Diretrizes: Adaptação do Processo
Tópicos
Á medida que você percorre os vários artefatos, as atividades e os papéis do Rational Unified Process (RUP), é possível perguntar a si mesmo:
- Preciso disto?
- Como devo percorrer todos esses itens para determinar quais deles são necessários para o projeto?
- Não é óbvio que o RUP se destina apenas a projetos grandes?
O tópico sobre adaptação aborda todas essas questões.
A finalidade de um projeto de software é gerar um produto. Um processo eficaz permite que o projeto gere um produto que atenda às necessidades de seus envolvidos, dentro do prazo e do orçamento.
A chave para um processo eficaz consiste em adaptá-lo para que seja o mais simples possível, seguindo um método de melhores práticas.
As diretrizes descritas aqui devem ser consideradas para a adaptação de um processo. Diretrizes mais detalhadas são fornecidas em Conceitos: Implementação de um Processo em um Projeto e em Atividade: Elaborar Caso de Desenvolvimento.
Um problema comum em muitos projetos é que geralmente enfocam em demasia uma área específica, aprofundando-se nos respectivos detalhes, sem a certeza de que haja conhecimento suficiente sobre os elementos "essenciais" que estão envolvidos no ciclo de vida total do processo para gerar um produto de qualidade.
Em geral, é melhor abordar todos os elementos essenciais de um processo de uma maneira superficial antes de enfocar detalhadamente uma área problemática específica.
Uma vez criado o framework de um processo de software de qualidade, um projeto poderá efetivamente concentrar-se em uma área específica que tenha sido identificada como a principal causa de seus problemas. Essa escolha baseia-se na identificação e priorização dos riscos do projeto e na determinação prévia de estratégias que visem minimizar esses riscos identificados.
Não incluir atividades e artefatos que não possam ser claramente justificados
O gerente de projetos ou o engenheiro de processos bem-intencionado pode ter uma extensa lista de itens desejáveis como, por exemplo, métricas, controles, relatórios, etc. Contudo, atividades e artefatos custam tempo e dinheiro. Alguns desses custos, como a interação diária com o conjunto de ferramentas do ambiente, podem estar visíveis ou simplesmente disfarçados na produtividade mais baixa em tarefas padrão.
Você deve distinguir as principais necessidades do processo na lista de itens desejáveis e determinar se as vantagens compensam o custo.
Poupar os desenvolvedores em relação ao processo
É provável que você tenha uma equipe altamente treinada com importantes habilidades de design, implementação e teste. Não os faça perder horas toda semana preenchendo formulários, aprimorando a documentação ou tentando aprender ferramentas complicadas. Se essas atividades forem necessárias, pense em designá-las a uma equipe de suporte qualificada.
Minimizar os artefatos formais intermediários
O formato dos artefatos intermediários, aqueles não destinados ao produto final, não é tão importante quanto à atividade e o esforço necessário para produzi-los. Não importa a aparência que eles tenham, nem as ferramentas usadas para criá-los, desde que atendam à sua finalidade. Como disse Dwight D. Eisenhower, "O plano não é nada; o planejamento é tudo".
Uma armadilha comum é formalizar os artefatos cedo demais. Versões anteriores de artefatos geralmente se desenvolvem com rapidez e permanecem atuais por algum tempo como representações diferentes, enquanto suas implicações são exploradas. A documentação formal pode impedir esse processo; é possível que você gaste muito tempo aprimorando um artefato que venha a ser muitas vezes dispensável. Diagramas manuscritos e descrições simples em cartões de índice são geralmente suficientes nos primeiros estágios de um artefato e, em alguns projetos, talvez sejam as únicas exigências.
Um artefato pode ser adaptado de modo a ser mantido em qualquer formato. Por exemplo, é possível capturar o documento de Visão como uma página da Web, o Plano de Projeto como um arquivo do Microsoft Project e a Lista de Riscos como um tipo de requisito do Rational RequisitePro.
Gerar quando possível
Alguns projetos gastam muito tempo preenchendo templates de documentos formais e recortando e colando informações manualmente. Em vez disso, gere os documentos necessários a partir da origem, usando ferramentas como o Rational SoDA, ou tente uma maneira mais simples de fornecer as mesmas informações, como usando o Rational Rose Publisher para gerar um modelo de design baseado na Web.
Em muitos casos, você pode ignorar totalmente um artefato porque as informações são implicitamente fornecidas no ambiente. Por exemplo, em vez de gerar a seção do Plano de Gerenciamento de Requisitos que lista os atributos de tipos de requisitos, você pode optar apenas por fornecer o projeto do Rational RequisitePro adaptado, com os tipos de requisitos e a rastreabilidade aplicáveis e, depois, examiná-lo com as partes interessadas. Outro exemplo consiste em fornecer uma versão somente leitura dos arquivos do Microsoft Project às partes interessadas, em vez de duplicar imagens gráficas em um Plano de Desenvolvimento de Software separado.
Usar a Web
Um artefato útil é aquele que comunica informações importantes. Essas informações precisam estar ao alcance das pessoas que precisam delas, e a tecnologia da Web é um excelente mecanismo para essa finalidade. Se os requisitos, o design e a implementação estiverem disponíveis na Web, não haverá necessidade de gerar grandes conjuntos de documentação impressa que se tornarão rapidamente obsoletos.
Usar ferramentas integradas
Selecione ferramentas que se ajustem ao processo e adapte-o para se ajustar a elas. Os resultados desejados são um processo e um conjunto de ferramentas de fácil utilização. Em geral, as ferramentas integradas são mais consistentes que as não integradas, além de fornecer métricas e relatórios mais informativos.
Reveja o processo regularmente para aprimorar e reduzir sua complexidade. Se a equipe não estiver convencida de que cada passo do processo fornece valor agregado ao produto, é provável que o processo seja interrompido.
Adaptar mas manter as melhores práticas
O RUP incentiva a adaptação. Contudo, ela não é uma licença para ignorar o processo como um todo. Os fundamentos do RUP estão embutidos nas melhores práticas. Siga o espírito dessas melhores práticas ao adaptar as atividades e os artefatos para que atendam às suas necessidades.
Copyright
(c) 1987 - 2001 Rational Software Corporation
| 
