Melhor Scrum

25
Melhor Scrum Um conjunto não-oficial de dicas e idéias de como implementar bem Scrum. Escrito por Peter Hundermark Instrutor (CST) e Coach (CSC) Certificado Scrum. Traduzido para o português por Samuel Gonsales Certificado ScrumMaster (CSM).

description

scrum

Transcript of Melhor Scrum

  • Melhor Scrum

    Um conjunto no-oficial de dicas e idias de como implementar bem Scrum.

    Escrito por Peter Hundermark Instrutor (CST) e Coach (CSC) Certificado Scrum.

    Traduzido para o portugus por Samuel Gonsales Certificado ScrumMaster (CSM).

  • Melhor Scrum 1

    Por que este guia? Jim York, Instrutor (CST) e Coach (CSC) Certificado Scrum, disse: Scrum simples. Praticar Scrum difcil. SM Muitas pessoas que conheo dizem que elas tm dificuldade para saber como iniciar a prtica de Scrum. Outros tm equipes que esto seguindo algumas prticas geis, mas que ainda esto longe de se tornar o que Jeff Sutherland definiu como hiper-produtivo. Espero que este pequeno livro possa ser uma fonte de inspirao para ajud-lo a praticar Scrum e conceitos geis melhor. Acima de tudo, espero poder incentiv-lo a percorrer juntamente com sua equipe e toda a sua organizao para longe das velhas formas de trabalho que simplesmente no fazer bem, trabalhar e encontrar novos caminhos que levam a obter mais qualidade, entregar com mais velocidade e acima de tudo, que seja mais divertido. Deixe-me, ento, saber o que voc gosta e o que no gosta para que eu possa melhor-lo. Agora v e faa! Peter Hundermark Cape Town, Novembro de 2009 Segunda Edio

  • Melhor Scrum 2

    O que Scrum?

    Origens Scrum um framework de gerenciamento de projetos que visa o desenvolvimento de produtos complexos. Scrum tem suas origens nas reas de gesto conhecimento, sistemas adaptativos complexos e teoria de controle emprico de processos. Foi tambm influenciado por padres observados no desenvolvimento de Software e Teoria das Restries.

    Scrum e gil Scrum o mais popular dos mtodos geis. freqentemente utilizado em conjunto com Extreme Programming (XP).

    Qual o problema?

    Releases demoram muito; A estabilizao leva muito tempo; As alteraes so difceis de fazer; A Qualidade est caindo; Marchas fnebres esto ferindo a moral;

    Durante dcadas os desenvolvedores de software tm tentado empregar mtodos definidos de trabalho e gerenciamento de projetos. Os mtodos definidos so adequados quando as variveis que entram no sistema so bem definidas e o mtodo empregado gera um resultado previsvel.Desenvolvimento de software e outras formas de trabalho complexo no so adequados a tais mtodos. E a alta taxa de falhas de projeto e insatisfao dos clientes ilustra isso claramente.

    Como o Scrum ajuda a resolver esses problemas? Alistair Cockburn [Cockburn 2008] descreve o desenvolvimento de software como um "jogo cooperativo de inveno e comunicao". Metodologias tradicionais de desenvolvimento so baseadas em documentos para capturar e comunicar conhecimento de um especialista ao outro. Os ciclos de feedback so muito longos ou mesmo no existem. Dcadas de projetos de baixa produtividade mostram que esta forma de trabalho conduz inevitavelmente ao fracasso. Scrum fornece uma plataforma para as pessoas trabalharem em conjunto de forma eficaz e expe implacavelmente todos os problemas tornando-os visveis em seu caminho.

    Melhor Scrum 2

  • Melhor Scrum 3

    A Essncia do Scrum A essncia do Scrum :

    A equipe recebe metas claras; A equipe se organiza em torno do trabalho; A equipe entrega regularmente os recursos mais valiosos; A equipe recebe feedback de pessoas de fora; A equipe reflete sobre sua forma de trabalhar a fim de melhorar; Toda a organizao tem visibilidade do progresso da equipe; A equipe de gesto comunica aos outros de maneira honesta sobre progressos e riscos.

    Esta forma de trabalho baseada em valores de auto-respeito, respeito pelos outros, confiana e coragem.

    Por que Scrum no faz nenhuma meno a qualquer prtica de desenvolvimento de software? As ferramentas de desenvolvimento e prticas mudam e melhoram continuamente e boas equipes iro trabalhar no sentido de obter o melhor uso delas. Scrum no tenta instruir equipes de como fazer seu trabalho. Scrum espera que as equipes faam o que for necessrio para entregar o produto desejado, dando-lhes o poder para faz-lo. Prticas e ferramentas de desenvolvimento so atualizadas constantemente e consistentemente e boas equipes trabalharo para tirar melhor proveito delas.

    Aplicabilidade Embora seja verdade que o Scrum foi usado inicialmente para desenvolver produtos de software, ele projetado para qualquer tipo de trabalho complexo. Hoje ele usado para gerenciar desenvolvimento de software e hardware, publicidade e marketing, igrejas e organizaes inteiras.

    Como Scrum mapeado para os mtodos tradicionais? A resposta rpida que ele no mapeado. Mtodos geis e Scrum so baseados em um paradigma diferente. Os fundadores Jeff Sutherland e Ken Schwaber tem repetido em diversas ocasies que intil tentar mapear mtodos definidos com um mtodo emprico.

    Scrum ter sucesso em minha organizao? Isso depende de voc! A implementao na sua organizao pode falhar por causa de uma falta de determinao das pessoas para superar os problemas que Scrum certamente ir expor. No entanto, milhares de equipes em todos os continentes e em todos os setores esto conseguindo tornar o seu mundo de trabalho melhor hoje do que era ontem.

  • Melhor Scrum 4

    Manifesto gil Em Fevereiro de 2001, dezessete especialistas em metodologias leves se reuniram para discutir e tentar chegar a uma definio comum de trabalho. Entre eles estavam Jeff Sutherland e Ken Schwaber, fundadores do Scrum, juntamente com Mike Beedle que trabalhou no desenvolvimento dos padres iniciais e escreveu o primeiro livro sobre Scrum. Este grupo chamava-se "A Aliana gil" (Agile Alliance) e concordaram com um Manifesto para Desenvolvimento gil de Software. Eles tambm definiram um conjunto de doze princpios por trs do manifesto que sero reproduzidos na pgina seguinte.

    Comentrio O Manifesto gil e seus doze princpios permanecem intactos durante uma dcada. Eles permanecem at hoje a melhor maneira de julgar se um mtodo realmente funciona de forma gil ou no. A maior crtica tem sido a tendncia para desenvolvimento de software, embora os mtodos geis possam ser mais amplamente aplicados.

    Nota Scrum um dos sabores dos mtodos geis. A adeso ao Manifesto gil e todos os seus princpios no significa necessariamente que uma equipe ou uma organizao est praticando Scrum. No entanto, a no adeso a qualquer um destes princpios implica que voc no est praticando Scrum (ou metodologia gil)!

    Espao para anotaes

  • Melhor Scrum 5

    Manifesto para Desenvolvimento gil de Software Estamos descobrindo maneiras melhores de desenvolver software, tanto para nossa prpria experincia como para ajudar os outros. Atravs deste trabalho, chegamos aos seguintes valores:

    - Indivduos e interaes so mais importantes que processos e ferramentas; - Software funcionando mais importante que documentao extensa; - Colaborao com o cliente mais importante que negociao de contrato; - Responder s mudanas mais importante que seguir um plano.

    Ou seja, enquanto no h valor nos itens direita, ns valorizamos mais os itens esquerda.

    Princpios por trs do Manifesto gil 1. Nossa maior prioridade satisfazer o cliente atravs da entrega antecipada e contnua de software valioso. 2. Aceitamos que os requisitos mudem mesmo em estgios avanados de desenvolvimento. Processos geis aproveitam a mudana para proporcionar vantagem competitiva ao cliente. 3. Entregar software funcionando freqentemente, a cada duas semanas ou a cada dois meses, com preferncia para o prazo mais curto. 4. Os gerentes de negcios e desenvolvedores trabalham em conjunto diariamente durante o projeto. 5. Os projetos so construdos em torno de indivduos motivados. D-lhes o ambiente e apoio de que precisam, e confie neles para fazer o trabalho. 6. A maneira mais eficiente e eficaz de comunicar informaes para a equipe de desenvolvimento atravs de conversa cara a cara. 7. O software em operao a medida primria do progresso do projeto. 8. Processos geis promovem o desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante por tempo indeterminado. 9. Ateno contnua a excelncia tcnica e bom design aumentam a agilidade; 10. Simplicidade, ou a arte de maximizar a quantidade de trabalho no feito, essencial. 11. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizveis. 12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, em seguida, ajusta e melhora seu comportamento em conformidade.

    Higsmith (2001)

  • Melhor Scrum 6

    Os papis de Scrum

    Introduo No h papel de Gerente de Projetos em Scrum. As responsabilidades do gerente de projeto tradicional so divididas ao longo dos trs papis na equipe Scrum:

    O Product Owner que gerencia o produto (e o retorno sobre o investimento); O ScrumMaster que gerencia os processos; A equipe que gerencia a si mesma.

    Este um desafio para os indivduos que atualmente cumprem esses papis e para os gestores nas organizaes em que trabalham. Michele Sliger e Stacia Broderick escreveram um guia til para a transio do Gerente de Projetos para o treinador de metodologias geis [Sliger e Broderick 2008]. No h lderes designados em equipes Scrum alm do Product Owner e ScrumMaster, e isso no necessrio. A necessidade de gestores de linha reduzida, porque as equipes so administradas numa vasta gama de funes. No raro encontrar 50 membros de uma equipe que se reportam diretamente a um nico gerente de linha em uma organizao que fez a transio para Scrum.

    A auto-organizao A auto-organizao no implica de forma alguma em uma abordagem laissez-faire (do francs deixai fazer), ao contrrio, as equipes auto-organizadas so altamente disciplinadas. Uma vez que elas tenham plena autonomia, esperamos que tenham mais responsabilidade para cumprir os compromissos que assumiram. Elas so encorajadas a assumir riscos razoveis e de aprender atravs de fracasso e auto-reflexo. Um alto grau de confiana e compromisso um resultado automtico de equipes verdadeiramente auto-organizadas. Novas equipes de Scrum vo exigir algum incentivo para explorar seus limites, e super-los, respondendo aos desafios com maior responsabilidade. Elas freqentemente precisam superar as armadilhas que muitas vezes impem as formas antigas e improdutivas que fizeram em seu trabalho durante anos. A auto-organizao no uma opo em Scrum, um princpio fundamental.Sem isso, nunca teremos equipes de alta performance. Caveat emptor!

  • Melhor Scrum 7

    Product Owner As responsabilidades do papel do Product Owner so:

    Trabalhar em uma viso compartilhada; Coletar os requisitos; Gesto e priorizao do Product Backlog; Aceitar o software no final de cada iterao; Gerenciar o plano de liberao de releases; Gerenciar a rentabilidade do projeto (ROI);

    Metfora: O Product Owner um CEO.

    ScrumMaster As responsabilidades do papel do ScrumMaster so:

    Garantir um ambiente de trabalho protegido para a equipe, livre de interferncias;

    Remover impedimentos; Manter o processo em movimento e incentivar o uso de Scrum; Socializar Scrum para a maior parte da organizao;

    Metfora: O ScrumMaster um facilitador, treinador e mentor!

    Equipe Scrum (TIME) As responsabilidades da funo de membro da equipe Scrum ou da equipe so:

    Estimar o tamanho dos itens do backlog; Comprometer-se com incrementos de software a ser entregue e entreg-los; Acompanhar seu prprio progresso; A auto-organizao, mas responsvel perante o Product Owner para a entrega que foi comprometida.

    Os membros da equipe podem ser desenvolvedores, testadores, analistas, arquitetos, escritores, designers e at mesmo usurios. A equipe multifuncional, o que significa que todos os seus membros possuem habilidades suficientes para fazer todo o trabalho. No h liderana definida previamente entre os membros da equipe.

    A Equipe Scrum composta por todos os trs papis: um Product Owner, um ScrumMaster e cinco a nove membros da equipe.

  • Melhor Scrum 8

    As reunies do Sprint O Sprint o corao do ciclo de Scrum. marcado pelo planejamento do Sprint no incio e pela reviso do Sprint e retrospectiva do Sprint no final. O comprimento do Sprint fixado e nunca estendido. A maioria das equipes escolhe duas, trs ou no mximo quatro semanas como sendo a durao do Sprint. Durante o Sprint a equipe realiza uma reunio diria. Cada reunio tem uma durao fixa de tempo. Isto significa ter uma durao mxima para concluir a reunio e no significa que necessrio ocupar todo o tempo fixado. Para um Sprint de 30 dias (ou quatro semanas) geralmente so dedicados 2 perodos para reunio de planejamento, bem como reviso e anlise retrospectiva com durao de cerca de quatro horas cada. Para Sprints mais curtos devemos ajustar as propores de acordo com a durao do Sprint. Alguns dos principais atributos das vrias reunies so descritos nas sees seguintes. Inicialmente compartilho com vocs algumas experincias pessoais que eu acho que vale a pena contar.

    Acho que duas semanas para cada Sprint um bom tempo para comear. Depois de trs Sprints, deixe a equipe re-avaliar o tamanho do Sprint.

    As equipes precisam de trs Sprints para compreender os novos conceitos, quebrar velhos hbitos e comear a agir como uma equipe.

    Nunca faa planejamento de Sprints na manh de segunda-feira. A equipe ainda no est na sua melhor forma e o dia mais comum para incio de frias e eventuais doenas. Nunca faa qualquer reviso ou retrospectiva na tarde de sexta-feira. A equipe est cansada e pensando no fim de semana. Por isso, uma boa idia considerar o incio e final de Sprints entre tera e quinta-feira.

    As equipes que executam duas semanas de Sprints podem ser tentadas a fazer as reunies no incio do Sprint em um dia. Em outras palavras, comear o dia com a reviso, em seguida a retrospectiva, depois do almoo fazer a primeira e segunda partes do planejamento. O pensamento fazer com que todas as reunies terminem o mais rpido possvel de modo que a equipe tenha 9 dias inteiros para fazer o trabalho. Na minha experincia, h dois problemas com essa abordagem:

    A equipe no acredita que estas reunies fazem parte do trabalho e de fato so a parte mais importante para o sucesso no restante do Sprint!

    Durante ltima parte do dia de planejamento o time est mentalmente exausto.

    No entanto, como sempre, deixe a equipe experimentar esse modelo se assim o desejarem!

  • Melhor Scrum 9

    Sprint Planning - Parte 1 A primeira parte do planejamento do Sprint (PS1) realmente um workshop para detalhar os requisitos. O Product Owner apresenta o conjunto de requisitos que quer que sejam implementados e a equipe faz perguntas necessrias para entender os requisitos em detalhes suficientes para entender o esforo necessrio para entregar essas funcionalidades no final do Sprint. A equipe decide o que pode entregar no Sprint, tendo em conta a durao Sprint, o tamanho da equipe e as habilidades atuais de seus membros, a sua definio de pronto, todos os feriados conhecidos ou dias de frias e quaisquer aes ou compromissos assumidos durante a retrospectiva realizada pouco antes desta reunio. O Product Owner deve estar presente durante esta reunio para orientar a equipe na direo correta e para responder s perguntas que normalmente so muitas. O ScrumMaster deve assegurar que quaisquer outras partes interessadas necessrias para ajudar a equipe a entender os requisitos est presente ou de planto. Todos os novos itens do backlog sero desenvolvidos durante o Sprint atual e o que no estava estimado anteriormente ser dimensionado imediatamente durante esta reunio. Esta, porm, no pode ser uma desculpa para evitar preparao do backlog - veja abaixo! No final do SP1 a equipe se compromete com o Product Owner o que eles acreditam que pode entregar testado e funcionando. Uma equipe experiente pode usar seu histrico de velocidade para prever o que conseguir entregar ('tempo passado'). Isto conhecido como taxa baseada em planejamento. Minha recomendao para a maioria das equipes fazer compromissos baseados em planejamento. O conjunto de itens do backlog que foram confirmados pela equipe deve ser chamado de Product Backlog selecionado.

    Sprint Planning - Parte 2 Se a primeira parte do planejamento do Sprint um workshop de requisitos, a segunda parte do planejamento do Sprint (SP2) um workshop de desenho. Nesta reunio a equipe colabora para criar um desenho de alto nvel dos recursos que se comprometeu a entregar. Um resultado desta reunio o Sprint backlog, ou lista de tarefas que a equipe precisa executar coletivamente afim de entregar funcionalidades testadas e funcionando. Este conjunto de tarefas chamado de Sprint backlog e mais freqentemente representado por uma lista de tarefas. Durante o SP2 a equipe pode ter dvidas adicionais sobre os requisitos. O ScrumMaster deve garantir que o Product Owner e, se necessrio, outras partes interessadas estejam de planto para respond-las. O desenho, como todo o resto no desenvolvimento, emergente. Alm disso, a reunio tem um tempo pr-estabelecido. Por isso, normal a equipe no ter o desenho perfeitamente concludo nesta reunio e descobrir mais tarefas durante o Sprint. Este no um sinal de que algo est errado. Eles devem simplesmente pegar um post-it e uma caneta e criar mais tarefas sempre que necessrio durante o Sprint.

  • Melhor Scrum 10

    Voc saber que o SP2 est sendo executado quando a equipe se rene em torno do quadro branco discutindo sobre a "melhor" maneira ou sobre a maneira "certa" para implementar um recurso.

    Reunio Diria do Scrum A reunio diria do Scrum um dos trs principais pontos de inspeo e adaptao no Scrum. A equipe se rene para se comunicar e sincronizar seus trabalhos. Uma vez que a equipe est colaborando, isto essencial para garantir o progresso contnuo e evitar bloqueios de trabalho. A equipe tambm ir avaliar continuamente o seu prprio progresso no sentido de atingir sua meta no Sprint. A reunio diria do Scrum no para relatar o progresso para o ScrumMaster ou Product Owner ou qualquer outra pessoa interessada. O Product Owner pode participar desde que ele permanea em posio passiva, falando apenas quando for questionado! O ScrumMaster deve garantir, usando todas as suas habilidades de facilitador, que cada membro da equipe se comprometeu a fazer algum trabalho para as prximas 24horas, que este tem como nico propsito ajudar a equipe como um todo a entregar o item seguinte na lista de pendncias e que os eventuais impedimentos para fazer este trabalho sero removidos para fora do caminho o mais rpido possvel. O ScrumMaster tambm deve garantir que a reunio seja restrita a 15 minutos, o que, surpreendentemente, tempo suficiente. Surpreendentemente reunies podem ser eficazes durante esse perodo curto de tempo. Jason Yip [Yip 2006] fornece um guia til para auxiliar o ScrumMasters na realizao desta reunio.

    Reviso do Sprint A reviso do Sprint (Sprint Review) muitas vezes erroneamente denominado de demo.Embora essa reunio inclua uma demonstrao das novas funcionalidades que a equipe concluiu durante o Sprint, seu principal objetivo inspecionar o que a equipe entregou e obter feedback dos participantes para adaptar o plano para o prximo Sprint. Assim o Sprint Review muito mais do que uma demonstrao. O foco da reviso do Sprint o produto que a equipe est construindo. Quando perguntado sobre quem deve ser convidado para a reviso de Sprint, eu respondo "o mundo inteiro". Minha inteno aqui ajudar o ScrumMaster e toda a organizao a entender que a ateno direta e feedback de um eleitorado mais amplo da organizao fundamental para maximizar o valor que a equipe vai entregar em sucessivos Sprints. Revises do Sprint tem muitos resultados possveis, incluindo o cancelamento do projeto. Na maioria dos casos, a equipe est autorizada a continuar por mais um Sprint e uma meta para este prximo Sprint deve ser definida.

    Espao para anotaes

  • Melhor Scrum 11

    Retrospectiva do Sprint A retrospectiva do Sprint a reunio final do Sprint. Segue-se imediatamente aps a reviso do Sprint. Nunca devemos omiti-la! Considerando que a reviso do Sprint focada no produto, a retrospectiva focada no processo e na forma em que a equipe Scrum est trabalhando em conjunto, incluindo as suas habilidades tcnicas e as prticas de desenvolvimento de software e ferramentas que esto usando. Considerando que a reviso do Sprint aberta a todos, a retrospectiva do Sprint restrita aos membros da equipe Scrum, que so o Product Owner, os membros da equipe de desenvolvimento e o ScrumMaster. Pessoas externas equipe, incluindo gerentes de todos os nveis da organizao so rigorosamente excludos a no ser que sejam especificamente convidados pela equipe. Esta regra deve ser entendida no contexto do objetivo da reunio, que inspecionar em um nvel profundo como a equipe est colaborando e tomar decises para melhorar. Isso muitas vezes exige introspeco profunda e compartilhamento, que por sua vez requer um ambiente seguro. Em A diretiva bsica da Retrospectiva (Retrospective Prime Directive) Norman Kerth ressalta o seguinte: "No importa em que evolumos, entendemos e acreditamos que cada um fazia o melhor que podia, dado o que sabia na poca, suas habilidades, recursos disponveis e a situao em que estavam." [Kerth 2001]. Boris Gloger [Gloger 2008] fornece um padro muito simples chamado Retrospectivas de Pulsao (Heartbeat Retrospectives) para que novas equipes possam aprender rapidamente a conduzir reunies de retrospectivas. Esther Derby e Diana Larsen [Derby e Larsen 2006] fornecem muitas atividades para facilitadores usarem durante essa reunio.

    Reunio de Estimativas. Esta reunio no mencionada na literatura Scrum, mas essencial se voc quer conseguir um fluxo contnuo dos recursos mais valiosos feitos a partir de suas equipes. Durante cada Sprint o Product Owner organiza uma ou duas reunies onde devem participar a equipe e, se necessrio, outras pessoas interessadas. Nesta reunio deve-se estimar o impacto de novos itens do backlog ou recalcular o tamanho de itens grandes que devem ser divididos em vrios itens pequenos, de forma tal que possam ser desenvolvidos no prximo Sprint.

    As equipes precisam dedicar de 5 a 10% de seu tempo durante o Sprint preparao para o prximo Sprint e subseqentes. A reunio de estimativas descrita acima um bom exemplo. Outros exemplos so as reunies de planejamento sobre como escrever histrias de usurios. Isso importante para evitar uma paralisao no limite (fim e incio) de cada Sprint. A outra implicao, claro que as equipes devem gastar de 90 a 95% de seu tempo fazendo o trabalho do Sprint atual!

  • Melhor Scrum 12

    Artefatos Scrum Scrum define apenas quatro artefatos:

    Product Backlog; Sprint Backlog; Grfico Burndown; Backlog de Impedimento;

    Scrum propositadamente no menciona nenhum outro documento e / ou artefato. Isso s vezes leva ao mal-entendido de que as equipes geis no precisam fazer qualquer documentao. Devemos treinar equipes para produzir apenas os artefatos que so realmente valiosos para si e para outros no futuro. Isso reduz o trabalho intil e a desnecessria matana de florestas!

    Product Backlog O product backlog simplesmente uma lista de itens de trabalho que precisa ser produzida ao longo do tempo. Os itens podem ser adicionados por qualquer pessoa, mas apenas o Product Owner tem o direito para determinar a ordem na qual eles vo ser executados pela equipe. Claro que um Product Owner bom vai negociar isso com as partes interessadas e com a equipe. Os requisitos esto emergindo, o que significa que no sabemos ou no podemos saber de antemo todos os itens e cada uma das caractersticas que queremos no produto final. por isso que o Product Backlog um documento vivo que exige a reviso constante para mant-lo atualizado e til ao longo do tempo. Muitos novos itens sero adicionados ao longo do tempo, itens existentes sero divididos em vrios itens menores, alguns itens sero removidos a partir da constatao de que no so mais necessrios. Alm disso, os itens devem ser estimados para determinar o custo-benefcio de cada um, que influenciam diretamente na prioridade que cada um ter e seus impactos em caso de atraso. Em praticamente todos os casos suficiente, e geralmente prefervel, criar e manter um Product Backlog num conjunto de histrias de usurios escritas em cartes de 150 x 100 mm. Ron Jeffries [Jeffries 2005] cunhou a aliterao Carto, Confirmao, Conversao (Card, Confirmation, Conversation, - os 3 Cs) para descrever como eles devem trabalhar com as histrias de usurios. As histrias so geralmente escritas a partir da perspectiva de um usurio do produto. O livro de Mike Cohn sobre histrias de usurios [Cohn 2004] vai dizer tudo o que voc precisa saber sobre elas.

    Sprint Backlog A maioria das equipes vai conhecer o Sprint Backlog como o quadro de tarefas, que a representao fsica da lista de trabalho que se comprometeram a fazer durante o Sprint atual. O quadro de tarefas um exemplo de um Kanban, palavra japonesa que significa sinalizao visvel. Ele comunica a equipe e qualquer outra pessoa que quiser saber das tarefas planejadas para o Sprint e seu status atual.

  • Melhor Scrum 13

    Sprint Burndown Chart O grfico de Sprint Burndown projetado para ajudar a equipe a monitorar seu progresso e ser um indicador importante para saber se eles vo cumprir o seu compromisso no final do Sprint. O formato clssico exige que a equipe estime a durao de cada tarefa em horas e em uma base diria para traar o total de horas restantes para todas as tarefas no concludas.

    Recomendo que as equipes construam em seu Sprint um grfico que demonstra os pontos da histria que devem ser realizados durante o Sprint atual. A lgica por trs disso :

    A estimativa de novas tarefas e re-estimativa de tarefas que esto em curso e que exigem um esforo considervel;

    As estimativas so imprecisas; A estimativa em unidades de tempo nos faz lembrar dos velhos hbitos de trabalho; A concluso das tarefas no entrega qualquer valor, apenas histrias concludas entregam valor;

    Portanto, em meu trabalho como consultor o Burndown Chart semelhante ao release ou produto, exceto pelo fato que o eixo X representa dias em vez de Sprints.

  • Melhor Scrum 14

    Produto ou Release Burndown Chart

    O grfico Burndown do produto, s vezes conhecido como o grfico Burndown de release, mede a taxa de entrega de funcionalidades, testadas ao longo do tempo. Esta taxa conhecida como a velocidade da equipe.

    Uma vez que as funes variam em complexidade e, portanto, em tempo e esforo, usamos uma escala para comparar tamanho. A escala mais comum conhecida como pontos de histrias de usurios. Uma vez que uma equipe tem trabalhado junto por alguns poucos Sprints, geralmente estabelece a sua velocidade dentro de um intervalo definido. Os Product Owners utilizam essa velocidade para prever a taxa que a equipe ir fornecer recursos no futuro, que conduz planos de liberao de produto e / ou release mais previsveis.

    Aconselhamos que a equipe use uma forma alternativa do grfico Burndown do produto que permita simultaneamente que os Product Owners controlem as alteraes do Product Backlog. Isto essencial dada a natureza dinmica desta lista. Usando esses grficos os Product Owners so capazes de relatar o progresso, identificar as datas de lanamento do produto e prever a extenso dos mesmos.

    Backlog de Impedimentos O backlog de impedimentos simplesmente uma lista de situaes que esto impedindo a equipe de progredir. Estas so situaes que o ScrumMaster deve colocar fora do caminho em sua busca incessante para ajudar a equipe a funcionar melhor. A gama de obstculos varia de precisar consertar a mquina de caf at ter que substituir o CEO! Um bom ScrumMaster tentar remover os impedimentos dentro de 24 horas desde sua identificao (OK, talvez substituir o CEO no se aplique!)

  • Melhor Scrum 15

    Iniciando Scrum Ken Schwaber [Schwaber 2007] disse certa vez que no h nada que precise ser feito antes de comear a usar Scrum. Interpretamos isso para dizer que no h adaptao do processo necessrio para iniciar. No entanto, praticamente nenhuma literatura auxilia nossa equipe Scrum a alcanar os primeiros sucessos sem ajuda externa. A melhor coisa que voc pode fazer contratar um treinador (coach) experiente. Se isso no for possvel, voc pode tentar usar um padro que j funciona com dezenas de equipes. Obviamente (eu espero) voc precisa de uma equipe Scrum. Isso significa ter um Product Owner, um ScrumMaster e de cinco a nove membros da equipe. Em seguida, siga essa seqncia de etapas, que sero detalhados nas prximas pginas.

    1. Treinar a equipe Scrum nos princpios do Scrum; 2. Estabelecer a viso; 3. Escrever histrias de usurio para formar o product backlog; 4. Ordenar os itens do backlog por valor de negcio; 5. Estimar o tamanho dos itens do backlog; 6. Reordenar o backlog, se necessrio, com base em fatores adicionais; 7. Criar o plano de release inicial; 8. Planejar o primeiro Sprint; 9. Comear os Sprints!

    Comeo o meu trabalho com uma nova equipe, com um treinamento de um dia sobre os fundamentos que eles precisam saber sobre metodologias geis e Scrum. Isto o suficiente para iniciar uma equipe Scrum que tenha um experiente ScrumMaster para apoi-la durante os primeiros Sprints.

    Os passos 2 a 7 podem ser definidos confortavelmente durante uma reunio de definio do produto que precisa contar com a equipe Scrum inteira. As melhores reunies so aquelas em que participam as partes interessadas, como arquitetos corporativos, gerentes de negcios e demais interessados no projeto.

  • Melhor Scrum 16

    Treinamento No treinamento da minha equipe eu uso um monte de exerccios em grupo e jogos para ilustrar os princpios. Tento cobrir a totalidade ou a maioria dos seguintes tpicos:

    O poder da auto-organizao; Processos empricos contra processos formalmente definidos; O valor do trabalho no mesmo espao fsico; A importncia da confiana; Princpios geis (Manifesto gil); O fluxo do Scrum (ciclo de reunies); Funes e responsabilidades (3 principais papis do Scrum); Usando histrias de usurios para os requisitos; Estimativas usando Agile Planning Poker; Conceitos de tamanho e velocidade; Conceito de Pronto! Usando um painel de tarefas; Acompanhamento dos progressos (grficos de burndown); Simulao de um Sprint inteiro.

    Definindo a viso Katzenberg e Smith [2002] confirmaram que ter objetivos claros essencial para moldar equipes de alta performance. O Product Owner geralmente ir partilhar a sua viso do produto. Uma tcnica que uso pedir a cada membro da equipe para escrever a sua verso da viso. Ento fazemos uma formao em pares e pedimos para chegar a uma viso que combina para ambos. O processo continua com dois pares de trabalho da mesma maneira e assim, at que a equipe completa conclui com uma viso nica. Este exerccio usa o poder do grupo em conjunto, resultando em maior compromisso com a viso obtida. A equipe deve apresentar a viso de modo proeminente em seu ambiente de trabalho. O exerccio de definio da viso pode ocupar cerca de trs horas.

    Criando o Product Backlog A prxima etapa a realizao de uma reunio para escrever histrias de usurios. vantajoso envolver partes interessadas no negcio nessa reunio. Certamente toda a equipe Scrum dever ser envolvida. Claro, o ScrumMaster ser o facilitador. Escrever boas histrias de usurios simplesmente uma questo de prtica. O princpio de Pareto (regra 80/20) tambm se aplica nessa etapa, assim como se aplica em diversos outros casos.

  • Melhor Scrum 17

    Mike Cohn [Cohn 2004] tem proporcionado um excelente guia para escrever histrias de usurio. Eu encorajo todos os Product Owners a terem uma cpia desse exemplar sempre mo! Bill Wake [Wake 2003] sugere a utilizao do acrnimo INVEST para lembrar os atributos que uma boa histria de usurio deve ter. No mnimo, o backlog deve conter elementos suficientes para a equipe planejar o primeiro Sprint. Comumente, o backlog contm todos os itens que compem o prximo release do produto. Como referncia, o backlog deve conter 80% de tarefas que possam ser concludas at o final do primeiro dia. A primeira parte do dia dois pode ser usada para adicionar os 20% restante e para resolver quaisquer questes pendentes. A pausa durante os dois dias muito importante, pois pode desencadear uma nova reflexo sobre o trabalho e gerar novas idias.

    Ordenando o backlog O backlog deve ser classificado por valor de negcio. Isto muito mais fcil de falar do que fazer. Mike Cohn [Cohn 2006] descreve dois mtodos para priorizar: o modelo Kano de satisfao do cliente e a abordagem Wiegers de ponderao relativa. O que eu gosto sobre estes dois mtodos que no s consideram o benefcio esperado para ter a funcionalidade, mas tambm leva em conta a penalizao por no ter tal funcionalidade. Isto particularmente til quando o backlog contm itens tcnicos, cujo valor do negcio no imediatamente bvio. No mnimo precisamos do julgamento subjetivo do Product Owner para avaliar uma funcionalidade em detrimento de outra. prefervel uma abordagem quantitativa utilizando uma tcnica semelhante ao Planning Poker. No importa como ser executada a ordenao do backlog uma das principais responsabilidades do Product Owner.

    Template: Em um determinado papel, eu quero funcionalidade por uma razo.

    Exemplo: Como um programador, eu quero caf para ficar acordado.

    Independent Independente pode ser implementada em qualquer ordem; Negotiable Negocivel ou no negocivel; Valuable Valiosa para o cliente; Estimatable Suficientemente estimvel para classificar e agendar; Small Pequeno e com breves descries; Testable Testvel eu poderia escrever um teste para essa funcionalidade.

  • Melhor Scrum 18

    Estimando o Backlog A estimativa tem sido sempre a chave para a conduo eficaz do planejamento de projetos. Gerentes de projeto passam semanas avaliando modelos complexos com dados histricos. A dura realidade que o melhor dessas tcnicas no proporciona melhores resultados que tcnicas muito simples, como o Planning Poker ou estimativa por afinidade. O Planning Poker funciona em parte porque est embasado em uma slida teoria, mas principalmente porque as pessoas que fazem as estimativas so as mesmas que realizam o trabalho. Quem teria pensado nisso? O Planning Poker rpido. Uma equipe com experincia estima em mdia um item a cada 3 minutos. O Planning Poker preciso. As estimativas obtidas usando Planning Poker so to boas quanto s obtidas com mtodos tradicionais. E, sobretudo, o Planning Poker divertido. Remove parte do tdio associado esta fase. A estimativa por afinidade ainda mais rpida do que o Planning Poker. tima para comear quando temos um backlog grande e o tempo mais importante do que a preciso e compartilhamento de informaes. No entanto, ainda precisamos entender alguns conceitos-chave sobre estimativa gil:

    Ns dimensionamos os itens do backlog atravs de comparao com outros itens. Por qu? Porque, como seres humanos encontramos resultados mais naturais e mais confiveis nas comparaes. Portanto, fcil concordar que "uma determinada histria de usurio o dobro da complexidade de outra histria" mesmo que ainda no saiba quanto tempo cada histria vai usar para ser implementada.

    Ns dimensionamos os itens do backlog usando unidades de complexidade ao invs de tempo. Por qu? Porque permite separar a taxa que uma equipe trabalha a partir do tamanho ou complexidade do trabalho. Isso nos protege de ter que mudar nossas estimativas de acordo com quem faz o trabalho, ou de acordo com as habilidades e capacidades de mudana da equipe ao longo do tempo. Usamos pontos da histria de usurio como unidades de medida.

    Usamos uma escala no-linear para calibrar que a diferena entre um '1' e um '2' , obviamente, mais significativa relativamente, do que entre '20' e '21'. Minha preferncia usar os nmeros pseudo-Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40 e 100. E definindo de 1 a 13 como o intervalo de tamanho de caractersticas que uma equipe pode entregar em um Sprint. Os nmeros mais elevados so reservados para grandes histrias (picos) que precisaro ser divididas em histrias menores antes que elas possam ser adotadas em um Sprint.

    Relatamos nossas estimativas de tamanho de tempo por meio de velocidade, que a taxa na qual uma equipe pode entregar funcionalidades testadas ao Product Owner. Dizemos que uma equipe tem uma velocidade de '25', quando eles so capazes de entregar no final de cada Sprint histrias cujos tamanhos, em mdia, somam 25 pontos.

    No uma boa idia comparar as estimativas entre equipes, a menos que estejam trabalhando no mesmo backlog. Esta uma questo de escala Scrum e facilmente resolvida, mas no um tpico para este pequeno guia.

  • Melhor Scrum 19

    Reordenando o Backlog Aps o dimensionamento dos itens do backlog podemos descobrir que alguns itens devem ser reordenados. Devemos levar em conta, alm do valor de negcio, os seguintes fatores:

    Tamanho: naturalmente vamos optar por implementar uma histria pequena e simples frente uma histria grande e complexa, se eles tm valor de negcio similar;

    Aprendizagem: podemos optar por implementar uma histria mais cedo que ajudar a equipe a aprender sobre o domnio do negcio ou uma nova tecnologia;

    Risco: podemos optar por implementar uma histria no incio, porque isso vai mitigar um risco identificado. Os exemplos mais bvios so os itens que ajudaro a estabelecer limites de desempenho e escalabilidade.

    Devemos sempre lembrar que o Product Owner tem palavra final sobre a ordenao do backlog.

    Release Planning Uma vez que tenhamos ordenado e avaliado o backlog, o prximo passo criar o plano inicial de liberao (Release Planning). Para fazer isso precisamos de uma estimativa da velocidade de nossa equipe. No entanto, como ainda no fizemos nenhum trabalho nesse momento, usamos uma tcnica simples, conhecida como planejamento baseado em compromisso. Primeiro, claro, devemos ter a certeza de saber o tamanho da equipe durante o Sprint e se qualquer membro da equipe ser afastado por licena, etc. Temos que definir o tamanho do Sprint. Geralmente recomendo que seja de duas semanas para uma nova equipe. Temos, ento, que criar uma definio de pronto para a equipe - o que d a equipe a noo de dizer que completou uma histria. O ScrumMaster agora pega o primeiro item a partir do topo do backlog e questiona equipe: "vocs podem completar este item durante o Sprint?. Ele continua fazendo isso at que a equipe decide no adicionar mais itens ao Sprint. Contando os pontos de histria de todos os itens comprometidos, a equipe tem a sua estimativa inicial de velocidade. Este valor de velocidade utilizado para distribuir os itens restantes do backlog ao longo de sucessivos Sprints. Esta lista de itens ligados Sprints o nosso Release Planning inicial. Ele exato? Talvez no, mas provavelmente mais aceitvel que qualquer coisa que um gerente de projetos possa produzir em um estgio inicial de um projeto. Uma vez que comeamos a trabalhar e completar um Sprint atrs do outro, vamos comear a traar a nossa velocidade atual e usar isto como um indicador de produo futura. Assim, o plano de lanamento (Release Planning) uma entidade viva que se torna mais e mais confivel medida que progredimos.

    No deixe que o release planning seja desnecessariamente longo.

    possvel preparar um backlog suficiente para o primeiro sprint em apenas

    dois dias para quase qualquer combinao de equipe e produto.

  • Melhor Scrum 20

    Localizao fsica de equipes Scrum Alistair Cockburn [Cockburn 2007] define o desenvolvimento de software como um jogo de inveno, cooperao e comunicao. O manifesto gil diz que os desenvolvedores e representantes das empresas devem trabalhar juntos em uma base diria e que conversas frente a frente so a melhor forma de transferir informaes. Sem dvida o mais importante para uma equipe colaborar de forma eficaz o compartilhamento no mesmo espao fsico. Um estudo sobre as equipes de desenvolvimento de software com equipes que compartilham o mesmo espao fsico [Teasley, Covi, Krishnan, & Olson, 2000] mostraram que elas tinham duas vezes mais produtividade que outras equipes onde os membros foram separados uns dos outros. A definio que eu uso para "compartilhar o mesmo espao fsico" que os membros da equipe estejam sentados no mximo num raio de 6 metros de distncia. Essa definio resulta na existncia de um limite para o nmero de pessoas que podem se acomodar em tal espao. Na prtica, este nmero de 8 a 10 pessoas, que felizmente corresponde ao tamanho mximo de uma equipe Scrum. Alm disso, cada membro da equipe deve ser capaz de ver todos os outros membros com o simples gesto de virar a cabea ou virar sua cadeira giratria para o lado. Isto significa que no devem haver divisrias entre as mesas - Adeus Dilbertville! Sem nenhuma boa razo alm do hbito, as organizaes dificilmente so relutantes em mudar o ambiente de trabalho para facilitar essa colaborao. Isto , h evidncias que mostram que os espaos das equipes no necessitam ser ampliados, podendo manter os layouts atuais. Qualquer proposta para uma reestruturao do espao fsico pode ser criticada pela administrao como uma ameaa a flexibilidade. Isto no necessariamente a verdade, pois a flexibilidade necessria na estrutura organizacional, e no no escritrio! Minha experincia que 90% das novas equipes de Scrum em organizaes que se esforam para praticar metodologias geis tem reas de trabalho simplistas e que esto se esforando para no horizonte de um ano realizar as mudanas necessrias para desenvolver um ambiente ldico. E uma vez que essas mudanas so feitas, todos concordam que converge para melhoria imediata e mensurvel. Por que isso ocorre? com a esperana de que esta resistncia absurda diminua com o tempo que ofereo aqui um esquema simples de trabalho para uma equipe Scrum. Esse esquema vai alm do escopo deste pequeno guia e para fornecer todo o raciocnio por trs deste projeto, voc ter que contratar-me!

    Salas de equipes reduzem significativamente a necessidade de usar salas de reunies para fazer o Sprint Planning, reunies dirias e revises em seu escritrio.

    Saiba de antemo que o designer ou arquiteto que trabalha para a sua empresa no vai ser de grande ajuda. Normalmente ele no estudou para criar espaos para o trabalho em equipe.

    O custo das mudanas ser recuperado no prazo de uma semana a um ms! Parece inacreditvel, no ?

  • Melhor Scrum 21

    Alguns parmetros de montagem da sala:

    As mesas devem ser retangulares para facilitar o trabalho em pares; Mesas de 1,5-1,8 m x 0,8 m so mesas de bom tamanho; Entre uma mesa e uma parede recomendo 1,2 m de espao; O canto de desenho deve medir cerca de 3 x 3 m; O tamanho tpico da sala deve ter 7 x 8 m = 50 a 60 m; O ScrumMaster deve ver toda equipe; O Product Owner tem um local no permanente; As paredes com janelas internas criam barreiras de rudo e do espao suficiente para radiadores de informao sem reduzir a luz;

  • Melhor Scrum 22

    Mtricas razovel esperar de qualquer gestor que ele queira, dentro de um perodo razovel, algumas medidas para ser capaz de aferir os resultados de uma equipe ou da transio da organizao para metodologias geis. Felizmente, existem mtricas que so fceis e rpidas de implementar. Baseado em minha prpria pesquisa e de outros profissionais geis, eu descrevi um conjunto de mtricas que sua equipe pode e deve implementar [Hundermark 2009]. Logo que a equipe entende o bsico do Scrum e tem alguma idia de sua velocidade - provavelmente no final do seu terceiro Sprint ser o momento para iniciar a medio. Na verdade, voc pode executar pesquisas de satisfao com clientes e equipes antes mesmo de comear com Scrum! Sem mais explicaes aqui, o conjunto de mtricas que eu recomendo para uma implementao inicial :

    Pesquisas com clientes e equipes; Grfico de velocidade; Grfico Burndown; A execuo de testes automatizados; Dvida Tcnica; Trabalho em processo; Tempo mdio do ciclo de concluso de histrias de usurios;

    E uma vez que a equipe foi capaz de colocar em algum tipo de medida para o valor do negcio, adicione o seguinte:

    Custo por Sprint ou pontos da histria; Valor real entregue; ROI Retorno sobre Investimento ou NPV Valor Presente Lquido (Net Present Value).

    Espao para anotaes

  • Melhor Scrum 23

    Coaching O que faz um treinador (coach)?

    Coaching Scrum definido como um compromisso com uma ou mais organizaes / equipes durante o qual o coach (treinador) atua como um mentor ou facilitador para as equipes melhorarem sua compreenso e aplicao de Scrum para chegar aos seus objetivos. O trabalho de orientao (mentoring) inclui indivduos e equipes, facilitao do processo de desenvolvimento, facilitao organizacional, alinhamento e interao com todos os nveis de liderana dentro de uma organizao. Pode tambm incluir orientao em mtodos relacionados com a eficcia do Scrum, os princpios descritos no Manifesto gil, os princpios Lean, e prticas de Extreme Programming.

    Certified Scrum Coach Application, Scrum Alliance

    Um treinador (coach) orienta indivduos dentro de uma organizao das seguintes maneiras:

    Conselho e consultoria para melhorar e acelerar o processo de auto-descoberta;

    Facilitar a adoo, implementao e aprendizagem Scrum; Liderana gil com base em um estilo de liderana servidora; Desenvolvimento organizacional para melhorar as habilidades, recursos e criatividade.

    Por que minha organizao precisa de coaching? Desenvolvimento de software e outros tipos de trabalhos realizados por trabalhadores do conhecimento se baseia no conhecimento tcito, em oposio com o conhecimento formal ou explcito. O conhecimento tcito difcil de se transmitir de pessoa para pessoa e geralmente obtido atravs da experincia pessoal. Um exemplo poderia ser o de aprender a andar de bicicleta. O papel do ScrumMaster deve conduzir a adoo e definio do processo, tanto para a equipe Scrum como para o restante da organizao. Formaes tericas, como por exemplo curso para Certificao ScrumMaster, um meio insuficiente para para adquirir o conhecimento tcito necessrio para utilizar eficazmente metodologias geis e Scrum na prtica. A equipe e a organizao precisam das habilidades de um profissional experiente, para gui-los atravs do labirinto de desafios que enfrentaro durante a transio para uma forma mais gil de trabalhar. A resposta mais freqente quando perguntamos aos gestores das organizaes o que fariam para terem uma transio mais eficaz para metodologias geis e Scrum "Faramos mais Coaching.

  • Melhor Scrum 24

    Referncias 1. Cockburn, Alistair (2007). Agile Software Development: The Cooperative Game (2nd edition). Addison Wesley 2. Cohn, Mike (2004). User Stories Applied. Addison Wesley. 3. Cohn, Mike (2006). Agile Estimating and Planning. Prentice Hall. 4. Gloger, Boris (2008). Heartbeat Retrospectives. http://borisgloger.com/ 2008/04/24/heart-beat-retrospectives-1-introduction/. 5. Highsmith, Jim, et al (2001). Manifesto for Agile Software Development. http:// www.agilemanifesto.org/. 6. Hundermark, Peter (2009). Measuring for Results. http://www.scrumsense.com/ coaching/measuring-for-results. 7. Jeffries, Ron (2001). Card, Conversation, Conrmation. http:// www.xprogramming.com/xpmag/expCardConversationConrmation. 8. Katzenberg, Jon R. And Smith, Douglas K. (2002). The Wisdom of Teams. Collins. 9. Nonaka, Ikujiro and Takeuchi, Hirotaka (1986). The New, New Product Development Game. Harvard Business Review, Jan-Feb 1986. 10. Sliger, Michele and Broderick, Stacia (2008). The Software Project Managers Bridge to Agility. Addison Wesley. 11. Schwaber, Ken (2007). The Enterprise and Scrum. Microsoft Press. 12. Schwaber, Ken (2009). Scrum Guide. http://www.scrumalliance.com/resources]. 13. Teasley, Covi, Krishnan, & Olson (2000). How Does Radical Collocation Help a Team Succeed? Proceedings of the 2000 ACM Conference on Computer Supported Cooperative Work (pp. 339 - 346). New York: ACM. 14. Wake, William (2003). INVEST in Good Stories, and SMART Tasks. http:// xp123.com/xplor/xp0308/index.shtml 15. Yip, Jason (2006). It's Not Just Standing Up: Patterns of Daily Stand-up Meetings. http://martinfowler.com/articles/itsNotJustStandingUp.html.