SlideShare uma empresa Scribd logo
Metodologias Ágeis em
Gerenciamento de Projetos
Daniel de Amaral




                   1
APRESENTAÇÃO




     2
Nossa agenda resumida
Aula 1                                         Aula 2
- Apresentação da disciplina                   - Overview dos métodos ágeis
- Conceituando GAP                             - Introdução ao Scrum
- Valores e princípios da filosofia Ágil       - O Framework Scrum
- Aplicação do GAP
- Framework do GAP
- Discussão em grupo sobre GAP


Aula 3                                         Aula 4
- Planejando com Scrum                         - PMBoK e os métodos ágeis
- Trabalho em grupo aplicando                  - O papel do gestor na cultura do GAP
conceitos do Scrum                             - Abordagem Ágil e os Contratos

                                                              + Detalhes no Plano
                                                              de Ensino da disciplina




                                           3
Visão do escopo
de nossos encontros
Vamos discutir sobre                         Não vamos discutir sobre

- Conceitos e principais paradigmas do       - Detalhes do Gerenciamento de
Gerenciamento de Projetos na                 Projetos “Tradicional” (foco das
abordagem Ágil.                              disciplinas PEP e GRTI)
- Princípios e Valores que norteiam os       - Práticas e técnicas utilizadas como
Métodos Ágeis e o Gerenciamento              ferramental de apoio as metodologias
Ágil de Projetos.                            ágeis (TDD, Integração Contínua, etc.)
- Visão geral do Framework Scrum.            - Detalhes de Engenharia de Software
- Práticas de gestão da abordagem            relacionados ao conteúdo de nossa
ágil.                                        disciplina.
- Papel do gestor em um ambiente de          - Softwares utilizados como
Agilidade.                                   ferramental de apoio as práticas ágeis.




                                         4
AULA 01
   5
Gerenciamento       Engenharia de
 de Projetos          Software




                6
GERENCIAMENTO
 DE PROJETOS



      7
Relembrando
O que é um Projeto?


• Esforço temporário empreendido para
  criar um produto, serviço ou resultado
  exclusivo. A sua natureza temporária
  indica um início e um término
  definidos (PMBOK, 4th edition)


                      8
Relembrando
O que é Gerenciamento de Projetos?


• Aplicação de conhecimenhtos,
  habilidades, ferramentas e técnicas
  às atividades do projeto a fim de
  atender aos seus requisitos (PMBOK, 4th edition)




                        9
Relembrando
Grupo de Processos PMBOK


                  Iniciação
                                         Planejamento




   Encerramento
                                                Execução

                         Monitoramento
                          e Controle




                                 10
Relembrando
Áreas de conhecimentos GP (PMBOK)

 Gerenciamento da   Gerenciamento do   Gerenciamento do
    Integração          Escopo              Tempo



                                        Gerenciamento
  Gerenciamento     Gerenciamento do    dos Recursos
   dos Custos          Qualidade          Humanos



  Gerenciamento
                     Gerenciamento      Gerenciamento
       das
                      dos Riscos        das Aquisições
  Comunicações


                           11
Relembrando
Nível típico de custos e pessoal
de um projeto ao longo do seu ciclo de vida




                       Fonte: PMBOK, 2008



                              12
Relembrando
Impacto da variável com base no tempo decorrido do
projeto




                      Fonte: PMBOK, 2008




                             13
PROJETOS DE SOFTWARE




         14
Projetos e ciclos de vida de
desenvolvimento de SW
• Nos projetos de tecnologia e
  desenvolvimento de software têm-se
  utilizado tradicionalmente a aplicação
  conjunta das práticas e processos do
  gerenciamento de projetos (PMBOK) com
  ciclos de vida lineares ou “Clássicos” de
  desenvolvimento de SW (ex.: Cascata /
  Waterfall).


                     15
Modelos “Clássicos” de
   desenvolvimento de Software
   • Cascata (Waterfall)
Definição dos                                                     Parênteses em defesa ao Dr.
requisitos de                                                     Royce : em seu artigo original
  Sistema
                                                                  ele já previa um ciclo iterativo
                Definição dos
                requisitos de
                                                                    entre as fases do modelo!
                  Software

                                Análise


                                              Design


                                                               Codificação


                                                                                Testes


                                          Fonte: ROYCE, 1970                                Implantação/
                                                                                             Operações


                                                 16
Modelos “Clássicos” de
                                                desenvolvimento de Software
                                                                                                                                                                                                                                                                             Custo
                                                                                                                                                                                                                                                                             Acumulado




                                                • Incremental
                                                                                                                                                                                                                                                            Progresso




                                                                                                                                                                                                                 1. Determinar objetivos,                                                                        2. Avaliar alternativas,
                                                                                                                                                                                                                 Alternativas, restrições                                                                      Identificar e atacar riscos



                                                • Espiral                                                                                                                                                                                                                                   Análise
                                                                                                                                                                                                                                                                                            dos riscos
                                                                                                                                                                                                                                                                                                       Análise
                                                                                                                                                                                                                                                                                                       dos riscos

                                                                                                                                                                                                                                                                               Análise
                                                                                                                                                                                                                                                                               dos riscos


                                                                                                                                                                                                                                                                                      Protótipo    Protótipo   Protótipo
                                                                                                                                   Incremento n                                                                  Revisão                                                                              2        Operacional
                                                                                                                                                                                                                                                                                         1

                                                                                                                                    Definição dos
                                                                                                                                                                                                                                                       Planejamento       Conceituação
Funcionalidades e Características do Software




                                                                                                                                     requisitos
                                                                               Incremento 2                                                                                                                                                            dos requisitos e                                        Design
                                                                                                                                                                                                                                                                          da operação              Design      Detalhado
                                                                                                                                                                                                                                                       Ciclo de vida
                                                                                     Definição dos                                                  Análise                                                                                                                           Requisitos
                                                                                      requisitos




                                                                                                                                       ...
                                                                                                                                                                 Design                                                                                                                                     Codificação
                                                Incremento 1                                          Análise
                                                                                                                                                                                                                                                       Plano de        Validação dos
                                                  Definição dos                                                                                                           Codificação                                                                  Desenvolvimento Requisitos
                                                   requisitos                                                       Design                                                                                                                                                        Verificação    Integração e
                                                                                                                                                                                                                                                                                  E validação    Testes
                                                                                                                                                                                        Testes                                                         Integração e
                                                                  Análise                                                      Codificação
                                                                                                                                                                                                                                                       Plano de testes                  Testes de
                                                                                                                                                                                                 Implantação/                                                                           Aceitação
                                                                            Design                                                             Testes                                             Operações


                                                                                                                                                                                                                         4. Planejar próximas fases/                       Implementação
                                                                                                                                                         Implantação/                                                                                                                              3. Desenvolvimento e Testes
                                                                                        Codificação
                                                                                                                                                          Operações
                                                                                                                                                                                                                                  iterações

                                                                                                         Testes


                                                                                                                    Implantação/
                                                                                                                     Operações


                                                                                                                                                                                                                                                 Fonte: BOEHM, 1988
                                                                                                                  Tempo decorrido do projeto


                                                                                                Fonte: PRESSMAN, 2006



                                                                                                                                                                                                                17
Modelos “Clássicos” de
desenvolvimento de Software
• Cria-se o plano de forma detalhada e todo
  o projeto é guiado através deste plano
  (“Plan-Driven Process”).
• O projeto de software é desenhado em
  todos seus detalhados antes de sua
  implementação (“Big Design Up Front”).
• Toda mudança é controlada de maneira
  formal (CCB).

                     18
Modelos “Clássicos” de
desenvolvimento de Software

• Através do rigor de planejamento busca-
  se previsibilidade e controle sobre as
  entregas a serem realizadas ao fim do
  projeto.
• Busca-se a execução através de um
  processo prescritivo.



                     19
Determinando o objetivo
• Fixa-se o plano, e todo esforço busca controlar os
  possíveis desvios...

                  Esforço para
               controlar os desvios



  Ponto
 de partida

                                           Alvo/Goal = Sucesso

       Plano
       Desvios



                                      20
Porém...
• O alvo é fixo?
  – A indústria de Software opera sob constante
    mudança (ambientes com alto grau de inovação).

   – Os processos do chamado Gerenciamento de
     Projetos “Tradicional” freqüentemente demonstram-
     se muito burocráticos e não atendem a natureza
     dinâmica do desenvolvimento de softwares.

   – Neste contexto, surge a necessidade de abordagens
     que possam facilmente responder as mudanças.


                           21
Porém...
• O alvo é fixo?
  – Natureza dos projetos de Software:
      • Software é intangível.
      • Descoberta.
      • Investigação.
      • Evolução dos requisitos ao longo do
        desenvolvimento do produto.
      • Mudança!
  – Projetos complexos acabam demandando uma
    abordagem empírica.



                        22
O alvo é fixo?
             Esforço para
          controlar os desvios



   Ponto
  de partida
                                      Alvo/Goal = Sucesso?
        Plano
        Desvios




                                           O alvo mudou, afinal,
                                        o mercado é dinâmico não?


                                 23
UMA REALIDADE
 A SE PENSAR



      24
25
26
O que define sucesso
em seus projetos?
• É apenas entregar no prazo e dentro do
  orçamento previsto?
• E quanto a satisfação do cliente?




                    27
ÁGIL




 28
Agilidade

• a.gi.li.da.de
  sf (lat agilitate)
1. Qualidade do que é ágil.
2. Desembaraço, ligeireza, presteza de
   movimentos.
3. Mobilidade, perspicácia, vivacidade.

                                    Fonte: Michaelis Online




                     29
Em nosso contexto,
o que é Agilidade?
• Habilidade de criar e responder a
  mudanças de forma a manter a
  lucratividade em um turbulento ambiente
  de negócios (HIGHSMITH, 2002)




                     30
Desenvolvimento Ágil
            Valores e
            Princípios



           Metodologias




            Práticas e
            Técnicas




                31
Breve visão histórica
          dos últimos 40 anos
          - Artigo “Managing             - “Spiral Model of




                                                                                                        2000´s
                                                                                - Dynamic Systems                - XP ganhando




                                                                      Anos 90
Anos 70




                               Anos 80
          the Development of             Software                               Development                      “momentum”.
          Large Software                 Development and                        Methodology                      - Adaptive Software
          Systems” publicado             Enhancemen” de                         (DSDM).                          Development por Jim
          por Dr. Winston W.             Barry Boehm.                           - Crystal                        Highsmith.
          Royce.                         - Publicado o livro                    Methodologies de                 - Publicação do
          - Evolutionary                 “The Mythical Man                      Alistair Cockburn.               Manifesto Ágil.
          processes por Tom              Month” de Fred                         - Primeiros passos do
          Gilb.                          Brooks.                                                                 - Metodologias e
                                                                                Scrum para projetos              práticas Ágeis
                                         - PeopleWare por                       de SW por Jeff S. e              crescendo de
                                         DeMarco and Lister.                    Ken Scwaber.                     maneira significativa
                                         - Artigo NNPDG                         - Origens do Extreme             no mercado.
                                         article de Takeuchi e                  Programming (XP)
                                         Nonaka.                                por Kent Beck.
                                         - RUP Objectory v1.0                   - Feature Driven
                                         - Publicado o                          Development por
                                         Capability Maturity                    Peter Coad e Jeff De
                                         Model (CMM) e livro                    Luca.
                                         Managing the
                                         Software Process de
                                         Watts Humphrey's.




                                                                 32
Breve visão histórica
dos últimos 40 anos

• Mesmo com todos os esforços em tornar o
  processo de desenvolvimento de sofware
  mais efetivo (RUP, etc.), a prática
  apresentava (ainda apresenta em muitos
  casos)...




                    33
• Excessso de documentação
• Lentidão de resposta as mudanças
• Distanciamento entre o que o cliente
quer (ou precisa) em relação ao que é
entregue


                 34
Processos Prescritivos vs Adaptativos
Mais                                                                                                                                                                                              Mais
prescritivos                                                                                                                                                                                      adaptativos

                               RUP (120+)                                          XP (13)                      Scrum (9)                           Kanban (3)                           Do Whatever (0)

 •   Architecture Reviewer                •   Business use case realization
 •   Business Designer                    •   Business use-case model          •   Whole team               •   Scrum Master                    •   Visualize the workflow
 •   Business-Model Reviewer              •   Business vision                  •   Coding standard          •   Product Owner                   •   Limit WIP
 •   Business-Process Analyst             •   Change request                   •   TDD                      •   Team                            •   Measure and optimize lead time
 •   Capsule Designer                     •   Configuration audit findings     •   Collective ownership     •   Sprint planning meeting
 •   Change Control Manager               •   Configuration management plan    •   Customer tests           •   Daily Scrum
 •   Code Reviewer                        •   Data model                       •   Pair programming         •   Sprint review
 •   Configuration Manager                •   Deployment model                 •   Refactoring              •   Product backlogt
 •   Course Developer                     •   Deployment plan                  •   Planning game            •   Sprint backlog
 •   Database Designer                    •   Design guidelines                •   Continuous integration   •   Burndown chart
 •   Deployment Manager                   •   Design model                     •   Simple design
 •   Design Reviewer                      •   Development case                 •   Sustainable pace
 •   Designer                             •   Development-organization         •   Metaphor
 •   Graphic Artist                           assessment                       •   Small releases
 •   Implementer                          •   End-user support mateirla
 •   Integrator                           •   Glossary
 •   Process Engineer                     •   Implementation model
 •   Project Manager                      •   Installation artifacts
 •   Project Reviewer                     •   Integration build plan
 •   Requirements Reviewer                •   Issues list
 •   Requirements Specifier               •   Iteration assessment
 •   Software Architect                   •   Iteration plan
 •   Stakeholder                          •   Manual styleguide
 •   System Administrator                 •   Programming guidelines
 •   System Analyst                       •   Quality assurance plan
 •   Technical Writer                     •   Reference architecture
 •   Test Analyst                         •   Release notes
 •
 •
 •
 •
     Test Designer
     Test Manager
     Tester
     Tool Specialist
                                          •
                                          •

                                          •
                                              Requirements attributes
                                              Requirements
                                              management plan
                                              Review record
                                                                                                                                            Comparação tem como objetivo
 •   User-Interface Designer              •   Risk list
 •
 •

 •
     Architectural analysis
     Assess Viability of architectural
     proof-of-concept
     Capsule design
                                          •
                                          •

                                          •
                                              Risk management plan
                                              Software architecture
                                              document
                                              Software development
                                                                                                                                              entendermos o contexto, não
 •
 •

 •
     Class design
     Construct architectural proof-of-
     concept
     Database design
                                          •

                                          •
                                              plan
                                              Software requirements
                                              specification
                                              Stakeholder requests
                                                                                                                                          julgarmos os processos. Não existe
 •   Describe distribution                •   Status assessment
 •
 •
 •
 •
     Describe the run-time architecture
     Design test packages and classes
     Develop design guidelines
     Develop programming guidelines
                                          •

                                          •
                                          •
                                              Supplementary business
                                              specification
                                              Supplementary specification
                                              Target organization assessment
                                                                                                                                             melhor e pior, mas sim o mais
 •
 •
 •
 •
     Identify design elements
     Identify design mechanisms
     Incorporate design elements
     Prioritize use cases
                                          •
                                          •
                                          •
                                          •
                                              Test automation architecture
                                              Test cases
                                              Test environment configuration
                                              Test evaluation summary
                                                                                                                                               adequado para diferentes
 •   Review the architecture              •   Test guidelines
 •
 •

 •
     Review the design
     Structure the implementation
     model
     Subsystem design
                                          •
                                          •
                                          •
                                          •
                                              Test ideas list
                                              Test interface specification
                                              Test plan
                                              Test suite
                                                                                                                                                     realidades...
 •   Use-case analysis                    •   Tool guidelines
 •   Use-case design                      •   Training materials
 •   Analysis model                       •   Use case model
 •   Architectural proof-of-concept       •   Use case package
 •   Bill of materials                    •   Use-case modeling guidelines
 •   Business architecture document       •   Use-case realization
 •                                        •
 •
 •
     Business case
     Business glossary
     Business modeling guidelines
                                          •
                                          •
                                              Use-case storyboard
                                              User-interface guidelines
                                              User-interface prototype
                                                                                                                                                                                Fonte: http://crisp.se/henrik.kniberg/
 •   Business object model                •   Vision
 •   Business rules                       •   Work order
 •   Business use case                    •   Workload analysis model




                                                                                                                   35
Manifesto Ágil
 Estamos descobrindo maneiras melhores de desenvolver software
 fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste
 trabalho, passamos a valorizar:

 Indivíduos e suas interações acima de processos e ferramentas
   Software funcionando acima de documentação abrangente
    Colaboração do cliente acima de negociação de contratos
     Resposta às mudanças acima da execução de um plano

 Isto é, ainda que haja valor nos itens à direita, valorizamos mais os
 itens à esquerda.



                                                       Fonte: http://agilemanifesto.org/

                                  36
12 Princípios do
   Manifesto (1/2)
                                     Acolhemos mudança de
   Nossa maior prioridade é       requisitos, inclusive em etapas Entregar software funcionando
 satisfazer os clientes através            avançadas do           frequentemente, em algumas
    de rápidas e contínuas         desenvolvimento. Processos        semanas ou meses, de
  entregas de software com        ágeis permitem mudanças que preferência no menor tempo
        valor agregado             contribuam para a vantagem                possível
                                   competitiva de seus clientes


                               Construa projetos através de
   Pessoas relacionadas à                                     O método mais eficiente e
                                indivíduos motivados. Dê à
 negócios e desenvolvedores                                 efetivo de distribuir informação
                                  equipe um ambiente que
devem trabalhar em conjunto e                                para e entre uma equipe de
                               atenda suas necessidades e
 diáriamente, durante todo o                                      desenvolvimento é a
                              confie em sua capacidade para
       curso do projeto                                        comunicação face a face
                                     realizar o trabalho


                                                                         Fonte: http://agilemanifesto.org/




                                                37
12 Princípios do
   Manifesto (2/2)
                                   Processos ágeis estimulam o
                                   desenvolvimento sustentável.
                                                                         Atenção contínua na
                                        Os patrocinadores,
Software funcional é a medida                                        excelência técnica e num bom
                                   desenvolvedores, e usuários
    primária de progresso                                              projeto/design aprimora a
                                    devem estar aptos a manter
                                                                                agilidade
                                        um ritmo constante
                                         indefinidamente


                                                                      Em intervalos regulares, a
                                      As melhores arquiteturas,       equipe reflete sobre como
    Simplicidade - a arte de
                                   requisitos e projetos (designs)    podem ser mais eficazes,
  maximizar a quantidade de
                                     emergem de equipes auto-        então sintonizam e ajustam
trabalho não feito - é essencial
                                            organizadas              seus comportamentos desta
                                                                               maneira

                                                                            Fonte: http://agilemanifesto.org/




                                                 38
Metodologias Ágeis de
Desenvolvimento de Sofware

          Extreme
Scrum Programming (XP)
                                Adaptive Software
Crystal Methods                 Development (ASD)
                        Feature Driven
Lean Development (LD) Development (FDD)
  Agile Modeling (AM)        Dynamic Systems
                        Development Method (DSDM)

                           39
Adoção dos Métodos Ágeis
pelo mercado

• Estudo recente realizado pela Forrester
  Research Inc. (~1300 profissionais de TI
  entrevistados) aponta 35% dos
  entrevistados respondendo que seu
  processo de desenvolvimento está muito
  próximo/ligado aos métodos ágeis.

                                   Fonte: InfoWorld, 2010
                                             Forrester, 2010




                     40
Empresas utilizando metódos Ágeis
(em pequena ou grande escala)
•   Google             •   Siemens
•   Yahoo!             •   Motorola
•   Adobe              •   Nokia
                       •   Eletronic Arts (EA Games)
•   HP
                       •   Departamento de Defesa
•   IBM                    Americano
•   Microsoft          •   E muitas outras (grande
•   Intel                  penetração em pequenas e
•   Cisco                  médias empresas)
•   3M
•   Nasdaq



                  41
Gerenciamento Ágil de
Projetos (GAP)
• Diante o advento das metodologias ágeis
  de desenvolvimento de software (mundo
  da engenharia de sw) o Gerenciamento de
  Projetos (mundo da gestão) é repensado
  para esta nova abordagem. Surge assim o
  chamado “Gerenciamento Ágil de
  Projetos”.


                    42
Gerenciamento Ágil de
Projetos (GAP)
• Conjunto de valores, princípios e práticas que
  auxiliam equipes de projeto a entregar produtos
  ou serviços de valor em um ambiente complexo,
  instável e desafiador Highsmith (2004)
• Nova plataforma de gerenciamento de projetos,
  aplicável a ambientes voláteis e desafiadores,
  sujeitos a mudanças freqüentes, em que o
  processo prescritivo e padronizado acaba não
  apresentando-se como a opção mais adequada
  Chin (2004)


                        43
Declaração de
Interdependencia (1/2)
Abordagens ágeis e adaptativas para conectar pessoas, projetos e
valor.
Nós somos uma comunidade de líderes de projetos que são altamente
bem-sucedidos em entregar resultados. Para alcançar esses
resultados:

Aumentamos o retorno sobre o investimento fazendo do fluxo
contínuo de valor o nosso foco.

Entregamos resultados confiáveis engajando clientes em interações
frequentes e em propriedade compartilhada.

Esperamos a incerteza e a administramos através de iterações,
antecipação e adaptação.
                                                    Fonte: http://pmdoi.org/

                               44
Declaração de
Interdependencia (2/2)
•   Libertamos a criatividade e a inovação reconhecendo que os
    indivíduos são a fonte de valor mais importante, e criando um
    ambiente no qual eles podem fazer a diferença.

•   Promovemos o desempenho através da responsabilidade do
    grupo pelos resultados e responsabilidade compartilhada pela
    efetividade da equipe.

•   Melhoramos a efetividade e confiabilidade através de
    estratégias, processos e práticas específicos para cada situação.



                                                           Fonte: http://pmdoi.org/



                                    45
Uma mudança de paradigma
Waterfall x Agile



                      Tradicional                              Ágil
Fixo                  Requisitos/Escopo            Recursos                  Cronograma




                                                              Value/Vision
                                                                 Driven
                       Plan-Driven



Variável   Recursos                   Cronograma                 Requisitos/Escopo

                                                                Fonte: Sliger & Broderick, 2008




                                          46
Processo Definido e Empírico
    Diferença das abordagens

Eu conheço todos os                              Termina
                                                 com todos        Guiado po
detalhes sobre o que                                               um plano
deve ser feito                                   os requisitos   (Plan-Driven)
(detalha-se o plano e                            entregues
requisitos)

                          Inspeção e Adaptação


Eu conheço a visão                               Termina ao
do produto/projeto                               Definir que       Empírico
                                                 os goals da     Guiado por uma
(inicia com visão geral
                                                                  visão de valor
definida e requisitos                            visão foram
de maior valor)                                  alcançados




                                        47
Framework do GAP
 Visão



                                            Plano de
                    Especulação                         Exploração
                                            Entregas



                            Ações de        Adaptação
                            Adaptação                                Funcionalidade
                                                                     Pronta
     Lista de
  Funcionalidades



                                                            Encerramento
                                  Produto
                                  Final


                                                                 Fonte: HIGHSMITH, 2004



                                             48
Visão complementar do
ciclo de vida do GAP




                  Fonte: Sliger & Broderick, 2008



             49
Princípios do GAP




           Fonte: HIGHSMITH, 2004




                    50
GP “Tradicional” e GAP
Tópico            Características GP “Tradicional”     Características GAP
                                                       Orientado por produto e centrado
Objetivo          Orientado por atividade e centrado
                                                       em pessoas.
Principal         em processo.

                  Estáveis e com baixo nível de        Projetos com mudanças constantes
Tipo de Projeto   mudanças.                            e que necessitam de respostas
                                                       rápidas.
                                                       Mais efetivo em projetos pequenos
                  Aplicável em projetos de todos os
Tamanho                                                (5-10 pessoas) – porém não existe
                  tamanhos. Mais efetivo em
                                                       restrições em ser implementado em
                  projetos de maior duração.
                                                       projetos de maior porte.
Gerente de
                  Controle total do projeto.
Projeto                                                Papel de facilitador.

Equipe de         Atuação com papéis claros e bem      Atuação colaborativa em todas as
Projeto           definidos.                           atividades do projeto.


                                                                     Fonte: ADAPTADO DE CHIN, 2004


                                               51
GP “Tradicional” e GAP
Tópico            Características GP “Tradicional” Características GAP
                  Detalhado e os envolvidos têm o    Curto e com a participação de todos
Planejamento      papel de validação, não participam os envolvidos na elaboração do
                  da elaboração do planejamento.     planejamento.
                                                       Aplicação de design simples. Evolui
Arquitetura       Definida com foco em todo o
                                                       junto com o projeto e baseia-se na
                  projeto e na reusabilidade
                                                       refatoração.
Modelo de
                  Cascata, espiral e iterativo.        Iterativo e incremental.
Desenvolvimento


Comunicação       Formal.                              Informal.


                  Processo formal de identificação e
Controle de                                            Dinâmico e com rapidez de
                  aprovação entre os envolvidos.
Mudanças                                               incorporação nas iterações.
                  Incorporação de novos requisitos
                  pode ser lento e caro.

                                                                     Fonte: ADAPTADO DE CHIN, 2004


                                             52
Aplicabilidade do GAP (segundo Chin)
                                    Múltiplas organizações        Múltiplas organizações    Um única organização
                                           externas                      internas               interessada
                                   interessadas/envolvidas        interessadas/envolvidas




 Projetos Operacionais                     Clássico                     Clássico                 Clássico



 Projetos de
 Desenvolvimento de
                                        Clássico/Ágil                 Clássico/Ágil                 Ágil
 novos produtos /
 processos

 Projetos de
 desenvolvimento de
                                        Clássico/Ágil                      Ágil                     Ágil
 novas tecnologias /
 plataformas

Clássico: Gerenciamento de Projetos “Tradicional”                                               FONTE: CHIN, 2004
Ágil: Gerenciamento Ágil de Projetos



                                                             53
AULA 02
   54
Metodologias Ágeis de
Desenvolvimento de Sofware

          Extreme
Scrum Programming (XP)
                                Adaptive Software
Crystal Methods                 Development (ASD)
                        Feature Driven
Lean Development (LD) Development (FDD)
  Agile Modeling (AM)        Dynamic Systems
                        Development Method (DSDM)

                           55
Extreme Programming – XP (1/5)

• Criado por Kent Beck, Ward Cunningham
  e Ron Jeffries a partir de suas
  experiências em um projeto piloto na
  Daimler Chrysler.




                   56
Extreme Programming – XP (2/5)

• Se baseia em valores e práticas.
• Valores:
  – Feedback
  – Comunicação
  – Simplicidade
  – Coragem



                     57
Extreme Programming – XP (3/5)

• Práticas
  – Cliente Presente
  – Jogo do Planejamento
  – Stand Up Meeting
  – Programação em Par
  – Desenvolvimento Guiado pelos Testes
  – Refactoring
  – Código Coletivo

                     58
Extreme Programming – XP (4/5)

• Práticas
  – Código Padronizado
  – Design Simples
  – Metáfora
  – Ritmo Sustentável
  – Integração Contínua
  – Releases Curtos


                     59
Extreme Programming – XP (5/5)

• Normalmente equipes XP são compostas
  pelos seguintes papéis:
   – Gerente de Projeto
   – Coach
   – Analista de Teste
   – Redator Técnico
   – Desenvolvedor


                   60
SCRUM




  61
O que é Scrum? (1/2)

• Scrum é um framework, utilizado
  para organizar times e entregar
  resultados de maneira mais produtiva
  e com alta qualidade.




                  62
O que é Scrum? (2/2)

• Fundamentado na teoria de controle
  de processos empíricos, emprega
  uma abordagem iterativa e
  incremental para otimizar a
  previsibilidade e controlar riscos.




                  63
Scrum não é...

• Uma metodologia que irá fazer
  desenvolver produtos melhores.
• Uma resposta sobre como desenvolver
  rapidamente software de qualidade.
• A solução para todos seus problemas...




                     64
Cenário de Complexidade e Scrum
    Distante de
    um acordo
                                                          Anarquia


                                             Complexo                        Cenário onde o
                                                                                 Scrum
           Requisitos


                                                                               demonstra
                                                                              maior valor
                                    Complicado




    Próximo de           Simples
     um acordo

                        Cenário            Tecnologia                 Cenário
                        Simples                                       Complexo

                                  Fonte: ADAPTADO DE SCHWABER, 2008




                                               65
Três Pilares do Scrum




 TRANSPARÊNCIA   INSPEÇÃO   ADAPTAÇÃO




                    66
Porque Scrum?

•   Aumento de ROI
•   Flexibilidade
•   Produto de Qualidade
•   Visibilidade
•   Feedback rápido e contínuo




                      67
Raízes do Scrum
• Co-criado por Jeff Sutherland e Ken Schwaber.
• Inspiração inicial a partir do artigo “The New New
  Product Development Game“ de Hirotaka Takeuchi
  e Ikujiro Nonaka, publicado em 1986 pela HBR.




                          68
Framework Scrum

• Papéis: Product Owner, ScrumMaster e Time.
• Cerimônias: Sprint Planning, Sprint Review e
  Daily Scrum.
• Artefatos: Product Backlog, Sprint Backlog e
  Burndown chart.




                       69
Papéis

• Product Owner
• ScrumMaster
• Scrum Team      Manager                                   Stakeholders...

                                 ScrumMaster




                             Product Owner
                                               Scrum Team

                                                              User
                  Customer




                     70
Porcos e Galinhas




        71
Product Owner (PO)
• Responsável pelo financiamento do
  projeto e por maximizar o retorno do
  investimeto (ROI) sob o trabalho que o
  time Scrum realiza.




                     72
Quem é o seu PO?




       73
ScrumMaster
• Responsável pelo processo Scrum. Atua como
  uma espécie de líder e facilitador, trabalha
  próximo ao PO e deve garantir que o time
  Scrum esteja operando sob máxima eficiência e
  eficácia, seguindo as regras e práticas do
  Scrum.




                       74
Time Scrum

•   Responsável pela realização do trabalho.
•   Cross-funcional.
•   Auto-organizado/auto-contido.
•   Tamanho recomendado: 5 a 9 pessoas.




                        75
Time Boxes

•   Reunião de Release Planning
•   Reunião de Sprint Planning
•   Sprint
•   Daily Scrum (ou Daily Stand-up)
•   Sprint Review
•   Reunião de Retrospectiva do Sprint



                       76
Fluxo Scrum                                                       1
                                                                         2
                                                                             Reunião de Release Planning
                                                                             Reunião de Sprint planning 1 parte
                                                                         3   Reunião de Sprint planning 2 parte
                                                                         4   Sprint
                                                                         5   Daily Scrum
                                                                         6   Sprint Review
                                                                         7   Retrospectiva do Sprint
                                                              5

                           Product Backlog
                             Selecionado


                                                              4
      Vision
Release, Milestones
                          1                                                                          Nova(s)
                                      2      3                                                  funcionalidade(s)
                                                                                             é (são) demonstrada(s)
                                                                                                 ao final de cada
                                                                                                       Sprint




                 Requisitos emergentes,
              funcionais e não funcionais    Requisitos são detalhados
              Priorizados de acordo com a    em atividades necessárias
                 Importância de negócio          para sua entrega




                                                                   77
Reunião de Release Planning

• Estabelece a meta da release e define as maiores
  prioridades do Product Backlog.
• Analisar os principais riscos.
• As características gerais e funcionalidades que estarão
  contidas na release.
• Estabelece uma data de entrega e custo prováveis.




                            78
Sprint
•   É uma iteração (não interação)
•   Time-boxed
•   Todo trabalho é realizado nos Sprints
•   Consiste no Sprint Planning, desenvolvimento do
    trabalho, Sprint Review e Restrospectiva.




                             79
Sprint – Interrupção Anormal
• Pode ser realizada caso o PO determine que não faz
  sentido terminar o trabalho iniciado.
• Este tipo de interrupção deve ser evitada sempre que
  possível.
• Começa-se um novo Sprint.




                            80
Reunião de Planejamento do
Sprint
• Momento em que planeja-se os detalhes do Sprint.
• Usualmente requer 1 dia de trabalho (8 horas).
• Divido em 2 momentos.




                           81
Daily Scrum (stand-up)

• 15 minutos (não mais)
   – O que você fizeste ontem?
   – O que irá fazer hoje?
   – Existe algum obstáculo em seu caminho?




                       82
Reunião de Revisão do Sprint

• O trabalho/funcionalidades construído durante o
  Sprint é apresentado ao Product Owner, qual
  avalia a aceitação ou não das entregas.
• Momento de inspeção e adaptação.




                        83
Retrospectiva da Sprint
• Quais foram os pontos positivos da Sprint?
• O que podemos melhorar para a próxima Sprint?
• ScrumMaster é o facilitador. Participação do PO é
  opcional. Reunião deve resultar em uma lista de
  ações a serem endereçacadas no próximo Sprint.




                           84
Artefatos

•   Product Backlog
•   Sprint Backlog
•   Release Burndown
•   Sprint Burndow




                       85
Product Backlog

• A “lista de desejos” do PO.
• Items priorizados de acordo com seu valor
  / importância de negócio.
• PO é o dono deste artefato.
• Enquanto o produto existir, o Product
  Backlog também exisitirá.



                     86
img source:




Fonte: http://epf.eclipse.org/wikis/scrum/



                   87
Sprint Backlog

• Detalha as atividades necessárias para
  transformar os itens selecionados do
  Product Backlog em um incremento do
  Sprint potencialmente entregável (pronto).




               Fonte: http://epf.eclipse.org/wikis/scrum/




                                  88
Sprint Burndown

• Demonstra o progresso da Sprint.
• Quanto do backlog de atividades
  necessárias o time já “queimou” no Sprint.




               Fonte: http://epf.eclipse.org/wikis/scrum/



                                  89
Release Burndown

• Demonstra o progresso da Release.
• Quanto do Product Backlog priorizado o
  time já entregou.
• Atualizado ao final de cada Sprint.
• Unidade de medida pode ser Story Points
  entregues em cada Sprint (não é regra).



                    90
Fonte: http://epf.eclipse.org/wikis/scrum/




                   91
Definição de Pronto (DoD)

• Scrum exige que os times desenvolvam
  um incremento de funcionalidade do
  produto a cada Sprint.
• Time deve ter uma clara definição do
  conceito de “Pronto” junto ao PO.
• O que é “Pronto” para você?




                   92
Exemplo de uma lista de “Pronto”
DoD Checklist:

• Desenvolver a funcionalidade
• Testar unitariamente
• Testar a integração com outros componentes (quando for o caso)
• Verificar se o build do projeto funciona sem erros e fazer o deploy em
uma ambiente de produção simulado
• Testar segundo os critérios de aceitação estabelecidos pelo cliente
• Depois dos testes desenvolvidos e a nova funcionalidade passando
em todos eles, avaliar a necessidade de fazer refactoring no novo
código
• Com a entrada da nova funcionalidade, avaliar a necessidade de
fazer refactoring em algum módulo do sistema
• Atualizar a documentação (quando necessário)




                                   93
Pronto




  94
Escalando Scrum

• Scrum em ordem primária funciona de maneira
  mais efetiva em times pequenos e localizados
  em um mesmo ambiente.
• Porém existem práticas para escalar Scrum a
  mais de um time, mesmo estando estes
  descentralizados (ex.: Scrum of Scrums).
• Processo de escalar Scrum deve ser planejado
  de maneira atenta aos possíveis problemas de
  distância e aumento dos canais de
  comunicação.

                       95
AULA 03
   96
VISÃO GERAL DE
PLANEJAMENTO ÁGIL
(PLANEJANDO COM SCRUM)



          97
Scrum não planeja?




        98
O que faz um
planejamento ser Ágil?
• É mais focado no processo contínuo de
  planejamento do que em um plano.
• Encoraja a mudança.
• Resulta em planos fáceis de serem
  modificados.
• É utilizado de maneira ativa durante todo o
  projeto.
                                       Fonte: COHN, 2006




                       99
Diferentes níveis de
planejamento
              Estratégico

               Portifólio

               Produto

               Release

               Iteração


                Diário

                            Fonte: COHN, 2006


                  100
Planejamento em diferentes
  níveis

Visão do Produto (longo prazo, estratégica)

                       Roadmap do Produto (release 1, release 2...)

                      Épicos                  Plano de Release (sprint 1, sprint 2...)

                                      Temas              Plano de Iteração(story. x, y...)

                                                     User
                                                    Stories           Trabalho diário
                                                                      (atividade x, y...)

                                                                 Atividades




                                              101
Product Backlog ao Sprint Backlog

Product Backlog   Product Backlog - Releases   Sprint Backlogs

                                                 Sprint 1
                  Release 1

                                                            Sprint 2
                  Release 2

                                                                   Sprint n
                  Release 3




                                      102
Plano de Release

Sprint 1              Sprint 2       Sprint 3 - 5

  História x            História a     História c   História c   História a



  História y            História b     História d   História d   História b



  História z                           História e   História e



                                       História f
    Atividade     Horas

    Atividade A   8

    Atividade B   4

    Atividade C   8

                                           103
Product Backlog




             104
Priorização do Product Backlog

               Cada iteração implementa
 Maior Valor   as funcionalidades ou estórias
 de negócio    (user stories) de maior valor


                          Novas requisições são incluídas
                          no backlog mediante priorização



                     Repriozações podem ser
                     feitas a qualquer momento


 Menor Valor              Funcionalidades/estórias
 de negócio               podem ser removidas a qualquer
                          momento



               105
Combinando Risco e Valor
para priorizar o Backlog
  Alto

                                        Faça
                     Evite
                                       primeiro
    Risco




                    Faça por           Faça em
                     último            segundo

 Baixo
            Baixo              Valor              Alto

                                                  Fonte: COHN, 2006

                                106
Product Backlog Iceberg

                                  user
                                 stories
                  Sprint




                                                        Prioridade
                                           temas
          Release




Próxima Release                                épicos




                           107
User Stories (Histórias do Usuário)

• É uma parte da funcionalidade do sistema,
  entendido pelo cliente / Product Owner,
  que representa um incremento de valor de
  negócio a ser implementado pela equipe.
• Tradicionalmente escritas em cartões.
• Meio de comunicação entre time e cliente
  sobre os requisitos a serem
  desenvolvidos.

                    108
User Stories (Histórias do Usuário)

• 3 C´s de Ron Jeffries´:
   – Cartão
   – Conversação
   – Confirmação




                      109
Como um <ator>,
eu gostaria de <ação>,
para <motivo/valor de negócio>.




              110
Como um usuário do LinkedIn,
eu quero atualizar o meu perfil
para que eu possa manter minhas
informações atualizadas.




              111
Como sistema A, eu quero
acompanhar a capacidade do
Sistema B, de modo que eu possa
emitir alertas apropriados
quando o mesmo atingir um
certo limite.


               112
Prática comum: escrever
                                           condições de satisfação
                                           da User Story atrás dos
                                           cartões como forma de
                                           estender o entendimento da
                                           funcionalidade, suas
                                           restrições, etc. junto ao cliente
Como um usuário do LinkedIn, eu
quero atualizar o meu perfil
para que eu possa manter minhas demonstrar:
                             Como
informações atualizadas.     [ ]Verifique se os campos de
                             preenchimento obrigatório estão
                             preenchidos.
                             [ ]Verifique se o usuário recebe
                             confirmação de atualização do
                             perfil.
                             [ ]Etc.


                               113
Tamanho Ideal para User Stories

• Nem tão grande que não possa ser
  específico e dividida em partes menores
  (Épicos) .
• Nem tão pequena que não seja facilmente
  entendida pelo cliente/Product Owner e
  perca seu significado de negócio
  (decomposição da User Story a um nível que
  possa confundir-se com as
  atividades/tarefas).

                     114
Uma User Story deve ser...

•   Independente
•   Negociável
•   Valiosa para o cliente/PO ou usuário
•   Estimável
•   Pequena (mantendo valor de negócio)
•   Testável



                      115
ESTIMATIVAS




     116
Estimativas

• Razões para estimar:
  – Previsão
  – Performance
  – Priorização
• Erro comum ao estimar:
  – Transformar estimativas em
    compromissos

                    117
Story Points

• Mede tamanho relativo, não tempo.
• Usualmente utiliza-se a escala Fibonacci
  (1,2,3,5,8,13,20,40,100).
• Atribuição do valor deve ser feita pelo time
  e não por uma pessoa.




                      118
Estimando Tamanho

                       GG
             G
         M
     P
PP




                 119
Tempo Ideal (Ideal Days)

• Pense em seu dia de trabalho sem
  interrupção alguma.
 Dia de trabalho (~8 horas)
 (-) Reuniões
 (-) Conversas no café
 (-) Almoço
 (-) Interrupções do colega/chefe/etc.
 (-) Leitura de notícias na web/etc.
 __________________________________
 = Ideal Day


                          120
Story Points ou Ideal Days?

• Resposta: depende da sua realidade e
  entendimento do time sobre estas
  unidades de medida.
• Comumente Ideal Days tende a ser
  melhor aceito em times que estão
  iniciando seu caminho em abordagem
  ágil.



                    121
Planning Poker (1/2)

• Técnica de estimativa que busca o consenso.
• Primeiramente descrita por James Grenning
  em 2002 e popularizada por Mike Cohn em
  seu livro Agile Planning and Estimating.
• Apesar de usualmente ser utilizada no
  processo de planejamento ágil, não trata-se
  da única técnica (utiliza-se outras como
  opinião de especialista, analogia, etc.)


                     122
Planning Poker (2/2)

             13




              13
                        13




                  123
Voltando ao Product Backlog
por 1 min...


                    8
     User Story a                          PO

                            5
            User Story b

                                       2
                        User Story c




                                124
Velocity (1/2)

• A velocidade com a qual um time consegue
  converter itens do Product Backlog em
  produto funcional.
• Um observação empírica da capacidade de
  um time completar determinado conjunto de
  trabalho por iterações.
• Em um cenário de utilização de Story Points
  refere-se a quantidade de “pontos” entregues
  ao final de uma Iteração/Sprint.

                      125
Velocity (2/2)

                 V= 8                        V= 7                          V= 9

 1       2                   2                       1       1       2
     2       3           1         3          1          2         2          1
Sprint 1                Sprint 2                    Sprint 3




                                                    Estimativa de Velocity: 7-9 pontos por
                                                    Sprint

                                                                 Fonte: http://crisp.se/henrik.kniberg/




                                       126
Estimativa / Velocity = Duração
Product Backlog
da Release = 100 story points




                                Velocidade do   Duração = 4
                                Time = 25 sp      sprints




                                         127
Gráfico Burnup

Escopo




                   Progresso




             128
Sprint Backlog




             129
Do Product Backlog ao Sprint Backlog

     Product
     Backlog                           Atividade 1
                                                              Sprint 1
                                             Atividade 2


                                       8
                   User Story a                 Atividade 3


                               5
               User Story b

                                   2
                User Story c




                        130
Task Board




         Fonte: http://epf.eclipse.org/wikis/scrum/




                           131
AULA 04
   132
BREVE CONEXÃO DO
GP “TRADICIONAL” A
 ABORDAGEM ÁGIL


        133
PMBOK e Agilidade

• O PMBOK é um grande e organizado
  compilado de conhecimentos relacionados
  a melhores práticas, técnicas e teorias de
  gestão ligadas ao gerenciamento de
  projetos.
• Não existe algo como PMBOK vs
  Gerenciamento Ágil de Projetos...



                     134
Gerenciamento da Integração
     GP “Tradicional”                           GAP
    Desenvolver o plano de            Planejamento da release
   gerenciamento do projeto                  e iterações


    Execução do Plano de
                                          Trabalho Iterativo
          Projeto


    Monitorar e controlar o             Facilitar, inspecionar,
     trabalho do projeto              adaptar, liderar, colaborar


      Realizar o controle              Feedback constante e
   integrado das mudanças               Backlog priorizado

          Não exaustivo em relação a todos processos do PMBOK

                                135
Gerenciamento do Escopo
   GP “Tradicional”                          GAP
                                    Backlog e reuniões de
     Definir o escopo
                                       planejamento


    Criar WBS (EAP)                        Criar FBS


                                   Definição dos critérios de
    Verificar o escopo             aceitação e envolvimento
                                           do cliente

                                    Feedback constante e
    Controlar o escopo
                                     Backlog priorizado

       Não exaustivo em relação a todos processos do PMBOK

                             136
Gerenciamento do Tempo
     GP “Tradicional”                          GAP

     Definir as atividades           Planejamento da Iteração


   Sequenciar as atividades          Planejamento da Iteração

                                         Membros do time
   Estimar os recursos das
                                      escolhem e estimam as
         atividades
                                            atividades
                                       Roadmap do projeto,
  Desenvolver o cronograma             planos de release e
                                            iteração
                                       Atualizar roadmap e
   Controlar o cronograma             planos de release com
                                         base na velocity
         Não exaustivo em relação a todos processos do PMBOK

                               137
Gerenciamento dos Custos
    GP “Tradicional”                           GAP

     Estimar os custos                   Plano de Release


                                          Orçamento de
   Determinar o orçamento
                                         Release/Iteração


                                        Priorizar o Product
     Controlar os custos
                                              Backlog


         Não exaustivo em relação a todos processos do PMBOK




                               138
Gerenciamento da Qualidade
    GP “Tradicional”                          GAP
                                     Critérios de Aceitação e
   Planejar a qualidade
                                       definição de pronto

                                      Qualidade como parte
   Realizar a garantia da
                                    intrínseca das atividades
         qualidade
                                             do time

                                    Definição dos critérios de
   Realizar o controle da
                                    aceitação / pronto; Testar
         qualidade
                                     cedo e frequentemente


        Não exaustivo em relação a todos processos do PMBOK




                              139
Gerenciamento dos Riscos
     GP “Tradicional”                           GAP
      Identificar os riscos;
                                       Planejamento Iterativo;
      Análise Qualitativa;
                                         Daily Stand-ups e
   Planejar as respostas aos
                                           Retrospectivas
              riscos


                                       Stand-ups e radiadores
    Monitorar e controlar os
                                      de informação altamente
            riscos
                                               visíveis



          Não exaustivo em relação a todos processos do PMBOK




                                140
CONTRATOS NA
 ABORDAGEM
    ÁGIL


     141
Contratos no contexto Ágil
• Contrato deve preocupar-se em detalhar a forma de
  interação/comunicação e trabalho entre as partes.
• Menos preditivo no que tange a definição detalhada do
  produto final (apresentar visão a qual se busca
  alcançar).
• Relação de confiança entre as partes é fundamental.
• Disponibilidade de usuários de negócio para responder
  as questões do projeto deve ser um requisito contratual.




                            142
Contratos no contexto Ágil
• Contratos do tipo preço fixo não são indicados (preço
  fixo = escopo fixo).
• Contratos do tipo Time & Material são os mais
  indicados.
• Faturamento preferencialmente alinhado com as
  iterações/sprints.
• Sign-off do cliente ao final de cada iteração ajuda no
  controle de progresso do Contrato.




                             143
GERENTE DE PROJETOS
    E O LÍDER NO
   CONTEXTO ÁGIL


         144
Papel do Gerente de Projetos
• Reconhecer que projetos ágeis irão mudar de direção
  muitas vezes durante seu curso.
• Mapear as influências externas que possam impactar
  o projeto e compartilhar de maneira adequada essa
  informação com os times.
• Atuar como um “canalizador” de informações,
  provendo informações de valor para o time de projeto.
• Manter uma visão geral do projeto para o time.




                           145
Papel do Gerente de Projetos
• Facilitar o processo de interação e comunicação entre
  as pessoas.
• Liderar o processo de adaptação através da
  manutenção das lições aprendidas, atuando nas
  ações corretivas.
• Proteger o time das distrações externas.
• Criar um ambiente seguro, qual incentiva a
  colaboração, o tomada de decisão e encoraja a
  experimentação.
• Manter um ambiente que suporta a alta produtividade.


                           146
CONSIDERAÇÕES
    FINAIS



      147
Considerações finais (1/2)
•   Lembrando: metodologias ágeis não são a solução para todos os
    problemas (identifique o cenário/contexto).
•   Mudar o modelo mental de pensar o planejamento/desenvolvimento
    de projetos de software.
•   Processo de mudança deve envolver alta diretoria (arranje o seu
    SPONSOR).
•   Lembre sempre dos valores e princípios.




                                 148
Considerações finais (2/2)
•   Scrum é simples na teoria e difícil na prática.
•   Para uma implantação bem sucedida é vital aliar as práticas ágeis
    de gestão com práticas técnicas (TDD, Refatoração, Pair
    Programming, Integração Contínua, etc.) - envolva sua equipe!
•   Mudança requer coragem e persistência.
•   Foco na melhoria contínua.




                                   149
FIM
 150
Referências citadas
•   AGILLE ALLIANCE. Manifesto for agile software development. Disponível em <http://www.agilemanifesto.org>.
•   BOEHM, B. W. A Spiral Model of Software Development and Enhancement. Computer, v.21, n.5, p.61-72,
    1988.
•   COHN, M. Agile Estimating and Planning. NJ: Prentice Hall, 2006.
•   CHIN, G. Agile Project Management: how to succeed in the face of changing project requirements. NY: Amacon,
    2004.
•   HIGHSMITH, J. Agile Software Development Ecosystems. Boston: Addison-Wesley, 2002.
•   HIGHSMITH, J. Agile Project Management: creating innovative products. Boston: Addison-Wesley, 2004.
•   PRESSMAN, R.S. Engenharia de Software. 6.ed. São Paulo: McGraw-Hill, 2006.
•   Project Management Institute – PMI. Um Guia do Conhecimento em Gerenciamento de Projetos – Guia PMBOK.
    4. ed. Pennsylvania, EUA, 2008.
•   ROYCE, W.W. Managing the development of large software systems. Proc. IEEE WESCON, Aug. 1970.
•   SCHWABER, K. Agile Project Management with Scrum. Washington: Microsoft Press, 2004.
•   SCHWABER, K. Scrum But. ScrumAlliance, 2008.
•   SLIGER, M.; BRODERICK, S. The Software Project Manager's Bridge to Agility. Boston: Addison-Wesley
    Professional, 2008.
•   TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. Harvard Business Review, p. 137-146,
    jan-fev 1986.




                                                     151

Mais conteúdo relacionado

Mais procurados

Metodologias Ágeis de Gestão de Projetos
Metodologias Ágeis de Gestão de ProjetosMetodologias Ágeis de Gestão de Projetos
Metodologias Ágeis de Gestão de Projetos
Leandro Faria
 
Gestão do Conhecimento aplicada à Gestão de Projetos
Gestão do Conhecimento aplicada à Gestão de ProjetosGestão do Conhecimento aplicada à Gestão de Projetos
Gestão do Conhecimento aplicada à Gestão de Projetos
Beatriz Benezra Dehtear, MBA
 
Aula 4 - Gestão de Projetos
Aula 4 - Gestão de ProjetosAula 4 - Gestão de Projetos
Aula 4 - Gestão de Projetos
Fernando Dantas
 
Fundamentos em Gerenciamento de Projetos PMI PR
Fundamentos em Gerenciamento de Projetos PMI PRFundamentos em Gerenciamento de Projetos PMI PR
Fundamentos em Gerenciamento de Projetos PMI PR
Rodrigo Giraldelli
 
Agile segundo o PMI
Agile segundo o PMIAgile segundo o PMI
Agile segundo o PMI
Achiles Camilo
 
Gerenciamento de Projetos
Gerenciamento de ProjetosGerenciamento de Projetos
Gerenciamento de Projetos
Marcos Abreu
 
Introdução a gerenciamento de projetos e PMBoK®
Introdução a gerenciamento de projetos e PMBoK®Introdução a gerenciamento de projetos e PMBoK®
Introdução a gerenciamento de projetos e PMBoK®
Synergia - Engenharia de Software e Sistemas
 
Gestão de Projetos
Gestão de ProjetosGestão de Projetos
Gestão de Projetos
HealthMinds Academy
 
[slides] Gestão de Projetos (2015: 2º semestre)
[slides] Gestão de Projetos (2015: 2º semestre)[slides] Gestão de Projetos (2015: 2º semestre)
[slides] Gestão de Projetos (2015: 2º semestre)
Alessandro Almeida
 
Apresentacao Pmbok
Apresentacao PmbokApresentacao Pmbok
Apresentacao Pmbok
Luiz Neto
 
Gestão de projetos
Gestão de projetosGestão de projetos
Gestão de projetos
Clayton Oliveira
 
Palestra sobre Gerenciamento de Projetos
Palestra sobre Gerenciamento de ProjetosPalestra sobre Gerenciamento de Projetos
Palestra sobre Gerenciamento de Projetos
JET e-Commerce
 
Treinamento Gestão de Projetos
Treinamento Gestão de ProjetosTreinamento Gestão de Projetos
Treinamento Gestão de Projetos
pobata
 
Pmbok
PmbokPmbok
Aula Pronta - Gerenciamento de Projetos
Aula Pronta - Gerenciamento de ProjetosAula Pronta - Gerenciamento de Projetos
Aula Pronta - Gerenciamento de Projetos
AyslanAnholon
 
Elaboração e Gestão de Projetos - 1. Fundamentos de Gestão de Projetos
Elaboração e Gestão de Projetos - 1. Fundamentos de Gestão de ProjetosElaboração e Gestão de Projetos - 1. Fundamentos de Gestão de Projetos
Elaboração e Gestão de Projetos - 1. Fundamentos de Gestão de Projetos
elonvila
 
UNIFESO 2019 - Gestão de Projetos Além do Óbvio
UNIFESO 2019 - Gestão de Projetos Além do ÓbvioUNIFESO 2019 - Gestão de Projetos Além do Óbvio
UNIFESO 2019 - Gestão de Projetos Além do Óbvio
Debora Modesto
 
Gestão de projetos
Gestão de projetosGestão de projetos
Gestão de projetos
Nativa Socioambiental
 
Estutura de gerenciamento de projetos
Estutura de gerenciamento de projetosEstutura de gerenciamento de projetos
Estutura de gerenciamento de projetos
Alaide Pitombeira de Freitas, CSM
 
Planejamento De Projetos
Planejamento De ProjetosPlanejamento De Projetos
Planejamento De Projetos
Ricardo Martins Neves
 

Mais procurados (20)

Metodologias Ágeis de Gestão de Projetos
Metodologias Ágeis de Gestão de ProjetosMetodologias Ágeis de Gestão de Projetos
Metodologias Ágeis de Gestão de Projetos
 
Gestão do Conhecimento aplicada à Gestão de Projetos
Gestão do Conhecimento aplicada à Gestão de ProjetosGestão do Conhecimento aplicada à Gestão de Projetos
Gestão do Conhecimento aplicada à Gestão de Projetos
 
Aula 4 - Gestão de Projetos
Aula 4 - Gestão de ProjetosAula 4 - Gestão de Projetos
Aula 4 - Gestão de Projetos
 
Fundamentos em Gerenciamento de Projetos PMI PR
Fundamentos em Gerenciamento de Projetos PMI PRFundamentos em Gerenciamento de Projetos PMI PR
Fundamentos em Gerenciamento de Projetos PMI PR
 
Agile segundo o PMI
Agile segundo o PMIAgile segundo o PMI
Agile segundo o PMI
 
Gerenciamento de Projetos
Gerenciamento de ProjetosGerenciamento de Projetos
Gerenciamento de Projetos
 
Introdução a gerenciamento de projetos e PMBoK®
Introdução a gerenciamento de projetos e PMBoK®Introdução a gerenciamento de projetos e PMBoK®
Introdução a gerenciamento de projetos e PMBoK®
 
Gestão de Projetos
Gestão de ProjetosGestão de Projetos
Gestão de Projetos
 
[slides] Gestão de Projetos (2015: 2º semestre)
[slides] Gestão de Projetos (2015: 2º semestre)[slides] Gestão de Projetos (2015: 2º semestre)
[slides] Gestão de Projetos (2015: 2º semestre)
 
Apresentacao Pmbok
Apresentacao PmbokApresentacao Pmbok
Apresentacao Pmbok
 
Gestão de projetos
Gestão de projetosGestão de projetos
Gestão de projetos
 
Palestra sobre Gerenciamento de Projetos
Palestra sobre Gerenciamento de ProjetosPalestra sobre Gerenciamento de Projetos
Palestra sobre Gerenciamento de Projetos
 
Treinamento Gestão de Projetos
Treinamento Gestão de ProjetosTreinamento Gestão de Projetos
Treinamento Gestão de Projetos
 
Pmbok
PmbokPmbok
Pmbok
 
Aula Pronta - Gerenciamento de Projetos
Aula Pronta - Gerenciamento de ProjetosAula Pronta - Gerenciamento de Projetos
Aula Pronta - Gerenciamento de Projetos
 
Elaboração e Gestão de Projetos - 1. Fundamentos de Gestão de Projetos
Elaboração e Gestão de Projetos - 1. Fundamentos de Gestão de ProjetosElaboração e Gestão de Projetos - 1. Fundamentos de Gestão de Projetos
Elaboração e Gestão de Projetos - 1. Fundamentos de Gestão de Projetos
 
UNIFESO 2019 - Gestão de Projetos Além do Óbvio
UNIFESO 2019 - Gestão de Projetos Além do ÓbvioUNIFESO 2019 - Gestão de Projetos Além do Óbvio
UNIFESO 2019 - Gestão de Projetos Além do Óbvio
 
Gestão de projetos
Gestão de projetosGestão de projetos
Gestão de projetos
 
Estutura de gerenciamento de projetos
Estutura de gerenciamento de projetosEstutura de gerenciamento de projetos
Estutura de gerenciamento de projetos
 
Planejamento De Projetos
Planejamento De ProjetosPlanejamento De Projetos
Planejamento De Projetos
 

Semelhante a Metodologias Ágeis em Gerenciamento de Projetos

Macrosolutions Treinamento: Gerenciamento de Escopo em Projetos
Macrosolutions Treinamento: Gerenciamento de Escopo em ProjetosMacrosolutions Treinamento: Gerenciamento de Escopo em Projetos
Macrosolutions Treinamento: Gerenciamento de Escopo em Projetos
Macrosolutions SA
 
Macrosolutions Treinamento: Análise de Valor Agregado em projetos (Earned Value)
Macrosolutions Treinamento: Análise de Valor Agregado em projetos (Earned Value)Macrosolutions Treinamento: Análise de Valor Agregado em projetos (Earned Value)
Macrosolutions Treinamento: Análise de Valor Agregado em projetos (Earned Value)
Macrosolutions SA
 
Gestão de Projetos usando Abordagem Ágil e o guia PMBOK
Gestão de Projetos usando Abordagem Ágil e o guia PMBOKGestão de Projetos usando Abordagem Ágil e o guia PMBOK
Gestão de Projetos usando Abordagem Ágil e o guia PMBOK
Icaro Dourado
 
Aula Introdução ao Gerenciamento de Projetos & MS Project
Aula Introdução ao Gerenciamento de Projetos & MS ProjectAula Introdução ao Gerenciamento de Projetos & MS Project
Aula Introdução ao Gerenciamento de Projetos & MS Project
Diego Nei, MBA, PMP®
 
Macrosolutions Treinamento: Gerenciamento de Tempo em Projetos
Macrosolutions Treinamento: Gerenciamento de Tempo em ProjetosMacrosolutions Treinamento: Gerenciamento de Tempo em Projetos
Macrosolutions Treinamento: Gerenciamento de Tempo em Projetos
Macrosolutions SA
 
Gerenciamento do escopo - Ano 2013 - PMBOK 5 edição
Gerenciamento do escopo - Ano 2013 - PMBOK 5 ediçãoGerenciamento do escopo - Ano 2013 - PMBOK 5 edição
Gerenciamento do escopo - Ano 2013 - PMBOK 5 edição
Rodrigo Lopes - Eng. - MBA - PMP - SCRUM - ITIL - COBIT
 
Macrosolutions Treinamento: Gerenciamento da Qualidade em Projetos
Macrosolutions Treinamento: Gerenciamento da Qualidade em ProjetosMacrosolutions Treinamento: Gerenciamento da Qualidade em Projetos
Macrosolutions Treinamento: Gerenciamento da Qualidade em Projetos
Macrosolutions SA
 
Fundamentos de Gerenciamento de projetos: porque os projetos falham?
Fundamentos de Gerenciamento de projetos: porque os projetos falham?Fundamentos de Gerenciamento de projetos: porque os projetos falham?
Fundamentos de Gerenciamento de projetos: porque os projetos falham?
IMED Virtual
 
Solution manager sap
Solution manager sapSolution manager sap
Solution manager sap
William Soares
 
1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP
Frank Coelho
 
1 apresentacao metodologia rcp
1  apresentacao metodologia rcp1  apresentacao metodologia rcp
1 apresentacao metodologia rcp
Frank Coelho
 
O projeto saber na magneti marelli cofap
O projeto saber na magneti marelli cofapO projeto saber na magneti marelli cofap
O projeto saber na magneti marelli cofap
Sociedade Brasileira de Gestão do Conhecimento
 
Complete Project Management
Complete Project ManagementComplete Project Management
Complete Project Management
PMO Projects Group
 
Gerenciamento De Projeto Para Slideshare
Gerenciamento De Projeto Para SlideshareGerenciamento De Projeto Para Slideshare
Gerenciamento De Projeto Para Slideshare
Leila Oliva
 
COMO SE TORNAR UM GP PMBOK 7 AINDA EM 2021
COMO SE TORNAR UM GP PMBOK 7 AINDA EM 2021COMO SE TORNAR UM GP PMBOK 7 AINDA EM 2021
COMO SE TORNAR UM GP PMBOK 7 AINDA EM 2021
Eduardo Cesar
 
Macrosolutions Treinamento: Gerenciamento de Portfólio
Macrosolutions Treinamento: Gerenciamento de PortfólioMacrosolutions Treinamento: Gerenciamento de Portfólio
Macrosolutions Treinamento: Gerenciamento de Portfólio
Macrosolutions SA
 
Projetos metodologias
Projetos   metodologiasProjetos   metodologias
Projetos metodologias
Pessoal
 
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
Facuuldade Norte Sul
 
Construção de um motel
Construção de um motelConstrução de um motel
Construção de um motel
Marco Coghi
 
Slides - Gestão de Projetos Atuliazação PMBoK 7 Edição.pdf
Slides - Gestão de Projetos Atuliazação PMBoK 7 Edição.pdfSlides - Gestão de Projetos Atuliazação PMBoK 7 Edição.pdf
Slides - Gestão de Projetos Atuliazação PMBoK 7 Edição.pdf
Jairo Garcia
 

Semelhante a Metodologias Ágeis em Gerenciamento de Projetos (20)

Macrosolutions Treinamento: Gerenciamento de Escopo em Projetos
Macrosolutions Treinamento: Gerenciamento de Escopo em ProjetosMacrosolutions Treinamento: Gerenciamento de Escopo em Projetos
Macrosolutions Treinamento: Gerenciamento de Escopo em Projetos
 
Macrosolutions Treinamento: Análise de Valor Agregado em projetos (Earned Value)
Macrosolutions Treinamento: Análise de Valor Agregado em projetos (Earned Value)Macrosolutions Treinamento: Análise de Valor Agregado em projetos (Earned Value)
Macrosolutions Treinamento: Análise de Valor Agregado em projetos (Earned Value)
 
Gestão de Projetos usando Abordagem Ágil e o guia PMBOK
Gestão de Projetos usando Abordagem Ágil e o guia PMBOKGestão de Projetos usando Abordagem Ágil e o guia PMBOK
Gestão de Projetos usando Abordagem Ágil e o guia PMBOK
 
Aula Introdução ao Gerenciamento de Projetos & MS Project
Aula Introdução ao Gerenciamento de Projetos & MS ProjectAula Introdução ao Gerenciamento de Projetos & MS Project
Aula Introdução ao Gerenciamento de Projetos & MS Project
 
Macrosolutions Treinamento: Gerenciamento de Tempo em Projetos
Macrosolutions Treinamento: Gerenciamento de Tempo em ProjetosMacrosolutions Treinamento: Gerenciamento de Tempo em Projetos
Macrosolutions Treinamento: Gerenciamento de Tempo em Projetos
 
Gerenciamento do escopo - Ano 2013 - PMBOK 5 edição
Gerenciamento do escopo - Ano 2013 - PMBOK 5 ediçãoGerenciamento do escopo - Ano 2013 - PMBOK 5 edição
Gerenciamento do escopo - Ano 2013 - PMBOK 5 edição
 
Macrosolutions Treinamento: Gerenciamento da Qualidade em Projetos
Macrosolutions Treinamento: Gerenciamento da Qualidade em ProjetosMacrosolutions Treinamento: Gerenciamento da Qualidade em Projetos
Macrosolutions Treinamento: Gerenciamento da Qualidade em Projetos
 
Fundamentos de Gerenciamento de projetos: porque os projetos falham?
Fundamentos de Gerenciamento de projetos: porque os projetos falham?Fundamentos de Gerenciamento de projetos: porque os projetos falham?
Fundamentos de Gerenciamento de projetos: porque os projetos falham?
 
Solution manager sap
Solution manager sapSolution manager sap
Solution manager sap
 
1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP
 
1 apresentacao metodologia rcp
1  apresentacao metodologia rcp1  apresentacao metodologia rcp
1 apresentacao metodologia rcp
 
O projeto saber na magneti marelli cofap
O projeto saber na magneti marelli cofapO projeto saber na magneti marelli cofap
O projeto saber na magneti marelli cofap
 
Complete Project Management
Complete Project ManagementComplete Project Management
Complete Project Management
 
Gerenciamento De Projeto Para Slideshare
Gerenciamento De Projeto Para SlideshareGerenciamento De Projeto Para Slideshare
Gerenciamento De Projeto Para Slideshare
 
COMO SE TORNAR UM GP PMBOK 7 AINDA EM 2021
COMO SE TORNAR UM GP PMBOK 7 AINDA EM 2021COMO SE TORNAR UM GP PMBOK 7 AINDA EM 2021
COMO SE TORNAR UM GP PMBOK 7 AINDA EM 2021
 
Macrosolutions Treinamento: Gerenciamento de Portfólio
Macrosolutions Treinamento: Gerenciamento de PortfólioMacrosolutions Treinamento: Gerenciamento de Portfólio
Macrosolutions Treinamento: Gerenciamento de Portfólio
 
Projetos metodologias
Projetos   metodologiasProjetos   metodologias
Projetos metodologias
 
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
 
Construção de um motel
Construção de um motelConstrução de um motel
Construção de um motel
 
Slides - Gestão de Projetos Atuliazação PMBoK 7 Edição.pdf
Slides - Gestão de Projetos Atuliazação PMBoK 7 Edição.pdfSlides - Gestão de Projetos Atuliazação PMBoK 7 Edição.pdf
Slides - Gestão de Projetos Atuliazação PMBoK 7 Edição.pdf
 

Último

Conferência Goiás I Conteúdo que vende: Estratégias para o aumento de convers...
Conferência Goiás I Conteúdo que vende: Estratégias para o aumento de convers...Conferência Goiás I Conteúdo que vende: Estratégias para o aumento de convers...
Conferência Goiás I Conteúdo que vende: Estratégias para o aumento de convers...
E-Commerce Brasil
 
Conferência Goiás I E-commerce Inteligente: o papel crucial da maturidade dig...
Conferência Goiás I E-commerce Inteligente: o papel crucial da maturidade dig...Conferência Goiás I E-commerce Inteligente: o papel crucial da maturidade dig...
Conferência Goiás I E-commerce Inteligente: o papel crucial da maturidade dig...
E-Commerce Brasil
 
Conferência Goiás I Os impactos da digitalização do Atacarejo no Brasil.
Conferência Goiás I Os impactos da digitalização do Atacarejo no Brasil.Conferência Goiás I Os impactos da digitalização do Atacarejo no Brasil.
Conferência Goiás I Os impactos da digitalização do Atacarejo no Brasil.
E-Commerce Brasil
 
aula sobre metodologia 5s, excelente opc
aula sobre metodologia 5s, excelente opcaula sobre metodologia 5s, excelente opc
aula sobre metodologia 5s, excelente opc
polianasenaces
 
Conferência Goiás I Prevenção à fraude em negócios B2B e B2C: boas práticas e...
Conferência Goiás I Prevenção à fraude em negócios B2B e B2C: boas práticas e...Conferência Goiás I Prevenção à fraude em negócios B2B e B2C: boas práticas e...
Conferência Goiás I Prevenção à fraude em negócios B2B e B2C: boas práticas e...
E-Commerce Brasil
 
Pequena apostila de contabilidade tributária.pdf
Pequena apostila de contabilidade tributária.pdfPequena apostila de contabilidade tributária.pdf
Pequena apostila de contabilidade tributária.pdf
MartesonCasteloBranc1
 

Último (6)

Conferência Goiás I Conteúdo que vende: Estratégias para o aumento de convers...
Conferência Goiás I Conteúdo que vende: Estratégias para o aumento de convers...Conferência Goiás I Conteúdo que vende: Estratégias para o aumento de convers...
Conferência Goiás I Conteúdo que vende: Estratégias para o aumento de convers...
 
Conferência Goiás I E-commerce Inteligente: o papel crucial da maturidade dig...
Conferência Goiás I E-commerce Inteligente: o papel crucial da maturidade dig...Conferência Goiás I E-commerce Inteligente: o papel crucial da maturidade dig...
Conferência Goiás I E-commerce Inteligente: o papel crucial da maturidade dig...
 
Conferência Goiás I Os impactos da digitalização do Atacarejo no Brasil.
Conferência Goiás I Os impactos da digitalização do Atacarejo no Brasil.Conferência Goiás I Os impactos da digitalização do Atacarejo no Brasil.
Conferência Goiás I Os impactos da digitalização do Atacarejo no Brasil.
 
aula sobre metodologia 5s, excelente opc
aula sobre metodologia 5s, excelente opcaula sobre metodologia 5s, excelente opc
aula sobre metodologia 5s, excelente opc
 
Conferência Goiás I Prevenção à fraude em negócios B2B e B2C: boas práticas e...
Conferência Goiás I Prevenção à fraude em negócios B2B e B2C: boas práticas e...Conferência Goiás I Prevenção à fraude em negócios B2B e B2C: boas práticas e...
Conferência Goiás I Prevenção à fraude em negócios B2B e B2C: boas práticas e...
 
Pequena apostila de contabilidade tributária.pdf
Pequena apostila de contabilidade tributária.pdfPequena apostila de contabilidade tributária.pdf
Pequena apostila de contabilidade tributária.pdf
 

Metodologias Ágeis em Gerenciamento de Projetos

  • 1. Metodologias Ágeis em Gerenciamento de Projetos Daniel de Amaral 1
  • 3. Nossa agenda resumida Aula 1 Aula 2 - Apresentação da disciplina - Overview dos métodos ágeis - Conceituando GAP - Introdução ao Scrum - Valores e princípios da filosofia Ágil - O Framework Scrum - Aplicação do GAP - Framework do GAP - Discussão em grupo sobre GAP Aula 3 Aula 4 - Planejando com Scrum - PMBoK e os métodos ágeis - Trabalho em grupo aplicando - O papel do gestor na cultura do GAP conceitos do Scrum - Abordagem Ágil e os Contratos + Detalhes no Plano de Ensino da disciplina 3
  • 4. Visão do escopo de nossos encontros Vamos discutir sobre Não vamos discutir sobre - Conceitos e principais paradigmas do - Detalhes do Gerenciamento de Gerenciamento de Projetos na Projetos “Tradicional” (foco das abordagem Ágil. disciplinas PEP e GRTI) - Princípios e Valores que norteiam os - Práticas e técnicas utilizadas como Métodos Ágeis e o Gerenciamento ferramental de apoio as metodologias Ágil de Projetos. ágeis (TDD, Integração Contínua, etc.) - Visão geral do Framework Scrum. - Detalhes de Engenharia de Software - Práticas de gestão da abordagem relacionados ao conteúdo de nossa ágil. disciplina. - Papel do gestor em um ambiente de - Softwares utilizados como Agilidade. ferramental de apoio as práticas ágeis. 4
  • 6. Gerenciamento Engenharia de de Projetos Software 6
  • 8. Relembrando O que é um Projeto? • Esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. A sua natureza temporária indica um início e um término definidos (PMBOK, 4th edition) 8
  • 9. Relembrando O que é Gerenciamento de Projetos? • Aplicação de conhecimenhtos, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos (PMBOK, 4th edition) 9
  • 10. Relembrando Grupo de Processos PMBOK Iniciação Planejamento Encerramento Execução Monitoramento e Controle 10
  • 11. Relembrando Áreas de conhecimentos GP (PMBOK) Gerenciamento da Gerenciamento do Gerenciamento do Integração Escopo Tempo Gerenciamento Gerenciamento Gerenciamento do dos Recursos dos Custos Qualidade Humanos Gerenciamento Gerenciamento Gerenciamento das dos Riscos das Aquisições Comunicações 11
  • 12. Relembrando Nível típico de custos e pessoal de um projeto ao longo do seu ciclo de vida Fonte: PMBOK, 2008 12
  • 13. Relembrando Impacto da variável com base no tempo decorrido do projeto Fonte: PMBOK, 2008 13
  • 15. Projetos e ciclos de vida de desenvolvimento de SW • Nos projetos de tecnologia e desenvolvimento de software têm-se utilizado tradicionalmente a aplicação conjunta das práticas e processos do gerenciamento de projetos (PMBOK) com ciclos de vida lineares ou “Clássicos” de desenvolvimento de SW (ex.: Cascata / Waterfall). 15
  • 16. Modelos “Clássicos” de desenvolvimento de Software • Cascata (Waterfall) Definição dos Parênteses em defesa ao Dr. requisitos de Royce : em seu artigo original Sistema ele já previa um ciclo iterativo Definição dos requisitos de entre as fases do modelo! Software Análise Design Codificação Testes Fonte: ROYCE, 1970 Implantação/ Operações 16
  • 17. Modelos “Clássicos” de desenvolvimento de Software Custo Acumulado • Incremental Progresso 1. Determinar objetivos, 2. Avaliar alternativas, Alternativas, restrições Identificar e atacar riscos • Espiral Análise dos riscos Análise dos riscos Análise dos riscos Protótipo Protótipo Protótipo Incremento n Revisão 2 Operacional 1 Definição dos Planejamento Conceituação Funcionalidades e Características do Software requisitos Incremento 2 dos requisitos e Design da operação Design Detalhado Ciclo de vida Definição dos Análise Requisitos requisitos ... Design Codificação Incremento 1 Análise Plano de Validação dos Definição dos Codificação Desenvolvimento Requisitos requisitos Design Verificação Integração e E validação Testes Testes Integração e Análise Codificação Plano de testes Testes de Implantação/ Aceitação Design Testes Operações 4. Planejar próximas fases/ Implementação Implantação/ 3. Desenvolvimento e Testes Codificação Operações iterações Testes Implantação/ Operações Fonte: BOEHM, 1988 Tempo decorrido do projeto Fonte: PRESSMAN, 2006 17
  • 18. Modelos “Clássicos” de desenvolvimento de Software • Cria-se o plano de forma detalhada e todo o projeto é guiado através deste plano (“Plan-Driven Process”). • O projeto de software é desenhado em todos seus detalhados antes de sua implementação (“Big Design Up Front”). • Toda mudança é controlada de maneira formal (CCB). 18
  • 19. Modelos “Clássicos” de desenvolvimento de Software • Através do rigor de planejamento busca- se previsibilidade e controle sobre as entregas a serem realizadas ao fim do projeto. • Busca-se a execução através de um processo prescritivo. 19
  • 20. Determinando o objetivo • Fixa-se o plano, e todo esforço busca controlar os possíveis desvios... Esforço para controlar os desvios Ponto de partida Alvo/Goal = Sucesso Plano Desvios 20
  • 21. Porém... • O alvo é fixo? – A indústria de Software opera sob constante mudança (ambientes com alto grau de inovação). – Os processos do chamado Gerenciamento de Projetos “Tradicional” freqüentemente demonstram- se muito burocráticos e não atendem a natureza dinâmica do desenvolvimento de softwares. – Neste contexto, surge a necessidade de abordagens que possam facilmente responder as mudanças. 21
  • 22. Porém... • O alvo é fixo? – Natureza dos projetos de Software: • Software é intangível. • Descoberta. • Investigação. • Evolução dos requisitos ao longo do desenvolvimento do produto. • Mudança! – Projetos complexos acabam demandando uma abordagem empírica. 22
  • 23. O alvo é fixo? Esforço para controlar os desvios Ponto de partida Alvo/Goal = Sucesso? Plano Desvios O alvo mudou, afinal, o mercado é dinâmico não? 23
  • 24. UMA REALIDADE A SE PENSAR 24
  • 25. 25
  • 26. 26
  • 27. O que define sucesso em seus projetos? • É apenas entregar no prazo e dentro do orçamento previsto? • E quanto a satisfação do cliente? 27
  • 29. Agilidade • a.gi.li.da.de sf (lat agilitate) 1. Qualidade do que é ágil. 2. Desembaraço, ligeireza, presteza de movimentos. 3. Mobilidade, perspicácia, vivacidade. Fonte: Michaelis Online 29
  • 30. Em nosso contexto, o que é Agilidade? • Habilidade de criar e responder a mudanças de forma a manter a lucratividade em um turbulento ambiente de negócios (HIGHSMITH, 2002) 30
  • 31. Desenvolvimento Ágil Valores e Princípios Metodologias Práticas e Técnicas 31
  • 32. Breve visão histórica dos últimos 40 anos - Artigo “Managing - “Spiral Model of 2000´s - Dynamic Systems - XP ganhando Anos 90 Anos 70 Anos 80 the Development of Software Development “momentum”. Large Software Development and Methodology - Adaptive Software Systems” publicado Enhancemen” de (DSDM). Development por Jim por Dr. Winston W. Barry Boehm. - Crystal Highsmith. Royce. - Publicado o livro Methodologies de - Publicação do - Evolutionary “The Mythical Man Alistair Cockburn. Manifesto Ágil. processes por Tom Month” de Fred - Primeiros passos do Gilb. Brooks. - Metodologias e Scrum para projetos práticas Ágeis - PeopleWare por de SW por Jeff S. e crescendo de DeMarco and Lister. Ken Scwaber. maneira significativa - Artigo NNPDG - Origens do Extreme no mercado. article de Takeuchi e Programming (XP) Nonaka. por Kent Beck. - RUP Objectory v1.0 - Feature Driven - Publicado o Development por Capability Maturity Peter Coad e Jeff De Model (CMM) e livro Luca. Managing the Software Process de Watts Humphrey's. 32
  • 33. Breve visão histórica dos últimos 40 anos • Mesmo com todos os esforços em tornar o processo de desenvolvimento de sofware mais efetivo (RUP, etc.), a prática apresentava (ainda apresenta em muitos casos)... 33
  • 34. • Excessso de documentação • Lentidão de resposta as mudanças • Distanciamento entre o que o cliente quer (ou precisa) em relação ao que é entregue 34
  • 35. Processos Prescritivos vs Adaptativos Mais Mais prescritivos adaptativos RUP (120+) XP (13) Scrum (9) Kanban (3) Do Whatever (0) • Architecture Reviewer • Business use case realization • Business Designer • Business use-case model • Whole team • Scrum Master • Visualize the workflow • Business-Model Reviewer • Business vision • Coding standard • Product Owner • Limit WIP • Business-Process Analyst • Change request • TDD • Team • Measure and optimize lead time • Capsule Designer • Configuration audit findings • Collective ownership • Sprint planning meeting • Change Control Manager • Configuration management plan • Customer tests • Daily Scrum • Code Reviewer • Data model • Pair programming • Sprint review • Configuration Manager • Deployment model • Refactoring • Product backlogt • Course Developer • Deployment plan • Planning game • Sprint backlog • Database Designer • Design guidelines • Continuous integration • Burndown chart • Deployment Manager • Design model • Simple design • Design Reviewer • Development case • Sustainable pace • Designer • Development-organization • Metaphor • Graphic Artist assessment • Small releases • Implementer • End-user support mateirla • Integrator • Glossary • Process Engineer • Implementation model • Project Manager • Installation artifacts • Project Reviewer • Integration build plan • Requirements Reviewer • Issues list • Requirements Specifier • Iteration assessment • Software Architect • Iteration plan • Stakeholder • Manual styleguide • System Administrator • Programming guidelines • System Analyst • Quality assurance plan • Technical Writer • Reference architecture • Test Analyst • Release notes • • • • Test Designer Test Manager Tester Tool Specialist • • • Requirements attributes Requirements management plan Review record Comparação tem como objetivo • User-Interface Designer • Risk list • • • Architectural analysis Assess Viability of architectural proof-of-concept Capsule design • • • Risk management plan Software architecture document Software development entendermos o contexto, não • • • Class design Construct architectural proof-of- concept Database design • • plan Software requirements specification Stakeholder requests julgarmos os processos. Não existe • Describe distribution • Status assessment • • • • Describe the run-time architecture Design test packages and classes Develop design guidelines Develop programming guidelines • • • Supplementary business specification Supplementary specification Target organization assessment melhor e pior, mas sim o mais • • • • Identify design elements Identify design mechanisms Incorporate design elements Prioritize use cases • • • • Test automation architecture Test cases Test environment configuration Test evaluation summary adequado para diferentes • Review the architecture • Test guidelines • • • Review the design Structure the implementation model Subsystem design • • • • Test ideas list Test interface specification Test plan Test suite realidades... • Use-case analysis • Tool guidelines • Use-case design • Training materials • Analysis model • Use case model • Architectural proof-of-concept • Use case package • Bill of materials • Use-case modeling guidelines • Business architecture document • Use-case realization • • • • Business case Business glossary Business modeling guidelines • • Use-case storyboard User-interface guidelines User-interface prototype Fonte: http://crisp.se/henrik.kniberg/ • Business object model • Vision • Business rules • Work order • Business use case • Workload analysis model 35
  • 36. Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar: Indivíduos e suas interações acima de processos e ferramentas Software funcionando acima de documentação abrangente Colaboração do cliente acima de negociação de contratos Resposta às mudanças acima da execução de um plano Isto é, ainda que haja valor nos itens à direita, valorizamos mais os itens à esquerda. Fonte: http://agilemanifesto.org/ 36
  • 37. 12 Princípios do Manifesto (1/2) Acolhemos mudança de Nossa maior prioridade é requisitos, inclusive em etapas Entregar software funcionando satisfazer os clientes através avançadas do frequentemente, em algumas de rápidas e contínuas desenvolvimento. Processos semanas ou meses, de entregas de software com ágeis permitem mudanças que preferência no menor tempo valor agregado contribuam para a vantagem possível competitiva de seus clientes Construa projetos através de Pessoas relacionadas à O método mais eficiente e indivíduos motivados. Dê à negócios e desenvolvedores efetivo de distribuir informação equipe um ambiente que devem trabalhar em conjunto e para e entre uma equipe de atenda suas necessidades e diáriamente, durante todo o desenvolvimento é a confie em sua capacidade para curso do projeto comunicação face a face realizar o trabalho Fonte: http://agilemanifesto.org/ 37
  • 38. 12 Princípios do Manifesto (2/2) Processos ágeis estimulam o desenvolvimento sustentável. Atenção contínua na Os patrocinadores, Software funcional é a medida excelência técnica e num bom desenvolvedores, e usuários primária de progresso projeto/design aprimora a devem estar aptos a manter agilidade um ritmo constante indefinidamente Em intervalos regulares, a As melhores arquiteturas, equipe reflete sobre como Simplicidade - a arte de requisitos e projetos (designs) podem ser mais eficazes, maximizar a quantidade de emergem de equipes auto- então sintonizam e ajustam trabalho não feito - é essencial organizadas seus comportamentos desta maneira Fonte: http://agilemanifesto.org/ 38
  • 39. Metodologias Ágeis de Desenvolvimento de Sofware Extreme Scrum Programming (XP) Adaptive Software Crystal Methods Development (ASD) Feature Driven Lean Development (LD) Development (FDD) Agile Modeling (AM) Dynamic Systems Development Method (DSDM) 39
  • 40. Adoção dos Métodos Ágeis pelo mercado • Estudo recente realizado pela Forrester Research Inc. (~1300 profissionais de TI entrevistados) aponta 35% dos entrevistados respondendo que seu processo de desenvolvimento está muito próximo/ligado aos métodos ágeis. Fonte: InfoWorld, 2010 Forrester, 2010 40
  • 41. Empresas utilizando metódos Ágeis (em pequena ou grande escala) • Google • Siemens • Yahoo! • Motorola • Adobe • Nokia • Eletronic Arts (EA Games) • HP • Departamento de Defesa • IBM Americano • Microsoft • E muitas outras (grande • Intel penetração em pequenas e • Cisco médias empresas) • 3M • Nasdaq 41
  • 42. Gerenciamento Ágil de Projetos (GAP) • Diante o advento das metodologias ágeis de desenvolvimento de software (mundo da engenharia de sw) o Gerenciamento de Projetos (mundo da gestão) é repensado para esta nova abordagem. Surge assim o chamado “Gerenciamento Ágil de Projetos”. 42
  • 43. Gerenciamento Ágil de Projetos (GAP) • Conjunto de valores, princípios e práticas que auxiliam equipes de projeto a entregar produtos ou serviços de valor em um ambiente complexo, instável e desafiador Highsmith (2004) • Nova plataforma de gerenciamento de projetos, aplicável a ambientes voláteis e desafiadores, sujeitos a mudanças freqüentes, em que o processo prescritivo e padronizado acaba não apresentando-se como a opção mais adequada Chin (2004) 43
  • 44. Declaração de Interdependencia (1/2) Abordagens ágeis e adaptativas para conectar pessoas, projetos e valor. Nós somos uma comunidade de líderes de projetos que são altamente bem-sucedidos em entregar resultados. Para alcançar esses resultados: Aumentamos o retorno sobre o investimento fazendo do fluxo contínuo de valor o nosso foco. Entregamos resultados confiáveis engajando clientes em interações frequentes e em propriedade compartilhada. Esperamos a incerteza e a administramos através de iterações, antecipação e adaptação. Fonte: http://pmdoi.org/ 44
  • 45. Declaração de Interdependencia (2/2) • Libertamos a criatividade e a inovação reconhecendo que os indivíduos são a fonte de valor mais importante, e criando um ambiente no qual eles podem fazer a diferença. • Promovemos o desempenho através da responsabilidade do grupo pelos resultados e responsabilidade compartilhada pela efetividade da equipe. • Melhoramos a efetividade e confiabilidade através de estratégias, processos e práticas específicos para cada situação. Fonte: http://pmdoi.org/ 45
  • 46. Uma mudança de paradigma Waterfall x Agile Tradicional Ágil Fixo Requisitos/Escopo Recursos Cronograma Value/Vision Driven Plan-Driven Variável Recursos Cronograma Requisitos/Escopo Fonte: Sliger & Broderick, 2008 46
  • 47. Processo Definido e Empírico Diferença das abordagens Eu conheço todos os Termina com todos Guiado po detalhes sobre o que um plano deve ser feito os requisitos (Plan-Driven) (detalha-se o plano e entregues requisitos) Inspeção e Adaptação Eu conheço a visão Termina ao do produto/projeto Definir que Empírico os goals da Guiado por uma (inicia com visão geral visão de valor definida e requisitos visão foram de maior valor) alcançados 47
  • 48. Framework do GAP Visão Plano de Especulação Exploração Entregas Ações de Adaptação Adaptação Funcionalidade Pronta Lista de Funcionalidades Encerramento Produto Final Fonte: HIGHSMITH, 2004 48
  • 49. Visão complementar do ciclo de vida do GAP Fonte: Sliger & Broderick, 2008 49
  • 50. Princípios do GAP Fonte: HIGHSMITH, 2004 50
  • 51. GP “Tradicional” e GAP Tópico Características GP “Tradicional” Características GAP Orientado por produto e centrado Objetivo Orientado por atividade e centrado em pessoas. Principal em processo. Estáveis e com baixo nível de Projetos com mudanças constantes Tipo de Projeto mudanças. e que necessitam de respostas rápidas. Mais efetivo em projetos pequenos Aplicável em projetos de todos os Tamanho (5-10 pessoas) – porém não existe tamanhos. Mais efetivo em restrições em ser implementado em projetos de maior duração. projetos de maior porte. Gerente de Controle total do projeto. Projeto Papel de facilitador. Equipe de Atuação com papéis claros e bem Atuação colaborativa em todas as Projeto definidos. atividades do projeto. Fonte: ADAPTADO DE CHIN, 2004 51
  • 52. GP “Tradicional” e GAP Tópico Características GP “Tradicional” Características GAP Detalhado e os envolvidos têm o Curto e com a participação de todos Planejamento papel de validação, não participam os envolvidos na elaboração do da elaboração do planejamento. planejamento. Aplicação de design simples. Evolui Arquitetura Definida com foco em todo o junto com o projeto e baseia-se na projeto e na reusabilidade refatoração. Modelo de Cascata, espiral e iterativo. Iterativo e incremental. Desenvolvimento Comunicação Formal. Informal. Processo formal de identificação e Controle de Dinâmico e com rapidez de aprovação entre os envolvidos. Mudanças incorporação nas iterações. Incorporação de novos requisitos pode ser lento e caro. Fonte: ADAPTADO DE CHIN, 2004 52
  • 53. Aplicabilidade do GAP (segundo Chin) Múltiplas organizações Múltiplas organizações Um única organização externas internas interessada interessadas/envolvidas interessadas/envolvidas Projetos Operacionais Clássico Clássico Clássico Projetos de Desenvolvimento de Clássico/Ágil Clássico/Ágil Ágil novos produtos / processos Projetos de desenvolvimento de Clássico/Ágil Ágil Ágil novas tecnologias / plataformas Clássico: Gerenciamento de Projetos “Tradicional” FONTE: CHIN, 2004 Ágil: Gerenciamento Ágil de Projetos 53
  • 54. AULA 02 54
  • 55. Metodologias Ágeis de Desenvolvimento de Sofware Extreme Scrum Programming (XP) Adaptive Software Crystal Methods Development (ASD) Feature Driven Lean Development (LD) Development (FDD) Agile Modeling (AM) Dynamic Systems Development Method (DSDM) 55
  • 56. Extreme Programming – XP (1/5) • Criado por Kent Beck, Ward Cunningham e Ron Jeffries a partir de suas experiências em um projeto piloto na Daimler Chrysler. 56
  • 57. Extreme Programming – XP (2/5) • Se baseia em valores e práticas. • Valores: – Feedback – Comunicação – Simplicidade – Coragem 57
  • 58. Extreme Programming – XP (3/5) • Práticas – Cliente Presente – Jogo do Planejamento – Stand Up Meeting – Programação em Par – Desenvolvimento Guiado pelos Testes – Refactoring – Código Coletivo 58
  • 59. Extreme Programming – XP (4/5) • Práticas – Código Padronizado – Design Simples – Metáfora – Ritmo Sustentável – Integração Contínua – Releases Curtos 59
  • 60. Extreme Programming – XP (5/5) • Normalmente equipes XP são compostas pelos seguintes papéis: – Gerente de Projeto – Coach – Analista de Teste – Redator Técnico – Desenvolvedor 60
  • 62. O que é Scrum? (1/2) • Scrum é um framework, utilizado para organizar times e entregar resultados de maneira mais produtiva e com alta qualidade. 62
  • 63. O que é Scrum? (2/2) • Fundamentado na teoria de controle de processos empíricos, emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. 63
  • 64. Scrum não é... • Uma metodologia que irá fazer desenvolver produtos melhores. • Uma resposta sobre como desenvolver rapidamente software de qualidade. • A solução para todos seus problemas... 64
  • 65. Cenário de Complexidade e Scrum Distante de um acordo Anarquia Complexo Cenário onde o Scrum Requisitos demonstra maior valor Complicado Próximo de Simples um acordo Cenário Tecnologia Cenário Simples Complexo Fonte: ADAPTADO DE SCHWABER, 2008 65
  • 66. Três Pilares do Scrum TRANSPARÊNCIA INSPEÇÃO ADAPTAÇÃO 66
  • 67. Porque Scrum? • Aumento de ROI • Flexibilidade • Produto de Qualidade • Visibilidade • Feedback rápido e contínuo 67
  • 68. Raízes do Scrum • Co-criado por Jeff Sutherland e Ken Schwaber. • Inspiração inicial a partir do artigo “The New New Product Development Game“ de Hirotaka Takeuchi e Ikujiro Nonaka, publicado em 1986 pela HBR. 68
  • 69. Framework Scrum • Papéis: Product Owner, ScrumMaster e Time. • Cerimônias: Sprint Planning, Sprint Review e Daily Scrum. • Artefatos: Product Backlog, Sprint Backlog e Burndown chart. 69
  • 70. Papéis • Product Owner • ScrumMaster • Scrum Team Manager Stakeholders... ScrumMaster Product Owner Scrum Team User Customer 70
  • 72. Product Owner (PO) • Responsável pelo financiamento do projeto e por maximizar o retorno do investimeto (ROI) sob o trabalho que o time Scrum realiza. 72
  • 73. Quem é o seu PO? 73
  • 74. ScrumMaster • Responsável pelo processo Scrum. Atua como uma espécie de líder e facilitador, trabalha próximo ao PO e deve garantir que o time Scrum esteja operando sob máxima eficiência e eficácia, seguindo as regras e práticas do Scrum. 74
  • 75. Time Scrum • Responsável pela realização do trabalho. • Cross-funcional. • Auto-organizado/auto-contido. • Tamanho recomendado: 5 a 9 pessoas. 75
  • 76. Time Boxes • Reunião de Release Planning • Reunião de Sprint Planning • Sprint • Daily Scrum (ou Daily Stand-up) • Sprint Review • Reunião de Retrospectiva do Sprint 76
  • 77. Fluxo Scrum 1 2 Reunião de Release Planning Reunião de Sprint planning 1 parte 3 Reunião de Sprint planning 2 parte 4 Sprint 5 Daily Scrum 6 Sprint Review 7 Retrospectiva do Sprint 5 Product Backlog Selecionado 4 Vision Release, Milestones 1 Nova(s) 2 3 funcionalidade(s) é (são) demonstrada(s) ao final de cada Sprint Requisitos emergentes, funcionais e não funcionais Requisitos são detalhados Priorizados de acordo com a em atividades necessárias Importância de negócio para sua entrega 77
  • 78. Reunião de Release Planning • Estabelece a meta da release e define as maiores prioridades do Product Backlog. • Analisar os principais riscos. • As características gerais e funcionalidades que estarão contidas na release. • Estabelece uma data de entrega e custo prováveis. 78
  • 79. Sprint • É uma iteração (não interação) • Time-boxed • Todo trabalho é realizado nos Sprints • Consiste no Sprint Planning, desenvolvimento do trabalho, Sprint Review e Restrospectiva. 79
  • 80. Sprint – Interrupção Anormal • Pode ser realizada caso o PO determine que não faz sentido terminar o trabalho iniciado. • Este tipo de interrupção deve ser evitada sempre que possível. • Começa-se um novo Sprint. 80
  • 81. Reunião de Planejamento do Sprint • Momento em que planeja-se os detalhes do Sprint. • Usualmente requer 1 dia de trabalho (8 horas). • Divido em 2 momentos. 81
  • 82. Daily Scrum (stand-up) • 15 minutos (não mais) – O que você fizeste ontem? – O que irá fazer hoje? – Existe algum obstáculo em seu caminho? 82
  • 83. Reunião de Revisão do Sprint • O trabalho/funcionalidades construído durante o Sprint é apresentado ao Product Owner, qual avalia a aceitação ou não das entregas. • Momento de inspeção e adaptação. 83
  • 84. Retrospectiva da Sprint • Quais foram os pontos positivos da Sprint? • O que podemos melhorar para a próxima Sprint? • ScrumMaster é o facilitador. Participação do PO é opcional. Reunião deve resultar em uma lista de ações a serem endereçacadas no próximo Sprint. 84
  • 85. Artefatos • Product Backlog • Sprint Backlog • Release Burndown • Sprint Burndow 85
  • 86. Product Backlog • A “lista de desejos” do PO. • Items priorizados de acordo com seu valor / importância de negócio. • PO é o dono deste artefato. • Enquanto o produto existir, o Product Backlog também exisitirá. 86
  • 88. Sprint Backlog • Detalha as atividades necessárias para transformar os itens selecionados do Product Backlog em um incremento do Sprint potencialmente entregável (pronto). Fonte: http://epf.eclipse.org/wikis/scrum/ 88
  • 89. Sprint Burndown • Demonstra o progresso da Sprint. • Quanto do backlog de atividades necessárias o time já “queimou” no Sprint. Fonte: http://epf.eclipse.org/wikis/scrum/ 89
  • 90. Release Burndown • Demonstra o progresso da Release. • Quanto do Product Backlog priorizado o time já entregou. • Atualizado ao final de cada Sprint. • Unidade de medida pode ser Story Points entregues em cada Sprint (não é regra). 90
  • 92. Definição de Pronto (DoD) • Scrum exige que os times desenvolvam um incremento de funcionalidade do produto a cada Sprint. • Time deve ter uma clara definição do conceito de “Pronto” junto ao PO. • O que é “Pronto” para você? 92
  • 93. Exemplo de uma lista de “Pronto” DoD Checklist: • Desenvolver a funcionalidade • Testar unitariamente • Testar a integração com outros componentes (quando for o caso) • Verificar se o build do projeto funciona sem erros e fazer o deploy em uma ambiente de produção simulado • Testar segundo os critérios de aceitação estabelecidos pelo cliente • Depois dos testes desenvolvidos e a nova funcionalidade passando em todos eles, avaliar a necessidade de fazer refactoring no novo código • Com a entrada da nova funcionalidade, avaliar a necessidade de fazer refactoring em algum módulo do sistema • Atualizar a documentação (quando necessário) 93
  • 95. Escalando Scrum • Scrum em ordem primária funciona de maneira mais efetiva em times pequenos e localizados em um mesmo ambiente. • Porém existem práticas para escalar Scrum a mais de um time, mesmo estando estes descentralizados (ex.: Scrum of Scrums). • Processo de escalar Scrum deve ser planejado de maneira atenta aos possíveis problemas de distância e aumento dos canais de comunicação. 95
  • 96. AULA 03 96
  • 97. VISÃO GERAL DE PLANEJAMENTO ÁGIL (PLANEJANDO COM SCRUM) 97
  • 99. O que faz um planejamento ser Ágil? • É mais focado no processo contínuo de planejamento do que em um plano. • Encoraja a mudança. • Resulta em planos fáceis de serem modificados. • É utilizado de maneira ativa durante todo o projeto. Fonte: COHN, 2006 99
  • 100. Diferentes níveis de planejamento Estratégico Portifólio Produto Release Iteração Diário Fonte: COHN, 2006 100
  • 101. Planejamento em diferentes níveis Visão do Produto (longo prazo, estratégica) Roadmap do Produto (release 1, release 2...) Épicos Plano de Release (sprint 1, sprint 2...) Temas Plano de Iteração(story. x, y...) User Stories Trabalho diário (atividade x, y...) Atividades 101
  • 102. Product Backlog ao Sprint Backlog Product Backlog Product Backlog - Releases Sprint Backlogs Sprint 1 Release 1 Sprint 2 Release 2 Sprint n Release 3 102
  • 103. Plano de Release Sprint 1 Sprint 2 Sprint 3 - 5 História x História a História c História c História a História y História b História d História d História b História z História e História e História f Atividade Horas Atividade A 8 Atividade B 4 Atividade C 8 103
  • 105. Priorização do Product Backlog Cada iteração implementa Maior Valor as funcionalidades ou estórias de negócio (user stories) de maior valor Novas requisições são incluídas no backlog mediante priorização Repriozações podem ser feitas a qualquer momento Menor Valor Funcionalidades/estórias de negócio podem ser removidas a qualquer momento 105
  • 106. Combinando Risco e Valor para priorizar o Backlog Alto Faça Evite primeiro Risco Faça por Faça em último segundo Baixo Baixo Valor Alto Fonte: COHN, 2006 106
  • 107. Product Backlog Iceberg user stories Sprint Prioridade temas Release Próxima Release épicos 107
  • 108. User Stories (Histórias do Usuário) • É uma parte da funcionalidade do sistema, entendido pelo cliente / Product Owner, que representa um incremento de valor de negócio a ser implementado pela equipe. • Tradicionalmente escritas em cartões. • Meio de comunicação entre time e cliente sobre os requisitos a serem desenvolvidos. 108
  • 109. User Stories (Histórias do Usuário) • 3 C´s de Ron Jeffries´: – Cartão – Conversação – Confirmação 109
  • 110. Como um <ator>, eu gostaria de <ação>, para <motivo/valor de negócio>. 110
  • 111. Como um usuário do LinkedIn, eu quero atualizar o meu perfil para que eu possa manter minhas informações atualizadas. 111
  • 112. Como sistema A, eu quero acompanhar a capacidade do Sistema B, de modo que eu possa emitir alertas apropriados quando o mesmo atingir um certo limite. 112
  • 113. Prática comum: escrever condições de satisfação da User Story atrás dos cartões como forma de estender o entendimento da funcionalidade, suas restrições, etc. junto ao cliente Como um usuário do LinkedIn, eu quero atualizar o meu perfil para que eu possa manter minhas demonstrar: Como informações atualizadas. [ ]Verifique se os campos de preenchimento obrigatório estão preenchidos. [ ]Verifique se o usuário recebe confirmação de atualização do perfil. [ ]Etc. 113
  • 114. Tamanho Ideal para User Stories • Nem tão grande que não possa ser específico e dividida em partes menores (Épicos) . • Nem tão pequena que não seja facilmente entendida pelo cliente/Product Owner e perca seu significado de negócio (decomposição da User Story a um nível que possa confundir-se com as atividades/tarefas). 114
  • 115. Uma User Story deve ser... • Independente • Negociável • Valiosa para o cliente/PO ou usuário • Estimável • Pequena (mantendo valor de negócio) • Testável 115
  • 116. ESTIMATIVAS 116
  • 117. Estimativas • Razões para estimar: – Previsão – Performance – Priorização • Erro comum ao estimar: – Transformar estimativas em compromissos 117
  • 118. Story Points • Mede tamanho relativo, não tempo. • Usualmente utiliza-se a escala Fibonacci (1,2,3,5,8,13,20,40,100). • Atribuição do valor deve ser feita pelo time e não por uma pessoa. 118
  • 119. Estimando Tamanho GG G M P PP 119
  • 120. Tempo Ideal (Ideal Days) • Pense em seu dia de trabalho sem interrupção alguma. Dia de trabalho (~8 horas) (-) Reuniões (-) Conversas no café (-) Almoço (-) Interrupções do colega/chefe/etc. (-) Leitura de notícias na web/etc. __________________________________ = Ideal Day 120
  • 121. Story Points ou Ideal Days? • Resposta: depende da sua realidade e entendimento do time sobre estas unidades de medida. • Comumente Ideal Days tende a ser melhor aceito em times que estão iniciando seu caminho em abordagem ágil. 121
  • 122. Planning Poker (1/2) • Técnica de estimativa que busca o consenso. • Primeiramente descrita por James Grenning em 2002 e popularizada por Mike Cohn em seu livro Agile Planning and Estimating. • Apesar de usualmente ser utilizada no processo de planejamento ágil, não trata-se da única técnica (utiliza-se outras como opinião de especialista, analogia, etc.) 122
  • 123. Planning Poker (2/2) 13 13 13 123
  • 124. Voltando ao Product Backlog por 1 min... 8 User Story a PO 5 User Story b 2 User Story c 124
  • 125. Velocity (1/2) • A velocidade com a qual um time consegue converter itens do Product Backlog em produto funcional. • Um observação empírica da capacidade de um time completar determinado conjunto de trabalho por iterações. • Em um cenário de utilização de Story Points refere-se a quantidade de “pontos” entregues ao final de uma Iteração/Sprint. 125
  • 126. Velocity (2/2) V= 8 V= 7 V= 9 1 2 2 1 1 2 2 3 1 3 1 2 2 1 Sprint 1 Sprint 2 Sprint 3 Estimativa de Velocity: 7-9 pontos por Sprint Fonte: http://crisp.se/henrik.kniberg/ 126
  • 127. Estimativa / Velocity = Duração Product Backlog da Release = 100 story points Velocidade do Duração = 4 Time = 25 sp sprints 127
  • 128. Gráfico Burnup Escopo Progresso 128
  • 130. Do Product Backlog ao Sprint Backlog Product Backlog Atividade 1 Sprint 1 Atividade 2 8 User Story a Atividade 3 5 User Story b 2 User Story c 130
  • 131. Task Board Fonte: http://epf.eclipse.org/wikis/scrum/ 131
  • 132. AULA 04 132
  • 133. BREVE CONEXÃO DO GP “TRADICIONAL” A ABORDAGEM ÁGIL 133
  • 134. PMBOK e Agilidade • O PMBOK é um grande e organizado compilado de conhecimentos relacionados a melhores práticas, técnicas e teorias de gestão ligadas ao gerenciamento de projetos. • Não existe algo como PMBOK vs Gerenciamento Ágil de Projetos... 134
  • 135. Gerenciamento da Integração GP “Tradicional” GAP Desenvolver o plano de Planejamento da release gerenciamento do projeto e iterações Execução do Plano de Trabalho Iterativo Projeto Monitorar e controlar o Facilitar, inspecionar, trabalho do projeto adaptar, liderar, colaborar Realizar o controle Feedback constante e integrado das mudanças Backlog priorizado Não exaustivo em relação a todos processos do PMBOK 135
  • 136. Gerenciamento do Escopo GP “Tradicional” GAP Backlog e reuniões de Definir o escopo planejamento Criar WBS (EAP) Criar FBS Definição dos critérios de Verificar o escopo aceitação e envolvimento do cliente Feedback constante e Controlar o escopo Backlog priorizado Não exaustivo em relação a todos processos do PMBOK 136
  • 137. Gerenciamento do Tempo GP “Tradicional” GAP Definir as atividades Planejamento da Iteração Sequenciar as atividades Planejamento da Iteração Membros do time Estimar os recursos das escolhem e estimam as atividades atividades Roadmap do projeto, Desenvolver o cronograma planos de release e iteração Atualizar roadmap e Controlar o cronograma planos de release com base na velocity Não exaustivo em relação a todos processos do PMBOK 137
  • 138. Gerenciamento dos Custos GP “Tradicional” GAP Estimar os custos Plano de Release Orçamento de Determinar o orçamento Release/Iteração Priorizar o Product Controlar os custos Backlog Não exaustivo em relação a todos processos do PMBOK 138
  • 139. Gerenciamento da Qualidade GP “Tradicional” GAP Critérios de Aceitação e Planejar a qualidade definição de pronto Qualidade como parte Realizar a garantia da intrínseca das atividades qualidade do time Definição dos critérios de Realizar o controle da aceitação / pronto; Testar qualidade cedo e frequentemente Não exaustivo em relação a todos processos do PMBOK 139
  • 140. Gerenciamento dos Riscos GP “Tradicional” GAP Identificar os riscos; Planejamento Iterativo; Análise Qualitativa; Daily Stand-ups e Planejar as respostas aos Retrospectivas riscos Stand-ups e radiadores Monitorar e controlar os de informação altamente riscos visíveis Não exaustivo em relação a todos processos do PMBOK 140
  • 142. Contratos no contexto Ágil • Contrato deve preocupar-se em detalhar a forma de interação/comunicação e trabalho entre as partes. • Menos preditivo no que tange a definição detalhada do produto final (apresentar visão a qual se busca alcançar). • Relação de confiança entre as partes é fundamental. • Disponibilidade de usuários de negócio para responder as questões do projeto deve ser um requisito contratual. 142
  • 143. Contratos no contexto Ágil • Contratos do tipo preço fixo não são indicados (preço fixo = escopo fixo). • Contratos do tipo Time & Material são os mais indicados. • Faturamento preferencialmente alinhado com as iterações/sprints. • Sign-off do cliente ao final de cada iteração ajuda no controle de progresso do Contrato. 143
  • 144. GERENTE DE PROJETOS E O LÍDER NO CONTEXTO ÁGIL 144
  • 145. Papel do Gerente de Projetos • Reconhecer que projetos ágeis irão mudar de direção muitas vezes durante seu curso. • Mapear as influências externas que possam impactar o projeto e compartilhar de maneira adequada essa informação com os times. • Atuar como um “canalizador” de informações, provendo informações de valor para o time de projeto. • Manter uma visão geral do projeto para o time. 145
  • 146. Papel do Gerente de Projetos • Facilitar o processo de interação e comunicação entre as pessoas. • Liderar o processo de adaptação através da manutenção das lições aprendidas, atuando nas ações corretivas. • Proteger o time das distrações externas. • Criar um ambiente seguro, qual incentiva a colaboração, o tomada de decisão e encoraja a experimentação. • Manter um ambiente que suporta a alta produtividade. 146
  • 147. CONSIDERAÇÕES FINAIS 147
  • 148. Considerações finais (1/2) • Lembrando: metodologias ágeis não são a solução para todos os problemas (identifique o cenário/contexto). • Mudar o modelo mental de pensar o planejamento/desenvolvimento de projetos de software. • Processo de mudança deve envolver alta diretoria (arranje o seu SPONSOR). • Lembre sempre dos valores e princípios. 148
  • 149. Considerações finais (2/2) • Scrum é simples na teoria e difícil na prática. • Para uma implantação bem sucedida é vital aliar as práticas ágeis de gestão com práticas técnicas (TDD, Refatoração, Pair Programming, Integração Contínua, etc.) - envolva sua equipe! • Mudança requer coragem e persistência. • Foco na melhoria contínua. 149
  • 151. Referências citadas • AGILLE ALLIANCE. Manifesto for agile software development. Disponível em <http://www.agilemanifesto.org>. • BOEHM, B. W. A Spiral Model of Software Development and Enhancement. Computer, v.21, n.5, p.61-72, 1988. • COHN, M. Agile Estimating and Planning. NJ: Prentice Hall, 2006. • CHIN, G. Agile Project Management: how to succeed in the face of changing project requirements. NY: Amacon, 2004. • HIGHSMITH, J. Agile Software Development Ecosystems. Boston: Addison-Wesley, 2002. • HIGHSMITH, J. Agile Project Management: creating innovative products. Boston: Addison-Wesley, 2004. • PRESSMAN, R.S. Engenharia de Software. 6.ed. São Paulo: McGraw-Hill, 2006. • Project Management Institute – PMI. Um Guia do Conhecimento em Gerenciamento de Projetos – Guia PMBOK. 4. ed. Pennsylvania, EUA, 2008. • ROYCE, W.W. Managing the development of large software systems. Proc. IEEE WESCON, Aug. 1970. • SCHWABER, K. Agile Project Management with Scrum. Washington: Microsoft Press, 2004. • SCHWABER, K. Scrum But. ScrumAlliance, 2008. • SLIGER, M.; BRODERICK, S. The Software Project Manager's Bridge to Agility. Boston: Addison-Wesley Professional, 2008. • TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. Harvard Business Review, p. 137-146, jan-fev 1986. 151