![Fechar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Alguns anos atrás, vários colegas da IBM começaram a pensar sobre como seria possível criar uma versão ágil do IBM Rational Unified Process, ou simplesmente RUP. Ao mesmo tempo em que esse novo processo deveria ser ágil , também teria que refletir as boas práticas já contidas no RUP e consolidadas no mercado de software.
A partir desse momento, o time IBM formado por gerentes de metodologias , especialistas e analistas de processo começou a trabalhar em uma nova versão com a proposta de criar um novo processo enxuto, completo e ao mesmo tempo extensível.
A longo do tempo esse mesmo time percebeu que seria necessária a contribuição através de conhecimentos e experiências de um conjunto muito mais amplo de pessoas. Daí então que a IBM através do projeto EPF (Eclipse Process Framework), liderado por Per Kroll (Gerente de Métodos IBM) forneceu para a comunidade Eclipse o conteúdo da versão inicial desse novo processo, até então considerada uma versão “light” e “ágil” do RUP.
A partir desse momento , dezenas de comunidades e empresas foram contribuindo com novas implementações e práticas como por exemplo Scrum, XP (Extreme Programming), DSDM (Dynamic Systems Development Method), etc..
Atualmente o OpenUP encontra-se na versão 1.5.0.1 disponível no site Eclipse :
Equipe IBM Projeto EPF:
http://www.eclipse.org/projects/project_summary.php?projectid=technology.epf
O OpenUP está em conformidade com os princípios do Manifesto do Desenvolvimento de Software Ágil, possue uma abordagem iterativa e incremental e é um processo de baixa cerimônia que não está associado a nenhuma ferramenta especifica.
O OpenUP é um processo que consideramos Mínimo, Completo e Extensível, valorizando a colaboração entre a equipe e os benefícios aos interessados ao invés da formalidade e entregáveis desnecessários.
O processo pode ser facilmente entendido através das 3 camadas abaixo descritas:
- Ciclo de Vida do Projeto – Fases com foco nas necessidades dos
Stakeholders
O OpenUP apresenta a mesma distribuição de fases já conhecidas no RUP, onde o critério de saída de cada fase é no mínimo atender as seguintes respostas:
Iniciação: Todos os stakeholders concordam com o escopo e objetivos do projeto ?
Elaboração: Todos concordam com a arquitetura proposta e o valor entregue ao cliente considerando os riscos levantados?
Construção: Existe uma aplicação que está quase pronta rodando bem próxima a ser finalizada?
Transição: A aplicação está finalizada e o cliente satisfeito?
- Ciclo de Vida da Iteração com foco no time:
Além da divisão por fases já conhecida, o OpenUP divide o projeto em iterações (também conhecidas como Sprints segundo a metodologia SCRUM) planejadas que podem variar de alguns dias a algumas semanas (a media recomendada é de 4 semanas podendo ser reduzida ou aumentada em até aproximadamente 6 semanas). Ao final de cada iteração deve ser gerado um incremento ao Produto (Build executável ou demo).
Ao final de cada iteração geralmente é realizada uma retrospectiva e avaliação onde são discutidas as lições aprendidas e a saúde do projeto. Vale mencionar que o principal objetivo da retrospectiva é aprender com erros e acertos e não apontar culpados.
- Micro incrementos com foco individual:
Um micro incremento é a execução de um pequeno passo que deve ser mensurável para alcançar os objetivos de uma iteração. Este pode representar o resultado de alguns dias ou horas de trabalho de uma pessoa ou um grupo determinado.
Figura 1: Camadas OpenUP: Micro incrementos, ciclo de vida da iteração e ciclo de vida do projeto.
Como já citei anteriormente , o OpenUP teve sua origem a partir do próprio RUP, portanto podemos encontrar uma série de similaridades considerando que o OpenUP apresenta uma quantidade bem menor de produtos de trabalho, papéis e tarefas.
Vou então descrever algumas diferenças que acredito serem importantes. Além da menor formalidade e quantidade de produtos de trabalho a primeira diferença é a introdução do conceito de micro incrementos. Como já descrito acima, o micro incremento representa a execução de uma pequena unidade do trabalho e deve ser bem definido para que a equipe possa controlar e monitorar o progresso diário. Cada micro incremento é especificado e controlado através de itens de trabalho (work item) onde o monitoramento é diário.
Para entendermos melhor esse conceito podemos considerar o exemplo abaixo:
Definir a visão do produto é uma tarefa que muitas vezes pode levar semanas, então para assegurar o controle diário é necessário dividir a tarefa em partes menores como por exemplo: Identificar os Stakeholders do projeto ou Identificar as principais necessidades.
Outro exemplo seria a tarefa de desenvolver a solução. O RUP recomenda que o caso de uso ou cenário seja a unidade de implementação, planejamento e controle de progresso do projeto, mas mesmo que consideremos um cenário de um caso de uso, poderíamos levar dias ou semanas para fazer a especificação, design, implementação e teste. Podemos então dividir essa tarefa em unidades menores para o controle diário como especificar, implementar ou testar um passo de um cenário de um caso de uso.
Outra diferença que merece uma atenção especial é a disciplina de gerencia de projetos. O principal objetivo de um projeto ágil é reduzir o espaco de tempo entre os chamados “feedback loops”, ou seja, garantir o monitoramento diário do gerente do projeto para assegurar o bom progresso e permitir que a equipe reaja o mais cedo possível a qualquer situação de mudança ou risco.
Para acompanhar o status do projeto, o OpenUP recomenda os “Scrum Daily meetings”, onde através de reuniões rápidas diárias , a equipe inteira do projeto possa compreender o que os outros membros já realizaram, remover possíveis barreiras e planejar o que será feito até a próxima reunião.
Outra prática não capturada pelo RUP atualmente é o que chamamos de auto-organização do time de projeto. Se você deseja utilizar o RUP de uma maneira ágil, é necessário obrigatoriamente adotar essa prática. A auto-organização impacta varias áreas incluindo como o time irá se planejar e comprometer-se com o que deve ser feito (pelo time e não por um indivíduo), como o trabalho deverá ser atribuído (membros do time se “auto atribuem” ao trabalho ao invés de serem alocados por algum gerente ou líder). E por ultimo auto-organização tem a ver com a forma na qual os membros do time interagem dentro do projeto , lembrando que o papel do individuo dentro do projeto é muito mais importante que seu cargo funcional.
Apesar das diferenças citadas acima, ambos processos são bem semelhantes pois são fundamentados basicamente nas mesmas praticas já conhecidas no Rational Unifed Process focando principalmente na redução de riscos e aumento de valor aos Stakeholders do projeto.
Figura 2: Curva de Redução de riscos e criação de valor durante o ciclo de vida do projeto.
O OpenUP nos mostra que um processo ágil é disciplinado, diferente do que muitos pensam sobre desenvolvimento ágil ser sinônimo de “desenvolvimento bagunçado”. Adotar um processo ágil significa adotar as melhores práticas gerenciais e técnicas com bom senso e muita disciplina.
Podemos mencionar que adotar um bom processo nem sempre é o suficiente. Uma equipe madura e bem capacitada também é essencial, não esquecendo que um bom Gerente de Projeto (podendo ser chamado de Master ou Scrum Master) é extremamente importante pois ele será o responsável em garantir a harmonia da equipe e atuar como um mentor removendo as possíveis barreiras encontradas durante o projeto.
Para finalizar é importante lembrar que em um processo ágil, a transparência e o comprometimento é a chave do sucesso. A comunicação diária, aberta e transparente permite que membros do time possam influenciar sobre o que e como fazer ao invés de simplesmente agirem como “robôs” que obedecem ordens sobre o que deve ser feito.
Formada pela Universidade Mackenzie e Pós-graduada pela FAAP, atua na área de desenvolvimento de sistemas a 15 anos . Certificada em RUP (Rational Unified Process) , PMP (Project Management Professional), Scrum Master, Gerência de Requisitos e Gerência de Configuração de Mudanças (IBM Clearcase e Clearquest). Atualmente trabalha como Especialista em Engenharia de Software na brand Rational da IBM Brasil.
