SlideShare ist ein Scribd-Unternehmen logo
1 von 40
Downloaden Sie, um offline zu lesen
JORNADA DA INFORMÁTICA - UNESP BAURU
   O que é Open UP?
   Core Principles
   Ciclo de Iterações
   Ciclo do Projeto
   Papéis e Artefatos
   Informações Adicionais
   Dúvidas
Apresentação, origem e situação atual
   Experiência dos participantes

   Metodologias conhecidas

   Áreas de atuação

   Motivação pessoal para estudo
   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)
 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
Open Up – Gerenciando Projetos Sob Principios Ágeis
   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)
Os quatro conceitos chaves
“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
“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!!!
“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
“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
“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
“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
“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!!
“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
Organização e geração das iterações
   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
   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
Para as n iterações do projeto, repetem-se as ações abaixo:
O Ciclo completo do projeto
   É 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
   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
   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
Redução do risco e criação constante de valor
A relação entre os papéis e artefatos
   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
Open Up – Gerenciando Projetos Sob Principios Ágeis
   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
   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
   Responsável pela modelagem da solução, a
    arquitetura do software
   Deve coordenar tecnicamente os
    desenvolvedores
         A interação do Arquiteto com os artefatos
   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
 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
 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
Ferramentas de apoio e referências
   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
 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/
Open Up – Gerenciando Projetos Sob Principios Ágeis
E-mail: jrs.net@gmail.com
Blog: http://jean-streleski.blogspot.com
msn: jeanjrs@hotmail.com

Weitere ähnliche Inhalte

Was ist angesagt?

Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...Keila Freitas
 
T1 g13.modelo cascata
T1 g13.modelo cascataT1 g13.modelo cascata
T1 g13.modelo cascatawilsonguns
 
Ciclo de vida de software
Ciclo de vida de softwareCiclo de vida de software
Ciclo de vida de softwarediha36
 
Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com ScrumFerramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com ScrumThiago Barros, PSM
 
Modelo cascata apresentação
Modelo cascata apresentaçãoModelo cascata apresentação
Modelo cascata apresentaçãoerysonsi
 
Gestão de Projetos (25/08/2014)
Gestão de Projetos (25/08/2014)Gestão de Projetos (25/08/2014)
Gestão de Projetos (25/08/2014)Alessandro Almeida
 
Ciclo de vida de software
Ciclo de vida de softwareCiclo de vida de software
Ciclo de vida de softwarediha36
 
Desenvolvimento Iterativo-Incremental
Desenvolvimento Iterativo-IncrementalDesenvolvimento Iterativo-Incremental
Desenvolvimento Iterativo-IncrementalRuan Carvalho
 
Modelos de ciclo de vida de software
Modelos de ciclo de vida de softwareModelos de ciclo de vida de software
Modelos de ciclo de vida de softwareYuri Garcia
 

Was ist angesagt? (19)

Os 12 Princípios Ágeis
Os 12 Princípios ÁgeisOs 12 Princípios Ágeis
Os 12 Princípios Ágeis
 
Metodologia Ágil
Metodologia ÁgilMetodologia Ágil
Metodologia Ágil
 
Aula 2 - Processos de Software
Aula 2 - Processos de SoftwareAula 2 - Processos de Software
Aula 2 - Processos de Software
 
04 Unified process
04 Unified process04 Unified process
04 Unified process
 
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
 
Aula 3 - Engenharia de Software
Aula 3 - Engenharia de SoftwareAula 3 - Engenharia de Software
Aula 3 - Engenharia de Software
 
T1 g13.modelo cascata
T1 g13.modelo cascataT1 g13.modelo cascata
T1 g13.modelo cascata
 
Ciclo de vida de software
Ciclo de vida de softwareCiclo de vida de software
Ciclo de vida de software
 
Processo 01
Processo 01Processo 01
Processo 01
 
Modelo em Cascata
Modelo em CascataModelo em Cascata
Modelo em Cascata
 
Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com ScrumFerramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum
 
Modelo cascata apresentação
Modelo cascata apresentaçãoModelo cascata apresentação
Modelo cascata apresentação
 
Outras Metodologias Ágeis Parte 3
Outras Metodologias Ágeis Parte 3Outras Metodologias Ágeis Parte 3
Outras Metodologias Ágeis Parte 3
 
Gestão de Projetos (25/08/2014)
Gestão de Projetos (25/08/2014)Gestão de Projetos (25/08/2014)
Gestão de Projetos (25/08/2014)
 
Modelo cascata
Modelo cascataModelo cascata
Modelo cascata
 
Ciclo de vida de software
Ciclo de vida de softwareCiclo de vida de software
Ciclo de vida de software
 
Crystal Clear
Crystal ClearCrystal Clear
Crystal Clear
 
Desenvolvimento Iterativo-Incremental
Desenvolvimento Iterativo-IncrementalDesenvolvimento Iterativo-Incremental
Desenvolvimento Iterativo-Incremental
 
Modelos de ciclo de vida de software
Modelos de ciclo de vida de softwareModelos de ciclo de vida de software
Modelos de ciclo de vida de software
 

Ähnlich wie Open Up – Gerenciando Projetos Sob Principios Ágeis

Aula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a ObjetosAula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a ObjetosLeandro Rezende
 
Fdd em uma casca de banana
Fdd em uma casca de bananaFdd em uma casca de banana
Fdd em uma casca de bananaejedelmal
 
Aula 1 Analise e Projeto
Aula 1   Analise e ProjetoAula 1   Analise e Projeto
Aula 1 Analise e ProjetoSergio Silva
 
Apresentação Open Up
Apresentação Open UpApresentação Open Up
Apresentação Open UpLuciane2309
 
Implantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SLImplantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SLAnnkatlover
 
AGILE UNIFIED PROCESS
AGILE UNIFIED PROCESSAGILE UNIFIED PROCESS
AGILE UNIFIED PROCESSEder Nogueira
 
Aula 3 desenvolvimento de projetos
Aula 3 desenvolvimento de projetosAula 3 desenvolvimento de projetos
Aula 3 desenvolvimento de projetosThiago Cetroni
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De SoftwareCursoSENAC
 
Governança Ágil - Ágiles 2009
Governança Ágil - Ágiles 2009Governança Ágil - Ágiles 2009
Governança Ágil - Ágiles 2009Clavius Tales
 
Memória de aula_aula04_eng_software
Memória de aula_aula04_eng_softwareMemória de aula_aula04_eng_software
Memória de aula_aula04_eng_softwarerenatocinttra
 
Exercicio 1 engenharia de software.
Exercicio 1 engenharia de software.Exercicio 1 engenharia de software.
Exercicio 1 engenharia de software.Renato Breaking
 
Scrum - Introdução Interna para o Núcleo de Arquitetura de Informação
Scrum - Introdução Interna para o Núcleo de Arquitetura de InformaçãoScrum - Introdução Interna para o Núcleo de Arquitetura de Informação
Scrum - Introdução Interna para o Núcleo de Arquitetura de InformaçãoAlessandro Novais
 

Ähnlich wie Open Up – Gerenciando Projetos Sob Principios Ágeis (20)

Aula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a ObjetosAula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a Objetos
 
Fdd em uma casca de banana
Fdd em uma casca de bananaFdd em uma casca de banana
Fdd em uma casca de banana
 
Aula 1 Analise e Projeto
Aula 1   Analise e ProjetoAula 1   Analise e Projeto
Aula 1 Analise e Projeto
 
Aula 1 analise e projeto
Aula 1   analise e projetoAula 1   analise e projeto
Aula 1 analise e projeto
 
Desenvolvimento Ágil
Desenvolvimento ÁgilDesenvolvimento Ágil
Desenvolvimento Ágil
 
38484931 questionario-es
38484931 questionario-es38484931 questionario-es
38484931 questionario-es
 
Apresentação Open Up
Apresentação Open UpApresentação Open Up
Apresentação Open Up
 
Implantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SLImplantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SL
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 
Jucelir
JucelirJucelir
Jucelir
 
AGILE UNIFIED PROCESS
AGILE UNIFIED PROCESSAGILE UNIFIED PROCESS
AGILE UNIFIED PROCESS
 
Aula 3 desenvolvimento de projetos
Aula 3 desenvolvimento de projetosAula 3 desenvolvimento de projetos
Aula 3 desenvolvimento de projetos
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 
Governança Ágil - Ágiles 2009
Governança Ágil - Ágiles 2009Governança Ágil - Ágiles 2009
Governança Ágil - Ágiles 2009
 
Memória de aula_aula04_eng_software
Memória de aula_aula04_eng_softwareMemória de aula_aula04_eng_software
Memória de aula_aula04_eng_software
 
Exercicio 1 engenharia de software.
Exercicio 1 engenharia de software.Exercicio 1 engenharia de software.
Exercicio 1 engenharia de software.
 
Scrum - Introdução Interna para o Núcleo de Arquitetura de Informação
Scrum - Introdução Interna para o Núcleo de Arquitetura de InformaçãoScrum - Introdução Interna para o Núcleo de Arquitetura de Informação
Scrum - Introdução Interna para o Núcleo de Arquitetura de Informação
 
Do Zero à Produção
Do Zero à ProduçãoDo Zero à Produção
Do Zero à Produção
 
Aula2 processos sw
Aula2 processos swAula2 processos sw
Aula2 processos sw
 

Open Up – Gerenciando Projetos Sob Principios Ágeis

  • 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
  • 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
  • 18. Organização e geração das iterações
  • 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:
  • 22. O Ciclo completo do projeto
  • 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
  • 26. Redução do risco e criação constante de valor
  • 27. A relação entre os papéis e artefatos
  • 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
  • 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
  • 36. Ferramentas de apoio e referências
  • 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/