Escolar Documentos
Profissional Documentos
Cultura Documentos
ScrumeXPDiretodasTrincheiras PDF
ScrumeXPDiretodasTrincheiras PDF
ScrumeXPDiretodasTrincheiras PDF
Cortesia de
Escrito Por:
Henrik Kniberg
2007 C4Media Inc
All rights reserved.
ISBN: 978-1-4303-2264-1
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.
INTRODUO 6
Termo de Responsabilidade 7
Porque eu escrevi isso 7
Mas o que Scrum? 8
Jeff Sutherland,
Ph.D., Co-Criador do Scrum
Prefcio por Mike Cohn
Mike Cohn
Autor de Agile Estimating and Planning e User Stories Applied for
Agile Software Development.
Prefcio Ei, Scrum funcionou!
Scrum funcionou! Pelo menos para ns (me refiro ao meu cliente atual em
Stockholm, cujo nome no pretendo mencionar aqui). Espero que ele
funcione pra voc tambm. Talvez esse livro te ajude ao longo do
caminho.
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.
Logo, essa minha chance de devolver algo. Aqui est minha histria de
guerra.
Eu espero que este documento provoque algum retorno til daqueles que
estejam na mesma situao. Por favor, me iluminem!
Se voc impaciente demais para fazer isso, sinta-se livre para continuar
lendo. Muito do jargo do Scrum explicado conforme avanamos, logo
ainda assim voc poder achar isso interessante.
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.
A razo pela qual toda equipe e o product owner devam estar na reunio
de planejamento do sprint porque cada estria contm trs variveis que
so muito dependentes umas das outras.
16 | SCRUM E XP DIRETO DAS TRINCHEIRAS
E se o product owner ainda insistir que ele no tem tempo para tomar
parte das reunies de planejamento do sprint? Eu normalmente tento uma
das estratgias, na seguinte ordem:
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.
A-ha! Ele est tentando usar qualidade interna como uma varivel. Como
eu sei? Porque ele quer que ns reduzamos a estimativa da estria sem
pagar o preo de reduzir o escopo.. A palavra quebra-galho deve
ativar um alarme na sua cabea...
Uma vez que o product owner tenha aprendido que qualidade interna no
negocivel, ele geralmente se especializa em manipuar as outras
variveis.
Bem, sprints curtos so bons. Eles permitem que a equipe seja gil, isto
, mude de direo freqentemente. Sprints curtos = ciclo curto de
feedback = entregas mais freqentes = feedback mais freqente do cliente
= menos tempo perdido, indo na direo errada = aprender e melhorar
rpido, etc.
No entanto, uma vez que vocs decidiram o tamanho que mais gostam,
mantenham ele por um bom tempo. Depois de alguns meses de
experimentao, ns achamos que 3 semanas estava bom. Ento ns
fazemos sprints de 3 semanas, ponto. Algumas vezes parecer um pouco
longo demais, outras vezes parecer um pouco curto demais. Mas,
mantendo o mesmo tamanho, isso se torna como um batimento cardaco
corporativo, com que todos se identificam confortavelmente. No h
discusso quanto s datas de entregas ou coisas do tipo, porque todos
sabem que a cada trs semanas haver uma entrega, ponto.
Por algum motivo difcil definir um objetivo para o sprint. Mas ainda
sim eu percebi que compensa se esforar para espremer um. Melhor um
objetivo meia-boca do que nenhum objetivo. O objetivo poderia ser
ganhar mais dinheiro ou completar as 3 estrias mais importantes ou
impressionar o CEO ou tornar o sistema bom o suficiente para
distribuir uma verso beta ou adicionar funcionalidades bsicas de
retaguarda ou qualquer coisa. O importante que seja em termos de
negcio, no termos tcnicos. Isto quer dizer, em termos que as pessoas
de fora da equipe possam entender.
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.
E o que dizer sobre uma estria que ficou quase completa durante o
sprint? Por que no pegamos medidas parciais em nossa velocidade real?
Bem, para tirar proveito do fato de que Scrum (e de fato o
desenvolvimento gil de software e os processos lean de fabricao em
geral) trata de ter as tarefas realizadas, prontas para serem entregues! O
valor de uma coisa feita pela metade zero (de fato, at negativo). Leia
COMO PLANEJAMOS SPRINT | 27
Portanto, nossa velocidade estimada ser certamente menor que 50. Mas o
quanto menor? Utilizamos para isso o termo fator de foco.
28 | SCRUM E XP DIRETO DAS TRINCHEIRAS
Tempo de ontem uma tcnica acessvel, mas use-a com uma dose de
bom senso. Se o ltimo sprint foi excepcionalmente ruim porque a maior
parte da equipe esteve doente por uma semana, ento pode ser seguro
assumir que voc no ter esta falta de sorte de novo e voc pode estimar
um fator de foco alto para o prximo sprint. Se a equipe instalou
recentemente um novo e rpido sistema de build contnuo voc pode,
provavelmente, aumentar o fator de foco devido a isto tambm. Se uma
pessoa nova est se juntando a este sprint voc precisa reduzir o fator de
foco para considerar seu treinamento. Etc.
Sempre que possvel olhe para os sprints passados e faa a mdia dos
nmeros para obter uma estimativa mais confivel.
Uma vez que temos a listagem preliminar das estrias a serem includas
no sprint, eu fao uma reviso baseada no meu sentimento. Eu peo a
equipe para ignorar os nmeros por um momento e pensar apenas em suas
percepes sobre a parte em questo do sprint. Se acham que levar
bastante tempo ento removemos uma ou duas estrias. E vice-versa.
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
34 | SCRUM E XP DIRETO DAS TRINCHEIRAS
H uma tcnica excelente para evitar isso ela chamada planning poker
(cunhada por Mike Cohn, eu acho).
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,
COMO PLANEJAMOS SPRINT | 37
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.
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.
Em alguns casos o product owner tem razo, mas quase sempre no tem.
Conclumos que o product owner nem sempre esta qualificado para tomar
estas decises. Assim, o que fazemos :
1) Tentamos evitar as estrias tcnicas. Procure transformar uma
estria tcnica em uma estria normal, com valores de negcio
mensurveis. Desse jeito o product owner vai ter uma chance
maior de tomar as decises corretas.
2) Se no conseguirmos transformar uma estria tcnica em uma
estria normal, veja se o trabalho pode ser feito como uma tarefa
dentro de outra estria. Por exemplo: refatorar a camada DAO
pode ser uma tarefa dentro da estria editar usurio, pois ela
envolve a camada DAO.
3) Se os dois itens anteriores falharem, defina-o como uma estria
tcnica, e mantenha uma lista separada destas estrias. Deixe que
o product owner a veja, mas no permita que modifique-a.
Utilizamos o parmetros fator de foco e velocidade estimada
para negociar com o product owner e separar algum tempo no
sprint para implementar as estrias tcnicas.
42 | SCRUM E XP DIRETO DAS TRINCHEIRAS
Ento, claro, tudo pode dar errado no restante do projeto, mas pelo
menos voc no poder culpar o planejamento do sprint :o)
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.
Quando o sprint est perto do fim, o scrum master lembra todo mundo
sobre a apresentao que ocorrer em breve.
Feito tudo isso, ningum tem desculpa pra no saber o que est
acontecendo.
46 | SCRUM E XP DIRETO DAS TRINCHEIRAS
6
Como fazemos os sprint backlogs
Voc j fez isso alguma vez? Uau! Bom trabalho.
Encontre uma parede grande que no utilizada ou que tem coisas inteis,
como o smbolo da empresa, diagramas velhos e quadros feios. Limpe a
parede (s pea permisso se for necessrio). Cole uma folha de papel
bem grande, bem grande mesmo (pelo menos 2m de altura x 2m de
largura, ou 3x2m para uma equipe grande). Ento faa assim:
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.
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?
O 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).
Uma vez que voc tenha a equipe toda junta, o retorno ser imediato.
Depois de somente um sprint a equipe ir concordar que foi uma boa idia
sentar junto (falando por experincia pessoal, mas no h nada dizendo
que a sua equipe no ser to teimosa para no admitir isto).
Junto significa:
Audibilidade: Qualquer um da equipe pode conversar com o
outro sem gritar ou sair da mesa.
COMO ARRUMAMOS A SALA DA EQUIPE | 55
E se voc tiver uma equipe distribuda? Bem, ento voc est sem sorte.
Use o mximo de resursos tcnicos que voc puder para minimizar o dano
vdeo conferncia, webcams, ferramentas de compartilhamento da rea
de trabalho, etc.
Mas, ento, eu era tambm (entra a musica tema do Darth Vader) o chefe
de desenvolvimento, um perfil funcional gerencial. O que significa que ao
entrar em uma equipe ela se tornava automaticamente menos auto-
gerenciavel. caramba, o chefe est aqui, ele provavelmente tem um
monte de opinies sobre o que deveramos estar fazendo e sobre quem
deveria estar fazendo o que. Vamos deixar ele falar!
Para as equipes Scrum que funcionam bem, garanta que tenham tudo o
que precisam e tire do caminho tudo aquilo que pode atrapalhar (exceto
durante as apresentaes de sprint).
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.
Voc s se livra dessa se tiver uma boa desculpa, como consulta mdica,
seu prprio casamento ou algo do tipo.
Vamos dizer que Joe e Lisa so os que no sabem o que fazer hoje.
Scrum master: OK, quem quer mostrar a release beta pra gente?
(considerando que isso era o objetivo do sprint)
Equipe: silncio confuso
Scrum master: No estamos prontos?
Equipe: hum... no
Scrum master: Mas que coisa. Por que no? O que est faltando?
Equipe: Bem, no temos o servidor de testes pra rodar, e o script de
gerao de build est falhando.
Scrum master: Aha. (adiciona dois post-its no quadro de tarefas). Joe
e Lisa, como podem nos ajudar hoje?
Joe: Hum.... Acho que vou tentar algum servidor de testes em algum
lugar.
Lisa: ... e eu vou tentar arrumar o script da build.
Se for, tente pare-lo com algum que possa ser o seu pastor. Joe ser
um timo desenvolvedor e arquiteto, apenas ele prefere que outra pessoa
lhe fale o que fazer . Perfeito. D Nicklas o dever de ser o pastor
permanente de Joe. Ou assuma a responsabilidade voc mesmo. Se Joe
importante o suficiente para sua equipe, isso ser um esforo vlido. Ns
tivemos casos como esse e isso funcionou mais ou menos.
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.
Trs colunas:
Bom: se pudssemos refazer o mesmo sprint novamente,
faramos as coisas do mesmo modo;
Poderia ter sido melhor: se pudssemos refazer o mesmo sprint
novamente, faramos as coisas de uma maneira diferente;
Melhorias: idias concretas sobre como podemos melhorar no
futuro;
Depois que a equipe fez o brainstorming com todos esses post-its, eles
usaram uma votao para determinar quais melhorias devem dar ateno
66 | SCRUM E XP DIRETO DAS TRINCHEIRAS
Nossa estratgia para tratar isso bastante simples. Uma pessoa (neste
caso, eu) participa de todas as retrospectivas de sprint, e age como uma
ponte de conhecimento. Bastante informal.
Uma alternativa seria fazer com que cada equipe publicasse um relatrio
da reunio de retrospectiva. Ns tentamos, mas descobrimos que poucas
pessoas liam estes relatrios, e menos ainda so os que agem atravs
deles. Ento fizemos realmente do jeito mais fcil.
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.
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.
Felizmente nunca tive que mudar a equipe de lugar. Mas faria isto se fosse
necessrio :o)
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.
Ruim:
Melhor ainda:
Uma forma de fazer isso com os lab days (ou qualquer nome que voc
quiser dar). So dias que os desenvolvedores podem fazer o que eles
quisererm (OK, fui inspirado pelo Google). Por exemplo, eles podem ler
sobre as ltimas verses de algumas ferramentas ou APIs, estudar para
certificao, discutir temas tcnicos com os colegas, participar de um
projeto pessoal, etc.
Nosso objetivo ter um lab day entre cada sprint. Dessa forma voc
ganha um descanso natural entre os sprints, e ao mesmo tempo, voc
permite sua equipe de desenvolvedores manter os conhecimentos em
dia. Alm disso, um benefcio bem atraente para contratao.
Melhor de todos?
Importncia Nome
130 banana
120 ma
115 laranja
110 goiaba
100 pra
95 passa
80 amendoim
70 donut
60 cebola
40 framboesa
35 mamo
10 mirtilo
10 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.
Se cada estria tinha uma estimativa de 5 dias (que eles no) ento essa
equipe poderia desenvolver aproximadamente 9 histrias por sprint.
76 | SCRUM E XP DIRETO DAS TRINCHEIRAS
Talvez no seja uma boa notcia para o cliente, mas pelo menos estaremos
sendo honestos e daremos ao cliente a opo de adiantar a entrega
devemos entregar as coisas mais importantes no prazo ou entregar tudo
atrasado. Geralmente, esta no uma deciso difcil. :o)
Como combinamos Scrum e XP
13
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.
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.
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.
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.
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.
Claro, reduzir a carga horria no foi o nico aspecto que nos levou essa
melhoria, mas ns todos estvamos convencidos que foi um dos grandes
responsveis.
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.
Errado.
testador!
Deixe-me explicar. O que eu quero dizer com testador neste caso ter
uma pessoa cuja habilidade primria testar, ao invs de uma pessoa
cuja funo apenas testar
Ento como o Sr. T (nosso testador) sabe que algo est pronto? Bem,
antes de mais nada, ele deve (surpresa!) testar! Em muitos casos algo que
o desenvolvedor considerou como pronto no era nem mesmo possvel de
ser testado! Seja porque o cdigo no foi adicionado ao sistema de
controle de verses, ou porque no foi instalado no servidor de testes, ou
no pde ser inicializado, ou qualquer outra causa. Assim que o Sr. T tiver
testado a funcionalidade, ele deve repassar a lista de pronto com o
desenvolvedor (caso voc tenha uma). Por exemplo, se a definio de
pronto diz que deve existir uma nota de release, ento o Sr. T verifica se
existe uma nota de release. Se houver algum tipo de especificao mais
formal para esta funcionalidade (o que raro no nosso caso) ento o Sr. T
tambm verifica isso, etc.
Por outro lado, o que fazer se o sr. T tornar-se um gargalo? Vamos supor
que estejamos no ltimo dia do sprint e de repente muita coisa est pronta
e o sr. T no teve a oportunidade de testar tudo. O que fazer? Bem, vamos
transformar todo o resto da equipe em ajudantes do sr. T. Ele decide qual
funcionalidade ele prprio precisa fazer e delega as outras para o restante
da equipe. Isso o que significa ter uma equipe multi-disciplinar!
Quase sempre mais barato construir menos, mas construir algo estvel.
Melhor do que construir montes de coisas que te deixam em pnico com
consertos de urgncia.
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.
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.
Minha experincia diz que melhor ter menos equipes, embora grandes,
do que ter muitas equipes pequenas que interfiram umas nas outras. Faa
pequenas equipes apenas se no forem interferir umas nas outras!
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.
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 combin-
las 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).
COMO LIDAMOS COM VRIAS EQUIPES | 99
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.
Com tantas estrelas no projeto, a quem cabe decidir quem fica em qual
equipe? Ao product owner? Aos trs Scrum masters juntos? Todo mundo
escolhe em que equipe quer ficar? Mas e se todo mundo quiser ficar na
equipe 1(porque a Scrum master 1 to bonitinha...)?
No foi fcil achar um nome para esse papel, Lder de Equipe foi o
menos pior.
Isto o que temos visto que melhor funciona. Um certo nvel de controle
centralizado no incio, seguido de um certo nvel de melhoria
descentralizada, depois.
Uma das primeiras coisas que fizemos quando introduzimos o Scrum foi
dissolver as equipes existentes especializadas em componentes
(abordagem 1) e criar equipes multifuncionais em seu lugar (abordagem
2). Isto diminuiu o nmero de casos de no pudemos completar este item
porque estvamos esperando pelos caras do servidor fazer o trabalho
deles.
Em um sprint pode ser uma boa idia ter uma equipe apenas de clientes,
consistindo apenas de pessoas que conhecem bem a base de cdigo do
cliente. No prximo sprint pode ser uma boa idia ter duas equipes e
dividir o pessoal cliente entre elas.
Uma exceo quando voc comea a praticar Scrum com uma equipe
grande pela primeira vez. Neste caso, provavelmente vale pena
experimentar um pouco com a subdiviso da equipe at que voc encontre
algo com que todos se sintam confortveis. Tenha certeza de que todos
entendo de no h problema algum se tudo der errado nas primeiras
vezes, desde que voc se mantenha sempre melhorando.
Se voc tem uma pessoa que ir dividir seu tempo entre multiplas equipes,
como o DBA citado anteriormente, ainda assim uma boa idia t-lo
como membro primrio em uma nica equipe. Descubra qual a equipe que
mais ir precisar dele e faa esta sua equipe casa. Quando mais
ningum estiver precisando dele, ele estar presente nas reunies dirias,
reunies de planejamento de sprint, retrospectivas e etc desta equipe.
Sim, isto funciona se voc (ou quem conduz a reunio) for rigoroso
quanto a mant-la curta.
O formato da reunio :
Por isso pedimos que s equipes evitem ter reunies dirias simultneas.
Equipes de bombeiros
Esta soluo funcionou muito bem. Quando a equipe Scrum teve uma sala
para trabalhar proativamente, eles finalmente estabilizaram o sistema.
Enquanto isso, a equipe de suporte desistiu completamente da ideia de
planejar atividades futuras. Trabalhando reativamente, eles simplesmente
consertavam qualquer defeito que aparecia.
O bom deste modelo que voc pode deixar as equipes praticamente por
conta prpria, baseado nas prioridades do product owner. O product
owner pode focar no que ele precisa e deixar as equipes decidirem como
dividir o trabalho.
Para ser mais concreto, aqui est o modo como a reunio de planejamento
de sprint funciona para esta equipe:
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.
Como normal, isso tudo um teste. Testar => adaptar => testar =>
adaptar => testar => adaptar => testar => adaptar => testar => adaptar
Mas um dos fundamentos do Scrum diz que a equipe toda deve estar
fisicamente no mesmo lugar. Ento o que fazemos?
Comeando o sprint
Todo dia
Fim do Sprint
Espero que este livro tenha lhe fornecido algumas idias teis, seja voc
um iniciante em Scrum ou um veterano.
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.
Coordenao
Bruno Pedroso brunopedroso@gmail.com
Renato Willi renato.willi@gmail.com
Reviso
Verso 1.0
Renato Willi renato.willi@gmail.com
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 pvggds@gmail.com
Ilustrao
Eduardo Bobsin Machado eduardo.bobsin@gmail.com
Traduo
Vincius Assef viniciusban@gmail.com
Cssio Marques cassiommc@gmail.com
lvaro Maia
Jos Incio Serafini serafini@sr.cefetes.br
Rafael Benevides rafabene@gmail.com
Rafael Recalde Caceres rafael.r.caceres@gmail.com
Fernanda Stringassi de Oliveira fernandasoliveira@yahoo.com
Renato Willi renato.willi@gmail.com
Rodrigo Palhano
Daniel Wildt dwildt@gmail.com
Francisco M. Soares Nt. xfrancisco.soares@gmail.com
Eduardo Bobsin Machado eduardo.bobsin@gmail.com
Juliana Berossa Steffen julianaberossa@gmail.com
Mauricio Vieira mauricio@mauriciovieira.net
Rodrigo Russo
Adam Victor Brandizzi brandizzi@gmail.com
Alexandre Gomes alegomes@gmail.com
Bruno Pedroso brunopedroso@gmail.com
Marcos Machado
Victor Hugo Germano victorhg@gmail.com
Acyr Jos Tedeschi
Emanoel Tadeu da Silva Freitas emanoeltadeu@gmail.com
Gustavo Grillo gustavogrillo@gmail.com
Israel Rodrigo Faria israel.faria@gmail.com
Marcos Vincius Guimares
Pablo Nunes Alves pablotj@gmail.com
Taiza Sousa
Apoio