quinta-feira, fevereiro 15, 2007

Por que realizar iterações no RUP ?

Por que iteramos? Será que iteramos apenas por causa do escopo? E aí sua pergunta é pertinente: se eu, de algum modo, conseguir fechar o escopo(o que na vasta maioria dos projetos de software não ocorre) então para que usar iterações?

A divisão em iterações não é apenas uma forma de controlar o escopo e gerenciar mudanças e incertezas. Na verdade dividir um projeto em mini-projetos(as iterações) é uma abordagem para redução e gerenciamento de riscos. Cada iteração deve possuir objetivos claros(a ênfase muda conforme as fases de iniciação, elaboração, construção e transição ) e, principalmente, um conjunto de riscos que serão mitigados ou eliminados a cada iteração.

Além disso cada iteração é realmente tratada como um projeto tendo um post-mortem e lições aprendidas (chamada no RUP de avaliação da iteração ou então de retrospectiva da iteração). Segundo os autores do RUP, se você não estiver fazendo uma avaliação da iteração a cada timebox de iteração então você não está usando o RUP. E olha que todos dizem isso :-) . Esse é um dos motivos porque acho que poucas são realmente as empresas que usam RUP.

Alguns exemplos de riscos, portanto, que poderão ser mitigados radativamente seriam:

- Risco do escopo não estar definido (este é o item que você citou no email e é um dos possíveis. Realmente quando passamos da fase de Elaboração a probabilidade desse risco ocorrer será muito mais baixa... mas ainda possível porque estamos falando em projetos de software... he, he! )

- Risco de não se dominar bem uma tecnologia

- Risco de mudanças de alto impacto devido a mudanças no mercado e no negócio - Risco de turn-over da equipe

- Risco de não ocorrer melhoria dos processos do time durante o projeto. Esse é um dos grandes benefícios interesssantes nos projetos iterativos. Você não espera até o fim do projeto para aplicar Lições aprendidas. Você faz uma espécie de post-mortem de projeto a cada iteração e não apenas no final. E é responsabilidade do GP e da equipe verificar o que não funcionou muito bem e definir atividades para melhorar isso já na próxima iteração. É interessante notar que esse feedback contínuo se alinha fortemente com as noções de Nonaka e Takeuchi acerca da criação de conhecimento e de novos produtos.

- Risco da equipe não ter objetivos claros de curto prazo

- Risco no processo de homologação da aplicação Além disso é importante notar que o proprio criador do processo cascata já disse e repetiu várias vezes que ele não foi bem compreendido e que o que ele explicou em seu artigo(que poucos que aplicam waterfall leram) é a necessidade de se colocar em produção apenas a segunda versão do software realizado no projeto . Vide: http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf especialmente a página 48.

Convido a todos a experimentar realmente o RUP ou outro processo iterativo como deveria ser feito e não mascarando e apenas usando os artefatos. É uma grande quebra de paradigma, mas vocês notarão a diferença com certeza" Mas, se precisarem de ajuda, peçam-na realmente a quem já usou o RUP de forma iterativa e ouçam esse pessoal. Não podemos ficar para trás em algo que já revolucionou a forma de fazer software nos EUA, na Europa e agora está chegando na Índia(a prova disso é o número de papers e artigos de indianos sobre os processos iterativos e ágeis).

Para mais detalhes documentados do porquê é sempre mais vantajoso dividir um projeto (por exemplo de 6 meses de construção em 6 "mini-projetos" de 1 mês) em iterações vide:

Bittner e Spence - Managing Iterative Software Development Projects

Mike Cohn - Agile Estimating and Planning

Reinertsen - Managing the Design Factory

Smith e Reinertsen - Developing products in half the time, 2nd edition

Marcadores:

0 Comentários:

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas