Your SlideShare is downloading. ×
Open Up – Gerenciando Projetos Sob Principios Ágeis
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Open Up – Gerenciando Projetos Sob Principios Ágeis

3,544
views

Published on

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

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,544
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
167
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. JORNADA DA INFORMÁTICA - UNESP BAURU
  • 2.  O que é Open UP?  Core Principles  Ciclo de Iterações  Ciclo do Projeto  Papéis e Artefatos  Informações Adicionais  Dúvidas
  • 3. Apresentação, origem e situação atual
  • 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.  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. Os quatro conceitos chaves
  • 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. “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. “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. “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. “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. “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. “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. “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. Organização e geração das iterações
  • 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.  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. Para as n iterações do projeto, repetem-se as ações abaixo:
  • 21. O Ciclo completo do projeto
  • 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.  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.  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. Redução do risco e criação constante de valor
  • 26. A relação entre os papéis e artefatos
  • 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.  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.  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.  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.  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.  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.  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. Ferramentas de apoio e referências
  • 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.  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. E-mail: jrs.net@gmail.com Blog: http://jean-streleski.blogspot.com msn: jeanjrs@hotmail.com

×