Partilhar via

Scrum e melhores práticas

  • Artigo

Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019

Reuniões de planejamento de sprint

Grande parte do planejamento de sprint envolve uma negociação entre o proprietário do produto e a equipe para determinar o foco e o trabalho a ser enfrentado na próxima sprint. É útil cronometrar a reunião de planejamento, restringindo-a a 4 horas ou menos.

Na primeira parte da reunião, o proprietário do produto se reúne com sua equipe para discutir as histórias de usuário que podem ser incluídas no sprint. O proprietário do produto compartilha informações e responde a todas as perguntas que sua equipe tem sobre essas histórias. Essa conversa pode revelar detalhes como fontes de dados e layout da interface do usuário. Ou pode revelar expectativas de tempo de resposta e considerações de segurança e usabilidade. Sua equipe deve capturar esses detalhes no formulário de itens da lista de pendências. Durante esta parte da reunião, sua equipe aprende o que deve construir.

Ao planejar seus sprints, você pode descobrir outros requisitos para capturar e adicionar à sua lista de pendências. Certifique-se de que está bem definido e em ordem de prioridade.

Além disso, definir uma meta de sprint como parte de seus esforços de planejamento pode ajudar a equipe a manter o foco no que é mais importante para cada sprint.

Depois de planejar seu sprint, você pode compartilhar o plano com as principais partes interessadas.

Pode saber mais com estes recursos:

Definir metas de sprint

As equipes Scrum usam metas de sprint para focar suas atividades de sprint. Eles geralmente estabelecem essa meta durante sua reunião de planejamento de sprint. O objetivo resume o que a equipa quer realizar até ao final do sprint. Ao declarar explicitamente o objetivo, você cria um entendimento compartilhado dentro da equipe do propósito principal. A meta de sprint também pode ajudar a orientar a equipe quando surgem conflitos em torno de prioridades.

Dicas das trincheiras: Defina metas de sprint

A meta de sprint define o que o proprietário do produto e a equipe consideram como o objetivo final para realizar esse sprint. Não é uma seleção aleatória de itens da lista de pendências que realmente não têm um relacionamento, mas um pequeno pedaço de texto que captura o que a equipe deve tentar realizar. Normalmente, o proprietário do produto apresenta a meta de sprint antes de selecionar muitos itens para a próxima sprint. Os itens para esse sprint devem se encaixar nesse objetivo comum.

As metas da Sprint podem ser orientadas a recursos, mas também podem ter um grande componente de processo, como automação de implantação ou automação de testes.

Por exemplo:

  • Neste sprint, vamos nos concentrar em uma história de usuário simples. Vamos usá-lo para provar que a solução proposta funciona.
  • Este sprint gira em torno da implementação dos recursos de segurança que protegem adequadamente a seção de administração do site.
  • Este sprint é sobre a integração dos gateways de pagamento mais importantes para que possamos começar a coletar dinheiro.

Definir as metas de sprint ajuda a equipe a manter o foco. Isso facilita a definição de prioridade de tarefas dentro de um sprint e provavelmente ajuda a limitar o número de partes interessadas e usuários finais envolvidos.

Durante a revisão do sprint, a pergunta mais importante que você deve se fazer é se você conseguiu atingir o objetivo do sprint. Quantas histórias você completou vem em segundo lugar. Se o objetivo for alcançado, o sprint é bem-sucedido, mesmo que nem todas as histórias tenham sido concluídas.

Contribuição de Jesse Houwing, Visual Studio devops Ranger e consultor sênior que trabalha para a Avanade Holanda.

Dicas para reuniões de triagem bem-sucedidas

A correção de bugs representa uma compensação com outros trabalhos. Use sua reunião de triagem para determinar o quão importante é a correção de cada bug em relação a outras prioridades relacionadas ao cumprimento do escopo, orçamento e cronograma do projeto.

  • Estabeleça os critérios da equipe para avaliar quais bugs corrigir e como atribuir prioridade e gravidade. Bugs associados a recursos de valor significativo (ou custo de oportunidade significativo de atraso), ou outros riscos do projeto, devem receber maior prioridade e gravidade. Guarde seus critérios de triagem com outros documentos da equipe e atualize conforme necessário.
  • Use seus critérios de triagem para determinar quais bugs corrigir e como definir seu Estado, Prioridade, Severidade e outros campos.
  • Ajuste seus critérios de triagem com base em onde você está em seu ciclo de desenvolvimento. Logo no início, você pode decidir corrigir a maioria dos bugs que você tria. No entanto, mais tarde no ciclo, você pode aumentar os critérios de triagem para reduzir o número de bugs que você precisa corrigir.
  • Depois de triar um bug, atribua-o a um desenvolvedor. O desenvolvedor pode então investigar e determinar como implementar uma correção.

Faça a gestão da sua dívida técnica

Considere gerenciar sua barra de bugs e dívida técnica como parte do conjunto geral de atividades de melhoria contínua da sua equipe. Poderá encontrar estes recursos de interesse:

Dicas das trincheiras: Gestão de bugs

Gestão Ágil de Bugs: Não é um Oximoro
por Gregg Boer, Gerente de Programa Principal, Visual Studio Cloud Services na Microsoft

Resolva qualquer dívida de bug conhecida a cada sprint

A cada sprint, a equipe analisa quaisquer bugs remanescentes na lista de pendências de bugs e dedica capacidade para reduzir esse conjunto conhecido de bugs a zero, ou quase zero. Seja um dia, uma semana ou todo o sprint, eles corrigem os bugs primeiro. Bugs encontrados posteriormente, dentro do sprint, não são considerados parte desse compromisso inicial. A menos que sejam de alta prioridade, eles são colocados na lista de pendências de bugs para o próximo sprint.

Muitas equipas trabalham numa organização baseada no compromisso. Muitas vezes, a gestão valoriza muito a capacidade de uma equipa cumprir os seus compromissos. Fazer o planejamento de capacidade contra um conjunto conhecido de bugs torna o planejamento de sprint mais determinístico, aumentando sua chance de cumprir compromissos. Quaisquer novos bugs descobertos durante o sprint não fazem parte do compromisso inicial e podem ser resolvidos no próximo sprint.

Gerencie dívidas de bugs em toda a empresa

Uma organização em transição para uma cultura em que a dívida é continuamente eliminada provavelmente está lidando com a seguinte pergunta: Como fazer com que as equipes reduzam a contagem de bugs sem dizer exatamente o que fazer? A liderança quer que a equipe mude, mas dá autonomia à equipe para determinar como eles mudam. Uma opção é usar uma tampa de bug.

Por exemplo, considere um limite de bugs de três bugs por engenheiro. Como tal, uma equipa de 10 pessoas não deve ter mais de 30 bugs na sua lista de pendências. Se a equipe estiver acima do limite, espera-se que pare de trabalhar em novos recursos e fique abaixo do limite de bugs. Espera-se que uma equipa esteja sempre abaixo do seu limite, mas a equipa decide como quer fazer isso. O limite de bugs garante que as equipes não carreguem dívidas de bugs por muito tempo. A equipe pode aprender com os erros que fazem com que os bugs sejam injetados em primeiro lugar.

Lembre-se de que a tampa de bug representa os bugs na lista de pendências de bugs. Ele não inclui bugs encontrados e corrigidos dentro do sprint em que um recurso é desenvolvido. Esses bugs são considerados trabalho não feito, não dívida.

Embora os bugs contribuam para a dívida técnica, eles podem não representar toda a dívida.

Um design de software deficiente, código mal escrito ou correções de curto prazo podem contribuir para a dívida técnica. A dívida técnica reflete um trabalho de desenvolvimento adicional que resulta de todos estes problemas.

Acompanhe o trabalho para lidar com dívidas técnicas como PBIs, histórias de usuários ou bugs. Para acompanhar o progresso de uma equipe em incorrer e lidar com dívidas técnicas, convém considerar como categorizar o item de trabalho e os detalhes que deseja acompanhar. Você pode adicionar tags a qualquer item de trabalho para agrupá-lo em uma categoria de sua escolha.

Papel do Scrum Master

Os Scrum Masters ajudam a construir e manter equipes saudáveis empregando processos Scrum. Eles orientam, treinam, ensinam e auxiliam as equipes Scrum no emprego adequado dos métodos Scrum. Os Scrum Masters também atuam como agentes de mudança para ajudar as equipes a superar impedimentos e conduzir a equipe para aumentos significativos de produtividade.

As principais responsabilidades do Scrum Masters incluem:

  • Suporte à equipe na adoção e acompanhamento de processos Scrum. Por exemplo, você não deve deixar que a reunião diária do Scrum se torne uma discussão aberta que dura 45 minutos.

  • Proteja-se contra o proprietário do produto ou os membros da equipe de adicionar trabalho após o início do sprint.

  • Limpar problemas de bloqueio que impedem a equipe de progredir. Esse trabalho pode exigir que você conclua pequenas tarefas, como aprovar uma ordem de compra para um novo computador de compilação ou resolver um conflito dentro de sua equipe.

  • Ajude a equipa a trabalhar para resolver conflitos e questões que surjam e aprenda com o processo.

  • Faça perguntas que revelem problemas ocultos e confirme que o que as pessoas estão comunicando é bem compreendido por toda a equipe.

  • Identifique e proteja a equipe de possíveis problemas que se tornem problemas importantes. Assim como é mais barato corrigir um bug logo após sua descoberta, também é mais fácil e menos perturbador corrigir um problema de equipe quando ele é pequeno e gerenciável.

  • Impeça que a equipe apresente histórias de usuários incompletas durante uma reunião de revisão de sprint.

  • Reúna, analise e apresente dados às partes interessadas do negócio para demonstrar como a equipe está melhorando e crescendo. Por exemplo, se sua equipe aumentou a quantidade de valor que entregou, gerando menos bugs, torne o valor visível por meio de comunicações regulares com as partes interessadas do negócio.

Bons Scrum Masters têm ou desenvolvem excelentes habilidades de comunicação, negociação e resolução de conflitos. Eles ouvem ativamente as palavras que as pessoas dizem e escrevem. Também ouvem a forma como transmitem as suas mensagens, por exemplo, a linguagem corporal, as expressões faciais, o ritmo vocal e outras formas de comunicação não verbal.

Assim como é mais barato corrigir um bug logo após sua descoberta, também é mais fácil e menos perturbador corrigir um problema da equipe quando ele é pequeno e gerenciável antes que ele se transforme em um grande problema.

Reuniões diárias do Scrum

As reuniões diárias do Scrum ajudam a manter a equipe focada no que precisa fazer no dia seguinte. Manter o foco ajuda a equipe a maximizar sua capacidade de cumprir os compromissos de sprint. Seu Scrum Master deve impor a estrutura da reunião e garantir que ela comece a tempo e termine em 15 minutos ou menos.

Três aspetos de reuniões Scrum bem-sucedidas são:

  • Todos se levantam. Levantar-se ajuda a manter as reuniões focadas e curtas.
  • Começam e terminam a tempo e ocorrem à mesma hora no mesmo local todos os dias
  • Todos participam, cada membro da equipe responde às três perguntas do Scrum:
    • O que realizei desde o Scrum mais recente?
    • O que posso realizar antes do próximo Scrum?
    • Que problemas ou impedimentos de bloqueio podem afetar o meu trabalho?

Nota

O foco para reuniões scrum é o status do trabalho que precisa ser passado de um membro da equipe para outro membro da equipe.

Os membros da equipa devem esforçar-se por responder às suas perguntas de forma rápida e concisa. Por exemplo:

"Ontem, atualizei a classe para refletir o novo elemento de dados que extraímos do banco de dados e consegui que ele aparecesse na interface. Esta tarefa está concluída. Hoje, garanto que o novo elemento de dados está calculando corretamente com o procedimento armazenado e os outros elementos de dados na tabela. Acredito que posso realizar esta tarefa hoje. Preciso de alguém para rever os meus cálculos. Não tenho impedimentos ou problemas de bloqueio."

Essa resposta transmite o que o membro da equipe realizou, o que o membro da equipe planeja realizar e que o membro da equipe gostaria de alguma ajuda para examinar o código.

Contraste com este próximo exemplo:

"Ontem, trabalhei na aula e funciona. Hoje, trabalho na interface. Sem problemas de bloqueio."

O membro da equipe não fornece detalhes suficientes sobre em que classe eles trabalharam nem sobre os componentes de interface que eles completarão. Na verdade, a palavra realizado nunca apareceu.

É importante que ninguém interrompa durante as denúncias. Cada pessoa deve dispor de tempo suficiente para responder às três perguntas.

Discussões mais aprofundadas e de acompanhamento devem ocorrer após a reunião, à medida que as pessoas retornam às suas mesas ou, se uma quantidade significativa de conversa for necessária, em uma reunião de acompanhamento.

Muitas equipes atrasam as discussões usando o método de "estacionamento virtual". À medida que surgem assuntos que um membro da equipe acha que precisam de mais discussão, eles podem caminhar tranquilamente até um quadro branco ou flipchart e listar o assunto no estacionamento. No final da reunião, a equipe determina como lidará com os itens listados.

Reuniões de revisão do Sprint

Conduza suas reuniões de revisão de sprint no último dia do sprint. Sua equipe demonstra cada item da lista de pendências do produto que foi concluída no sprint. O proprietário do produto, os clientes e as partes interessadas aceitam as histórias de usuários que atendem às suas expectativas e identificam quaisquer novos requisitos. Os clientes geralmente entendem suas necessidades mais completamente depois de ver as demonstrações e podem identificar as mudanças que desejam ver.

Com base nessa reunião, algumas histórias de usuários são aceitas como completas. Histórias de usuários incompletas permanecem na lista de pendências do produto. Novas histórias de usuários são adicionadas à lista de pendências. Ambos os conjuntos de histórias são classificados e estimados ou reestimados na próxima reunião de planejamento de sprint.

Após esta reunião e a reunião retrospetiva, sua equipe planeja o próximo sprint. Como as necessidades de negócios mudam rapidamente, você pode aproveitar essa reunião com o proprietário do produto, clientes e partes interessadas para revisar as prioridades da lista de pendências do produto novamente.

Reuniões retrospetivas Sprint

As retrospetivas, quando bem conduzidas e em intervalos regulares, apoiam a melhoria contínua.

A reunião retrospetiva do sprint normalmente ocorre no último dia do sprint, após a reunião de revisão do sprint. Nesta reunião, sua equipe explora a execução do Scrum e o que pode precisar de ajustes.

Com base em discussões, sua equipe pode alterar um ou mais processos para melhorar sua própria eficácia, produtividade, qualidade e satisfação. Esta reunião e as melhorias resultantes são fundamentais para o princípio ágil da auto-organização.

Nota

Para dar suporte à retrospetiva da sua equipe, considere instalar a extensão Retrospetivas do Marketplace. Esta extensão suporta a coleta de feedback sobre os marcos do seu projeto, a organização e priorização do feedback e a criação e acompanhamento de tarefas acionáveis para ajudar sua equipe a melhorar ao longo do tempo.

Procure abordar estas áreas durante as retrospetivas de sprint da sua equipa:

  • Problemas que afetaram a eficácia, produtividade e qualidade gerais da sua equipa.

  • Elementos que afetaram a satisfação geral da sua equipa e o fluxo do projeto.

  • O que aconteceu para causar itens incompletos da lista de pendências? Que ações a equipe pode tomar para evitar esses problemas no futuro?

    Por exemplo, considere uma equipe que tinha várias tarefas que apenas um indivíduo da equipe poderia fazer. A experiência isolada criou um caminho crítico que ameaçou o sucesso do sprint. O membro individual da equipe colocou horas extras, enquanto outros membros da equipe ficaram frustrados por não poderem fazer mais para ajudar. No futuro, a equipe decidiu praticar a programação eXtreme para ajudar a corrigir esse problema ao longo do tempo.

Como uma equipe, trabalhe para determinar se deve adaptar um ou mais processos para minimizar a ocorrência de problemas durante o sprint.

Sua equipe pode precisar fazer algum trabalho para implementar uma melhoria. Por exemplo, uma equipe que se viu afetada negativamente por muitas compilações fracassadas decidiu implementar a integração contínua. Como eles não queriam interromper o processo, eles levaram algumas horas para configurar uma compilação de teste antes de ativá-la em sua compilação de produção. Para representar esse trabalho, eles criaram um spike e organizaram esse trabalho contra o resto da lista de pendências do produto.