Este documento apresenta uma introdução à metodologia Open UP, descrevendo seus princípios e práticas chaves, como equilibrar prioridades dos stakeholders, colaboração entre equipe, foco na arquitetura e evolução contínua. Também explica os papéis, artefatos e ciclo de vida do projeto com iterações, além de ferramentas de apoio.
4. Experiência dos participantes
Metodologias conhecidas
Áreas de atuação
Motivação pessoal para estudo
5. Teve suas origens no Rational Unified Process
(RUP), processo proprietário da IBM,
embasado em um framework de processos
Abordagem mais “clean” do RUP
Foi de encontro as necessidades de pequenas
e médias equipes, com uma abordagem
agilista (Manifesto Ágil)
6. Metodologia Ágil baseada nos princípios do
Unified Process
Abordagem Iterativa e Incremental
Baseada em Casos de Uso, cenários e com foco na
comunicação entre equipe e cliente
Open Source: Extensível e adaptável
Mantido pela Eclipse Foundation
É essencial a participação direta do stakeholder como
membro da equipe
7.
8. Encontra-se atualmente na versão 1.0,
recentemente lançada (Agosto 2007)
Lançada inicialmente pela IBM e após a
liberação do código, mantida pela Eclipse
Foundation
Library Open Source disponível para
download e extensível através do uso do EPF
(Eclipse Process Framework)
10. “Balance competing priorities to maximize stakeholder value ”
Prioridades definidas junto ao cliente
Business Centric X Architecture Centric
Metodologia Iterativa e Incremental – Prova constante de
valor
Três fatores de entendimento entre equipe e cliente:
O Problema a ser resolvido
Custos, Recursos, Cronograma do Projeto
Funcionalidades da Solução
11. “Balance competing priorities to maximize stakeholder value ”
Práticas
Conheça muito bem seu cliente e o que ele quer, mantendo-o na
“equipe do projeto”
Entenda muito bem o problema antes de pensar na solução
Faça a equipe conhecer o projeto como um todo
Utilize cenários e casos de uso para captura de requisitos
Alinhe prioridades continuamente durante o projeto
Gerencie mudanças naturalmente, elas são inevitáveis!!!
12. “Collaborate to align interests and share understanding ”
Software é criado por pessoas com diferentes visões e
interesses que devem trabalhar juntas;
Desenvolva práticas que criem um ambiente colaborativo,
alinhando interesses de toda equipe;
Opõe modelos adotados nas chamadas “Fábricas de
Software”
Equipe motivada
13. “Collaborate to align interests and share understanding ”
Práticas
Mantenha um entendimento comum do projeto dentro da equipe
através de artefatos e comunicação clara e pró-ativa
Desenvolva um ambiente saudável onde cada membro da equipe
gerencie seu próprio trabalho. Transparência e clareza nas atribuições
e responsabilidades
Compartilhe responsabilidades permitindo que todos da equipe se
sintam parte do projeto
Aprendizado contínuo – Workshops internos
14. “Focus on the architecture early to minimize risks and organize
development ”
Foco na arquitetura do sistema no início do projeto
O foco na arquitetura auxilia a equipe a avaliar complexidade,
mitigar riscos arquiteturais e organizar o desenvolvimento
A arquitetura deve ser a o alicerce do sistema, o meio para se
chegar ao fim, que é o objetivo do negócio
A arquitetura deve ser dirigida a atender as necessidades de
negócio
15. “Focus on the architecture early to minimize risks and
organize development ”
Práticas
Pense em uma arquitetura para aquilo que se conhece hoje, sem
querer prever o futuro – Business Centric
Use a arquitetura como uma forma de centrar os desenvolvedores no
objetivo do projeto
Organize a arquitetura evitando acoplamento e com componentes
reutilizáveis
Reuse e aprenda com componentes de outros projetos
16. “Evolve to continuously obtain feedback and improve ”
Promova práticas que permitam a equipe obter feedback e
provar valor continuamente ao cliente
Gerenciamento de Mudanças - Através do feedback
contínuo, as mudanças tem um impacto muito menor
A equipe sente-se motivada e participante direta do projeto
Esqueça a blindagem do seu projeto!!
17. “Evolve to continuously obtain feedback and improve ”
Práticas
Desenvolva o projeto em iterações
Foque a equipe na entrega do próximo build
Gerencie os riscos continuamente à partir do feedback obtido
Gerencie as mudanças de seu projeto
Meça o progresso continuamente, permitindo o redimensionamento
de recursos
Faça encontros regulares com a equipe, absorvendo idéias e
resolvendo problemas de cotidiano
19. As iterações no Open UP agrupam um ou mais
requisitos em períodos fixos, de um mês em média
Uma iteração contempla todas as fases da construção
do software
Ao final da iteração, uma versão do software rodando
é entregue ao cliente, comprovando o trabalho
realizado até então
A montagem das iterações é umas das disciplinas
mais complicadas na adoção de uma metodologia
iterativa e incremental
20. Cada iteração é composta por vários itens de trabalho.
Exemplo: Modelar banco, desenvolver camada de acesso
a dados, etc;
Para cada item de trabalho, o membro da equipe cria os
seus micro incrementos
O micro incremento entrega código e/ou artefato
diariamente para agregar valor a iteração
Através dos micro incrementos, o arquiteto pode avaliar a
qualidade do código produzido pelos desenvolvedores
21. Para as n iterações do projeto, repetem-se as ações abaixo:
23. É durante o ciclo de vida do projeto que os
artefatos serão gerados, permitindo ao
stakeholder e a equipe, tomarem decisões a
cerca do negócio, do projeto, dos riscos que
envolvem o processo de desenvolvimento
Um projeto é composto por várias iterações
O projeto é organizado em quatro fases e cada
iteração pode conter as mesmas fases que
organizam o projeto
24. Fase 1 – Inception - Esta fase objetiva a criação de uma
visão geral do problema a ser resolvido, propor os
pontos chaves do sistema, sugerindo ao menos uma
solução, baseando-se em variáveis como custo,
cronograma e recursos
Fase 2 – Elaboration – É nesta fase em que a equipe se
preocupará com o detalhamento dos requisitos e como
a arquitetura proposta irá trabalhar com os requisitos.
Neste momento a equipe deverá mitigar riscos técnicos
e não técnicos, alinhando as ações junto ao stakeholder
25. Fase 3 – Construction - Aqui, efetivamente, o sistema
será desenvolvido, focando em atender requisitos
propostos pela iteração. Ao final desta fase, será
entregue uma versão estável e testada do sistema
Fase 4 – Transition – O foco nesta fase é fazer a
transição da versão nova do software do ambiente do
desenvolvimento para o stakeholder. Aqui são
realizados e aplicadas técnicas de testes, de forma que o
software entregue na iteração seja totalmente funcional
28. Uma boa equipe conta com profissionais com
diferentes habilidades
Open UP sugere a divisão de
responsabilidades em papéis. Cada papel irá
trabalhar com um ou mais artefatos
Artefato é qualquer tipo de saída do processo
de desenvolvimento de software, seja ele
código, diagrama ou documentação
29.
30. O stakeholder representa o real interessado no
projeto. Pode ser uma pessoa ou um grupo de
pessoas representando uma instituição
O stakeholder deve participar ativamente de
todas as fases do projeto
Não é responsável direto por nenhum artefato,
porém participa indiretamente da confecção e
avaliação de outros artefatos
31. Responsável por ser o elo de ligação entre o
cliente e a equipe.
Em uma nova abordagem, tem o foco no
negócio, Analista de Negócio
A interação do Analista com os artefatos
32. Responsável pela modelagem da solução, a
arquitetura do software
Deve coordenar tecnicamente os
desenvolvedores
A interação do Arquiteto com os artefatos
33. Responsável pelo desenvolvimento do software,
incluindo seguir a arquitetura proposta,
implementando testes unitários, garantindo a
qualidade do código desenvolvido
A interação do Desenvolvedor com os artefatos
34. Responsável pela equipe de projeto, coordenando a
interação com o stakeholder, mantendo a equipe
focada no projeto
Deve ter um perfil de liderança e organização
A interação do Gerente de Projeto com os artefatos
35. Responsável imediato pela avaliação de cada versão
do software liberada para o stakeholder
Deve coordenar os testes de forma sistemática,
notificando a equipe dos resultados e sugerindo
correções
A interação do Tester com os artefatos
37. Por ser uma ferramentas open source e
relativamente nova, existem poucas
ferramentas de apoio ao gerenciamento do
projeto.
Recentemente foram lançadas duas
ferramentas, a Project Koach e a Mingle.
Análise da Project Koach, em meu blog
38. Documentação completa para consulta on-line e também para download
http://www.epfwiki.net/wikis/openup/index.htm
http://www.eclipse.org/epf/downloads/openup/openup_downloads.php
EPF Composer – Ferramenta baseado na plataforma Eclipse para extensão do
OpenUP
http://www.epfwiki.net/wikis/openup/index.htm
Project Koach – Ferramenta de apoio ao gerenciamento do projeto
http://www.projectkoach.com/
Blogs com conteúdo sobre OpenUP e metodologias
Meu Blog - http://jean-streleski.blogspot.com
José Paulo Papo - http://josepaulopapo.blogspot.com/
Paulo Vasconcellos - http://finito-log.blogspot.com/
Manifesto Ágil
http://agilemanifesto.org/