Padrões para uso das fases e iterações do RUP

A divisão de iterações entre as fases do RUP pode seguir um número de padrões ( patterns ). Entender esses padrões pode ajudar os gerentes de projetos iterativos a decidir como organizar melhor as iterações nas fases.

O número de iterações nas fases pode variar de acordo com os tipos de riscos:

Na fase de iniciação ( Inception ) : O número de iterações depende da complexidade do negócio e do domínio do problema. Em casos de processos de aquisições formais também a fase de iniciação pode ser mais longa e ter um número maior de iterações.

Na fase de elaboração ( Elaboration ): O número de iterações depende da complexidade dos riscos e questões técnicas e da novidade tecnológica.

Na fase de Construção ( Construction ): O número de iterações depende da quantidade de funcionalidades que precisam ser desenvolvidas.

Na fase de Transição ( Transition ): O número de iterações depende da complexidade de implantar e configurar a solução num ambiente de homologação e produção, depende do número de ciclos de testes de aceitação (como alpha testing, beta testing, etc) e também da necessidade ou não de atividades de migração ou convivência paralela de sistemas.

Abaixo seguem as figuras que mostram cada um dos padrões. A última figura mostra um exemplo de um grande sistema dividido em várias evoluções. Notem que as estratégias e padrões adotados podem mudar de acordo com a evolução em que se está no momento.


Padrão para desenvolvimento incremental:

Padrão para desenvolvimento evolucionário

Padrão para entrega incremental


Padrão para construção imediata


Padrão "Sem Elaboração"


Exemplo de uso

Materiais sobre RUP e processos iterativos

No site Erudio estão publicados os materiais de minha disciplina de RUP e Processos Iterativos, realizada pela pós-graduação em Engenharia de Software da Universidade São Judas Tadeu. Material baseado em uma série de livros e artigos e que versa sobre princípios e práticas do Rational Unified Process versão 7 (a nova versão lançad em 2006), gestão de projetos iterativos, OpenUP e OpenUP/Basic.

Publiquei a ementa em formato pdf mas coloco também aqui no blog para facilitar. Até o dia dessa postagem foram incluídas as aulas de 1 a 3. Semanalmente serão inseridas novas aulas (Até a finalização na aula 6. As aulas 7 e 8 se referem a atividades como o RUP Game e apresentações de trabalhos dos alunos).

O material se encontra na seção de downloads do site Erudio.

Objetivos da disciplina

Ao final da disciplina os alunos estarão habilitados a:

* Conhecer os princípios e práticas do RUP 7 e RUP 2003.
* Aplicar a gestão, o planejamento e as estimativas de projetos de forma iterativa.
* Comparar o RUP, o OpenUP e os processos de desenvolvimento ágil.
* Elaborar um planejamento para adoção do RUP em uma organização.
* Conhecer ferramentas e técnicas para a configuração e customização de processos

Plano de Aulas

Aula 01
- Apresentação
- Introdução
• Terminologia básica do RUP
- Fundamentos Teóricos
• Princípios do RUP 2003
• Princípios do RUP 7

Aula 02
- Práticas do RUP – Parte 1
• Práticas para demonstrar o valor iterativamente
• Práticas para foco contínuo em qualidade
- Scrum Game

Aula 03
- Práticas do RUP – Parte 2
• Práticas para balancear as prioridades dos envolvidos
• Práticas para colaborar entre times
• Práticas para elevar o nível de abstração
• Práticas para adaptar o processo
- Definição dos temas e dos grupos de trabalho

Aula 04
- Planejando um projeto iterativo – Parte 1
• Os níveis de planejamento iterativo
• Planejamento Geral do Projeto
• Planejamento de Fases e Evoluções
• Planejamento de Iterações

Aula 05
- Planejando um projeto iterativo – Parte 2
• Planejamento diário
• Avaliações de Iterações, Fases e Projetos
• Estimando projetos iterativos
• Contratos em projetos iterativos
- OpenUP
• OpenUp e Desenvolvimento ágil
• Scrum e OpenUP/Basic
- Planning Poker

Aula 06
- Adotando RUP em uma organização
• Avaliando a situação atual e analisando os problemas
• Criando um plano de adoção e comunicação
• Definindo um plano detalhado para o esforço de implantação
• Avaliar e realizar melhorias contínuas no processo
- Ferramentas para customização de processos
• EPF Composer
• Rational Method Composer

Aula 07
- RUP Game

Aula 08
- Apresentação dos trabalhos realizados pelos alunos
- Conclusão da disciplina

Artigos para leitura

Aula 2 - Key principles for business-driven development


Aula 4 – Five Levels of Agile Planning: From Enterprise Product Vision to Team Stand-up

Aula 6 – Introducing IBM Rational Method Composer

Obs: O número da aula se refere à aula em que um resumo deve ser entregue para o professor na sala.

Bibliografia

1. Ambler, Scott - The Enterprise Unified Process: Extending the Rational Unified Process, Prentice Hall, 2005.
2. Bergstrom, Stefan e Raberg, Lotta - Adopting the Rational Unified Process: Success with the RUP, Addison-Wesley, 2003.
3. Bittner, Kurt e Spence, Ian - Managing Iterative Software Development Projects, Addison-Wesley, 2006.
4. Cohn, Mike – Agile Estimating and Planning, Prentice Hall, 2005.
5. Gibbs, Dennis - Project Management with the IBM Rational Unified Process: Lessons From The Trenches, IBM Press, 2006.
6. Kroll, Per - The Rational Unified Process Made Easy: A Practitioner's Guide to Rational Unified Process, Addison-Wesley, 2003.
7. Kroll, Per e McIsaac, Bruce - Agility and Discipline Made Easy: Practices from OpenUP and RUP, Addison-Wesley, 2006.
8. Kruchten, Philippe - The Rational Unified Process: An Introduction, Third Edition, Addison-Wesley, 2003.
9. McConnell, Steve – Software Estimation: Demystifying the Black Art, Microsoft Press, 2006.
10. Paula Filho, Wilson de Pádua – Engenharia de Software, 2ª. Edição, Editora LTC, 2003.
11. Schwaber, Ken - Agile Project Management with Scrum, Microsoft Press, 2004.
12. Site com o OpenUP/Basic publicado
13. Site para download do OpenUP
14. Site oficial do RUP e Rational Method Composer
15. Site oficial de ferramentas IBM Rational

RUP ágil ?

Resposta curta: Sim!!!!

Resposta longa:

Com base no manifesto ágil você pode definir sim o RUP como sendo ágil. Agora uma coisa que se deve lembrar sempre: o RUP não é um processo e sim um framework de processo. Isso significa que customiza-se o RUP de acordo com suas necessidades organizacionais e de projetos. Dessa forma você pode ter um RUP mais "leve e ágil" ou um RUP mais "pesado". No livro de Craig Larman chamado "Agile and Iterative Development: A Manager's Guide" encontra-se uma figura com a escala de processos e é interessante notar que o RUP está tanto do lado ágil como do lado mais pesado.

De qualquer modo, o RUP prega o desenvolvimento iterativo. Só por essa característica ele é mais ágil que seus possíveis concorrentes sequenciais.

A pergunta mais importante é: vocês realizam iterações com avaliações periódicas quando usam o RUP em projetos? Se a pergunta for positiva então você provavelmente usa mesmo o RUP. Se não (se não utiliza iterações), conforme os criadores do RUP, você não usa o RUP mas apenas seus artefatos dentro de outro processo de desenvolvimento.

Para quem não acredita no parágrafo acima vide:

http://www.agilealliance.org/system/article/file/941/file.pdf (fortemente recomendável!!! O título é ótimo: "How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering") .

É um artigo escrito a três mãos sendo que dois dos autores são os mantenedores do RUP. Olhe que maravilha o que escrevem para provar que RUP é ágil no passo 2:
"The RUP was not meant by its authors to be either heavy or predictive, and it is due to superimposition ofincorrect process ideas or misunderstanding of the RUP, exacerbated by the large set of detailed process documentation that the RUP product provides, that it could be so mischaracterized or poorly implemented.The authors of the RUP intended and encourage it to be applied in a light, agile, adaptive process spirit."

E no passo 4 está a ênfase no desenvolvimento iterativo.

Outro artigo, sobre a versão mais nova do RUP:
http://www-128.ibm.com/developerworks/rational/library/oct05/kroll/

Note o que escrevem(no segundo artigo) no princípio de demonstrar valor iterativamente(Anti-pattern é algo que não deve ser feito quando se usa o RUP. Um anti-pattern é uma prática ruim que costuma ser encontrada no mercado, diferentemente do pattern que é uma prática boa em determinado contexto):

Demonstrate value iteratively
"Benefits: Early risk reduction, higher predictability, trust among stakeholders

Pattern: Adaptive management using an iterative process. Attack major technical, business, and programmatic risks first. Enable feedback by delivering incremental user value in each iteration.

Anti-pattern: Plan the whole lifecycle in detail, track variances against plan. Detailed plans are better plans. Assess status by reviewing specifications."

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

Análise de ROI para projetos de TI

Abaixo segue uma lista de bons livros que li sobre o assunto de retorno de investimento ( ROI ) de projetos de desenvolvimento de software e melhoria de processos. Coloquei aqui após ter respondido a uma pergunta sobre essa bibliografia no fórum do PMI-SP.


Software by Numbers: Low-Risk, High-Return Development

ROI of Software Process Improvement: Metrics for Project Managers and Software Engineers

ROI of Software Process Improvement: Metrics for Project Managers and Software Engineers

Making the Software Business Case: Improvement by the Numbers

Software Estimation: Demystifying the Black Art

Metodologias Ágeis, Escopo e Preço Fixo

Segue uma resposta que dei a uma pergunta na lista CMM-Brasil sobre "Como uma metodologia ágil resolve o problema cliente x escopo x preço global fixo?"

Minha resposta (que poderá ser útil aos leitores do meu blog):

Normalmente se faz assim(é uma das possibilidades mais comuns e que dão mais certo do que fazer apenas um contrato de preço fixo): Um preço global fixo é dado para as fases de Iniciação e Elaboração do RUP. Depois é dado outro preço fixo para a Construção e Transição (onde fica o esforço e o custo maior do projeto ). Dessa maneira o risco do segundo contrato fica muito menor e a contratada não precisa jogar enormes margens de risco para se proteger de projetos com grande incerteza (pois ao término da fase de elaboração você precisa atender ao objetivo de ter uma arquitetura executável estável ).

E mesmo que você tenha tudo fixo ainda dá para ser iterativo (mas não ágil).

Fiz uma palestra para o PMI-SP tratando sobre como realizar contratos melhores para projetos iterativos, com foco em RUP (que na sua versão 7 está ainda mais iterativo e deu uma forte guinada para o mundo ágil). Ele trata em mais detalhes sobre o que falei acima. Dê uma olhada em:

Palestra sobre contratos iterativos no PMI-SP


Mais um segundo assunto: Gostaria de lembrar que diversos processos ágeis e iterativos (como o RUP, OpenUP, Scrum) possuem uma forte disciplina e formalização e são, ao mesmo tempo, ágeis. Quem ainda não acredita precisa ler o livro "Managing Iterative Software Development Projects" de Bittner e Spence e o livro "Balancing Agility and Discipline" do, nada mais e nada menos, Boehm.

Ministrarei uma disciplina de pós onde falarei muito destes e outros temas. Vou disponibilizá-las online e me proponho a fazer palestras gratuitas sobre alguns dos conceitos apresentados na gestão de projetos iterativos sem perder a disciplina e a formalidade. Acho que essa dicotomia "ágil X formalismo" já furou faz tempo. Mas ela ainda vigora pois muitos ainda acham que agilidade é igual a XP que é igual a code and fix. Temos que lembrar que RUP, Scrum, OpenUP, FDD também são ágeis e possuem um nível de formalidade muito interessante para qualquer projeto.

O que se vê hoje no mercado é que muitas empresas dizem que usam o RUP mas não aplicam os princípios que estão por trás dele, especialmente o desenvolvimento iterativo. Na verdade usam os artefatos do RUP em um formato cascata, algo que inclusive é desaconselhado pela própria IBM Rational.

Outras ferramentas de integração contínua e automação de builds

Duas novas ferramentas interessantes para integração contínua e automação de builds se encontram no mercado.

A primeira se chama Pulse. Ela possui uma interface gráfica inovadora e diversas facilidades para builds distribuídos.

A segunda se chama Bamboo. O ponto mais interessante da ferramenta é que ela foi construída pela Atlassian, os criadores do famoso sistema de gestão de defeitos e issues chamado JIRA. Desse modo, uma de suas funcionalidades interessantes é a integração bidirecional com o JIRA.

Ambos os produtos possuem um preço acessível para uma categoria de ferramenta (automação de builds e integração contínua) que a cada dia que passa se torna mais essencial em qualquer processo de desenvolvimento de software.