Scrum e práticas recomendadas

Azure DevOps Services | Servidor Azure DevOps | Azure DevOps Server 2022 | Azure DevOps Server 2020

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 para enfrentar no próximo sprint. É útil delimitar o tempo da 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 de interface do usuário. Ou pode revelar expectativas de tempo de resposta e considerações sobre segurança e usabilidade. Sua equipe deve capturar esses detalhes no formulário de itens de lista de pendências. Durante essa parte da reunião, sua equipe aprenderá o que deve construir.

Ao planejar seus sprints, você pode descobrir outros requisitos para capturar e adicionar à sua lista de pendências. Verifique se ele 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 se manter focada no que é mais importante para cada sprint.

Depois de planejar seu sprint, talvez você queira compartilhar o plano com os principais interessados.

Você pode saber mais com esses recursos:

• O que é Scrum?
• White paper de planejamento da Sprint
• O Guia do Scrum
• White paper Compilar e gerenciar a lista de pendências do produto

Definir metas de sprint

As equipes de Scrum usam metas de sprint para concentrar suas atividades de sprint. Eles geralmente definem essa meta durante a reunião de planejamento de sprint. O objetivo resume o que a equipe quer realizar até o final do sprint. Ao declarar explicitamente a meta, você cria a compreensão compartilhada dentro da equipe da finalidade principal. A meta de sprint também pode ajudar a orientar a equipe quando surgem conflitos em torno de prioridades.

Dicas das trincheiras: Definir metas de sprint

A meta de sprint define o que o proprietário do produto e a equipe consideram como o destino final para realizar esse sprint. Não é uma seleção aleatória de itens de lista de pendências que realmente não têm uma relação, mas uma pequena parte do texto que captura o que a equipe deve tentar realizar. Normalmente, o dono do produto define a meta de sprint antes de selecionar muitos itens para o próximo sprint. Os itens para esse sprint devem se ajustar a essa meta comum.

As metas de sprint podem ser orientadas para funcionalidades, mas também podem ter um grande componente de processo, como automação de implantação ou automação de testes.

Por exemplo:

• Este sprint nos concentraremos em uma história de usuário simples. Vamos usá-la para provar que a solução proposta funciona.
• Esse sprint gira em torno da implementação dos recursos de segurança que protegem corretamente 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 se manter focada. Isso facilita a definição da prioridade de tarefas dentro de um sprint e provavelmente ajuda a limitar o número de stakeholders e usuários finais envolvidos.

Durante a revisão de sprint, a pergunta mais importante que você deve se fazer é se você conseguiu alcançar a meta de sprint. Quantas histórias você completou vem em segundo lugar. Se o objetivo for alcançado, o sprint terá sucesso, 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 (Países Baixos).

Dicas para reuniões de triagem bem-sucedidas

Corrigir bugs representa uma compensação em relação a outras tarefas. Use sua reunião de triagem para determinar a importância de corrigir cada bug em relação a outras prioridades relacionadas ao cumprimento do escopo, orçamento e agendamento 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 de projeto devem receber a maior prioridade e gravidade. Armazene seus critérios de triagem com outros documentos de equipe e atualize conforme necessário.
• Use os critérios de triagem para determinar quais bugs corrigir e como definir seus campos Estado, Prioridade, Gravidade e outros.
• Ajuste seus critérios de triagem com base em onde você está em seu ciclo de desenvolvimento. No início, você pode decidir corrigir a maioria dos bugs após a triagem. No entanto, posteriormente no ciclo, você pode elevar os critérios de triagem para reduzir o número de bugs que você precisa corrigir.
• Depois de fazer a triagem de um bug, atribua-o a um desenvolvedor. Em seguida, o desenvolvedor pode investigar e determinar como implementar uma correção.

Gerenciar sua dívida técnica

Considere gerenciar a barra de bugs e a dívida técnica como parte do conjunto geral de atividades de melhoria contínua da sua equipe. Você pode encontrar esses recursos de interesse:

• Dívida técnica boa e ruim (e como o TDD ajuda) por Henrik Kniberg
• Gerenciar a dívida técnica, postado por Sven Johann & Eberhard Wolff

Dicas das trincheiras: gerenciamento de bugs

Gerenciamento agile de bugs: não é um oximoro
por Gregg Boer, Gerente de Programas Principal, Visual Studio Cloud Services na Microsoft

Resolver qualquer dívida de bug conhecida a cada sprint

A cada sprint, a equipe analisa os bugs restantes na lista de pendências de bugs e aloca recursos para reduzir esse conjunto conhecido de bugs a zero, ou próximo disso. Seja um dia, uma semana ou todo o sprint, eles corrigem os bugs primeiro. Os 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 equipes trabalham em uma organização baseada em compromisso. Muitas vezes, o gerenciamento coloca um valor alto na capacidade de uma equipe de cumprir seus compromissos. Fazer o planejamento de capacidade em relação a 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 na próxima corrida.

Gerenciar a dívida de bugs em uma empresa

Uma organização em transição para uma cultura onde a dívida é continuamente eliminada provavelmente está lidando com a seguinte pergunta: Como você faz 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á à equipe autonomia para determinar como elas mudam. Uma opção é usar um limite de bug.

Por exemplo, considere um limite de três bugs para cada engenheiro. Dessa forma, uma equipe de 10 pessoas não deve ter mais de 30 bugs em sua lista de pendências de bugs. Se a equipe estiver acima do limite, espera-se que ela interrompa o trabalho em novos recursos e se concentre em reduzir os bugs até o limite. Espera-se que uma equipe esteja sempre abaixo do limite, mas a equipe 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 o limite de bugs representa os bugs na lista de pendências do bug. Ele não inclui bugs encontrados e corrigidos dentro do sprint no qual um recurso é desenvolvido. Esses bugs são considerados trabalhos desfeitos, não dívidas.

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

Design de software ruim, 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 extra que surge de todos esses 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 a dívida técnica, leve em consideração como categorizar o item de trabalho e os detalhes que deseja acompanhar. Você pode adicionar marcas a qualquer item de trabalho para agrupá-lo em uma categoria de sua escolha.

Função do Mestre do Scrum

O Scrum Masters ajuda a criar e manter equipes saudáveis empregando processos do Scrum. Eles orientam, treinam, ensinam e auxiliam as equipes scrum no emprego adequado dos métodos Scrum. O Scrum Masters também atua como agentes de mudança para ajudar as equipes a superar os impedimentos e levar a equipe a aumentos significativos de produtividade.

As principais responsabilidades do Scrum Masters incluem:

• Dê suporte à equipe para adotar e seguir os processos do Scrum. Por exemplo, você não deve deixar que a reunião diária do Scrum se torne uma discussão aberta que dure 45 minutos.

• Proteger contra a adição de trabalho pelo proprietário do produto ou por membros da equipe após o início do sprint.

• Limpe os problemas de bloqueio que impedem a equipe de avançar. Esse trabalho pode exigir que você conclua pequenas tarefas, como aprovar uma ordem de compra para um novo computador de build ou resolver um conflito em sua equipe.

• Ajude a equipe a trabalhar para resolver conflitos e problemas que surgem e aprendem com o processo.

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

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

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

• Reúna, analise e apresente dados aos stakeholders de negócios para demonstrar como a equipe está melhorando e crescendo. Por exemplo, se sua equipe aumentou a quantidade de valor que entregou ao gerar menos bugs, torne o valor visível por meio de comunicações regulares com os stakeholders empresariais.

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. Eles também ouvem como entregam suas mensagens, por exemplo, sua linguagem corporal, expressões faciais, ritmo vocal e outra comunicação não verbal.

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

Reuniões diárias do Scrum

As reuniões diárias do Scrum ajudam a manter uma equipe focada no que ela precisa fazer no dia seguinte. Manter-se focado ajuda a equipe a maximizar sua capacidade de cumprir compromissos de sprint. O Mestre do Scrum deve impor a estrutura da reunião e garantir que ela comece na hora e seja concluída em 15 minutos ou menos.

Três aspectos das reuniões bem-sucedidas do Scrum são:

• Todos se levantam. A posição em pé ajuda a manter as reuniões focadas e curtas.
• Eles começam e terminam na hora e ocorrem ao mesmo tempo no mesmo local todos os dias
• Todos participam, cada membro da equipe responde às três perguntas do Scrum:
  • O que eu realizei desde o Scrum mais recente?
  • O que posso fazer antes do próximo Scrum?
  • Quais problemas ou impedimentos de bloqueio podem afetar meu trabalho?

Os membros da equipe devem se esforçar para responder 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 ela aparecesse na interface. Esta tarefa está concluída. Hoje, garantirei que o novo elemento de dados faça os cálculos corretamente com o procedimento armazenado e os outros elementos de dados na tabela. Acredito que posso realizar essa tarefa hoje. Preciso de alguém para revisar meus cálculos. Não tenho impedimentos nem 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 examinando o código.

Contraste com este próximo exemplo:

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

O membro da equipe não fornece detalhes suficientes sobre em qual classe eles trabalharam nem sobre os componentes de interface que serão concluídos. Na verdade, não ouvimos a palavra realizado.

É importante que ninguém interrompa durante as apresentações de relatórios. Cada pessoa deve ter tempo suficiente para responder às três perguntas.

Discussões mais detalhadas 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 da "lista de espera virtual". À medida que surgem assuntos que um membro da equipe acha que precisa de mais discussão, eles podem caminhar silenciosamente até um quadro branco ou flipchart e listar o assunto no estacionamento. No final da reunião, a equipe determina como eles lidarão com os itens listados.

Reuniões de revisão de sprint

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

Com base nesta reunião, algumas histórias de usuários são aceitas como concluídas. As histórias de usuário incompletas permanecem na lista de pendências do produto. Novas histórias de usuário são adicionadas à lista de pendências. Ambos os conjuntos de histórias serão classificados e estimados ou reavaliados na próxima reunião de planejamento de sprint.

Após essa reunião e a reunião retrospectiva, sua equipe planeja o próximo sprint. Como os negócios precisam mudar rapidamente, você pode aproveitar essa reunião com o proprietário do produto, os clientes e os stakeholders para revisar as prioridades da lista de pendências do produto novamente.

Reuniões retrospectivas do Sprint

As retrospectivas, quando bem conduzidas e em intervalos regulares, dão suporte à melhoria contínua.

A retrospectiva 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 mudar um ou mais processos para melhorar sua própria eficácia, produtividade, qualidade e satisfação. Essa reunião e as melhorias resultantes são fundamentais para o princípio ágil da auto-organização.

Procure abordar essas áreas durante as retrospectivas de sprint da equipe:

• Problemas que afetaram a eficácia geral, a produtividade e a qualidade da sua equipe.

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

• O que aconteceu que levou a itens de pendência incompletos? Quais ações a equipe pode executar para evitar esses problemas no futuro?

  Por exemplo, considere uma equipe que tinha várias tarefas que apenas um indivíduo na equipe poderia fazer. A expertise isolada criou um caminho crítico que ameaçava o sucesso do sprint. O membro individual da equipe colocou horas extras enquanto outros membros da equipe estavam frustrados por não poderem fazer mais para ajudar. Daqui para frente, 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 um ou mais processos devem ser adaptados para minimizar a ocorrência de problemas durante o sprint.

Talvez sua equipe precise fazer algum trabalho para implementar uma melhoria. Por exemplo, uma equipe que se viu afetada negativamente por muitos builds com falha decidiu implementar a integração contínua. Como ela não queria interromper o processo, ela levou algumas horas para configurar uma compilação de avaliação antes de ativá-la em sua compilação de produção. Para representar esse trabalho, ela criou um pico e organizou esse trabalho em relação ao restante da lista de pendências do produto.

Conteúdo relacionado

• Atividades de fim do sprint
• O que é Scrum?
• Retrospectivas ágeis: Transformando boas equipes em ótimas