Escolar Documentos
Profissional Documentos
Cultura Documentos
ScrumeXPDiretodasTrincheiras PDF
ScrumeXPDiretodasTrincheiras PDF
Escrito Por:
Henrik Kniberg
Dedicatria
O primeiro rascunho desse livro demorou apenas um final de semana para
ser digitado, mas com certeza foi um final de semana intenso! Fator de
foco de 150% :o)
Obrigado minha esposa Sophia e aos meus filhos Dave e Jenny por
agentar minha falta de sociabilidade naquele fim de semana. E obrigado
tambm aos pais de Sophia, Eva e Jrgen por virem ajudar a tomar conta
da famlia.
Obrigado tambm aos meus colegas da Crisp, em Estocolmo, e s pessoas
do grupo de discusso do yahoo scrumdevelopment por revisarem e me
ajudarem a melhorar este trabalho.
E, finalmente, obrigado a todos os leitores que forneceram um canal
constante de feedback bastante til. Eu estou particularmente satisfeito
por ouvir que esse trabalho tem impactado tantos de vocs a ponto de
darem uma chance ao desenvolvimento gil de software.
Contedo
3
PREFCIO POR JEFF SUTHERLAND
PREFCIO POR MIKE COHN
I
III
INTRODUO
Termo de Responsabilidade
Porque eu escrevi isso
Mas o que Scrum?
6
7
7
8
9
11
12
13
15
15
17
18
19
20
21
22
23
25
33
34
36
37
38
39
39
40
43
44
45
46
46
48
48
49
50
51
52
52
53
53
54
55
55
57
57
58
58
61
61
62
62
64
64
64
66
67
67
70
72
72
73
75
76
77
97
97
100
101
102
104
106
107
108
110
111
113
117
118
121
122
124
125
125
125
126
LTIMAS PALAVRAS
Leituras recomendadas
Sobre o autor
Sobre a Traduo
127
128
130
131
1
Introduo
Voc est para comear a utilizar Scrum em sua empresa. Ou talvez voc
esteja usando Scrum h alguns meses. Conhece os princpios, leu alguns
livros, ou talvez at j tenha feito a certificao de scrum master.
Parabns!
Mas ainda se sente confuso.
Como disse Ken Schwaber, Scrum no uma metodologia, um
framework. O que significa que Scrum no vai te dizer exatamente o que
fazer.
A boa notcia que vou te dizer exatamente como fao Scrum, em um
nvel de detalhes excruciantemente doloroso. A m noticia , bem, esta a
maneira como EU fao Scrum. E isto no significa que Voc deva faz-lo
exatamente da mesma maneira. De fato, eu tambm faria de maneira
diferente, se encontrasse situaes diferentes.
O melhor e o pior do Scrum que voc forado a adaptar o processo
para sua situao especifica.
Minha abordagem atual para o Scrum o resultado de um ano de
experincias numa equipe de desenvolvimento de aproximadamente 40
pessoas. A empresa estava em uma situao difcil com tarefas levando
mais tempo que o previsto, problemas de qualidade severos, constantes
incndios, deadlines estourados, etc. A empresa decidiu utilizar Scrum
mas no completou a implantao, o que foi como minha tarefa. Para a
maioria das pessoas na equipe de desenvolvimento naquela poca, Scrum
era uma buzzword que escutavam de vez em quando nos corredores, mas
que no tinha nenhuma implicao para o trabalho dirio.
Aps um ano, implementamos Scrum em todas as camadas da empresa,
tentamos diferentes tamanhos de equipes (3-12 pessoas), diferentes
tamanhos de sprint (2-6 semanas), diferentes formas de definir pronto,
diferentes formatos para os product backlog e de sprint backlogs (Excel,
Jira, cartes), diferentes estratgias de testes, diferentes formas de realizar
Termo de Responsabilidade
Este documento no assume representar a forma correta de usar Scrum!
Ele apenas representa uma forma de usar Scrum, o resultado da melhoria
contnua ao longo de um ano. Voc pode at mesmo decidir que ns
entendemos tudo errado.
Tudo o que h neste documento reflete minhas prprias opinies pessoais
e subjetivas e no de forma alguma uma declarao oficial da Crisp ou
do meu cliente atual. Por esta razo eu intencionalmente evitei mencionar
quaisquer produtos ou pessoas especficas.
2
Como fazemos product backlogs
O product backlog o corao do Scrum. aqui que tudo comea. O
product backlog basicamente uma lista de requisitos, estrias, Coisas
que o cliente deseja, descritas utilizando a terminologia do cliente.
Ns as chamamos de estrias, ou algumas vezes apenas de itens do
backlog.
Nossas estrias incluem os seguintes campos:
ID Uma identificao nica, apenas um nmero com autoincremento. Isso para evitar que percamos o controle sobre as
estrias quando ns mudamos seus nomes.
Nome Um nome curto e descritivo para a estria. Por exemplo,
Ver o histrico de transaes. Suficientemente claro para que
os desenvolvedores e o product owner entendam mais ou menos
sobre o que estamos falando, e claro o bastante para distingui-la
das demais estrias. Normalmente de 2 a 10 palavras.
Importncia a pontuao de importncia dessa estria para o
product owner. Por exemplo 10. Ou 150. Mais pontos = mais
importante.
o Eu tento evitar o termo prioridade j que prioridade 1
tipicamente interpretado como prioridade mais alta, o
que fica feio se mais tarde voc decidir que algo ainda
mais importante. Qual pontuao de prioridade esse item
deveria receber? Prioridade 0? Prioridade -1?
Estimativa inicial As estimativas iniciais da equipe sobre
quanto tempo necessrio para implementar aquela estria, se
comparada a outras estrias. A unidade pontos por estria e
geralmente corresponde mais ou menos a relao homem/dias
ideal.
1. Pergunte equipe se vocs puderem ter o nmero
ideal de pessoas para esta estria (nem muitas, nem
poucas, normalmnte duas), e se trancarem em uma
sala cheia de comida e trabalharem sem distrbio
Notas
Precisa de uma
diagrama
UML de
sequncia. No
necessrio se
preocupar com
criptografia
por enquanto.
Usar
paginao para
evitar
consultas
muito grandes
ao banco de
dados. Projetar
de forma
similar
pgina de
visualizao de
usurios.
3
Como nos preparamos para o
planejamento do sprint
Est bem, o dia de planejamento do sprint est chegando rpido. Uma
lio que aprendemos sempre :
Lio: Tenha certeza de que o product backlog est organizado e fechado
antes da reunio de planejamento do sprint.
E o que isso significa? Que todas as estrias esto perfeitamente bem
definidas? Que todas as estimativas esto corretas? Que todas as
prioridades devem permanecer fixas? No, no e no! O que isso significa
:
O product backlog deveria existir! (j pensou nisso?)
Deveria haver apenas um product backlog e apenas um product
owner (por produto).
Todos os itens importantes deveriam ter uma escala de
importncia associada a eles. Cada um com a sua escala diferente
da dos outros.
o Na verdade, no h problema se todos os itens de pouca
importncia tiverem a mesma escala, j que eles no
sero o foco da reunio de planejamento.
o Qualquer estria que o product owner acredite ter a mais
remota possibilidade de ser includa no prximo sprint,
deve ter uma escala nica de importncia.
o O nvel de importncia s usado para classificar os
itens por importncia. Assim, se o item A tem
importncia de 20 e o item B 100, significa apenas que B
mais importante que A. No significa que B cinco
vezes mais importante do que A. Se B tivesse com a
escala 21, significaria a mesma coisa!
o til deixar espaos vazios entre as numeraes para
poder inserir novos itens. Supondo que o item C seja
descoberto como mais importante do que A, mas menos
importante do que B, ele poderia ganhar a escala 30, ao
4
Como planejamos sprint
O planejamento de sprint uma reunio crtica, provavelmente o evento
mais importante no Scrum (na minha opinio, claro). Um encontro de
planejamento de sprint mal feito pode bagunar totalmente um sprint.
O propsito da reunio de planejamento do sprint dar equipe
informao suficiente para trabalharem em paz por algumas semanas, e
para dar ao product owner confiana suficiente para deix-los fazerem
isto.
OK, isto foi confuso. O resultado concreto do encontro de planejamento
de sprint :
Um objetivo de sprint.
Uma lista de membros da equipe (e seus nveis de
comprometimento, se no 100%).
Um sprint backlog (= uma lista de estrias inclusas no sprint).
Uma data definida para a apresentao do sprint.
Data e local definidos para a reunio diria.
No geral, um sistema com alta qualidade interna pode ainda ter uma baixa
qualidade externa. Entretanto, um sistema com baixa qualidade interna
raramente ter uma qualidade externa alta. difcil construir algo legal a
partir de fundaes podres.
Eu trato qualidade externa como parte do escopo. Em alguns casos pode
fazer perfeito sentido, negocialmente, lanar uma verso do sistema que
tenha uma interface deselegante e lenta, e lanar uma verso melhorada
posteriormente. Eu deixo o dilema para o product owner, uma vez que ele
responsvel por determinar o escopo.
Qualidade interna, porm, no est em discusso. responsabilidade da
equipe manter a qualidade do sistema sob todas as circunstncias e isso
simplesmente no negocivel. Nunca.
(Bem, OK, quase nunca)
Uma terceira opo dividir uma estria. O product owner pode decidir
que existem aspectos na estria A que no so realmente importantes,
ento ele divide a estria A em A1 e A2 separando-as em prioridades
diferentes.
Definio de pronto
importante que o product owner e a equipe concordem com uma
definio clara de pronto. Uma estria est completa quando todo o
cdigo est no repositrio? Ou est completa apenas quando foi feito
deploy em um ambiente de teste e a estria foi verificada por uma equipe
de testes de integrao? Sempre que possvel ns usamos a definio
pronto para deploy em produo, mas algumas vezes precisamos usar a
Esclarecendo Estrias
O pior quando uma equipe orgulhosamente demonstra uma nova
funcionalidade durante o sprint e o product owner franze as
sombrancelhas e diz: Bem, est bonito, mas isso no o que eu pedi!
Como voc assegura que a compreenso que o product owner tem, casa
com a compreenso que a equipe tem sobre a estria? Ou que cada
membro da equipe tem a mesma compreenso de cada estria? Bem, voc
no tem como. Mas aqui vo algumas simples tcnicas para identificar as
piores confuses.
A tcnica mais simples ter certeza que todos os campos foram
preenchidos em cada estria (ou mais especificamente, para cada estria
que for mais importante de ser considerada para essa reunio).
Exemplo 1:
A equipe e o product owner esto felizes com o sprint e prontos para
terminar o encontro. O scrum master diz Esperem um segundo, na
estria chamada adiciona usurio, no h estimativa. Vamos estimar!
Depois de algumas rodadas de planning poker a equipe concorda com 20
pontos por histria enquanto o product owner levanta e enfaticamente diz:
-O queeeee?!. Depois de alguns minutos de discusso acalourada, ela se
transforma numa no compreenso, por parte da equipe, sobre o escopo
adicionar usurio, eles acreditaram ser uma boa interface web para
adicionar, remover e proucurar por usurios, enquanto o product owner
compreendeu adicionar usurios como uma chamada manual usando
SQL num banco de dados. Eles estimam novamente e concordam em 5
pontos por estria.
Exemplo 2:
A equipe e o product owner esto felizes com o plano do sprint e prontos
para terminar o encontro. O scrum master diz: Esperem um segundo,
como a estria adicionar usurios ser demonstrada? algum murmurinho
depois e algum se levanta e diz: Bem, primeiro logamos no site e a
ento... e o product owner interrompe: Logamos no site?! No, no,
Estrias tcnicas
Eis aqui um problema complexo: Estrias tcnicas. Ou itens no
funcionais. Ou como voc preferir cham-los.
Estou referindo-me quelas coisas que precisam ser feitas mas que no
fazem parte das entregas, no esto relacionadas diretamente com
nenhuma estria especfica e no agregam valor para o product owner.
Ns as chamamos de estrias tcnicas.
Por exemplo:
Instalar um servidor de build
o Por que necessrio: porque economiza uma enorme
quantidade de tempo para os desenvolvedores e reduz o
risco dos problemas de integrao ao fim da iterao.
claro, a outra opo s deixar o product owner desinformado ou darlhe um fator de foco no negocivel. Mas no tem desculpa para no
tentar chegar um consenso primeiro.
Se o product owner for um companheiro competente e razovel (e ns
tivemos sorte aqui) sugiro mant-lo to informado quanto possvel e
deix-lo decidir sobre as prioridades. Transparncia um dos valores
centrais do Scrum, certo?
5
Como comunicamos sprints
importante manter a empresa inteira informada sobre o que est
acontecendo. Embora as pessoas reclamem, ou mesmo pior, faam falsas
suposies sobre o que est acontecendo.
Ns usamos a pgina de informaes do sprint para isso.
As vezes ns inclumos informaes sobre como cada estria ser
demonstrada tambm.
O mais cedo possvel depois da reunio de planejamento do sprint, o
scrum master cria esta pgina, pe no ar no Wiki, e envia para a empresa
inteira.
Ns tambm temos a pgina dashboard no nosso wiki, que junta tudo
que est acontecendo nos sprints.
6
Como fazemos os sprint backlogs
Voc j fez isso alguma vez? Uau! Bom trabalho.
Bem, agora que j completamos a reunio de planejamento do sprint e
contamos ao mundo sobre nosso sprint novinho em folha, hora do
Scrum master criar um sprint backlog. Ele precisa ser feito depois da
reunio de planejamento do sprint, mas antes da primeiro reunio diria
do Scrum.
Ei, e a rastreabilidade?!
A melhor rastreabilidade que eu posso sugerir neste modelo tirar uma
foto digital do quadro de tarefas todo dia. Eu fao isso s vezes, mas eu
nunca encontrei um motivo para vasculhar estas fotos.
Se rastreabilidade muito importante para voc, ento o quadro de tarefas
talvez no seja uma boa soluo para voc.
Mas eu sugiro que voc realmente tente estimar o valor real de ter uma
rastreabilidade detalhada do sprint. Uma vez que o sprint est pronto, o
software funcionando e a documentao entregue, algum realmente se
preocupa com quantas estrias foram completadas no dia 5 de um sprint?
Algum realmente se preocupa com qual era o tempo estimado para
escrever um teste de falha para Depsito?
7
Como arrumamos a sala da equipe
O canto do design
Eu notei que muitas das mais interessantes e valiosas discusses sobre
design acontecem espontaneamente na frente do quadro de tarefas.
Por esta razo, ns tentamos arrumar esta rea explicitamente como um
canto do design.
Isto realmente bem til. No h forma melhor de ter uma viso geral do
sistema do que ficar no canto do design e dar uma olhadela em ambas as
paredes, e ento dar uma olhadela no computador e tentar o ltimo build
do sistema (se voc for sortudo o bastante para ter build contnuo, veja pg
81 Como combinamos Scrum e XP).
A parede do design s um grande quadro-branco contendo os rabiscos
de design e esboos (printouts) da documentao de design mais
importante (grficos de seqncias, prottipos de GUI, modelos de
domnio, etc).
8
Como fazemos as reunies dirias
Nossas reunies dirias (daily scrums) so seguidas bem a risca. Elas
comeam exatamente na hora, todo dia no mesmo lugar. No comeo ns
amos para um sala separada para fazer o planejamento do sprint (esses
eram os dias que usvamos o sprint backlog eletrnico). No entanto, agora
ns fazemos nossas reunies dirias na sala da equipe na frente do quatro
de tarefas. Nada supera isso.
Ns normalmente fazemos as reunies em p, uma vez que isso reduz o
risco de ultrapassar 15 minutos.
9
Como fazemos apresentaes de sprint
A apresentao de sprint (ou reviso de sprint como algumas pessoas
chamam), uma parte importante do Scrum que as pessoas tendem a
subestimar.
Oh ns realmente precisamos fazer uma apresentao? Realmente no h
muita diverso para mostrar!
Ns temos tempo para preparar a &%$# de uma apresentao!
Eu no tenho tempo para assistir s apresentaes de outras equipes!
10
Como fazemos retrospectivas de Sprints
Por que insistimos que todas as equipes
faam retrospectivas
A coisa mais importante sobre retrospectivas assegurar-se de que elas
aconteam.
Por alguma razo, equipes nem sempre parecem propensas a fazer
retrospectivas. Sem um estmulo, muitas de nossas equipes
freqentemente no fariam a retrospectiva e seguiriam adiante para o
prximo sprint. Pode ser algo cultural na Sucia, no tenho certeza.
Mesmo assim, todos concordam que retrospectivas so extremamente
teis. Na verdade, eu diria que a retrospectiva o segundo evento mais
importante no Scrum (o primeiro seria a reunio de planejamento do
sprint), pois essa a sua melhor chance de melhorar!
claro, voc no precisa que de uma reunio de retrospectiva, saiam boas
idias. Voc pode fazer isso na sua banheira em casa! Mas a equipe
aceitar a idia? Talvez, mas a probabilidade de obter a aceitao da
equipe muito maior se a idia vem da equipe, isto , ocorre durante a
retrospectiva, quando todos tm permisso para contribuir e discutir as
idias.
Sem retrospectivas, voc descobrir que a equipe continua a cometer os
mesmos erros repetidamente.
Mudar ou no mudar
Digamos que a equipe conclua que nos comunicamos muito pouco entre
ns, ento pisamos nos calos dos outros e bagunamos os designs uns dos
outros.
O que voc deve fazer sobre isso? Introduzir reunies dirias de design?
Introduzir novas ferramentas para facilitarem a comunicao? Adicionar
mais pginas wiki? Bem, talvez. Pensando novamente, talvez no.
Descobrimos que, em muitos casos, s identificar o problema com clareza
suficiente o bastante para resolv-lo automaticamente no prximo
sprint. Especialmente se voc cola a retrospectiva do sprint na parede
(sempre nos esquecemos disso, que vergonha pra gente!). Cada mudana
que voc introduz, adiciona algum tipo de custo. Ento, antes de
introduz-las, considere no fazer nada e esperar o problema desaparecer
(ou se tornar menor) automaticamente.
O exemplo acima (nos comunicamos pouco entre ns), um tpico
exemplo de algo que melhor resolvido sem se fazer absolutamente nada.
Se voc intorduzir uma nova mudana a cada vez que algum reclamar de
alguma coisa, pessoas podem se tornar relutantes a revelar problemas
menores, o que seria terrvel.
11
Intervalo entre sprints
Na vida real, nem sempre voc pode estar em uma corrida (sprint). Voc
precisa descansar entre as corridas (sprint). Se voc est sempre correndo,
na verdade voc est caminhando.
O mesmo acontece no Scrum e no desenvolvimento de software em geral.
Sprints so muito intensos. Como desenvolvedor, voc nunca ir querer
estar descansando, todos os dias voc tem que ir naquela reunio infeliz e
dizer diante de todo mundo o que voc fez ontem. Poucos iro dizer: Eu
gastei a maior parte do meu dia navegando por blogs e servindo
cappuccino.
Adicionalmente ao descanso propriamente dito, existe uma outra boa
razo para ter um intervalo entre os sprints. Aps a apresentao do sprint
e a retrospectiva, a equipe e o product owner estaro ambos cheios de
informaes e idias para digerir. Se eles imediatamente correrem e
comearem a planejar o prximo sprint, existir grande possibilidade de
ningum ter tempo de digerir qualquer informao ou lies aprendidas, o
product owner no ter tido tempo para ajustar suas prioridades aps a
demonstrao do sprint, etc.
Ruim:
Ns tentaremos introduzir algum tipo de intervalo aps comear um novo
sprint (mais especificamente, no perodo aps a retrospectiva do sprint e
antes da prxima reunio de planejamento do sprint). Nem sempre
conseguimos.
Por ltimo, ns tentamos ter a certeza que a retrospectiva do sprint e suas
reunies de planejamento subseqentes no ocorram no mesmo dia.
Todos devem ter uma boa noite-sem-sprint de sono antes de comear um
novo sprint.
12
Como fazemos o planejamento de
release e contratos com preo fixo
Algumas vezes ns precisamos planejar antecipadamente mais de um
sprint por vez. Tipicamente em conjunto com um contrato de preo fixo
onde ns temos que planejar antecipadamente, ou ento arriscar assinar
algo que no poderemos entregar a tempo.
Tipicamente, o planejamento de release para ns uma tentativa de
responder questo quando, no pior caso, ns seremos capazes de
entregar a verso 1.0 deste novo sistema.
Se voc realmente quer aprender sobre planejamento de release eu sugiro
que voc pule este captulo e compre o livro Agile Estimating and
Planning, de Mike Cohn. Eu realmente gostaria de ter lido esse livro
mais cedo (eu o li aps termos percebido as coisas por conta prpria...).
Minha verso de planejamento de release um pouco simplista mas deve
servir como um bom ponto de partida.
Nome
banana
ma
laranja
goiaba
pra
passa
amendoim
donut
cebola
framboesa
mamo
mirtilo
pssego
Nome
Estimativa
banana
12
ma
9
laranja
20
goiaba
8
pra
20
passa
12
amendoim
10
donut
8
cebola
10
framboesa
14
mamo
4
mirtilo
pssego
Estime velocidade
OK, agora ns temos uma estimativa de tempo, bem a grosso modo, para
as estrias mais importantes.
Prximo passo estimar nossa velocidade mdia por sprint.
Isso significa que ns precisamos decidir nosso fator de foco. Veja a pg
24 "Como a equipe decide quais estrias incluir no sprint".
O fator de foco basicamente quanto do tempo da equipe gasto
focando na execuo da estria em questo. Nunca de 100%, visto que
equipes perdem tempo fazendo itens no planejados, trocando o contexto
que esto fazendo, ajudando outras equipes, verificando seus e-mails,
consertando seus computadores com defeito, discutindo polticas na
cozinha, etc.
Vamos dizer que ns determinemos o fator de foco da equipe em 50%
(um pouco baixo, ns normalmente paramos em torno de 70%). E vamos
dizer que o tamanho do nosso sprint ser de 3 semanas (15 dias) e nossa
equipe composta por 6 membros.
Cada sprint tem 90 dias-homem de durao, mas podemos esperar uma
produo completa de 45 dias-homem no valor das estrias (devido o
fator de foco ser de 50%).
Ento nossa velocidade estimada de 45 pontos.
Se cada estria tinha uma estimativa de 5 dias (que eles no) ento essa
equipe poderia desenvolver aproximadamente 9 histrias por sprint.
Name
Estimativa
Sprint 1
banana
12
ma
9
laranja
20
Sprint 2
goiaba
8
pra
20
passa
12
Sprint 3
amendoim
10
donut
8
cebola
10
framboesa
14
Sprint 4
mamo
4
mirtilo
pssego
13
Como combinamos Scrum e XP
Dizer que Scrum e XP (eXtreme Programming) podem ser combinados de
forma vantajosa no seria uma afirmao polmica. A maioria do material
que vejo na internet apoia essa hiptese, ento no vou me demorar
justificando o porqu.
Bem, terei que dizer uma coisa. O Scrum focado nas prticas de
gerenciamento e organizao, enquanto o XP d mais ateno s tarefas
de programao mesmo. A est o porqu de elas trabalharem bem juntas
elas abrangem reas diferentes e uma complementa a outra.
Eu deixo aqui minha opinio de que o Scrum e o XP podem ser
combinados de forma a dar resultados muito bons!
Eu vou destacar algumas das melhores prticas do XP e como elas se
aplicam ao nosso dia-a-dia. Nem todas nossas equipes decidiram adotar
todas elas, mas no total ns experimentamos a maioria das combinaes
de XP/Scrum. Algumas dessas prticas so diretamente tratadas pelo
Scrum e podem ser vistas como sobrepostas, por exemplo, Toda a
Equipe, Sentar Juntos, Estrias e Planning game. Em todos esses
casos, ns simplesmente usamos o Scrum ao invs do XP.
Programao em par
Ns comeamos com esta prtica em uma de nossas equipes. Atualmente
tem funcionado bem. A maioria de nossas outras equipes no usam
programao em par freqentemente, mas como tentamos em uma equipe
por alguns sprints, eu me sinto encorajado a incentivar mais equipes a
colocarem em prtica.
Algumas concluses sobre programao em par:
Programao em par aumenta a qualidade do cdigo
Design incremental
Significa manter o design simples desde o incio e melhor-lo
continuamente, ao invs de tentar deix-lo perfeito desde o incio e ento
congel-lo.
Ns estamos indo muito bem assim, isto , ns gastamos uma quantidade
considervel de tempo melhorando o design existente e ns raramente
perdemos tempo projetando de forma precipitada. s vezes ns
estragamos tudo, claro, por exemplo quando deixamos que um design
instvel crie muitas razes, de forma que refatorar se torna um grande
projeto. Mas no geral estamos muito satisfeitos.
Melhoria contnua do design praticamente um efeito coleteral do
Desenvolvimento Orientado a Testes.
Integrao contnua
A maioria dos nossos produtos possui uma configurao de integrao
contnua razoavelmente sofisticada, baseada em Maven e QuickBuild. Isto
extremamente vlido e poupa tempo. Essa a soluo definitiva para
um velho problema Ei, mas isso funciona na minha mquina. Nosso
servidor de construo contnua age como o juiz ou ponto de referncia
a partir do qual se determina a qualidade de todas as nossas bases de
cdigo.
Toda vez que algum atualiza alguma coisa no sistema de controle de
verso o servidor de construo contnua ir acordar, construir tudo desde
o incio num servidor compartilhado e realizar todos os testes. Se alguma
coisa der errado, ele enviar um email avisando a equipe inteira que a
construo falhou, incluindo informaes sobre exatamente qual mudana
de cdigo quebrou a construo, links para relatrios de teste, etc.
Todas as noites o servidor de construo contnua ir reconstruir o
produto desde o incio e publicar binrios (ears, wars, etc),
documentaes, relatrios de teste, relatrios de cobertura de testes,
relatrios de dependncias, etc, no nosso portal de documentaes
internas. Alguns produtos sero tambm automaticamente implementados
em um ambiente de teste.
Configurar isso deu muito trabalho, mas valeu cada minuto.
Padro de codificao
Recentemente ns comeamos a definir o nosso padro de codificao.
Teria sido muito til se tivssemos feito isso antes. No leva quase tempo
nenhum. Comece com ele simples e v crescendo conforme a
necessidade. Escreva apenas regras que no sejam bvias para todo
mundo e correlacione com algum material j existente, sempre que
possvel.
A maioria dos programadores tem seu estilo prprio de codificao. So
pequenos detalhes como, por exemplo, a forma de tratar excees, como
comentar o cdigo, quando retornar valor nulo, etc. Em alguns casos as
diferenas no causam problemas, mas em outros casos pode levar ao
projeto de um sistema extremamente inconsistente e um cdigo fonte
difcil de entender. Um padro de codificao aqui muito til, j que
voc foca em coisas que realmente importam.
Aqui esto alguns exemplos do nosso padro de codificao:
http://java.sun.com/docs/codeconv/html/CodeConvTOC.
doc.html
14
Como fazemos testes
Essa a parte mais difcil. No tenho certeza se a parte mais difcil do
Scrum ou do desenvolvimento de software em geral.
A etapa de testes , provavelmente, a que mais varia de uma empresa para
outra. Ela depende de quantos testadores voc tem, de quo automatizados
so os testes, de que tipo de sistema voc tem (apenas servidor+aplicao
web? ou na verdade voc entrega pacotes de software?), do tamanho dos
ciclos de release, quo crtico o sistema (servidor de blog versus
controle de trfego areo), etc.
Ns temos feito muitos experimentos em como fazer testes com Scrum.
Tentarei descrever o que temos feito e o que aprendemos at agora.
Aps o sprint 1, uma release bugada 1.0.0 lanada. Da, durante o sprint
2, os bugs da ltima release comeam a ser notificados, a equipe gasta
grande parte do tempo corrigindo-os e forada a lanar uma verso
intermediria 1.0.1 no meio do sprint 2. Ento, ao final do sprint 2, uma
release
1.1.0 com novas funcionalidades disponibilizada.
Provavelmente esta verso 1.1.0 estar ainda mais bugada que a release
1.0.0, j que o tempo nela investido foi prejudicado devido necessidade
urgente de correo da primeira release 1.0.0, e isso sempre se repetir.
As linhas diagonais em vermelho da figura simbolizam o caos.
No fica muito bonito, n? A m notcia, entretanto, que este problema
permanecer mesmo se voc tiver uma equipe s para testes de aceitao
de releases. A nica diferena ser que a maioria dos relatos de bugs viro
da equipe de teste, e no de usurios raivosos. Sob a perspectiva de
negcios, isso j faz uma grande diferena. Para desenvolvedores,
contudo, d na mesma. Talvez a nica exceo seja o fato de testadores
serem menos agressivos que usurios. Geralmente.
De volta realidade
Provavelmente eu tenho passado a impresso de que ns temos testadores
em todas as equipes, que temos uma enorme equipe de testes de aceite
para cada produto, que entregamos depois de cada sprint, etc, etc.
Bem, ns no temos.
Ns algumas vezes gerenciamos projetos com testes, e ns temos visto
efeitos positivos. Mas ainda estamos longe de um aceitvel processo de
garantia de qualidade, e ainda temos muito a aprender.
15
Como lidamos com vrias equipes
Muitas coisas se complicam quando se tem vrias equipes trabalhando no
mesmo produto. Esse problema universal e no tem nada a ver com o
Scrum. Mais desenvolvedores = mais complicaes.
Ns temos (como sempre) experincia com isso. No mximo, ns temos
aproximadamente 40 pessoas trabalhando no mesmo produto.
A questes chaves so:
Quantas equipes criar
Como alocar pessoas nas equipes
Equipes virtuais
Como voc sabe se tomou a deciso certa ou errada em relao aos prs e
contras de ter uma equipe grande ou uma equipe pequena?
Se voc manteve seus olhos e ouvidos abertos voc deve ter notado o
termo equipes virtuais.
Exemplo 1: Voc escolhe ter uma equipe grande. Mas quando voc
comea a observar quem fala com quem durante o sprint, percebe que a
equipe acabou se dividindo em duas sub-equipes.
Exemplo 2: Voc escolhe ter trs equipes menores. Mas quando voc
comea a observar quem fala com quem durante o sprint, percebe que as
equipes 1 e 2 esto conversando entre si o tempo todo, enquanto que a
equipe 3 est trabalhando isoladamente.
A maioria dos livros que eu li dizem que o tamanho de equipe ideal est
em algum ponto entre 5 e 9 pessoas.
Do que eu vi at agora a nica coisa que eu posso fazer concordar.
Apesar de que eu diria de 3 a 8 pessoas. Na verdade, eu acredito que vale
pena pagar o preo para chegar em uma equipe deste tamanho.
Digamos que voc tem uma nica equipe com 10 pessoas. Considere a
possibilidade de retirar da equipe os dois membros mais fracos. Oops, eu
disse isso?
Digamos que voc tenha dois produtos diferentes, com uma equipe de trs
pessoas por produto, e as duas esto lentas. Seria uma boa idia combinlas em uma nica equipe de 6 pessoas responsvel pelos dois produtos.
Neste caso retire um dos dois product owners da funo (ou lhe d outra
funo de consultoria ou algo do tipo).
Digamos agora que voc possui uma nica equipe com 12 pessoas, porque
a base de cdigo est to ruim que no h como duas equipes diferentes
trabalharem independentemente. No poupe esforos em consertar a base
de cdigo (ao invs de criar novas funcionalidades) at que voc chegue a
um ponto onde possvel dividir a equipe. Rapidamente este investimento
ir compensar.
Equipes de bombeiros
Tivemos uma situao onde no era possvel adotar Scrum em um grande
produto porque gastvamos muito tempo apagando incndios, ex:
corrigindo exaustivamente falhas de uma verso prematura do sistema.
Este era um verdadeiro ciclo vicioso. Ficvamos to ocupados corrigindo
falhas que no tnhamos tempo hbil para trabalhar proativamente na
preveno de novas falhas (exemplo: melhorias no desenvolvimento,
automao de testes, criao de ferramentas de monitoramento,
ferramentas de suporte, etc).
Para ser mais concreto, aqui est o modo como a reunio de planejamento
de sprint funciona para esta equipe:
A reunio de planejamento de sprint ocorre em um centro de conferncias
externo.
Logo antes da reunio, o product owner define um quadro para ser o
quadro do product backlog e coloca estrias ali (cartes), ordenadas por
prioridade relativa. Ele continua colocando-as at que o quadro esteja
cheio. Normalmente estes so itens mais do que suficientes para um
sprint.
Cada equipe seleciona uma parte vazia do quadro e coloca seu nome ali.
Este o seu quadro de equipe. Cada equipe ento pega algumas estrias
do quadro do product backlog, comeando pelas estrias com maior
prioridade e coloca os cartes em seu prprio quadro de equipe.
Isso est ilustrado na imagem a seguir, com setas amarelas simbolizando o
fluxo dos cartes do quadro de product backlog para os quadros de
equipe.
16
Como lidamos com equipes distribudas
geograficamente
O que acontece quando as equipes esto em locais geogrficos diferentes?
A maior parte da mgica do Scrum e do XP baseada em equipes
localizadas juntas e membros de equipe fortemente colaborativos que
programam em pares e encontram-se cara-a-cara todos os dias.
Ns temos algumas equipes geograficamente separadas e tambm alguns
membros trabalhando em casa de vez em quando.
Nossa estratgia para essa situao bem simples. Ns usamos todos os
truques possveis para aumentar a largura de banda de comunicao entre
os membros separados fisicamente. Eu no falo simplesmente sobre a
largura de banda em Mbits/segundo (apesar disso tambm ser importante).
Eu me refiro largura de banda de comunicao em um sentido mais
amplo:
adaptar
17
Checklist do scrum master
No final deste captulo eu irei mostrar a vocs o checklist do nosso
scrum master, listando suas rotinas administrativas mais comuns. Coisa
fcil de se esquecer. Ns cortamos as coisas bvias como remova os
impedimentos da equipe.
Comeando o sprint
Todo dia
Fim do Sprint
18
ltimas palavras
Ufa! Nunca pensei que seria to demorado.
Espero que este livro tenha lhe fornecido algumas idias teis, seja voc
um iniciante em Scrum ou um veterano.
Como o Scrum deve ser adaptado s necessidades especficas de cada
ambiente, difcil discutir de forma construtiva sobre as melhores prticas
de forma genrica. Apesar disso estou interessado em receber seu
feedback. Diga-me como a sua abordagem difere da minha. Envie suas
idias sobre como podemos melhorar!
Sinta-se a vontade para me contatar em henrik.kniberg@crisp.se
Ou ento em scrumdevelopment@yahoogroups.com.
Se voc gostou deste livro pode dar uma olhada tambm em meu blog.
Espero ir adicionando alguns posts sobre Java e desenvolvimento gil.
http://blog.crisp.se/henrikkniberg/
Ah, e no esquea
Isto s um trabalho, certo?
Leituras recomendadas
Aqui esto alguns livros que me deram muita inspirao e idias. So
altamente recomendados!
Sobre o autor
Henrik Kniberg (henrik.kniberg@crisp.se) consultor na Crisp em
Estocolmo (www.crisp.se), especializando em Java e desenvolvimento
gil de software.
Desde que apareceram os primeiros livros de XP e o manifesto gil,
Henrik abraou os princpios geis e tentou aprender como aplic-los
eficientemente em diferentes tipos de organizaes. Como co-fundador a
CTO (chief technology officer) de Goyada 1998-2003, ele teve ampla
oportunidade de experimentar o TDD (test-driven development) e outras
prticas geis bem como montar e gerenciar uma plataforma tcnica e
uma equipe de desenvolvimento com 30 pessoas.
No final de 2005 Henrik foi contratado como chefe de desenvolvimento
em uma companhia Sueca da industria de jogos eletrnicos. A companhia
estava em crise com problemas tcnicos e organizacionais urgentes.
Usando Scrum e XP como uma ferramenta, Henrik ajudou a companhia
sair da crise atravs da implementao de princpios geis e leves em
todos os nveis da empresa.
Em uma Sexta-feira de Novembro de 2006, Henrik estava em casa na
cama, com febre e decidiu tomar algumas notas para ele mesmo do que
ele aprendeu atravs do ltimo ano. Uma vez que comeou a escrever, no
conseguiu parar aps trs dias frenticos; escrevendo e desenhando as
notas iniciais se tornaram um artigo de 80 pginas intitulado Scrum e XP
direto das Trincheiras, que veio se tornar este livro.
Henrik usa uma abordagem holstica e divertida na adoo de diferentes
perfis como gerente, desenvolvedor, Scrum master, professor e coach. Ele
apaixonado em ajudar as companhias a construir excelentes softwares,
excelentes equipes, participando em qualquer perfil que seja necessrio
para isto.
Henrik cresceu em Tokyo e agora vive em Estocolmo com sua esposa
Sophia e dois filhos. Ele um msico ativo em seu tempo livre,
compondo e tocando baixo e teclado com sua banda local.
Para mais informaes, acesse: http://www.crisp.se/henrik.kniberg
Sobre a Traduo
Este livro foi traduzido voluntariamente por brasileiros, nas mais diversas
funes, com os mais diversos conhecimentos das lnguas cujo nico
interesse foi o de disseminar e popularizar as metodologias geis
Coordenao
Bruno Pedroso
Renato Willi
brunopedroso@gmail.com
renato.willi@gmail.com
Reviso
Verso 1.0
Renato Willi
Verso 1.1
Marcos Vincius Guimares
Ian Gallina
Verso 1.2
Leonardo Siqueira Rodrigues
Verso 1.3
Andr Delorme
Verso 1.4
Paulo Victor Gama Gross de Souza
renato.willi@gmail.com
pvggds@gmail.com
Ilustrao
Eduardo Bobsin Machado
eduardo.bobsin@gmail.com
Traduo
Vincius Assef
Cssio Marques
lvaro Maia
Jos Incio Serafini
Rafael Benevides
Rafael Recalde Caceres
Fernanda Stringassi de Oliveira
Renato Willi
Rodrigo Palhano
Daniel Wildt
Francisco M. Soares Nt.
Eduardo Bobsin Machado
Juliana Berossa Steffen
Mauricio Vieira
Rodrigo Russo
viniciusban@gmail.com
cassiommc@gmail.com
serafini@sr.cefetes.br
rafabene@gmail.com
rafael.r.caceres@gmail.com
fernandasoliveira@yahoo.com
renato.willi@gmail.com
dwildt@gmail.com
xfrancisco.soares@gmail.com
eduardo.bobsin@gmail.com
julianaberossa@gmail.com
mauricio@mauriciovieira.net
brandizzi@gmail.com
alegomes@gmail.com
brunopedroso@gmail.com
victorhg@gmail.com
emanoeltadeu@gmail.com
gustavogrillo@gmail.com
israel.faria@gmail.com
pablotj@gmail.com
Apoio
SEA Tecnologia
www.seatecnologia.com.br