Open Up – Gerenciando Projetos Sob Principios Ágeis

3,943 views
3,819 views

Published on

Palestra sobre Open UP realizada na Jornada da Informática da Unesp Bauru no ano de 2007

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,943
On SlideShare
0
From Embeds
0
Number of Embeds
35
Actions
Shares
0
Downloads
176
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Open Up – Gerenciando Projetos Sob Principios Ágeis

  1. 1. JORNADA DA INFORMÁTICA - UNESP BAURU
  2. 2.  O que é Open UP?  Core Principles  Ciclo de Iterações  Ciclo do Projeto  Papéis e Artefatos  Informações Adicionais  Dúvidas
  3. 3. Apresentação, origem e situação atual
  4. 4.  Experiência dos participantes  Metodologias conhecidas  Áreas de atuação  Motivação pessoal para estudo
  5. 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. 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. 7.  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)
  8. 8. Os quatro conceitos chaves
  9. 9. “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
  10. 10. “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!!!
  11. 11. “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
  12. 12. “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
  13. 13. “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
  14. 14. “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
  15. 15. “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!!
  16. 16. “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
  17. 17. Organização e geração das iterações
  18. 18.  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
  19. 19.  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
  20. 20. Para as n iterações do projeto, repetem-se as ações abaixo:
  21. 21. O Ciclo completo do projeto
  22. 22.  É 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
  23. 23.  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
  24. 24.  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
  25. 25. Redução do risco e criação constante de valor
  26. 26. A relação entre os papéis e artefatos
  27. 27.  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
  28. 28.  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
  29. 29.  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
  30. 30.  Responsável pela modelagem da solução, a arquitetura do software  Deve coordenar tecnicamente os desenvolvedores A interação do Arquiteto com os artefatos
  31. 31.  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
  32. 32.  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
  33. 33.  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
  34. 34. Ferramentas de apoio e referências
  35. 35.  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
  36. 36.  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/
  37. 37. E-mail: jrs.net@gmail.com Blog: http://jean-streleski.blogspot.com msn: jeanjrs@hotmail.com

×