Métodos Ágeis de Gerência de Desenvolvimento de Software

(1)

Métodos Ágeis de Gerência de

Desenvolvimento de

Software

_Software

Rodrigo de Toledo

(Cenpes/PDP/GR)

20,22 abril 2009

ADS-TI

(2)

Plano

• Introdução: – Motivação – Histórico – Princípios – XP • Scrum: – Scrum flow

– Personagens, artefatos e meetings

• Prática:

– Velocity, 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

(3)

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)

• Horário intervalo?

(4)

Introdução

(5)

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

(6)

Motivação – Métodos Ágeis

(7)

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

(8)

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?

(9)

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

(10)

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. – (people-oriented x process-oriented).

• Time-box:

– Todas as etapas devem estar contidas no seu tempo. – Isso é mais importante que a completude do escopo. – Prazo fixo, escopo variável.

(11)

Um pouco de história do

desenvolvimento de software

(12)

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 • ...

(13)

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

(14)

• 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

(15)

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.

(16)

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

(17)

Motivação - Engenharia

• Perda de Flexibilidade (Jeff Sutherland et al. 08)

– Princípio da Incerteza de Ziv:

Incerteza é inerente e inevitável em desenvolvimento de software processos e produtos.

– Princípio da Incerteza de Requisitos de Humphrey:

Em um novo sistema os requisitos não serão completamente conhecidos até que os usuários tenham o usado.

– Lema de Wegner:

(18)

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

(19)

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

(20)

Video

(21)

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 ... – Algumas histórias ou lendas:

• Força tarefa japonesa (by Ken)

• Grupo de consultoria (Toyota consulting)

• Qualidade começou nos anos 70 com um americano * – SmallTalk (Xerox, 1980)

• OO, metaclasses, dev. environment, virtual machine (1983), unit test

(22)

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 (Test Driven Development)

– 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

(23)

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

(24)

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 …

(25)

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

(26)

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.

Kent Beck Mike Beedle Arie van Bennekum

Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

(27)

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,

(28)

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

(29)

Comunicação face-a-face

Comunicação Interativa Chat Wiki?

(30)

Video

(31)

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

• Cross-functional teams; self-organized teams

– Mudanças de requisitos são bem vindas

– Melhoria contínua

– Desenvolvimento:

(32)

Camadas x Fatias

• A cada ciclo de desenvolvimento (iteração)

termina-se uma nova fatia e não uma camada

(33)

XP – eXtreme Programming

(34)

XP – eXtreme Programming

VALUES PRINCIPLES PRACTICES

• 5 Valores

– ~14 Princípios • ~24 Práticas

• VALUES

– Comunicação – Feedback – Simplicidade – Coragem – Respeito

(35)

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

(36)

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

(37)

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:

(38)

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)

((antes ou depois do Scrum ?))

(39)

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

(40)

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

– cuidado com a invasão de espaço (cultural: bubble space)

• Dicas:

– Ping-pong programming (test and code)

(41)

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

(42)

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

(43)

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

• Codificação e teste (não documentação) • Base única de código

(44)

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 Board

(45)

SCRUM

(46)

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

(47)

Scrum

• Vamos ver:

– Primeiros conceitos – Personagens – Artefatos – Meetings (cerimônias)

(48)

Planejamento Iceberg

Epics Epics Themes Themes Stories Stories Tasks Tasks

t

(49)

Scrum – Primeiros Conceitos

• Sprint:

– Iteração (i, i+1, i+2, ...)

– 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 stories a serem realizadas durante a sprint – Baseada nas maiores prioridades do product backlog – De acordo com a capacidade da equipe em uma

(50)

Scrum

(51)

Scrum - Personagens

(52)

Scrum - Personagens

• Apenas três

• Não têm relação direta com cargos e

hierarquias

Scrum Master Product Owner

(53)

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

(54)

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

– Ajuda o product owner nas suas tarefas

– De olho na próxima sprint

(55)

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

• transparência e diálogo

(56)

(57)

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”?

(58)

Scrum - Artefatos

(59)

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 ...

• Teste de aceitação

– Outros possíveis campos:

• “Me <name>, as <user role>, would like to <feature>, so that <value>”

(60)

Scrum – Artefatos

• Exemplo de Selected Backlog

(61)

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

(62)

Por que usar pontos (e não tempo)?

• Foco em estimativa relativa

• Performances individuais diferentes

• Foco em tamanho/esforço e não duração

• Usar Homem-dia sempre leva a um fator de ajuste

• 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 velocity da equipe… • Cria-se uma noção intuitiva de pontos

• Evita pressão externa sobre as estimativas • Síndrome do estudante e lei de parkson

• Mas pode atrapalhar ao juntar grupos diferentes

(63)

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

(64)

Scrum – Artefatos

(65)

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

(66)

Scrum – Artefatos

• Burn-down Chart

– São dois: • Por sprint • Produto completo – 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):

(67)

Scrum – Artefatos

- Não foi isso o que eu quis dizer sobre “burn-down correction”! - O projeto está

indo ladeira abaixo!!!

(68)

Scrum - Meetings

(69)

Scrum - Meetings

• São 6 diferentes meetings

Obs: São permitidos observadores externos (mas galinhas não tem voz). Exceção: Retrospective MEETINGS Sprint i Sprint i +1 _... ... Review Retrospective

Daily meetings Daily meetings

Sprint Planning 2 Sprint Planning 1 Estimation (planning poker) Estimation (planning poker)

(70)

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:

• algumas poucas vezes e de maneira rápida ao longo da sprint • opcionalmente junto com a sprint planning 1

(71)

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):

1. Verificamos se a story está bem compreendida por todos. 2. Fazemos uma rodada de PP entre os membros do time.

3. Os membros que tiverem dado menor e maior valores fazem uma breve defesa do porquê.

Repetimos itens 3 e 4 até convergir

(72)

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

– Product owner + time + scrum master

– Objetivo: definir selected backlog e sprint goal

– Quando: todo início de sprint

(73)

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 à

velocity 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.

(74)

Scrum - Meetings

• Sprint Planning 2

– Material:

• Selected backlog priorizado

– Time + scrum master (+ product owner)

– Objetivo:

• Definir tarefas de cada story do sprint (criar post-it)

(75)

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:

• Aprendizado de tecnologia desconhecida • Programação • Teste • Code review • Documentação • Infra

Done!

(76)

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

(77)

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

O que eu fiz ontem?

1

O que vou fazer hoje?

2

Tenho algum obstáculo?

3

(78)

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:

(79)

Scrum - Meetings

• Review

– Procedimento:

• Revisar detalhes da última sprint: – objetivo, stories, burndown chart etc.

• Demo do último incremento do projeto.

(80)

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

(81)

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 • Fechamento

(82)

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

– Preparar Review

– Levantamento das infos práticas para a próxima sprint (pessoas…)

(83)

Scrum - Meetings

Nas 4 reuniões maiores:

– Planning 1 – Planning 2 – Retrospective – Review

(84)

Scrum

Flow

(85)

Meetings

Sprint i Sprint i +1

Review

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 impediments Ponto negativo:

▪ Retrospective sem informações da review Meetings Sprint i Sprint i +1 _... ... Review Retrospective

Sprint Planning 2 Sprint Planning 1 Planning Poker Planning Poker

1 day 1 day

(86)

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

• 1 minuto para retrospectiva/review • 5 iterações

máxima? a nossa velocity Você tem certeza que é isso que ele quis dizer sobre

10 20304050

543210

70 80 60 90

(87)

Scrum - Velocity

• Velocity

(88)

Dinâmica – Quem faz o que…

• Quais são os três personagens do Scrum?

– SM, PO, time

• Quem é …?

– Responsável por proteger o time: – Responsável pelo design:

– Atribuidor de tarefas:

– Participa como galinha na sprint-planning 2: – Não deve estar na retrospective:

– Responsável por manter Scrum funcionando: – Responsável pelo Product Backlog:

– Atribui pontos às stories (planning poker): – Aceita ou rejeita o que foi produzido:

(89)

Scrum - Princípios

(90)

Scrum - Princípios

Processo iterativo e incremental (1/6)

• Modelo Tradicional

• Modelo Ágil

(91)

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.

(92)

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

Manifesto Ágil: devemos valorizar mais INDIVÍDUOS e INTERAÇÕES que processos e ferramentas

(93)

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

(94)

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 60% de Funcionalidade não utilizadas

(95)

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 alterar

(96)

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.

(97)

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, sprint, dia

• Não discutir muito o processo:

(98)

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

(99)

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

(100)

Ainda sobre SCRUM

• Sprint, um resumo • Done, Velocity • Infraestrutura • Escalabilidade • Aprendizado • Exemplo Prático

(101)

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 ? – A descrição da sprint deve conter:

• Data de início e fim

• Pessoas comprometidas (time) • Objetivo

• Total de pontos • Selected backlog – Botão Vermelho

(102)

Scrum - DONE

Design

Codificação

Teste unitário

Revisão de código

Refactoring

Comentado

Commited

(integração, testes …)

Documentado

(103)

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

(104)

Scrum – Suporte Tecnológico

• Integração Contínua

– Hudson (ou CruiseControl ou Bamboo) – Scons  Cmake • Wiki (Visibilidade) – Confluence, MediaWiki • Versionamento – TortoiseSVN, ClearCase • Teste Unitário – J-Unit – Cpp-Unit – NUnit – Google test

• Revisão automática de código

– Together (padrões, otimização, etc...) • Acompanhamento de issues

(105)

Sistema

Siviep

(106)

(107)

(108)

Scrum - Relatórios

• Product backlog a cada sprint

– Análise das diferenças

• Análise de desempenho

– Burn-down charts, velocity …

(109)

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”

(110)

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:

– Google AdSense

(111)

Scrum of Scrum

(112)

Scrum of Scrum

(113)

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

• Idealmente, SofS é 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

(114)

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

(115)

• Antes do Scrum

– Um pouco mais de um ano de projeto

– Nenhum resultado (business value)

• Depois do Scrum

– 5-7 pessoas

– 20 sprints realizadas (até 2008)

Exemplo Prático - SiVIEP

(116)

Poços

Plataforma (PNA-I) Plataforma (PNA-II)

Reservatório

(117)

(118)

• Adaptações iniciais do Scrum no SiVIEP:

– 3 dias úteis de trabalho por semana

– Limbo + Prod. Backlog candidates

– Mesa retrátil

– Post-it chart (cor diferente para post-it novo)

– Estimation meeting acontece em conjunto com

sprint planning 1

– Inversão entre retrospective e review

Exemplo Prático - SiVIEP

(119)

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)

(120)

É possível ser mais produtivo?

Sistema 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

http://www.phidelis.com.br/blogs/alissonvale/post/A-Historia-de-um-Sistema-Kanban.aspx

http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html http://www.infoq.com/br/news/2009/01/brasil-representacao-conferencia

(121)

Scrum – Conclusões

• O que é scrum para vocês?

• Comparado com outros métodos?

(122)

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

(123)

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)

(124)

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

(125)

Scrum e CMMI Level 5, como fazer

• 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

(126)

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

(127)

Pontos fortes e pontos fracos

dos métodos ágeis

(128)

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?

(129)

• Scrum, patterns. “Organizational patterns and agility”, James O. Coplien, 2004

Jim ficou surpreso quando descobriu que o Scrum resumia pelo menos 33

Orgulho do time Círculo de

confiança

(130)

Pontos frágeis dos Métodos Ágeis

• Para times 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

(131)

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)

(132)

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?

• Estão todos preparados/maduros para que os problemas fiquem em evidência?

(133)

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

(134)

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:

(135)

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

(estimado por Jeff Sutherland)

(136)

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/

(137)

Métodos Ágeis aplicados no Brasil

• Globo.com

– Ago 2008: 17 times ágeis • Tecgraf

• Ci&T (“The 2008 Global Outsourcing 100”)

– 100 pessoas em projetos ágeis

– Projetos ágeis com times de 6-10 pessoas – Começando scrum of scrums

– 11 sprints/mês (set 2008) • 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

(138)

Introduzindo Métodos Ágeis

• Como introduzir:

– Ken Schwaber:

• Democraticamente (bottom-up)

– Jeff Sutherland:

• Institucionalmente (top-down)

– Mike Cohn:

• Ambos os sentidos são interessantes

– Mark Striebeck at Google:

(139)

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” 4.Retrospectiva 5.SCRUM – Product backlog – Meetings – etc

“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!”

(140)

Introduzindo Métodos Ágeis

• 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 – Com algum grau de informalidade

– Respeitem as horas de trabalho dos funcionários – Pequenas ou grandes empresas (de software)

(141)

Por onde começar?

• O mínimo:

– Processo iterativo com melhoria contínua

• Sem perder tempo no início:

– Primeiros passos:

• Product backlog aproximado • Alguns story points

• (Quanto tempo para fazer isso?) – Selected backlog

– To do; doing; done – Stand-up meeting

– Sprint 0, menos comprometida (uma transição)

• Sprints curtas no início

– Feedback inicial mais rápido

(142)

Por onde começar?

• Exemplo de stories para a sprint 0

– “Instalar sistema de versionamento" – “Instalar integração contínua“

• Configurar Hudson

– “Instalar teste unitário"

– "Realizar mini-palestra (2h) sobre Scrum" – “Gerar o product backlog no excell”

– “Pontuar as stories do P.B.“

– “Gerar um modelo inicial de componentes/camadas” – “Criar o task-board"

– “Criar a aplicação” (login ou algo mais…) • janela aparece com botão de fechar

(143)

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

(144)

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

(145)

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

Problemas ao

implementar Agile

(146)

Por onde começar?

• The Nokia test:

– Identifica se um time está fazendo SCRUM – Dividido em dois grupos de perguntas

– Iteratividade:

• Iterações com time-box fixo?

• Iterações menores que 4 (6) semanas?

• Iteração só começa com a lista completa do “a fazer” (S.B.)? • Iteração termina com um software funcionando?

• Iteração contém testes?

– Scruming:

• P.O. é bem definido (uma única pessoa)? • Existe um Product Backlog (P.B.) priorizado? • O P.B. está estimado pelo time?

• Há um burn-down chart (velocity) ao longo da sprint ?

(147)

Por onde começar?

• 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”

• Cuidado ao tentar todas as práticas ao mesmo tempo…

- O que o seu processo precisa é de uma mudança completa (make-over). Ou seja, adotando todas as práticas