Escolar Documentos
Profissional Documentos
Cultura Documentos
Scrum Exp Dire To Das Trin Cheir As
Scrum Exp Dire To Das Trin Cheir As
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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).
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.
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.
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.
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.
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.
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.
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.
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?
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:
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).
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.
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?
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.
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.
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.
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.
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.
Ei, e a rastreabilidade?!
A melhor rastreabilidade que eu posso sugerir neste modelo tirar uma foto digital do quadro de tarefas todo dia. Eu fao isso s vezes, mas eu nunca encontrei um motivo para vasculhar estas fotos. Se rastreabilidade muito importante para voc, ento o quadro de tarefas talvez no seja uma boa soluo para voc. Mas eu sugiro que voc realmente tente estimar o valor real de ter uma rastreabilidade detalhada do sprint. Uma vez que o sprint est pronto, o software funcionando e a documentao entregue, algum realmente se preocupa com quantas estrias foram completadas no dia 5 de um sprint? Algum realmente se preocupa com qual era o tempo estimado para escrever um teste de falha para Depsito?
7
Como arrumamos a sala da equipe
O canto do design
Eu notei que muitas das mais interessantes e valiosas discusses sobre design acontecem espontaneamente na frente do quadro de tarefas. Por esta razo, ns tentamos arrumar esta rea explicitamente como um canto do design.
Isto realmente bem til. No h forma melhor de ter uma viso geral do sistema do que ficar no canto do design e dar uma olhadela em ambas as paredes, e ento dar uma olhadela no computador e tentar o ltimo build do sistema (se voc for sortudo o bastante para ter build contnuo, veja pg 81 Como combinamos Scrum e XP). A parede do design s um grande quadro-branco contendo os rabiscos de design e esboos (printouts) da documentao de design mais importante (grficos de seqncias, prottipos de GUI, modelos de domnio, etc).
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.
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.
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.
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.
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 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.
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.
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.
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.
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):
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.
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).
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.
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
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.
Design incremental
Significa manter o design simples desde o incio e melhor-lo continuamente, ao invs de tentar deix-lo perfeito desde o incio e ento congel-lo. Ns estamos indo muito bem assim, isto , ns gastamos uma quantidade considervel de tempo melhorando o design existente e ns raramente perdemos tempo projetando de forma precipitada. s vezes ns estragamos tudo, claro, por exemplo quando deixamos que um design instvel crie muitas razes, de forma que refatorar se torna um grande projeto. Mas no geral estamos muito satisfeitos. Melhoria contnua do design praticamente um efeito coleteral do Desenvolvimento Orientado a Testes.
Integrao contnua
A maioria dos nossos produtos possui uma configurao de integrao contnua razoavelmente sofisticada, baseada em Maven e QuickBuild. Isto extremamente vlido e poupa tempo. Essa a soluo definitiva para um velho problema Ei, mas isso funciona na minha mquina. Nosso servidor de construo contnua age como o juiz ou ponto de referncia a partir do qual se determina a qualidade de todas as nossas bases de cdigo. Toda vez que algum atualiza alguma coisa no sistema de controle de verso o servidor de construo contnua ir acordar, construir tudo desde o incio num servidor compartilhado e realizar todos os testes. Se alguma coisa der errado, ele enviar um email avisando a equipe inteira que a construo falhou, incluindo informaes sobre exatamente qual mudana de cdigo quebrou a construo, links para relatrios de teste, etc. Todas as noites o servidor de construo contnua ir reconstruir o produto desde o incio e publicar binrios (ears, wars, etc), documentaes, relatrios de teste, relatrios de cobertura de testes, relatrios de dependncias, etc, no nosso portal de documentaes internas. Alguns produtos sero tambm automaticamente implementados em um ambiente de teste. Configurar isso deu muito trabalho, mas valeu cada minuto.
Padro de codificao
Recentemente ns comeamos a definir o nosso padro de codificao. Teria sido muito til se tivssemos feito isso antes. No leva quase tempo nenhum. Comece com ele simples e v crescendo conforme a necessidade. Escreva apenas regras que no sejam bvias para todo mundo e correlacione com algum material j existente, sempre que possvel. A maioria dos programadores tem seu estilo prprio de codificao. So pequenos detalhes como, por exemplo, a forma de tratar excees, como comentar o cdigo, quando retornar valor nulo, etc. Em alguns casos as diferenas no causam problemas, mas em outros casos pode levar ao projeto de um sistema extremamente inconsistente e um cdigo fonte difcil de entender. Um padro de codificao aqui muito til, j que voc foca em coisas que realmente importam. Aqui esto alguns exemplos do nosso padro de codificao: 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.
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.
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.
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.
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.
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.
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.
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?)
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
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.
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.
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.
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).
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.
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?
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.
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.
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.
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.
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.
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?
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).
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.
Para ser mais concreto, aqui est o modo como a reunio de planejamento de sprint funciona para esta equipe: A reunio de planejamento de sprint ocorre em um centro de conferncias externo. Logo antes da reunio, o product owner define um quadro para ser o quadro do product backlog e coloca estrias ali (cartes), ordenadas por prioridade relativa. Ele continua colocando-as at que o quadro esteja cheio. Normalmente estes so itens mais do que suficientes para um sprint.
Cada equipe seleciona uma parte vazia do quadro e coloca seu nome ali. Este o seu quadro de equipe. Cada equipe ento pega algumas estrias do quadro do product backlog, comeando pelas estrias com maior prioridade e coloca os cartes em seu prprio quadro de equipe. Isso est ilustrado na imagem a seguir, com setas amarelas simbolizando o fluxo dos cartes do quadro de product backlog para os quadros de equipe.
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.
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.
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.
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
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
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.
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/
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
Apoio
SEA Tecnologia
www.seatecnologia.com.br