FREE ONLINE EDITION

(non-printable free online version)

Trazido para voc como Cortesia de

Este livro distribudo gratuitamente no portal InfoQ.com. Se voc recebeu este livro de qualquer outra fonte, por favor, suporte o autor e o editor cadastrando-se em InfoQ.com.

Visite a pgina deste livro em:

http://infoq.com/br/minibooks/scrum-xp-fromthe-trenches

Scrum e XP direto das Trincheiras

Como fazemos Scrum

Escrito Por: Henrik Kniberg

 2007 C4Media Inc All rights reserved. C4Media, Publisher of InfoQ.com. Este livro parte da srie InfoQ de livros sobre Desenvolvimento de Software Corporativo. Para informaes sobre compra desse ou outros livros InfoQ, entre em contato com books@c4media.com. Nenhuma parte dessa publicao pode ser reproduzida, gravada em um sistema de busca e recuperao de dados ou transmitida sob qualquer forma ou por quaisquer meios, eletrnicos, mecnicos, fotocopiado, gravado, escaneado ou qualquer outro, sem prvia permisso do Publicador, exceto se autorizado pelas Sees 107 ou 108 da Lei de Copyright dos Estados Unidos de 1976. Designaes usadas por companhias para distinguir seus produtos so frequentemente conhecidas como marcas registradas. Em todos os locais onde a C4Media Inc. tem conhecimento desse fato, os nomes dos produtos aparecem com a letra inicial Maiscula ou TODAS AS LETRAS MAISCULAS. Os leitores, entretanto, devem contactar as respectivas empresas para informaes mais completas sobre suas marcas registradas. Editor: Diana Plesa / Felipe Rodrigues Tradutores: Vrios voluntrios gerenciados pela SEA Tecnologia Dados de Publicao-em-Catlogo da Biblioteca do Congresso Norte-Americano: 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. 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 PREFCIO EI, SCRUM FUNCIONOU! INTRODUO Termo de Responsabilidade Porque eu escrevi isso Mas o que Scrum? COMO FAZEMOS PRODUCT BACKLOGS Campos adicionais da estria COMO NS MANTEMOS O PRODUCT BACKLOG A NVEL DE NEGCIO COMO NOS PREPARAMOS PARA O PLANEJAMENTO DO SPRINT COMO PLANEJAMOS SPRINT POR QUE O PRODUCT OWNER DEVE PARTICIPAR POR QUE QUALIDADE NO NEGOCIVEL Reunies de planejamento do sprint que se arrastam sem fim Agenda da reunio de planejamento do sprint Definindo o tamanho do sprint Definindo o objetivo do sprint Decidindo quais estrias incluir no sprint Como o product owner afeta quais estrias estaro neste Sprint? Como a equipe decide que estrias incluir no sprint? Definio de pronto Estimativa de tempo usando planning poker Esclarecendo Estrias Quebrando estrias em estrias menores Dividindo estrias em tarefas Definindo a hora e lugar da reunio diria I III V 6 7 7 8 9 11 12 13 15 15 17 18 19 20 21 22 23 25 33 34 36 37 38 39

Onde traar a linha Estrias tcnicas Sistema de acompanhamento de bugs vs. product backlog A reunio de planejamento do sprint est finalmente terminada! COMO COMUNICAMOS SPRINTS COMO FAZEMOS OS SPRINT BACKLOGS Formato do sprint backlog Como funciona o quadro de tarefas Exemplo 1 depois da primeira reunio diria Exemplo 2 poucos dias depois Como funciona o grfico de burndown Sinais de alarme do quadro de tarefas Ei, e a rastreabilidade?! Estimando dias vs horas COMO ARRUMAMOS A SALA DA EQUIPE O canto do design Sente a equipe junta! Mantenha o product owner por perto Mantenha os gerentes e coaches por perto COMO FAZEMOS AS REUNIES DIRIAS Como atualizamos o quadro de tarefas Lidando com atrasados Lidando com o no sei o que fazer hoje COMO FAZEMOS APRESENTAES DE SPRINT Por que insistimos que todos os sprints terminem com uma apresentao Checklist para as apresentaes de sprint Lidando com coisas no demonstrveis COMO FAZEMOS RETROSPECTIVAS DE SPRINTS Por que insistimos que todas as equipes faam retrospectivas Como organizamos retrospectivas Divulgando lies aprendidas entre equipes Mudar ou no mudar Exemplos de coisas que podem aparecer durante as retrospectivas INTERVALO ENTRE SPRINTS COMO FAZEMOS O PLANEJAMENTO DE RELEASE E CONTRATOS COM PREO FIXO Defina seus critrios de aceitao

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

Faa estimativas de tempo para os itens mais importantes Estime velocidade Junte tudo num plano de release Adaptao do plano de release

73 75 76 77

COMO COMBINAMOS SCRUM E XP 78 Programao em par 78 Desenvolvimento Orientado a Testes (TDD) 79 Design incremental 82 Integrao contnua 82 Propriedade coletiva do cdigo 83 Ambiente de trabalho informativo 83 Padro de codificao 83 Ritmo Sustentvel / Trabalho energizado 84 Como fazemos testes 86 Voc provavelmente no vai conseguir eliminar a fase dos testes de aceitao86 Minimize a fase de testes de aceitao 87 Aumente a qualidade colocando os testadores na equipe Scrum 87 Aumentar a qualidade fazendo menos por Sprint 90 O teste de aceitao deveria fazer parte do sprint? 90 Ciclos de sprint vs. ciclos de testes de aceitao 91 No exponha o elo mais fraco de sua corrente 95 De volta realidade 96 COMO LIDAMOS COM VRIAS EQUIPES Quantas equipes criar Sincronizar sprints ou no? Por que criamos o papel de Lder de Equipe Como alocamos pessoas s equipes Equipes especializadas ou no? Reorganizar as equipes entre os sprints ou no? Membros de equipe em tempo parcial Como fazemos Scrum-de-Scrums Intercalando as reunies dirias Equipes de bombeiros Dividir o product backlog ou no? Fazendo Branching de cdigo Retrospectivas com vrias equipes COMO LIDAMOS COM EQUIPES DISTRIBUDAS GEOGRAFICAMENTE Equipes em outro pas Membros da equipe trabalhando em casa. 97 97 100 101 102 104 106 107 108 110 111 113 117 118 121 122 124

CHECKLIST DO SCRUM MASTER Comeando o sprint Todo dia Fim do Sprint LTIMAS PALAVRAS Leituras recomendadas Sobre o autor Sobre a Traduo

125 125 125 126 127 128 130 131

Prefcio por Jeff Sutherland

As equipes precisam conhecer o bsico do Scrum. Como voc cria e estima um product backlog? Como voc o transforma num sprint backlog? Como voc gerencia um grfico burndown e calcula a velocidade de sua equipe? O livro do Henrik um kit para iniciantes com prticas bsicas que ajudam equipes a irem alm de apenas tentativas de praticar o Scrum para execut-lo bem. Uma boa execuo do Scrum est se tornando mais importante para as equipes que buscam investimento de fundos externos. Como um mentor gil para um grupo de capital de risco, eu os ajudo a investirem em empresas que executam as prticas geis com eficincia. O Parceiro Snior do grupo tem perguntado a todas as empresas do portflio se elas conhecem a velocidade de suas equipes. Elas tm dificuldade em responder a essa questo de imediato. Oportunidades futuras de investimento iro exigir que as equipes de desenvolvimento saibam sua velocidade de produo. Por que isso to importante? Se as equipes no conhecem sua prpria velocidade, o product owner no pode criar um guia de produto com datas de releases com credibilidade. E sem datas de release interdependentes, a empresa poder falhar e os investidores podero perder seu dinheiro! Esse problema enfrentado por companhias grandes e pequenas, novas ou antigas, com investimento prprio ou externo. Numa discusso recente sobre a implantao do Scrum no Google, numa conferncia em Londres, eu perguntei s 135 pessoas presentes quantos deles estavam praticando Scrum, e 30 responderam positivamente. Ento eu perguntei se eles estavam fazendo o desenvolvimento iterativo usando os padres da Nokia. Desenvolvimento iterativo fundamental no Manifesto gil entregue software funcionando cedo e com freqncia. Depois de anos de retrospectivas com centenas de equipes de Scrum, a Nokia desenvolveu alguns requisitos bsicos para o desenvolvimento iterativo: As iteraes devem ter um tempo fixo com menos de seis semanas de durao. Ao final da iterao, o cdigo deve ser testado pelo CQ e funcionar corretamente. Das 30 pessoas que responderam estar usando o Scrum, apenas metade disse que estava atendendo o primeiro princpio do Manifesto gil pelos padres da Nokia. Ento eu perguntei se eles atendiam aos padres da Nokia para o Scrum:

ii | SCRUM E XP DIRETO DAS TRINCHEIRAS Uma equipe de Scrum deve ter um product owner e saber quem ele . O product owner deve ter um product backlog com estimativas criadas pela equipe. A equipe deve ter um grfico burndown e saber sua velocidade. No deve haver nenhuma interferncia externa sobre a equipe durante um sprint. Das 30 pessoas praticantes do Scrum, apenas 3 atendiam o teste da Nokia para identificar uma equipe de Scrum. Essas seriam as nicas que receberiam futuros investimentos dos meus parceiros. O valor do livro do Henrik que se voc seguir as prticas que ele recomenda, voc ter um product backlog, estimativas para o product backlog, um grfico burndown, e saber a velocidade de sua equipe, alm de outras prticas fundamentais para um Scrum altamente funcional. Voc passar no teste da Nokia e estar apto a receber investimento no seu trabalho. Se voc for uma empresa iniciante, poderia at receber investimento de um grupo de capital de risco. Voc pode ser o futuro do desenvolvimento de software e o criador da prxima gerao dos produtos lderes de mercado. Jeff Sutherland, Ph.D., Co-Criador do Scrum

Prefcio por Mike Cohn

Ambos Scrum e Extreme Programming (XP) pregam que a equipe complete alguma parte palpvel de trabalho que seja entregvel ao fim de cada iterao. Essas iteraes so pensadas para serem curtas e com espao de tempo definido. Este foco em entregas de cdigo funcionando em um curto espao de tempo significa que equipes Scrum e XP no tm tempo para teorias. Eles no perseguem o desenho do diagrama UML perfeito em ferramentas case, a escrita do documento de requsitos perfeito, ou a escrita do cdigo que poder acomodar todas as mudanas futuras imaginveis. Ao invs disso, equipes Scrum e XP focam em ter as coisas prontas. Essas equipes aceitam que cometem erros ao longo do caminho, mas tambm compreendem que o melhor modo de identificar esses erros parar de pensar sobre o software em um nvel terico de anlise e design e mergulhar fundo, sujar as mos e comear a construir o produto. esse mesmo foco em fazer ao invs de teorizar que distingue esse livro. E aparentemente Henrik Kniberg entende isso direito, desde o princpio. Ele no oferece uma longa descrio sobre o que Scrum; ele nos remete a alguns sites simples para isso. Ao invs disso, Henrik d um salto e comea imediatamente descrevendo como suas equipes gerenciam e trabalham com seu product backlog. Da, ele parte para todos os outros elementos e prticas de um projeto gil bem executado. Sem teorias, sem referncias. Sem notas de rodap. Nada disso necessrio. O livro de Henrik no uma explanao filosfica sobre por que Scrum funciona ou por que voc poderia querer experiment-lo. uma descrio de como uma boa equipe gil funciona. Eis o porqu do subttulo do livro, Como fazemos Scrum, ser to apropriado. Pode no ser o modo como voc faz Scrum, mas o modo como as equipes do Henrik fazem Scrum. Voc pode perguntar por que deveria se importar com a forma como outra equipe faz Scrum. Voc deveria se importar porque todos podemos aprender como fazer melhor Scrum ouvindo histrias de como foi feito por outros, especialmente aqueles que esto fazendo direito. No existe, e nunca existir uma lista de melhores prticas em Scrum, porque o contexto dos projetos e equipes descarta todas as outras consideraes. Ao invs de melhores prticas, o que precisamos conhecer so boas prticas e o contexto onde foram bem sucedidas. Leia histrias suficientes de equipes bem sucedidas e como elas fizeram as coisas e voc estar preparado para os obstculos que se apresentarem a voc e ao seu uso de Scrum e XP.

iv | SCRUM E XP DIRETO DAS TRINCHEIRAS Henrik prov as boas prticas e o contexto necessrio para nos ajudar a aprender melhor como fazer Scrum e XP, nas trincheiras dos seus projetos. 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. Esta a primeira vez que vi uma metodologia de desenvolvimento (desculpe Ken, um framework) funcionar diretamente de um livro. Plug n Play. Todos estamos felizes com isso desenvolvedores, testadores, gerentes. Nos ajudou a sair de situaes difceis e nos permitiu manter o foco e momentum, apesar das severas turbulncias de mercado e redues de pessoal. Eu no deveria dizer que estava surpreso, mas estava. Aps digerir inicialmente alguns livros sobre Scrum, me parecia bom, mas quase to bom para ser verdade (e todos ns conhecemos o ditado quando alguma coisa parece muito boa para ser verdade...). Ento eu estava justificadamente um pouco ctico. Mas aps fazer Scrum por um ano, estou suficientemente impressionado (e a maioria das pessoas nas minhas equipes tambm) que continuarei a usar Scrum como padro em novos projetos sempre que no haja uma forte razo para no us-lo.

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

apresentaes de sprint, diferentes formas de sincronizao de mltiplas equipes Scrum, etc. Tambm fizemos experimentos com prticas de XP diferentes formas de realizar a build contnua, programao em pares, desenvolvimento orientado a testes, etc, e como combin-los com Scrum. Este um processo de aprendizado contnuo, de modo que a estria no termina aqui. Estou convencido que esta empresa continuar aprendendo (se continuarem a realizar as retrospectivas dos sprints) e terem novos insights sobre como melhor implementar Scrum em seus contextos particulares.

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.

Porque eu escrevi isso

Quando estava aprendendo Scrum, li os livros relevantes sobre Scrum e agile, acessei muitos sites e fruns sobre Scrum, fiz a certificao do Ken Schwaber, perturbei-o com perguntas e passei muito tempo conversando com meus colegas. Uma das mais valiosas fontes de informao, entretanto, foram as histrias de guerra. As histrias de guerra transformam princpios e prticas em... bem... Como voc realmente faz isso. Elas tambm me ajudaram a identificar (e algumas vezes evitar) erros comuns de iniciantes em Scrum. 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!

Mas o que Scrum?

Oh, me desculpe. Voc completamente novo no Scrum ou XP? Neste caso talvez voc queira dar uma olhada nos seguintes links:

8 | SCRUM E XP DIRETO DAS TRINCHEIRAS http://agilemanifesto.org/ http://www.mountaingoatsoftware.com/scrum http://www.xprogramming.com/xpmag/whatisxp.htm 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. 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

10 | SCRUM E XP DIRETO DAS TRINCHEIRAS algum, aps quantos dias vocs apresentaro uma implementao pronta, demonstrvel e testada? Se a resposta for com 3 pessoas trancados em uma sala levar aproximadamente 4 dias ento a estimativa inicial de 12 pontos por estria. 2. O importante no ter estimativas absolutamente precisas (por exemplo, dizer que uma estria com 2 pontos dever gastar 2 dias), mas sim obter estimativas relativas corretas (por exemplo, dizer que uma estria com 2 pontos gastar cerca da metade de uma estria com 4 pontos). Como demonstrar Uma descrio em alto nvel de como a estria ser demonstrada na apresentao do sprint. Isso simplesmente uma simples especificao de teste. Faa isso, ento faa aquilo e ento isso dever acontecer. o Se voc pratica TDD (desenvolvimento orientado a testes) essa descrio pode ser usada como pseudocdigo para o seu cdigo de teste de aceitao. Notas quaisquer outras informaes, esclarecimentos, referncias a outras fontes de informao, etc. Normalmente gil bem breve. PRODUCT BACKLOG (exemplo) ID Nome Imp Est Como demonstrar 1 Depsito 30 5 Logar-se, abrir a pgina de depsito, depositar R$ 10,00, ir para a pgina do meu saldo e verificar que este aumentou em R$ 10,00. 2 Verificar 10 8 Logar-se, clicar em seu prprio transaes. Fazer histrico de um depsito. Voltar transaes para transaes, verificar se o novo depsito listado.

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.

Ns experimentamos com muitos outros campos, mas ao final do dia os seis campos acima eram os nicos realmente utilizados sprint aps sprint. Ns normalmente fazemos isso em um documento do Excel com compartilhamento habilitado (isso , mltiplos usurios podem edit-lo simultaneamente). Oficialmente o product owner o dono do documento, mas ns no queremos deixar os outros usurios de fora. Vrias vezes um desenvolvedor desejar abrir o documento para esclarecer algo ou alterar uma estimativa. Pela mesma razo, ns no mantemos este documento no repositrio de controle de verses, ns o colocamos em um drive compartilhado na rede. Essa a forma mais simples de permitir mltiplos editores simultneos sem causar conflitos de lock ou merge. Quase todos os outros artefatos, entretanto, so colocados no repositrio de controle de verses.

Campos adicionais da estria

Algumas vezes ns usamos campos adicionais no product backlog, principalmente como convenincia para ajudar o product owner na hora de decidir as priorizaes. Track (Tilha/Rastro) uma categorizao bsica dessa estria, por exemplo, back office ou otimizao. Dessa forma, o product owner pode facilmente filtrar por todos os itens de otimizao e definir sua prioridade para baixa, etc. Componentes Geralmente so includos campos na forma de checkboxes em um documento no Excel, por exemplo base de dados, servidor, cliente. Aqui a equipe ou o product owner podem identificar quais componentes tcnicos esto envolvidos na implementao dessa histria. Isto til quando se tem vrias equipes de Scrum, como por exemplo uma equipe de back office e outra de cliente, assim facilitando a deciso de cada equipe na escolha das estrias. Solicitante o product owner pode querer manter o rastro de qual cliente ou o stakeholder que solicitou o item, para poder fornecer um feedback sobre o progresso desse item. ID do bug se houver um sistema separado para registro de erros (bug tracking), como ns fazemos com o Jira, til manter a rastreabilidade da estria com um ou mais erros reportados sobre ela.

12 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Como ns mantemos o product backlog a nvel de negcio

Se o product owner tem uma formao tcnica, ele pode adicionar estrias como Adicionar ndice na tabela de eventos. Por que ele quer algo assim? O verdadeiro objetivo implcito provavelmente algo como acelerar o formulrio de pesquisa de eventos no back office. Pode ocorrer que os ndices no sejam os gargalos que causam a lentido no formulrio. Pode ser algo completamente diferente. A equipe normalmente melhor adaptada para descobrir como resolver algo, assim o product owner deveria focar-se nos objetivos de negcio. Quando vejo estrias com orientao tcnica como essa, normalmente eu pergunto ao product owner uma srie de questes de mas por qu, at encontrar o objetivo subjacente. Ento ns reformulamos a estria nos termos do objetivo subjacente (acelerar o formulrio de pesquisa de eventos no back office). A descrio tcnica original acaba virando uma nota (Indexar a tabela de eventos poderia resolver isso).

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

14 | SCRUM E XP DIRETO DAS TRINCHEIRAS invs de 20,5. Assim, deixe os espaos. bem mais prtico. O product owner deveria entender cada estria (normalmente ele o autor, mas em alguns casos outras pessoas adicionam requisitos, mas o product owner ainda precisa prioriz-los). Ele no precisa conhecer exatamente o que necessrio para implementar, mas ele deveria entender o porqu dessa estria estar ali. Nota: Outras pessoas alm do product owner podem adicionar estrias ao product backlog. Mas elas no podem associar uma escala de importncia. Esse um papel exclusivo do product owner. Eles tambm no podem estimar prazos. Essa uma tarefa exclusiva da equipe. A seguir, outras abordagens que ns tentamos ou avaliamos: Usar Jira (nosso sistema de bug tracking) para hospedar o product backlog. A maioria de nossos product owners acharam que era preciso dar muitos cliques para realizar as tarefas. Excel bom e fcil de manusear. Voc pode usar cores facilmente, reordenar os itens, adicionar novas colunas quando necessrio, adicionar notas, importar e exportar dados, etc. Usar uma ferramenta de suporte a processos geis, como VersionOne, ScrumWorks, XPlanner, etc. Ainda no testamos nenhuma delas, mas provavelmente faremos isso no futuro.

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.

Por que o product owner deve participar

s vezes, os product owners relutam em despender horas com a equipe fazendo planejamento do sprint. Pessoal, eu j listei o que eu quero. Eu no tenho tempo para estar na sua reunio de planejamento. Isto um problema muito grave. 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

Escopo e importncia so definidos pelo product owner. Estimativa definida pela equipe. Durante uma reunio de planejamento do sprint, estas trs variveis so refinadas continuamente por dilogo cara-a-cara entre equipe e product owner. Normalmente, o product owner inicia a reunio resumindo seu objetivo para o sprint e as estrias mais importantes. Em seguida, a equipe toma a frente e estima o tempo de cada estria, comeando pela mais importante. Ao fazer isto, eles vo se deparar com questes de escopo importantes esta estria apagar usurio inclui passar por cada transao pendente para o usurio e cancelar cada uma? Em alguns casos, as respostas sero surpreendentes para a equipe, fazendo com que eles mudem suas estimativas. Em alguns casos, a estimativa de tempo para uma estria no ser aquela que o product owner esperava. Isto poder faz-lo mudar a importncia da estria. Ou mudar o escopo da estria, que por sua vez far a equipe reestimar, etc., etc. Este tipo de colaborao direta fundamental para o Scrum e, de fato, todo o desenvolvimento gil de software. 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: Tento ajudar o product owner a entender por que a sua participao direta crucial e espero que ele mude de idia. Tento fazer com que algum da equipe se voluntarize a ser o intermediador do product owner. Diga ao product owner Como voc no pode participar de nossa reunio, ns deixaremos Jeff represent-lo como um intermediador. Ele ter plenos poderes para mudar as prioridades e escopo das estrias na sua ausncia durante a reunio. Eu sugiro que voc sincronize com ele o mximo possvel antes da reunio. Se voc no quiser que Jeff seja o seu intermediador, por favor sugira alguma outra pessoa,

COMO PLANEJAMOS SPRINT | 17 que possa se juntar a ns durante toda a durao da reunio. Tente convencer a equipe de gerenciamento a designar um novo product owner. Adie o lanamento do sprint at que o product owner ache tempo para se juntar reunio. Enquanto isto, se recuse a entregar qualquer coisa. Deixe a equipe passar cada dia fazendo aquilo que sentir ser mais importante para o dia.

Por que qualidade no negocivel

No tringulo acima, eu intencionamente evitei a quarta varivel qualidade. Eu tento distinguir entre qualidade interna e qualidade externa: Qualidade externa o que percebido pelos usurios do sistema. Uma interface de usurio lenta e no intuitiva um exemplo de baixa qualidade externa. Qualidade interna refere-se a questes que normalmente no so visveis ao usurio, mas que tm profundos efeitos na manutenibilidade do sistema. Coisas como consistncia do projeto do sistema, cobertura dos testes, facilidade de leitura do cdigo, refactoring etc. 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)

18 | SCRUM E XP DIRETO DAS TRINCHEIRAS Ento, como mostramos a diferena entre problemas de qualidade interna e problemas de qualidade externa? Digamos que o product owner diga OK pessoal, eu respeito sua estimativa de tempo de seis pontos de estria, mas eu tenho certeza de que vocs podem fazer algum tipo de quebra-galho para isso na metade do tempo se vocs se concentrarem nisso. 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... E por que ns no permitimos isso? Minha experincia que sacrificar qualidade interna quase sempre uma idia muito, muito ruim. O tempo economizado largamente superado pelo custo, tanto em curto quanto em longo prazo. Uma vez que se permita que uma base de cdigo se deteriore, muito difcil recuperar a qualidade mais tarde. Ao invs disso, eu tento levar a discusso para o escopo. J que conseguir essa feature mais cedo importante para voc, podemos reduzir o escopo de modo que seja mais rpido implement-la. Talvez possamos simplificar o tratamento de erros e fazer 'Tratamentos de erros avanados' numa estria separada, que reservamos para o futuro. Ou podemos reduzir a prioridade das outras estrias, de modo que possamos focar nessa. Que tal? Uma vez que o product owner tenha aprendido que qualidade interna no negocivel, ele geralmente se especializa em manipuar as outras variveis.

Reunies de planejamento do sprint que se arrastam sem fim

O mais difcil em reunies de planejamento de sprint o fato de: 1) As pessoas pensarem que elas no iro demorar tanto 2) ... mas elas demoram! Tudo no Scrum delimitado pelo tempo. Eu amo essa regra, simples e consistente. Tentamos nos ater a ela.

COMO PLANEJAMOS SPRINT | 19 Ento, o que devemos fazer quando o prazo estipulado para a reunio de planejamento do sprint est prestes a se esgotar e ainda no temos nem sinal de um objetivo do ou de um sprint backlog? Interrompemos a reunio?? Ou melhor estendermos a discusso por mais uma hora? Ou suspendemos temporiamente e continuamos no dia seguinte? Isso acontece vrias vezes, especialmente em equipes novatas no framework. Ento, o que voc faz? Eu no sei. Mas o que podemos fazer? Bem, geralmente eu interrompo a reunio abruptamente. Finalizo-a. Deixa o sprint sofrer as consequncias. Mais especificamente, eu digo equipe e ao product owner: ento, esta reunio terminar em 10 minutos. Ns no temos ainda o planejamento do sprint. Vamos trabalhar com o que temos ou vamos agendar outra reunio de 4 horas para amanh, a partir das 8 horas da manh?. Adivinha o que iro escolher :o) J tentei deixar a reunio rolar solta, extrapolando o prazo previsto. Geralmente, no resolve nada, pois as pessoas j esto cansadas. Se a equipe no conseguiu produzir um planejamento decente para o sprint em 2 ou 8 horas (ou seja l qual for a durao escolhida para sua reunio), provavelmente 1 hora a mais no ir resolver em nada o problema. A proposta de agendar uma nova reunio para o dia seguinte, seria bem razovel, se no fosse o fato de as pessoas geralmente j estarem impacientes para iniciar logo o sprint e no quererem perder mais tempo com horas de planejamento. Por isso, minha deciso de interromper mesmo a reunio. Deixa o sprint sofrer com isso. O lado bom disso que a equipe aprende uma boa lio, e a prxima reunio de planejamento do sprint ser bem mais eficiente. Alm disso, as pessoas sero menos resistentes quando voc propor um prazo para a reunio que outrora teria sido considerado muito longo. Aprenda a respeitar a delimitao do tempo e aprenda a defini-la de forma realstica. Isso se aplica tanto para prazos de reunies quanto para prazos de sprints.

Agenda da reunio de planejamento do sprint

Possuir algum tipo de cronograma para a reunio de planejamento do sprint reduzir o risco de ultrapassar o espao de tempo previsto. Eis um exemplo de um cronograma tpico.

20 | SCRUM E XP DIRETO DAS TRINCHEIRAS Reunio de planejamento do sprint: 13:00 17:00 (10 minutos de intervalo a cada hora) 13:00 13:30. O product owner repassa o objetivo do sprint e sumariza o product backlog. Definir lugar, data e hora da demonstrao. 13:30 15:00. A equipe estima o tempo e quebra os itens conforme necessrio. O product owner atualiza as taxas de importncia conforme necessrio. Os itens so esclarecidos. Como demonstrar preenchido para todos os itens de maior importncia. 15:00 16:00. A equipe escolhe as estrias a serem includas no sprint. Calculam a velocidade para verificar se o planejamento ficou realista. 16:00 17:00. Escolher data e lugar para a reunio diria (se no forem os mesmo do ltimo sprint). Complementar a quebra de estrias em tarefas. Esse cronograma no precisa, de forma alguma, ser seguido risca. O scrum master pode aumentar ou diminuir os tempos conforme necessrio, ao longo da reunio.

Definindo o tamanho do sprint

Uma das sadas da reunio de planejamento do sprint uma data definida para a apresentao. Isso significa que vocs precisam definir o tamanho do sprint. Ento, qual seria um bom tamanho de sprint? 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. Entretanto, sprints longos so bons tambm. A equipe tem mais tempo para ganhar ritmo, ela tem mais espao para se recuperar dos problemas, e conseguir atingir o objetivo do sprint, voc tem menos overhead em termos de reunies de planejamento, apresentaes, etc. No geral, product owners gostam de sprints curtos e desenvolvedores preferem os longos. Ento o tamanho do sprint representa um

COMO PLANEJAMOS SPRINT | 21 compromisso. Ns experimentamos bastante isso, e chegamos ao nosso tamanho favorito: 3 semanas. A maioria das nossas equipes (mas no todas) faz sprints de 3 semanas. Curtas o bastante para nos dar agilidade corporativa adequada, longas o bastante para a equipe conseguir fluidez e se recuperar de eventuais problemas durante o sprint. Uma coisa que conclumos foi: faa experimentos com o tamanho do sprint, no incio. No perca muito tempo analisando, apenas escolha um tamanho decente, e d-lhe uma chance por um sprint ou dois, ento mude o tamanho. 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.

Definindo o objetivo do sprint

Acontece quase toda vez. Em algum momento durante o planejamento do sprint, eu pergunto ento, qual o objetivo deste sprint? e todo mundo fica parado me olhando e o product owner franze a sobrancelha e coa o queixo. 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. O objetivo do sprint deve responder a pergunta fundamental Por que ns estamos fazendo este sprint? Porque no samos de frias ao invs de faz-lo?. De fato, uma maneira de extrair o objetivo de um sprint do product owner literalmente fazer esta pergunta.

22 | SCRUM E XP DIRETO DAS TRINCHEIRAS O objetivo deve ser algo que j no tenha sido atingido. Impressionar o CEO pode ser um objetivo timo, mas no se ele j est impressionado com o sistema atualmente. Neste caso, todos poderiam ir embora para a casa que mesmo assim o objetivo seria atingido. O objetivo do sprint pode parecer bobo e artificial durante o planejamento do sprint, mas freqentemente se torna til no meio dele, que quando as pessoas comeam a ficar confusas sobre o que elas deveriam estar fazendo. Se voc tem vrias equipes Scrum (como ns temos) trabalhando em produtos diferentes, muito til poder listar os objetivos de todas as equipes em uma nica pgina wiki (ou o que seja) e coloc-la em um local evidente para que todos na companhia (no somente a gerncia) saibam o que a empresa est fazendo e por qu!

Decidindo quais estrias incluir no sprint

Uma das principais atividades da reunio de planejamento do sprint decidir quais estrias incluir no sprint. Mais especificamente, quais estrias do product backlog copiar para o sprint backlog.

Observe a figura acima. Cada retngulo representa uma estria, ordenado pela importncia. A estria mais importante est no topo da lista. O tamanho de cada retngulo representa o tamanho daquela estria (ou seja, o tempo estimado nos pontos de estria). A altura do brao azul representa a velocidade estimada da equipe, ou seja, quantos pontos de estria a equipe acredita poder completar durante o prximo sprint.

COMO PLANEJAMOS SPRINT | 23 O sprint backlog da direita um snapshot das estrias do product backlog. Ele representa a lista de estrias que a equipe executar para o sprint. A equipe decide como as muitas estrias sero includas no sprint. No o product owner ou qualquer outra pessoa. Isso levanta duas questes: 1. Como fazer a equipe decidir quais estrias incluir no sprint? 2. Como pode o product owner afetar a deciso dela? Eu comearei com a segunda questo.

Como o product owner afeta quais estrias estaro neste Sprint?

Digamos que ns tenhamos a seguinte situao durante uma reunio de planejamento de sprint.

O product owner est desapontado com o fato de que a estria D no ser includa no sprint. Quais so as suas opes durante a reunio de planejamento do sprint? Uma opo reordenar a priorizao. Se ele der estria D a maior prioridade, a equipe ser obrigada a adicion-la ao sprint (neste caso tirando a estria C).

24 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Uma segunda opo mudar o escopo reduzir o escopo da estria A at que a equipe acredite que a estria D caber no sprint.

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.

Como v, mesmo que o product owner no possa alterar a velocidade estimada, h vrias formas como este pode influenciar quais estrias estaro presentes num sprint.

COMO PLANEJAMOS SPRINT | 25

Como a equipe decide que estrias incluir no sprint?

Utilizamos duas tcnicas para isso: 1. No sentimento/instinto 2. Clculo da Velocidade

Estimativa usando o sentimento ou instinto

Scrum master: Ol pessoal, podemos terminar a estria A neste Sprint? (apontando para o item mais importante no backlog de produtos) Lisa: D. Claro que podemos. Temos 3 semanas, e uma funcionalidade bastante trivial Scrum master: OK, e se incluirmos a estria B tambm? (apontando para o Segundo item mais importante) Tom & Lisa em unssono: Continua fcil Scrum master: OK, e que tal as estrias A, B e C? Sam (ao cliente): a estria C inclui os tratamentos avanados de erros? Cliente: no, podemos ignorar por enquanto, somente implemente o tratamento de erros bsicos Sam: ento C pode entrar tambm? Scrum master: OK, e se incluirmos a estoria D? Lisa: Hmm.... Tom: acredito que podemos faz-lo Scrum master: 90% certo? 50%? Lisa & Tom: Mais pra 90%. Scrum master: OK, ento D entra tambm. Que acham de incluirmos a estria E? Sam: Talvez. Scrum master: 90%? 50%? Sam: Perto de 50%. Lisa: Estou na dvida. Scrum master: OK, ento vai ficar de fora. Nos comprometemos com A, B, C e D. Se pudermos, terminaremos E tambm, mas ningum poder contar com isso, assim deixaremos fora do plano do sprint. Que acham disso? Todos: OK! O sentimento ou instinto funciona muito bem para pequenas equipes e sprint curtos.

26 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Estimativas usando clculos de velocidade

Essa tcnica envolve dois passos: 1. Defina a velocidade estimada. 2. Calcular quantas estrias voc pode adicionar sem exceder a velocidade estimada. Velocidade uma medida da quantidade trabalho realizado, onde cada item medido com base na sua estimativa inicial. A figura abaixo mostra um exemplo de velocidade estimada no incio de um sprint e a velocidade real no final do sprint. Cada retngulo uma estria, e o nmero dentro dele a estimativa inicial dela.

Note que a velocidade real baseada na estimativa inicial de cada estria. Quaisquer modificaes na estimativa de tempo da estria durante o sprint devem ser ignoradas. J posso ouvir voc dizendo: Como isso til? Maior ou menor velocidade depende de uma srie de fatores! Programadores inexperientes, estimativas iniciais incorretas, diminuio de escopo, problemas no previstos durante o sprint, etc.! Eu concordo, esse um nmero cru mesmo. Mas ainda assim uma medida til, especialmente quando no for comparado com nada mais. Ele te fornece alguns fatos fixos. Independentemente dos motivos, aqui est uma diferena aproximada de o quanto ns achvamos que gastaramos na atividade e o quanto realmente gastamos. 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 o livro Managing the Design Factory de Donald Reinertsen ou algum dos livros de Poppendieck para saber mais sobre o assunto. Ento, com que varinha mgica estimamos velocidade? Uma maneira muito simples de fazer isso olhar para o histrico da equipe. Qual foi a velocidade dela nos sprints mais recentes? Ento assuma que a velocidade nesse sprint ser equivalente. Essa tcnica conhecida como tempo de ontem. Isso s possvel para equipes que j tenham terminado alguns sprints (com as estatsticas disponveis) e faro o prximo praticamente da mesma forma com o mesmo nmero de membros e mesmas condies de trabalho, etc. Obviamente, nem sempre esse o caso. Uma variante mais sofisticada fazer um clculo simples de recursos. Vamos supor que estamos planejando um sprint de 3 semanas (15 dias de trabalho) com uma equipe de 4 pessoas. Lisa estar de folga por 2 dias. Dave est disponvel somente 50% e estar de folga por 1 dia. Colocando tudo isso junto...

... resulta em 50 homem-dias disponveis para este sprint. Ser esta a nossa velocidade estimada? No! Porque nossa unidade de estimativa pontos por estria, os quais, no nosso caso, correspondem a uma aproximao de homens-dia ideal. Um homem-dia ideal um dia perfeitamente efetivo, sem distrbios, o que raro. Alm disso, temos que levar em considerao coisas como o trabalho no planejado que adicionado ao sprint, pessoas que ficam doentes, etc. 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

O fator de foco uma estimativa de como a equipe focada. Um fator de foco baixo, pode significar que a equipe espera ter muitas interferncias ou percebe que suas prprias estimativas de tempo so otimistas. A melhor maneira para determinar um fator de foco razovel considerar o ltimo sprint (ou melhor ainda, a mdia de alguns sprints anteriores).

A velocidade atual a soma das estimativas iniciais de todas as estrias que foram finalizadas no ltimo sprint. Vamos supor que o ltimo sprint terminou 18 pontos por estria utilizando uma equipe de 3 pessoas, com Tom, Lisa e Sam trabalhando 3 semanas, resultando em um total de 45 homens-dia. E agora ns estamos tentando calcular nossa velocidade estimada para o prximo sprint. Para complicar as coisas, um cara novo, o Dave, est se juntando equipe para esse sprint. Levando em considerao as folgas e as obstrues ns temos 50 homem-dias para o prximo sprint.

Portanto, nossa velocidade estimada para o prximo sprint de 20 pontos por estria. O que significa que a equipe deveria adicionar estrias ao sprint at atingir uma soma de aproximadamente 20.

COMO PLANEJAMOS SPRINT | 29

Neste caso, a equipe talvez escolha as 4 primeiras estrias para obter um total de 19 pontos por estria, ou as 5 primeiras totalizando 24 pontos por estria. Vamos supor que eles escolham 4 estrias, visto que o mais prximo de 20 pontos por estria que se chega. Na dvida, selecione menos estrias. Como estas 4 estrias adicionaram 19 pontos por estria, a velocidade estimada final para este sprint 19. 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. E se a equipe for completamente nova e voc no tiver nenhuma estatstica? Olhe para o fator de foco de outras equipes em circunstncias similares. E se voc no tiver nenhuma outra equipe para olhar? Suponha um fator de foco. A boa notcia que o seu chute ser usando somente no primeiro sprint. Depois disto voc ter estatsticas e pode medir e melhorar continuamente seu fator de foco e a velocidade estimada.

30 | SCRUM E XP DIRETO DAS TRINCHEIRAS O fator de foco padro que eu uso para novas equipes usualmente 70%, porque este o ponto onde muitos de nossas outras equipes chegaram com o tempo.

Qual tcnica de estimativa ns usamos ?

Eu mencionei diversas tcnicas acima instinto/sentimento, clculo de velocidade baseado no tempo de ontem, e clculo de velocidade baseada no homens-dia disponveis e fator de foco. Ento, qual tcnica ns usamos ? Geralmente combinamos estas tcnicas em certas medidas. Realmente no toma muito tempo. Olhamos para o fator de foco e na velocidade atual do ltimo sprint. Olhamos para a disponibilidade total de nossos recursos disponveis e estimamos o fator de foco. Discutimos quaisquer diferenas entre estes fatores de foco e fazemos os ajustes necessrios. 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. Ao final do dia, o objetivo simplesmente decidir quais estrias ns incluiremos no sprint. Fator de foco, disponibilidade de recursos e velocidade estimada so apenas meios de atingir o objetivo.

Por que ns usamos cartes

A maior parte da reunio de planejamento do sprint gasto lidando com as estrias no product backlog. Estimando-as, repriorizando-as, esclarecendo-as, quebrando-as, etc. Como fazemos isso na prtica ? Bem, normalmente, as equipes ligam o projetor e mostram um backlog feito em Excel, ento um cara (tipicamente o product owner ou o scrum master) pega o teclado, esboa cada estria e estimula uma discusso. A medida que as prioridades e detalhes so discutidas pela equipe e pelo product owner, a pessoa ao teclado atualiza a estria direto no Excel.

COMO PLANEJAMOS SPRINT | 31 Parece bom? Bem, no . Normalmente um saco. E o que pior, a equipe normalmente no avisa que um saco at eles chegarem no fim da reunio e perceberem que ainda no conseguiram passar para lista de estrias! Uma soluo que funciona muito melhor criar cartes e coloc-los na parede (ou numa mesa grande).

Esta uma interface de usurio superior comparada a computador & projetor porque: Pessoas ficam em p e caminham => elas ficam acordadas e alerta por mais tempo. Todos se sentem mais pessoalmente envolvidos (ao invs de s o cara com o teclado). Mltiplas estrias podem ser editadas simultaneamente. A repriorizao trivial - s trocar a posio dos cartes. Aps a reunio, os cartes podem ser levados para a sala da equipe e ser usado como um quadro de tarefas na parede (veja pg 49 "Como ns fazemos o sprint backlog) Voc pode tanto escrev-los mo ou (como geralmente fazemos), quanto usar um script simples para gerar cartes imprimveis diretamente do product backlog.

32 | SCRUM E XP DIRETO DAS TRINCHEIRAS

PS o script est disponvel no meu blog em http://blog.crisp.se/henrikkniberg. Importante: Depois da reunio de planejamento do sprint, nosso scrum master atualiza manualmente o product backlog no Excel com respeito a quaisquer mudanas que foram feitas aos cartes fsicos de estrias. Sim, isso um pequeno inconveniente administrativo, mas ns achamos perfeitamente aceitvel considerando o quo mais eficiente a reunio de planejamento do sprint com cartes fsicos. Uma nota sobre o campo Importncia. Essa a importncia como especificado no product backlog do Excel no momento da impresso. Tlo no carto torna fcil ordenar os cartes fisicamente por importncia (normalmente colocamos os itens mais importantes esquerda, e os menos direita). Entretanto, uma vez que os cartes esto na parede, voc pode ignorar a classificao de importncia e usar a ordenao fsica na parede para indicar importncia relativa. Se o product owner troca dois itens, no perca tempo atualizando a classificao de importncia no papel. Certifique-se de atualizar a classificao de importncia no product backlog do Excel somente depois da reunio. Estimativas de tempo so mais fceis (e mais precisas) de fazer se a estria quebrada em tarefas. Ns usamos o termo atividade pois a palavra tarefa significa algo completamente diferente em sueco :o) Isso tambm bom e fcil de fazer com nossos cartes. Voc pode dividir a equipe em pares e cada um quebra uma estria, em paralelo. Fisicamente ns fazemos isso adicionando pequenas notas em post-it embaixo de cada estria, cada post-it refletindo uma tarefa dentro daquela estria.

COMO PLANEJAMOS SPRINT | 33

Ns no atualizamos o product backlog do Excel com respeito a nossas quebras em tarefas por duas razes: A quebra de tarefas geralmente bastante voltil, i.e. elas so freqentemente alteradas e refinadas durante o sprint, ento d muito trabalho manter product backlog do Excel sincronizado. O product owner no precisa estar envolvido neste nvel de detalhes, mesmo. Assim como com os cartes de estrias, os post-its de quebra de tarefas podem ser reusados diretamente no sprint backlog (veja pg. 49 Como fazemos os sprint backlogs).

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 definio feito deploy em servidor de teste e pronto para os testes de aceitao. No incio costumvamos ter checklists detalhados para isso. Atualmente ns frequentemente dizemos uma estria est pronta quanto o tester da equipe Scrum diz que est. responsabilidade do tester se certificar de que a inteno do product owner foi compreendida pela equipe e que o item est suficientemente pronto para que passe pela definio de pronto acordada. Ns percebemos que nem todas as estrias podem ser tratadas da mesma forma. Uma estria com o nome Formulrio para pesquisa de usurios ser tratada de forma muito diferente de uma estria com o nome Manual de operaes. No segundo caso, a definio de pronto pode simplesmente significar aceito pela equipe de operaes. por isso que o senso comum geralmente melhor do que checklists formais. Se voc frequentemente se confunde quanto definio de pronto (o que ocorreu conosco no incio) voc provavelmente deveria ter um campo definio de pronto para cada estria individual.

Estimativa de tempo usando planning poker

Estimar uma atividade da equipe cada membro freqentemente envolvido pra estimar cada estria. Por que? Quando vamos planejar, normalmente ns no sabemos exatamente quem vai implementar quais partes de quais estrias. Estrias normalmente envolvem diversas pessoas e diversos tipos de expertise (design de interface de usurio, codificao, teste, etc). Para prover uma estimativa, o membro da equipe precisa de algum tipo de entendimento do qu trata a estria. Pedindo para todos estimarem cada item, ns nos certificamos que cada membro da equipe compreende do que cada item se trata. Isso aumenta a probabilidade de que os membros se ajudaro durante o sprint. Isso tambm aumenta a probabilidade de que questes importantes sobre a estria surjam cedo. Quando pedimos que todos estimem uma estria, freqentemente descobrimos discrepncias onde duas pessoas da equipe tm estimativas bastante diferentes para a mesma estria. Esse tipo de coisa melhor ser descoberto e discutido o quanto antes.

COMO PLANEJAMOS SPRINT | 35 Se voc pedir equipe para que gere uma estimativa, normalmente a pessoa que melhor entende a estria ser a primeira a revelar a sua. Infelizmente, isso afetar fortemente as estimativas de todo o resto. H uma tcnica excelente para evitar isso ela chamada planning poker (cunhada por Mike Cohn, eu acho).

Cada membro da equipe recebe um baralho de 13 cartas como mostrado acima. Sempre que uma estria deve ser estimada, cada membro escolhe uma carta que representa a sua estimativa de tempo (em pontos por estria) e coloca-a virada para baixo sobre a mesa. Quando todos os membros da equipe tiverem feito sua estimativa, as cartas so reveladas simultaneamente. Dessa forma, cada membro da equipe forado a pensar por si prprio ao invs de basear-se na estimativa de outra pessoa. Se houver uma grande divergncia entre duas estimativas, a equipe discute as diferenas e tenta chegar a uma viso comum do trabalho envolvido na estria. Eles podem fazer algum tipo de decomposio de tarefas. Depois disso, a equipe faz novamente a estimativa. Esse processo repetido at que as estimativas de tempo cheguem a uma convergncia, isto , todas as estimativas sejam aproximadamente a mesma para cada estria. importante lembrar aos membros da equipe que eles devem estimar a quantidade total de esforo envolvido na estria. No somente a sua parte do trabalho. O testador no deve somente estimar a quantidade de esforo de teste. Note que a seqncia de nmeros no linear. For exemplo, no h nada entre 40 e 100. Por qu? Assim evita-se a falsa sensao de preciso para grandes estimativas de tempo. Se uma estria estimada em aproximadamente 20 postos por estria, no relevante se ela deve ser 20 ou 18 ou 21. Todos sabemos que uma estria grande e que difcil estimar. Portanto, 20 o nosso palpite aproximado. Quer estimativas mais detalhadas? Ento, quebre a estria em estrias menores e estime-as! E no, voc no pode trapacear combinando um 5 e um 2 para fazer um 7. Voc deve escolher 5 ou 8. No h um 7 nas cartas.

36 | SCRUM E XP DIRETO DAS TRINCHEIRAS Existem algumas cartas especiais: 0 = esta estria j est feita ou esta estria to pequena que leva somente alguns minutos de trabalho; ? = Eu no fao idia alguma; Xcara de caf = Estou cansado demais para pensar. Vamos fazer uma pequena pausa.

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 no, essa funcionalidade no dever ser parte do web site de forma alguma, isso dever ser apenas um script SQL para administradores tcnicos. A descrio de como demonstrar a estria pode e deve ser muito breve! Ou voc nunca vai encerrar a reunio de planejamento do sprint a tempo. Isso basicamente uma descrio por alto de como executar os mais tpicos testes de cenrio manualmente. Faa isso, faa aquilo, e verifique isso. Eu descobri que essa simples descrio cobre freqentes desentendimentos sobre o escopo da estria. Bom descobri-las cedo, certo?

Quebrando estrias em estrias menores

Estrias no deveriam ser muito pequenas nem muito grandes (em termos de estimativas). Se voc possui um grupo de estrias de 0.5 ponto, voc provavelmente ser uma vtima do microgerenciamento. Da mesma forma, uma estria de 40 pontos ter grande risco de terminar parcialmente completa, o que no produz valor sua empresa e apenas amplia a administrao. Ainda assim, se sua velocidade for 70 e as duas estrias de maior prioridade possuirem o peso de 40 pontos por estria cada, o planejamento torna-se um pouco difcil. Voc dever escolher entre comprometer-se pouco (ex. produzir apenas um item) ou comprometer-se demais (ex.produzir os dois itens). Descobrimos que quase sempre possvel quebrar uma estria em pedaos menores. Apenas tenha certeza de que as partes (estrias menores) ainda representam entregas com valor de negcio. Ns normalmente nos empenhamos para estrias estimadas em 2 - 8 homens-dia. Nossa velocidade geralmente entre 40 e 60 para uma equipe tpica, e isso nos d algo em torno de 10 estrias por sprint. Algumas vezes sero to poucas quanto 5 e outras vezes sero tantas quanto 15. Este um nmero gerencivel de cartes para se trabalhar.

Dividindo estrias em tarefas

Espere um momento, qual a diferena entre tarefas e estrias? Uma pergunta muito apropriada.

38 | SCRUM E XP DIRETO DAS TRINCHEIRAS A distino bem simples. Estrias so trabalhos que podem ser entregues e que o product owner tem que se preocupar. Tarefas so atividades que no podem ser entregues, ou atividades que o product owner no precisa se preocupar. Exemplo da diviso de uma estria em outras menores:

Exemplo da diviso de uma estria em tarefas:

Seguem aqui algumas observaes importantes: Equipes novas no Scrum so relutantes em gastar tempo dividindo um conjunto de estrias em tarefas como essas. Algumas sentem que essa uma abordagem em cascata. Para estrias que no foram claramente entendidas, to simples fazer essa diviso logo, ou mais tarde. Esse tipo de diviso freqentemente revela trabalho adicional que faz com que a estimativa de tempo aumente, mas por outro lado resulta em um planejamento do sprint mais realista. Esse tipo de diviso logo cedo torna as reunies dirias do scrum notavelmente mais eficientes (veja pgina 64 Como fazemos as reunies dirias). Mesmo que a diviso seja imprecisa e mude quando o trabalho iniciar, as vantagens acima ainda aplicam-se. Assim, ns tentamos fazer o espao de tempo do planejamento do scrum grande o bastante para acomod-la, mas se o tempo esgota-se, deixemos ela de lado (veja Onde desenhar a linha abaixo). Nota ns praticamos TDD (test driven development desenvolvimento orientado a testes) que na prtica significa que a primeira tarefa para quase todas as estrias escrever um teste de defeito e a ltima tarefa refazer (= melhorar a legibilidade do cdigo e remover duplicidades).

Definindo a hora e lugar da reunio diria

Uma sada frequentemente esquecida da reunio de planejamento de sprint hora e local para a reunio diria do scrum definidos. Sem isto, seu sprint ter um mau incio. A primeira reunio diria essencial para o lanamento onde todos decidem comear a trabalhar.

COMO PLANEJAMOS SPRINT | 39 Eu prefiro reunies matutinas. Mas, eu devo admitir, ns no tentamos fazer reunies dirias na tarde ou meio-dia.. Desvantagem de reunies vespertinas: quando voc for trabalhar de manh, voc tem que tentar se lembrar do que falou ontem para as pessoas sobre o que faria hoje. Desvantagem de reunies matutinas: quando voc for trabalhar de manh, voc tem que se lembrar do que fez ontem, pra que possa reportar isto. Na minha opinio, a primeira desvantagem pior, porque o mais importante o que voc vai fazer, no o que voc fez. Nosso procedimento padro selecionar o horrio mais cedo sem que ningum reclame. Normalmente 9:00, 9:30 ou 10:00. O mais importante que seja uma hora que todos da equipe aceitem completamente, de corao.

Onde traar a linha

OK, ento o tempo est acabando. De todas as coisas que queremos fazer durante a reunio de planejamento do sprint, o que ns devemos cortar, se o tempo acabar? Bem, eu uso a seguinte lista de prioridades: Prioridade 1: Um objetivo para o sprint e uma data para a realizao da demonstrao. Isto o mnimo que voc precisa para iniciar um sprint. A equipe tem um objetivo e uma data de trmino, e eles podem trabalhar a partir do product backlog. ruim, sim, e voc deve seriamente considerar o agendamento de uma nova reunio para planejamento do sprint para o dia seguinte, mas se voc realmente precisa iniciar o sprint, isto dever ajudar. Para ser honesto, eu nunca iniciei um sprint com esta pequena informao. Prioridade 2: Lista de estrias que a equipe aceitou trabalhar neste sprint. Prioridade 3: Preencha a informao de estimativa para cada estria do sprint.

40 | SCRUM E XP DIRETO DAS TRINCHEIRAS Prioridade 4: A informao Como demonstrar deve ser preenchida em cada estria do sprint. Prioridade 5: Clculos de velocidade e recursos, como uma verificao de realidade para o seu plano de sprint. Inclui lista de membros da equipe e o comprometimento deles (de outra forma no se consegue calcular velocidade). Prioridade 6: Hora e local especfico para a reunio diria. Se decide isto de forma muito rpida, mas se voc no tiver tempo o scrum master pode simplesmente decidir isto depois da reunio e pode avisar todos por email. Prioridade 7: Estrias quebradas em tarefas. Esta quebra pode ser feita diariamente, assim como as reunies dirias, mas isto vai gerar uma leve interrupo no fluxo do sprint.

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. Escrever um resumo do projeto do sistema o Por que necessrio: Porque os desenvolvedores insistem em esquecer-se do projeto geral e, em conseqncia, de escrever um cdigo consistente. Precisam de um documento do tipo resumo para manter todos na mesma linha de projeto. Refazer a camada DAO

COMO PLANEJAMOS SPRINT | 41 o Por que necessrio: Porque a camada DAO tem sido uma total desordem e tem tomado tempo de todos devido a essa confuso e aos bugs desnecessrios. Limpar esse cdigo vai economizar tempo de todos e aumentar a robustez do sistema.

Fazer o upgrade do Jira (bug tracker) o Por que necessrio: A verso atual tem muitos bugs e lenta. Fazer o upgrade vai economizar tempo de todos. Essas estrias fazem parte do senso comum? Ou elas esto conectadas com alguma estria especfica? Quem as prioriza? O product owner deveria envolver-se com essas coisas? Fizemos vrias experincias com diferentes maneiras de lidar com estrias tcnicas. Tentamos trat-las como estrias de primeira classe, como todas as outras. No funcionou bem. Quando o product owner priorizou o backlog, foi como comparar maas com laranjas. De fato, por razes obvias as estrias tcnicas obtinham sempre prioridade menor devido ao modo de pensar como: ok, pessoal, Estou certo de que um servidor de build contnuo importante, mas vamos atacar primeiro alguma coisa que possamos faturar! E ento podemos adicionar o brinquedo tecnolgico mais tarde, OK? 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 Exemplo (um dilogo muito semelhante este ocorreu durante uma de nossas reunies de planejamento do sprint.) Equipe: "Ns temos trabalho tcnico interno que precisa ser feito. Gostaramos de dedicar 10% do nosso tempo para faz-lo, por exemplo, reduzir o fator de foco de 75% para 65%. Tudo bem?" product owner: "De jeito nenhum! Ns no temos tempo!" Equipe: : "Bem, olhe para o ltimo sprint (todas as cabeas viram pra curva de velocidade no quadro branco). Nossa velocidade estimada era 80, a atual 30, certo?" PO: "Exatamente! Ento ns no temos tempo pra servio interno! Precisamos de novas caractersticas!" Equipe: "Bem, a razo de nossa velocidade ter se tornado to baixa foi que perdemos muito tempo tentando integrar verses funcionais para testes". PO: Sim, e? Equipe: Bem, nossa velocidade vai continuar sendo ruim se no fizermos alguma coisa sobre isso. PO: Sim, e? Equipe: "Ento ns propomos subtrairmos aproximadamente 10% deste sprint para configurar um servidor de produo e para cuidar de outras coisas que iro resolver os problemas de integrao. Isto provavelmente ir aumentar nossa velocidade de sprint em pelo menos 20% para cada sprint subsequente. Pra sempre!" PO: "Verdade? Ento por qu ns no fizemos isto no sprint passado?" Equipe: "Err porque voc no quis que fizssemos." PO: "Oh, hum, muito bem, parece uma boa idia fazermos isto agora ento!" 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?

COMO PLANEJAMOS SPRINT | 43

Sistema de acompanhamento de bugs vs. product backlog

Eis aqui uma armadilha. Excel um timo formato para o product backlog. Mas voc ainda precisa de um sistema de acompanhamento de bugs, e o Excel provavelmente no lhe atender. Ns usamos Jira. Ento, como ns levamos os defeitos registrados no Jira para as reunies de planejamento do sprint? Eu quero dizer que no devemos apenas ignor-los e focarmos apenas nas estrias. Ns tentamos vrias estratgias: 1) O product owner imprime os bugs prioritrios registrados no Jira, leva-os reunio de planejamento do sprint e afixa-os na parede junto com as outras estrias (especificando, desse modo, implicitamente, a prioridade desses itens em comparao com as outras estrias). 2) O product owner cria estrias que fazem referncia aos itens do Jira. Por exemplo: consertar os bugs mais crticos dos relatrios do back office, Jira-124, Jira-126 e Jira-180. 3) O concerto de bugs considerado fora do sprint, p.ex., a equipe mantm um fator de foco pequeno o suficiente (50%, por exemplo) para garantir que tenham tempo para consert-los. Assim, assumem que gastaro um certo perodo de tempo de cada sprint consertando os bugs. 4) Colocar o product backlog dentro do Jira (p.ex. descartar o Excel). Trate os bugs como qualquer outra estria. Ns ainda no conclumos qual dessas estratgias a melhor para ns. De fato, elas variam de equipe para equipe e de sprint para sprint. Eu sou propenso a apostar na primeira estratgia. Ela mais legal e mais simples.

A reunio de planejamento do sprint est finalmente terminada!

Uau, Eu nunca imaginei que este captulo sobre planejamento do sprint fosse ser to longo! Eu acho que isso reflete a minha opinio de que a reunio de planejamento do sprint a coisa mais importante que se faz no Scrum. Empenhe-se bastante para faz-la corretamente e todo o resto ser muito mais fcil.

44 | SCRUM E XP DIRETO DAS TRINCHEIRAS A reunio de planejamento do sprint obteve sucesso se todos (os membros da equipe e o product owner) sairem da reunio com um sorriso no rosto, acordam na outra manh com um sorriso e todos fazem a primeira reunio diria com um sorriso. 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. 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.

Alm disso, o scrum master imprime a pgina de informao do sprint e coloca no mural do lado de fora da sala da equipe. Ento todo mundo que passa pode v-la e descobrir o que a equipe fazendo. Desde que isso inclua o tempo e o lugar da reunio diria e da apresentao do sprint, se saber onde ir para descobrir mais. 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. 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.

Formato do sprint backlog

Ns j tentamos alguns formatos diferentes para o sprint backlog, incluindo Jira, Excel e um quadro de tarefas pregado na parede. No princpio ns usamos principalmente Excel. Existem vrios modelos prontos de sprint backlogs em Excel, incluindo grficos de burndown automticos e coisas do gnero. Eu poderia falar bastante como ns refinamos nossos sprint backlogs em Excel. Mas no farei isso. No vou nem incluir um exemplo aqui. Ao invs disso, irei descrever em detalhes o que ns temos visto ser o formato mais produtivo para o sprint backlog um quadro de tarefas pregado na parede! 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: claro que voc poderia usar um quadro branco. Mas seria um desperdcio. Se possvel, use os quadros-brancos para rascunhos de projeto e as outras paredes para os quadros de tarefas.

COMO FAZEMOS SPRINT BACKLOGS | 47 NOTA se voc usar post-its para tarefas, no esquea de col-los usando durex ou fita crepe mesmo, ou voc ir encontrar todos eles misturados no cho no dia seguinte.

48 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Como funciona o quadro de tarefas

Voc pode, claro, adicionar todo tipo de colunas adicionais. Esperando pelo teste de integrao por exemplo. Ou Cancelado. Entretanto antes de complicar as coisas, pense profundamente. Esta adio de coluna realmente necessria? Eu descobri que simplicidade extremamente vlida para este tipo de coisa, ento eu apenas adiciono complicaes quando o custo de no fazer muito alto.

Exemplo 1 depois da primeira reunio diria

Depois da primeira reunio diria, o quadro de tarefas vai parecer como este: Como se pode ver, trs tarefas foram selecionadas e colocadas em produo. A equipe vai trabalhar nestas tarefas hoje. s vezes, para equipes grandes, uma tarefa fica presa na etapa de produo pois ningum lembra quem estava trabalhando nela. Se isto acontecer de forma recorrente em uma equipe, normalmente se define uma poltica como rotular as tarefas em produo com o nome da pessoa que est trabalhando nela.

COMO FAZEMOS SPRINT BACKLOGS | 49

Exemplo 2 poucos dias depois

Poucos dias depois, o quadro de tarefas pode se parecer com algo assim:

Como pode ver, completamos a estria depsito (i.e. foi integrada ao repositrio com o cdigo fonte, testada, refatorada, etc). A ferramenta de migrao est parcialmente completa, a parte do login foi iniciada e a parte de administrao de usurios no comeou. Tivemos 3 itens no-planejados, como pode se ver na parte inferior direita. Guard-los til para que sejam lembrados quando voc for fazer a retrospectiva do sprint.

Eis um exemplo de um sprint backlog real perto do fim do sprint. Ele de fato fica meio bagunado com o andamento do sprint, mas isso est OK pois sua vida curta. A cada novo sprint, ns criamos um fresco, limpo e novo sprint backlog.

50 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Como funciona o grfico de burndown

Vamos dar um zoom no grfico de burndown:

Este grfico mostra que: No primeiro dia do sprint, 1 de agosto, a equipe estimou que havia aproximadamente 70 pontos por estria de trabalho a serem feitos. Isso foi na verdade a velocidade estimada de todo o sprint. Em 16 de agosto a equipe estimou que havia aproximadamente 15 pontos por estria de trabalho a serem feitos. A linha de tendncia tracejada mostra que eles esto aproximadamente dentro do prazo, isto , neste ritmo eles completaro tudo at o final do sprint Ns pulamos os finais de semana no eixo-x, uma vez que o trabalho raramente executado aos finais de semana. Ns costumvamos incluir finais de semana mas isso tornaria o grfico de burndown um pouco confuso, j que o mesmo ficaria reto nos finais de semana e isso poderia parecer um sinal de alarme.

COMO FAZEMOS SPRINT BACKLOGS | 51

Sinais de alarme do quadro de tarefas

Uma olhada rpida no quadro de tarefas daria a qualquer um uma indicao de quo bem o sprint est progredindo. O scrum master responsvel por garantir que a equipe haja quando surgirem sinais de alarme como:

52 | SCRUM E XP DIRETO DAS TRINCHEIRAS

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?

Estimando dias vs horas

Na maioria dos livros e artigos sobre Scrum, voc vai encontrar que as tarefas so estimadas em horas, e no em dias. Costumvamos fazer isto. Nossa formula geral era: 1 homem-dia = 6 horas-homem reais. Atualmente deixamos de fazer assim, pelo menos na maior parte de nosso grupo, pelas seguintes razes: As estimativas em homem-hora eram muito granulares, e isto provocava uma tendncia a estimar muitas tarefas de 1-2 horas e a conseqente micro gerencia. De qualquer forma, como todos estavam pensando em temos de homens-dias, e simplesmente multiplicavam por 6 antes de escrever homem-hora. Hmmmm, esta tarefa deve gastar um dia. Bom, tenho que escrever horas, ento escrevo 6 horas. Duas unidades diferentes podem causar confuso. Esta estimativa em homem-hora ou homem-dia? Assim, atualmente usamos o homem-dia para todas as nossas estimativas (embora continuemos chamando de pontos por estria - story points). Nosso menor valor 0,5, isto , qualquer tarefa que menor que 0,5 ser eliminada, combinada com outras tarefas ou receber o valor de 0,5. (No tem problema superestimar um pouco). Simples e elegante.

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

Acima: uma reunio diria acontecendo no canto mencionado.

Hmmmm..... aquele burndown parece suspeitosamente legal e direto, no. Mas a equipe insiste que real :o)

54 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Sente a equipe junta!

Com relao aos assentos e a organizao das mesas de trabalho h uma coisa que pode no ter sido reforada o suficiente:

Sente a equipe junta!

Para esclarecer um pouquinho mais, o que eu estou dizendo

Sente a equipe junta!

As pessoas so relutantes para mudar. Pelo menos nos lugares onde eu trabalhei. Eles no querem ter que juntar todas as suas coisas, desconectar o computador, mover todas as suas tralhas para uma nova mesa, e conectar tudo de novo. Quanto menor a distncia, maior a relutncia, Vamos l chefe, para que mudar somente 5 metros?. Mas quando estamos construindo equipes de Scrum eficientes no h outras alternativas. Somente mantenha a equipe junta. Mesmo que voc tenha que pessoalmente ameaar cada um, carregar todo o equipamento deles, e limpar suas velhas manchas de caf. Se no h espao para a equipe, crie um espao. Qualquer lugar. Mesmo se voc tiver que colocar a equipe no poro. Mova as mesas ao redor, suborne o gerente responsvel, faa o que for necessrio. Somente mantenha a equipe junta. 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). Agora o que junto significa? Como devem ser distribudas as mesas de trabalho? Bem, eu no tenho nenhuma opinio firme sobre a melhor distribuio das mesas. E mesmo que eu tivesse, eu acredito que a maioria das equipes no tenha o luxo de decidir exatamente como posicionar suas mesas de trabalho. Geralmente existem restries fsicas a equipe vizinha, a porta do banheiro, uma grande mquina caa-nqueis no meio da sala, o que for. 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 Visibilidade: Todos da equipe podem ver todos os demais. Cada um da equipe consegue ver o quadro de tarefas. No necessariamente perto o suficiente para l-lo, mas pelo menos para v-lo. Isolamento: Se toda equipe de repente levantar e se envolver em uma espontnea e animada discusso sobre implementao, no haver ningum de fora da equipe perto o suficiente para ser perturbado. E vice-versa.

"Isolamento" no significa que a equipe tenha que ficar completamente isolada. Em um ambiente de trabalho aberto e repartido em cubculos pode ser suficiente que a equipe tenha seu prprio cubculo com paredes altas o bastante para filtrar o mximo do barulho das outras equipes. 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.

Mantenha o product owner por perto

O product owner deve estar suficientemente perto para permitir que a equipe possa ir onde esta e perguntar qualquer coisa, e tambm para que ele possa ir ao quadro de tarefas. Mas ele no deve estar junto a equipe. Por que? Porque ele provavelmente no ser capaz de se controlar e no se meter em detalhes e a equipe no fluir adequadamente (isto , alcanar um estado focado, hiperprodutivo e auto-gerenciado) Para ser honesto, isto uma especulao. Nunca vi um caso em que o product owner esteve junto da equipe, de modo que no tenho nenhum motivo para dizer que no uma boa idia. s uma intuio pessoal e o que comentam outros scrum masters.

Mantenha os gerentes e coaches por perto

Isto um pouco difcil para escrever, pois fui tanto gerente quanto coach... Minha tarefa era trabalhar o mais prximo possvel da equipe. Formei os grupos, me movia entre eles, programava em pares com outras pessoas, ajudava outros scrum masters, organizava reunies de planejamento de sprint, etc. Fazendo um retrospecto, a maioria das pessoas considerou isso

56 | SCRUM E XP DIRETO DAS TRINCHEIRAS como uma Coisa Boa, j que tinha alguma experincia com o desenvolvimento gil de software. 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 autogerenciavel. 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! Meu ponto de vista : se voc um coach Scrum (e talvez tambm um gerente), envolva-se o mximo possvel. Porem s por uma perodo limitado de tempo, ento saia e deixe o grupo fluir e se auto-gerenciar. Verifique a equipe de vez em quando (no muito freqentemente) participando das apresentaes de sprint e observando o quadro de tarefas e escutando os scrum matinais. Se voc encontrar uma rea onde pode haver melhorias, rena-se com o scrum master e ajude-o. NUNCA em frente a equipe. Outra boa idia participar das retrospectivas do sprint (veja na pagina 77 Como fazemos as retrospectivas do sprint), desde que sua equipe confie suficientemente em voc para que sua presena no os iniba. 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. Ns normalmente fazemos as reunies em p, uma vez que isso reduz o risco de ultrapassar 15 minutos.

Como atualizamos o quadro de tarefas

Normalmente atualizamos o quadro de tarefas durante a reunio diria. Conforme cada pessoa descreve o que fez ontem e o que far hoje, vai colocando post-its no quadro de tarefas. Enquanto essa pessoa descreve um item no planejado, tambm cria um post-it para este item. Quando atualiza uma estimativa de prazo, atualiza a mesma no respectivo post-it escrevendo a nova e riscando a estimativa antiga. s vezes o scrum master faz o trabalho com os post-its enquanto as outras pessoas conversam.

Algumas equipes tm a poltica de que cada pessoa deve atualizar o quadro de tarefas antes de cada reunio. Isso tambm funciona bem. Apenas escolha uma poltica e se atenha a ela. Independente do formato em que seu sprint backlog est, tente fazer com que toda a equipe se envolva na tarefa de manter o sprint backlog atualizado. Ns tentamos realizar sprints onde o scrum master era o nico mantenedor do sprint backlog e todos os dias tinha que sair e perguntar as pessoas sobre suas estimativas de prazo. As desvantagens disso so:

58 | SCRUM E XP DIRETO DAS TRINCHEIRAS O Scrum master gasta tempo demais administrando essas coisas, ao invs de apoiando a equipe e removendo impedimentos. Os membros da equipe perdem a noo do status do sprint, uma vez que o sprint backlog no algo com o que eles precisem se preocupar. Essa falta de feedback reduz a agilidade e o foco da equipe. Se o sprint backlog for bem definido, cada membro da equipe poder atualiz-lo facilmente. Imediatamente aps a reunio diria do Scrum, algum totaliza todas as estimativas de prazo (obviamente, excluindo aquelas que estiverem na coluna de prontos) e marca um novo ponto no sprint burndown.

Lidando com atrasados

Algumas equipes possuem um pote de moedas e notas. Quando voc se atrasa, mesmo que apenas um minuto, voc coloca um valor prdeterminado no pote. Sem argumentao. Se voc ligar antes da reunio avisando que vai se atrasar, ainda assim tem que pagar. Voc s se livra dessa se tiver uma boa desculpa, como consulta mdica, seu prprio casamento ou algo do tipo. O dinheiro do pote usado para eventos sociais. Comprar sanduches quando temos noite de jogo, por exemplo. :o) Isso funciona bem. Mas s necessrio para equipes onde as pessoas se atrasam freqentemente. Algumas equipes no precisam desse tipo de mtodo.

Lidando com o no sei o que fazer hoje

No raro algum dizer "Ontem eu fiz bla bla bla, mas hoje eu no tenho a mnima ideia do que fazer " (ei, essa ultima parte rimou). E agora? Vamos dizer que Joe e Lisa so os que no sabem o que fazer hoje. Se eu sou scrum master, eu apenas passo e deixo a prxima pessoa falar, mas anoto a pessoa que no tem nada para fazer. Depois de todos terem falado, eu vou ao quadro de tarefas com toda a equipe, de cima para baixo, e verifico que tudo est em sincronia, que todos sabem o que cada

COMO FAZEMOS AS REUNIES DIRIAS | 59 item significa, etc. Eu convido as pessoas a adicionarem mais post-its. Ento eu volto para aquelas pessoas que no sabem o que fazer: "agora que ns passamos pelo quadro de tarefas, vocs tem alguma idia sobre o que vocs podem fazer hoje"? Tomara que tenham. Se no, eu avalio se h uma oportunidade de programao em par. Vamos dizer que Niklas est indo implementar a GUI de back office do usurio administrador hoje. Nesse caso eu educadamente sugiro que talvez Joe e Lisa possam fazer par com Niklas nisso. Normalmente funciona. E se aquilo no funcionar, aqui est o prximo truque. 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 tiver sorte, algum de fato ir mostrar a release que pediu. timo! Voc atingiu o objetivo do sprint. Mas e se estiver no meio do sprint? Fcil. Parabenize a equipe pelo trabalho bem feito, pegue uma ou duas estrias da seo prximos no seu quadro de tarefas e passe para a fazer esquerda. Ento refaa a reunio diria. Notifique o product owner que voc adicionou novos itens no sprint. Mas o que acontece se a equipe no alcanou o objetivo e Joe e Lisa ainda se recusam a fazer algo til. Eu normalmente considero uma das seguintes estratgias (nenhuma delas muito agradvel mas uma ltima alternativa): Vergonha: Bem eu no tenho nenhuma idia de como vocs podem ajudar a equipe mas acho que talvez vocs possam ir para casa, ler um livro ou alguma outra coisa. Ou apenas se sentar e ver se algum precisa de ajuda.. Velha-Escola: Apenas atribua-os uma tarefa.

60 | SCRUM E XP DIRETO DAS TRINCHEIRAS Presso do par: Diga Usem o tempo que for necessrio, Joe e Lisa. Ns todos estaremos esperando aqui sem pressa at que vocs possam arrumar algo que nos ajude a alcanar o objetivo. Servido: Diga Vocs podem ajudar a equipe indiretamente sendo mordomos hoje. Faam caf, massageiem as pessoas, limpem o lixo, cozinhem-nos algo para comer, e qualquer outra coisa que ns pedirmos durante o dia. Vocs se surpreendero em quo rapidamente Joe e Lisa se apresentaro para as tarefas tcnicas :o)

Se uma pessoa freqentemente te forar a tomar esse tipo de medidas, voc precisa remov-la do grupo e dar um srio treinamento. Se o problema persistir, voc deve avaliar o quanto a pessoa importante para a equipe. Se no for, tente remov-la da equipe. 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. 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!

Por que insistimos que todos os sprints terminem com uma apresentao
Uma apresentao de sprint bem feita, apesar disso poder parecer dramtico, tem um efeito profundo. A equipe ganha crdito por suas realizaes. Eles se sentem bem. Outros aprendem o que sua equipe est fazendo. A apresentao atrai feedback vital dos stakeholders. Apresentaes so (ou deveriam ser) um evento social onde equipes diferentes podem interagir umas com as outras e discutir seu trabalho. Isso tem muito valor. Fazer uma apresentao fora a equipe a realmente terminar as coisas e liber-las (mesmo que seja apenas em um ambiente de teste). Sem apresentaes, ns continuamos recebendo imensas pilhas de coisas 99% prontas. Com apresentaes ns podemos ter menos itens prontos, mas estes itens estaro realmente prontos, o que (no nosso caso) muito melhor do que termos uma pilha inteira de coisas que esto apenas parcialmente prontas e que iro poluir o prximo sprint. Se uma equipe mais ou menos forada a fazer uma apresentao do sprint mesmo no tendo muita coisa funcionando para ser mostrada, a apresentao ser constrangedora. A equipe ir gaguejar e tropear

62 | SCRUM E XP DIRETO DAS TRINCHEIRAS durante a apresentao e os aplausos no final sero fingidos. As pessoas se lamentaro pela equipe, alguns podem ficar irritados por terem perdido tempo indo uma apresentao ruim. Isso machuca. Mas o efeito como o de um remdio amargo. No prximo sprint, a equipe realmente tentar concluir as coisas! Eles pensaro talvez ns possamos demonstrar apenas 2 coisas no prximo sprint ao invs de 5, mas poxa, dessa vez elas iro funcionar!. A equipe sabe que de qualquer forma eles tero que fazer uma apresentao, o que aumenta significantemente a chance de que haja algo til para demonstrar. Eu vi isso acontecer muitas vezes.

Checklist para as apresentaes de sprint

Certifique-se de apresentar claramente o objetivo do sprint. Se houver pessoas na apresentao que no sabem absolutamente nada sobre seu produto, utilize alguns minutos para descrev-lo. No gaste muito tempo preparando a apresentao, especialmente evite enfeitar demais as apresentaes. Corte tudo que no interessa e foque-se apenas em demonstrar cdigo realmente funcionando. Mantenha um bom ritmo, isto , foque sua preparao em fazer com que a apresentao seja rpida ao invs de bonita. Mantenha a apresentao em um nvel orientado ao negcio, deixe de fora detalhes tcnicos. Foque em o que ns fizemos ao invs de como ns fizemos. Se possvel, deixe a audincia testar o produto. No demonstre um monte de correes de pequenos bugs e funcionalidades triviais. Mencione-as mas no as demonstre, j que isso geralmente leva muito tempo e desvia o foco das estrias mais importantes.

Lidando com coisas no demonstrveis

Membro da equipe: Eu no vou demonstrar esse item, porque isso no pode ser demonstrado. A estria Melhorar a escalabilidade para que o sistema possa suportar 10.000 usurios simultaneamente. Eu no posso preparar 10.000 usurios simultaneamente para uma apresentao, posso? Scrum master: Voc terminou a estria? Membro da equipe. Sim, claro. Scrum master: Como voc sabe?

COMO FAZEMOS AS REUNIES DIRIAS | 63 Membro da equipe: Eu configurei o sistema em um ambiente de teste de performance, iniciei 8 servidores de carga e disparei requisies simultneas contra o sistema. Scrum master: Mas voc tem alguma indicao de que o sistema iria suportar 10.000 usurios?. Membro da equipe: Sim. As mquinas de teste estavam com o limite insignificante, elas ainda poderiam suportar 50.000 requisies simultneas durante meu teste. Scrum master: Como voc sabe? Membro da equipe (frustrado): Bem, eu tenho esse relatrio! Voc mesmo pode ver, o relatrio mostra como o teste estava configurado e quantas requisies eu enviei! Scrum master: Oh excelente! Ento essa sua apresentao. Apenas mostre o relatrio e passe-o para a platia. Melhor do que nada, n?. Membro da equipe: Oh, isto suficiente? Mas isso feio, preciso melhor-lo.. Scrum master: OK, mas no gaste muito tempo. O relatrio no tem que estar bonito, apenas informativo.

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.

Como organizamos retrospectivas

O formato geral varia um pouco, mas geralmente ns fazemos assim:

COMO FAZEMOS RETROSPECTIVAS DE SPRINTS | 65 Ns alocamos 1 a 3 horas dependendo de quanto a discusso j estiver adiantada. Participantes: o product owner, a equipe toda, e eu mesmo (Scrum master). Ns vamos para uma sala fechada, ou um confortvel sof de canto, um terrao, ou algum outro lugar como estes. Onde ns pudermos no ter interrupes. Ns geralmente no fazemos retrospectivas no espao de trabalho da equipe, pois as pessoas tendem a perder a ateno. Algum designado como secretrio. O Scrum master mostra o sprint backlog e, com a ajuda da equipe, resume o sprint. Eventos e decises importantes, etc. Ns fazemos as rodadas. Cada pessoa tem a chance de dizer, sem ser interrompido, o que eles acharam que foi bom, o que eles acharam que poderia ter sido melhor, e o que eles gostariam de fazer de forma diferente no prximo sprint. Ns comparamos a velocidade estimada com a velocidade realizada. Se existir uma grande diferena ns tentamos analisar o motivo. Quando o tempo j est quase acabado, o Scrum master tenta resumir as sugestes concretas sobre o que ns poderemos fazer melhor no prximo sprint.

Nossas retrospectivas no so geralmente muito estruturadas. Mas o tema subjacente sempre o mesmo: o que ns podemos fazer melhor no prximo sprint. Aqui est um quadro de exemplo de uma retrospectiva recente: 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; Assim sendo, as colunas 1 e 2 olham pro passado enquanto que a coluna 3 olha pro 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 durante o prximo sprint. A cada membro da equipe foi dado trs ms e foram convidados a votar em quaisquer das melhorias que gostariam que a equipe priorizasse para execuo durante o prximo sprint. Cada membro da equipe poderia distribuir os ms como quisesse, at mesmo colocar todos no mesmo item. Baseado nisso, selecionaro cinco melhorias de processo para dar ateno e verificaro isso durante a prxima retrospectiva do sprint. importante no ser ambicioso demais nesse momento. Mantenha o foco somente em algumas melhorias por sprint.

Divulgando lies aprendidas entre equipes

A informao que surge durante uma retrospectiva do sprint normalmente muito valiosa. Esta equipe est com dificuldades de foco por que o gerente de vendas est sequestrando programadores para participarem como "especialistas tcnicos" em reunies de vendas? Esta uma informao importante. Quem sabe outras equipes estejam tendo os mesmos problemas? Deveramos educar mais o gerente de produtos a respeito de nossos produtos, para que ele possa ser o apoio s vendas? Uma retrospectiva de sprint no diz respeito a apenas como uma nica equipe pode fazer um bom trabalho para o prximo sprint. Possui implicaes muito maiores que isso. 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. Regras importantes para uma pessoa "ponte de conhecimento": Deve ser um bom ouvinte Se a retrospectiva estiver em muito silncio, ele deve estar preparado para fazer perguntas simples mas estratgicas para estimular a discusso do grupo. Por exemplo: "se voc pudesse retornar no tempo e refazer o mesmo sprint por 1 dia, o que seria feito diferente?"

COMO FAZEMOS RETROSPECTIVAS DE SPRINTS | 67 Deve estar disposto a investir tempo visitando todas as retrospectivas de todas as equipes. Deve estar em algum tipo de posio de autoridade, para que possa agir em sugestes melhorias que estejam fora do controle da equipe. Isto funcionou perfeitamente bem, mas podem existir outras abordagens que funcionariam muito melhor. Neste caso, por favor me elucide.

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.

Exemplos de coisas que podem aparecer durante as retrospectivas

Aqui vo alguns exemplos de situaes comuns que podem aparecer durante o planejamento do sprint, e algumas aes.

68 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Ns deveramos ter gasto mais tempo quebrando as estrias em sub-itens e tarefas

Isto bem comum. Todos os dias na reunio diria, membros da equipe se pegam dizendo: Eu realmente no sei o que fazer hoje. Ento aps cada reunio diria voc gasta mais tempo tentando encontrar as tarefas concretas. Geralmente mais eficaz adiar isto para um momento mais oportuno. Aes tpicas: Nenhuma. A equipe provavelmente encontrar uma soluo por ela mesma durante o prximo planejamento do sprint. Se isto acontece frequentemente, aumente o tempo do planejamento do sprint.

Interferncias externas demais

Aes tpicas: pea equipe para reduzir o fator de foco no prximo sprint, assim tero um plano mais realista pea equipe para recordar melhor as interferncias no prximo sprint. Quem interrompeu, quanto tempo tomou. Ser mais fcil resolver o problema depois. pea equipe para concentrar as interferncias no scrum master ou product owner pea equipe para designar uma pessoa para ser o goleiro. Todas as interrupes sero repassadas ele, assim o resto da equipe pode se concentrar. Pode ser o scrum master ou ser revezado entre o resto.

Ns nos comprometemos com coisas demais e s metade est pronta

Aes tpicas: nada. A equipe provavelmente no vai se comprometer com coisas demais no prximo sprint. Ou no mnimo no errar por tanto.

Nosso ambiente barulhento e bagunado demais

Aes tpicas: tente criar um ambiente melhor, ou tire a equipe do local. Alugue um quarto de hotel, Qualquer coisa. Veja pg 59 Como arrumamos a sala da equipe ). Se no for possvel, diga equipe para diminuir o fator de foco no prximo sprint, e deixar claro que isso se deve ao ambiente barulhento e bagunado. Espera-se que que isto faa o product owner tomar alguma atitude sobre isto.

COMO FAZEMOS RETROSPECTIVAS DE SPRINTS | 69 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. 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.

COMO FAZEMOS O PLANEJAMENTO DE RELEASE E CONTRATOS COM PREO FIXO |71 Melhor: 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? Atualmente ns temos um lab day por ms. Especificamente, a primeira sexta-feira de cada ms. Por que no entre os sprints? Bem, porque eu senti que era importante para a empresa toda ter o lab day ao mesmo tempo. De outra forma, as pessoas tendem a no levar isso muito a srio. E j que ns no temos os sprints de todos os produtos alinhados, eu tive que selecionar um lab day independente dos sprints. Um dia ns poderamos tentar sincronizar os sprints de todos os produtos (p.ex., a mesma data de incio e fim dos sprints para todos os produtos e equipes). Nesse caso, ns colocaramos o lab day entre cada 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.

Defina seus critrios de aceitao

Alm do product backlog, o product owner define uma lista de critrios de aceitao, que uma simples classificao do que os nveis de importncia no product backlog realmente significam em termos do contrato. Aqui est um exemplo de regras para critrios de aceitao: Todos os itens com importncia >= 100 devem ser includos na verso 1.0, caso contrrio seremos mortalmente penalizados. Todos os itens com importncia entre 50 e 99 deveriam ser includos na verso 1.0, mas ns devemos ser capazes de conclulos em um release subsequente feito rapidamente. Itens com importncia entre 25 e 49 so necessrios, mas podem ser feitos em release 1.1 subsequente.

COMO FAZEMOS O PLANEJAMENTO DE RELEASE E CONTRATOS COM PREO FIXO |73 Itens com importncia < 25 so especulativos e podem at mesmo nunca vir a ser necessrios. E aqui est um exemplo de um product backlog, codificado em cores com base nas regras acima. Importncia 130 120 115 110 100 95 80 70 60 40 35 10 10 Nome banana ma laranja goiaba pra passa amendoim donut cebola framboesa mamo mirtilo pssego

Vermelho = deve ser includo na verso 1.0 (banana - pra) Amarelo = deveria ser includo na verso 1.0 (passa - cebola) Verde = pode ser feito mais tarde (framboesa - pssego) Logo se ns entregarmos tudo entre banana e cebola dentro do prazo, estamos a salvo. Se o tempo encurtar ns podemos deixar de entregar passa, amendoim, donut ou cebola. Tudo abaixo disso bnus.

Faa estimativas de tempo para os itens mais importantes

Afim de fazer o planejamento de release o product owner precisa de estimativas, ao menos para todas as histrias que esto inclusas no contrato. Assim como no planejamento do sprint, este um esforo cooperativo entre o product owner e a equipe a equipe estima, o product owner descreve os itens e responde questes.

74 | SCRUM E XP DIRETO DAS TRINCHEIRAS Uma estimativa de tempo valiosa ao se mostrar perto do correto, menos valiosa ao se distanciar, digamos, por um fator de 30% e completamente sem valor se no possuir qualquer conexo com a realidade. Aqui est um exemplo do valor de uma estimativa de tempo em funo de quem fez os clculos e de quanto tempo eles gastaram fazendo isso.

Tudo isso foi apenas uma maneira complicada de dizer: Deixa a equipe fazer as estimativas. No faa com que eles gastem tempo demais. Certifique-se de que eles tenham entendido que as estimativas de tempo so estimativas cruas, no compromissos. Normalmente o product owner rene toda a equipe em uma sala, fornece algumas distraes e lhes diz que o objetivo da reunio fazer uma estimativa de tempo para as 20 estrias mais importantes no product backlog (ou algo do tipo). Ele passa por cada estria uma vez e ento deixa a equipe trabalhar. O product owner permanece na sala para responder perguntas e esclarecer o escopo de cada item conforme necessrio. Assim como no planejamento de sprint, o campo como apresentar uma maneira bastante til de diminuir o risco de equvocos. Esta reunio deve ocorrer dentro de um intervalo de tempo fixo, caso contrrio as equipes tendem a gastar tempo demais estimando poucas estrias. Se o product owner desejar que mais tempo seja gasto nessa tarefa, ele simplesmente agenda outra reunio para mais tarde. A equipe deve se certificar de que o impacto destas reunies nos seus sprints seja claramente visvel para o product owner, para que ele possa compreender que o trabalho de estimativas de tempo possui um custo. Imp 130 120 115 110 100 95 80 70 60 40 35 10 10 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 Aqui est um exemplo de como estimativas de tempo devem terminar (em pontos por estria):

COMO FAZEMOS O PLANEJAMENTO DE RELEASE E CONTRATOS COM PREO FIXO |75

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.

76 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Junte tudo num plano de release

Agora que temos estimativas de tempo e uma velocidade (45) podemos facilmente fatiar o product backlog em sprints: Imp 130 120 115 110 100 95 80 70 60 40 35 10 10 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

Cada sprint inclui tantas estrias quanto possvel sem exceder a velocidade estimada de 45. Agora podemos ver que precisaremos de provavelmente 3 sprints para terminar todos os deve ter e os deveria ter. 3 sprints = 9 semanas = 2 meses. essa a deadline que prometemos ao cliente? Depende completamente da natureza do contrato; quo fixo o escopo, etc. Muitas vezes adicionamos um buffer significante para nos proteger de ms estimativas, problemas inesperados, funcionalidades inesperadas, etc. Neste caso devemos acordar em uma entrega para daqui a 3 meses, nos dando um ms de reserva. O lado bom que podemos demonstrar algo usvel para o cliente a cada 3 semanas e convid-lo a mudar os requisitos conforme vamos avanando (claro que dependendo de como o contrato).

COMO FAZEMOS O PLANEJAMENTO DE RELEASE E CONTRATOS COM PREO FIXO |77

Adaptao do plano de release

A realidade no se adaptar ao plano, ento o plano deve adaptar-se realidade. Aps cada sprint, observamos a velocidade para aquele sprint. Se a velocidade atual foi muito diferente da velocidade estimada, revisamos a velocidade estimada para os sprints futuros e atualizamos o plano de release. Se isso nos deixar em apuros, o product owner pode ento negociar com o cliente ou verificar como reduzir o escopo sem descumprir o contrato. Tambm pode ser que ele e a equipe descubram alguma maneira de aumentar a velocidade ou o fator de foco, atravs da remoo de alguns impedimentos graves que foram identificados durante o sprint. O product owner pode ligar para o cliente e dizer Ol, ns estamos um pouco atrasados, mas acredito que podemos entregar no prazo simplesmente removendo a funcionalidade Pacman embutido que leva um grande tempo de desenvolvimento. Se voc quiser, poderemos adicion-la em um release posterior, 3 semanas aps o primeiro release. 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)

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

COMO COMBINAMOS SCRUM E XP | 79 Programao em par aumenta o foco da equipe (por exemplo: quando o par lhe diz: Ei, estas coisas realmente so necessrias para este sprint?) Surpreendentemente muitos desenvolvedores que so fortemente contra programao em par nunca tentaram antes e rapidamente aprendem a gostar uma vez que experimentam. Programao em par cansativa e no deve ser feito todos os dias Trocar os pares freqentemente bom. Programao em par nivela o conhecimento da equipe. Surpreendentemente de forma rpida tambm. Algumas pessoas simplesmente no se sentem confortveis com programao em par. No jogue fora um excelente programador simplesmente porque ele no se sente confortvel com programao em par Reviso de cdigo uma alternativa vlida para a programao em par. O navegador (o cara que no est digitando) deve ter um computador para si prprio. No para ser usado no desenvolvimento, mas para pequenas atividades quando necessrio, navegar na documentao enquanto o piloto (o cara nos teclados) o espera, etc. No force as pessoas a praticarem a programao em par. Encoraje as pessoas e fornea as ferramentas corretas, mas deixeas experimentar por si mesmas.

Desenvolvimento Orientado a Testes (TDD)

Amm! Isso para mim mais importante que Scrum e XP. Voc pode tirar minha casa, minha TV e meu cachorro, mas no tente me fazer parar de usar TDD! Se voc no gosta de TDD ento no me deixe no recinto, porque eu vou tentar fazer isso passar de um jeito ou de outro :o) Aqui vai um sumrio de 10 segundos de TDD: Desenvolvimento orientado a testes significa que voc escreve um teste automatizado, ento escreve apenas cdigo suficiente para faz-lo passar, ento voc refatora o cdigo primeiramente para melhorar a legibilidade e remover duplicao. Enxague e repita.

Algumas reflexes sobre o desenvolvimento orientado a testes. TDD difcil. Leva um tempo para o programador pegar o jeito. Na verdade, em muitos casos no importa quanto voc ensina, treina e

80 | SCRUM E XP DIRETO DAS TRINCHEIRAS

demonstra - em muitos casos a nica maneira de um programador "pegar o jeito" fazendo ele programar em par com algum que bom em TDD. Contudo, uma vez que pega o jeito, normalmente severamente infectado e nunca mais ir querer trabalhar de outra forma. TDD tem um efeito profundamente positivo no design do sistema. Leva tempo para deixar o TDD efetivamente pronto e funcionando em um novo produto, especialmente em testes de integrao de caixa-preta, mas o retorno de investimento rpido. Tenha certeza que voc investe o tempo necessrio para tornar mais fcil escrever os testes. Isso significa obter as ferramentas certas, educar as pessoas, prover o utilitrio de classes ou base de classes certo, etc. Ns usamos as seguintes ferramentes para desenvolvimento orientado a testes. JUnit / httpUnit / jWebUnit. Estamos considerando TestNG e Selenium. HSQLDB como BD embutido na memria para fins de teste. Jetty como container web embutido na memria para fins de testes. Cobertura para mtricas de cobertura de testes. Spring framework para ligao dos diferentes tipos de fixtures de teste (com mocks, sem mocks, com banco de dados externo, com banco de dados na memria, etc).

Em nossos produtos mais sofisticados (da perspectiva do TDD) ns automatizamos os testes e aceitao fechados. Esses testes carregam o sistema todo na memria, incluindo bases de dados e servidores web, e acessam o sistema usando apenas as interfaces pblicas (por exemplo HTTP). Dessa forma ns aceleramos muito os ciclos de desenvolvimento-buildteste. Esse ambiente tambm funciona como uma rede de segurana, dando aos desenvolvedores a confiana suficiente para refatorar com freqncia, o que significa que o projeto mantem-se limpo e simples medida que o sistema cresce.

TDD em cdigos novos

Ns usamos o TDD para todo novo desenvolvimento, mesmo que o incio do projeto demore mais (j que precisamos de mais ferramentas e suporte para os testes. uma dose de no-brainer, os benefcios so to grandes que no h nenhuma desculpa para no praticarmos o TDD.

COMO COMBINAMOS SCRUM E XP | 81

TDD em cdigos j existentes

TDD difcil, mas tentar aplic-lo numa base de cdigo que no foi construda visando o TDD desde o princpio... realmente muito difcil! Por que? Bem, na verdade, eu poderia escrever muito sobre isso, mas acho que vou parar aqui. Vou tratar disso num prximo artigo meu TDD from the Trehches :o) Ns gastamos bastante tempo tentando automatizar os testes de integrao num dos nossos sistemas mais complexos. Os cdigos foram bastante mexidos e estavam bastante bagunados e completamente desprovidos de teste. Para cada verso do sistema ns temos uma equipe dedicada de testadores que fazem um conjunto completo de testes de regresso e performance. Os testes de regresso so normalmente trabalho manual. Isso atrasa bastante o ciclo de desenvolvimento e liberao da verso. Nosso objetivo automatizar esses testes. Depois de termo batido nossas cabeas contra o muro alguns meses, no chegamos muito perto do que queramos. Depois disso, mudamos nossa abordagem. Ns aceitamos o fato de que estvamos estagnados nos testes manuais de regresso e, ao invs disso, deveramos estar nos perguntando Como posso fazer esse processo de testes manuais ficar mais rpido? Isso era um jogo, e ns constatamos que muito trabalho de teste da equipe foi gasto fazendo tarefas triviais de instalao como navegar no back office para configurar tournments para os propsitos dos testes, ou esperando pelo agendamento de um tournament para comear. Ento ns criamos utilidades para isso. Pequenas, de fcil acesso como atalhos e scripts que dispensavam o trabalho duro e deixava o foco nos testes efetivamente. Esse esforo realmente se pagou. Na verdade, isso provavelmente o que deveramos ter feito desde o incio. Ns estvamos to ansiosos em automatizar os testes que esquecemos de fazer o passo a passo, onde o primeiro passo seria fazer os testes manuais mais eficientes. Lio Aprendida: se voc estiver estagnado com os testes manuais de regresso, e quiser automatizar desse jeito, no o faa (a menos que isso seja realmente muito fcil). Ao invs disso, construa coisas que faam os testes de regresso mais fceis. A sim considere automatizar o teste efetivo.

82 | SCRUM E XP DIRETO DAS TRINCHEIRAS

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.

COMO COMBINAMOS SCRUM E XP | 83

Propriedade coletiva do cdigo

Ns encorajamos a propriedade coletiva do cdigo mas ainda nem todas as equipes tm adotado esse mtodo de trabalho. Descobrimos que a programao em pares (pair programming) com a mudana freqente dos pares leva automaticamente a um maior nvel de propriedade coletiva de cdigo. As equipes com essa caracterstica tm provado ser muito robustas, o sprint delas, por exemplo, no morre apenas porque algum importante ficou doente.

Ambiente de trabalho informativo

Todas as equipes tm acesso aos quadros brancos e a uma parede vazia e fazem um bom uso desses recursos. Na maioria das salas voc encontrar as paredes preenchidas com todo tipo de informao sobre o produto e o projeto. Assim, o maior problema passa a ser o lixo antigo acumulado nas paredes. Por isso deveramos introduzir o papel do faxineiro em cada equipe. Encorajamos o uso do quadro de tarefas, mas nem todas as equipes ainda o adotaram. Veja na pgina 59 Como ns organizamos a sala da equipe.

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: Voc pode quebrar qualquer uma dessas regras, mas tenha a certeza que por uma boa razo e documente isso.

84 | SCRUM E XP DIRETO DAS TRINCHEIRAS Use a conveno de codificao da Sun como padro:

http://java.sun.com/docs/codeconv/html/CodeConvTOC. doc.html

Nunca, jamais, nem pense em capturar excees sem logar o stack trace ou rethowing. log.debug() uma boa, mas no perca o stack trace. Use a dependncia baseada em mtodos setter para desacoplar as classes umas das outras. (exceto quando um acoplamento forte for desejvel). Evite abreviaes. Abreviaes bem conhecidas como DAO so bem-vindas. Os mtodos que retornam collections ou arrays no devem retornar nulo. Retorne colees ou arrays vazios ao invs de nulo.

Ritmo Sustentvel / Trabalho energizado

Muitos livros sobre desenvolvimento gil de software dizem que horasextras so anti-produtivas no desenvolvimento de software. Aps algumas experincias relutantes com isso eu s posso concordar plenamente com eles! H aproximadamente um ano atrs uma de nossas equipes (a maior delas ) estava trabalhando horas extras excessivas. A qualidade do software legado era horrvel e eles tinham que gastar boa parte do tempo apagando incndios. A equipe de teste (que tambm estava fazendo horas extras) no tinha chance de fazer nenhuma garantia de segurana. Nossos usurios estavam furiosos e os relatrios internos queriam comer-nos vivos. Depois de alguns meses ns tnhamos negociado cargas horrias menores e mais decentes. Pessoas trabalhando cargas horrias normais (exceto durante alguns picos eventuais no projeto). E, surpresa, produtividade e qualidade notveis. 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. 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.

Voc provavelmente no vai conseguir eliminar a fase dos testes de aceitao

No mundo Scrum ideal, um sprint resulta em um verso potencialmente instalvel do seu sistema. Ento s instalar, certo? Errado. Nossa experincia que isso na verdade no funciona. Haver bugs desagradveis. Se a qualidade tem qualquer tipo de valor para voc, necessrio algum tipo de fase de testes de aceitao manuais. nessa hora que testadores dedicados que no fazem parte da sua equipe martelam o sistema com aqueles tipos de testes que a equipe Scrum no imaginou, ou no teve tempo para fazer, ou no tiveram o hardware necessrio para fazer. Estes testadores acessam o sistema exatamente da mesma forma que os usurios finais, o que significa que eles devem ser realizados manualmente (assumindo que seu sistema seja feito para usurios humanos).

86 | SCRUM E XP DIRETO DAS TRINCHEIRAS

A equipe de testes encontrar bugs, a equipe Scrum ter que produzir releases para correo de bugs e mais cedo ou mais tarde (espera-se que mais cedo) voc estar apto para liberar uma verso 1.0.1 sem bugs aos usurios finais, ao invs de entregar uma verso 1.0.0 instvel. Quando eu digo fase de testes de aceitao eu estou me referindo a todo o perodo de teste, debug e re-release at que exista uma verso boa o bastante para ser colocada em produo.

Minimize a fase de testes de aceitao

A fase de testes de aceitao machuca. Ela principalmente no-gil. Apesar de no podermos elimin-la, ns podemos (e devemos) minimizla. Mais especificamente, minimizar a quantidade de tempo necessria para a fase de testes de aceitao. Isso pode ser afeito: Maximizando a qualidade do cdigo entregue pela equipe Scrum Maximizando a eficincia do trabalho de teste manual (isto , encontrar os melhores testadores, dar-lhes as melhores ferramentas, certificar-se de que eles lhe avisam quando houver tarefas que consomem muito tempo e que podem ser automatizadas Ento, como ns maximizamos a qualidade do cdigo entregue pela equipe Scrum? Bem, existem diversas maneiras. Aqui esto duas que ns achamos que funcionam muito bem: Coloque os testadores na equipe Scrum Faa menos a cada sprint

Aumente a qualidade colocando os testadores na equipe Scrum

Sim, eu costumo escutar as duas objees:
Mas isso bvio! Equipes Scrum devem ser multi-funcionais! Equipes Scrum no devem possuir cargos! Ns no podemos ter um cara que apenas

COMO FAZEMOS TESTES | 87 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 Desenvolvedores so quase sempre maus testadores. Especialmente desenvolvedores que testam o seu prprio cdigo.

O testador o cara que aprova

Alm de ser apenas mais um membro da equipe, o testador tem uma importante funo. Ele o cara que aprova. Nada considerado 'pronto em um sprint at que ele diga que est. Eu descobri que desenvolvedores frequentemente dizem que algo est pronto quando na verdade no est. Mesmo que voc tenha uma definio de pronto muito clara (o que realmente deveria ser o caso, veja pgina 34 Definio de pronto), desenvolvedores freqentemente iro se esquecer disso. Ns programadores somos pessoas impacientes e queremos sempre passar para a prxima etapa o mais rpido possvel. 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. Um interessante efeito colateral disso que agora a equipe tem uma pessoa que perfeitamente apta para organizar a apresentao do sprint.

O que o testador faz quando no h nada para testar?

Essa pergunta sempre vem tona. Sr. T: Scrum master, no tenho nada para testar agora, o que mais eu posso fazer?. Ainda vai demorar uma semana para que a equipe termine a primeira estria. Ento, o que o testador poderia fazer nesse perodo?

88 | SCRUM E XP DIRETO DAS TRINCHEIRAS Bem, antes de tudo, ele deveria estar se preparando para os testes. Ou seja, escrevendo as especificaes de teste, preparando um ambiente de testes, etc. Assim, quando um desenvolvedor liberar alguma funcionalidade para ser testada, no haveria nenhuma espera. O sr. T poderia comear o teste imediatamente. Se a equipe est usando TDD, as pessoas ocupam tempo escrevendo cdigos de teste desde o primeiro dia. O testador deveria fazer par com os desenvolvedores que esto escrevendo esses cdigos de teste. Se o testador no sabe programar, ele ainda assim deveria fazer par com os desenvolvedores, a menos que ele apenas navegue e deixe o desenvolvedor digitar. Um bom testador normalmente adiciona tipos diferentes de testes aos de um bom desenvolvedor. Assim, um complementa o outro. Se a equipe no est usando TDD, ou se no h casos de teste suficientes para ocupar todo o tempo do testador, ele deveria simplesmente fazer o possvel para ajudar a equipe alcanar o objetivo do sprint. Igual a qualquer outro membro da equipe. Se o testador sabe programar ento timo. Se no, sua equipe ter que identificar as tarefas extra programao que devem ser feitas no sprint. Quando voc quebrar as estrias em tarefas, durante a reunio de planejamento do sprint, a equipe tende a focar nas tarefas de programao. Entretanto, normalmente existem muita outras que no so programao e que tambm precisam ser feitas no sprint. Se voc investir tempo tentando identificar as tarefas que no so programao durante a fase de planejamento do sprint, as chances de o sr. T contribuir so muito grandes, mesmo que ele no programe e que no haja nenhum teste para fazer agora. Exemplos de tarefas necessrias ao sprint, mas que no so programao: Preparar um ambiente de teste. Esclarecer requisitos. Discutir detalhes de deploy com a operao. Escrever documentos de deploy (release notes, RFC, ou qualquer outro que sua empresa use). Contatar recursos externos (projetistas de interface com usurio, por exemplo). Melhorar os scripts de build. Mais quebras de estrias em tarefas. Identificar perguntas-chave dos desenvolvedores e conseguir a resposta para elas.

COMO FAZEMOS TESTES | 89 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! Resumindo, sim, o sr. T tem um papel especial na equipe, mas ele tambm pode fazer outras coisas. E os outros membros da equipe tambm podem fazer o trabalho dele.

Aumentar a qualidade fazendo menos por Sprint

Voltando reunio de planejamento do sprint. Colocando de forma simples, no coloque muitas estrias no sprint! Se voc tem problemas de qualidade, ou longos ciclos de aceitao, faa menos por sprint! Isso ir meio que automaticamente elevar a qualidade. Menores ciclos de teste para aceitao, menos bugs afetando o usurio, e maior produtividade ao longo da caminhada. Isso pois a equipe poder focar nas novas coisas ao invs de ficar consertando coisas velhas que vivem quebrando. 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.

O teste de aceitao deveria fazer parte do sprint?

Ns variamos muito aqui. Algumas de nossas equipes incluem o teste de aceitao no sprint. Porm, a maioria delas, no. Por duas razes: Um sprint tem um limite de tempo. Testes de aceitao (Usando minha definio que inclui debugar e re-instalar), so muito difceis de se mensurar o tempo. O que fazer se o tempo se esgotar e voc ainda tiver um bug crtico? Voc vai lanar uma release com um bug crtico? Voc vai esperar at o prximo sprint? Na maioria dos casos ambos so inaceitveis. Ento deixe o teste manual de aceitao de lado. Se voc tem vrias equipes trabalhando no mesmo produto, o teste manual de aceitao deve ser seguido combinado com o trabalho de ambas equipes. Se ambas fizeram o teste manual de aceitao dentro do tempo do sprint, voc ainda precisa de uma

90 | SCRUM E XP DIRETO DAS TRINCHEIRAS equipe para fazer o teste final de release, que a integrao do trabalho das equipes.

Isso pode no significar a soluo perfeita mas boa o suficiente pra gente na maioria dos casos.

Ciclos de sprint vs. ciclos de testes de aceitao

Idealmente, no mundo perfeito do Scrum, voc no precisa de testes de aceitao, uma vez que as releases geradas ao final de cada sprint j esto prontas para a produo.

Bem, no bem assim. Segue um esquema mais realista:

COMO FAZEMOS TESTES | 91

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.

92 | SCRUM E XP DIRETO DAS TRINCHEIRAS

No encontramos ainda nenhuma soluo simples para este problema, apesar de j termos experimentado diferentes modelos. Primeiro de tudo, novamente, maximize a qualidade do cdigo que a equipe gera. O custo de encontrar e corrigir bugs cedo, durante o sprint, extremamente menor se comparado ao mesmo custo aps o trmino da iterao. De qualquer forma, permanence o mesmo fato. Ainda que minizemos a quantidade de bugs, haver registros de bugs aps o sprint ter sido finalizado. Como lidar com isso?

Abordagem 1: No inicie a construo de coisas novas antes das coisas antigas estarem em produo
Parece bom no? Voc tambm sentiu aquele sentimento aconchegante de incerteza? Ns estivemos prximos de adotar esta abordagem diversas vezes, e desenhamos modelos requintados sobre como poderamos fazer isto. Entretanto sempre mudamos de idia quando visualizamos o lado negativo disto. Ns teramos que adicionar um perodo de liberao sem um espao de tempo fixo entre cada sprint, onde faramos apenas teste e depurao at que pudssemos realizar um release em produo.

COMO FAZEMOS TESTES | 93 Ns no gostamos da noo de ter perodos sem espao de tempo fixo entre os sprints, principalmente porque isto iria quebrar o ritmo que a equipe possui nos sprints. Ns no poderamos mais dizer que a cada 3 semanas ns iniciamos um novo sprint. Alm do que, isto no resolve completamente o problema. Mesmo que tivssemos um perodo de release, vo aparecer relatos de defeitos urgentes de tempos em tempos, e precisamos estar preparados para tratar deles.

1. Abordagem 2: OK para comear a implementar novas funcionalidades, mas priorizar colocar as coisas antigas em produo
Esta nossa abordagem preferida. Pelo menos at agora. Basicamente quando terminamos um sprint, ns vamos para o prximo. Mas esperamos gastar algum tempo deste prximo sprint consertando coisas do ltimo sprint. Se os prximos sprints se tornarem severamente prejudicados por causa do gasto excessivo de tempo na correo de bugs do ltimo sprint, ns avaliamos por que isto aconteceu e como podemos melhorar a qualidade. Ns procuramos ter a certeza de que sprints so duradouros o suficiente para no serem impactados por um punhado de tempo gasto concertando bugs do sprint anterior. Gradualmente, aps um perodo de muitos meses, a quantidade de tempo gasto consertando bugs do sprint anterior diminuiu. Assim nos tornamos hbeis em escalar menos pessoas envolvidas quando estes bugs acontecem, e nem toda equipe precisa ser incomodada todas as vezes. Agora estamos em um nvel mais aceitvel.

Durante as reunies de planejamento do sprint, ns ajustamos o fato de foco baixo o suficiente para considerar o tempo que gastamos concertando os bugs do ltimo sprint. Com o tempo, as equipes se tornaram bastante eficazes em fazer esta estimativa. A mtrica de velocidade ajuda muito (veja pgina 25 Como a equipe decide quais estrias so includas no sprint?)

94 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Abordagem ruim foco em construir novas coisas

Este efeito significa foco em construir novas coisas ao invs de colocar as coisas antigas em produo. Quem gostaria de fazer isto? Mesmo assim cometemos este erro de vez em quando no comeo, e eu tenho a certeza de que muitas empresas fazem o mesmo. uma doena relacionada a presso do projeto. Muitos gerentes realmente no compreendem que quando toda a codificao terminar, voc geralmente estar longe do release de produo. Pelo menos para sistemas complexos. Ento o gerente (ou product owner) pede para a equipe continuar adicionando novas funcionalidades enquanto a mochila de cdigo das coisas quase prontas se torna cada vez mais e mais pesada, diminuindo a velocidade de tudo.

No exponha o elo mais fraco de sua corrente

Digamos que o teste de aceitao seja o seu elo mais fraco. Voc tem pouqussimos testadores ou o perodo de testes demora mais devido baixa qualidade do cdigo. Digamos que a equipe de testes de aceitao possa testar no mximo 3 funcionalidades por semana (no, ns no usamos funcionalidades por semana como mtrica; s estou dando um exemplo). E digamos que seus desenvolvedores produzam 6 novas funcionalidades por semana. tentador para os gerentes ou product owners (ou talvez mesmo para a equipe) prever o desenvolvimento de 6 novas funcionalidades por semana. No faa isso! A realidade ir peg-lo de um modo ou de outro. E vai machuc-lo. Ao invs disso, planeje 3 novas funcionalidades por semana e invista o restante do tempo para aliviar o gargalo de testes. Exemplo: Aloque alguns desenvolvedores como testadores (Ah, eles iro am-lo por isso). Implemente ferramentas e scripts que facilitem os testes. Adicione mais cdigo que automatize os testes. Aumente o tamanho do sprint e tenha os testes de aceitao includos nele. Defina alguns sprints como sprints para teste onde a equipe inteira atuar como uma equipe de testes de aceitao. Contrate mais testadores (mesmo que isso signifique dispensar alguns desenvolvedores).

COMO FAZEMOS TESTES | 95 Ns temos usado todas essas alternativas (exceto a ltima). As melhores solues a longo prazo so obviamente a 2 e 3, isto , melhores ferramentas e scripts para automao dos testes Anlises retrospectivas so um bom frum para identificar o elo mais fraco de sua corrente.

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

Quantas equipes criar

Se lidar com vrias equipes to difcil, por que vamos nos incomodar? Por que simplesmente no colocar todos na mesma equipe? A maior equipe de scrum que ns tivemos tinha aproximadamente 11 pessoas. Ela funcionava, mas no muito bem. Reunies dirias tendiam a durar mais de 15 minutos. Os membros da equipe no sabiam o que os membros das outras equipes estavam fazendo, e isso gerava confuso. Era muito dificil para o scrum master manter todos alinhados ao objetivo, e dificil de encontrar tempo de enderear todos os obstculos que eram reportados. A alternativa era dividir em duas equipes. Mas isso melhor? No necessariamente. Se a equipe tem experincia e confortvel com o Scrum, e h um jeito lgico de dividir o roadmap em duas pistas diferentes, e essas duas pistas no envolvem o mesmo cdigo fonte, ento eu deveria dizer que uma boa idia dividir a equipe. De outra forma eu optaria por manter a equipe nica, a despeito das desvantagens de uma grande equipe.

COMO LIDAMOS COM VRIAS EQUIPES | 97 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.

O que isso significa? Que sua estratgia de diviso de equipes estava errada? Sim, se as equipes virtuais parecerem permanentes. No, se as equipes virtuais parecerem temporrias.

98 | SCRUM E XP DIRETO DAS TRINCHEIRAS Olhe novamente para o exemplo 1. Se as duas sub-equipes virtuais tendem a mudar de vez em quando (por exemplo, as pessoas vo de uma sub-equipe para outra) ento provavelmente voc tomou a deciso certa ao mant-las como uma nica equipe. Se as duas sub-equipes virtuais mantm-se as mesmas durante todo o sprint, talvez voc queira separ-las em duas equipes reais no prximo sprint. Agora olhe novamente para o exemplo 2. Se as equipes 1 e 2 esto conversando entre si (e no com a equipe 3) durante todo o sprint, talvez voc queira combinar as equipes 1 e 2 em uma nica equipe no prximo sprint. Se as equipes 1 e 2 esto conversando muito entre si durante a primeira metade do sprint e ento as equipes 1 e 3 comeam a conversar durante a segunda metade do sprint, ento voc deve considerar a possibilidade de combinar as trs equipes em uma, ou ento deix-las como trs equipes. Cite esta questo durante a retrospectiva do sprint e deixe que as equipes decidam por si. Diviso de equipes das partes realmente difceis do Scrum. No pense ou se esforce demais em otimizao. Experimente, observe as equipes virtuais e certifique-se que voc tem tempo suficiente para discutir esse tipo de coisa durante as retrospectivas. Mais cedo ou mais tarde voc encontrar a soluo correta para o seu caso. O importante que as equipes estejam confortveis e no fiquem trombando umas na outras com freqncia.

Tamanho de equipe ideal

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

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.

Sincronizar sprints ou no?

Digamos que voc tenha trs equipes trabalhando no mesmo produto. Os sprints delas deveriam ser sincronizados, p.ex. comear e terminar juntos? Ou eles deveriam se sobrepor? Nossa primeira escolha foi ter sprints sobrepostos (com respeito ao tempo).

Essa situao parece boa. A qualquer momento haveria um sprint perto de terminar e um outro quase comeando. O trabalho do product owner estaria diludo durante todo o tempo. Haveria releases jorrando continuamente do sistema. Apresentaes toda semana. Aleluia! Esse cenrio realmente me pareceu convincente!

100 | SCRUM E XP DIRETO DAS TRINCHEIRAS Ns comeamos assim, at que um dia eu tive a oportunidade de conversar com Ken Schwaber (na poca de minha certificao em Scrum). Ele me mostrou que essa era uma pssima idia, que seria muito melhor sincronizar os sprints. Eu no lembro direito os motivos, mas depois de debatermos um pouco, ele me convenceu.

Essa a soluo que temos usando desde ento, e eu nunca me arrependi disso. Eu nunca saberei se os sprints sobrepostos funcionariam, mas acho que no. As vantagens dos sprints sincronizados so: Existe naturalmente um tempo para rearranjar as equipes entre os sprints! Com a sobreposio, no h como rearranjar uma equipe sem atrapalhar pelo menos uma outra, no meio do sprint. Todas as equipes podem trabalhar com o mesmo objetivo num sprint e fazer as reunies de planejamento juntas, o que promove melhor colaborao entre as equipes. Menos sobrecarga administrativa, p.ex., menos reunies de planejamento, sprint demos e releases.

Por que criamos o papel de Lder de Equipe

Digamos que temos um nico produto e trs equipes.

O sujeito de vermelho (P) o product owner. Os caras de preto (S) so os Scrum masters. Os outros so pees... quer dizer... respeitveis membros da equipe.

COMO LIDAMOS COM VRIAS EQUIPES | 101 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...)? E se mais tarde chega-se a concluso que impossvel ter mais do que duas equipes trabalhando em paralelo no mesmo cdigo e precisarmos transformar as trs equipes de seis pessoas em duas de nove. Ou seja, apenas dois Scrum masters. Qual dos trs ser devidamente exonerado? Em muitas empresas essas so questes delicadas. extremamente tentador entregar a alocao e realocao dos recursos nas mos do product owner. Mas isso no coisa de product owner, certo? O product owner o especialista no domnio que d o norte a equipe. Ele no deve se envolver nos pequenos detalhes. Especialmente porque um frango (se voc no conhece a metfora dos porcos e frangos digite chickens and pigs no Google). Ns resolvemos essa questo criando um papel de Lder de Equipe. Esse papel corresponde ao que chamamos de Scrum master dos Scrums masters ou o chefo ou Scrum master senior etc. Ele no lidera nenhuma equipe especfica mas responsvel por resolver problemas entre as equipes, como quem ser o Scrum master da equipe, como as pessoas devem ser divididas entre as equipes, etc. No foi fcil achar um nome para esse papel, Lder de Equipe foi o menos pior. Essa soluo funcionou para ns e podemos recomend-la (independente de como voc resolve chamar esse papel).

Como alocamos pessoas s equipes

Existem duas estratgias gerais para alocar pessoas s equipes, quando voc tem vrias equipes trabalhando no mesmo produto. Deixe uma pessoa designada para fazer a alocao. Por exemplo o lder da equipe citado acima, o product owner, ou o gerente funcional (se ele estiver envolvido o suficiente para tomar boas decises a esse respeito) Deixe as equipes fazerem a escolha por elas prprias.

102 | SCRUM E XP DIRETO DAS TRINCHEIRAS Ns temos experimentado todas as trs opes. Trs?! Sim. Estratgia 1, estratgia 2 e as duas combinadas. Descobrimos que a combinao das duas tem melhor resultado. Antes da reunio de planejamento do sprint, o lder da equipe convoca uma reunio de alocao das equipes junto ao product owner e todos os Scrum masters. Ns conversamos sobre o ltimo sprint e decidimos se as realocaes da equipes esto garantidas. Entretanto, podemos decidir combinar duas equipes, ou transferir algum de uma equipe para outra. Ns tomamos uma deciso e anotamos como uma proposta de alocao das equipes, que levamos reunio de planejamento do sprint. A primeira coisa que ns fazemos na reunio de planejamento do sprint atacar o product backlog na ordem das prioridades. O lder da equipe ento diz algo como: Ol pessoal. Ns sugerimos a seguinte alocao das equipes para o prximo sprint.

Como podem ver, isso significaria uma reduo de 4 para 3 equipes. Ns relacionamos os membros de cada equipe. Por favor, agora juntem-se e arrumem uma seo na parede. (o lder da equipe aguarda enquanto as pessoas ajeitam-se na sala. Depois de algum tempo haver 3 grupos de pessoas, cada um deles perto de uma parte vazia na parede). Agora essa diviso das equipes uma prvia! s um ponta-p inicial para ganharmos tempo. Durante o avano dessa reunio vocs so livres para mudar de equipe, dividir sua equipe em duas, juntar com outra, o que vocs quiserem. Usem o bom senso baseado nas prioridades do projeto.

COMO LIDAMOS COM VRIAS EQUIPES | 103 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.

Equipes especializadas ou no?

Digamos que sua tecnologia seja composta de 3 partes principais:

E digamos que voc tenha 15 pessoas trabalhando neste produto, e voc no gostaria de execut-lo como uma nica equipe. Quais equipes voc criaria?

Abordagem 1: Equipes especializadas em componentes

Uma soluo criar equipes especializadas em componentes, como equipe cliente, equipe servidor e o equipe BD.

104 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Foi assim que comeamos a princpio. No funciona muito bem, pelo menos no quando a maioria das estrias envolve mltiplas camadas. Por exemplo, digamos que ns tenhamos uma estria denominada quadro de avisos onde pessoas possam colocar recados/mensagens para outras pessoas. Este quadro de avisos implicaria atualizar a interface grfica no cliente, adicionar processamento lgico no servidor e adicionar algumas tabelas no banco de dados.

Ou seja, as trs equipes cliente, servidor e banco de dados devem interagir e colaborar para finalizar a estria. E isso no muito bom.

Abordagem 2: Equipes multifuncionais

COMO LIDAMOS COM VRIAS EQUIPES | 105 Uma segunda abordagem criar equipes multifuncionais, isto , equipes que no esto amarradas a nenhum componente especfico.

Se a maioria de nossas estrias envolvem mltiplos componentes, esta estratgia de diviso de equipes ir funcionar melhor. Cada equipe pode implementar uma estria completa, incluindo as partes do cliente, do servidor e do BD. Cada equipe pode desse modo trabalhar mais independente de cada outra, o que uma Boa Coisa. 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. Contudo, fazemos de vez em quando a criao de equipes temporrias especializadas em componentes, sempre que surge uma forte necessidade.

Reorganizar as equipes entre os sprints ou no?

Cada sprint geralmente bem diferente do outro., dependendo de quais tipos de estrias possuem maior prioridade naquele momento especfico. Como resultado, a definio da equipe ideal pode ser diferente para cada sprint.

106 | SCRUM E XP DIRETO DAS TRINCHEIRAS Na verdade, praticamente em todos os sprints nos vemos falando coisas como este sprint realmente no um sprint normal porque (blablabla) .... Aps um tempo ns desistimos da definio de sprints normais. No existem sprints normais. Assim como no h famlias normais ou pessoas normais. 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. Um dos aspectos chave do Scrum o da cola da equipe, ou seja, se uma equipe acaba trabalhando junta atravs de mltiplos sprints eles se tornaro muito unidos. Eles aprendero a alcanar fluncia com o grupo e atingiro um nvel de produtividade incrvel. Mas demora alguns sprints para que chegue neste nvel. Se voc ficar mudando as equipes voc nunca alcanar uma forte cola da equipe. Logo, se voc pretende reorganizar as equipes, certifique-se de ter levando em considerao todas as consequncias. Esta uma mudana de curto ou longo prazo? Se esta for uma mudana de curto prazo, ignore-a. Se for uma mudana de longo prazo, faa isso. 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.

Membros de equipe em tempo parcial

Eu tenho que confirmar o que os livros de Scrum dizem ter membros em tempo parcial em uma equipe Scrum geralmente no uma boa idia. Digamos que voc est pretendendo incluir o Joe como um membro em tempo parcial na sua equipe Scrum. Primeiro pense nisso com cuidado. Voc realmente precisa do Joe na sua equipe? Voc tem certeza de que no pode incluir o Joe em tempo integral? Quais so seus outros compromissos? Ser que algum pode assumir estes outros compromissos do Joe e fazer com que ele assuma uma funo um pouco mais passiva ou de apoio em relao a este compromisso? Ser que o Joe pode passar a

COMO LIDAMOS COM VRIAS EQUIPES | 107 integrar sua equipe em tempo integral no prximo sprint, e neste intervalo transferir suas outras responsabilidades para outra pessoa? Algumas vezes simplesmente no h soluo. Voc precisa desesperadamente do Joe porque ele o nico DBA no prdio, mas as outras equipes tambm precisam dele tanto quanto, logo ele nunca ser alocado em tempo integral na sua equipe e a empresa no pode contratar mais DBAs. Tudo bem. Este um caso vlido para t-lo por tempo parcial (o que a propsito exatamente o que nos aconteceu). Mas tenha certeza que voc est sempre fazendo essa avaliao. De modo geral, eu prefiro ter uma equipe com 3 membros em tempo integral do um equipe com 8 membros em tempo parcial. 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.

Como fazemos Scrum-de-Scrums

Scrum-de-Scrums so basicamente reunies regulares onde todos Scrum masters se encontram para conversar. Em um ponto no tempo ns tnhamos quatro produtos, onde trs dos produtos tinham apenas uma equipe cada, e o ltimo produto tinha 25 pessoas divididas em vrias equipes. Algo assim:

108 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Isso significa que tnhamos dois nveis de Scrum-de-Scrums. Ns tnhamos um Scrum-de-Scrums de nvel de produto consistindo de todas as equipes dentro do Produto D, e um Scrum-de-Scrums de nvel corporativo consistindo de todos produtos.

Scrum-de-Scrums de nvel de produto

Esta reunio foi muito importante. Ns a fazamos uma vez por semana, algumas vezes mais do que isso. Discutamos problemas de integrao, de balanceamento de equipes, preparaes para a prxima reunio de planejamento de sprint, etc. Ns alocvamos 30 minutos, mas freqentemente passvamos disso. Uma alternativa seria termos tido Scrum-de-Scrums todos os dias, mas nunca chegamos a tentar isso. Nosso planejamento de Scrum-de-Scrums era 1) Ao redor da mesa, todos descrevem o que sua equipe realizou na ltima semana, o que planeja alcanar nessa semana, e que impedimentos eles tm. 2) Quaisquer outras preocupaes inter-equipes que precisem ser levantadas, como problemas de integrao, por exemplo. O planejamento de Scrum-de-Scrums no realmente importante para mim, o importante que voc faa reunies Scrum-de-Scrums regularmente.

Nvel corporativo Scrum-de-Scrums

Ns chamamos esta reunio de "O Pulso". Ns temos feito essa reunio numa variedade de formatos, com uma variedade de participantes.

COMO LIDAMOS COM VRIAS EQUIPES | 109 Ultimamente temos suprimido todo o conceito e, ao invs disso, substitudo por uma reunio com todas as pessoas (bem, todas as pessoas envolvidas no desenvolvimento). 15 minutos O qu? 15 minutos? Com todos? Todos os membros de todas as equipes de todos os produtos? Isto funciona? Sim, isto funciona se voc (ou quem conduz a reunio) for rigoroso quanto a mant-la curta. O formato da reunio : 1) Notcias e atualizaes do chefe de desenvolvimento. Informaes sobre prximos eventos, por exemplo. 2) Round-robin. Uma pessoa de cada grupo de produtos relata o que eles fizeram na semana passada, o que eles planejam fazer essa semana e qualquer problema. Algumas outras pessoas tambm reportam (lder do gerenciameto de configurao, lder do controle de qualidade, etc) 3) Todos os outros so livres para adicionar qualquer informao ou fazer perguntas Esse um frum para informaes rpidas, no discusses ou reflexes. Deixando-a assim, 15 minutos normalmente funciona. Algumas vezes ns extrapolamos, mas muito raramente mais que 30 minutos. Se discusses interessantes comeam, eu fao uma pausa e convido todos os interessados para ficar depois do reunio e continu-la. Por que ns fazendo uma reunio de pulso -todas-mos? Porque ns notamos que o nvel corporativo Scrum-de-Scrums mais para comunicao. Ns raramente temos discusses nesse grupo. Alm disso, muitas outras pessoas fora do grupo esto famintos por esse tipo de informao. Basicamente, equipes querem saber o que outras equipes esto fazendo. Ento ns notamos que, se estamos indo reunio e gastando tempo informando cada um sobre o que cada equipe est fazendo, por que no simplesmente deixar todos freqentarem?

Intercalando as reunies dirias

Se voc tem muitas equipes Scrum para um mesmo produto, e todos fazem a reunio diria ao mesmo tempo, voc tem um problema. O product owner (e pessoas intrometidas como eu) s podem atender a reunio diria de uma equipe por dia.

110 | SCRUM E XP DIRETO DAS TRINCHEIRAS Por isso pedimos que s equipes evitem ter reunies dirias simultneas.

A agenda de exemplo acima de um perodo em que ns tnhamos reunies dirias em salas separadas, ao invs de ser na sala da prpria equipe. As reunies duravam 15 minutos normalmente, mas cada equipe tem um perodo reservado de 30 minutos caso eles precisem estourar o tempo um pouquinho. Isto extremamente importante por dois motivos: 1. Pessoas como eu e o product owner podem ir a todas as reunies dirias de uma manh. No h maneira melhor de se ter uma foto precisa de como a sprint est se saindo e quais so as potenciais ameaas. 2. As equipes podem visitar as reunies dirias umas das outras. No acontece com muita freqncia, mas de vez em quando as equipes estaro trabalhando em reas semelhantes, ento alguns membros da equipe atendem s reunies umas das outras para que haja sincronia. A parte ruim que isso reduz a liberdade da equipe eles no podem escolher o horrio que quiserem para fazer suas reunies dirias. Mas isto no tem sido realmente um problema para ns.

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

COMO LIDAMOS COM VRIAS EQUIPES | 111

Ns resolvemos este problema criando uma equipe de bombeiros e outra equipe Scrum dedicada. A funo da equipe Scrum era (com as bnos do product owner) tentar estabilizar o sistema e efetivamente prevenir os incndios. J a equipe de bombeiros (chamvamos de suporte, na verdade) tinha duas funes: 1) Apagar incndios; 2) Proteger a equipe Scrum de todos os tipos de perturbao, incluindo coisas de como requisies ad-hoc vindas de lugar algum. A equipe de bombeiros ficava disposta prxima porta; a equipe Scrum ficava ao fundo da sala. Desta forma, os bombeiros poderiam proteger fisicamente a equipe Scrum de interferncias tais como vendedores vorazes ou clientes raivosos. Desenvolvedores experientes eram distribudos nas duas equipes, desta forma uma equipe no seria to dependente da outra. Basicamente, esta foi uma tentativa de resolver este impasse. Como poderamos comear a usar Scrum se a equipe no tinha sequer a chance de planejar mais que um dia de trabalho por vez? Nossa estratgia foi, como mencionado, dividir o grupo. 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. Claro que a equipe Scrum no era totalmente intocvel. Freqentemente a equipe de suporte tinha que envolver pessoas-chave da equipe Scrum, ou pior, a equipe toda. De qualquer forma, aps alguns meses, o sistema estava suficientemente estvel e conseguimos desfazer a equipe de suporte e criar equipes adicionais. Os membros da equipe de suporte (bombeiros) ficaram felizes em aposentar seus capacetes de batalha e juntar-se s equipes Scrum.

112 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Dividir o product backlog ou no?

Digamos que voc tem um produto e duas equipes Scrum. Quantos product backlogs voc deve ter? Quantos product owners? Ns analisamos trs modelos para esse tipo de situao. A escolha tem um efeito realmente grande em como as reunies de planejamento de sprint so conduzidas.

Estratgia 1: Um product owner, um backlog

Este o modelo S Pode Haver Um. Nosso modelo predileto. 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: 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.

COMO LIDAMOS COM VRIAS EQUIPES | 113

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.

114 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Conforme a reunio progride, o product owner e a equipe debatem sobre os cartes, movendo-os para cima e para baixo para alterar sua prioridade, quebrando-os em itens menores, etc. Aps mais ou menos uma hora, cada equipe tem uma verso candidata para sprint backlog em seu quadro de equipe. Aps isso as equipes trabalham independentemente, realizando estimativas de prazo e dividindo as tarefas.

COMO LIDAMOS COM VRIAS EQUIPES | 115 bagunado, catico e exaustivo, mas tambm efetivo, divertido e social. Quando o tempo acaba, normalmente todas as equipes tm informao suficiente para iniciar seu sprint.

Estratgia 2: Um product owner, mltiplos backlogs

Nesta abordagem, o product owner mantm mltiplos product backlogs, um por equipe. Ns no tentamos esta abordagem, mas chegamos perto. Este basicamente nosso plano B no caso da primeira abordagem falhar. A fraqueza desta estratgia que o product owner quem aloca estrias para as equipes, tarefa esta que provavelmente seria melhor realizada pelas prprias equipes.

Estratgia 3: Mltiplos product owners, um backlog por dono.

Esta estratgia semelhante a segunda estratgia, um product backlog por equipe, mas com um product owner por equipe tambm!

116 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Ns no chegamos a execut-la, e provavelmente nunca iremos. Se dois product backlogs compartilham o mesmo cdigo-fonte, isso ir provavelmente causar srios conflitos de interesse entre os dois product owners. Se dois product backlogs implicarem na construo de cdigo-fonte separados, essencialmente seria o mesmo que separar o produto como um todo em sub-produtos e execut-los independentemente. O que significa que estaramos de volta a situao uma-equipe-por-produto, a qual a melhor e mais fcil.

Fazendo Branching de cdigo

Com mltiplos times trabalhando no mesmo cdigo-fonte, ns inevitavelmente tivemos que trabalhar com branches (ramificaes) no sistema de gerenciamento de configurao de software (ou SCM software configuration management). Existem inmeros livros e artigos que explicam como lidar com vrias pessoas trabalhando no mesmo cdigo-fonte, ento eu no vou entrar em detalhes aqui. Eu no tenho nada novo ou revolucionrio a adicionar. Irei, entretanto, resumir algumas das mais importantes lies aprendidas at ento por nossas equipes. Seja rigoroso ao manter a linha principal (trunk) num estado consistente. Isso significa, que em todos os casos, tudo deve estar compilando com todos os testes unitrios passando. Deve ser possvel gerar uma entrega a qualquer momento. Preferencialmente o sistema de compilao contnuo deve compilar e auto executar testes durante a noite.

COMO LIDAMOS COM VRIAS EQUIPES | 117 Gere uma tag (rtulo) para cada liberao ou entrega do cdigo. No importa se uma entrega para testes de aceitao ou para produo, tenha certeza que existe uma tag no seu ramo principal para identificar exatamente cada entrega feita. Desta forma voc poder em qualquer momento no futuro voltar e criar branches de manuteno a partir daquele ponto especfico. Crie novos branches somente quando necessrio. Uma boa prtica fazer o branch de uma nova verso do cdigo somente quando no possvel usar uma verso de cdigo j existente sem quebrar sua poltica. Se estiver em dvidas, no crie o branch. Por que? Porque cada branch ativo gera um custo de administrao e complexidade. Use branches principalmente para separar ciclos de vida diferentes. Voc pode optar ou no por ter o cdigo de cada equipe Scrum no seu prprio ramo de cdigo. Porm se voc misturar pequenas correes com grandes alteraes na mesma linha de cdigo, voc encontrar dificuldades para entregar as pequenas correes! Faa a sincronizao freqentemente. Se voc estiver trabalhando numa branch, sincronize-se ao ramo principal (trunk) sempre que tiver algo que esteja compilando. Todos os dias quando chegar para trabalhar, faa a sincronia do ramo principal para o seu branch, desta forma voc estar garantindo que seu branch esteja atualizado respeitando tambm as alteraes das demais equipes. Se isso te levar a problemas com o merge, simplesmente aceite o fato que seria muito pior esperar para fazer a atualizao.

Retrospectivas com vrias equipes

Como fazemos retrospectivas de sprint quando h mltiplas equipes trabalhando no mesmo produto? Imediatamente aps a apresentao do sprint, depois do aplauso e da mistura, cada equipe volta pra sua sala prpria, ou para alguma localizao confortvel fora do escritrio. Elas fazem retrospectivas mais ou menos como descrito na pg. 71 Como fazemos retrospectivas de sprint.

118 | SCRUM E XP DIRETO DAS TRINCHEIRAS Durante a reunio de planejamento de sprint ( qual todas as equipes vo, j que fazemos sprints sincronizados a cada produto), a primeira coisa que fazemos deixar um porta-voz de cada equipe resumir pontos chaves de sua retrospectiva. Leva em torno de 5 minutos por equipe. Ento temos uma discusso aberta em torno de 10 a 20 minutos. Depois fazemos uma pausa. Finalmente, comeamos o planejamento de sprint mesmo. Ns nunca tentamos outra maneira para mltiplas equipes, isso funciona bem o suficiente. A maior desvantagem que no h intervalo entre a retrospectiva e o planejamento do sprint. (Veja pg. 78 Intervalo entre sprints ). Para produtos de uma s equipe, ns no fazemos resumo retrospectivo durante a reunio de planejamento do sprint. No h necessidade, j que todos estavam presentes na verdadeira reunio de retrospectiva.

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: A habilidade de programar juntos em pares. A habilidade de participar cara-a-cara na reunio diria. A habilidade de haver discusses cara-a-cara a qualquer momento. A habilidade de encontrar-se fisicamente para uma social. A habilidade de ter reunies espontneas com a equipe inteira. A habilidade de ter a mesma viso do sprint backlog, sprint burndown, product backlog e outros termmetros de informao. Algumas mtricas que ns implementamos (ou estamos implementando. Ns no fizemos tudo ainda) so: Webcam e fone de ouvido em cada estao de trabalho. Salas de conferncia habilitadas para encontros remotos com webcams, microfones p/ conferncia, computadores sempre prontos, software de compartilhamento de desktop, etc. Janelas remotas. Telas grandes em cada local, mostrando o que est acontecendo nos outros locais. uma espcie de janela

COMO LIDAMOS COM VRIAS EQUIPES | 121 virtual entre dois departamentos. Voc pode ficar l e navegar. Voc pode ver quem est nas mesas e quem est conversando com quem. Isso para criar um sentimento de ei, ns estamos juntos nisso. Programas de intercmbio, quando pessoas de um lugar viajam e visitam outras regularmente.

Usando essas tcnicas e mais algumas, ns estamos lentamente mas certamente comeando a pegar o jeito de como fazer reunies de planejamento, demonstraes, retrospectivas, reunies dirias, etc. com membros da equipe distribudos geograficamente. Como normal, isso tudo um teste. Testar => adaptar => testar =>
adaptar => testar =>
adaptar => testar =>
adaptar => testar =>
adaptar

Equipes em outro pas

Ns temos vrias equipes em outros pases e temos experimentado como lidar eficientemente com elas usando Scrum. Existem duas estratgias principais aqui: equipes separadas ou membros separados das equipes.

122 | SCRUM E XP DIRETO DAS TRINCHEIRAS

A primeira estratgia, equipes separadas, uma escolha instigante. Entretanto, ns comeamos com a segunda estratgia, membros separados das equipes. Existem vrias razes para isso. 1. Ns queremos que os membros das equipes conheam-se bem. 2. Ns queremos uma excelente infra-estrutura de comunicao entre os dois locais, e tambm queremos dar um forte incentivo s equipes para mant-las. 3. No princpio, a equipe em outro pas muito pequena para formar uma equipe autnoma. 4. Ns queremos um perodo de intenso compartilhamento de conhecimento antes que as equipes em outro pas independentes sejam uma alternativa vivel.

COMO LIDAMOS COM VRIAS EQUIPES | 123 Ao longo do tempo, ns poderemos andar na direo da estratgia de equipes separadas

Membros da equipe trabalhando em casa.

Trabalhar em casa pode ser muito bom algumas vezes. As vezes voc consegue programar mais em um dia em casa do que conseguiria a semana toda na empresa. Isso se no tiver filhos :o) Mas um dos fundamentos do Scrum diz que a equipe toda deve estar fisicamente no mesmo lugar. Ento o que fazemos? Basicamente deixamos a equipe decidir quando e com que frequencia adequado trabalhar de casa. Alguns membros da equipe trabalham regularmente de casa devido a viagens. Entretanto, ns encorajamos as equipes a estarem no mesmo local a maior parte do tempo. Quando os membros da equipe trabalham de casa eles participam das reunies dirias atravs da chamada de voz do skype (as vezes por vdeo). Eles ficam disponveis em mensageiros on-line o dia todo. No to bom quanto estarem na mesma sala, mas o suficiente. Ns tentamos uma vez o conceito de ter as quartas-feiras como o dia do foco. Isto significava que basicamente se voc quisesse trabalhar em casa, tudo bem, mas faa isso nas quartas-feiras. E cheque antes com sua equipe. Isto funcionou muito bem com a equipe na qual tentamos. Geralmente toda a equipe ficava em casa na quarta-feira e conseguiam render bem, sem deixar de colaborarem uns com os outros satisfatoriamente. O fato de que era apenas um dia na semana no deixa que a equipe ficasse muito fora-de-sincronia. Mas por algum motivo a idia no pegou com as outras equipes. Em geral, pessoal trabalhando em casa no foi realmente um problema para ns.

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
Depois da reunio de planejamento do sprint, Crie uma pgina de informaes. o Adicione um link para sua pgina do dashboard no wiki. o Imprima a pgina e coloque num muro onde as pessoas passam. Mande um email para todo mundo avisando que um novo sprint comeou. Inclua o objetivo do sprint e um link para a pgina de informaes do sprint. Atualize o documento de estatsticas do sprint. Adicione a velocidade real, o tamanho da equipe, o comprimento do sprint, etc.

Todo dia
Garanta que a reunio diria comece e termine pontualmente. Garanta que estrias sejam adicionadas e removidas do sprint backlog conforme a necessidade de manter o sprint dentro do planejamento.

CHECKLIST DO SCRUM MASTER | 125

Garanta que o product owner seja notificado dessas mudanas. Garanta que o sprint backlog e burndown sejam mantidos atualizados pela equipe. Garanta que problemas e impedimentos foram resolvidos ou reportados ao product owner e/ou chefe de desenvolvimento. o

Fim do Sprint
Faa uma demonstrao aberta do sprint. Todos devem ser avisados sobre a demonstrao dois dias antes. Faa uma retrospectiva do sprint com a equipe inteira e o product owner. Convide o chefe de desenvolvimento tambm, da ele pode ajudar a espalhar os conhecimentos que aprendeu. Atualize o documento de estatsticas do sprint. Adicione a velocidade real e os pontos chave da retrospectiva.

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

Adam Victor Brandizzi Alexandre Gomes Bruno Pedroso Marcos Machado Victor Hugo Germano Acyr Jos Tedeschi Emanoel Tadeu da Silva Freitas Gustavo Grillo Israel Rodrigo Faria Marcos Vincius Guimares Pablo Nunes Alves Taiza Sousa

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