Métodos Ágeis de Gerência de
Métodos Ágeis de Gerência de
Desenvolvimento de
Desenvolvimento de
Software
Software
Rodrigo de Toledo
Rodrigo de Toledo
CCE / PUC-Rio CCE / PUC-Rio10-17 abril 2010
10-17 abril 2010
Plano
Plano
• Introdução: – Motivação – Histórico – Princípios – XP • Scrum:– Fluxo Scrum (Scrum Flow)
– Personagens, artefatos e meetings
• Prática:
– Velocidade, Sprint, Review – Aplicações, mitos e restrições – Exemplos
• Conclusão:
– Metodologias ágeis no mundo
• Scrum e CMMI
– Pontos fortes e pontos frágeis
– Como introduzir metodologias ágeis
• Por onde começar? • Contratos
Informações Gerais!
Informações Gerais!
• Assunto apaixonante
• Assunto polêmico
• Quebra de paradigmas
• “Depende” é sempre a melhor resposta
• Uso excessivo do inglês
– Termos
– Dificuldades de tradução (ex: “meetings” cerimônias)
• Não se desespere
• Métodos Ágeis não servem para tudo
• Arrogância x Respeito
• Perguntas a vontade
(mas respostas só no momento certo)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, – Orientado a pessoas, – Times multidisciplinares, – Inspeção/adaptação,
– Time-box
– Alta produtividade (4 a 10 vezes maior)
– Satisfação de todos: clientes, usuários, gerentes e desenvolvedores
Motivação – Métodos Ágeis
Motivação – Métodos Ágeis
• Mudanças de paradigma
Motivação
Motivação
• Quais são os problemas mais freqüentes
em projetos de TI ?
– Responder interativamente
– Lembrar dos diferentes pontos de vista:
• Desenvolvedor • Gerente de TI • Cliente
O que é
O que é
Método Ágil
Método Ágil
?
?
• É um processo?
– Não
• É um novo modelo mental?
– Talvez
• É um “nome-guarda-chuva” para diversos
métodos?
– Sim
• É uma jogada de marketing?
Motivação – Auto-ajuda
Motivação – Auto-ajuda
1. Independente da situação, você sempre
pode melhorar.
2. Você sempre pode começar a melhorar
por você mesmo.
3. Você sempre pode começar hoje.
X
Kent Beck (XP)Termos
Termos
• Métodos Ágeis:
– Se contrapõem às metodologias de engenharia clássica, usualmente aplicados ao desenvolvimento de software.
– Ex: XP, Scrum, Crystal, Lean, (RUP?), DSDM , FDD, Evo ...
• Iteração:
– Etapas curtas (1 a 4 semanas) de planejamento/desenvolvimento. – Se contrapõem ao processo em cascata.
• Adaptação:
– Opção verdadeira à natureza imprevisível do desenvolvimento de software. – Troca-se o par planejamento/controle por inspeção/adaptação.
• Auto-organização:
– As pessoas são responsáveis pelo seu próprio trabalho. – (orientado a pessoas X orientado a processos).
• Time-box:
– Todas as etapas devem estar contidas no seu tempo. – Isso é mais importante que a completude do escopo.
Um pouco de história do
Um pouco de história do
desenvolvimento de software
Motivação – Caos
Motivação – Caos
• Desenvolvimento caótico
– “Code and fix” ou “Quick and dirty”
– Um cara só faz tudo - generalista
– Pode funcionar para aplicações pequenas
– Pontos negativos:
• Imprevisível • “Dono” do código • Baixo reuso • Dificuldade de 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?
• Engenharia civil, mecânica...
• Planejamento Implementação • Linha de montagem (cascata)
• 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
• Ex: gravidade, replicação ...
– Mudanças tecnológicas maiores em impacto e freqüência.
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”
– Mudança de tecnologia
Motivação - Engenharia
Motivação - Engenharia
• Perda de Flexibilidade - The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process
(Jeff Sutherland et al. 08)
Incerteza é inerente e inevitável em desenvolvimento de software, processos e produtos
The Uncertainty Principle in Software Engineering
The Uncertainty Principle in Software Engineering
Hadar Ziv
Em um novo sistema, os requisitos não serão completamente conhecidos até que os usuários o tenham usado
A Discipline for Software Engineering
A Discipline for Software Engineering
Watts Humphrey
Não é possível especificar completamente um sistema interativo
Why Interaction is More Powerful than
BDUF – Big Design Up Front
BDUF – Big Design Up Front
Projetos de TI: • 1993, Caper Jones Grandes sistemas: 65% de fracasso • 1999, Jarzombek DOD: 75% de fracasso • 2001, Thomas Sistemas em UK: 87% de fracasso
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 valor agregado (business value) no menor custo
Video
Histórico – Métodos Ágeis
Histórico – Métodos Ágeis
• Anos 80 (qualidade)
– Nonaka e Takeuchi:
• “Knowledge Management” (gestão do conhecimento)
• Papers: “The New New Product Development Game”, 1986 “The knowledge-creating company”
• Toyota, Xerox, 3M, Fujifilm ...
– Lenda ou fato?
• Qualidade começou nos anos 70 com um americano *
– SmallTalk (Xerox, 1980)
• OO, metaclasses, dev. Environment. • 1983: virtual machine e unit test
* http://en.wikipedia.org/wiki/W._Edwards_Deming http://en.wikipedia.org/wiki/Joseph_M._Juran
Histórico – Métodos Ágeis
Histórico – Métodos Ágeis
• Anos 90
– 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 (Test Driven Development)
– Scrum (Jeff Sutherland, Ken Schwaber, Mike Beedle 93~95~99)
• Mais gerencial que XP
– Crystal (Alistair Cockburn) – FDD
– Lean / Kanban (Toyota)
Histórico – Métodos Ágeis
Histórico – Métodos Ágeis
• Influência do Scrum no XP
“Tem como pegar umas cópias do artigo sobre SCRUM do HBR? Tenho escrito alguns patterns para algo bem similar e gostaria de ter certeza que estou ‘roubando’ o máximo de idéias possíveis.” Kent
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 …
Agile Manifesto
Agile Manifesto
over over over over(A) Documentação compreensiva (B) Negociação contratual
(C) Colaboração com o cliente (D) Seguir um plano
(E) Indivíduos e interações (F) Processos e ferramentas (G) Responder a mudanças (H) Software funcionando
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 toolsWorking software
over comprehensive documentationCustomer collaboration
over contract negotiationResponding to change
over following a planThat is, while there is value in the items on the right, we value the items on the left more.
Kent Beck Mike Beedle Arie van Bennekum
Alistair Cockburn Ward Cunningham James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
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,
Alguns destaques dos princípios Ágeis
Alguns destaques dos princípios Ágeis
• Nossa maior prioridade é satisfazer o cliente
através de entrega contínua e antecipada de
software que agregue valor (
valuable software
)
• Receber bem as mudanças de requisitos
(
welcome
), mesmo que sejam tardias no processo
de desenvolvimento.
• Entregar software funcional com freqüência
• Pessoas motivadas
• Simplicidade – a arte de maximizar o trabalho
não feito
• Em intervalos regulares, o time reflete em como
ser mais eficiente
Comunicação face-a-face
Comunicação face-a-face
Comunicação Interativa Chat Wiki?Video
Video
Mudanças de paradigma
Mudanças de paradigma
– Modelo cascata Modelo iterativo
– Escopo fixo Tempo fixo (qualidade fixa)
– Planejamento/controle Inspeção/adaptação
– Orientado a processo Orientado a pessoas
• Times multidisciplinares e auto-organizados
– Mudanças de requisitos são bem vindas
– Melhoria contínua
– Desenvolvimento:
Camadas x Fatias
Camadas x Fatias
• A cada ciclo de desenvolvimento (iteração)
termina-se uma nova fatia e não uma camada
XP – eXtreme Programming
XP – eXtreme Programming
XP – eXtreme Programming
VALUES PRINCIPLES PRACTICES• 5 Valores
– ~14 Princípios • ~24 Práticas• VALUES
– Comunicação – Feedback – Simplicidade – Coragem – RespeitoXP Valores (1/2)
XP Valores (1/2)
• Comunicação:
– Compreensão do projeto – Reaproveitamento de soluções – Noção de time• Simplicidade:
– Valor de maior esforço intelectual
– “Qual a coisa mais simples que poderia funcionar?”
• Respeito:
– Aos indivíduos (profissional e pessoalmente) – Aos objetivos do projeto/empresa
XP Valores (2/2)
XP Valores (2/2)
• Feedback:
– Essencial a um processo iterativo sujeito a mudanças – Seria melhor se fosse possível acertar de primeira,
mas...
• Pode ser impossível prever a melhor maneira • O melhor hoje pode ser ruim amanhã
• Planejar o melhor possível pode ser tão custoso (ou demorado) que inviabilize o projeto
– Atenção, o feedback não pode ser maior que a capacidade de processá-lo
• Coragem:
– Coragem para jogar fora soluções ruins – Coragem para quebrar paradigmas
– Encorajar o time
XP Princípios
XP Princípios
• Alguns dos princípios:
– Melhoria contínua (improvement) – Diversidade
• equipes multidisciplinares
– Fluxo contínuo
• oposto ao método cascata
– Falhar
• não ter medo de errar se isso trouxer aprendizado • às vezes é a única maneira de acertar...
– Qualidade (robustez)
• não pode ser uma variável
• faça o melhor possível dentro do contexto
– Outros:
XP Práticas
XP Práticas
• Segundo Kent Beck:
– São práticas que objetivam a melhora
– Motivar a busca pela perfeição
• Divididas em dois grupos:
– Primárias
• Úteis independentemente das outras • Melhoria imediata
– Derivadas (corolárias)
XP Práticas (primárias)
XP Práticas (primárias)
• Sentar juntos / time completo
– Quase sempre os problemas são peopleware
– Times Cross-functional (SCRUM dá mais ênfase nisto)
• Espaço de trabalho informativo
– (como SCRUM)
• Trabalho energizado
– O que é mais produtivo, 40h ou 80h semanais ?
• Comprometimento (Slack)
– Evitar overcommitting – Evitar underdelivering
XP Práticas (primárias)
XP Práticas (primárias)
• Story
– Diferente de requisito – Estimativa do esforço• Ciclo semanal
– Stories selecionadas devem acabar na sexta – Psicologicamente bom terminar para sexta – Deployable version ao final do ciclo
• Ciclo quinzenal
– Planejar as próximas 2 semanas – Impedimentos
XP Práticas (primárias)
XP Práticas (primárias)
• Integração contínua / Ten-minute Build
– “Programação é um problema de dividir para conquistar e integrar”
• Test-first Programming (TDD)
– Proporciona coesão e confiança (inclusive para refactoring) – Ritmo: test, code, refactor, test, code, refactor...
– 1:2 linhas de código para linhas de teste
• Design Incremental
– Diário (para aquele dia)
– Estratégia mais ecônomica:
• Grandes decisões no início
• Decisões pequenas progressivamente
– Diferente da teoria do Barry Boehm 1960’s – Adaptação
Pair programming
Pair programming
• Esclarecer pequenas dúvidas de concepção • Motivação mútua (+ foco, - interrupções)
• Padronização
– codificação, design, testes, comportamentos… • Nivela por cima
• Aprendizado (inclusive de detalhes), cross-training • Aprimoração de quem ensina
• Maior compreensão coletiva da solução ((cross-functional)) • Redução de bugs (um é debugger do outro) (escalas ≠)
• Laurie Williams, "Pair Programming Illuminated", 2003 – 15% menos bug, 15% mais lento
• Atenção:
– trocar pares, variando (experiente-inexperiente; exp-exp; inexp-inexp) – cuidado com a invasão de espaço (cultural: bubble space)
– Não faz sentindo para trabalhos braçais • Dicas:
– Ping-pong programming (test and code)
XP Práticas (
XP Práticas (
Corollary
Corollary
)
)
• Envolvimento do cliente
– No Scrum é um pouco diferente
• Deployment incremental (e diário)
– Como alternativa às super-releases
• Continuidade do time
– Evitar desmembrar o time
• Redução do time (Shrinking Teams)
– Toyota Production System
– “Tentar deixar todo mundo ocupado pode ocultar o fato do time estar com folga nos seus recursos”
• Análise de causa raiz
– Bug Teste Correção Entender motivo Ação – Five Whys (5 porquês)
– Quase sempre o problema é de pessoal
• Código compartilhado / Base única de código • Codificação e teste (não documentação)
Terminologia SCRUM
Terminologia 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
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
Scrum
Scrum
• Vamos ver:
– Primeiros conceitos – Personagens – Artefatos – Meetings (cerimônias)Planejamento Iceberg
Planejamento Iceberg
Stories Stories Tarefas Tarefast
t
Épicos ÉpicosScrum – Primeiros Conceitos
Scrum – Primeiros Conceitos
• Sprint:
– Iteração (i, i+1, i+2, ...)
– Período de 2 a 4 semanas de trabalho da equipe
• Sprint diário:
– 1 dia de trabalho da equipe
• Product backlog:
– Lista de requisitos em formato user-story – Ordenada por prioridade
• Selected backlog:
– Lista de stories 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 têm relação direta com cargos e
hierarquias
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 participa da
elaboração do 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 (lidera)
– 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
– Ajuda o product owner nas suas tarefas
– De olho na próxima sprint
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, focado 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
- Porco, estava pensando que poderíamos abrir um restaurante juntos. - E qual seria o nome?
- Que tal “Presunto com ovos”?
Scrum - Artefatos
Scrum – Artefatos
Scrum – Artefatos
• User Story (backlog items)
– User stories são os itens do Product e Selected Backlogs. – Campos:
• ID, Título (ou descrição sucinta) • Valor
– Valor medido pelo product owner (business value) e / ou
– valores relativos sem significado absoluto (apenas para priorizar)
• Story points
– Esforço medido pelo time
• Descrição mais detalhada
– Suficiente para compreensão de time
– Pode conter uma descrição da interação com o usuário ou uma prévia da lista de tarefas ou ...
– “Me <name>, as <user role>, would like to <feature>, so that <value>”
• Teste de aceitação
– Outros possíveis campos:
Scrum – Artefatos
Scrum – Artefatos
• Exemplo de Selected Backlog
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
Por que usar pontos (e não tempo)?
Por que usar pontos (e não tempo)?
• Foco em estimativa relativa
• Foco em tamanho/esforço e não duração
• Usar Homem-dia sempre leva a um fator de ajuste • Performances individuais diferentes
• Com HDia a aceleração da equipe pode ficar mascarada – Tarefas similares tendem a diminuir HDia com o tempo • Ao entrar mais um membro na equipe:
– Em pontos, é esperado uma queda de produtividade do time – Com HDia há um aumento irreal de produtividade…
– Obs: 3 sprints para estabilizar a velocidade da equipe… • Cria-se uma noção intuitiva de pontos
• Evita pressão externa sobre as estimativas • Síndrome do estudante e lei de Parkinson
• Mas pode atrapalhar ao juntar grupos diferentes
Scrum – Artefatos
Scrum – Artefatos
• Tarefas
– Cada story deverá ser quebrada em tarefas – São a menor unidade de divisão
– Idealmente, tarefas correspondem a no máximo 1 dia de trabalho
– Cada tarefa vira um Post-it
– As atribuições das tarefas às pessoas ocorre diariamente
• Sprint Backlog
– Conjunto de tarefas de cada uma das stories da sprint atual
Scrum – Artefatos
Scrum – Artefatos
• Task Board
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
Scrum – Artefatos
Scrum – Artefatos
• Burn-down Chart
– São dois:
• Por sprint
• Produto completo / Release
– Contagem de pontos
• Pontos parciais das stories • Total de pontos da story
• Video
– Sw House paulista (BlueSoft):
• http://bluesoft.wordpress.com/2008/09/17/como-montamos-o-quadro-do-scrum/
– Outro (Sovis):
Scrum – Artefatos
Scrum – Artefatos
• Burn-down Chart
da release ou do produto:
– Normalmente segue um padrão
– Tem que pontuar tudo no Prod. Backlog
• Burn-up Chart
– Linha de escopo e linha de realizado – Desacopla I/O de stories da realização – Funciona em projetos sem prazo fixo
• Ex: manutenção, desenvolvimento interno
Mais stories novas do que realizadas
Stories removidas
Scrum – Artefatos
Scrum – Artefatos
• Burn-up Chart da release ou do produto:
– Previsão de término:
• Projetar horizontalmente a linha do escopo • Projetar linha de realização segundo histórico • Data de fim provável no cruzamento
– Projeção da linha de realização:
• Média geral, média das 3 últimas sprints, médias sem extremos, média exceto as 3 primeiras, etc... (vide Mike Cohn)
– Projetos sem prazo fixo:
Scrum – Artefatos
Scrum – Artefatos
- O projeto está indo ladeira
Scrum – Artefatos
Scrum – Artefatos
• Quebrando Stories:
Diferença entre stories e tarefas:
• Story: sempre agrega algum valor
• Tarefa: atividade sem importância ao PO Independente Negociável Valorável Estimável Small (pequena) Testável
I
N
V
E
S
T
Propriedades das
stories:
Scrum - Meetings
Scrum - Meetings
Scrum - Meetings
• São 6 diferentes meetings
Obs: São permitidos observadores externos (mas galinhas não tem voz). Exceção: Retrospective (existe exceção da exceção)
MEETINGS
Sprint i Sprint i +1 ...
...
Review Retrospective
Daily meetings Daily meetings
Sprint Planning 2 Sprint Planning 1 Estimation (planning poker) Estimation (planning poker)
Scrum - Meetings
Scrum - Meetings
• Planning Poker ou
Estimation meeting
– Envolvidos: time (+ product owner)
– Material: cartas do planning poker com os valores: 0 ½ 1 2 3 5 8 13 20 40 100 200
– Freqüência:
• poucas vezes ao longo da sprint
Scrum – Meetings:
Scrum – Meetings:
•
Planning Poker
– Procedimento (exemplo):
1. Identificar no product backlog o item que o time julga ser o de menor esforço e determinar como 2 pontos.
Para cada item (ou story):
2. Verificamos se a story está bem compreendida por todos. 3. Fazemos uma rodada de PP entre os membros do time.
4. Os membros que tiverem dado menor e maior valores fazem uma breve defesa do porquê.
Repetimos itens 3 e 4 até convergir
Pontuação:
Complexidade E s forço IncertezaComplexidade E s forço
Incerteza Complexidade E s forço
Incerteza Complexidade E s forço Incerteza 5 5 13 Story 1 Story 2 Story 3
Scrum - Meetings
Scrum - Meetings
• Sprint Planning 1
– Material:
• Product backlog atualizado, priorizado e estimado • Informações práticas sobre próxima sprint
– pessoas, tempo de sprint, etc
– Product owner + time + scrum master
– Objetivo: definir selected backlog e sprint goal
– Quando: todo início de sprint
Scrum - Meetings
Scrum - Meetings
• Sprint Planning 1
– Procedimento:
• Selected backlog é preenchido com os itens de maior prioridade do product backlog até completar o número de story points correspondente à
velocidade do time.
• O product owner poderá então propor alterações para incluir, excluir e alterar o escopo das stories. • Sprint goal: frase curta com o objetivo da sprint.
Scrum - Meetings
Scrum - Meetings
• Sprint Planning 2
– Material:
• Selected backlog priorizado
– Time + scrum master (+ product owner)
– Objetivo:
• Definir tarefas de cada story da sprint (criar post-it)
Scrum - Meetings
Scrum - Meetings
• Sprint Planning 2
– Procedimento:
• Divisão das stories em tarefas de 1 dia, criando post-its para a coluna “to do” (painel de tarefas).
• Lembrar que as tarefas devem incluir: • Redesign (arquitetura)
• Aprendizado de tecnologia desconhecida • Codificação • Teste • Code review • Documentação • Infra
Done!
Scrum - Meetings
Scrum - Meetings
• Daily meetings ou
Stand-up meetings ou
Scrum meetings
– Participantes: time (+SM)– Material: Painel de tarefas; post-it; canetas – Freqüência: diária
– Objetivo:
• Comunicar progresso (status diário) • Identificar obstáculos
• Manter foco • Noção de time
Scrum - Meetings
Scrum - Meetings
• Stand-up meetings
– Procedimento
:
• De pé, máximo de 15 minutos, não é para discutir problemas • 3 perguntas atualizando o Task Board:
• Sincronização de conhecimento • Atualização do burn-down
• SM deve observar as mensagens indiretas
– Pode-se propor uma penalidade para os atrasados às reuniões
O que eu fiz ontem?
1
O que vou fazer hoje?2
Tenho algum obstáculo?3
Scrum - Meetings
Scrum - Meetings
• Review
– Material:
• Informações do painel de tarefas + SW
– Participantes:
• Product owner + scrum master + time
– Objetivo:
• Revisar último sprint e andamento global do projeto
– Freqüência:
• A cada fim de sprint
Rev
iew
Rev
iew
Burn Down
Scrum - Meetings
Scrum - Meetings
• Review
– 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.
Rev
iew
Rev
iew
Burn Down Review Review clapclap clapScrum - Meetings
Scrum - Meetings
• Retrospective
– Material:
• Informações do painel de tarefas já organizados. • Post-its e flip-chart
• Ambiente seguro – Participantes:
• Time, scrum master
– Objetivo:
• Rediscutir o processo de desenvolvimento (visando a sua melhora)
• MELHORIA CONTÍNUA
Scrum - Meetings
Scrum - Meetings
• Retrospective
– Procedimento:
• Repassar a sprint cronologicamente • 5 min de WWWs em post-it
– What Went Well? (o que aconteceu de bom?)
– What Went Wrong? (e de ruim? “What can be improved?”)
• Discutir os itens organizando um impediment backlog – Quem é responsável por cada item?
Quase sempre o SM
– Lista de compromissos assumidos pela equipe • Hansei / Kaizen
Scrum - Meetings
Scrum - Meetings
• Retrospective
Minha experiência:
– PPT para conduzir reunião – Começando por:
“Independente do que será discutido, nós entendemos e acreditamos que todos fizeram o seu melhor, dado o que sabiam naquele momento, suas habilidades e competências, os recursos disponíveis e as circunstâncias da situação” (*)
– Ou seja, vamos evitar acusações: “no names”
– Slide com resumo da sprint (goal, stories, pontos, burn-down) – WWWs
– Levantamento das infos práticas para a próxima sprint (pessoas…)
Scrum - Meetings
Scrum - Meetings
Nas 4 reuniões maiores:
– Planning 1 – Planning 2 – Retrospective – Review
Scrum
Scrum
Flow
Flow
Meetings
Sprint i Sprint i +1
Daily meetings Daily meetings
Planning 2
Adaptações SIVIEP
1 day
Planning Poker
Pontos positivos:
▪ Participação do Prod. Owner em 1 único dia
▪ Apenas 1 dia sem produção
▪ Pode-se preparar a review com o time
▪ Pode-se discutir impedimentos
▪ Apresentar melhorias do processo Ponto negativo:
▪ Retrospective sem informações da
Meetings
Sprint i Sprint i +1 ...
...
Review Retrospective
Daily meetings Daily meetings
Sprint Planning 2 Sprint Planning 1
Planning Poker Planning Poker
1 day 1 day
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 lateral
• Mesmo ponto de início e fim • 90 segundos por sprint
• Mais próximo possível de Bug-free • 1 minuto para retrospectiva/review • 4 iterações
máxima? nossa velocidade Você tem certeza que é isso que ele quis dizer sobre a
10 20304050
543210
70 80 60 90Dinâmica – Quem faz o que…
Dinâmica – Quem faz o que…
•
Quais são os três personagens do Scrum?
– SM, PO, time
•
Quem é …?
1. Responsável por proteger o time: 2. Responsável pelo design:
3. Atribuidor de tarefas:
4. Participa como galinha na sprint-planning 2: 5. Não deve estar na retrospectiva:
6. Responsável por manter Scrum funcionando: 7. Responsável pelo Product Backlog:
8. Atribui pontos às stories (planning poker): 9. Aceita ou rejeita o que foi produzido:
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
– Aumento de confiança do cliente
– Motivação do time
– Melhoria contínua
– Antecipação de valor agregado
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
Exemplo de auto-atribuição de tarefas...
- Eu auto-seleciono o porco para ir…
- Você não pode auto-selecionar outra pessoa, repare o “auto” na sua frase…
- Ok, então eu me auto-seleciono o “ser supremo” e seleciono vocês como escravos para irem…
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êm rapidamente à superfície
• Group programming (collective code ownership) – Resultado das atribuições diárias e
– Equipes cross-functional (especialista-generalista) • Evitar 65% de Funcionalidade não utilizadas
Scrum - Princípios
Scrum - Princípios
Time-box (4/6)
• O tempo da sprint é mandatório
(assim como qualidade)
• Todos os meetings
têm tempo fixo:
– Daily-meeting – Sprint Planning – Etc... Qualidade Tempo Escopo Fixos custo/esforço Único que pode alterarScrum - 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
• Último momento responsável (Last responsible moment)
Scrum - Princípios
Scrum - Princípios
Menos planejamento, mais ação (5/6)
• Planejamento Iceberg
– Escala progressiva
– Detalhes do planejamento devem ser inversamente proporcionais à distância no tempo
– Scrum tem 3 escalas: projeto/release, sprint, dia
• Não discutir muito o processo:
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 - Princípios
Scrum - Princípios
• Observação, os 6 princípios descritos aqui foram
minha interpretação pessoal
• Existem 5 valores do Scrum (by Ken)
(não tão divulgados como XP)
– Foco
– Abertura ((de espírito)) – Comprometimento
– Respeito – Coragem
Ainda sobre SCRUM
Ainda sobre SCRUM
• Sprint, um resumo • Done, Velocidade • 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 o time atrasar ?
• O que fazer se o time se adiantar ?
• O que fazer com stories parcialmente feitas ?
– A descrição da sprint deve conter:
• Data de início e fim
• Pessoas comprometidas (time) • Objetivo
• Total de pontos • Selected backlog
Scrum - DONE
Scrum - DONE
Design
Codificação
Teste unitário
Revisão de código
Refactoring
Comentado
Comitado
(integração, testes …)
Documentado
Scrum - DONE
Scrum - DONE
• Entrando em acordo sobre “done”…
• Jeff Sutherland
– Done Done, done Done, done, done…
- Este projeto é meu … e não está pronto (done) enquanto
eu não estiver pronto
Scrum – Suporte Tecnológico
Scrum – Suporte Tecnológico
• Integração Contínua
– Hudson (outras: CruiseControl, Bamboo, Continuum) – C++: Scons Cmake
• Wiki (Visibilidade)
– Confluence, MediaWiki, TWiki
• Versionamento
– TortoiseSVN, Subversion, ClearCase, GIT
• Teste Unitário
– J-Unit, Cpp-Unit, NUnit, DBunit, MStest, Google test
• Revisão automática de código (padrões, otimização, etc...)
– Together, Codelogic, Findbugs, Fortify, Checkstyle/PMD
• Acompanhamento de issues
– Jira, Mantis, Trac, Bugzila, Assembla
• “Scrum” Tools
– TinyPM, ScrumFire, TargetProcess, Mingle, VersionOne, SylverCatalist
Sistema
Sistema
Siviep
Scrum - Relatórios
Scrum - Relatórios
• (Visão do projeto)
• Product backlog a cada sprint
– Análise das diferenças
• Análise de desempenho
– Burn-down charts, velocidade …
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
• Impedimentos podem revelar
esta necessidade
– Pode-se criar tarefa “estudo”
– Pode-se criar story “capacitação”
Escalabilidade
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
(segundo Mike, em 2007 havia pelo menos 3 no mundo) • Faz uso genérico do Scrum (além de des. de sw)
• Próximo desafio: + de 10.000 pessoas
• Exemplos:
Scrum of Scrum
Scrum of Scrum
Scrum of Scrum
Scrum of Scrum
• Requisitos (stories) descem via PO’s
• Impedimentos sobem via SM’s
• Reuniões diárias dos PO’s e SM’s
• Devem existir Scrum Master Master
– Como?
– Um dos PO’s e um dos SM’s; ou – Um SMM que resolva tudo
• Originalmente, SofS foi o resultado de uma
decisão democrática de se dividir um time grande
– Primeiro se resolve infra (build, comunicação etc…) – Os membros do time inicial viram os PO’s dos times
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
– Colaborativo
– Arquitetura de componentes – Sistema de Plug-in’s
– Acesso às funcionalidades via script – Open source
– Plataforma de desenvolvimento para outras universidades – Browser 3D
Poços
Plataforma (PNA-I) Plataforma (PNA-II)
Reservatório
2008
2009
Exemplo Prático – v3o2
Exemplo Prático – v3o2
• E&P
• Projeto antigo com diversos usuários
• ± 15 sprints realizadas
• Começou com 2 times de 5 pessoas (± scrum of
scrum)
É possível ser mais produtivo?
É possível ser mais produtivo?
Sistema Lean/Kanban
• Entrega just-in-time
– Não há iterações
– Fluxo contínuo de entrega
• Backlog sempre pode ser alterado
– Backlog Kanban dividido em duas áreas
• 7 cartões de maior prioridade
• Cartões a serem trabalhados nos próximos 30 dias
• Equipe de atendimento ao cliente
– Recebe cartões que finalizaram no desenvolvimento
• Estimativa:
– T-shirt sizing: P, M, G
– Qualquer um pode estimar
– Pode-se trocar o tamanho ao longo do processo
• Fonte: Alisson Vale
– www.phidelis.com.br/blogs/alissonvale/post/A-Historia-de-um-Sistema-Kanban.aspx – www.agilemanagement.net/Articles/Weblog/KanbaninAction.html
Lean e Scrum-Ban
Lean e Scrum-Ban
• Lean ≡ Lean Thinking ≡ TPS ≡ Toyota way
– Construindo profissionais (building people) – Melhoria contínua
– “Eliminar desperdícios” [Lean Thinking 1996]
• Scrum-ban
– Trabalho em andamento limitado (limited WIP) – Mais colunas (pronto, revisão, teste, entrega etc...) – Combinação de ambos
• Quebra das quebras de paradigmas
– Time-box Fluxo contínuo (pontos por sprint tempo de entrega) – Escopo totalmente aberto (não é fechado nem durante a sprint)
– Desacopla frequência de planejamento da frequência de entrega – Permite times de especialistas
• Atenção!!!!
– Dificilmente é um ponto de partida (é mais um ponto a se chegar) – Cuidado para não voltar ao modelo cascata
• Referências (veja também: David Anderson)
– http://leansoftwareengineering.com/ksse/scrum-ban/
– http://www.infoq.com/minibooks/kanban-scrum-minibook (making the most of both) – http://www.leanprimer.com/downloads/lean_primer.pdf
Scrum – Conclusões
Scrum – Conclusões
• O que é scrum para vocês?
• Comparado com outros métodos?
Tópicos para discussões finais
Tópicos para discussões finais
• Diferenças entre Scrum e XP • Scrum e CMMI
• Pontos fortes e pontos frágeis • Contratos
• Como introduzir na prática • Conclusão
Diferenças entre Scrum e XP
Diferenças entre Scrum e XP
• XP é mais técnico (programação) Scrum é mais gerencial (liderança) • XP tem iterações de 1 ou 2 semanas
Scrum tem iterações de 2 a 4 semanas
• XP fala de atribuições de diversos profissionais Scrum é mais cross-functional
• XP diz que cliente tem que estar presente
Scrum diz que cliente tem que estar disponível • Scrum prega a flexibilidade mais claramente • Scrum simplifica personagens (apenas 3)
• Scrum é mais concreto (meetings e artefatos) XP e Scrum são muito alinhados! Porém:
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 level 3, desde 94), 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
• Brasileiros:
– “Mapping CMMI Project Management Process Areas to SCRUM Practices”, Ana Sofia et al., 2007
• David Anderson
Scrum e CMMI nível 5 segundo o
Scrum e CMMI nível 5 segundo o
artigo do Jeff Sutherland
artigo do Jeff Sutherland
• 12 dicas de como fazer
• Falhas no CMMI 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 a infra-estrutura técnica e organizacional
– Foca em eficiência interna e ignora a competitividade externa
Pontos fortes e pontos fracos
Pontos fortes e pontos fracos
dos métodos ágeis
Pontos Fortes dos Métodos Ágeis
Pontos Fortes dos Métodos Ágeis
• Listar:
– Quais são as características do Scrum que
motivam os desenvolvedores?
– Argumentos para convencer um cliente a
adotar métodos ágeis?
Pontos frágeis dos Métodos Ágeis
Pontos frágeis dos Métodos Ágeis
• Para times tecnicamente experientes
– Ken Schwaber diz que funciona com idiotas
• Processo exigente, trabalha-se muito
– Google compensa com o esquema 80-20
• Pode tornar o ambiente mais sério (?)
• Perda de flexibilidade no horário
– Stand-up meetings
• Perde-se parcialmente a privacidade
– Todos sabem o que você está fazendo
– Pair-programming
Pontos frágeis dos Métodos Ágeis
Pontos frágeis dos Métodos Ágeis
• Pode-se encontrar resistência com outros
setores não ágeis
• Há situações que não cabem mudanças
de requisitos constantes
– Ex: robo em Marte da Nasa
– “No Silver Bullet”, Frederick Brooks
Atenção! Cuidado com os falsos mitos
negativos:
– Só serve para grupos pequenos (FALSO)
– Não gera documentação (FALSO)
Pontos frágeis dos Métodos Ágeis
Pontos frágeis dos Métodos Ágeis
• Como tratar especialistas em equipes multidisciplinares? • Como fazer o contrato (preço e escopo)?
• Como auditar e certificar? ((obs: falar sobre CSM)) • Como lidar com pessoas em mais de um projeto? • Como avaliar indivíduos se o trabalho é em grupo?
– Conciliar metas individuais e metas em grupo
– Valorizar metas individuais relativas à atuação de grupo (“individual teamwork”)
– O time pode avaliar cada membro
• Os que planejavam e atribuíam tarefas estão preparados para deixar com que outros o façam? E vice-versa?
• Estão todos preparados/maduros para que os problemas fiquem em evidência?
Contratos
Contratos
• Problema:
– Convencional (não ágil):
• Fixed price / fixed date ou … “Latest date / maximum cost”
• Soluções:
– Contratos com períodos menores
• Subdivisão de contratação • Subcontratos trimestrais
– Contrato por hora de consultoria (pessoa/mês e não hora)
• Esquema Tecgraf
– Já existem diversos modelos de contrato prontos – Link em português:
• http://www.infoq.com/br/news/2008/10/agile-contracts-working-group • http://www.erudio.com.br/downloads/doc_download-42.html
Contratos
Contratos
• Segundo Kent Beck (XP):
– Contrato com Escopo Negociável
• Fixa tempo, custo e qualidade
• Interessante para modelo “serviço”
• Pode ser uma seqüência de pequenos contratos
– Pay-per-use
• Melhor opção
• Se levado ao extremo:
– Cada story tem por objetivo aumentar o uso
• Pay-per-release é ruim pois opõe interesses:
– Cliente quer poucas releases ($)
– Sw House quer muitas releases com o mínimo de incremento
– Modelo de Subscrição:
Métodos Ágeis aplicados no mundo
Métodos Ágeis aplicados no mundo
• Empresas
– 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….
• Finlândia tem a maior incidência de SM,
por que?
• Em 2007, 120 mil times de Scrum no mundo
Métodos Ágeis aplicados no mundo
Métodos Ágeis aplicados no mundo
Standish Group, 2006
– Métodos ágeis são um dos responsáveis para o aumento recente do número de projetos com sucesso
http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
Forrester Institute, 2007
– 17% das empresas norte-americanas e européias estão utilizando o desenvolvimento ágil.
– 29% conhecem e acompanham o assunto.
PMI.org, dezembro 2008
– Agile Software Development Projects Enable Adaptability and Success
• “Agile pode ser a cura para projetos de desenvolvimento de software atrasados e com alto custo”
• “Estamos convencidos que Agile pode atacar qualquer domínio de problema, tão logo a cultura do negócio esteja pronta para trabalhar com ela”
http://www.pmi.org/passport/dec08
http://blog.adsystems.com.br/2008/12/30/oficializada-a-comunidade-pmi-agile/
PM Network, january 2009
– The incredible shrinking team
http://www.pmnetwork-digital.com/pmnetwork/200901open/
Métodos Ágeis aplicados no Brasil
Métodos Ágeis aplicados no Brasil
• Globo.com
– Ago 2008: 17 times ágeis
– Dez 2009: http://gc.blog.br/2009/12/04/2-anos-de-scrum-e-agile-na-globo-com-e-algumas-coisas-que-eu-aprendi/
• Tecgraf
– Desde início de 2007
• Ci&T (“The 2008 Global Outsourcing 100”)
– 100 pessoas em projetos ágeis – 11 sprints/mês (set 2008)
• Petrobras
– SNEP: 20 times
– TIC-Engenharia, CENPES, UN-RN, outras iniciativas
• MEC, Aeronáutica…
http://blog.seatecnologia.com.br/articles/2008/05/29/experiencias-%C3%81geis-na-sea-episodio-i-%E2%80%93-a-ameaca-fantasma
• O Globo – capa Boa Chance – 15 fev 2009
http://oglobo.globo.com/economia/seubolso/mat/2009/02/14/metodo-que-prega-metas-de-curto-prazo-integracao-de-equipe-ganha-mercado-754418293.asp
Introduzindo Métodos Ágeis
Introduzindo Métodos Ágeis
• Como introduzir:
– Ken Schwaber (e Kent Beck):
• Democraticamente (bottom-up)
– Jeff Sutherland:
• Institucionalmente (top-down)
– Mike Cohn:
• Ambos os sentidos são interessantes
– Mark Striebeck at Google:
Por onde começar?
Por onde começar?
• Segundo Mark Stribeck (Google)
(“Ssh! We are adding a process”)
1.Selected backlog Burn-down chart
Estimativa em pontos Ciclo semanal
2.Daily meetings
3.Foco em completar stories
– Redução do “doing” – Conceito de “done” 1.Retrospectiva 2.SCRUM – Product backlog – Meetings
“Burndown charts facilitaram a visualização do progresso e nos deu um senso de satis-fação e realização!”
Engenheiro de software
“Levou um tempo até eu ter confiança no Burndown e aceitar o questionamento sobre o meu feeling de quando uma funcionalidade estaria pronta!”
Por onde começar?
Por onde começar?
• Segundo Kent Beck (XP)
– Pode-se começar por qualquer prática primária
• Escolha de acordo com o problema a ser enfrentado
– Comece por você mesmo (weekly)
– Use XP ((ou outro método ágil)) para conduzir as mudanças
• Espécie de meta-processo
– Verifique a melhoria – (Bottom-up)
– Cuidado, certas práticas não têm efeito se não forem combinadas com outras. Ex:
• shared code (ou collective code ownership)
não sem Continuous Integration e “pair programming”
Por onde começar?
Por onde começar?
• Segundo Ken Schwaber (Scrum)
– Project Quickstart: 2 dias
• Ensinando Scrum
• Preparando a primeira sprint
• (Talvez só mesmo o Ken consiga isso)
– O mínimo necessário para começar o scrum:
• Visão do projeto (descrevendo seus benefícios) • Product Backlog
– O Scrum só é compreendido depois de praticado
– Primeiras sprints cuidam mais da infra-estrutura
• Especialmente em projetos com muitos membros • Mas a sprint sempre tem features para o usuário
Por onde começar?
Por onde começar?
• Problemas enfrentados pelo Jeff (top-down)
• Resistência organizacional • Apatia gerencial • Treinamento inadequado • Falta de suporte dos parceiros • Falta de regras formais