Geral

À medida que percorre os vários produtos de trabalho, as tarefas e as funções no RUP (Rational Unified Process), você pode 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 destine apenas a projetos grandes?

O tópico sobre adaptação aborda todas essas questões.

A finalidade de um projeto de software é produzir um produto. Um processo eficaz permite que o projeto gere um produto que atenda às necessidades de seus investidores, dentro do tempo e do orçamento. Para obter informações adicionais, consulte o artefato: Produto.

A chave para um bom processo consiste em ajustá-lo para ele que seja o mais simples possível e, ao mesmo tempo, seguindo os Princípios Básicos.

As diretrizes aqui descritas devem ser consideradas durante o ajuste de um processo. Uma orientação mais detalhada é fornecida em Conceito: Ajuste do RUP.

Construir Primeiro uma Estrutura

Um problema comum em muitos projetos é que geralmente eles têm um foco rigoroso em 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 focar rigorosamente uma área problemática específica.

Uma vez criada a estrutura de um processo de software de qualidade, um projeto pode efetivamente ter como foco uma área específica que tenha sido identificada como a principal causa de seus problemas. Essa seleção baseia-se na identificação e priorização dos riscos do projeto e na determinação prévia de estratégias de mitigação para os riscos identificados.

Não Incluir Tarefas e Produtos de Trabalho 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. Entretanto, as tarefas e os produtos de trabalho 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 tarefas forem necessárias, pense em designá-las a uma equipe de suporte qualificada.

Minimizar Produtos de Trabalho Intermediários Formais

O formato dos produtos de trabalho intermediários, aqueles não destinados ao produto final, não é tão importante quanto à tarefa e o esforço necessários para produzi-los. Não importa a aparência deles ou as ferramentas utilizadas para construí-los, desde que atendam à finalidade. Como disse Dwight D. Eisenhower, "O plano não é nada; o planejamento é tudo."

Uma armadilha comum é formalizar os produtos de trabalho cedo demais.  Versões anteriores de produtos de trabalho 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 produto de trabalho 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 produto de trabalho e, em alguns projetos, talvez sejam as únicas exigências.

Utilizar Formatos Convenientes

Um produto de trabalho pode ser adaptado de modo a ser mantido em qualquer formato. Por exemplo, o documento de Visão pode ser capturado como uma página da Web, o Plano de Projeto pode ser capturado como um arquivo do Microsoft Project e a Lista de Riscos pode ser capturada como um tipo de requisito do Rational RequisitePro .

Gerar quando possível

Alguns projetos gastam muito tempo preenchendo gabaritos de documentos formais, recortando e colando manualmente as informações. Em vez disso, considere gerar os documentos necessários a partir da origem, utilizando ferramentas como o Rational SoDA, ou negocie uma forma mais simples de fornecer as mesmas informações, por exemplo, utilizando o Rational Rose Publisher para gerar um modelo de design com baseado na Web.

Em muitos casos, você pode ignorar totalmente um produto de trabalho porque as informações são fornecidas implicitamente 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 produto de trabalho útil é aquele que comunica informações importantes.  Essas informações precisam estar ao alcance das pessoas que precisam delas. 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.

Rever o Processo Regularmente

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 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 incorporados em suas práticas. Siga a essência dessas práticas ao adaptar as tarefas e os produtos de trabalho de modo a ajustá-los às suas necessidades.