Métodos Ágeis de Gerência de
Métodos Ágeis de Gerência de
Software
Software
Rodrigo de Toledo
Rodrigo de Toledo
(CSM)(CSM)10 maio 2008
10 maio 2008
(Formação) (Formação)Plano
Plano
• Introdução: – Motivação – Histórico – Princípios • Scrum: – Scrum flow– Personagens, artefatos e meetings
• Prática:
– Velocity, Sprint, Review
– Aplicações, mitos e restrições
• Conclusão:
– Metodologias ágeis no mundo
• Scrum e CMMI
– Metodologias ágeis na Petrobras
Introdução
Motivação – Métodos Ágeis
Motivação – Métodos Ágeis
• Metodologias apropriadas a essa nova
ciência: a engenharia de software
• O que tem de tão interessante:
– Processos iterativos,
– people-oriented,
– Cross-functional teams,
– inspeção/adaptação,
– Alta produtividade (4 a 10 vezes maior)
– Satisfação de todos: clientes, usuários,
Motivação – Métodos Ágeis
Motivação – Métodos Ágeis
Termos
Termos
• Métodos Ágeis: se contrapõem às metodologias de engenharia
clássica, geralmente aplicados ao desenvolvimento de software. Ex: XP, Scrum, Crystal, Lean (RUP?)...
• Iteração: Etapas curtas (2 a 4 semanas) de
planejamento/desenvolvimento. O processo iterativo se contrapõem ao processo em cascata.
• Adaptação: Passa a ser a verdadeira opção à natureza imprevisível do desenvolvimento de software. Troca-se o par planejamento/controle por inspeção/adaptação.
• Self-organization: As pessoas são responsáveis pelo seu
próprio trabalho. (people-oriented x process-oriented)
• Time-box: Todas as etapas devem estar contidas no seu tempo
Motivação - Caos
Motivação - Caos
• Desenvolvimento caótico
– “Code and fix” ou “Quick and dirty”
– Um cara só faz tudo - generalista
– Imprevisível
– Pode funcionar para aplicações pequenas
– Pontos negativos:
• “Dono” do código • Baixo reuso
• Dificuldade para manutenção • ...
Motivação - Engenharia
Motivação - Engenharia
• Metodologias de engenharias
– Eng. de sw é muito nova comparada com as demais – Por que não usar outras metodologias clássicas?
• Eng. Civil, mecânica, aeronáutica ... • Planejamento Implementação • Linha de montagem
• Cada etapa tem um responsável diferente - especialistas
– Benefícios:
• Gerenciamento facilitado (pessoas são peças) • Reuso possível
• Metodologias de engenharias
– Questionamentos:
• Esforço no planejamento é muito maior que nas outras engenharias
• É previsível ?
– Desenvolvimento de sw é considerado a atividade mais complexa do ser humano.
– Pontos negativos:
• Software não é prédio • Perda de flexibilidade • Falsas verdades
Motivação - Engenharia
Motivação - Engenharia
Motivação - Engenharia
• Construir software NÃO É
igual a construir prédio
– Metáforas são perigosas (mas quase inevitáveis) – Nosso peão é um arquiteto (criativo, artista)
• Desde a primeira prova de programação • Peão feliz/infeliz (muro/igreja)
– Se derrubar uma parede errada, basta fazer um ctrl+z – Falta um tijolo no prédio falta um “ ; ” no código – Não estamos presos a leis físicas (e.g., gravidade) – Mudanças tecnológicas maiores em impacto e
Motivação - Engenharia
Motivação - Engenharia
• Perda de Flexibilidade
– Mudanças externas constantes
• Decorrentes da imprecisão dos requisitos
– Falha de quem está levantando
– Incapacidade do cliente em detalhar
(ex: construção customizada de um carro)
Frase comum: “o problema deste projeto é que os requisitos vivem mudando”
Motivação - Engenharia
Motivação - Engenharia
• Perda de Flexibilidade (Jeff Sutherland et al. 08)
– Ziv’s Uncertainty Principle:
Uncertainty is inherent and inevitable in software development processes and products
– Humphrey’s Requirements Uncertainty Principle:
For a new software system the requirements will not be completely known until after the users have used it.
– Wegner’s Lemma:
Motivação - Engenharia
Motivação - Engenharia
• Mitos sobre as metodologias de engenharia:
– Esforço maior apenas no início do projeto – Pessoas são apenas peças do processo – Quanto mais informação escrita melhor – Previsibilidade
• Processos criativos não são fáceis de planejar
((A engenharia de software é ao mesmo tempo uma ciência precisa/matemática e um exercício criativo/humano))
• Pior ainda: Fingir que é previsível
– Documentos que não são lidos
– Documentos para descrever como algo será feito escritos depois desse algo feito
– Fim do projeto! Bom projeto tem fim ? – O que é um produto de sucesso ?
• No prazo, no custo e de acordo com o plano
Maior Business Value Não
Video
Histórico – Métodos Ágeis
Histórico – Métodos Ágeis
• Anos 80 (qualidade)
– Nonaka e Takeuchi:
• Toyota, Xerox, 3M, Fujifilm ... • “Knowledge Management”
• Papers: “The New New Product Development Game”, 1986 “The knowledge-creating company”
– Algumas histórias ou lendas:
• Força tarefa japonesa
• Grupo de consultoria (Toyota consulting)
• Qualidade começou anos 70 com americano
– SmallTalk (Xerox, 1980)
• OO, metaclasses, dev. environment, virtual machine (1983), unit test
Histórico – Métodos Ágeis
Histórico – Métodos Ágeis
• Anos 90 (Eng.Sw.)
– XP (Kent Beck e Ron Jeffries, ~97)
• 5 valores, 14 princípios, 24 práticas • Outra lenda:
Kent Beck desafia QA’s (GQS) em 2001 • TDD
– Scrum (Jeff Sutherland, Ken Schwaber, Mike
Beedle 93~95~99)
• Mais gerencial que XP
– Crystal (Alistair Cockburn)
• Coleção de métodos • Mais flexível que XP
Histórico – Métodos Ágeis
Histórico – Métodos Ágeis
• Anos 2000
– Grande divulgação
– Diversos exemplos de uso
• 2001
– Agile Manifesto
– Agile Alliance
• Últimos anos
– Google, Yahoo, Borland, Sega (todas as
grandes empresas de jogos), MS …
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Kent Beck Mike Beedle Arie van Bennekum
Alistair Cockburn Ward Cunningham
Principles behind the Agile Manifesto
Principles behind the Agile Manifesto
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility. • Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Video
Video
About SCRUM
About SCRUM
Product Owner Scrum Master Done Visibility Retrospectives Planning POKER Stand-up Meeting Sprint Product Backlog Selected Backlog Sprint Backlog Team Burn-down Chart Story Points Time Box Task BoardSCRUM
Scrum
Scrum
• Metaprocesso (framework)
– “Metodologia que diz que metodologias não são tão importantes”
• Adaptável
– 1ª regra: as regras podem ser alteradas*
• Promete alta qualidade
– software robusto
• Promete alta produtividade
– 4 a 10 vezes mais produtivo
– Mais “business value” ou valor agregado * Existem algumas pré-condições
Scrum – Primeiros Conceitos
Scrum – Primeiros Conceitos
• Sprint:
– iteração
– período de 2 a 4 semanas de trabalho da equipe
• Daily sprint:
– 1 dia de trabalho da equipe
• Product backlog:
– Lista de requisitos em formato user-story – Ordenada por prioridade
• Selected backlog:
– Lista de tarefas a serem realizadas durante a sprint – Baseada nas maiores prioridades do product backlog – De acordo com a capacidade da equipe em uma
Scrum
Scrum - Personagens
Scrum - Personagens
Scrum - Personagens
• Apenas três
• Não tem relação direta com cargos e
hierarquias
Scrum Master Product Owner
Scrum - Personagens
Scrum - Personagens
• Product Owner
– Fornece a visão do negócio
– Mantém os itens do product backlog
atualizados e priorizados
– A cada início de sprint auxilia a elaborar o
selected backlog
– Maximiza ROI ("valor agregado")
– Aceita ou rejeita o que foi produzido
– Alta participação em início e fim de sprints
– Disponível para esclarecer dúvidas
Scrum - Personagens
Scrum - Personagens
• Scrum Master
– Facilitador
– Não tem autoridade
– Conduz reuniões e eventos
– Mantém o Scrum funcionando
– Remove empecilhos e obstáculos
– Presta serviço ao time
– Protege o time
– Ajuda o time nas suas tarefas
Scrum - Personagens
Scrum - Personagens
• Time
– Multidisciplinar
• sem papéis específicos
– Auto-gerenciado
– de 5 a 9 pessoas
– Comprometido com o objetivo e consigo mesmo
• esforçado, pontual etc.
– Autoridade para fazer o que for necessário para
atingir o objetivo
– Comunicação constante
Scrum - Comprometimento
Scrum - Comprometimento
• Comprometimento x Envolvimento
• Porcos e galinhas
Scrum - Princípios
Scrum - Princípios
Scrum - Princípios
Processo iterativo e incremental (1/6)
• Modelo Tradicional
• Modelo Ágil
Scrum - Princípios
Scrum - Princípios
Processo iterativo e incremental (1/6)
• Benefícios:
– confiabilidade do software
– antecipação de valor agregado
– aumento de confiança do cliente
– motivação do time
Manifesto Ágil: devemos valorizar mais SOFTWARE FUNCIONAIS do que documentações extensas.
Scrum - Princípios
Scrum - Princípios
Auto-organização (2/6)
• Acreditar na competência das pessoas
• O time tem capacidade de se
auto-organizar
• Tarefas não devem ser atribuídas
autoritariamente, mas voluntariamente
– pull tasks, not push
• atribuições ocorrem diariamente
Scrum - Princípios
Scrum - Princípios
Comunicação (transparência) (3/6)
• Através de reuniões diárias a comunicação é
feita pessoalmente
• Controles visuais
• Reuniões regulares de retrospectiva
– A cada mudança de sprint – Verificação de obstáculos – Melhora contínua
• Problemas vêem rapidamente a superfície
• group programming (collective code ownership)
– Resultado das atribuições diárias e
Scrum - Princípios
Scrum - Princípios
Time-box (4/6)
• O tempo da sprint é mandatório
(assim como qualidade)
• Todos os meetings
tem tempo fixo:
– Daily-meeting – Sprint Planning – Etc... Qualidade Tempo Escopo Fixos custo/esforço Único que pode alterar
Scrum - Princípios
Scrum - Princípios
Menos planejamento, mais ação (5/6)
• Retardar decisões
– Por causa da complexidade – Não há conflito com:
• "não deixe para amanhã o que pode ser feito hoje" • Um é ação e outro é planejamento
– Retardar uma decisão e retomá-la apenas no momento apropriado:
• cenário mais atualizado • novas prioridades
• mais conhecimento sobre as condições
Manifesto Ágil: devemos valorizar mais REAGIR A MUDANÇAS do que seguir um plano.
Scrum - Princípios
Scrum - Princípios
Menos planejamento, mais ação (5/6)
• Mais código e menos documentação prévia
• Planejamento Fibonacci (1,1,2,3,5,8,13,21...)
– Escala progressiva
– Detalhes do planejamento devem ser inversamente proporcionais à distância no tempo
– Scrum tem 3 escalas: projeto, sprint, dia
• Não discutir muito o processo:
– Tentar primeiro e melhorar para a próxima sprint
Manifesto Ágil: devemos valorizar mais SOFTWARE FUNCIONAIS do que documentações extensas. REPETINDO
Scrum - Princípios
Scrum - Princípios
Cliente é um parceiro (6/6)
• Participação ao longo do projeto
• Acompanhamento mensal
• Disponibilidade para dúvidas
• Mudanças de requisitos são bem-vindas a
qualquer momento
Manifesto Ágil: devemos valorizar mais COLABORAÇÃO COM O
Scrum Phases
Scrum Phases
• Diferença entre
estratégia e tática
• Já vimos:
– Product Backlog – Selected Backlog• Falta vermos:
– User story – Story point– Task e Sprint Backlog – Task Board
Scrum
Scrum
Flow
Scrum - Artefatos
Scrum – Artefatos
Scrum – Artefatos
• User Story (backlog items)
– Product e Selected Backlogs são compostos por user stories. – Campos:
• ID, Título (ou descrição sucinta) • Valor
– Valor medido pelo product owner (business value)
– Não precisa ter valores absolutos, podem ser relativos
• Story points
• Descrição mais detalhada
– Suficiente para compreensão de time
– Pode ser uma descrição da interação com o usuário ou uma prévia da lista de tarefas
– Outros possíveis campos:
• “Me <name>, as <user role>, would like to <feature>, so that <value>” • Sprint number
Scrum – Artefatos
Scrum – Artefatos
• Story Points
– Medida de esforço de implementação
– Associado a cada story
– Valores concretos ou relativos?
• Pode ser associado a uma referência concreta
– ex: Homem-dia de trabalho
• Pode ser simplesmente um valor relativo
– Ex: Escolhe-se a story mais simples e pontua com valor 2
– Usa-se uma série adaptada de Fibonacci:
1, 2, 3, 5, 8, 13, 20, 40 e 100
Scrum – Artefatos
Scrum – Artefatos
• Tasks
– Cada story deverá ser quebrada em tarefas
– Idealmente, tarefas correspondem a 1 dia de trabalho – São a menor unidade de divisão
– Cada tarefa vira um Post-it
– As atribuições das tarefas às pessoas ocorre diariamente
• Sprint Backlog
– Conjunto de tasks de cada uma das stories da sprint corrente
Scrum – Artefatos
Scrum – Artefatos
Scrum – Artefatos
Scrum – Artefatos
• Task Board
– To do, doing, done – Conceito de DONE
– Pode ter outras colunas, exemplos:
• commited • reviewed – Burn-down chart – Outros conteúdos: • Post-it chart • Limbo • Impediments • Notícias – Mesa retrátil
Scrum – Artefatos
Scrum – Artefatos
• Burn-down Chart
– São dois:
• Por sprint • Produto completo– Contagem de pontos
• Pontos parciais das stories • Total de pontos da story
Scrum - Meetings
Scrum - Meetings
Scrum - Meetings
• São 6 diferentes meetings
MEETINGS
Sprint i Sprint i +1 ...
...
Review Retrospecitve
Daily meetings Daily meetings
Sprint Planning 2 Sprint Planning 1 Estimation Estimation
Scrum - Meetings
Scrum - Meetings
• Sprint Planning 1
– Material:
• Product backlog atualizado, priorizado e estimado. • Informações práticas sobre próximo sprint
• pessoas, tempo de sprint etc.
– Envolvidos: Product owner + time + scrum master – Objetivo: Definir sprint backlog
– Procedimento:
• sprint backlog é preenchido com os itens de maior prioridade do product backlog até completar o número de story points correspondente a velocity do time.
• O product owner poderá então propor alterações para incluir, excluir e alterar o escopo das stories.
Scrum - Meetings
Scrum - Meetings
• Sprint Planning 2 – Material:
• Sprint backlog priorizado e detalhes do sprint (incluindo o objetivo).
• Informações práticas sobre próximo sprint (pessoas, tempo de sprint etc.).
– Envolvidos: Time + scrum master (+ product owner) – Objetivo: Definir tarefas de cada story do sprint. – Procedimento:
• Divisão das stories em tarefas de 1 dia, criando post-its para a coluna to do do VRSIVIEP:painel de tarefas.
• Lembrar que as tarefas devem incluir:
• Aprendizado de tecnologia desconhecida • Programação
• Teste
• Code review • Documentação
Scrum - Meetings
Scrum - Meetings
• Planning Poker ou Estimation meeting – Envolvidos: time
– Material: cartas do planning poker com os valores: 1 2 3 5 8 13 20 40 100 200.
– Procedimento:
1. Identificar no product backlog o item que o time julga ser o de menor esforço e pontuamos como 2.
2. A partir do product backlog fazemos um "pre-selected" backlog com os itens mais urgentes na visão do prod. owner, ou seja, Luciano+Ismael.
Para cada item:
4. Lemos a story relativa ao item e verificamos se não há desentendimento. 5. Fazemos uma rodada de PP entre os membros do time.
6. Os membros que tiverem dado menor e maior valores fazem uma breve defesa do porque.
Repetimos itens 4 e 5 até convergir
8. O valor é associado ao item, você pode verificar naquele arquivo sprint1.txt que passei para você os valores atribuídos aos 9 itens do sprint1.
– Freqüência:
Scrum - Meetings
Scrum - Meetings
• Daily meetings ou Satand-up meetings ou Scrum meetings – Envolvidos: time.– Material: Painel de tarefas; post-it; canetas. – Procedimento:
• De pé, máximo de 15 minutos, não é para discutir/resolver problemas • 3 perguntas atualizando o Task Board:
• o que eu fiz ontem? • o que farei hoje?
• tenho algum empecilho? • Sincronização de conhecimento • atualização do burn-down
Scrum - Meetings
Scrum - Meetings
O que eu fiz ontem?
1
O que vou fazer hoje?
2
Tenho algum obstáculo?
3
Scrum - Meetings
Scrum - Meetings
• Retrospective
– Material:
• informações do VRSIVIEP:painel de tarefas já organizados. • post-its e flip-chart
– Envolvidos:
• Time, scrum master (+ product owner)
– Objetivo:
• Rediscutir o processo de desenvolvimento (visando sua melhora)
– Procedimento:
• Repassar a sprint cronologicamente
• 5 min de WWWs (What Went Well & What Went Wrong) em post-it • Discutir os itens organizando o impediment backlog
– who is in control?.
• Fechamento: cada individuo faz sua conclusão
(Se a retrospective for anterior a review, pode-se preparar a review com o time.)
Scrum - Meetings
Scrum - Meetings
• Review
– Material:
• informações do painel de tarefas
– Envolvidos:
• time + scrum master + product owner
– Objetivo:
• Revisar último sprint e andamento global do projeto
– Procedimento:
• Revisar detalhes da última sprint: objetivo, stories, burndown chart etc. • Demo do último incremento do projeto.
• Pode incluir a demonstração de documentos e outros.
(Se a review for posterior a retrospective, pode-se discutir impediments)
– Freqüência:
Scrum
Scrum
Flow
Ainda sobre SCRUM
Ainda sobre SCRUM
• Sprint, um resumo
• Done, Velocity
• Infraestrutura
• Escalabilidade
• Aprendizado
• Exemplo Prático
Scrum - Sprint
Scrum - Sprint
• Sprint, um resumo
– Iteração de 2 a 4 semanas
– Termina com uma deployable version
– Não pode ter sua data postergada
• O que fazer se atrasar ?
– A descrição da sprint deve conter:
• Data início e fim
• Pessoas envolvidas (time) • Objetivo
• Total de pontos • Sprint backlog
Gráfico de Baleia
Gráfico de Baleia
Ao invés de completar uma coisa por vez...
... equipes Scrum fazem um pouco de cada coisa, todo o tempo.
Scrum - DONE
Scrum - DONE
Design
Codificação
Unit-test
Code review
Refactoring
Comentado
Commited
Documentado
Scrum - Velocity
Scrum - Velocity
• Velocity
Jogo das bolas
Jogo das bolas
• Um único time
• As bolas devem passar por todos
• Bolas devem ser passadas ficando um tempo no ar • Não podem ser passadas ao vizinho
• Mesmo ponto de início e fim • 2 minutos por sprint
• 1 minuto para retrospectiva/review • 5 iterações
Scrum – Suporte Tecnológico
Scrum – Suporte Tecnológico
• Teste Unitário
– J-Unit – Cpp-Unit – NUnit• Integração Contínua
– Hudson – Scons• Wiki (Visibilidade)
– Confluence• Subversion
– TortoiseSVN• Acompanhamento de issues
– JiraEscalabilidade
Escalabilidade
• Times de 7
±
2 pessoas
• Pode ser escalável
• Scrum of Scrum
– Ken Schwaber
• Diversas vezes implementou para centenas de desenvolvedores
– Mike Cohn
• Implementou para mais de 1000
• Faz uso genérico do Scrum (além de des. de sw) • Próximo objetivo: + de 10.000 pessoas
Scrum of Scrum
Scrum of Scrum
Scrum - Relatórios
Scrum - Relatórios
• Product backlog a cada sprint
– Análise das diferenças
• Análise de desempenho
– Burn-down charts, velocity …
Scrum - Aprendizado
Scrum - Aprendizado
• Group programming
– Especialistas compartilham sua experiência
• Retrospective
– Todos aprendem sobre o processo e como
melhorá-lo
– Essa é a explicação de porque os métodos
ágeis se tornaram tão bons
Exemplo Prático - SiVIEP
Exemplo Prático - SiVIEP
• Sistema de Visualização Integrado de E&P • Alta complexidade de requisitos:
– Multi-plataforma – Realidade Virtual
• Renderização distribuída
• Interação com dispositivos 3D
– Suporte a grafo de cena – Som 3D
– Cluster – Distribuído
– Arquitetura de componentes – Plug-in
– Acesso as funcionalidades via script – Open source
– Plataforma de desenvolvimento para outras universidades – Browser 3D
• Um pouco mais de ano de projeto antes
do Scrum
• 5-6 pessoas
• ±10 sprints realizadas
Exemplo Prático - SiVIEP
Poços
Plataforma (PNA-I) Plataforma (PNA-II)
Reservatório
• Adaptações do Scrum no SiVIEP:
– 3 dias úteis de trabalho por semana
– Estimation meeting acontece em conjunto
com sprint planning 1
– Limbo + Prod. Backlog candidates
– mesa retrátil
– Post-it chart (cor diferente para post-it novo)
– Inversão entre retrospective e review
Exemplo Prático - SiVIEP
Meetings Sprint i Sprint i +1 ... ... Review Retrospecitve
Daily meetings Daily meetings
Sprint Planning 2 Sprint Planning 1 Estimation Estimation 1 day 1 day Meetings Sprint i Sprint i +1 ... ... Review Retrospecitve
Daily meetings Daily meetings
Sprint Planning 2 Sprint Planning 1 PROCESSO SIVIEP 1 day Estimation •Pontos positivos: •Participação do Prod. Owner em 1 único dia •Apenas 1 dia sem produção •Pontos negativos: - retrospective antes da review - Estimation na frente do prod. Owner PROCESSO CONVENCIONAL
Exemplo Prático – V3O2
Exemplo Prático – V3O2
• E&P
• Projeto antigo com diversos usuários
• ± 8 sprints realizadas
Tópicos para discussão
Tópicos para discussão
• Pontos negativos
• CMMI
Pontos negativos dos Métodos Ágeis
Pontos negativos dos Métodos Ágeis
• Para times com pessoas experientes
– Ken Schwaber diz que funciona para idiotas
• Processo exigente, trabalha-se muito
– Google compensa com o esquema 80-20
• Perda de flexibilidade no horário
• Como tratar especialistas em equipes
multidisciplinares?
• Como fazer o contrato (preço e escopo)?
• Como auditar e certificar?
Atenção! Cuidado com os falsos mitos negativos:
– Só serve para grupos pequenos (FALSO) – Não gera documentação (FALSO)
Contratos
Contratos
• Fixed price / fixed date or
Latest date / maximum cost
• Já existem diversos modelos de contrato
prontos
Scrum & CMM
Scrum & CMM
• Level 2:
– Christ Vriens, “Certifying for CMM Level 2 and ISO9001 with XP@Scrum”, May 2002
• Ken Schwaber
– Primeira experiência ruim:
• Sistema web para um grande banco (CMM level3, há 3 anos), 1997
– Encontro com Mark Paulk, 2002
• Descobriu que o SCRUM já era CMM level 2 quase 3
• 2003, fez pequenos ajustes para tornar SCRUM em CMM level 3 • Jeff Sutherland
– Se tornou especialista em CMM (em conjunto com o Scrum) – Certificou algumas empresas em CMMI com Scrum
– J Sutherland et al., “Scrum and CMMI Level 5: The Magic Potion for Code Warriors”, 2008
Scrum and CMMI Level 5
Scrum and CMMI Level 5
• Establish and maintain an organizational policy for planning and performing Agile Methods
• Establish and maintain the plan for performing Agile Methods
• Provide adequate resources for performing Agile Methods
• Assign responsibility and authority for performing Agile Methods
• Train the people performing Agile Methods
• Place designated work products under appropriate level of configuration management
• Identify and involve the relevant stakeholders as planned
• Monitor and control Agile Methods against the plan and take appropriate corrective action
• Objectively evaluate adherence to the Agile Methods and address noncompliance
• Review the activities, status, and results of the Agile Methods with higher-level management and resolve issues
• Establish and maintain the description of Agile Methods
• Collect the results from using Agile Methods to support future use and improve the organization’s approach to Agile Methods
Falhas no CMMI
Falhas no CMMI
(corrigidas pelo Scrum)
(corrigidas pelo Scrum)
• Respeita processos mas ignora pessoas
• Não foca em problemas organizacionais
internos
• Associa erradamente qualidade de produto à
qualidade do processo. (O que é um produto de
sucesso?)
• Não é business-oriented
• Ignora infra-estrutura técnica e organizacional
• Foca em eficiência interna e ignora a
Métodos Ágeis aplicados no mundo
Métodos Ágeis aplicados no mundo
• Empreas
– Google, Yahoo, Microsoft, Electronic Arts, High Moon Studios, Lockheed Martin, Philips, Siemens, Nokia, Capital One, BBC, Intuit, Nielsen Media, First American Real Estate, BMC Software, Ipswitch, John Deere, Lexis Nexis, Sabre, Salesforce.com, Time
Warner, Turner Broadcasting, Oce….
• Como introduzir:
– Ken Schwaber: democraticamente (bottom-up) – Jeff Sutherland: institucionalmente (top-down)
– Mike Cohn: ambos os métodos são interessantes – Mark Striebeck at Google: “Ssh! We Are Adding a
Métodos Ágeis aplicados no mundo
Métodos Ágeis aplicados no mundo
• Cenário ideal para começar:
– Grupo pequeno (<10) – Projeto complexo
– Time interessado
– Product owner disponível
• Perfil ideal das empresas:
• Empresas que valorizam o bem-estar dos funcionários • Informais
• Respeitem as horas de trabalho dos funcionários • Pequenas ou grandes empresas (de software)
Métodos Ágeis aplicados na Petrobras
Métodos Ágeis aplicados na Petrobras
• Justamente por essas características, a Petrobras proporciona boas possibilidades de uso Ágil
• Hoje
– Existem algumas iniciativas
– Mais por parte das prestadoras de serviços
– Escolher projetos mais propícios (E&P, CENPES...) – Pouco desenvolvedores crachá verde
• Curto Prazo
– Nós podemos mudar o cenário (agora todos os 40 são ágeis) – Deve ser feito democraticamente (ou não?)
• Longo Prazo
– Metodologia Agil (além de OO, R/3 etc...) – Associar a CMMI ?
Futuro dos métodos ágeis
Futuro dos métodos ágeis
• É possível usar SCRUM para outros
desenvolvimentos que não sejam
software?
– Essa pergunta me ocorre desde o meu curso
de CSM
– Recentemente, no TMCE 2008:
“Agile PDM-implementation”, Jörg Feldhusen,
Frederik Bungert, Manuel Löwer
Referências
Referências
• Sobre o SCRUM (by Ken Schwaber)
Ken Schwaber e Mike Beedle • Sobre a prática do Scrum
Ken Schwaber • Implementação do Scrum em diversas empresas • Quase um romance Ken Schwaber • pretendo ler
Referências
Referências
• Da Internet
– Jeff-Sutherland-7-Ways-To-Fail-With-Scrum.pdf – “Agile Project Management”
• Sobre liderança ágil
– “Scrum from the trenches”
• Experiência de uso do Scrum em uma empresa na Suécia • Altamente recomendável para quem está implementando
Referências
Referências
• Outras:
– Nonaka e Takeuchi:
• “The New New Product Development Game”, 1986
• “The knowledge-creating company”, 1995, 8000 referências (+ 4000 para versão japonesa)
– Jeff Sutherland:
• “Scrum and CMMI Level 5: The Magic Potion for Code Warriors”, 2008
• “Agile development: lessons learned from the first scrum”, 2004