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

Tradução resumida do livro
“The Elements of Scrum”
Chris Sims e Hillary Louise Johnson

Henrique Bueno
riquebueno@gmail.com

Versão 2

www.hbueno.com Página 1

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.


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

Mais conteúdo relacionado

Mais procurados

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

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