tradução resumida do livro "the elements of scrum"

www.hbueno.com Página 1

Tradução resumida do livro

“The Elements of Scrum” Chris Sims e Hillary Louise Johnson

Henrique Bueno

[email protected]

Versão 2

mailto:[email protected]


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.


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.

http://www.agilealliance.org/


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


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 contratos


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.


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! Mas


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.


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!


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.


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.


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 os


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 Scrum


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


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 impedimentos


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 Sprint


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


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.


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.


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.


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.


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ão


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.


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.


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 stories


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


Foco no valor

In order to <create some value>

As a <type of user>


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,


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.


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 da


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.

tradução resumida do livro "the elements of scrum"

Documents

adiantada

precisa ser

lista de estrias

levantamento

definio de

desenvolvimento

por outro

final da sprint