Tradução resumida do livro   “The Elements of Scrum”     Chris Sims e Hillary Louise Johnson                  Henrique Bue...
1. Introdução a Agilidade   1.1. No começo: O Método Cascata      Winston W. Royce apresentou o tradicional método Cascata...
Em um processo Cascata, cada etapa deve ser concluída antes do início da          próxima etapa, e todas as etapas devem s...
“O movimento ágil não é anti-metodologia”, Highsmith disse, “de fato, nós     queremos recuperar a credibilidade da palavr...
Mas como isso tudo funciona na prática? Como você faz desenvolvimento          ágil? Independente da adoção de Scrum, Lean...
Responder a mudanças mais que seguir um plano          Como a maioria das coisas verdadeiras, os valores ágeis soam simple...
Uma má interpretação comum é que times ágeis não documentam ou          planejam; mas na prática, times ágeis realmente ga...
existe um obstáculo. Controle de mudança só pode funcionar no contexto          onde mudança é realmente controlável.     ...
Uma de nossas estórias favoritas de tecnologia é de uma startup chamada          Confinity, que teve um software chamado P...
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em                                conjunto por todo o pro...
Esse princípio é simples o suficiente: a prova está no pudim. Não na lista          da mercearia, não na receita. Não na g...
Simplicidade--a arte de maximizar a quantidade de trabalho não                                      realizado--é essencial...
humanos, e se há um consolo, eles também podem cair em bons hábitos. A           maior parte de um processo ágil – alguns ...
“Amor é a força inflama o espírito e amarra times juntos” Phil Jackson      “Talento vence jogos, mas trabalho em equipe e...
Isso parece ser um grande trabalho ... bem ... e é! Na nossa experiência,          este é o perfil que mais é demandado em...
Facilitador     2.2.3. O papel do membro do time          Times Scrum são altamente colaborativos; eles também são auto-  ...
O ciclo Sprint é o ritmo fundamental do processo Scrum, mas o conceito não é      exclusivo do Scrum. Métodos ágeis compar...
A meta desta parte da reunião é levantar um conjunto de estórias que                 todos acreditam que serão entregues n...
Como estimar tarefas: Quais unidades utilizar? Existem 3 estratégias                 comuns: horas, pontos e quantidade.  ...
Algumas pessoas simplesmente chamam esta reunião de Backlog          grooming. Nesta reunião você irá trabalhar com próxim...
2.3.7. Inspecione e adapte, baby          Então, porque nós fazemos desenvolvimento de software em ciclos curtos?         ...
2.4.3. Radiadores de informação          Andando na área de trabalho de um time Scrum você irá encontrar as          pared...
Essa é a ferramenta que o product owner utiliza para acompanhar o          trabalho restante ao longo do tempo. Os increme...
2.4.8. Quadro de tarefas          Um quadro de tarefas é um irradiador de informação: ele serve para manter          todos...
Outra variação comum é dividir o quadro em raias horizontais. Cada estória          fica em sua própria raia e as tarefas ...
“Computadores tornam mais fácil fazer várias coisas, mas a maioria das coisas      que eles tornam mais fácil fazer não pr...
então todos os envolvidos na conversa irão concordar que a estória é          implementada como se pretende. Critérios de ...
Enquanto seres humanos são ruins para estimar durações, eles são bons          para comparar coisas e falar qual é a maior...
tarefa, e todos mostram suas escolhas ao mesmo tempo. Se todos          estimarem a mesma coisa, você está feito, não há n...
Próximos SlideShares
Carregando em…5
×

Tradução resumida do livro "The Elements of Scrum"

874 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
874
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
44
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Tradução resumida do livro "The Elements of Scrum"

  1. 1. Tradução resumida do livro “The Elements of Scrum” Chris Sims e Hillary Louise Johnson Henrique Bueno riquebueno@gmail.com Versão 2www.hbueno.com Página 1
  2. 2. 1. Introdução a Agilidade 1.1. No começo: O Método Cascata Winston W. Royce apresentou o tradicional método Cascata em um artigo no IEEE WestCom em 1970. Royce não utilizou o termo Cascata, mas descreveu um processo sequencial onde cada fase é concluída antes do início da próxima fase. O que você não deve saber é que Royce apresentou este modelo como um exemplo de processo de desenvolvimento de software a não ser seguido! Royce disse que com certeza ninguém conduziria um projeto de software desta forma, e em seguida descreveu um processo iterativo, muito parecido com as metodologias ágeis de hoje, que ele declarou categoricamente ser superior. Entretanto, a descrição do que seria conhecido como Cascata foi muito discutido pelos ouvintes da apresentação. O evento que transformou o status da abordagem Cascata como o modelo padrão e reconhecido para o desenvolvimento de software em empresas foi a adoção pelo Departamento de Defesa Americano (DDA). Em 1985 o método Cascata foi adotado como padrão oficial para a condução dos projetos do DDA, das agências do governo e das empresas contratadas pelo governo. Na virada do século XXI, até o governo americano começou a perceber que a escolha do método Cascata foi falha. Em 2005, um documento oficial da Nasa descrevendo o método dizia: “O modelo padrão Cascata está associado a falha ou cancelamento de um grande número de sistemas. Ele também pode ser muito caro”. O documento mencionava uma metodologia que parecia ser promissora chamada “eXtreme Programming”. Quatro anos mais tarde, a Nasa anunciou que seus engenheiros tinham planejado sua própria metodologia ágil chamada "Extreme Programming Maestro Style". A Nasa utilizou esta metodologia para escrever o software de controle do robô enviado a Marte. Interessante, né? 1.1.1. Definição do método Cascata O método Cascata para desenvolvimento e entrega de projetos de software para empresas divide o processo em etapas discretas: levantamento de requisitos, projeto, codificação e teste.www.hbueno.com Página 2
  3. 3. Em um processo Cascata, cada etapa deve ser concluída antes do início da próxima etapa, e todas as etapas devem ser completadas antes da entrega de qualquer valor ao cliente. Defensores da abordagem Cascata defendem uma filosofia conhecida como Big Design Up Front (BDUF), que é comum a várias metodologias de desenvolvimento de software baseadas em planos. Um argumento comum a favor do BDUP é que trabalhando de forma perfeita na fase de projeto antes de passar à fase de implementação, os erros e bugs serão encontrados cedo e consequentemente os gastos durante o restante do projeto. O problema está no uso da palavra “perfeito”. BDUF se baseia na premissa de que é possível ser perfeito no projeto de um produto antes de iniciar sua produção. Talvez isso seja verdade no processo de construção de carros, mas produtos de software são sistemas complexos e não estáticos. 1.2. A chegada dos “Agilistas” “Agora tenho apenas uma noção, mas acho que posso conseguir dinheiro para tornar isso um conceito, e mais tarde transformar em uma ideia.” Woody Allen Em 2001, 17 geeks se encontraram no resort de ski Snowbird em Utah para explorar um pressentimento compartilhado sobre o futuro do desenvolvimento de software. Eles incluíram defensores de metodologias nascentes como Scrum, eXtreme Programming, Crystal, Feature-driven development, e outros “simpáticos a necessidade de alternativas aos pesados processos de desenvolvimento de software baseados em documentação”. Eles chegaram a um nome para o movimento: “Ágil”. Eles criaram a Aliança Ágil (www.agilealliance.org) e escreveram o Manifesto Ágil: um curto conjunto de sentenças que deveria funcionar como a Declaração de Independência, Constituição e Carta de Direitos do novo movimento.www.hbueno.com Página 3
  4. 4. “O movimento ágil não é anti-metodologia”, Highsmith disse, “de fato, nós queremos recuperar a credibilidade da palavra metodologia. Nós queremos restaurar a balança. Nós abraçamos a modelagem, mas não para preencher alguns diagramas que ficarão empoeirados no repositório corporativo”. Nada disso ocorreu no vácuo. A Aliança Ágil foi uma reação à forma como projetos de software estavam sendo comumente gerenciados. Os tempos estavam para mudança. Em 1995, o relatório anual “Chaos” do Standish Group (blog.standishgroup.com) detalhou a falha dos métodos tradicionais de desenvolvimento de software. De acordo com o relatório, apenas 16% dos projetos de software conduzidos pelas estratégias tradicionais acabaram no tempo e no prazo definidos, 31% dos projetos foram cancelados, enquanto 53% passaram 189% da previsão de gastos inicial. Quando os gerentes de TI foram questionados sobre estes números, as principais causas foram “falta de envolvimento do cliente” e “requisitos incompletos”. Os teóricos ágeis que se encontraram em Snowbird acreditaram que a metodologia iterativa era o futuro. 1.2.1. O método iterativo Um problema chave do BDUF é que ele assume conhecimento perfeito do futuro. Mas qualquer um que tenha trabalhado em um projeto de software em escala corporativa sabe que a única coisa com a qual você pode contar é a mudança. Processos ágeis de todos os tipos compartilham uma coisa: eles aceitam mudança, enxergam isso como uma oportunidade para crescimento, ao invés de um obstáculo. Times ágeis fazem o mesmo trabalho que times cascata, mas eles fazem de forma diferente. O ciclo de desenvolvimento ágil emprega as mesmas funções que o método Cascata, levantamento de requisitos, projeto, codificação e teste. A visão simples de como a metodologia ágil difere do desenvolvimento cascata é este: um time ágil, ao invés de completar cada etapa antes de ir para a próxima etapa, faz um pouco da etapa de levantamento, um pouco do projeto, codifica e testa, e entrega um pouco de valor ao cliente. Então o time começa tudo de novo... e de novo, refinando os processos junto como o progresso do trabalho, até que o projeto seja completado. As iterações ágeis (chamadas de sprints em Scrum) não são miniaturas de cascatas; em processos ágeis, não existem etapas. Desenvolvimento ágil é um processo holístico, isso significa que teste, projeto, codificação e levantamento de requisitos são processos totalmente integrados e interdependentes. Teste, por exemplo, está dentro do processo de projeto. Requisitos não são simplesmente levantados; ao invés disso, um profundo e compartilhado conhecimento deles é cultivado pela constante comunicação entre o time o product owner e o cliente.www.hbueno.com Página 4
  5. 5. Mas como isso tudo funciona na prática? Como você faz desenvolvimento ágil? Independente da adoção de Scrum, Lean, eXtreme Programming, ou da sua combinação de metodologias ágeis, você irá: Testar durante o desenvolvimento, não apenas no final – um erro resolvido agora é mais barato que um que tem a chance de se propagar pelo sistema durante meses. Entregar o produto cedo e frequentemente – apenas demonstrando software que funciona ao cliente você conseguirá saber o que ele realmente quer. Como processos ágeis incluem constante feedback dos clientes, projetos permanecem relevantes e na trilha, e como cada incremento é uma entrega completa, desenvolvimento ágil funciona como mitigador de riscos: o projeto deve ser cancelado? Então o cliente pode continuar a usar o software até então entregue. Documentar durante o desenvolvimento, e apenas o necessário – quando você escreve documentação dentro do processo, você escreve apenas documentação que é relevante e útil. Construir times multifuncionais para quebrar barreiras – através de times funcionais nenhum indivíduo ou departamento pode se tornar gargalo no processo. A principal ideia atrás da abordagem ágil é entregar valor ao negócio imediatamente, na forma de software funcional, e continuar a entregar valor em incrementos regulares. Como nós iremos ver no próximo capítulo, os benefícios que um negócio pode obter trabalhando de forma iterativa são imediatos e cumulativos. 1.3. Os valores e princípios da metodologia ágil “É importante que um objetivo nunca seja definido em termos de atividade ou métodos. Ele deve sempre estar diretamente relacionado a como a vida é melhor para cada um.” W. Edwards Deming “Meu objetivo não é ensinar o método que todos devem seguir para conduzir bem suas justificativas, mas somente revelar como eu tentei conduzir minhas próprias.” René Descartes Não deixe que o tom idealístico do Manifesto Ágil faça você pensar que ele foi escrito por um grupo de sonhadores; os autores são veteranos do desenvolvimento de software, e eles basearam seus princípios em seus aprendizados no campo de batalha. Desta forma, os valores e os princípios concebidos pelos fundadores da Aliança Ágil permanecem firmes; todos os dias nós vemos como eles são aplicáveis em projetos de software do mundo real. Segue nas próximas seções uma discussão de cada valor e princípio que juntos formam o Manifesto Ágil. 1.3.1. Os valores da metodologia ágil Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratoswww.hbueno.com Página 5
  6. 6. Responder a mudanças mais que seguir um plano Como a maioria das coisas verdadeiras, os valores ágeis soam simples e óbvios quando você os ouve pela primeira vez, e eles permaneceram inalterados desde o dia que os fundadores da Aliança Ágil os publicaram pela primeira vez como parte do Manifesto Ágil. A filosofia ágil não está relacionada a “deve ser assim” ou verdades absolutas. Isso que torna o pensamento ágil tão poderoso e flexível. Não existe livro de regras a seguir ou referenciar, apenas valores e princípios a internalizar. Vamos analisar cada um dos valores ágeis de uma forma mais profunda: Indivíduos e interações mais que processos e ferramentas Um dos princípios básicos da agilidade é que pessoas que fazem o trabalho sabem a melhor forma de realizar o trabalho. Vamos supor que todos os seus seis times preferem criar estimativas jogando Planning Poker. Agora, quando você começa a trabalhar com um novo time, você os instruirá a usar Planning Poker? Se você está praticando uma metodologia de desenvolvimento ágil como Scrum ou eXtreme Programming, a resposta é um enfático não! Você deseja que cada time auto-organizável de indivíduos utilize as ferramentas que melhor funcionam para eles. Você irá sugerir que o novo time tente Planning Poker durante uma sprint ou duas, uma vez que funcionou tão bem para os outros times? Sim! É uma boa prática chegar a decisões como quais ferramentas utilizar através de tentativa e erro – o processo de inspecionar e adaptar. Mas pense sobre isso: você e seus times nunca irão saber se existe uma ferramenta melhor que Planning Poker se você proibir ou desencorajar experimentação. Existem ferramentas, metodologias e processos ágeis em abundância, e você deve experimentá-los em abundância. Processos e ferramentas devem servir as pessoas e não o contrário. Software em funcionamento mais que documentação abrangente Esta é outra questão sútil que convida a má interpretação. Documentação é boa quando é utilizada com o propósito de criar valor e mover o projeto para frente. Por exemplo, documentação para o usuário é uma parte valiosa da maioria dos produtos. Problemas aparecem quando o foco sai do produto e vai para o processo de documentação. Quando você inicia seu processo de desenvolvimento investindo pesadamente na documentação up-front (lembra da discussão sobre BDUF no método Cascata?), você sacrifica a oportunidade de inspecionar e adaptar através do aprendizado de seus erros e ajustando seus processos e requisitos conforme o projeto avança.www.hbueno.com Página 6
  7. 7. Uma má interpretação comum é que times ágeis não documentam ou planejam; mas na prática, times ágeis realmente gastam mais tempo e energia planejando e documentando do que os times tradicionais, porque o plano está sempre sendo elaborado e atualizado. Em um projeto de software ágil, o plano está ao seu redor, na forma de user stories, backlogs, testes de aceitação, e grandes e visíveis gráficos; eles todos são parte de seu rico ambiente de comunicação. Um plano ágil é uma coisa viva que se acumula e se desenvolve durante a vida do projeto. Então, onde o time ágil busca suas respostas, se não existe documentação? Você olha para o software que está funcionando: tudo que foi construído, testado e integrado até a data atual. Se você tem um software funcionando, testes automatizados, um backlog atualizado, e um product owner participativo, você tem tudo que você precisa para mover seu projeto para frente de uma forma eficiente e efetiva. Colaboração com o cliente mais que negociação de contratos Este valor ágil também tenta abolir o espectro do planejamento up-front, mas com ênfase em manter aberto o diálogo entre o time de desenvolvimento e o cliente. Nós sabemos que contratos são bons e necessários, especialmente quando eles protegem todas as partes. Muitos dos fundadores da Aliança Ágil eram consultores, assim eles eram familiares às armadilhas do trabalho com contratos, onde a proposta é geralmente nada mais do que uma aposta que eles conseguem concluir o trabalho em certa quantidade de tempo, com o lucro dependendo de quão rápido e barato eles conseguem entregar os requisitos mínimos do cliente. Os autores do Manifesto Ágil concluíram que projetos baseados em contratos enfatizam as coisas erradas. Eles preferem um modelo baseado em tempo e material onde todas as partes trabalham juntas como parceiras para construir o sistema com maior valor no tempo e custo definido. O risco do cliente é mitigado não por uma garantia up-front que põe o contrato em risco, mas pelo seu constante envolvimento no processo e pela habilidade do time ágil em entregar de forma regular incrementos do software que funciona. A eficiência criada ao se seguir um framework ágil, no qual software funcionando é entregue cedo e frequentemente, também garante que o cliente irá perceber um valor máximo para o tempo e dinheiro investido. Responder a mudanças mais que seguir um plano Organizações dirigidas por planos geralmente possuem processos de “controle de mudança” projetados com a melhor das intenções: para prevenir o projeto de sofrer atritos e inchaços. Um objetivo valioso! Maswww.hbueno.com Página 7
  8. 8. existe um obstáculo. Controle de mudança só pode funcionar no contexto onde mudança é realmente controlável. Em desenvolvimento de software, mudanças são inevitáveis e é por isso que os melhores processos são aqueles que consideram as mudanças como coisas boas para o projeto. Planejamento em um projeto de software deve ser fluido, não fixo, para o bem do time, mas principalmente para o bem do produto e finalmente para o bem do cliente. É por isso que você se planeja para mudança e muda seu plano. “Agilistas” amam apontar que enquanto métodos tradicionais de desenvolvimento de software são baseados em plano, projetos ágeis são baseados em planejamento. Ser ágil está relacionado a construção de um processo flexível que antecipa e abrange mudanças, permitindo o time se adaptar a novos requisitos e desenvolvimentos inesperados. Isto é agora um refrão familiar: inspecionar e adaptar. 1.3.2. Os princípios da metodologia ágil Os princípios ágeis podem ser vistos como uma maior elaboração e aplicação prática dos valores ágeis; eles são a outra metade do Manifesto Ágil. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. Se, como o relatório “Chaos” do Standish Group afirma, 20 a 30% dos projetos falham, e a maioria são executados significativamente acima dos custos, então qual era a “prioridade máxima” desses projetos? Você já trabalhou em um projeto onde a prioridade de fato era satisfazer um chefe excêntrico ao invés do cliente? Prioridade = políticas do escritório. Onde você tinha que trabalhar até mais tarde para produzir alguma coisa porque você teve que ir a reuniões obrigado? Prioridade = burocracia. Onde você sabia que a funcionalidade que você estava construindo nunca seria entregue, mas teve que manter sua cabeça baixa e construir de qualquer jeito? Prioridade = conformidade organizacional. Colocando o cliente em primeiro lugar e prometendo entregar valor continuamente, você introduz verificações e equilíbrio ao fluxo de entregas, e previne pessoas e organizações de escorregar para dentro de comportamentos que servem a organização e não ao cliente. Organizações que adotam métodos ágeis geralmente experimentam significativo crescimento de dores conforme esses tipos de prioridades mal compreendidas são extirpadas e expostas. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.www.hbueno.com Página 8
  9. 9. Uma de nossas estórias favoritas de tecnologia é de uma startup chamada Confinity, que teve um software chamado PayPal. Nos primeiros dias, o core do produto era um método de “empréstimo” de dinheiro entre Palm Pilots. Os fundadores imaginaram que indivíduos fossem utilizar esta tecnologia para tarefas como emprestar 20 bucks para outro ou dividir a conta do restaurante. Como uma segunda funcionalidade, eles adicionaram a habilidade de enviar pagamento por e-mail. Bem, esta segunda ideia se tornou a killer app, e os fundadores puderam reconhecer onde sua vantagem competitiva estava. Eles foram capazes de mudar os requisitos de seu produto radicalmente para tirar vantagem de uma grande oportunidade. Coisas acontecem: Tecnologias surgem rapidamente. Concorrentes trazem surpresas para o mercado. Panoramas regulatórios mudam. Recessões atingem as indústrias. Gênios fazem descobertas no meio da noite. Seu time não deve precisar chamar a Agência Federal de Gerenciamento de Emergências (FEMA – Federal Emergency Management Agency) para incorporar mudanças pequenas ou até grandes nos seus requisitos. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo. Hillary (um dos autores) uma vez participou de um evento chamado “Final de semana da Startup”, onde 200 empreendedores tecnológicos se juntaram em uma sexta-feira para ter ideias, então formaram pequenos times e trabalharam freneticamente por um período de 52 horas lançando companhias on-line no domingo. Este é um exemplo extremo do axioma: quanto menos tempo você tem, mais eficientemente você trabalhará. Os times do final de semana não tinham tempo para longas reuniões de planejamento. A maioria dos times começou a codificar depois de uma hora de formação, iniciando com as características mais essenciais de um site e projetando seus produtos assim que eles surgiam. Todas as 28 empresas formadas naquele final de semana apresentaram demos funcionando no domingo, e poucas lançaram aplicações web funcionando completamente. Tudo bem, este não é o método que você quer utilizar para construir um sistema de escalonamento para aviões, ou aplicações para bases de dados de serviços financeiros, mas o que times podem tirar deste exemplo é a lição que ciclos pequenos podem melhorar a eficiência do esforço. Muitos times pensam que a melhor forma para facilitar a entrada na agilidade é começar com longos ciclos de Sprint, mas o oposto é geralmente verdade. Um ciclo curto força você a focar no essencial e acabar com os hábitos de produtividade dos dias de cascata. Nada é melhor para reduzir o tempo de reuniões improdutivas do que saber que você tem que entregar software funcionando a cada sete dias!www.hbueno.com Página 9
  10. 10. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. Cada lado é conhecido por resistir ao outro. Pessoas do negócio fazem perguntas mal informadas e solicitam demandas idiotas, dizem os desenvolvedores. E por outro lado, pessoas do negócio veem os desenvolvedores como arrogantes, tipos excêntricos que se preocupam mais com a beleza da abstração dos seus códigos do que com o produto final. Bem, se as duas facções só se veem uma vez por mês, adivinhe o que acontecerá? Esses julgamentos serão verdadeiros! Colaboração regular permite que pessoas técnicas entendam e compartilhem a visão daqueles do negócio. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. Desenvolvimento de software não é um processo industrial, e os membros do time de desenvolvimento de software não são corpos intercambiáveis realizando tarefas roteadas em uma linha de montagem. Ainda que uma reclamação comum entre desenvolvedores seja que as empresas onde eles trabalham os tratem como “recursos humanos sem rosto”. Alguns desenvolvedores pesarosamente se descrevem como “macacos de código”. A boa nova é que a maioria dos times de desenvolvimento de software são compostos por seres humanos com grandes habilidades. Eles são especialistas com a capacidade de sentir paixão sobre seu trabalho. Dê a eles espaço e liberdade que eles precisam, e espere ótimos resultados de retorno. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face. Você já trabalhou em uma fazenda cúbica? Você sabe, um lugar onde cada um senta em um cubículo e se comunica com os outros através de texto e e- mail, mesmo quando eles estão em uma mesma sala? Times ágeis estão muito mais próximos de trabalhar em lugares abertos e compartilhados para comunicar verbalmente sempre que possível. Por quê? Porque agilidade é um affair da comunicação. Este princípio é algumas vezes mal interpretado por proponentes de métodos ágeis como se times distribuídos não pudessem ser ágeis. Mas perceba que o princípio apenas diz que face a face é melhor. Você pode praticar trabalho em grupos ágeis remotamente, mas você terá que ter uma atenção especial com os fluxos de comunicação. Software funcionando é a medida primária de progresso.www.hbueno.com Página 10
  11. 11. Esse princípio é simples o suficiente: a prova está no pudim. Não na lista da mercearia, não na receita. Não na grandeza do chefe da cozinha. Não na colher de prata que o preparou. Apenas o pudim. Você deve perceber que este princípio se relaciona diretamente ao princípio número 1 (“Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.”). Se suas prioridades estão corretamente alinhadas, então você produzirá software funcionando. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. Todos nós já experimentamos “tempos de crise” – a fase final de um projeto onde todos ficam até mais tarde e aparentemente vivos, dormindo e comendo no trabalho em um estado de produtividade ampliada; mas software houses são conhecidas por levar esta prática ao extremo. O que você não deve saber é que horas extremas de trabalho realmente reduzem produtividade ao invés de aumentar. Henry Ford escandalizou a indústria mundial quando introduziu a semana de 5 dias e o dia de 8 horas em 1926 – reduzindo de 8 dias e 10 horas. Ford falou a revista “Wold’s Work”, “O salário de uma semana cheia por um curto trabalho na semana irá pagar”. Contínua atenção a excelência técnica e bom design aumenta a agilidade. Agilidade não é sobre cortar caminho para ir mais rápido. Qualquer um que tenha trabalhado em um projeto baseado em código legado irá atestar o fato de que o progresso é lento quando aqueles que vieram antes utilizaram atalhos. Por outro lado, quando o time dá atenção ao projeto, arquitetura, teste, e limpeza do código, é muito mais fácil fazer mudanças. Isto aumenta a habilidade do time de entregar valor rapidamente. Alguns acreditam que times ágeis não fazem projeto alto nível da arquitetura. Isso não é verdade! Um time ágil faz isso o tempo todo. Quando o time faz uma mudança, eles inspecionam e adaptam sua arquitetura, projeto, documentação técnica, teste de cobertura, etc. Ao longo do curso do projeto um time ágil faz mais estas atividades do que times tradicionais, mas eles fazem isso no tempo. Dessa forma, a arquitetura está sempre apropriada para o estado atual do código, nem tanto, nem tão pouco. Membros de times ágeis estão sempre aumentando suas habilidades técnicas porque eles aprendem uns com os outros. O tempo investido aprendendo sobre desenvolvimento direcionado a teste, padrões de projeto, e práticas do estado da arte são recompensados pela vida do projeto.www.hbueno.com Página 11
  12. 12. Simplicidade--a arte de maximizar a quantidade de trabalho não realizado--é essencial. O estudo “Chaos” sobre projetos de software do Standish Group diz que 45% das funcionalidades de um software nunca são usadas. Apenas 7% são sempre usadas, e outros 13% são geralmente usadas. Quando você faz “big design up front”, você só tem uma chance, no começo do projeto para especificar tudo que você irá desejar no projeto, desde o necessário – um menu, uma página de login, um banco de dados – até as coisas mais supérfluas, como um pop-up ou uma figura animada. Em projeto ágeis, você constrói os requisitos mais importantes primeiro, e os outros menos importantes são atacados depois. Características que parecem ser supérfluo ou idiotas saem do backlog naturalmente. As melhores arquiteturas, requisitos e designs emergem de equipes auto- organizáveis. O argumento comum a favor daqueles que dizem que arquitetura deve ficar com os arquitetos é que é preciso um especialista com visão para criar uma coisa elegante. Como a piada: “O que é um camelo? É um cavalo projetado por um comitê”. Mas existem 2 falhas neste raciocínio. Primeiro: existe um mundo de diferenças entre um time e um comitê. Um time é um grupo de indivíduos com habilidades funcionando de forma sincronizada para alcançar um objetivo comum. Um comitê ... bem, um comitê é um grupo de pessoas que não tem nada melhor a fazer do que sentar em um comitê. O Chicago Bulls era um time. A segunda suposição falsa é que software é “uma coisa”. O objetivo de um projeto de software nunca é fazer “uma coisa”, mas construir um sistema que resolve um problema. E resolver problemas é uma tarefa em que equipes superam até indivíduos muito talentosos. Você pode ter um arquiteto brilhante em seu time ágil, mas em um time scrum, ele não é “O arquiteto”. O time irá valorizar seu conhecimento como um recurso importante e geralmente solicitar ajuda. O arquiteto terá suas digitais por todo o projeto mas não será “o responsável pela arquitetura”. O time compartilha esta responsabilidade de forma igual. Na prática, isso significa que eles são responsáveis por cooperar um com o outro e colocar o projeto em primeiro lugar. Times auto-organizáveis não deixam de ter contribuições individuais; a única coisa que eles deixam para trás são os egos. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo. Indivíduos, times e organizações tem um traço em comum: eles são suscetíveis a cair em maus hábitos e cair em buracos. E assim são oswww.hbueno.com Página 12
  13. 13. humanos, e se há um consolo, eles também podem cair em bons hábitos. A maior parte de um processo ágil – alguns dizem que a parte mais importante – é inspecionar e adaptar em intervalos regulares, amplificando o que funciona e consertando o que não funcionou. Uma ferramenta poderosa para acompanhar este ajuste fino é a retrospectiva, uma atividade focada em aprender a partir do que aconteceu e aplicar este aprendizado diretamente para fazer coisas melhores para frente. Retrospectivas são úteis entre iterações, entre releases, e após incidentes incomuns. A retrospectiva ágil é muito mais poderosa do que parece em um primeiro momento. Alguns times que são novos no processo ágil acreditam que podem ganhar tempo fugindo da retrospectiva. Não! Na realidade, nós nos arriscamos a dizer que se fosse para fazer apenas um passo rumo à agilidade, você deveria incluir a retrospectiva no seu fluxo de trabalho. Nada irá provar o valor do desenvolvimento iterativo mais rápido que perceber os grandes benefícios obtidos por regularmente inspecionar e melhorar a forma de trabalho.2. Scrum 2.1. Uma breve história do Scrum “Scrum: um framework baseado no time para desenvolver sistemas e produtos complexos” A Aliança Scrum “Scrum, como definido, na realidade não diz nada sobre software. Scrum é sobre gerenciamento de trabalho e dinâmicas de times que podem ser usadas em projetos que não são de software” Jeff McKenna O primeiro time Scrum foi formado em 1993, quando Jeff Sutherland, na época vice-presidente na Easel Corporation, estava inspirado para utilizar uma nova abordagem para um projeto de software crítico. O time que ajudou a desenvolver a nova metodologia, incluía Jeff McKenna, então um consultor de orientação a objetos, e John Scumniotales, para o qual a Easel era o primeiro trabalho de desenvolvimento fora da universidade. Os 3 viriam a ser membros fundadores do Manifesto Ágil. Enquanto isso, Ken Schwaber, CEO da empresa Advanced Development Methods Inc, estava experimentando uma “quebra de produtividade” através do uso de um processo empírico (inspecionar e adaptar), ao invés de processos definidos (planejar e executar). Sutherland e Schwaber eram colaboradores antigos e conhecedores dos seus trabalhos, Scrum nasceu quando eles colaborativamente trabalharam em um artigo em 1995 para uma conferência chamada Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) que formalizou e tornou público o framework Scrum. 2.2. Os papéis no Scrumwww.hbueno.com Página 13
  14. 14. “Amor é a força inflama o espírito e amarra times juntos” Phil Jackson “Talento vence jogos, mas trabalho em equipe e inteligência vencem campeonatos” Michael Jordan Times Scrum incluem indivíduos de diferentes domínios tradicionais que chegam com diferentes títulos como: arquiteto, analista de negócios, desenvolvedor de software, testador, especialista em documentação, líder de produto, líder de projeto, chefe lavador de garrafas, etc. Um time Scrum precisa de todos esses perfis, mas Scrum reconhece apenas 3 perfis distintos: product owner, scrum master e team member. 2.2.1. O papel do Product Owner Um time de desenvolvimento representa um investimento significativo nos negócios. Existem salários a serem pagos, escritórios a alugar, computadores e softwares a comprar e manter, etc. O negócio investe esse dinheiro no time porque espera um bom retorno, melhor do que ele poderia obter investindo no banco. O product owner é responsável por maximizar o retorno que o negócio terá com o investimento. Um product owner faz isso direcionando o time para o trabalho de maior valor. Isto é, o product owner controla a priorização dos itens do backlog. Em Scrum, ninguém além do product owner está autorizado a dizer para o time trabalhar ou alterar a prioridade dos itens do backlog. Isso necessariamente significa que o product owner irá trabalhar perto dos stakeholders para determinar o que precisa ser feito, e quando, para entregar o maior valor ao negócio. Provavelmente alguns stakeholders irão voltar aos hábitos e ir diretamente nos membros da equipe para tentar resolver pendências mais rapidamente. Membros do time devem aprender a redirecionar essas requisições de forma diplomática: “Isso parece importante, você deveria levar para o nosso product owner”. O product owner deve garantir que as necessidades do cliente e dos usuários finais estão bem compreendidas pelo time. O product owner deve fazer isso diretamente criando, refinando e comunicando requisitos. É a responsabilidade do product owner garantir que os requisitos estão disponíveis e entendidos pelo time. Isso significa que ele deverá estar disponível para o time, para responder várias questões que irão aparecer durante os sprints. O product owner é o guardador da visão do produto. Essa visão diz para quem o produto está sendo desenvolvido, porque ele é necessário, e como ele será usado. Ele informa todas as decisões que devem ser tomadas para o produto se tornar uma realidade.www.hbueno.com Página 14
  15. 15. Isso parece ser um grande trabalho ... bem ... e é! Na nossa experiência, este é o perfil que mais é demandado em um time Scrum. Existe uma tensão natural entre o product owner e o resto do time; o product owner sempre quer mais, e o time deve defender seu ritmo sustentável. Essa tensão é saudável, desde que nenhum dos lados seja dominante. 2.2.1.1. O papel do Product Owner resumido Tem a visão do produto Representa o negócio Representa o cliente Mantem o product backlog Prioriza estórias Cria critérios de aceitação das estórias Está disponível para responder perguntas dos membros do time 2.2.2. O papel do Scrum Master O Scrum Master atua como um técnico, guiando o time para níveis cada vez mais altos de coesão, auto-organização, e desempenho. Enquanto o entregável do time é o produto, o entregável do Scrum Master é a auto- organização do time. O Scrum Master é o guardião, facilitador e scrum expert. Ele não é o chefe. Certamente ele tem uma espécie de liderança no time, mas é estritamente por influência, não autoridade ou posição de poder. O Scrum Master é o expert em Scrum e auxilia o time a tirar o maior valor do Scrum, realizando várias funções: facilitando Scrum meetings, auxiliando o time a entender os artefatos do Scrum, auxiliando os demais membros da equipe, inclusive o product owner, a entender melhor seus papéis no time Scrum. Um outro papel importante do scrum master é remover impedimentos para o time. Por exemplo, um membro do time está bloqueado esperando o administrador de banco de dados aprovar uma mudança, o scrum master deverá escalar o problema para resovê-lo. O Scrum Master trabalha para auxiliar o time a ver o problema, e o encoraja para encontrar uma solução. É possível que um Scrum Master também atue executando tarefas. Essa situação é as vezes chamada de Working Scrum Master. Existem alguns problemas em relação a isso. Por exemplo, quando deadlines se aproximam, um Working Scrum Master pode focar em seus entregáveis quando na verdade teria mais valor auxiliando o time. 2.2.2.1. O papel do Scrum Master resumido Especialista em Scrum e assessor Treinador Escavadeira de impedimentoswww.hbueno.com Página 15
  16. 16. Facilitador 2.2.3. O papel do membro do time Times Scrum são altamente colaborativos; eles também são auto- organizáveis. Membros do time têm total autoridade sobre como o trabalho será feito. O time decide sozinho quais ferramentas e técnicas serão usadas, e quem trabalhará em qual tarefa. A teoria é que as pessoas que fazem o trabalho são as maiores autoridades para melhor fazer isso. Os membros da equipe também são os responsáveis em estimar o custo de cada nova funcionalidade a ser implementada. O product owner irá escolher a ordem das estórias, mas apenas os desenvolvedores podem dizer qual a duração de cada tarefa. Então, quantos membros um time Scrum deve ter? É regra básica é 7, com mais ou menos 2. Times pequenos não terão diferentes perfis para auxiliar na execução das tarefas das estórias. Por outro lado, o overhead de comunicação de times grandes é elevado. 2.2.3.1. “O time Scrum” vs “O time” Os primeiros escritores de scrum faziam distinção entre “Scrum Team” e “Team”. Ken Schwaber’s Scrum Guide, por exemplo, utilizava o termo Scrum Team especificamente para indicar scrum master, product owner, e os membros da equipe; enquanto o Team era referenciado como todos exceto o scrum master e o product owner. 2.2.3.2. O papel do membro do time resumido Responsável por entregar user stories Faz todo o trabalho de desenvolvimento Se auto-organiza para entregar user stories Responsável pelo processo de estimativa Responsável por tomar decisões de “como realizar o trabalho” Reduz “isso não é meu trabalho” 2.2.3.3. A parábola do porco e da galinha 2.3. O Sprintwww.hbueno.com Página 16
  17. 17. O ciclo Sprint é o ritmo fundamental do processo Scrum, mas o conceito não é exclusivo do Scrum. Métodos ágeis compartilham a abordagem iterativa para a execução de trabalho. Independente se você chama seu período de desenvolvimento de Sprint, ciclo ou iteração, você está falando da mesma coisa: um processo onde você morde pequenos pedaços do seu projeto e os conclui antes de começar a morder outros mais. No final do seu Sprint, você demonstrará software funcionando. Scrum não tem tamanho específico para sprints, mas 4 semanas é geralmente considerado o máximo e o mais comum é 2 semanas. A tabela abaixo mostra as várias reuniões que devem ser escalonadas durante uma Sprint de uma semana. Muitos autores chamam as reuniões de cerimônias. 2.3.1. Sprint Planning Meeting A reunião Sprint Planning marca o começo da sprint. Comumente, esta reunião tem duas partes. O objetivo da primeira é para o time se comprometer com um conjunto de entregáveis para o Sprint. Durante a segunda parte da reunião, o time identifica as tarefas que devem ser completadas para realizar a entrega das estórias acordadas. É recomendado uma ou duas horas para esta reunião com sprints de 1 semana de desenvolvimento, enquanto 4 horas de reunião para um Sprint de 4 semanas. 2.3.1.1. Parte um: “O que nós faremos?”www.hbueno.com Página 17
  18. 18. A meta desta parte da reunião é levantar um conjunto de estórias que todos acreditam que serão entregues no final da Sprint. O product owner lidera esta parte da reunião. Em ordem de prioridade, o product owner apresenta as estórias que ele gostaria que fossem completadas na Sprint. O membros do time discutem cada estória com o product owner, e revisam o critério de aceitação para ter certeza que eles tiveram o mesmo entendimento. Os membros do time conversam para conferir dependências entre estórias. Por fim, o membros do time discutem se eles podem considerar uma estória entregável para aquele Sprint. Este processo é repetido para cada estória, até que o time sinta que eles não podem se comprometer mais com nenhum trabalho. Perceba a separação da autoridade: o product owner decide quais estórias serão consideradas, mas é o time que decide quanto trabalho será entregue no final da Sprint. 2.3.1.2. Parte dois: “Como nós faremos?” Na fase dois da reunião, o time arregaça as mangas e começa a decompor as estórias selecionadas em tarefas. Lembre que estórias são entregáveis: coisas que stakeholders, usuários e consumidores querem. Para entregar uma estória, o time precisará completar tarefas. Exemplos de tarefas: pegar mais informações com usuários; projetar uma nova tela; adicionar novas colunas em uma tabela do banco de dados; fazer teste de caixa preta de uma nova funcionalidade; escrever um texto de ajuda; traduzir os itens de um menu para o arquivo de locale; rodar os scripts para gerar um novo release, etc. O product owner deve estar disponível durante esse processo para responder perguntas. O time deve também ajustar a lista de estórias que ele está comprometido, uma vez que durante o processo de identificação das tarefas o time poderá perceber que se comprometeu com muitas ou poucas estórias. Se isso acontecer, o time deverá entrar em negociação com o product owner. Como o time faz o melhor esforço para identificar todas as tarefas necessárias, é irreal acreditar que a lista de tarefas estará completa. Uma vez iniciado o trabalho, novas tarefas surgirão. É esperado que um time de alto desempenho identifique 60% a 70% das tarefas durante a reunião. Alguns times colocam tamanhos para as tarefas. A razão é auxiliar no escalonamento das tarefas durante a Sprint, especificamente quando o time precisa alertar o product owner se há perigo de não entregar alguma estória conforme o acordado. Adicionalmente, tarefas com estimativas muito grandes deve ser quebradas, uma vez que quanto maior a tarefa menos entendimento dela se tem. Uma regra é que qualquer tarefa que tenha tamanho de mais que meio dia pode ser quebrada em tarefas menores.www.hbueno.com Página 18
  19. 19. Como estimar tarefas: Quais unidades utilizar? Existem 3 estratégias comuns: horas, pontos e quantidade. Para a primeira, o time define uma quantidade de horas necessária para concluir cada tarefa. Essa estratégia é um problema porque naturalmente as pessoas tem dificuldades de estimar. Alguns times associam pontos às tarefas. Esse processo é chamado de “Planning Poker”, e é descrito no capítulo dez. Por fim, a forma mais simples é contar quantas tarefas existem. Essa estratégia tem a vantagem de ser a mais simples e a desvantagem de não alertar problemas de prazo quando restam poucas tarefas mas bem grandes. Qual estratégia deve ser utilizada? A decisão é do time. Lembre que, o objetivo é alertar o mais cedo possível quando acredita-se que não será possível entregar as estórias comprometidas. Nós falamos muito sobre os compromissos que o time assume, mas o product owner também assume compromissos. Ele se compromete a não adicionar novas estórias às sprints, a menos que o time solicite; a estar disponível para esclarecer dúvidas; e ser um guia até que as estórias estejam aceitáveis e possam ser consideradas completas. 2.3.2. Daily Scrum A daily scrum, muitas vezes chamada de stand-up meeting é: Diária: muitos times optam por realizar a reunião na parte da manhã. Outros optam por realizar no meio do dia. Encontre um horário que funcione para seu time todos os dias. Pequena: apenas membros da equipe de desenvolvimento participam, tantas pessoas quantas couberem em um pequeno círculo em pé. Breve: esta reunião não pode ser utilizada para resolver problemas grandes, mas apenas para deixar as linhas de comunicação abertas. Esta reunião não pode durar mais que 15 minutos. Objetiva: todos os participantes rapidamente compartilham: “o que eu realizei desde a última reunião diária”, “o que eu espero realizar até a próxima reunião diária” e “quais obstáculos estão me atrapalhando”. 2.3.3. Story Time Esta reunião não é geralmente conhecida como parte do scrum, mas é uma boa maneira de realizar a preparação do backlog.www.hbueno.com Página 19
  20. 20. Algumas pessoas simplesmente chamam esta reunião de Backlog grooming. Nesta reunião você irá trabalhar com próximas estórias, e não com estórias do Sprint atual. Nós recomendamos uma por semana, independente do tamanho do Sprint. Você irá definir tamanhos para as estórias que ainda não foram priorizadas. Você também irá quebrar estórias grandes em menores. O objetivo é ter uma coleção de pequenas e bem compreendidas estórias no topo do backlog. 2.3.4. Sprint Review É recomendado que esta reunião dure no máximo 1 hora para cada semana de desenvolvimento. É uma boa prática convidar todos os envolvidos para ela. O time relata quais estórias não foram concluídas, e demonstra aquelas que foram. A reunião de revisão deve ser um exercício de aprendizado para todos. 2.3.5. Retrospectiva Scrum foi projetado para ajudar times a inspecionar e adaptar continuamente, resultando em evolução do desempenho e felicidade. A retrospectiva, feita ao fim de cada Sprint, é dedicada para o time focar no que foi aprendido durante a Sprint, e como o aprendizado pode ser aplicado para trazer melhoria. Nós recomendamos uma ou duas horas para cada semana de desenvolvimento. A retrospectiva permite que o aprendizado e insights sejam capturados enquanto as experiências estão frescas e antes que padrões negativos tenham chance de tomarem o local. O objetivo é simples: identificar um ou talvez duas coisas específicas a melhorar, e criar um plano de ação para implementar as mudanças. Algumas pessoas novas no scrum já experimentaram sessões tradicionais de lições aprendidas. Essas ocorrem no fim de um longo projeto, e geralmente geral longas listas que são esquecidas tão cedo quanto o fim da reunião. 2.3.6. Sprints com finais anormais: quando bons sprints vão mal Em Scrum, o acordo básico entre o time e a gestão é que a gestão não irá alterar os requisitos durante uma Sprint. Em geral, isso funciona bem para todos os envolvidos. Entretanto, pode ocorrer algo que invalide tudo dentro de uma Sprint. Nesses casos raros, o product owner pode propor um final anormal de Sprint. Mesmo quando uma Sprint acaba cedo, você deverá ter um review da Sprint se tiverem estórias completas e podem ser entregues.www.hbueno.com Página 20
  21. 21. 2.3.7. Inspecione e adapte, baby Então, porque nós fazemos desenvolvimento de software em ciclos curtos? Para aprender. Experiência é o melhor professor, e o ciclo do Scrum é projetado para fornecer múltiplas oportunidades para você receber feedbacks, de clientes, do time, do mercado, e aprender com isso. O que você aprender durante a execução de um ciclo auxilia no planejamento do próximo ciclo. O Sprint tem 3 ciclos formais de inspecionar e adaptar: a reunião diária, o Sprint review e a retrospectiva. 2.4. Artefatos do Scrum Essas são as ferramentas que os praticantes de Scrum usam para tornar o processo visível. Backlogs e burn charts fazem parte do Scrum desde o começo. Nós incluímos outros dois: o quadro de tarefas e a definição de feito. 2.4.1. O Product Backlog O product backlog é a lista acumulada de entregáveis desejados para o produto. Ele inclui características, correção de bugs, mudanças na documentação, e tudo mais que tiver significado e valor para produzir. Enquanto o termo item de backlog está tecnicamente correto, vários times Scrum preferem usar o termo “user story” ou simplesmente “story”. Os itens no topo do backlog tendem a ser pequenos e bem definidos. Isso é bom, uma vez que essas estórias serão implementadas logo. Mais abaixo do backlog, as estórias devem ser maiores e um pouco menos definidas. O product owner é o dono do backlog. Apenas ele pode adicionar, subtrair ou priorizar itens de um backlog, ainda que isso seja feito com a colaboração dos stakeholders. Como um artefato, um backlog deve existir como uma lista na parede, uma planilha, ou algo do tipo. 2.4.2. O Sprint Backlog O Sprint backlog é a lista de tarefas a fazer do time em um Sprint. Diferentemente do product backlog, ele tem um tempo de vida para ser concluído: a duração do Sprint. O Sprint backlog é gerado durante o planejamento do Sprint, e uma vez que a reunião acabou, o product owner não poderá alterar a lista de estórias do Sprint. Em Scrum, essa é a diferença fundamental entre o negócio e o time de desenvolvimento: o negócio pode mudar a direção no começo de cada Sprint, mas uma vez iniciado o Sprint o time é autorizado a focar na entrega das estórias que eles se comprometeram.www.hbueno.com Página 21
  22. 22. 2.4.3. Radiadores de informação Andando na área de trabalho de um time Scrum você irá encontrar as paredes cobertas de gráficos desenhados a mão e um quadro cheio de notas indicando o que foi deixado para fazer, está sendo feito ou foi feito. Essas ferramentas de baixa tecnologia são chamadas de radiadores de informação. 2.4.4. Burn Charts Um gráfico burn down descreve o trabalho deixado para ser feito ao longo do tempo. Ele plota o trabalho restante ao longo do eixo vertical e o tempo no eixo horizontal. Em geral, nós esperamos que o trabalho restante diminua ao longo do tempo conforme o time vai concluindo as tarefas. Algumas vezes o trabalho restante altera repentinamente, quando o escopo de mudanças causa um lote de tarefas a ser adicionado ou removido. Esses eventos aparecem como linhas verticais no gráfico burn down. Existem outros tipos de gráficos burn down que nós comumente usamos no Scrum: release burn down, e o Sprint burn down. Alguns times também usam um gráfico burn up. 2.4.5. Burn down chart da versãowww.hbueno.com Página 22
  23. 23. Essa é a ferramenta que o product owner utiliza para acompanhar o trabalho restante ao longo do tempo. Os incrementos de tempo plotados no gráfico são Sprints. Conforme você avança para uma release, você quer ver a linha de trabalho restante diminuir. Acompanhar essa linha reduzir e deixá-la visível é uma boa forma de deixar seus stakeholders cientes dos efeitos que a imposição da adição de requisitos adicionais têm no progresso do trabalho até uma release. Isso também pode ajudar um time reconhecer problemas com sua produtividade. 2.4.6. Burn down chart da Sprint Este gráfico mostra o restante do trabalho que ainda existe para ser feito na sprint. Conforme as tarefas são adicionadas ou completadas, os membros do time atualizam o gráfico, indicando quanto trabalho ainda falta. A quantidade de trabalho pode ser expressa por horas, pontos ou quantidade. O propósito deste gráfico é deixar claro para o time se eles estão próximos a meta de entregar tudo que foi combinado para o Sprint. Uma característica interessante deste gráfico é que a linha sempre aumenta no começo da Sprint. O que está acontecendo? Enquanto o time está fazendo o trabalho inicial, eles estão descobrindo novas tarefas que precisam ser feitas. Isso é normal. Conforme essas tarefas são descobertas, elas são dimensionadas e incluídas ao backlog do Sprint. 2.4.7. Burn up chart A velocidade do time é o número de unidades de trabalho concluídos por Sprint. Um gráfico burn up plota pontos concluídos ao longo do tempo, e é um indicador visual da velocidade do time. Trabalho feito é representado no eixo vertical, e o tempo é representado no horizontal. Dessa forma, você consegue ver seu progresso em uma linha que sobe da esquerda para direita.www.hbueno.com Página 23
  24. 24. 2.4.8. Quadro de tarefas Um quadro de tarefas é um irradiador de informação: ele serve para manter todos constantemente atualizados por osmose. Quando suas tarefas estão visíveis a todos da sala, você nunca precisa procura-las, tudo que você precisa fazer é virar a cabeça. O quadro de tarefas mais simples consiste de 3 colunas: a fazer, fazendo e feito. Após concluir seu Sprint backlog durante o planejamento, você irá escrever suas tarefas em tickets e colocá-los na coluna a fazer. Agora, conforme as tarefas são concluídas, você precisa movê-las para as outras colunas. Uma variação simples do quadro básico é a inclusão de uma quarta coluna chamada relatado. Durante a reunião diária, após informar o que fez em um ticket done, o empregado move o ticket para relatado. Isso ajuda a comunicação das tarefas concluídas.www.hbueno.com Página 24
  25. 25. Outra variação comum é dividir o quadro em raias horizontais. Cada estória fica em sua própria raia e as tarefas associadas a esta estória ficam na mesma raia. Outros times incluem colunas adicionais como: codificando, testando ou esperando aprovação. Você também pode incluir uma coluna com o backlog. Ele mostra funcionalidades futuras que o time pode começar a trabalhar caso ele já tenha concluído tudo que estava priorizado para o Sprint. 2.4.9. Definição de feito “Fazer nada é muito difícil de fazer... você nunca sabe quando você acabou” Leslie Nielsen Todo time deve gastar um tempo antes do início de um projeto para colaborar com a definição de “feito”. Essa definição deve ser escrita em um lugar muito visível. Scrum atribui grande importância ao conceito do time produzir produtos entregáveis em cada Sprint. Na prática, vários times Scrum definem uma funcionalidade como feita quando é potencialmente entregável; uma vez que não é sempre prático realmente entregar funcionalidades que foram concluídas, faz sentido estabelecer uma série de critérios de conclusão que demonstrem que uma funcionalidade está pronta para ser entregue. Ken Schwaber sugere que uma definição de “concluído” deve conter: code review, design review, refactoring, teste de desempenho, testes de unidade e possivelmente muito mais. 2.5. User storieswww.hbueno.com Página 25
  26. 26. “Computadores tornam mais fácil fazer várias coisas, mas a maioria das coisas que eles tornam mais fácil fazer não precisam ser feitas” Andy Rooney User stories são os blocos de construção do product backlog. Combinado com conversas e critérios de aceitação, eles são uma forma eficiente e efetiva para os product owners fornecerem requisitos para o time. User stories são geralmente escritas manualmente em cartões, embora alguns times optem por ferramentas de software para gravá-los. Muitos times utilizam um formato popular e particular para um user story. Segue um modelo: As a <type of user> I want <to do something> So that <some value is created> 2.5.1. Variações do tema O formato acima coloca o foco no usuário; eles são listados primeiro. Alguns times preferem mover o foco para o objetivo ou valor, então eles mudam a ordem para isso. Foco no objetivo In order to <achieve some goal> As a <type of user> I want <to do something> Foco no valor In order to <create some value> As a <type of user> I want <to do something> 2.5.2. A user story é um ticket para uma conversa User stories não são requisitos completos ou especificações; eles são espaços reservados. Eles contem informação suficiente para lembrar o time que existe algo a ser feito, mas nós intencionalmente não entramos no detalhe... até que necessário. Quando o time vai elaborar uma user story, nós preferimos fazer isso na forma de uma conversa entre os membros do time envolvidos. O objetivo da conversa é chegar a um entendimento único sobre o que a estória trata, e exatamente o que precisa ser feito. 2.5.3. Critério de aceitação torna real Quando você chega ao ponto de uma conversa onde todos pensam que chegaram a um entendimento comum de uma estória, é hora de escrever um critério de aceitação. Gere uma lista de testes aprovado/reprovado,www.hbueno.com Página 26
  27. 27. então todos os envolvidos na conversa irão concordar que a estória é implementada como se pretende. Critérios de aceitação respondem a pergunta: “Quando nós iremos saber quando isso faz o que deveria fazer?”. 2.5.4. Colocando tudo junto O user story, a conversa, e o critério de aceitação combinam para preencher uma especificação de requisitos completa. O user story nos permite rapidamente capturar ideias. Em conversas nós podemos elaborar a ideia e chegar a uma compreensão do que realmente é necessário. Finalmente, nós capturamos nossa compreensão comum em critérios de aceitação que são específicos e testáveis. 2.6. Estimando o trabalho através do tamanho das estórias Bem vindo às Ilhas Ágeis! Responda rápido: “quanto tempo se leva para ir de Fowler a Beck?”. É uma resposta difícil, ainda mais quando não se sabe o meio de transporte. Outra pergunta: “Quanto tempo se leva para ir de Beck a Jeffries?”. Ainda temos o mesmo problema. A questão é que não podemos definir o tempo das viagens sem mais informações, entretanto, podemos dizer que a segunda viagem é aproximadamente dois terços da primeira. Isso é definir estimativas relativas. 2.6.1. Por que estimar? O objetivo real de estimar é fornecer alguma medida de previsibilidade do escalonamento. Saber o tamanho das tarefas auxilia na tomada de decisões do negócio. Esse é o objetivo de criar estimativas: informar as decisões de negócio, que em última análise cria mais valor. 2.6.2. Tamanhos relativos vs Estimativa de tempo A estratégia tradicional de estimar é perguntar aos desenvolvedores quanto tampo levará uma tarefa. Existem dois problemas com esta abordagem: eles realmente não sabem quanto tempo levará e eles irão te dar uma resposta de qualquer jeito.www.hbueno.com Página 27
  28. 28. Enquanto seres humanos são ruins para estimar durações, eles são bons para comparar coisas e falar qual é a maior. Isso significa que somos ruins em tamanho absoluto, mas bons em tamanhos relativos. Assim, o importante é lembrar que times atribuem tamanhos a suas estórias, usando story points como unidade. Em resumo, um story point é uma unidade relativa de medida para uma quantidade de trabalho necessário para completar uma user story. Segundo, o time trabalha durante uma Sprint e conclui algumas estórias. Agora eles podem expressar a taxa que eles concluem trabalho como a quantidade de pontos por Sprint. Isso é chamado de velocidade do time. Sua velocidade é simplesmente a média de story points completados por Sprint. 2.6.3. Números de Fibonacci Números de Fibonacci são usados para estimar tamanhos de estórias. Em termos mais simples, a sequencia de Fibonacci é a série de inteiros onde cada número é igual a soma dos dois números anteriores: 1, 2, 3, 5, 8, 13, 21, 34, 55, etc. Fibonacci observou que esta sequência ocorria frequentemente na natureza, por exemplo, no crescimento da população de coelhos, ramos de uma árvore, etc. O que importa para nós, é que os números de Fibonacci, quando usados para representar tamanho, crescem na mesma taxa em que humanos são capazes de facilmente perceber diferenças. Abaixo temos cards típicos utilizados nas reuniões story time. 2.6.4. Planning poker Planning poker é jogo de estimativa projetado por James Grennning em 2002. Ficou popular em 2005 por Mike Cohn no livro “Agile Estimating and Planning”. Planning poker é um jogo estruturado usado para alcançar o consenso do grupo no processo de estimativa de tarefas. No início do jogo cada membro do time tem um deck de cartas Fibonacci na mão. O scrum máster lê a estória em voz alta. Cada membro do time escolhe uma carta para melhor representar seu chute de dificuldade dawww.hbueno.com Página 28
  29. 29. tarefa, e todos mostram suas escolhas ao mesmo tempo. Se todos estimarem a mesma coisa, você está feito, não há necessidade de discussão. Caso contrário, as pessoas que colocaram a maior e menor cartas explicam porque fizeram isso e a jogada é repetida. Se as novas estimativas forem iguais, ok. Caso sejam estimativas diferentes novamente, as pessoas com as cartas maior e menor tentarão convencer o resto da equipe. Se ainda assim, não houver acordo, uma nova rodada acontece e assim sucessivamente. Na prática, estimativas rapidamente convergem através de rounds de discussões estruturadas. 2.6.5. Velocidade Uma vez que o time completou uma ou duas sprints, você terá uma ideia de quantos story points você pode atacar durante um Sprint. Essa taxa é conhecida como velocidade do time. O product owner utiliza a velocidade do time para ajudá-lo na escolha de estórias para a próxima Sprint. A velocidade nunca deve ser usada como métrica de desempenho: a questão não é sobre demonstrar ao gerente que você está trabalhando rápido, mas ter previsibilidade do escalonamento para produzir mais valor.www.hbueno.com Página 29

×