Compartilhar via

Scrum e melhores práticas

  • Artigo

Azure DevOps Services | 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 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 compartilhará informações e responderá a todas as perguntas que sua equipe tiver 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 da lista de pendências do produto. Durante essa parte da reunião, sua equipe aprenderá o que ela deve criar.

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 se manter focada no que é mais importante para cada sprint.

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

Você pode aprender mais com estes recursos:

Definir metas de sprint

As equipes de Scrum usam metas de sprint para concentrar suas atividades de sprint. Elas geralmente definem essa meta durante a reunião de planejamento de sprint. A meta resume o que a equipe deseja realizar até o final do sprint. Ao declarar explicitamente a meta, você cria uma 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 da lista de pendências do produto 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 proprietário do produto vem com a meta de sprint antes de selecionar muitos itens para o próximo sprint. Os itens desse sprint devem se ajustar a essa meta comum.

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

Por exemplo:

  • Este sprint nos concentraremos em uma história de usuário simples. Vamos usá-la para provar que a solução proposta funcionará.
  • Esse sprint gira em torno da implementação dos recursos de segurança que protegerão corretamente a seção de administração do site.
  • Esse 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 facilitará a definição da prioridade das tarefas dentro de um sprint e provavelmente ajudará 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 fazer a si mesmo é 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, devops Ranger do Visual Studio e consultor sênior que trabalha para a Avanade Netherlands.

Dicas para reuniões de triagem bem-sucedidas

Corrigir bugs representa uma compensação com outro trabalho. Use sua reunião de triagem para determinar o quão importante é 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 da equipe e atualize conforme necessário.
  • Use os critérios de triagem para determinar quais bugs corrigir e como definir seu Estado, Prioridade, Gravidade e outros campos.
  • Ajuste seus critérios de triagem com base na posição que você se encontra no 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. 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:

Dicas das trincheiras: gerenciamento de bugs

Gerenciamento de Bugs Agile: não é um Oximoro
por Gregg Boer, Gerente de Programas Principal, Serviços de Nuvem do Visual Studio na Microsoft

Resolver qualquer dívida de bug conhecida a cada sprint

A cada sprint, a equipe examina todos os bugs restantes na lista de pendências de bugs e dedica capacidade para reduzir esse conjunto conhecido de bugs até zero ou quase zero. Seja em 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. Todos os novos bugs descobertos durante o sprint não fazem parte do compromisso inicial e poderão ser abordados no próximo sprint.

Gerenciar a dívida de bugs em uma empresa

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

Por exemplo, considere um limite de bugs de três bugs por engenheiro. Dessa forma, uma equipe de 10 pessoas não deve ter mais de 30 bugs na 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 os bugs encontrados e corrigidos no sprint no qual o 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 Scrum Master

Os Scrum Masters ajudam a criar e manter equipes saudáveis empregando os processos Scrum. Eles orientam, treinam, ensinam e auxiliam as equipes do 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 os impedimentos e impulsioná-las em direção a aumentos significativos de produtividade.

As principais responsabilidades do Scrum Masters incluem:

  • Dar suporte à equipe para adotar e seguir os processos de Scrum. Por exemplo, você não deve deixar que a reunião diária de 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.

  • Limpar os problemas de bloqueio que impedem que a equipe avance. 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 da equipe.

  • Ajude a equipe a trabalhar para resolve conflitos e problemas que surgem e aprender com o processo.

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

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

  • Evite 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 a 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 de negócios.

Scrum Masters bons 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 estão atentos em como entregam suas mensagens, por exemplo, sua linguagem corporal, expressões faciais, ritmo vocal e outras comunicações não verbais.

Assim como é mais barato corrigir um bug logo após sua descoberta, também é mais fácil e menos complicado corrigir um problema de equipe quando ele é pequeno e gerenciável, antes de crescer e se tornar um grande problema.

Reuniões diárias de Scrum

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

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

  • Todos se levantam. Ficar 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 impedimentos ou problemas de bloqueio podem afetar meu trabalho?

Observação

O foco para reuniões de scrum está no status de trabalho que precisa ser passado de um membro da equipe para outro.

Os membros da equipe devem se esforçar para responder as 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 cumprirei esta tarefa hoje. Vou precisar 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 ele planeja realizar e que gostaria de ajuda para examinar o código.

Compare com este próximo exemplo:

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

O membro da equipe não fornece detalhes suficientes sobre em qual classe ele trabalhou nem sobre os componentes de interface que ele vai concluir. Na verdade, não ouvimos a palavra realizado.

É importante que ninguém interrompa durante o relatório. 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 for necessária uma quantidade significativa de conversa, em uma reunião de acompanhamento.

Muitas equipes atrasam as discussões usando o método "estacionamento virtual". À medida que surgem assuntos que um membro da equipe acha que precisa de mais discussões, eles podem caminhar silenciosamente até um quadro de comunicações 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

Conduza suas reuniões de revisão de sprint no último dia do sprint. A equipe demonstra cada item da lista de pendências do produto que ela concluiu 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 novos requisitos, se houverem. Os clientes geralmente entendem suas necessidades de forma mais completa 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 serão aceitas como concluídas. Histórias de usuários incompletas permanecerão na lista de pendências do produto. Novas histórias de usuários serã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 de retrospectiva, sua equipe planejará o próximo sprint. Como as necessidades comerciais mudam rapidamente, você pode aproveitar essa reunião com o proprietário do produto, os clientes e os stakeholders para revisar novamente as prioridades da lista de pendências do produto.

Reuniões de retrospectiva do sprint

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

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

Com base nas discussões, a equipe pode alterar um ou mais processos para melhorar sua eficácia, produtividade, qualidade e satisfação. Essa reunião e as melhorias resultantes são essenciais para o princípio Agile de auto-organização.

Observação

Para dar suporte à retrospectiva da sua equipe, considere instalar a extensão Retrospectivas do Marketplace. Essa extensão dá suporte à coleta de comentários sobre os marcos do projeto, à organização e à priorização dos comentários e à criação e ao acompanhamento de tarefas acionáveis para ajudar sua equipe a melhorar ao longo do tempo.

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 do projeto.

  • O que aconteceu para existirem itens da lista de pendências do produto incompletos? Quais ações a equipe executará para evitar esses problemas no futuro?

    Por exemplo, considere uma equipe que tinha várias tarefas que apenas um indivíduo dessa equipe poderia realizar. A experiência isolada criou um caminho crítico que ameaçava o sucesso do sprint. O membro individual da equipe fez horas extras, enquanto outros membros da equipe ficaram frustrados por não poderem fazer mais nada para ajudá-lo. Daqui para frente, a equipe decidiu praticar a eXtreme Programming para ajudar a corrigir esse problema ao longo do tempo.

Em equipe, trabalhe para determinar se deseja adaptar um ou mais processos 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 muitas compilações 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.