neste artigo de nível introdutório, olhamos para a mecânica de um Sprint, e para como os membros da equipe são esperados para colaborar a fim de produzir um incremento de qualidade de lançamento.

the first day: Sprint Planning

the whole team, including the Product Owner, meet on the first day of the Sprint and conduct a Sprint Planning session. Esta é a primeira coisa a acontecer assim que o Sprint começa.o planeamento Sprint deve ser preparado. A preparação mais importante é garantir que o atraso do produto tenha sido refinado a um nível adequado de detalhe, com estimativas e critérios de aceitação (este é o propósito do refinamento do atraso do produto). Em seguida, o proprietário do produto deve ter encomendado o trabalho no Backlog do produto, e ter uma idéia geral de como negociar um objetivo Sprint valioso com a equipe. As opções para negociar um objetivo também deveriam ter sido consideradas durante o refinamento, e refletidas na ordenação de backlog. Além disso, a equipe deve ter uma idéia de sua capacidade para este Sprint, ou seja, quanto trabalho eles acreditam que podem assumir. Eles podem ser capazes de usar sua experiência com Sprints anteriores para ajudá-los a determinar o tamanho deste orçamento.

primeiro planeie o valor que será entregue

cada Sprint deverá resultar num aumento valioso do trabalho completo, apto e pronto para lançamento imediato. O proprietário do produto é totalmente responsável pelo que “valor” significa, e deve ter ordenado o Backlog do produto de tal forma que o valor pode ser maximizado pela equipe, sprint-by-sprint. A primeira coisa que a equipe deve fazer é, portanto, planejar quais itens do backlog de produtos devem ser trabalhados neste Sprint, de modo que o melhor valor pode ser entregue até o final dele.para isso, a equipe trabalha com o proprietário do produto para selecionar os itens mais valiosos do Backlog do produto que se encaixa na capacidade projetada para o Sprint. Tenha em mente que cada item no Backlog do produto deveria ter sido dada uma estimativa pela equipe, para que eles saibam aproximadamente quanto trabalho é provável estar envolvido. esta seleção de trabalho deve ser coesa, e não apenas um agrupamento de itens não relacionados e díspares. Lembre-se que um Sprint é uma oportunidade de tempo para alcançar algo significativo. Por exemplo, no final do Sprint pode ter sido apresentada uma característica coerente, ou um risco significativo terá sido mitigado. O Sprint Goal é uma expressão simples deste propósito, do significado global do trabalho selecionado e da coerência por trás da seleção.um bom objetivo Sprint permitirá à equipe demonstrar foco e compromisso, e permitir a colaboração e o re-planejamento do trabalho para que ele seja cumprido.

próximo plano de como o trabalho será feito

um Sprint Backlog é mais do que apenas uma selecção de trabalho com um objectivo final em mente. É também um plano para como esse objetivo será alcançado, e como o trabalho associado será realizado. Isto pode ser feito identificando e ordenando as tarefas técnicas que são susceptíveis de ser envolvidas. Com efeito, o Sprint Backlog é um plano para cumprir o objectivo Sprint, e uma previsão do trabalho que terá de ser feito.

O proprietário do produto não precisa de estar presente nesta parte do planeamento Sprint, uma vez que cabe à equipa planear esta Previsão a nível técnico. No entanto, o proprietário do produto deve estar disponível, mesmo que apenas remotamente, para responder a quaisquer perguntas que a equipe possa ter, e para fornecer qualquer esclarecimento que possa ser necessário sobre o escopo do trabalho. Se mais de um lançamento é esperado durante o Sprint, isso deve ser acordado com o PO e contabilizado no Sprint Backlog.no final do planeamento Sprint, uma equipa deve estar confiante de que fez uma boa previsão do trabalho que será necessário para atingir o objectivo Sprint. Ele terá capturado esse plano no Sprint Backlog que a equipe totalmente possui. A equipa deve ser capaz de começar a implementar esse plano imediatamente e com uma clara compreensão – como um sprint Burndown – da quantidade de trabalho que resta em determinado momento.

cada dia, todos os dias

uma vez que a equipa tenha planeado o seu Sprint Backlog podem começar a trabalhar. Se eles planejaram as coisas como tarefas, eles colaborarão uns com os outros, como uma equipe, para garantir que essas tarefas sejam concluídas. Eles serão capazes de rastrear o seu progresso usando o seu quadro de tarefas e o seu Sprint Burndown de trabalho restante.

cada membro da equipa terá a certeza de manter o Scrum Task Board e o Sprint Burndown atualizado, para que a informação possa ser invocada por outros. Um radiador de informação deve sempre dizer a verdade.

mantenha um Scrum diário

todos os dias úteis, ao mesmo tempo, a equipa de desenvolvimento irá reunir e planear o que fará para os aproximar do objectivo de Sprint. Esta reunião chama-se Daily Scrum e nunca deve demorar mais de 15 minutos.

apenas os membros da equipa de desenvolvimento devem participar, uma vez que o plano de trabalho pertence inteiramente a eles. Trata-se de uma oportunidade para voltar a planear o Sprint como resultado de novas descobertas e lições aprendidas durante o Sprint. Toda a equipa deve participar. Cada membro da equipe deve ser capaz de dar conta de:

• o Que eles fizeram ontem para ajudar a equipe a cumprir a Sprint Objetivo
• o Que eles pretendem fazer hoje para ajudar a equipe a cumprir a Sprint Objetivo
• Quaisquer impedimentos que estão atrapalhando o seu caminho

até o final do Daily Scrum, a equipe deve ter um plano claro para as próximas 24 horas e uma compreensão de como eles terão de colaborar para o conseguir. Eles também devem ter uma lista de quaisquer impedimentos que requerem a atenção do mestre Scrum.

Refinar o Product Backlog

No Scrum, o Product Backlog Refinamento não é um evento formal, mas de uma atividade contínua – o processo de adição de detalhes, de ordem, e as estimativas para o Product Backlog Itens, tais como as Histórias de Usuário. Cabe às próprias equipes Scrum decidir quantas vezes fazer isso, embora seja certamente uma boa idéia para eles para construir refinamento em sua rotina diária. Refinement não deve levar mais de 10% do tempo total de uma equipe durante um Sprint. Para a maioria das equipes, meia hora por dia pode ser adequada, embora alguns possam preferir passar uma hora ou duas vezes por semana. O importante é certificar-se de que o Backlog do produto é refinado em tempo hábil para que o planejamento Sprint possa ocorrer sem impedimentos. A equipe inteira, incluindo o proprietário do produto, deve participar.

uma sessão de refinamento normalmente começa com o proprietário do produto Apresentando o Backlog do produto atual para a equipe. O backlog pode ser mantido em uma série de formas, como uma placa de Scrum eletrônico ou outra ferramenta de colaboração, ou pode simplesmente ser uma planilha. Um projetor ou tela compartilhada pode ser muito útil.

the team start at the top of the Product Backlog and work their way Downward, refining each item in turn. Eles examinarão cada um e discutirão seu escopo, e os critérios de aceitação que serão necessários para sua conclusão. Cada item será então estimado usando uma técnica como o planejamento de Poker. Um item grande pode ser dividido em itens menores que capturem mais detalhes. Os Epic podem ser decompostos em histórias de usuários, por exemplo.

A equipa pára assim que a caixa de tempo da sessão terminar. Eles vão recomeçar onde pararam da próxima vez, eventualmente começando no topo novamente para que o backlog seja mantido atualizado.

sempre colabore

na prática ágil, os membros da equipe nunca trabalham isoladamente – se o fizessem, não seriam uma equipe. De fato, o trabalho em equipe é tão importante que o papel é a equipe de desenvolvimento e não o desenvolvedor.isto significa que cada membro da equipa de desenvolvimento deve colaborar com os seus pares durante todo o dia, uma vez que são conjuntamente responsáveis pelo progresso do trabalho. Quaisquer problemas ou falhas são propriedade conjunta da equipe, bem como seus sucessos. A colaboração não se restringe a eventos como o Scrum diário, mas aplica-se a tudo o que a equipe faz ao longo de cada Sprint inteiro.exemplos de colaboração incluem::

• a Ajudar os colegas para completar o trabalho em andamento antes de colocar no novo trabalho a partir de uma lista de pendências
• a programação em Par, como se revezando para usar o teclado e o ajudando e verificar o trabalho de cada um
• revisão de Pares
• a Pedir ajuda, e estar dispostos a dar-lhe
• Indo para onde o trabalho e a ajudar, em vez de esperar para o trabalho ser passado para eles
• certificando-se de que todo o trabalho que, de facto, satisfazem a Definição de Done
• Chamar um Scrum para resolver problemas que precisam da equipe de atenção imediata
• Aumentar impedimentos para o Scrum Master para que eles possam ser manipulados em tempo hábil
• a Atualização de um Scrum quadro de Tarefas e o burndown chart de modo que as informações up-to-date e pode ser invocado
• Habilidade e a partilha de conhecimento

O último dia: Revisão e Retrospectiva

Mantenha uma Sprint Review

Se uma equipe tem colaborado de forma eficiente, eles têm trabalhado em conjunto para atender a Sprint Objetivo, gestão de riscos e ajustar seus planos conforme necessário. Eles terão demonstrado controle durante todo o Sprint através de um mesmo esgotamento de trabalho restante, onde cada membro viu como sua responsabilidade pessoal para ajudar a concluir o trabalho em progresso. Eles terão um incremento valioso para demonstrar ao proprietário do produto e a todas as partes interessadas convidadas. Uma revisão é algo que uma equipa deve esperar ansiosamente.também é algo para o qual uma equipa tem de se preparar. Deve ser concedido tempo suficiente para uma demonstração do trabalho realizado. As tarefas podem ser planejadas em um Sprint Backlog para este fim, para garantir que a revisão faz justiça ao trabalho feito e ao valor que está agora disponível. Além disso, se o proprietário do produto acha que seria uma boa idéia convidar partes interessadas, então esses convites deveriam ter sido enviados. A revisão é uma oportunidade para celebrar o trabalho que foi feito e para mostrar suas realizações, de modo que a confiança é inspirada e um investimento contínuo na equipe pode ser justificado.

uma revisão Sprint também é uma oportunidade de inspecionar e adaptar. É uma boa altura para o proprietário do produto explicar como o produto está a funcionar bem, para obter feedback em primeira mão de quaisquer partes convidadas, e para tirar quaisquer lições que possam ser usadas para melhorar ainda mais o atraso do produto. Se algum trabalho não tiver sido concluído, por qualquer razão, então isso também será revisto e re-estimado no Backlog do produto para possível planejamento em sprints futuros.

em Seguida, realizar um Sprint Retrospective

Revisão Do Sprint olhou para o Produto e o valor entregue, no trabalho que tem sido feito, e honestamente e abertamente em qualquer trabalho que não foi feito, qualquer que seja o motivo.
a próxima coisa a fazer é realizar uma retrospectiva Sprint. Uma retrospectiva considera o processo que a equipe está acompanhando. Estão a trabalhar da forma mais eficaz possível? Geralmente é melhor realizar a retrospectiva imediatamente após a revisão, porque o primeiro pode introduzir idéias para consideração no segundo.

toda a equipe de desenvolvimento, o proprietário do produto e o mestre Scrum devem todos participar da retrospectiva, porque todos são conjuntamente responsáveis pelo sucesso do trabalho da equipe. É realmente importante ter uma sessão livre e aberta que chega ao coração de quaisquer problemas e identifica ações que irão ajudar a resolvê-los. Uma declaração retrospectiva pode começar com a seguinte declaração::”independentemente do que descobrimos, entendemos e acreditamos verdadeiramente que todos fizeram o melhor trabalho possível, dado o que sabiam na altura, as suas competências e capacidades, os recursos disponíveis e a situação em mãos.”

In a “Retro”, everyone has an equal voice. Uma abordagem, que o mestre Scrum pode facilitar, é identificar:coisas que correram bem coisas que não correram tão bem ideias para melhorias para membros da equipa que fizeram algo excepcional estabelecimento de uma linha de tempo pode ajudar as memórias dos participantes de jog sobre eventos significativos durante o Sprint.