Sprint Review: Como obter muito mais da sua revisão da sprint

A Sprint Review é uma das cerimônias Ágeis mais importantes com certeza. Normalmente, é uma reunião ao vivo perto ou no final de uma sprint ou em todos as outras sprints.

Desenvolvedores, membros da equipe de produto e partes interessadas se reúnem para ver o que foi construído desde a última revisão. Seguindo o objetivo ágil de software funcionando, a equipe deve ser capaz de mostrar novos recursos e funcionalidades.

Esta parte da revisão pode ser chamada também de Sprint Demo.

🎯 Objetivo de uma Sprint Review

Curiosamente, o objetivo fundamental e o resultado da Sprint Review são frequentemente omitidos ou ignorados, ou desconhecidos pelas equipes. O objetivo da Sprint Review é coletar feedback sobre o Incremento do Produto das partes interessadas, considerar as condições atuais de negócios (como o uso do produto, concorrentes, vendas, marketing etc.) e planejar o que fazer a seguir.

As partes interessadas, tanto internas quanto, em alguns casos, externas, devem ser convidadas para a Sprint Review.

Em algumas empresas, clientes e usuários são convidados para as Sprint Reviews – se possível, dependendo de contratos e outros fatores.

Ainda observo em algumas organizações que os Times Scrum mostram apenas uma demonstração e código para si mesmos.

Não há interessados ​​convidados. Em vez disso, os desenvolvedores mostram o código e os testes para o Product Owner.

Nesse caso, não há inspeção e adaptação verdadeiras. O Product Owner não deve se surpreender com o Incremento.

Ao contrário, todo o Time Scrum deve buscar feedback dos outros.

🔍 Demonstrar não é tudo

Mas a demonstração é apenas uma parte da revisão da sprint. Além disso, a equipe deve revisar os objetivos do produto e como o trabalho concluído se alinha com os objetivos gerais do projeto.

A equipe deve determinar se o trabalho feito na sprint anterior ajudou a atingir as metas ou ficou aquém – talvez a equipe tenha trabalhado em algo ótimo, mas não progrediu em direção à meta.

Este é o momento em que a equipe pode corrigir o curso; talvez, ele escolha histórias diferentes para a próximo sprint, ou mude o foco, ou, se necessário, procure alterar os recursos da equipe para que diferentes histórias possam ser realizadas em sprints futuras ou para impactar a velocidade da equipe.

A revisão da sprint também ajuda as partes interessadas a entender melhor o status do produto e permite que elas usem e vejam o produto, talvez pela primeira vez.

Isso pode levar a discussões produtivas sobre o produto, incluindo se ele está pronto para os clientes, o que ainda precisa ser construído, o plano de lançamento e a composição de sprints futuros.

Até este ponto, esta reunião poderia ser realizada com um número limitado de pessoas – nem todo desenvolvedor precisa apresentar e nem todo stakeholder precisa revisar.

No entanto, a revisão da sprint ganha valor quando mais pessoas participam – e participam. Isso porque, além de demonstrações e revisões de metas, essa é uma atividade onde são feitas conversas e conexões importantes.

Vejamos alguns desses outros benefícios potenciais da revisão da sprint.

🗣️ Feedback para a equipe de desenvolvimento

No gerenciamento de projetos tradicional, a equipe do produto é responsável por escrever as especificações, entregá-las aos desenvolvedores e esperar que a equipe construa o que foi solicitado.

Durante o intervalo, os desenvolvedores geralmente não colaboram muito com a equipe do produto, esperando até que estejam “concluídos” para reunir todos novamente.

Este processo sempre causou frustração. Mesmo a melhor equipe terá dificuldade para entregar exatamente a coisa certa para o produto. Isso pode ser porque as necessidades mudaram, ou novas informações do cliente foram aprendidas, ou pode ser que os detalhes estivessem faltando na especificação original, e a equipe construiu o que achava certo (às vezes conhecido como critério do desenvolvedor) e acabou errado.

O Agile contorna isso com o ciclo do-inspecionar-adaptar que é incorporado ao processo.

Em vez de esperar até que tudo esteja completo, o Agile coloca pontos de verificação ao longo do caminho, onde o que foi “feito” pode ser “inspecionado” e quaisquer mudanças de direção ou alterações no produto podem ser discutidas com a equipe e outras partes interessadas, se necessário.

Ao adicionar esse ciclo de feedback ao processo, a equipe está constantemente ajustando o que está trabalhando e o que está priorizando e mudando de direção antes que seja tarde demais.

Fazer com que as partes interessadas forneçam feedback à equipe de desenvolvimento durante a revisão da sprint é uma ótima maneira de criar um produto melhor e manter o projeto na direção certa.

📢 Feedback da equipe de desenvolvimento

O feedback é melhor quando é multidirecional. Não deve ser limitado apenas aos stakeholders dando seus comentários aos desenvolvedores, bons e ruins, e a partir disso desenvolvedores e fazem mudanças.

Este também deve ser um momento para a equipe de desenvolvimento dar feedback às partes interessadas do projeto, incluindo a equipe do produto, a equipe de design ou qualquer outra pessoa que trabalhe com os desenvolvedores.

Pode ser que os requisitos não tenham ficado claros recentemente e a equipe os queira em um formato diferente.

Ou talvez haja uma maneira melhor de fazer o que a equipe de produto solicitou, e a equipe de desenvolvimento quer falar sobre como fazer as coisas de maneira diferente.

Portanto, além de dar feedback aos desenvolvedores, os desenvolvedores devem ter o poder de dar feedback ao produto.

Mais do que apenas dar comentários sobre como o projeto está operando, os desenvolvedores também devem usar parte desse tempo para entender melhor o produto e como seu trabalho está impactando o quadro geral.

Quando a equipe entende o raciocínio por trás do trabalho, eles tendem a ser mais bem-sucedidos em construí-lo.

A equipe também deve se sentir à vontade para dar feedback sobre o produto em si. Isso pode ser novas ideias para recursos, alterações em outros adicionais ou maneiras de atender a um novo cliente ou um novo caso de uso.

Se a equipe de desenvolvimento estiver trabalhando em estreita colaboração com o produto, provavelmente terá insights e pontos de vista que outras partes interessadas não têm.

Extrair isso da equipe durante a revisão da sprint pode ser uma ótima maneira de discutir novas ideias e ajudar a colaborar em um produto melhor.

🤝 Construção de relacionamento

A revisão da sprint geralmente é um evento positivo. Novas partes do produto podem ser reveladas pela primeira vez, metas foram adiantadas ou até mesmo concluídas, e pode haver conquistas a serem anunciadas e comemoradas.

Pela natureza alegre do evento, também é um bom momento para a construção de relacionamento com os stakeholders.

Embora alguns membros do desenvolvimento possam trabalhar em estreita colaboração com algumas partes interessadas, é raro que toda a equipe trabalhe em conjunto.

Fazer com que a equipe colabore durante a revisão da sprint é uma maneira natural de todas as partes interessadas colaborarem e trabalharem juntas de maneiras que podem não ter a chance de outra maneira.

O Agile valoriza muito os relacionamentos. No manifesto original, dois dos itens valorizam as pessoas sobre o processo e a colaboração do cliente.

Usar a revisão da sprint para ter toda a equipe, stakeholders e clientes, cria o ambiente para relacionamentos melhores e fortes entre todos.

Em geral, quanto melhores forem os relacionamentos entre a equipe de desenvolvimento e as partes interessadas, melhores serão os resultados.

Os desenvolvedores terão uma melhor compreensão das necessidades dos clientes, e a equipe de produto terá uma melhor avaliação de como trabalhar melhor com a equipe.

Todos são responsáveis ​​por construir valor, e quanto mais as pessoas colaborarem e apreciarem umas às outras, melhores serão os resultados.

🎁 O take-away

A reunião de revisão da sprint é uma parte importante do processo Agile. Uma parte da revisão inclui uma demonstração do trabalho concluído recentemente, permitindo que as partes interessadas vejam o software em funcionamento pela primeira vez.

O restante da revisão se concentra nas metas, como o produto está indo, como o trabalho está ajudando a atingir as metas e algumas discussões sobre lançamentos futuros.

Além disso, a revisão da sprint tem três funções mais importantes:

  • Fornecer feedback para a equipe de desenvolvimento das partes interessadas;
  • Fornecer feedback para as partes interessadas da equipe de desenvolvimento;
  • Ajudar a construir e fortalecer o relacionamento entre todos os membros da equipe.

Pode ser tentador focar na parte de demonstração da revisão da sprint, mas isso é apenas metade da história. Ao ter uma visão mais ampla do produto, mais partes interessadas podem se envolver e participar, o que levará a uma equipe mais forte e a um produto melhor.

👥 Como envolver as partes interessadas em suas revisões de Sprint

Essa ausência de stakeholders pode ser consequência do progresso do produto, pois uma colaboração transparente entre a equipe e os stakeholders é fundamental para a construção de um produto de sucesso.

Como você pode evitar avaliações de Sprint ruins? Como coletamos feedback das partes interessadas? Como tornamos este evento Scrum valioso e significativo?

Aqui estão cinco razões pelas quais seus stakeholders não estão participando de revisões de sprint com soluções.

1. Você pode ter agendado a Revisão da Sprint na hora errada🕛

MOTIVO: O agendamento apático é uma das principais razões para a ausência de stakeholders nas revisões de sprint. As partes interessadas podem ter outros compromissos essenciais no dia da revisão da sprint.

Portanto, mesmo que estejam fisicamente disponíveis em sua agenda, sua mente pode estar absorta em outro trabalho importante.

RECURSO: Comunicação eficaz entre a equipe e as partes interessadas durante o agendamento.

Se possível, o cronograma da revisão do sprint deve ser definido no meio da semana em vez do último dia da semana. Na minha experiência, as Sprint Reviews de sexta-feira tiveram quase 50% das partes interessadas não aparecendo.

  • Pense nos resultados e no propósito do evento.
  • Tenha um cenário! Achei muito útil criar uma estratégia curta com o que deve ser discutido e quais perguntas vamos fazer aos nossos stakeholders.
  • Deixe algum espaço para perguntas, preocupações e novas ideias das partes interessadas.
  • Esteja preparado para uma discussão, não apenas uma apresentação.
  • Esteja preparado com algumas técnicas de facilitação relevantes para este evento. (tenha cuidado, nem todos os métodos de facilitação são apropriados para a Revisão da Sprint).
  • Pense no número de pessoas. Quantas equipes estarão presentes? Quantos interessados ​​virão? Escolha as técnicas que são relevantes para sua situação.

2. Sua Sprint Review é apenas uma demonstração🔎

MOTIVO: Outro motivo pelo qual um stakeholder pode pular a revisão do sprint pode ser por que você não consegue captar o interesse dele. A equipe às vezes exagera e converte a Sprint Review como uma demonstração.

Portanto, quando é apresentado apenas como uma demonstração e todos os outros interessados ​​estão apenas ouvindo, muitas vezes é sequestrado por uma discussão profunda unilateral que pode não interessar a todos os interessados.

RECURSO: O ônus está no Scrum Master para facilitar um fluxo suave de comunicação que mantém todas as partes interessadas envolvidas. A revisão pode ser mais imersiva onde as partes interessadas são solicitadas a se envolver melhor.

Pela minha experiência, costumo fazer uma pausa suave, cutucar todas as partes interessadas e convidá-las a abrir seus pensamentos. Algo muito interessante que pode ser feito é criar um acordo de trabalho.

  • Acordo de trabalho – Uma prática poderosa que pode ajudá-lo a facilitar a Revisão da Sprint e outros eventos. Achei valioso reunir as partes interessadas e as equipes. Nós criamos nossos Acordos de Trabalho (para este evento e futuras revisões também). O resultado pode
    incluir as seguintes regras:
  1. As partes interessadas fornecem feedback;
  2. Todos podemos fazer perguntas;
  3. Discussão e evidências em vez de brigas improdutivas;
  4. Respeitar os time-boxes;
  5. Compartilhar perspectivas de negócios;
  6. Compartilhar perspectivas de tecnologia e viabilidade;
  7. Pelo menos um representante do departamento X está presente nas Sprint Reviews.

Estes são apenas meus exemplos. Vocês podem criar juntos regras completamente diferentes que sejam relevantes para suas equipes, partes interessadas e situações.

3. Sua Sprint Review não está emocionante 🥲

Quantas vezes você já pensou: “Esta Sprint Review é inútil e chata!” ou “Estamos apenas revisando internamente o que já vimos antes como Time Scrum. Não temos feedback novo. Vamos pular este evento. Perda de tempo.”

MOTIVO: Às vezes, as partes interessadas não consideram a revisão do sprint necessária. Eles provavelmente não comparecerão, pois podem conhecer a discussão e as decisões tomadas durante o evento.

RECURSO: Antes do evento, as equipes Scrum devem encontrar maneiras de atrair ou puxar os interesses de seus stakeholders. É melhor estacionar o que provavelmente virá no próximo Sprint e incluir uma palavra na agenda da sua Revisão da Sprint.

Na minha experiência, isso também significaria uma participação mais ativa das partes interessadas, pois elas estarão ansiosas para ouvir o que está por vir.

  • Utilize Gravação de um vídeo – além de anotar o que foi dito, considere a gravação de um vídeo, como facilitador, você não precisa ser essa pessoa que desenha ou escreve.
    Certifique-se apenas  de que alguma gravação foi feita. A gravação de um vídeo usando a funcionalidade cria uma excelente oportunidade de visualização diferente das notas. E pode abrir nossos cérebros para mais ideias e criatividade.
  • Lean Coffee1 – esta técnica pode estruturar sua discussão quando um grupo tem muitos comentários, ideias e perguntas.

4. Fluxo 🔃

MOTIVO: O fluxo da revisão também pode desinteressar a parte interessada. Discussões dispersas durante a revisão podem tornar a reunião tediosa. Às vezes, o ritmo inconsistente e as transições difíceis também podem dissuadir as partes interessadas.

RECURSO: O Scrum Master deve intervir e ajudar a equipe scrum a definir e manter um ritmo rápido do evento. Isso pode ser feito com um planejamento meticuloso antes da reunião, incentivando uma conversa tranquila e sem esforço entre a equipe e as partes interessadas.

  • Perguntas abertas – comece com perguntas: o que, quando, por que, por que motivo, como. As perguntas fechadas são usadas apenas se você quiser confirmar algo ou terminar a atividade.
  • 15% Solutions2 – esta prática pode restringir muitos pontos de ação (também pode ser ótimo para
    outros eventos).

5. Feedback📣

MOTIVO: O objetivo principal da revisão da sprint é receber feedback das partes interessadas, mas muitas vezes, a parte interessada pode não ter a oportunidade de contribuir para a conversa, pois a equipe ingenuamente fica obcecada com sua apresentação.

RECURSO: A equipe pode planejar uma pausa para conversa após cada demonstração para que a parte interessada possa acompanhar o ritmo e os desenvolvimentos dos backlogs do produto.

Na minha experiência, após cada demonstração de recurso, há uma pequena pesquisa que acontece instantaneamente. Dessa forma, você pode realmente transformar uma demonstração em uma sessão de feedback colaborativo.

🗣️ Como Facilitar o Feedback

Crie um ambiente seguro que permita transparência. Estou ciente de que em algumas organizações, dependendo da cultura, inicialmente, alguns stakeholders chegam a Sprint Review com expectativas, energia e atitude diferentes. Achei útil configurar a cena antecipadamente nas primeiras Sprint Reviews. Pode incluir o objetivo do evento, a necessidade de perguntas e coleta de feedback, inspeção do mercado, oportunidades de negócios e tecnologia, etc.

Pense no que seria apropriado em seu contexto. Esta é uma sessão colaborativa. Certifique-se de que todos possam participar – ou fazer perguntas ou fornecer feedback.

Veja algumas dicas de técnicas abaixo:

  • Incentive as pessoas a falar.
  • Facilitar a visualização do feedback ajuda as pessoas a ver o que foi dito antes e cria um espaço para ideias criativas. Além disso, garante que todo o feedback seja coletado. Lembre-se, como facilitador, você pode pedir a alguém para ajudá-lo. Ser um facilitador não significa que todo o trabalho do escriba pertence a você.
  • Observe a dinâmica. Se o engajamento diminuir, reaja e aja de acordo. Às vezes, tornar as coisas transparentes ajuda (O que aconteceu? Por que isso aconteceu?).
  • Quando relevante, faça perguntas abertas (O que você acha? Por qual motivo você propõe isso? Que evidências você tem? O que os clientes dizem? Como eles usam o produto? O que poderia mudar o status quo? Qual é o resultado dos experimentos? Qual é o progresso em direção ao Objetivo do Produto?).
  • Foco no valor. Não se esqueça do mais importante para a Sprint Review: discutir  valor e clientes.

Conclusão

Uma vez que percebemos o propósito da Sprint Review, fica mais fácil facilitar este evento. Nesta postagem do blog, forneci algumas dicas de facilitação e respostas com base na minha experiência e conhecimento.

Agora, depois de conhecer algumas dicas, é hora de colocá-las em prática! Tente repensar seu estilo atual e dê uma olhada nestes conselhos. Espero que você encontre algo que nunca praticou até agora e que incorpore em suas revisões da Sprint. Boa sorte!

Definição de Pronto e Definição de feito (DoR e DoD)

PARTE 1: Definição de DoR e DoD

Os conceitos de Definição de Pronto (DoR) e Definição de feito (DoD) são termos usados para reforçar a Transparência, garantir a Qualidade Integrada e definir as expectativas corretas para os itens de trabalho a serem planejados, desenvolvidos e concluídos durante o desenvolvimento de um produto Ágil.

Porque?

Primeiramente a escrita de DoR e DoD são ferramentas de comunicação entre as partes, por exemplo, Dono do Produto e Equipe de Desenvolvimento para definir expectativas claras – Transparência.

Visto que é um padrão formalmente acordado e um entendimento comum reduzirão retrabalhos e defeitos, cuidando da qualidade durante a construção do produto, e não por meio da inspeção do produto – Qualidade Integrada.

Inclusive  DoR e o DoD definem um padrão de qualidade para todos os participantes envolvidos, portanto, é crucial que as próprias equipes criem seus DoR e DoD, os possuam e os sigam. Na criação dessas definições, duas coisas são cruciais: consultar os princípios do Agile (SAFe) e garantir o acordo total da equipe.

Como?

O DoR e o DoD devem ser vistos como critérios de entrada e saída, com o DoR servindo como uma pré-condição para verificar se um item está pronto para ser levado para a etapa atual e testar o DoD se um item está pronto para ser movido para a próxima etapa.

DoR e DoD podem ser aplicados em qualquer nível (por exemplo, equipe, programa, grande solução, portfólio, empresa, etc.) e a diferentes itens (por exemplo, histórias de usuário, recursos, capacidades, epopeias, iterações, lançamentos, incrementos de programa e até mesmo um programa piloto Agile completo).

A aplicação mais comum e básica dos conceitos DoR e DoD é vista no nível da equipe à medida que são aplicados às Histórias de Usuário.

Essas definições devem ser visíveis no ambiente de trabalho da equipe e usadas quando os itens são movidos de uma etapa para outra, especialmente quando os itens são levados para execução e quando são movidos para concluídos!

Os itens aos quais essas definições são aplicadas devem ter um resultado binário: Concluído ou Não Concluído. Evite a tentação de “quase pronto”, “meio que feito” ou “99% feito”.

Evolução DoR e DoD

DoR e DoD são acordos vivos que evoluem à medida que os usuários aprendem melhores maneiras de fazer seu trabalho, eles adquirem excelência em seu trabalho, sua prática amadurece, sua pista arquitetônica ou ambiente de desenvolvimento melhoram, eles adquirem melhores ferramentas, o contexto de suas mudanças de trabalho, surgem novos regulamentos ou requisitos de conformidade, etc.

DoR e DoD são um reflexo da realidade atual e não devem impor um padrão que seja irreal.

Com o tempo, o DoR e o DoD melhoram, levando os padrões e a qualidade cada vez mais alto. Em certo sentido, DoR e DoD podem ser usados ​​como um indicador da maturidade das equipes Agile e sua jornada Agile.

As equipes passam de um DoR e DoD de alto nível para um nível mais detalhado, de um nível mais flexível para outro mais rigoroso, e eventualmente alcançando a capacidade de “Produto Potencialmente Remetível” a cada Iteração.

Essa abordagem é um reflexo do princípio do Manifesto Ágil “Atenção contínua à excelência técnica e um bom design aumenta a agilidade”.

DoR e DoD vs Critérios de Aceitação (AC)

Tendo em vista que DoR e DoD são mais genéricos e frequentemente aplicáveis ​​a um amplo conjunto de itens, enquanto os Critérios de Aceitação (AC) são específicos para um item.

Por exemplo, no nível da equipe, DoR e DoD se aplicam a todos os itens do backlog da equipe, como User Stories, enquanto no nível do programa, eles se aplicam a todos os itens do backlog do programa, como Features, e assim por diante.

Já que DoD e AC são conceitos ortogonais e ambos são obrigados a considerar um item Concluído.

Entretanto DoD é uma espécie de superconjunto de AC. Juntos, DoR e DoD garantem a qualidade de um item e o AC garante sua funcionalidade. Por meio do AC, os itens de trabalho ficam mais específicos.

Ou seja a AC valida que o item certo foi construído. O DoD verifica se o item foi construído corretamente, portanto, as equipes podem incluir NFRs (requisitos não funcionais) relevantes em seu DoD como restrições no design local e nas decisões de implementação.

Para esclarecimento a diferença entre os dois é que o DoD é comum para todas as histórias de usuário, enquanto os critérios de aceitação são aplicáveis ​​a histórias de usuário específicas. Os critérios de aceitação de cada história de usuário serão diferentes com base nos requisitos dessa história de usuário.

O DoR e o DoD facilitam as mudanças culturais e promovem uma nova mentalidade, enquanto o AC visa a excelência técnica.

DoR e DoD são a autoridade da equipe, enquanto o AC é a autoridade do cliente ou de seus representantes (Product Owner / Manager).

Autonomia vs Conformidade

Uma empresa pode ter certos requisitos nos níveis de programa ou solução que devem ser incorporados ao DoR e DoD. Por exemplo, o uso de certas ferramentas, uma certa forma de relatório, teste, financiamento, etc.

Embora as equipes tenham autonomia para criar seus próprios DoR e DoD, alguns requisitos podem vir como parte da política ou padrão corporativo que exige a conformação das equipes. Esses últimos requisitos farão parte dos, digamos, critérios fixos para o DoR e o DoD.

Cuidado com o anti-padrão DoR

Por outro lado o DoR pode facilmente cruzar a linha entre Agile e Waterfall quando a equipe não consegue realizar nenhum trabalho ou trabalho suficiente para uma iteração até que algo mais seja concluído. É quando um DoR se transforma em um anti-padrão.

Visto que é normal permitir a entrada de algumas histórias de usuários se eles não estiverem 100% reclamando das regras. Lembre-se de que o princípio iterativo e incremental também se aplica às regras contidas no DoR.

De acordo com Mike Cohn:

“quando um DoR inclui uma regra de que algo deve ser feito antes que a próxima coisa possa começar, ele move a equipe perigosamente perto do processo de passagem de estágio
… E pior, pode ser um grande e perigoso passo para trás em direção a um abordagem em cascata ”.

Entretanto algumas regras no DoR devem ser atendidas, como Critérios de Aceitação e Estimativa para Histórias de Usuário, enquanto algumas das regras podem ser apenas desejadas.
Conforme as equipes amadurecem em sua prática, seu DoR pode se tornar redundante. É apenas no início da jornada ágil que as equipes precisam seguir algumas diretrizes acordadas por escrito.

PARTE 2: Diretrizes para a criação de DoR e DoD

Essas diretrizes são desenvolvidas de forma genérica e podem ser adaptadas a qualquer nível (Equipe, Programa, Grande Solução, Portfólio) ou propósito e atividade, como Liberação, Iteração, Incremento do Programa ou um programa Piloto Ágil completo.

Facilite um workshop com toda a equipe ágil1. Certifique-se de que este seja um exercício de equipe inteira. Dependendo do nível e da finalidade do DoR e do DoD, os participantes podem incluir o proprietário do produto, gerenciamento de produto, gerenciamento de solução, gerenciamento de liberação, arquitetos, equipes de desenvolvimento, equipe de sistema, escritório jurídico, clientes, fornecedores e muito mais. Providencie participantes online, se necessário.

Dependendo do nível e do tamanho da equipe, recomenda-se uma sessão de 2 a 4 horas. Uma sessão (ou sessões) de acompanhamento pode ser organizada, se necessário.

Certifique-se de que a sala tenha um quadro branco, suprimentos como post-its, marcadores e agulhas e espaço suficiente para colaboração e interação. Acomode-se para colaboração online, se necessário.

Criação de DoR para histórias de usuários / features Criação do DoD para histórias de usuários / features
  • Identifique todas as atividades necessárias para preparar uma história de usuário para o planejamento de iteração / um recurso pronto para as equipes de planejamento de PI ou Agile escreverem histórias de usuário.
    • Foco em atividades que agregam valor
    • Essas atividades podem variar amplamente dependendo do produto (software, hardware, mainframe, design ou artefatos conceituais, etc.)
  • Selecione apenas as atividades que ocorrem novamente para quase todas as histórias de usuário / recurso para ficar pronto
  • Registre todas essas atividades recorrentes em uma lista abrangente de critérios potenciais para DoR
  • Priorizar a lista de atividades de cima para baixo
  • Faça uma lista restrita apenas dos critérios que podem ser atendidos de forma realista antes que uma história de usuário seja puxada para o planejamento / recurso de iteração para as equipes de planejamento de PI ou Agile para escrever histórias de usuário
    • A equipe decide o quão completo e perfeito eles querem seu DoR neste ponto
    • Preste atenção em como a estimativa de Recursos deve ser feita antes das Histórias de Usuário associadas
    • Estimativa e depois que as Histórias de Usuário são estimadas
  • Obtenha a concordância e o compromisso da equipe com os critérios selecionados, que agora são o DoR para Histórias de usuários / recursos
  • Identifique todas as atividades necessárias para concluir uma história de usuário / um recurso.
    • Foco em atividades voltadas para a qualidade do produto (Qualidade Integrada).
    • Essas atividades podem variar amplamente dependendo do produto (software, hardware, mainframe, design ou artefatos conceituais, etc.)
    • Atividades de aprovação ou assinatura com partes externas e partes interessadas que estão fora do controle da equipe podem ser omitidas.
  • Selecione apenas as atividades que ocorrem novamente para que quase todas as histórias de usuário / recurso sejam concluídas.
  • Registre todas essas atividades recorrentes em uma lista abrangente de critérios potenciais para DoD
  • Priorizar a lista de atividades de cima para baixo
  • Faça uma lista restrita apenas dos critérios que podem ser atendidos de forma realista antes que uma história / recurso de usuário seja concluída o A equipe decide o quão completo e perfeito eles querem seu DoD neste ponto
    • Preste atenção ao que fazer se um recurso pode ser considerado completo, mas ainda está associado
    • Histórias de usuários abertas
  • Obtenha a concordância e o compromisso da equipe com os critérios selecionados, que agora são o DoD para Histórias de usuários / recursos

Uma vez que o DoR e o DoD são criados, eles devem ser publicados, mantidos visíveis, de preferência na área de trabalho da equipe e nas ferramentas Agile que usam. Imprima-o como um pôster colorido que chama a atenção para enfatizar sua importância.

Repita todo o exercício descrito nas diretrizes acima em uma cadência regular, como fim da Iteração ou PI2 para expandir e refinar ainda mais o DoR e o DoD. Use os critérios restantes da lista abrangente inicialmente criada e quaisquer novos critérios devem ser adicionados.

PARTE 3: Exemplos DoR e DoD

Os exemplos DoR e DoD abaixo contêm critérios gerais para diferentes níveis. Conforme declarado, DoR e DoD são acordos informados pela realidade por todos os participantes, portanto, a tabela deve ser considerada apenas como um exemplo.

Desenvolvimento de Produto
Definition of Ready Definition of Done
Time:

Histórias de usuários

  • Uma história de usuário está pronta se, por exemplo:
    Possui critérios de aceitação que podem ser testados objetivamente
  • Estimado por toda a equipe de desenvolvimento
    Socializado com toda a equipe
  • Tem o tamanho certo que pode ser concluído em uma Sprint, de preferência de 2 a 3 dias ou não maior do que [certos] pontos da história
  • Está em conformidade com o Modelo de INVEST (Independente, Negociável, Valioso, Estimativa, Pequeno, Testável) e não tem dependências externas
  • Carregado / criado na ferramenta / ambiente Agile da equipe
  • Escrito no formato de voz do usuário:
    QUEM <alguém>, O QUE <fazer algo>, POR QUE <algum resultado ou benefício>. Por exemplo.:
    COMO <alguém>, EU QUERO <fazer algo>, ASSIM QUE <algum resultado ou benefício>
Uma história de usuário é concluída se, por exemplo:

  • Atende aos seus critérios de aceitação
  • Testado (por exemplo, para software / hardware)
  • Validado (por exemplo, para documentos de design, modelos)
  • Demonstrado para as partes interessadas
  • Não há mais defeitos que devem ser corrigidos
  • Documentado
  • Aceito pelo Dono do Produto
Programa:

Features

Um recurso está pronto se, por exemplo:

  • Possui critérios de aceitação que podem ser testados objetivamente
  • Tem o tamanho certo que pode ser concluído em um PI
  • Tem histórias de usuário definidas
  • Carregado na ferramenta / ambiente Agile da equipe
  • Estimado (pontos da história, tamanho da camiseta, …)
  • Escrito na Matriz de Recursos e Benefícios:

Feature – Uma frase curta que fornece um nome e contexto;
Hipótese de benefício – O benefício mensurável proposto para o usuário final ou empresa

Um recurso é concluído se, por exemplo:

  • Atende aos seus critérios de aceitação
  • Testado e integrado
  • Demonstrado para as partes interessadas
  • Documentado e treinamento fornecido
  • Não há mais defeitos que devem ser corrigidos
  • Suas histórias de usuário necessárias são concluídas e todas as histórias de usuário restantes são cuidadas, por exemplo, desacopladas do recurso e movidas para o backlog, ou excluídas, ou …
  • Aceito pela Gestão de Produto
Solução em larga escala:

Capacidades

Uma capacidade está pronta se, por exemplo:

  • Tem o tamanho certo que pode ser concluído em um PI, embora por vários ARTs
  • Seus facilitadores associados para o trabalho técnico necessário são identificados
  • Socializado com a Gestão de Produto das ARTs relevantes
  • Descrito usando uma frase e hipótese de benefícios, semelhante a Características:

Capacidade – Uma frase curta que fornece um nome e contexto;
Hipótese de benefício – O benefício mensurável proposto para o usuário final ou empresa

Uma capacidade é realizada se, por exemplo:

  • Seus recursos associados estão concluídos
  • É implantado no ambiente de teste
  • Seus NFRs associados são atendidos
  • Integração de ponta a ponta, testes, validação e verificação são feitos
  • Não há mais defeitos que devem ser corrigidos
  • Demonstrado para as partes interessadas
  • Documentado e treinamento fornecido
  • Aceito pela Gestão da Solução
Lançamento do produto
Uma liberação está pronta se, por exemplo:

  • Todos os recursos / capacidades são concluídos
  • Teste de integração ponta a ponta é feito
  • Teste de regressão é feito
  • A documentação de liberação está completa
  • Não há mais defeitos que devem ser corrigidos
  • O guia do usuário é criado
  • O treinamento do usuário é criado
  • Aprovado por Gerenciamento de Produto / Solução
  • Aprovado pelo Gerenciamento de Liberação
Uma liberação é realizada se, por exemplo:

  • Testes de integração ponta a ponta e V&V são realizados
  • Teste de regressão é feito
  • O teste de desempenho é feito
  • NFRs são atendidos
  • Não há mais defeitos que devem ser corrigidos
  • Os padrões estabelecidos são atendidos
  • O treinamento é entregue
  • Aprovado pelo Produto / Solução
  • Gerenciamento e Gerenciamento de Liberação

Conclusão

DoR e DoD são uma lista de verificação para verificar se todas as atividades de valor agregado e orientadas pela qualidade foram concluídas. Essa abordagem aparentemente simples tem um impacto tremendo na qualidade, entrega, previsibilidade e precisão do produto com a estimativa de trabalho.

Embora DoR e DoD sejam genéricos para todos os itens na categoria, nem todas as suas atividades podem ser aplicáveis ​​a cada item (história de usuário, recurso, etc.). Portanto, a autoridade e a discrição da equipe são necessárias para lidar com as exceções.

Frequentemente, essas definições são uma lista abrangente para garantir que todas as atividades importantes sejam consideradas.

Ao desenvolver o DoR e o DoD, se uma precaução deve ser tomada, não defina a barra de qualidade muito alta para torná-la irreal. Não defina-o para a altura da melhor equipe realizadora para ver apenas as novas equipes fracassarem ou lutarem para alcançá-lo.

Qualquer coisa que não seja realista para ser alcançada no nível atual pode ser movida para o próximo nível superior. Por exemplo, se o teste de integração não for possível dentro da Iteração, mova-o para o Incremento do Sistema, se não, mova-o para Release, etc. Isso é o que se considera atingir maturidade Agile com o tempo. Claro, o objetivo é mudar constantemente a qualidade para a esquerda.

Finalmente, como o SAFe Framework3 como um todo, o DoR e o DoD também são escaláveis, ou seja, os critérios são cumulativos em cada nível.

Cada definição de nível superior assume todos os critérios dos níveis inferiores. Por exemplo, o DoD no nível do programa assume todos os critérios do nível da equipe mais os novos critérios do nível do programa e assim por diante.

Da mesma forma, os critérios de liberação assumem todos os níveis predecessores mais aqueles específicos para a liberação.

Product Backlog, tudo o que você precisa saber

Para ter ideia de tudo que você precisa saber sobre Product Backlog neste artigo, vamos contextualizar e balizar nossos conhecimentos um pouco.

O que é um Product Backlog? Definição

Uma das características importantes do Scrum é que há um, e apenas um, backlog de trabalho aguardando para ser priorizado, desenvolvido e concluído.

Um Backlog é uma lista de requisitos e requisitos de negócios que ainda não foram implementados. Um Backlog ajuda a entender melhor o produto, além de garantir que cada recurso necessário seja listado.

No desenvolvimento de software, um Product Backlog é uma lista abrangente de tudo o que pode ser necessário no produto. Ele inclui todos os recursos que serão implementados, bem como todos os bugs e problemas que devem ser corrigidos.

Um Product Backlog eficaz ajuda o gerenciamento de produtos e a equipe de desenvolvimento a priorizar tarefas e colaborar.

O objetivo de usar um backlog de produto é garantir que os recursos desenvolvidos sejam priorizados em termos de tempo e importância de valor para o usuário final.

Quem é responsável pelo Product Backlog?

O Product Owner é o responsável e mantenedor do backlog do produto. Além disso, é responsabilidade do Product Owner entender, avaliar e selecionar os itens de backlog individuais que serão adicionados a um sprint ou release atual.

É o PO que  deve receber informações de todas as partes interessadas, incluindo clientes, membros da equipe, executivos, tendências atuais e outras funções internas, mas, em última análise, ele é o tomador de decisão final.

O Product Owner é a pessoa que determina o trabalho que será realizado em cada iteração . O trabalho real atribuído à iteração requer um diálogo colaborativo entre o Product Owner e a equipe ágil.

O PO geralmente pede que a equipe assuma mais trabalho, e a equipe do projeto – deve se comprometer apenas com o nível de trabalho que pode ser totalmente concluído durante a iteração. Em última análise, a equipe Agile é responsável por decidir sobre o trabalho exato que compõe a iteração.

O que é Sprint Backlog? E como ele é planejado?

Em um projeto ágil, a carga de trabalho é determinada no início de cada iteração (sprint). O Product Owner avalia e prioriza o trabalho que precisa ser feito, enquanto a equipe determina a quantidade de trabalho que pode ser concluída e a meta da sprint.

A reunião de planejamento de iteração (Sprint Planning) define o cenário e deve ser executada como um diálogo colaborativo,.

Um dos aspectos exclusivos de um projeto Agile é que a carga de trabalho é determinada no início de cada iteração. Ao contrário dos projetos tradicionais, a carga de trabalho não é definida com meses e meses de antecedência.

Há apenas a necessidade de um planejamento detalhado para a próxima iteração. (O  Product backlog pode ser mapeado em alto nível para iterações futuras, mas o planejamento detalhado ocorre uma iteração por vez.) Isso permite que um projeto ágil seja flexível em sua carga de trabalho e sensível às mudanças nas necessidades e prioridades do cliente.

No início de cada iteração, o Product Owner e a equipe do projeto se reúnem para determinar a carga de trabalho para essa iteração. Durante a reunião, o Product Owner avalia o backlog do produto e simplesmente extrai o próximo conjunto de histórias de usuário que são de maior prioridade.

Esse nível de esforço para concluir a história do usuário pode já ter sido estimado quando a história foi adicionada. Caso contrário, a equipe estima o trabalho na reunião de planejamento.

Essa estimativa pode assumir a forma de horas de esforço real, mas é mais provável que a estimativa seja baseada em “pontos da história” – vamos falar sobre eles depois – A estimativa inclui o trabalho necessário para implementar totalmente a história do usuário, incluindo a análise, design, construção, teste e integração.

Essa separação de histórias, para um pedaço do projeto é chamado de Sprint Backlog.

Legal! até aqui você já entendeu que o Product Backlog (backlog do produto) é a lista de tudo que consta dentro de um produto com os desejos e regras de negócios, enquanto o Sprint Backlog é uma lista priorizada que vai ser executada já na próxima iteração.

Documentação de projeto e o Product Backlog

Em um projeto ágil, você não cria documentos grandes para atender aos requisitos do usuário; na verdade, você não precisa de um documento tradicional. A técnica preferida é usar um backlog do produto, que representa uma coleção priorizada de trabalho restante no projeto em um determinado momento.

Em um projeto Agile, você não cria documentos grandes para atender aos requisitos do usuário. Na verdade, você não precisa de um documento tradicional. A técnica preferida é criar um backlog do produto.

O backlog não é um documento tanto quanto é simplesmente a coleção priorizada de trabalho que permanece em um projeto. Pode ser uma planilha ou tabela que contém uma lista de histórias de usuários. Também pode ser uma pilha de cartões de índice, cada um contendo uma história de usuário ou um item exclusivo de trabalho.

O backlog inicial do produto é gerado no início de um projeto Agile. O tempo pode coincidir com uma fase de iniciação do projeto ou durante uma iteração inicial de configuração (às vezes chamada de iteração 0). O backlog inicial do produto consiste em todo o trabalho facilmente identificado que é conhecido quando o projeto é iniciado.

À medida que cada iteração começa, uma reunião de planejamento é realizada entre o proprietário do produto e a equipe do projeto. O proprietário do produto identifica o trabalho no backlog do produto que ele gostaria que fosse concluído na iteração.

A equipe do projeto valida que pode concluir o trabalho. As negociações são realizadas se houver uma diferença de opinião sobre o trabalho que pode ser concluído durante a iteração. O trabalho mutuamente acordado é então retirado do backlog do produto e implementado durante a iteração.

O que mais existe no backlog do produto?

O backlog do produto representa a totalidade do trabalho restante no projeto em um determinado momento. A maior parte do backlog consiste em histórias de usuários que implementam funcionalidades de benefício para o usuário. No entanto, outros trabalhos também estarão na lista de pendências. Isso inclui.

Entregas do usuário Nem todos os itens do backlog do produto requerem codificação de software. Por exemplo, o proprietário do produto pode querer um Manual do Usuário, conteúdo de treinamento, perguntas frequentes etc. Se as entregas devem ser criadas pela equipe do projeto, o trabalho precisa ser priorizado e incluído na iteração apropriada.

Entregas de TI Essas são entregas exigidas pela organização de TI. Isso pode incluir um Manual de Recuperação de Desastres, documento de retenção de registros, documentação de controle de alterações, etc. Alguns deles podem ter valor para o usuário, mas às vezes são necessários para a organização de TI.

Defeitos e correções de bugs Se erros críticos e bugs surgirem durante uma iteração, eles precisam ser resolvidos para que o código do produto seja viável no final de uma iteração. No entanto, muitos bugs se enquadram na categoria de incômodos.

Eles precisam ser corrigidos, mas há discrição quanto ao momento das correções. Esses tipos de correções podem ser colocados no backlog e priorizados em uma iteração subsequente. Em alguns casos, a equipe espera até o final do projeto para uma limpeza final de bugs e erros.

Como são escritas as histórias no backlog?

As histórias de usuários são escritas de forma vaga e não contêm necessariamente muitos detalhes. As histórias devem conter detalhes suficientes para que tanto o cliente quanto a equipe do projeto se lembrem a que a história se refere.

A história também pode incluir outras informações, como uma estimativa do trabalho necessário para implementar a história. Quando a história é priorizada para uma iteração específica, deve haver informações suficientes para que o proprietário do produto e a equipe possam lembrar o contexto e possam trabalhar juntos para definir os requisitos detalhados.

Na iteração de configuração, o proprietário do produto cria quantas histórias de usuário ele conhece no momento. Não é necessário descobrir todas as histórias de uma só vez. As histórias podem ser adicionadas, modificadas e excluídas continuamente durante o projeto.

Em um projeto tradicional, as mudanças nas histórias de usuários seriam adicionadas usando o gerenciamento de mudanças de escopo. Em um projeto Agile, o proprietário do produto pode adicionar, alterar e remover quaisquer histórias.

O conceito de fluência de escopo não ocorre durante uma iteração. A quantidade de trabalho em uma iteração é fixada pela velocidade da equipe. Se o proprietário do produto continuar a adicionar novos itens à lista de pendências, pode ocorrer aumento de escopo exigindo iterações adicionais para implementar o trabalho em áreas que não faziam parte do escopo original do projeto.

Esse tipo de desvio de escopo deve ser controlado para garantir que o projeto Agile não se desvie.

Se o Product Owner é dono do Backlog, como fica o time?

Embora a equipe de desenvolvimento possa certamente expressar suas opiniões sobre o que deve ser trabalhado, eles não podem realmente agir de acordo com essas opiniões sem o consentimento do Product Owner.

Isso pode levar a uma sensação de “desempoderamento” por parte da equipe de desenvolvimento. Embora uma equipe de alto desempenho deva ser muito colaborativa e permitir que todas as vozes sejam ouvidas, a equipe pode sentir que as necessidades da tecnologia ou os sistemas não estão sendo suportados, ou talvez até valorizados.

Isso pode causar a sensação de “nós contra eles”, que é exatamente o cenário que Scrum e/ou  Agile deveriam evitar. Na verdade, algumas organizações tentam dividir o backlog entre “produto” e “tecnologia” e, às vezes, dão a cada um seu próprio Product Owner. Esta é a maneira errada de resolver este problema.

Dividir ou separar as pendências só causará confusão e interrupção, e não fornecerá transparência sobre o que está sendo trabalhado pela equipe.

O processo funciona melhor quando há um único backlog de trabalho priorizado contendo tudo o que deve ser desenvolvido e há uma maneira altamente visível (física ou eletrônica) para qualquer parte interessada ver o que está em andamento em uma iteração atual.

De qualquer forma, fazer qualquer outra coisa não é necessário – o Agile possui mecanismos para impedir que esse tipo de desempoderamento aconteça, embora o ônus seja da equipe de desenvolvimento para usá-los.

Usar esses mecanismos é a abordagem certa para manter a equipe se sentindo capacitada.

Itens chave para um bom backlog

Há seis itens chave para procurar em uma história de backlog saudável. Ao classificar cada história nessas facetas, você pode ter uma noção fácil de quão pronta a história está para ser escolhida e desenvolvida. Os seis são prioridade, requisitos, estimativas, dependências e definição de pronto e definição de feito.

O processo de refinamento do backlog e consequentemente dos requisitos até o ponto em que eles estejam prontos para serem trabalhados é conhecido como ‘limpeza do backlog’.

Mas essa tarefa realiza mais do que esclarecer requisitos; informa as partes interessadas, contribui para o plano do projeto e reforça os princípios ágeis em geral. Aqui está a orientação sobre como e quando isso deve ser feito.

Uma das inovações mais úteis da família de práticas Agile é o conceito de backlog do produto. No passado, o acúmulo de requisitos existia em um documento – geralmente chamado de Documento de Requisitos de Negócios (BRD – Bussiness Requirements Document) – que continha necessidades totalmente especificadas para o produto com base em qualquer informação que o proprietário da empresa tivesse na época.

O backlog, então, era o que estava no documento que ainda não estava concluído. Isso é realmente muito simples; se o documento contiver 50 itens e três deles estiverem completos, a lista de pendências consistirá em mais 47 itens. É melhor a equipe começar a trabalhar!.

Praticantes ágeis acreditam que duas coisas são verdadeiras: os produtos são melhores quando trabalhamos juntos e devemos abraçar a ideia de que os requisitos estão mudando o tempo todo.

O simples processo de passar semanas ou meses criando um documento enorme que é então entregue aos desenvolvedores não apenas viola os dois princípios, mas perde completamente o objetivo de como criar ótimos produtos. (além de que esse documento enorme acaba na gaveta).

Em vez de despender esforço criando um documento longo que é inferior (devido à falta de colaboração) e desatualizado (devido às necessidades de mudança do negócio), o Agile sugere a criação de algo chamado product backlog.

Esse backlog do produto é uma lista priorizada de requisitos, histórias de usuários, tarefas e atividades que a equipe do produto precisa realizar para levar o produto ao mercado.

Ele difere substancialmente do antigo BRD, pois a lista de requisitos teve diferentes níveis de energia colocados neles, e a lista é fixa e adaptável às necessidades do produto e da equipe do produto.

O processo de transformar esse backlog em algo excelente é chamado de Backlog Refinement (antigamente era grooming) e é um conceito fácil de ser mal interpretado ou usado indevidamente, tanto do ponto de vista do produto quanto do desenvolvedor.

Por que se preocupar com a limpeza no refinamento?

Existem duas dimensões que um backlog de produto Agile traz para o produto que o antigo BRD não trazia: prioridades e a capacidade de alterar ou inserir novos requisitos com o passar do tempo.

No entanto, há mais uma faceta oculta para trabalhar com um backlog priorizado: como algumas das histórias de usuários acabarão no final da lista, não há necessidade de gastar muito tempo com elas.

Acontece que é uma ideia melhor “deixar de lado” essas histórias e reorientar seu tempo nas histórias de usuários que estão no topo da pilha. Em vez de obter os requisitos “suficientemente bons” em geral, o proprietário do produto é responsável por obter os requisitos que estão no topo da pilha “prontos para a iniciar” – mesmo às custas das histórias na parte inferior da pilha.

Um backlog devidamente preparado é o ativo mais importante que uma equipe Agile pode ter. Para que seja o mais útil possível, deve ser capaz de fazer três coisas :

  1. Fornecer itens prontos para o trabalho para a equipe de desenvolvimento:
  2. Ser flexível e conter todas as informações disponíveis sobre o produto e
  3. Fornecer insights para todas as partes interessadas sobre o que está no pipeline a ser trabalhado.

O objetivo principal do backlog é dar trabalho à equipe de desenvolvimento que está pronta para começar. Isso significa que:

  • Ele está totalmente especificado,
  • Suas perguntas são respondidas,
  • O dimensionamento está completo e os critérios de sucesso registrados.

Um membro da equipe deve ser capaz de pegar um item da lista de pendências e começar a trabalhar imediatamente, não importa se é engenheiro de software, testador ou designer.

Isso realmente exige muito esforço do proprietário do produto e da equipe do produto – esforço que foi desviado dos itens na parte inferior do backlog.

Não há nada que um proprietário de produto possa fazer que afete mais a eficiência da equipe do que ter as próximas tarefas prontas para serem executadas.

Se um desenvolvedor de qualquer tipo tiver que passar por um intervalo de até meio dia enquanto espera para começar a trabalhar em algo, isso custará significativamente ao produto no final.

Enquanto isso, o backlog deve ser flexível, tanto em conteúdo quanto em prioridade. Quando o backlog inicial foi criado, ele foi feito com todas as informações, análises e inteligência que o product owner tinha.

Agora que a lista de pendências foi aberta para desenvolvedores, partes interessadas, clientes e outros proprietários de produtos, novas ideias surgirão e uma nova prioridade surgirá.

Por exemplo, trabalhei recentemente em um produto em que o proprietário do produto decidiu intencionalmente não priorizar uma parte inteira do aplicativo em favor de criar uma experiência mais rica nas outras partes.

O feedback foi instantâneo e intenso; sem a funcionalidade que faltava, o produto era inútil. Em vez de esperar um ano ou mais para recuperar essa funcionalidade, o proprietário do produto conseguiu colocar essas histórias de usuários de volta no topo da lista, prepará-las completamente, e levá-los para a próxima versão.

É assim que o Agile deve funcionar!

O backlog também deve ser usado como documentação externa. Todas as partes interessadas querem saber o que está por vir, quando seu caso de uso será criado e o que mais está na lista.

Um backlog devidamente preparado pode servir a essa função. Ao apontar as pessoas para a lista de pendências, elas podem ver o que está perto do topo, o que está na parte inferior e onde sua solicitação está em prioridade relativa.

Eles também podem ter informações ou feedback sobre as prioridades atuais, requisitos futuros ou podem até ter ideias brilhantes que não estão na lista.

Em suma, o backlog pode servir como documento de requisitos, plano de projeto e comunicação com as partes interessadas, tudo ao mesmo tempo. Mas só se for bem feito.

Itens de prioridade de um backlog antes do refinamento

Repare que existem seis itens que são prioridade num product backlog. Os seis são prioridade, requisitos, estimativas, dependências e definição de pronto e definição de feito.

Para criar um backlog saudável, ao classificar cada história em uma escala de zero a três, você obterá uma pontuação total entre zero e 18, permitindo que a equipe saiba, de relance, quais histórias estão em boa forma e quais não estão e, assim, quais a forma do backlog está no todo. Aqui está uma olhada em cada um dos fatores que compõem a “saúde da história”.

1. Prioridade.

Isso parece quase óbvio, pois as tarefas no topo do backlog são as de maior prioridade e as de baixo são as mais baixas. Isso não significa que a razão por trás da prioridade seja compreendida, o que é ainda mais importante.

A equipe de desenvolvimento geralmente prioriza mentalmente o trabalho com base em sua própria compreensão de por que algo é necessário. O papel do proprietário do produto é garantir que a equipe entenda o valor do trabalho; os desenvolvedores não precisam necessariamente concordar com ela, mas precisam entendê-la.

Desenvolvedores trabalhando em algo que não entendem é ruim para todos.

2. Requisitos.

Quase igualmente importante é a compreensão da obra em si, que, mais uma vez, parece óbvia. A parte difícil é que os requisitos nunca são completos; eles só são bons o suficiente por enquanto.

Mesmo depois que um recurso está disponível nas mãos do cliente, ainda há refinamentos, alterações e melhorias que podem ser feitas e provavelmente estão sendo constantemente adicionadas ao backlog.

No entanto, uma vez que uma história de usuário recebe um ou dois sprints de desenvolvimento, é hora de garantir que os requisitos sejam entendidos o suficiente para que um desenvolvedor possa pegá-lo e trabalhar nele.

Os requisitos não precisam ser definitivos – nunca são – mas precisam estar prontos.

3. Estimativas.

Uma parte da preparação do backlog é dimensionar as histórias, usando um mecanismo como pontos de história ou qualquer estratégia que a equipe se sinta confortável em usar.

Histórias que ainda são desconhecidas em relação ao nível de esforço, risco ou complexidade, ou histórias que têm estimativas grandes demais para serem concluídas, trazem muitos problemas para os desenvolvedores.

Quando chega a hora de planejar um sprint, um release ou até mesmo um único dia, é importante saber o tamanho do trabalho que está sendo considerado.

Sem um bom dimensionamento, a equipe fica apenas adivinhando o que pode ser concluído e nunca saberia responder se as coisas estão dentro do prazo ou não.

Estamos trabalhando com um projeto não com adivinhações.

4. Dependências.

Uma das causas frequentes de atraso envolve histórias sendo “bloqueadas” – ou seja, há uma dependência que não foi resolvida que está impedindo o desenvolvedor de progredir.

Se uma história for bloqueada durante o desenvolvimento ou, pior, entrar em um sprint já bloqueado, então é uma história inútil. Essas dependências podem estar em outras equipes de desenvolvimento, equipes fora do desenvolvimento, como criação, marca ou marketing, ou até mesmo o proprietário do produto tomando uma decisão sobre algo.

Como parte da preparação de uma história, é importante descobrir se o desenvolvedor tem tudo o que é necessário para começar o trabalho ou se o terá quando o sprint começar. Alguns podem ser resolvidos da noite para o dia; alguns podem levar vários meses para resolver.

É importante saber onde uma história está quando ela se aproxima do topo da lista de pendências.

5. Definição de Pronto. DoR – Definition of Ready

O que está sendo feito nas tarefas também tem “critérios de aceitação” – ou seja, quais casos de uso e funcionalidades devem existir e poder ser mostrados em uma demonstração para que a história seja considerada completa.

Nesse caso, está associado a cada item de trabalho individual que flui por uma equipe ágil.

Se você estivesse praticando Scrum, então seria no nível do item do backlog do produto (PBI).

Se você estiver operando como uma equipe de programação extrema (XP) ou Kanban (ou simplesmente alavancando histórias de usuários), então seria para cada história que entrasse em uma equipe.

Os critérios de prontidão seriam uma definição clara do que conota uma história de usuário ou PBI que está “pronta” para execução dentro da iteração ou sprint.

Os itens são executados desde a funcionalidade voltada para o usuário até requisitos de latência e desempenho, condições de erro e testes negativos. Quanto mais um desenvolvedor souber o que será necessário para que a história seja aceita, melhor será para todos.

Na verdade, uma metodologia de desenvolvimento requer escrever os testes de aceitação primeiro e depois fazer o desenvolvimento.

6. Definição de Feito. DoD – Definition of Done

Espero que todos estejam familiarizados com a terminologia “definition of done” (DoD), ou “done-ness”, do ponto de vista dos métodos ágeis. É uma frase comum e incrivelmente importante para a saúde e maturidade da equipe ágil. É essencialmente um critério de saída, se você preferir, para o trabalho de sprint das equipes.

No nível da história do usuário, é comum referir-se aos critérios de aceitação de cada história como a verificação de conclusão da completude da história.

Em um nível de sprint completo, é comum se referir ao objetivo do sprint como o ponto de verificação para o que a equipe estava tentando entregar. E o acabamento também permeia a forma como os membros da equipe entregam seu trabalho.

Por exemplo, as revisões de código fazem parte dos critérios de conclusão de uma equipe? Nesse caso, ele planejará e executará revisões de código consistentemente como parte do desenvolvimento e entrega de cada história.

Portanto, a definição de “feito” é um critério de saída, que determina a condição de completude para o trabalho que está sendo entregue. Mas há outro critério que é útil em equipes ágeis na outra ponta do fluxo de trabalho – a entrega a DoR.

Acontece que impedir que histórias mal definidas (ou trabalho) entrem em cada sprint em primeiro lugar é uma maneira incrivelmente saudável de evitar os desafios que descrevi na introdução. Mas vamos explorar a prontidão com um pouco mais de detalhes.

O outro lado do DoD: Descrevendo “Pronto”

Pessoalmente, gosto de uma abordagem de lista de verificação para descrever os critérios de prontidão das equipes para o trabalho. Aqui está um exemplo dos tipos de verificações que eu vi serem valiosas para as equipes aproveitarem ao amadurecer suas histórias:

  • A história é bem escrita; e tem um mínimo de cinco testes de aceitação definidos.
  • A história foi dimensionada para se ajustar à velocidade das equipes e à duração do sprint; por exemplo, algo entre 1-13 pontos.
  • A equipe examinou a história em várias sessões de preparação – seu escopo e natureza são bem compreendidos.
  • A equipe tem o conjunto de habilidades e experiência necessários para implementar a história e entregá-la para atender à definição de “pronto” da organização e da equipe.
  • Se necessário, a história teve um pico de pesquisa para explorar (e refinar) suas implicações de arquitetura e design; ou para explorar os desafios de testabilidade associados a ele.
  • A história descreve o comportamento de ponta a ponta no sistema.
  • A equipe entende como abordar o teste dos aspectos funcionais e não funcionais das histórias.
  • Quaisquer dependências de outras histórias e/ou equipes foram “conectadas” para que a história seja sincronizada e entregue como parte do “todo maior”.
  • A história se alinha com o objetivo do sprint e é claramente demonstrável.

Portanto, não há fases distintas neste caso. Uma nova história de usuário simplesmente precisa atender a todas as verificações acima para que seja considerada pronta para execução.

Como cada história fica pronta depende do proprietário do produto para cada backlog do produto, colaborando com sua equipe. Pode levar um ou 50 passos para chegar lá.

Pode ser rápido ou lento. Mas trabalhando juntos, eles decidem como conduzir uma história até a prontidão para execução.

Criando um semáforo do seu Backlog Refinado

Levando em consideração que vamos utilizar o DAP (Detalhar, Avaliar e Priorizar) para as histórias que serão refinadas, podemos criar também um semáforo com estes Seis itens que falamos acima para seu backlog, dessa forma vamos avaliar as histórias: A, B e C

História Prioridade Requisitos Estimativas Dependências DoD DoR Total
A 1 2 2 1 1 1 8
B 3 3 2 3 2 2 15
C 2 1 1 1 1 1 7

 

Neste ponto, as histórias no backlog devem ser avaliadas ao longo dos Seis vetores acima: Prioridade, Requisitos, Estimativas, Dependências, DoR e DoD.

O ideal, para se ter uma boa métrica, fazer a média de até cerca de seis sprints de histórias é suficiente, embora esse número possa ser potencialmente um pouco maior ou menor, dependendo da cadência de lançamento da organização ou do tamanho do incremento de planejamento.

Histórias classificadas entre 11 e 18 estão prontas (verde); as histórias que estão entre 6-10 ainda não estão prontas (amarelo); e qualquer coisa abaixo de seis não está pronta (vermelho). Isso fornece um mecanismo rápido de semáforo para verificar rapidamente o status do backlog da equipe.

Ter algumas histórias vermelhas não é uma coisa ruim, especialmente se elas estiverem mais abaixo na lista de prioridades. Se você estiver três meses antes da chegada dos pintores, há muitos momentos de responsabilidade antes de precisar escolher seu esquema de cores.

No entanto, histórias vermelhas, ou mesmo muitas histórias amarelas, planejadas para inclusão nos próximos dois sprints, podem sinalizar um problema ou uma lista de pendências que não está em boa forma.

Na verdade, eu sugiro que um backlog perfeito tenha principalmente histórias verdes nos próximos dois sprints, principalmente amarelos nos dois seguintes e principalmente vermelhos nos dois seguintes.

Ao fazer essa avaliação, a equipe pode dizer rapidamente quão saudável é o plano e, portanto, quão certo eles estão de que a equipe está “no caminho certo” para entregar.

Nunca haverá um caso em que não haja incógnitas; na verdade, um dos pontos do Agile é admitir que você não pode saber tudo antes do tempo.

Mas quanto mais você conseguir entender as coisas, especialmente as coisas que estão ao alcance da equipe, mais confiante ela poderá começar a investir no caminho para entregar valor ao cliente e à organização.

Expresse o valor do cliente

A primeira maneira pela qual uma equipe de desenvolvimento pode priorizar seu trabalho técnico é expressar o valor do trabalho em termos de benefício para o cliente.

Afinal, se não houver uma boa razão para fazer o trabalho em primeiro lugar, é lógico que ele não deve ser feito.

Mesmo coisas aparentemente mundanas podem ser enquadradas de forma a ajudar o cliente.

Já ouvi gerentes de desenvolvimento dizerem: “A estabilidade e a segurança de nossos sistemas é um recurso que lançamos todos os dias para nossos usuários”. Quando visto por essa lente, não é difícil descobrir quanto valor para o cliente seria criado e como a prioridade se compara a outros itens.

Esse tipo de determinação pode ser feito para muitas melhorias que parecem técnicas por natureza, mas na realidade são voltadas para o cliente.

Isso inclui itens como melhorias de desempenho, correções de bugs, dimensionamento de carga e até itens invisíveis, como a aplicação de hotfixes ou patches de segurança a uma estrutura de aplicativo.

Todas essas tarefas podem ser vistas como boas para todos e, portanto, devem ser priorizadas junto com novos recursos ou novas funcionalidades. Qualquer bom Product Owner seria capaz de entender o valor que está sendo criado e colocar isso em contexto com todo o resto.

O desafio é que esse tipo de cálculo não é natural para a maioria dos profissionais de produtos; embora reconheçam que há boas razões para fazer esses itens, muitas vezes têm dificuldade em quantificá-los.

É aqui que a equipe de desenvolvimento precisa agir como se estivesse na organização do produto, determinando o quanto os tempos de resposta serão mais rápidos ou quantas vezes um determinado defeito e acionado por um cliente ajudará a calcular o valor do trabalho.

As melhores práticas do setor podem ser citadas quando se trata de atualizações de estrutura, assim como eventos nas notícias que expõem vulnerabilidades que devem ser fechadas.

Qualquer que seja o caminho escolhido pela equipe, deve ser em termos de criação de valor; chamar as coisas de “devem ser feitas” sem fundamentação não é uma maneira útil de colaborar.

Refinar como parte da estimativa

Muitas das atividades que compõem um projeto ágil devem ser feitas em equipe, com todos no mesmo lugar. De fato, no Manifesto Ágil, um dos princípios afirma que as interações cara a cara são a maneira mais eficiente e eficaz de se comunicar.

Isso apresenta um problema para um gerente de projeto executando um projeto em que a equipe é distribuída, no todo ou em parte. Embora ter todos na mesma sala possa ser o ideal, não é realista se as pessoas trabalharem a quilômetros ou países de distância, ou se todos forem forçados a trabalhar em suas casas.

E enquanto a tecnologia pode ajudar a nos aproximar e imitar a interação face a face, há outras logísticas, como fusos horários e conectividade, a serem superadas.

Na prática, quase tudo o que pode ser feito em Agile pode ser feito de forma distribuída, desde o Daily Scrum até demonstrações e retrospectivas. É preciso apenas um cuidado extra para torná-los eficazes.

Uma atividade ágil importante que as equipes distribuídas podem realizar sem muita perda é o refinamento do backlog.

É importante para um scrum master, product owner ou mesmo um gerente de projeto que se encontra gerenciando uma equipe distribuída não tentar substituir os processos existentes pelo mesmo usando tecnologia.

Não é “o mesmo, apenas em vídeo”.

O seu objetivo é encontrar uma maneira de obter o mesmo valor de uma atividade sem necessariamente fazê-la exatamente da mesma forma que a equipe fez no passado.

O mesmo vale para o refinamento do backlog. Para uma equipe que costumava se reunir na mesma sala toda quinta-feira à tarde, simplesmente mudar para fazer a mesma coisa por videoconferência não terá os mesmos resultados.

O resultado desejado de uma sessão de refinamento é que os itens do backlog passem de ideias para itens acionáveis ​​que são compreendidos, dimensionados e priorizados.

Isso é possível, mesmo que todos estejam presos trabalhando em seus “escritórios domésticos”.

Na verdade, mesmo que todos estejam trabalhando na mesma mesa, certas partes de uma sessão de refinamento devem ser feitas em particular.

Para garantir que todos entendam um requisito, todos devem passar algum tempo sozinhos, certificando-se de que o entendem e que há informações suficientes sobre a história para que alguém possa pegá-lo e ter uma boa ideia do que precisa ser feito.

O escopo, ou determinar quanto esforço algo exigirá, também deve ser feito em particular. O conceito de “planning pôquer” é uma forma de prevenir o pensamento de grupo, e como uma forma de garantir que os desenvolvedores mais experientes, ou mais falantes, não se sobreponham a todos na sala.

Ambas as partes do refinamento devem ser feitas separadamente e, em um ambiente distribuído, às vezes pode ser feita mais facilmente.

Aqui está um exemplo de como seria uma sessão de refinamento de backlog distribuído.

Cada um analisa o refinamento por conta própria

O refinamento começa com o dono do produto ou a pessoa que possui a história introduzindo os requisitos, objetivos e resultados desejados da história.

Isso pode ser feito ao vivo por meio de discussão ou pode ser algumas linhas escritas dentro da própria história. O dono do produto deve incluir requisitos detalhados, cenários, casos de falha, regras de negócios e outros itens importantes para completar a história.

Cada membro da equipe de produto deve analisar a história por conta própria, para garantir que a história conforme escrita corresponda à compreensão do que estão discutindo.

É muito fácil em uma situação de grupo presumir que outros membros da equipe têm o mesmo entendimento, ou eles entendem ambiguidades ou partes da história que não são claras.

Façam perguntas juntos no refinamento

Ao ler a história, cada desenvolvedor deve fazer perguntas esclarecedoras. Cada membro da equipe terá uma lista de itens que precisam de mais informações ou mais detalhes e devem estar preparados para perguntar ao dono do produto.

Esta parte deve ser feita em grupo, pois haverá perguntas de outros membros da equipe, e uma pergunta provavelmente gerará mais algumas. Os desenvolvedores devem fazer perguntas ao dono do produto até sentirem que entendem bem a história e todos concordarem que todas as perguntas foram respondidas, incluindo novas perguntas que surgiram durante a própria discussão.

Isso não significa que a história seja tão detalhada a ponto de não ter mais nada a ser considerado, mas sim que a história atendeu à “definição de pronto” para a equipe.

Reunião de backlog produtiva

Estimar o refinamento separadamente

Uma vez que a história atende à definição de pronto, cada desenvolvedor decide por si mesmo sobre o tamanho da história. Diferentes metodologias usam diferentes mecanismos para decidir como definir o escopo de uma história; a maioria dos projetos ágeis usa pontos de história.

Esses pontos pretendem representar uma visão geral da dificuldade de uma história, incluem complexidades desconhecidas, riscos, dependências e esforço real para completá-la.

Quando as estimativas são feitas ao vivo em uma reunião, cada desenvolvedor as descobre por conta própria, seja usando o planning poker ou por algum outro método.

Cada desenvolvedor terá uma visão diferente sobre o quão difícil será concluir uma história, seja devido à experiência passada, ou usando uma solução da qual apenas alguns membros da equipe estão cientes, ou talvez conhecendo um ponto de discórdia da última vez que a equipe lidou um pedido como este.

Seja qual for a causa, mesmo quando feito ao vivo, cada membro da equipe cria o que pensa por conta própria. Esse valor é então revelado à equipe, de uma só vez, o que leva a uma discussão e a um resultado final.

Fazer isso de maneira distribuída, na verdade, torna essa etapa mais fácil. Cada desenvolvedor pode levar seu tempo para entender o espaço do problema, e sua solução.

Quando todos dizem que estão prontos, a discussão final pode começar e podem chegar a sua própria determinação quanto ao escopo, sem ter uma sala cheia de pessoas olhando para eles enquanto ponderam.

Discutir o refinamento e finalizar em equipe

Uma vez que as estimativas de esforço de todos são conhecidas, a equipe deve se reunir novamente e discutir o resultado. É raro que todos na equipe tenham a mesma opinião; alguns serão mais altos ou mais baixos do que outros, e pode haver um ou dois valores atípicos.

Nesse ponto, a equipe analisa os processos de pensamento uns dos outros e como eles acabaram com seu valor. A equipe pode então voltar a votar em particular ou simplesmente decidir chegar a um acordo que todos possam aceitar.

Uma vez que isso seja resolvido, a equipe pode dividir a história em tarefas que podem ser feitas individualmente. Ser distribuído pode facilitar essa parte; todos precisam estar confortáveis ​​com o valor final por conta própria.

Estar separado pode ajudar a impor isso e evitar que as pessoas concordem simplesmente em concordar ou permitir que uma pessoa domine a discussão.

A pessoa que lidera a sessão de refinamento deve garantir que os pensamentos de todos sejam ouvidos e que todos entendam o resultado final.

Pessoalmente, o líder provavelmente olharia ao redor da sala e tentaria julgar com base em acenos de cabeça ou talvez até mesmo julgando o silêncio.

Como todos estão separados, todos precisarão dizer em voz alta que estão alinhados.

Sobre fazer refinamento remoto

Em vez de tentar ler os rostos das pessoas, fazer com que as pessoas falem tornará os sentimentos das pessoas muito mais claros, o que pode realmente levar a uma equipe melhor coordenada no final.

Mais e mais empresas estão executando seus projetos de maneira distribuída. Isso é especialmente verdadeiro durante uma pandemia mundial, mas também estava se tornando cada vez mais verdadeiro devido à natureza global da indústria e aos avanços da tecnologia.

Algumas das atividades e cerimônias associadas à execução de um projeto Agile precisam de um esforço extra para garantir que ainda possam atingir seus objetivos sem que todos precisem estar na mesma sala.

O refinamento da lista de pendências, no entanto, se presta facilmente ao trabalho com uma equipe que não está reunida.

Certas partes dele, certificando-se de que as histórias sejam compreendidas e chegando a estimativas de escopo e esforço, devem ser feitas individualmente.

Outras partes, como fazer perguntas e elaborar um plano final, podem ser feitas em conjunto, com todos se revezando, tomando os devidos cuidados

Como saber quando realizar o refinamento?

Você já entrou em um sprint assumindo uma história de usuário da qual se arrependeu mais tarde? Por exemplo:

  • Uma que você deveria ter dividido um pouquinho mais?
  • Uma que a equipe não tinha uma “pista de bola de neve” de como implementar tecnicamente?
  • Uma em que o valor não era claro do ponto de vista do negócio?
  • Uma onde a estimativa e a realidade não eram iguais?
  • Uma que, quando você “fez”, você não tinha certeza de como determinar que foi feito?

Eu estou supondo, é claro que você tem. Eu encontro essas cenas em equipes que estou treinando o tempo todo. E verdade seja dita, não é um evento terrível. Equipes cometem erros… o tempo todo. E eles geralmente aprendem com eles.

O verdadeiro problema, da minha perspectiva, é com as equipes que continuam fazendo esse sprint sobre sprint sobre sprint. Sim, a dinâmica muda um pouco, mas o resultado final é o mesmo. A equipe está aceitando histórias de usuários que realmente não estão prontas para o sprint!

Então a pergunta é: o que pode ser feito para evitar isso? Existe alguma técnica que impeça que isso aconteça, ou essas equipes estão condenadas a continuar repetindo seus erros? Estou feliz que você perguntou.

Relação com o refinamento do backlog

Então, você pode estar se perguntando: como uma história de usuário fica pronta? Do meu ponto de vista, é parte da preparação ou refinamento contínuo e em tempo real do backlog que uma equipe assume como parte natural do amadurecimento de seu backlog.

Reuniões regulares de preparação fornecem um local para essas discussões, e é simplesmente uma parte de preparar seus backlogs suficientemente para uma execução eficaz.

As equipes geralmente agendam até 10% de seu tempo em cada sprint para refinamento do backlog. Cerca de metade disso é focado em reuniões, talvez duas reuniões de 1 hora por semana.

O restante do tempo é gasto em refinamento individual ou em pequenos grupos. O ponto é que a equipe mergulhe continuamente em seus backlogs de produtos.

O refinamento geralmente examina:

  • Estimativa de história
  • Decomposição da história
  • Definição da história
  • Investigação da história
  • Aceitação da história

Você continua refinando cada história de usuário até que a equipe tenha alcançado um nível sólido de compreensão e a história tenha sido dimensionada adequadamente para caber em um sprint.

Muitas vezes, as equipes estão antecipando vários sprints, de modo que o refinamento não é apenas em torno do que vem a seguir, mas principalmente focando em um fluxo de trabalho para a próxima versão ou mais.

Como eu “Preparo” meu Backlog

Este artigo não pretende ser uma cartilha sobre o processo passo a passo sobre como fazer a preparação do backlog, mas as etapas gerais são as mesmas.

No Agile, existe um acrônimo chamado DEEP que é frequentemente usado. Significa: Detalhado, Emergente, Estimado e Priorizado. Cada um desses quatro poderia ser assunto de seu próprio artigo, mas vamos dar uma olhada em cada um e entendê-los melhor.

O D é para Detalhado

E muitas vezes você verá isso chamado “Detalhado apropriadamente”.

O que isso significa é que cada história de usuário ou item no backlog precisa ser detalhada o suficiente para a posição em que está e que o nível de atenção  esteja pronto para quando um desenvolvedor a pegar.

Dependendo da história, isso pode significar que todos os ativos estão prontos, todos os equipamentos adquiridos ou todos os casos de exceção são conhecidos e descritos.

Se uma história está na parte inferior, pode ser explicada com menos precisão, pois não há necessidade de prepará-la ainda.

O primeiro E é geralmente para Emergente

A ideia é que o backlog mude com o tempo e esse comportamento deve ser adotado, não resistido.

O backlog inicial vem dos pensamentos iniciais do proprietário do produto; é raro que uma pessoa trabalhando sozinha vá acertar tudo na primeira tentativa.

Na verdade, se o backlog mantiver a mesma priorização em todo o projeto, isso é mais um sinal de que algo está dando errado do que um sinal de que as coisas estão dando certo.

À medida que a equipe aprende mais sobre o produto (geralmente chamado de “discovery do produto”), novas coisas serão adicionadas, algumas serão removidas e muitas coisas mudarão de prioridade. Este é um sinal de um backlog saudável.

O segundo E é para Estimativa

Falamos acima que não se espera apenas que o backlog seja uma listagem de requisitos, mas também uma ferramenta para o planejamento do projeto.

Para que isso funcione, os itens precisam ser estimados adequadamente. A estimativa ágil é uma arte e também uma ciência, mas a mesma coisa vale tanto para a estimativa quanto para o detalhamento.

Quanto mais próximo um item estiver do topo da lista de pendências, mais detalhadamente ele deve ser estimado. Os itens na parte inferior podem ter estimativas como “grande” ou “muito grande”.

Mas para fazer um planejamento adequado, os itens no topo devem ter estimativas que ajudem a fazer um plano que funcione. Cada equipe usa um mecanismo diferente, de pontos de história a dias de esforço ou qualquer outra coisa.

O mecanismo real não importa, o que importa é que o que é usado realmente ajuda a criar um plano útil.

Finalmente, o P é para Priorizado

Embora já tenhamos falado sobre isso, o conceito de criar uma lista priorizada pode ser difícil para novos proprietários de produtos. Às vezes, os proprietários de produtos dividem os recursos em listas que não alteram o comportamento, como “obrigatório”, “crítico” e “bloqueador de lançamento”.

Dependendo do seu ponto de vista, todas essas três coisas são as mesmas. 

O Agile propõe uma classificação literal da pilha de prioridades, de um ao infinito, o que ajuda a responder às perguntas sobre o que fazer a seguir, o que está no próximo sprint e o que está fazendo o lançamento.

Se um proprietário do produto não puder priorizar, ou pior, criar várias prioridades principais, a lista de pendências se tornará inútil.

A preparação adequada do backlog o torna DEEP; os itens são devidamente detalhados, novas ideias e novos pensamentos podem surgir, estimativas são criadas e definidas e as prioridades são claras e comunicadas. Sem isso, a equipe terá um desempenho inferior.

Resumo e Conclusão

O backlog deve ser preparado constantemente; histórias de usuários devem ser esclarecidas, especificadas e preparadas para o trabalho. E os itens que estão em desenvolvimento ativo devem ficar o mais estáveis ​​possível.

Isso significa que o ato de preparar o backlog nunca deve parar; muitas equipes reservam tempo para fazer isso semanalmente, incluindo todos da equipe.

O impacto dessa preparação deve ser sentido em intervalos regulares, seja a cada sprint, a cada lançamento ou em algum outro intervalo especificado. Aderir a um cronograma beneficiará a equipe e o produto, que é a essência do Agile.

O backlog do produto serve a muitos propósitos. É a lista canônica de requisitos que são totalmente especificados, em ordem de prioridade, e estão prontos para um desenvolvedor pegar e trabalhar.

Ele também serve como uma ferramenta de planejamento que mostra quais itens estão sendo trabalhados, quais são os próximos itens e fornece algumas informações sobre os recursos que estão em baixa na lista de prioridades.

As partes interessadas podem visualizar a lista de pendências e entender para onde o produto está indo e quando podem esperar ver a funcionalidade pela qual estão esperando. É uma ferramenta poderosa.

Mas além de ser um artefato útil para executar um projeto, também é uma boa maneira de incorporar os princípios do Agile.

Ter a equipe de desenvolvimento como atores completos na preparação dos requisitos e ter o proprietário do produto envolvido no design e na estimativa ajuda a unir a equipe e remove a situação “nós contra eles” com a qual todos lutamos no passado.

A preparação adequada ajuda o produto, a equipe e a organização.

Embora pareça sem importância, pode ser a coisa mais importante que você precisa para acertar.

Estes não são tipicamente parte da definição do “core Scrum”. No entanto, como histórias de usuários e preparação de backlog, são práticas incrivelmente úteis para muitas equipes.

Se você refletir de volta à introdução, essas equipes em dificuldades perderam de vista como pré-definir adequadamente seu trabalho.

Mas, para ser muito mais sucinto: é sempre uma boa prática para equipes ágeis garantir que suas histórias estejam prontas antes de colocá-las em um sprint.

A reunião de Sprint Planning efetiva

No início de cada Sprint, a equipe Scrum e o Product Owner negociam o escopo do Sprint em uma reunião com tempo limitado para discutir e concordar com o backlog da Sprint, mas como realizar uma Sprint Planning efetiva?

O Product Owner quer que a funcionalidade seja implementada adequadamente e que seja investido o dinheiro do cliente com sabedoria no desenvolvimento, a equipe quer uma missão que consiga cumprir, e claro,  todo mundo quer que a reunião de Sprint Planning termine na hora!

Sprint Planning template

Vou deixar aqui pra você um template de agenda da Sprint Planning, para que seu planejamento de sprint seja bem-sucedido. 

A finalidade da Reunião de Planejamento da Sprint (Sprint Planning) é que o Product Owner e a equipe negociem o que deve ser realizado durante a Sprint, ou, como prefiro chamar, o contrato de Sprint.

Embora valorizemos as interações do cliente em relação aos contratos formais, os contratos ainda podem ser úteis e eu gosto de falar sobre um “contrato de Sprint“.

É simplesmente um acordo entre o Product Owner, que concorda em não mudar o combinado antes do final do Sprint, e a equipe, que se compromete a entregar um conjunto definido de funcionalidades até aquele momento.

Parâmetros Básicos do Contrato de Sprint

Um dos segredos mais bem guardados do Scrum é que um projeto consiste em uma série de mini-projetos de tempo fixo, qualidade fixa e escopo fixo, onde cada mini-projeto tem um teto de custo.

Sendo assim basta somar os resultados de todos os mini-projetos juntos e você tem o valor do seu lançamento.

Como o comprimento do Sprint, o tamanho da equipe e a definição do feito são definidos e fixados para a duração do sprint, apenas o escopo pode variar e, mesmo aqui, a equipe se esforça para definir e cumprir o compromisso.

Da mesma forma o custo depende principalmente das horas trabalhadas, o limite superior é conhecido, mas desde que as coisas acontecem.

Bem como ser chamado para ajudar outro projeto ou a visita de um médico inesperado.

Nestes casos o limite raramente é alcançado. Então você tem um teto de custo.

Enquanto a qualidade é expressa através da definição de feito e só deve mudar ocasionalmente. Como todos os parâmetros são fixos para a duração do Sprint, a única coisa a se concordar é o escopo.

Embora não seja um parâmetro do contrato, a velocidade esperada ajuda a definir a expectativa de quanto pode ser realizado dentro da Sprint.

Permanecendo dentro do time-box

O Scrum Master modera a reunião de Sprint planning, mas o Product Owner vem com a agenda, afinal ele quer que a funcionalidade seja entregue e que o projeto geral esteja no caminho certo.

Independentemente da duração do sprint ou do tamanho da sua equipe, a preparação é a chave para terminar a tempo.

Se você está despreparado, a reunião pode realmente se arrastar!

Antes de começar, a equipe de implementação deve ter visto, entendido e avaliado as histórias – As histórias devem ser pequenas o suficiente para serem implementadas em uma sprint – Os critérios de aceitação deveriam ter sido definidos.

Isso aumenta muito suas chances de o Product Owner aceitar a implementação ja na primeira tentativa.

A equipe deve saber quanta capacidade eles têm disponível. Isto é: as férias, treinamentos, eventos da empresa e outros compromissos devem ser conhecidos e contabilizados antes do início da sprint.

Alguns eventos são imprevisíveis, caso em que você apenas faz uma estimativa razoável de quanto vai consumir, concorda com as prioridades do Product Owner e aceita algumas histórias como “condicionais” – aquelas que você fará se tiver tempo.

Uma reunião de planejamento simples da sprint

Eu usei essa estrutura em vários contextos, incluindo um caso em que o Product Owner  pagou pela equipe por hora e outro com equipes distribuídas em dois ambientes (sites) diferentes.

O quanto você precisa ser formal dependerá de muitas coisas, incluindo o tamanho do projeto, quão bem o projeto está indo, a relação comercial entre o proprietário do produto e a equipe, como as partes cooperam, etc.

Quanto mais desafiador o projeto, mais você precisa pontilhar você e cruzar seu t.

Revise os parâmetros básicos – Data de início e término, hora e local da reunião de revisão do sprint, disponibilidade da equipe e definição de pronto;

Apresentar e discutir cada história – Uma caixa de tempo para cada um pode ser útil para manter toda a reunião no caminho certo, manter uma reserva no final desta seção para histórias difíceis geralmente torna mais fácil seguir em frente se a discussão estiver ficando presa em uma história;

Comprometa-se com as histórias – Percorra a lista, uma de cada vez e por ordem de prioridade, faça com que a equipe se comprometa com cada uma até que ninguém se comprometa mais;

Realize o Acordo – Confirme a lista de histórias confirmadas com o Product Owner.

Como Scrum Master, achei útil confirmar o contrato da Sprint com um e-mail para o Product Owner, nele enviei uma imagem do quadro de tarefas, um pdf da planilha, um dump de tela da página wiki, ou até mesmo o próprio chamado na ferramenta que utilizamos (com os anexos nele) pode ser uma maneira eficaz de capturar o contrato.

Todos ficam sabendo exatamente sobre o que deve ser feito e tanto o Product Owner quanto a equipe têm uma base sólida para examinar o sucesso da sprint e o estado geral do projeto na revisão do sprint.

Conclusão

Em suma, não é porque priorizamos software funcionando em detrimento de documentação que você não “pode” ou “deve” parar de trabalhar em seus documentos, você pode utilizar esse template numa reunião de Sprint Planning e conseguir “fechar” o contrato com sua equipe e seu Product Owner de uma forma simples e transparente.

Em breve enviarei mais notícias das minhas jornadas ágeis e conforme for aprendendo eu acabo compartilhando com você. Um grande abraço e até semana que vem.

 

Contratos para projetos ágeis: tudo que você precisa saber

Como cliente ou fornecedor de serviços de software no início de um projeto de desenvolvimento, você sabe que há muito em jogo para trabalhar apenas com um acordo verbal, contratos para projetos ágeis soam como algo paradoxal ao Manifesto ágil.

Embora o Manifesto Ágil1 valorize a colaboração do cliente acima dos contratos, os contratos são necessários ao trabalhar com fornecedores externos. Um contrato é realmente apenas um conjunto de “regras do jogo” escritas.

As regras certas aumentam a chance de sucesso de ambas as partes. As regras erradas dificultam a cooperação e impedem o progresso.

Quais tipos de contrato são melhores para projetos ágeis de desenvolvimento de software?

Este é o primeiro de dois artigos. Neste artigo, veremos o objetivo e o conteúdo de um contrato e alguns critérios para avaliar contratos ágeis.

Na próxima semana, veremos alternativas de contratação de projetos de software Scrum e examinaremos seus pontos fortes e fracos.

Qual é o propósito de um contrato?

Contratos definem as regras básicas de jogo para o projeto. Em teoria, eles são livremente inseridos por ambas as partes para criar as condições ideais para concluir com sucesso o projeto.

Na prática, os contratos são frequentemente vistos como jogos competitivos, em que o objetivo é colocar a outra parte em desvantagem, especialmente se as coisas correrem mal.

Contudo empresas muito grandes e o governo geralmente têm condições padronizadas que precisam ser aceitas “em bloco” como um pré-requisito para que você consiga fazer negócios com elas.

Essas condições raramente são justas, portanto, um resultado razoável do projeto depende muito de um bom relacionamento com o cliente real e de evitar o recurso ao contrato ou à lei – O Manifesto Ágil está certo neste ponto: os relacionamentos com os clientes são mais importantes do que os contratos escritos!.

Mesmo que os contratos negociados nem sempre busquem uma relação ganha-ganha, você pode precisar da ajuda de especialistas.

No entanto, da perspectiva do cliente, os contratos não produzem valor agregado. Eles são um produto residual, portanto, o esforço gasto na negociação e produção deve ser minimizado.

Um contrato distribui o risco e reflete a confiança entre as partes.

O que acontece se algo der errado? Quem paga quanto o projeto é mais difícil do que o esperado? Quem se beneficia se o projeto for concluído antes do planejado?

As regras de jogo erradas podem ser prejudiciais para o sucesso do projeto. Regras ruins podem levar a preços irrealistas, prazos ou expectativas pouco funcionais. Relações de ganhar/perder são prejudiciais para o sucesso do projeto – A qualidade sofre mais frequentemente – Você quer que a “Equipe A” ou a “Equipe B” trabalhem no seu projeto? Pense cuidadosamente sobre quanta pressão você coloca no fornecedor.

Como avaliar as formas de contrato

Os contratos comerciais podem assumir muitas formas. Quais são as alternativas de contrato adequadas para projetos de desenvolvimento ágil? Para qualquer contrato, eu olharia:

  • Como o contrato é estruturado? Quais são as regras básicas para entregar o escopo e o faturamento?
  • Como distribuir o risco e a recompensa entre o cliente e o fornecedor?
  • Como ele lida com mudanças nos requisitos?
  • Que modelo de relacionamento com o cliente ele promove: competitiva (minha vitória é sua perda), cooperativa (ganha-ganha), indiferente (não me importa – você perde) ou dependente (cara-eu-ganho-coroa-você perde) ?

Se eu não elaborasse o contrato, também procuraria por armadilhas – a negociação de contato pode ser um jogo competitivo – A questão aqui é o que você faz se encontrar uma? – Tentar eliminá-lo ou aceitar e seguir em frente? Vamos chamar isso de “decisão de negócios“.

Quais informações devem ser incluídas em um contrato?

Quanto mais confiança existir entre cliente e fornecedor, menos você precisará anotar. Na minha experiência, há alguns pontos que pertencem a todos os contratos:

  1. Objetivos do projeto e da cooperação entre as empresas. Isto reflete diretamente ao “elevator pitch” e a missão do produto.
  2. Um esboço da estrutura do projeto – processo de Scrum, papéis principais e quaisquer diferenças do Scrum que se aplicam.
  3. Key-Users – quem é responsável nos níveis operacional e de escalonamento e o que é exigido dessas pessoas?
  4. Pagamento e faturamento, incluindo quaisquer cláusulas de bônus e penalidade.
  5. Rescisão antecipada e normal.
  6. “Detalhes legais.” Dependendo da lei local e dos costumes legais, pode ser necessário limitar a responsabilidade civil, especificar local, garantir a separação (que partes do contrato permanecem em vigor, mesmo que partes do contrato sejam consideradas inválidas) ou incluir outras cláusulas no texto para evitar que várias coisas ruins com bases legais aconteçam. Exemplos de contratos de referência da sua região e realizar benchmarking pode ser muito útil (e são mais baratos que um advogado!).

Você precisa incluir o escopo no contrato?

Frequentemente o escopo está presente (pelo menos nos contratos do governo que eu participei, o escopo foi incluído por lei), mas se concentrar o contrato no escopo também faz com que o escopo fique inflexível.

Se possível, é melhor especificar como você gerenciará o escopo (por exemplo, Backlog do produto, contrato do Sprint), mas detalhes operacionais devem ser deixados para a equipe do projeto.

Os pontos 2, 3, 4 e 5 determinam as regras de jogo para o seu projeto. Se você acertar, você terá a base para um bom projeto. Mas quais são as melhores regras? Há pelo menos meia dúzia de tipos diferentes de contrato, de tempo e materiais a preço fixo, escopo fixo.

No próximo artigo vou trazer alguns tipos de contrato que vão “clarear” um pouco mais sua mente neste quesito. Até semana que vem!

Contratos Ágeis – 10 tipos de contrato

De acordo com Peter Stevens2, levantamos 10 tipos de contratos ágeis que podem fazer a diferença em seus projetos de software.

Além disso,  analisamos o propósito e o conteúdo de um contrato e identificamos critérios para avaliar contratos para projetos Scrum e ágeis.

Onde sugeri 4 pontos para comparar formas de contrato:

  • Como o contrato é estruturado? Quais são as regras básicas para entregar o escopo e o faturamento?
  • Como distribuir o risco e a recompensa entre o cliente e o fornecedor?
  • Como ele lida com mudanças nos requisitos?
  • Que modelo de relacionamento com o cliente ele promove: competitiva (minha vitória é sua perda), cooperativa (ganha-ganha), indiferente (não me importa – você perde) ou dependente (cara-eu-ganho-coroa-você perde) ?

Nesta semana, vamos analisar vários contratos possíveis e ver como eles funcionam com projetos de desenvolvimento ágeis e do Scrum:

  • O “Contrato de Sprint”
  • Preço Fixo / Escopo Fixo
  • Tempo e Materiais
  • Tempo e Materiais com Escopo Fixo e Teto de Custo
  • Tempo e Materiais com Escopo Variável e Teto de Custo
  • Desenvolvimento Faseado
  • Cláusulas de bônus / penalidade
  • Lucro Fixo
  • “Dinheiro para nada, mudanças de graça”
  • Empreendimentos conjuntos /Joint Ventures

Contratos ágeis – Contrato de Sprint

Trabalhando com o Scrum, descobri que a metáfora de um “Contrato de Sprint” que é útil para entender (e às vezes reforçar) o relacionamento entre o Product Owner e a equipe de implementação.

agile-contracts-sprint3

Estrutura: Este não é realmente um contrato comercial, mas simplesmente o acordo entre o Dono do Produto e a Equipe para um sprint.

Escopo: A equipe de implementação concorda em fazer o melhor para entregar um conjunto de recursos (escopo) acordado para um padrão de qualidade definido até o final do sprint. (Idealmente, eles entregam o que prometeram, ou até mesmo um pouco mais.)

O Product Owner concorda em não alterar suas instruções antes do final do Sprint.

Risco: Um projeto Scrum pode ser considerado como uma série de mini projetos com parâmetros fixos:

Tempo (Sprint), Escopo (Backlog), Qualidade (Definição de pronto) e Custo (Tamanho da Equipe * Comprimento da Sprint). Apenas o escopo pode variar e isso é medido a cada sprint.

Dica: Confirmar “o contrato de Sprint” via e-mail ou publicá-lo no (Wiki/base de conhecimento) do projeto no início de cada Sprint é geralmente uma boa ideia.

Cria confiança, independentemente da forma contratual subjacente.

Dica 2: O contrato da Sprint pode ser referenciado no contrato comercial.

Descobri que, depois de alguns lançamentos, o contrato comercial pode se reduzir a um contrato de tempo e material de uma página, talvez com um teto de custo para o trimestre ou para o próximo grande lançamento.

Contratos ágeis – Preço Fixo / Escopo Fixo

agile-contracts-preco-escopo-fixos3Estrutura: Concorde com as entregas, entregue-as – Envie uma fatura – Os clientes gostam de projetos de preço fixo porque lhes dá segurança (ou pelo menos eles pensam assim).

Escopo: O nome diz tudo, não é? O jogo de solicitação de alteração (correção: processo de solicitação de alteração) destina-se a limitar as alterações no escopo – Esse processo é caro e as alterações geralmente não são evitáveis – Como o cliente quase por definição quer sempre mais escopo, encerrar o projeto pode ser difícil.

O fornecedor quer que o cliente seja feliz, então o fornecedor geralmente produz. As palavras “etcetera” são muito perigosas na especificação de um requisito de preço fixo.

Risco: O risco óbvio está do lado do fornecedor. Se as estimativas estiverem erradas, o projeto perderá dinheiro.

Riscos menos óbvios são o jogo de solicitação de mudança, através do qual o fornecedor negocia receita adicional através de mudanças de escopo.

Se o fornecedor subestimou mal o esforço ou risco, ou cotou um preço irrealista baixo, as perdas podem até ameaçar a existência do fornecedor, o que também representa um problema para o cliente.

Relacionamento: De competitivo para indiferente – O cliente geralmente quer ter mais e o fornecedor quer fazer menos – O fornecedor quer que o cliente seja feliz, então normalmente o fornecedor produz.

Dica: Especifique os requisitos funcionais com histórias do usuário.

Contratos ágeis – Tempo e Materiais

agile-contracts-time-materials3Estrutura: Vá e trabalhe por um mês e envie uma fatura ao cliente.

Fornecedores gostam disso, porque o cliente corre o risco de mudar de ideia no meio do caminho.

Escopo: A priori não fixo. Mais cedo ou mais tarde, o cliente não quer pagar mais, então o projeto chega ao fim.

Risco:  São carregados em 100% pelo cliente. O fornecedor tem pouco incentivo para manter os custos baixos.

O esforço para garantir que apenas esforços e despesas legítimos sejam faturados pode ser substancial.

Relacionamento: Indiferente. O fornecedor fica feliz quando há mais trabalho porque mais trabalho significa mais dinheiro.

Dica:  Recomendado para projetos em que o cliente possa gerenciar melhor o risco do que o fornecedor.

Isso geralmente é combinado com um teto de custo. Quão bem funciona pode depender de como o escopo é tratado.

Contratos ágeis – Tempo e Materiais com Escopo Fixo e Teto de Custo

agile-contracts-time-materials-escop[1]Estrutura: Igual ao preço fixo, escopo fixo, exceto se o fornecedor concluir antecipadamente, o projeto passa a custar menos, porque somente o esforço real é faturado.

Escopo: O mesmo que preço fixo, escopo fixo.

Risco: Neste caso esse contrato parece representar o “melhor dos dois mundos” do ponto de vista do cliente.

Se requer menos esforço do que o esperado, custa menos. Mas uma vez que o teto de custo foi alcançado, ele se comporta como um projeto de preço fixo.

Relacionamento: Dependente – Do ponto de vista do fornecedor, o objetivo é atingir exatamente o limite de custo – Não há incentivo para o fornecedor entregar abaixo do custo máximo orçado.

O cliente provavelmente tratou o projeto internamente como um projeto de preço fixo e, portanto, não tem incentivos para renunciar ao escopo para economizar dinheiro.

Contratos ágeis – Tempo e Materiais com Escopo Variável e Teto de Custo

agile-contracts-time-materials-escop[2]Estrutura: Igual ao tempo e materiais, exceto um teto de custo, que limita o risco financeiro do cliente.

Escopo: O mesmo que um preço fixo, projeto de escopo fixo.

Risco: O orçamento expira sem atingir o valor comercial necessário para o cliente.

O cliente não recebe tudo o que ele pede.

Relacionamento: Cooperativa. A combinação de orçamento limitado e escopo variável enfoca o cliente e o fornecedor na obtenção do valor comercial desejado dentro do orçamento disponível.

Dica: Por experiência, eu diria que este tipo de contrato combina bem com o Scrum.

O cliente tem controle sobre cada sprint individual. Um relacionamento construtivo significa que, mesmo que os problemas se desenvolvam no caminho, as emoções estão certas em chegar a uma solução mutuamente aceitável.

Contratos ágeis – Desenvolvimento Faseado

agile-contracts-phased-development3Estrutura: Divulgue os lançamentos trimestrais e aprove fundos adicionais após cada lançamento bem-sucedido.

Escopo: Não explicitamente definidas pelo modelo. Lançamentos estão em vigor na caixa de tempo.

O conhecimento de que haverá outro lançamento no próximo trimestre torna mais fácil aceitar o adiamento de um recurso para alcançar a caixa de tempo.

Risco: O risco do cliente é limitado a um trimestre de custos de desenvolvimento.

Relacionamento: Cooperativa. Tanto o cliente quanto o fornecedor têm um incentivo para que cada lançamento seja bem-sucedido, para que o financiamento adicional seja aprovado.

Dica: Os capitalistas de risco geralmente trabalham nessa base. Isso combina bem com tempo e materiais com escopo variável e um teto de custo.

É um trabalho muito prático quando utilizamos este modelo.

Nós simplesmente especificamos a meta de liberação, a taxa horária e o teto de custo no contrato comercial.

O cliente fornece o Product Owner.

Todo o resto é determinado nos contratos de sprint.

Contratos ágeis – Cláusulas de bônus / penalidade

agile-contracts-bonus-penalti3Estrutura: O fornecedor recebe um bônus se o projeto for concluído antecipadamente e pagar uma multa se chegar atrasado. A quantia de bônus ou penalidade é uma função do atraso

Escopo: Difíceis de aceitar, porque as mudanças potencialmente impactam a data de entrega, o que certamente não é permitido.

Risco: O cliente tem um incentivo para conclusão antecipada? Os argumentos do ROI devem ser convincentes e transparentes.

Caso contrário, o cliente obtém uma solução mais barata e mais demorada.

Relacionamento: Pode ser cooperativo, mas pode degenerar em indiferença se o cliente realmente não precisar do software até a data acordada.

Dica: Geralmente aplicado a projetos de construção, por exemplo estradas, túneis e pistas, para o qual funciona bem.

Mudanças no escopo não são problema e custos econômicos genuínos levam o cliente a cumprir o prazo também.

Contratos ágeis – Lucro Fixo

agile-contracts-lucro-fixo3Estrutura: Qualquer orçamento de projeto consiste em custos efetivos e lucro. As partes concordam com o lucro antecipadamente, por ex. R$ 100.000. Independentemente de quando o projeto é concluído, o contratado recebe os custos incorridos mais o lucro acordado.

Escopo: O escopo é fixo.

Risco: O risco é compartilhado. Se o projeto termina antes do previsto, o cliente paga menos, mas o fornecedor ainda tem seu lucro.

Se o projeto exceder o orçamento, o cliente paga mais, mas o fornecedor não obtém lucro adicional.

Após a data de entrega prevista, o fornecedor não poderá faturar mais nenhum lucro, apenas cobrir seus custos.

Relacionamento: Cooperativa – ambos têm um claro incentivo para terminar antes.

O cliente economiza dinheiro e o fornecedor tem uma margem de lucro maior.

Contratos ágeis – Dinheiro para nada, mudanças de graça

agile-contracts-money-nothing3Estrutura: Isso funciona com projetos de software ágil porque há pouco ou nenhum trabalho em andamento.

Após cada sprint, a funcionalidade está completa ou não iniciada. O trabalho baseia-se basicamente em uma base de tempo e materiais com uma meta de custo, geralmente com a intenção de que o projeto não use todo o orçamento do projeto.

Depois que uma certa quantidade de funcionalidade foi entregue, o cliente deve perceber que o valor de negócio suficiente foi percebido que o desenvolvimento adicional não é necessário e, portanto, pode cancelar o projeto.

Uma taxa de cancelamento igual ao lucro remanescente é devida.

Escopo: Pode ser alterado.

Recursos planejados, mas não implementados, podem ser substituídos por outras histórias do mesmo tamanho.

Recursos adicionais custam extra.

Risco: Compartilhado. Ambas as partes têm interesse em concluir o projeto cedo.

O cliente tem custos mais baixos, o fornecedor tem uma margem maior.

Dica: Se o orçamento for excedido, as regras dos contratos de teto fixo de custo ou custo fixo podem ser aplicadas. A abordagem de lucro fixo é mais consistente com o objetivo de promover um relacionamento cooperativo.

Contratos ágeis – Empreendimentos conjuntos/Joint Ventures

agile-contracts-joint-ventures3Estrutura: Dois parceiros investem em um produto de interesse comum.

É improvável que o dinheiro flua diretamente entre os parceiros na fase de desenvolvimento, mas cada parte deve ter um ROI, que pode vir da divisão de receita ou apenas se beneficia do uso do software.

Escopo: Definido para atender às necessidades da parceria.

Risco: Dois de tudo. Cadeias de decisão podem ficar longas.

Rivalidades podem se desenvolver entre as equipes.

Modelos diferentes para extrair valor do produto podem levar a diferentes prioridades que diferem pela vontade de investir.

Dica: Trate o projeto como uma empresa separada: uma equipe, colocalizada, com desenvolvimento e marketing de produto / papel do proprietário do produto.

Pense de maneira realista sobre cenários de separação amigáveis ​​e não tão amigáveis.

Conclusão

Um contrato estabelece as bases importantes para um projeto bem-sucedido. E o Manifesto Ágil acertou: trabalhar com o cliente é mais importante que o contrato.

Então faça o que fizer, mantenha o relacionamento com o cliente positivo!

Leitura adicional Jeff Sutherland – Money for nothing3. Um projeto de contrato está sendo desenvolvido pelo Agile Project Group, iniciado por Gerry Kirk.

Criando boas metas de Sprint

Se temos um Sprint Backlog, essencialmente o plano para o Sprint, por que precisamos de uma meta da Sprint? 

Essa é a pergunta que recebo várias e várias vezes em treinamentos e no trabalho. Lembre-se de que o desenvolvimento de software é complexo e não podemos planejar perfeitamente o desconhecido. Quando criamos o Sprint Backlog, existe a expectativa de que mais trabalho surja durante a Sprint. O escopo pode precisar ser renegociado. A Meta Sprint ajuda a focar em um objetivo que queremos alcançar e permite a flexibilidade para negociar o trabalho para atingir esse objetivo.

Criar um objetivo claro da Sprint pode ser um desafio para os times Scrum. Aqui estão quatro problemas comuns com as metas da Sprint e algumas dicas para melhorá-las.

1 – A Meta da Sprint é muito grande.

Meta da sprint é grande

 

Quando temos metas de Sprint compostas (por exemplo, atingir X e Y e Z), estamos- dividindo o foco e não permitindo muita flexibilidade.- – Aqui estão algumas razões pelas quais acabamos nessa situação e sugestões de como pensar de maneira diferente.

  • Estamos trabalhando em vários projetos ou iniciativas não relacionadas. – Quando estamos ordenando o Product Backlog e fazendo o Sprint Planning, considere tanto a coesão do trabalho quanto a iniciativa de prioridade máxima (singular).- Quando colocamos muito em uma Sprint, estamos nos preparando para o fracasso. Acabamos com o desperdício devido í  mudança de contexto e pouco espaço para o trabalho emergir í  medida que aprendemos.- Se parecer impossível escolher um, talvez nossas Sprints sejam muito longas e não ofereçam ao negí³cio a oportunidade de mudar o foco e a direção com a frequência suficiente.
  • Tentamos abranger todos os itens do Product Backlog (PBI).- Quando dou cursos de Scrum, muitas vezes ouço que as equipes consideram sua Meta da Sprint como “completar todos os PBIs”. Isso é o equivalente a não ter uma meta da sprint. Isso parece um pouco preguiçoso.- Sim, chegar a bons objetivos de sprint é difícil.- Aproveite o tempo para fazê-lo.
  • Achamos que a equipe pode não trabalhar tanto se o desafio não for grande o suficiente.- Esse sentimento me lembra um pouco de comando e controle.- Para que equipes auto organizadas- e capacitadas sejam eficazes, devemos acreditar que as pessoas estão comprometidas em fazer o melhor.- Se a meta da Sprint for atingida antes do final da Sprint, os profissionais descobrirão o que mais podem fazer para contribuir de maneira significativa. Isso pode significar entregar mais funcionalidade.- Isso pode significar trabalhar em itens de melhoria contínua.- Confie neles para descobrir.

2 – O objetivo da Sprint é vago.

 

Quando chegamos ao final de um Sprint, toda a equipe está de acordo se o objetivo da Sprint foi ou não alcançado? Caso contrário, o objetivo da Sprint pode ser muito vago. Aqui estão algumas dicas para criar metas de sprint mais claras.

  • Durante o planejamento da Sprint, pergunte “como saberemos se alcançamos a meta da Sprint?” – Se tivermos respostas diferentes ou olhares confusos do Product Owner ou de qualquer membro da equipe de desenvolvimento, precisamos de mais discussão e refinamento da Meta da Sprin.
  • Torne o Objetivo da Sprint mensurável. – Isso ajuda a reduzir a subjetividade, ou opinião.
  • Durante o Planejamento do Sprint, use uma técnica de consenso para- confirmar a compreensão e o comprometimento de todos com o Objetivo da Sprint.- Essa também é uma maneira de ajudar a- incentivar a propriedade da equipe- .

Aqui estío alguns exemplos de objetivos de sprint pouco claros e modificações para torná-los mais claros.

Objetivo de sprint pouco claro Objetivo de Sprint mais claro
Melhore a funcionalidade do carrinho de compras. Simplifique o processo de compra para permitir um aumento nas taxas de conversão.
Melhorar o desempenho. Aumente o tempo de carregamento da página em 10%.
Novo segmento de mercado a bordo. Permita que um novo segmento de mercado adquira o Serviço Y.

3 – A equipe não presta atenção ao objetivo do Sprint durante o Sprint.

Distração na sprint

 

Lembre-se de que temos que realmente prestar atenção a ele para ajudar a fornecer foco.

  • Torne-o visível.
    Escreva a Meta da Sprint no Scrum Board ou prí³ximo dele. Faça-o grande.
    – Use uma cor ou borda que se destaque.
  • Ensine a equipe a- falar sobre o progresso em direção a Meta da Sprint na Reunião Diária.
    – Os membros da equipe de desenvolvimento geralmente fornecem atualizações sobre os itens do backlog do produto em que estão trabalhando, e o objetivo do Sprint nunca é discutido.
    – Faça parte do Daily Scrum.
    – O facilitador pode perguntar í  equipe no final da Reunião Diária como eles se sentem sobre a probabilidade de atingir a Meta da Sprint, se são necessários ajustes no plano diário para reorientar ou se o escopo precisa ser negociado.
    – Isso pode ajudar a melhorar a colaboração da equipe .
  • Faça da Meta da Sprint uma medida de equipe e mantenha-a visível no espaço da equipe.
    – Semelhante à  forma como uma equipe pode rastrear sua velocidade ou cobertura de teste automatizado ao longo do tempo, uma equipe também pode rastrear a conquista da meta do Sprint ao longo do tempo.
    – Manter essas informações visíveis ajuda a equipe a pensar sobre elas.
    – Dados históricos e tendências podem ser usados  para discussão na Sprint Retrospective.
  • Uma palavra de cautela: atingir uma meta de Sprint é passar/falhar.
    – Não existe 85% alcançado.

4 – A Meta da Sprint não parece significativa.

Uma meta de sprint deve fornecer propí³sito.- Isso ajuda a equipe a saber por que eles estão construindo o incremento.- As pessoas querem fazer um trabalho significativo.- As pessoas querem fazer um trabalho que tenha impacto.- Este é um driver para a- motivação intrínseca.- Vamos pensar em maneiras de tornar as metas da Sprint mais significativas para as pessoas que estão construindo o produto.

  • Torne-a focada no negí³cio ou no usuário quando possível. – O que um usuário poderá fazer quando implementarmos esse recurso?- O que uma área de negí³cio poderá alcançar quando implementarmos uma melhoria?
  • Concentre-se em testar suposições de negí³cios e obter feedback.- Muitas vezes não sabemos o que os usuários realmente precisam ou estão dispostos a fazer (porque nem os usuários sabem).
    – Um Product Owner precisa de feedback antecipado para testar suposições sobre valor para os usuários.
  • Torná-la focada na redução do risco.- Provar uma tecnologia ou design é uma parte importante da redução de riscos.- Se soubermos que uma tecnologia não vai atender í s nossas necessidades de desempenho, segurança ou escalabilidade, podemos mudar de direção.- Quanto mais cedo mudarmos de direção, mais barato será o custo da mudança.
Em resumo, uma boa Meta da Sprint pode ajudar uma equipe a se concentrar e ter a flexibilidade de criar um Incremento Feito ao final de uma Sprint.
Uma boa Meta da Sprint ajuda uma equipe a entender o propósito e o impacto do trabalho que está fazendo, o que é um fator determinante para a motivação intrínseca. Roman Pichler fornece um modelo útil- para criar metas de sprint eficazes– .

Se você acha que um desses problemas está afetando sua equipe, escolha uma técnica e experimente, entre em contato e comente aqui!

Planejamento de sprints de trás para a frente?

Sprints, aqui está o problema: muitas equipes planejam suas sprints completamente de trás pra frente. Isso não é totalmente inesperado.

Guia do Scrum é bastante escasso quando se trata do tópico de criar a meta para as sprints, basicamente afirmando que o objetivo da sprint é a meta do sprint, e serve para informar, inspirar e orientar a equipe com relação ao que mesmo explicando por que a equipe está trabalhando no produto.

No entanto, tudo isso parece um pouco autorreferencial – a meta é o que eles estão trabalhando e o que a equipe está trabalhando os traz para o objetivo? – Isso não parece fornecer muita orientação para a equipe.

Não é de surpreender que muitas equipes consigam atingir seus objetivos de maneira ascendente. A equipe examina o que está no topo da lista de pendências, com talvez um pouco de acréscimo do Product Owner e de outras partes interessadas, e estabelece o objetivo ao compilar as histórias e tarefas adicionadas ao sprint.

Para um exemplo simples, imagine que eu quero estar preparado para uma festa que estou organizando hoje à noite. Meu backlog pessoal pode conter tarefas como:

  1. Pegar gelo;
  2. Fazer lanches;
  3. Selecionar músicas; e
  4. Aspirar o tapete.

Acrescento essas quatro tarefas à minha lista diária e decido que meu objetivo é pegar gelo e comida, limpar a casa e escolher algumas músicas.

Fácil de entender e parece muito com uma lista de tarefas simples. E, no entanto, eu posso fazer todas essas coisas e ainda não estar pronto para a festa.

É assim que parece um objetivo de baixo para cima – uma lista de tarefas que, se concluídas, significa que podemos verificar tudo e encerrar o dia – Isso é inútil quando se trata de saber se você está fazendo as coisas corretas; não é uma maneira eficaz de inspirar uma equipe; e não oferece muita flexibilidade caso a situação mude ou novas informações sejam descobertas.

Essas são as razões pelas quais a missão para os sprints devem ser criada de cima para baixo – determinando como seria uma iteração bem-sucedida (“Estou preparado para a festa”), e não como a agregação das tarefas envolvidas.

Deve incluir todos os itens que já são conhecidos e vários que não são. Vejamos como uma equipe pode fazer um melhor objetivo de sprint.

Primeiro, ignore a lista de pendências

Quando a equipe inicia a sessão de planejamento, é tentador simplesmente abrir a lista de pendências, ver quais histórias estão no topo e perguntar ao proprietário do produto se essas histórias ainda são importantes.

Se o Product Owner e o Scrum Master tiverem realizado seu trabalho corretamente, um backlog bem preparado terá os itens mais críticos no topo e estarão prontos para desenvolvimento com requisitos e definições  de pronto claramente definidos.

Pegando as principais tarefas

Em seguida, é um exercício simples arrastar as principais histórias para o sprint, até que a capacidade seja esgotada e concluir o planejamento.

De fato, dada uma ferramenta sólida o suficiente e com uma lista de pendências mantida em boa forma, esse método de planejamento pode ser feito sem uma reunião ou mesmo sem a interação humana. O que também seria completamente errado.

É assim que o planejamento de baixo para cima opera; a equipe “descobre” a meta observando as tarefas que estão prestes a serem concluídas.

Embora isso atenda a todos os critérios de planejamento e, de fato, crie um sprint devidamente formado e cheio de trabalho, não criará um objetivo ou direção para a equipe.

Para usar outro exemplo simples, uma decisão que a maioria das pessoas toma diariamente é decidir o que elas querem comer no jantar.

Às vezes, o método para fazer essa determinação envolve abrir os armários, ver o que está armazenado lá e decidir o que eles querem é uma tigela de sopa, ou as sobras da noite passada.

Certamente, isso servirá ao propósito de deixar a pessoa com menos fome, e pode até ser satisfatória o suficiente, estará longe do que eles “queriam” para o jantar.

Da mesma forma, o objetivo dos sprints devem ser algo que motive a equipe, dê um objetivo à equipe e ajude com as milhares de micro decisões que precisam ser tomadas ao longo do sprint.

Foco nos resultados

Em vez de prestar atenção no que itens individuais precisam ser feitos, a equipe deve se concentrar no resultado que espera obter do sprint.

Essa seria a abordagem de cima para baixo para criar uma meta, prestando atenção ao que a equipe está tentando realizar.

Em nosso exemplo, isso seria garantir que eles estejam preparados para a festa ou que tenham uma refeição satisfatória; em um exemplo real, serão coisas como garantir que um cliente possa entrar em um site, fazer um pedido ou entrar em contato com o atendimento ao cliente para obter suporte.

Com esse objetivo em mente, a equipe pode decidir quais histórias e tarefas serão necessárias para alcançar esse resultado e adicioná-las aos sprints.

A importância das histórias e o que adiar nas sprints

Histórias importantes, mas que não ajudam a atingir o objetivo do sprint atual, podem ser adiadas por enquanto.

À medida que o sprint progride, novas tarefas, cenários e até obstáculos surgirão e precisarão ser trabalhados.

Isso não é incomum; a adição de tarefas (embora geralmente não sejam histórias) ao sprint atual acontece com frequência e pode até ser representada em um gráfico de detalhamento padrão.

Com a compreensão de qual é o objetivo do sprint, adicionar coisas que ajudem a alcançar os critérios de saída pode ser comunicado de uma maneira que faça sentido para todos.

Também ajuda a agir como uma barreira para adicionar coisas que não parecem relevantes ou urgentes.

Certamente, itens de missão crítica e coisas necessárias para manter as luzes acesas entrarão na fila, mas isso ajuda a definir um nível alto para o quão difícil deve ser a inserção de novos trabalhos nos sprints depois de ter sido concluído e planejado considerando o objetivo principal do sprint,

Prever como atingir a meta das Sprints

Depois que o objetivo do sprint é determinado, a próxima tarefa é descobrir como alcançá-lo. Um mecanismo para fazer isso é pensar no que a equipe gostaria de apresentar no final das sprints em uma demonstração.

Ao determinar o que deve estar funcionando, o que deve estar visível e como isso será mostrado, pode ajudar a esclarecer quais tarefas precisam ser trabalhadas.

A equipe pode trabalhar de trás para frente a partir dessa descrição para ajudar a identificar o que não precisa ser desenvolvido imediatamente, especialmente se puder ser mostrado de uma maneira alternativa.

Vi demonstrações em que, depois de inserir alguns dados em um formulário da web, a próxima parte da apresentação foi a saída de uma consulta SQL escrita em um editor de banco de dados.

Não é bonito, mas prova suficiente de que a capacidade estava funcionando.

Parte disso envolve uma boa fatia vertical, mas o objetivo real é fornecer uma visão do que a equipe precisa fazer. A lista de trabalhos que precisam ser concluídos – como feito, feito, feito – deve ficar claro na mente de todos.

Separando o joio do trigo

Desde o final da reunião de planejamento até a extensão completa do sprint, a equipe deve ter uma imagem mental de exibição de seu trabalho e saber como o que eles estão trabalhando ajudará a alcançar esse objetivo.

Se um desenvolvedor se encontrar trabalhando em algo que não considera que impeça a apresentação do recurso, esse trabalho deverá ser deixado de lado para se concentrar ainda mais nos principais componentes do recurso.

Afinal, um bom objetivo do sprint ajuda a inspirar a equipe, dando-lhes algo para visualizar, além de conectar o trabalho que está sendo concluído ao resultado desejado.

Ele deve ser usado tanto taticamente, na determinação da lista de histórias que a integram quanto na estratégia, motivando a equipe para a conclusão.

Decida como medir suas Sprints

Uma vez que a última parte a descobrir é como a meta será avaliada e, em particular, o que a equipe deve acompanhar para determinar o sucesso.

Entretanto, o resultado de um sprint é redigido no tempo futuro, como em que funcionalidade estará disponível no final.

Pode ser que um cliente possa efetuar login ou fazer um pedido, mas o termo operacional é que ele é capaz de fazê-lo, e não o que realmente faz.

Em geral, a equipe de desenvolvimento não é responsável por gerar interesse ou demanda por um recurso ou produto; é mais seu objetivo disponibilizar recursos e produtos.

No entanto, isso não impede a equipe de desenvolvimento de apresentar métricas de sucesso para o que está construindo.

Deixe a equipe decidir

Dependendo do recurso, a equipe pode decidir que, dentro de uma semana após o lançamento, pelo menos uma pessoa utilizará a função em um ambiente de produção.

Contanto que o próprio Product Owner o faça, isso será fácil de conseguir.

Se houver uma melhoria em algo existente, a equipe poderá observar taxas de sucesso, desempenho ou alguma medida existente, e dizer que dentro de um certo período de tempo, isso mudará para melhor.

O que fazer com sprints de trás para frente

Também é útil fazer as duas coisas:

  1. Dizer que dentro de uma semana, um certo número de pessoas usará um recurso com sucesso e,
  2. Dentro de um mês, um número ainda maior o usará.

Pode ser uma combinação de tipos diferentes, medindo o uso e o desempenho, de modo que um número de clientes use o recurso e ele tenha características de desempenho.

Qualquer que seja o pensamento por trás da métrica, o objetivo principal é pensar em primeiro lugar.

Concluindo

Em suma, definir uma meta ajuda a criar uma visão sobre o que a equipe está trabalhando, definindo a métrica ainda mais na mente da equipe de desenvolvimento.

Ambos são extremamente importantes.

Então para criar uma meta de sprint de cima para baixo não é apenas uma parte necessária do processo, pode ser a parte mais importante.

Em conformidade a essa criação que ajuda a orientar tudo, desde a decisão do que fazer nos sprints, até o que precisa ser adicionado e o que não é necessário, e permite que as pessoas se concentrem no que será demonstrado quando tudo terminar.

Em suma, ao iniciar uma sessão de planejamento, decidindo o que você está tentando realizar, levará a um resultado melhor para todos.

Daily Meeting

Daily Meeting: qual é a Anatomia da Daily?

As daily meetings ou  stand-up tornaram-se um ritual comum de muitas equipes, especialmente no desenvolvimento de software Ágil. No entanto, existem muitos detalhes sutis que distinguem os stand-ups efetivos de uma perda de tempo.

Daily Meeting: Ficar de pé para manter uma reunião curta

A reunião diária stand-up (também conhecida como “daily scrum”, “daily huddle”, “morning roll-call”, etc.) é simples de descrever:

Toda a equipe se encontra todos os dias para uma rápida atualização de status. Nós nos levantamos para manter a reunião curta.

É isso aí, li o Scrum Guide e já sei fazer essa reunião. #SQN

Mas esta curta definição não lhe diz realmente os detalhes sutis que distinguem um stand-up efetivo de uma perda de tempo.

Então, como posso te explicar?

Para praticantes experientes, quando as coisas dão errado com o stand-up, eles vão saber instintivamente o que ajustar para corrigir a situação.

Para os novatos, quando as coisas dão errado, é muito menos provável que eles descubram o que fazer … e é muito mais provável que, sem assistência, eles simplesmente abandonem completamente a prática.

Isso seria uma pena, já que stand-ups bem administrados adicionam valor significativo às equipes.

Para lidar com isso, é importante explicitar os benefícios e as consequências de práticas comuns para os levantamentos diários. Esses padrões de reuniões diárias podem ajudar os praticantes menos experientes, bem como lembrar os praticantes mais experientes das razões por trás de sua intuição.

O que pode ser “bom”?

Vamos com uma pequena historinha:

O “Get Up Stand Up” de Bob Marley começa… agindo como um sino pavloviano quando a equipe se levanta para passear na frente da parede de cartões sem qualquer aviso adicional.

Essa música em particular faz parte de uma rotação programada que toca na mesma hora da manhã, todos os dias.

Algumas pessoas estão movendo cartões para seus pontos corretos no fluxo de trabalho, incluindo a afixação de Post-Its coloridos diferentes com notas adicionais. Algumas pessoas interessadas fora da equipe direta do projeto também perambularam para ver como as coisas progrediram.

Percebendo que a atividade na parede parou, o líder da equipe inicia um cronômetro grande que a equipe havia comprado anteriormente; Eles estavam interessados ​​em quanto tempo a reunião diária de stand-up realmente levaria.

Um dos membros da equipe se aproxima para falar sobre o cartão na parte mais à direita do quadro, mais próximo do ponto de implantação. Ele ainda está tendo alguns problemas com o script de implantação. Outro membro da equipe sugere que ela pode ajudar a resolver isso. A sequência continua da direita para a esquerda, de cima para baixo, pessoas descrevendo o que está acontecendo com cada um dos itens de trabalho e outras entrando em contato se puderem ajudar a resolver obstáculos. Do outro lado, o líder da equipe está registrando os obstáculos levantados no quadro de melhorias.

Em um ponto, há uma discussão um pouco mais longa que explora como lidar com um problema específico. Percebendo que vão se estender, o líder da equipe sutilmente levanta um dedo para interromper … pouco antes de uma das pessoas sugerir que eles devam falar sobre isso depois da reunião.

Pouco tempo depois, todos os cartões são cobertos e o líder da equipe pergunta se alguém tem mais alguma coisa para compartilhar. Alguém aponta uma ideia interessante que ela tinha sobre um novo recurso que tornaria obsoleto algo do que foi planejado. Isso desperta o interesse do Product Owner que sempre tenta comparecer aos stand-ups e ambos concordam em falar sobre isso depois.

O líder da equipe então revira os olhos enquanto a equipe inicia a tradicional cerimônia de encerramento “… 1 … 2 … 3 … Excelsior!” Não é coisa dele, mas ele teve que admitir, a reunião termina com uma nota alta.

As pessoas se separam e começam a discutir várias coisas que foram levantadas, incluindo os obstáculos, as novas ideias e perguntas sobre determinados itens de trabalho.

O conjunto particular de problemas que ocorrem quando as pessoas tentam trabalhar juntas

Reuniões em stand-up diárias são uma solução recorrente para um conjunto particular de problemas que ocorrem quando um grupo de pessoas tenta trabalhar em equipe.

Os stand-ups são um mecanismo para sincronizar regularmente para que as equipes …

  • Compartilhem a compreensão dos objetivos. Mesmo se pensássemos que nos entendíamos no começo (o que provavelmente não), nossa compreensão se desvia, assim como o contexto em que estamos operando. Uma “equipe” em que cada membro da equipe está trabalhando em direção a objetivos diferentes tende a ser ineficaz.
  • Coordenem os esforços. Se o trabalho não precisa ser coordenado, você não precisa de uma equipe. Por outro lado, se você tem uma equipe, eu assumo que o trabalho requer coordenação. A falta de coordenação entre os membros da equipe tende a levar a resultados ruins.
  • Compartilhem problemas e melhorias. Um dos principais benefícios de uma equipe versus trabalhar sozinho é que os membros da equipe podem ajudar uns aos outros quando alguém encontra um problema ou descobre uma maneira melhor de fazer algo. Uma “equipe” em que os membros da equipe não se sentem à vontade para compartilhar problemas e / ou não se ajudam mutuamente tende a ser ineficaz.
  • Identifiquem-se como uma equipe. É muito difícil se identificar psicologicamente com um grupo se você não se envolver regularmente com o grupo. Você não desenvolverá um forte senso de parentesco mesmo se acreditar que eles são capazes e que perseguem os mesmos objetivos.

Padrões de reuniões diárias de stand-up

Eu organizei os padrões para responder às seguintes perguntas:

  1. Quem atende?
  2. Sobre o que falamos?
  3. Em que ordem falamos?
  4. Onde e quando?
  5. Como podemos manter o nível de energia?
  6. Como incentivamos a autonomia?

Quem atende?🙋‍♀️🙋‍♂️🙋

Todos

Pessoas e representantes de várias áreas (por exemplo, marketing, apoio à produção, alta gerência, treinamento, etc.) desejam conhecer e / ou contribuir para o status e o progresso do projeto. A comunicação do status em várias reuniões e relatórios requer muito esforço duplicado.

Assim sendo

Substitua algumas ou todas as reuniões e relatórios pelo stand-up diário. Qualquer pessoa que esteja diretamente envolvida ou queira saber sobre o funcionamento diário do projeto deve participar da única reunião diária em pé.

Mas

As pessoas não envolvidas diretamente podem interromper o stand-up se não estiverem claras sobre o comportamento esperado. Isso pode ser resolvido simplesmente informando novos participantes e observadores das normas esperadas de antemão.

Nem todas as formas de relatórios serão, nem devem, ser cobertas pelo formato de stand-up. Por exemplo, o progresso geral do projeto seria melhor comunicado com um Gráfico grande e visível, como burn-up, diagrama de fluxo cumulativo, etc.

Itens de trabalho atendidos

Também conhecido como: stand-up com foco na história

se as histórias são tão importantes para o projeto, elas deveriam ser aquelas falando no standup – Brian Marick, “Latour 3: Anthrax e standups1

As pessoas estão muito concentradas nos corredores, não no bastão . Ou seja, todo mundo está ocupado, mas não necessariamente progredindo nos itens de trabalho.

Assim sendo

Em vez de pensar no stand-up diário como um ritual para as pessoas, pense nele como um ritual onde os Itens de Trabalho são atendidos (por exemplo, Histórias de Usuários em um contexto Ágil) e as pessoas só atendem para falar sobre itens de trabalho. Afinal, os itens de trabalho não podem realmente falar.

As perguntas dos Obstáculos de Ontem e de Hoje ainda podem ser usadas, mas serão da perspectiva do item de trabalho, e não da pessoa. Isso também significa que nem toda pessoa pode falar. Não há senso de obrigação de dizer qualquer coisa que não seja relevante para progredir no trabalho.

Por causa do foco mais claro, é mais provável que as pessoas aumentem e comecem a se levantar para remover os obstáculos sem avisar.

Mas

A falta de obrigação de falar pode esconder problemas com pessoas que são tímidas ou que não estão inclinadas a dizer qualquer coisa. Isso é mais difícil de detectar com um foco de item de trabalho.

Sobre o que falamos?🟢

Ontem, Hoje e Obstáculos

Também conhecido como: três perguntas

Algumas pessoas são falantes e tendem a se perder em Story Telling . Algumas pessoas querem se envolver na Solução de Problemas imediatamente após ouvir um problema. Reuniões que demoram muito tendem a ter pouca energia e os participantes não diretamente relacionados a uma longa discussão tendem a se distrair.

Assim sendo

Estruture as contribuições usando o seguinte formato:

  1. O que eu fiz ontem?
  2. O que farei hoje?
  3. Quais obstáculos estão impedindo meu progresso?

Este é o número mínimo de perguntas que satisfazem os objetivos dos stand-ups diários. Outros tópicos de discussão (por exemplo, discussões de design, fofocas, etc.) devem ser adiados até depois da reunião.

Olve Maudal2 sugeriu que as perguntas fossem invertidas para enfatizar a ordem correta de importância:

  1. Quais os impedimentos no seu caminho?
  2. O que você está trabalhando hoje?
  3. O que você terminou desde ontem?

Lasse Koskela3 propôs outra forma dessas perguntas para enfatizar que os membros da equipe não devem se reportar ao líder:

Cada membro da equipe atualiza seus pares:

Por sua vez, cada membro da equipe fornece a seus colegas 3 informações:

  1. Coisas que fiz desde a reunião de ontem
  2. Coisas que vou fazer hoje
  3. Obstáculos que eu preciso de alguém para remover

Jonathan Rasmussen4 ofereceu uma redação diferente para mudar a dinâmica do stand-up:

  • O que você fez para mudar o mundo ontem
  • Como você vai “esmagar” hoje
  • Como você está indo para atravessar quaisquer obstáculos infelizes o suficiente para estar em seu caminho

Responder a esses tipos de perguntas muda completamente a dinâmica do stand-up. Em vez de apenas ficar lá e dar uma atualização, você está colocando tudo em linha e declarando sua intenção para o universo.

Há também várias equipes que adicionaram perguntas adicionais.

A empresa Buffer5 adicionou uma seção onde as pessoas compartilham algo em que estão trabalhando para melhorar a si mesmas.

Thomas Cagley6 sugere adicionar riscos .

Mark Levison7 achou útil adicionar mais perguntas de melhoria direcionadas.

As duas últimas perguntas seriam alteradas para corresponder ao contexto específico.

  1. O que você completou ontem?
  2. Com o que você se compromete hoje?
  3. Quais são seus impedimentos / obstáculos?
  4. Que código vamos “botar o nariz” / teste de unidade ausente / … você viu ontem?
  5. Que melhoria você fez no código ontem?

Mas

A estrutura não é tão importante quanto as informações fornecidas pelas respostas às perguntas. Se as informações forem fornecidas em um protocolo menos estruturado, não é importante se ater a uma lista de verificação. À medida que as equipes amadurecem, você pode achar que deseja ajustar a estrutura, o que é reflexo de como esse padrão já evoluiu.

A questão mais importante é se os Obstáculos do Ontem de Hoje estão criando um foco muito grande no compromisso pessoal versus prestar atenção nas coisas certas … o que leva ao Walk the Board .

Conselho de Melhorias👌

Também conhecido como: A placa de bloqueio, placa de impedimento, o jornal Kaizen. (sabe aquela equipe de transformação ágil? Então é essa mesmo!)

Obstáculos levantados no stand-up não são removidos ou resolvidos em tempo hábil.

Assim sendo

Postar obstáculos levantados para um Conselho de Melhorias. Este é um quadro branco visível publicamente ou gráfico que identifica obstáculos levantados e controla o progresso de sua resolução.

Um Conselho de Melhorias pode ser atualizado fora de stand-ups e serve como uma maneira mais imediata e talvez menos confrontante de inicialmente levantar obstáculos. Um erro comum é não escrever grande o suficiente para permitir que as pessoas leiam os bloqueios à distância.

O simples ato de escrever um problema e, portanto, reconhecê-lo explicitamente, é uma maneira muito confiável de reduzir conversas prolongadas. Assim, mesmo que nem todos concordem que qualquer item em particular é um obstáculo, vale a pena simplesmente escrevê-lo para discussão após o término da reunião.

Incluindo uma contagem de ocorrências com cada obstáculo aumentado destaca quais questões são geralmente mais importantes para lidar primeiro.

O design da placa pode variar de algumas maneiras. Por exemplo, uma estrutura de tabela como a seguinte:

Problema Contagem Contenção Contramedida Status
Nome do problema Contagem Contínua de Ocorrências Solução a curto prazo Solução de longo prazo baseada na análise de causa raiz A planta faz o ato de verificação

Outro estilo é mais como um quadro de tarefas:

To Do In Progress Done
Cartões de índice representando obstáculos levantados Cartas de obstáculos movem-se aqui quando estamos trabalhando ativamente nelas Cartas de obstáculos se movem aqui quando as resolvemos

Mas

O Conselho de Melhoria corre o risco de se transformar em um conselho de disputa se muitos obstáculos forem levantados sobre ele que a equipe não tem influência na resolução.

Em que ordem falamos?

Quem chega por último fala primeiro

Durante um stand-up, os participantes precisam saber quem deve falar primeiro. Fazer com que o facilitador decida quem deve falar primeiro é uma força sutil, mas definida, contra a auto-organização. A equipe deve saber sem intervenção que fala primeiro.

Assim sendo

Concordamos que a Última pessoa que chegar Fala Primeiro. Esta é uma regra simples que também tem o benefício adicional de incentivar as pessoas a serem pontuais em aparecer para o stand-up.

Contudo

A última pessoa a chegar acaba sendo a pessoa menos preparada para começar bem a reunião.

Round Robin (Rodízio)

Durante um stand-up, os participantes precisam saber quem deve falar em seguida. Ter um facilitador decidir quem fala a seguir é uma força sutil, embora definida, contra a auto-organização. A equipe deve saber sem intervenção que fala em seguida.

Assim sendo

Use uma regra predeterminada simples como um Round Robin para determinar quem deve ir em seguida. Não importa se é no sentido horário ou anti-horário. O que importa é que a equipe conduz a reunião, não o facilitador ou o gerente.

Passe o token🗝️

Com mecanismos de ordenação simples e previsíveis (por exemplo, Rodízio), é muito fácil para os participantes ignorarem outros oradores até que esteja mais próximo do seu turno. Pode haver uma tendência a pensar em outras coisas em vez de prestar atenção ao que os outros estão dizendo.

Assim sendo

Apresente um mecanismo de ordenação imprevisível, como jogar um token de fala (por exemplo, uma bola) para determinar quem deve falar em seguida. Ter um token de fala também simplifica a decisão de quem fala primeiro, pois será a pessoa que por acaso pegou o token (ou a primeira pessoa que jogar o token).

Jogar algo ao redor apresenta um pouco de diversão ao ritual de stand-up diário e, portanto, serve como um bom mecanismo de infecção para outras equipes de observação.

Eu aprendi primeiro sobre esse padrão em um projeto que eu estava onde usamos uma pequena bola de malabarismo, mas quase tudo pode ser usado como símbolo. Outras equipes usaram bolas de rugby8  ou até mesmo brinquedos de pelúcia9 .

Mas

Com equipes maiores, pode ser difícil lembrar quem já falou. Nesses casos, pode ser mais fácil manter mecanismos mais simples, como o Round Robin .

Dependendo da cultura da organização ou mesmo da equipe, jogar uma bola ao redor também pode ser visto como não profissional e criaria uma percepção negativa desnecessária do ritual.

Pegue um cartão🃏

Durante um stand-up, os participantes precisam saber quem deve falar primeiro e depois disso, quem deve falar em seguida. Ter um facilitador decidir quem deve falar é uma força sutil, mas definida, contra a auto-organização. A equipe não está interessada em passar o token, porque eles normalmente têm copos de café nas mãos.

Assim sendo

Peça a cada membro da equipe que pegue um cartão10 para determinar qual ordem falar. Imagine uma pilha de cartas, cada uma com um número. À medida que cada membro da equipe chega à reunião, eles podem selecionar um cartão que, em seguida, diz a eles em que ordem falar.

Walk the Board🏃

Também conhecido como: Walk the Wall

[S]tandups mantêm todos ocupados. [W]alking the board mantém todos focados nas coisas mais importantes.

– Bret Pettichord via Twitter

Outra questão com o formato convencional é que as tarefas ou fluxos de trabalho não são discutidos de forma coerente; em vez disso, cada assunto surge brevemente, dependendo da ordem em que os membros da equipe falam. Isso pode tornar difícil dizer o que realmente está acontecendo11 – Dave Nicolette.

As pessoas estão mais focadas em estar ocupadas do que realmente progredindo no trabalho, então você mudou para um modelo onde Atendem-se os Itens de Trabalho ao invés de pessoas, no entanto, mesmo com este item de trabalho focado em pé, ainda é difícil entender o que está acontecendo e encomendar mecanismos como Rodízio ou Passe o Token .

Assim sendo

Walk the board , ou seja, a estrutura do stand-up que percorre cada item de trabalho exibido em sua placa de gerenciamento visual.

A maioria das equipes Agile e Lean usará um sistema de gerenciamento visual para expor o que está sendo trabalhado. Para o desenvolvimento de software Ágil, isso pode ser chamado de “quadro de tarefas”, “parede da história” ou “quadro Kanban”.

Essas placas apresentarão um processo pelo qual os itens de trabalho serão movidos. O progresso é tipicamente representado por cartões que se movem fisicamente pelo tabuleiro. Idealmente, o posicionamento vertical indicará prioridade.

Com esta placa no lugar, o stand-up se move através de cada item de trabalho do fim do processo para o início do processo (por exemplo, da direita para a esquerda) e da maior para a menor prioridade (por exemplo, de cima para baixo). Você pode até mesmo indicar explicitamente no quadro-negro qual sequência deve ser usada.

Pawel Brodzinski12 propôs uma sequência padrão :

  1. Bloqueadores
  2. Expedir ou itens de emergência
  3. Itens que não foram movidos desde o último standup (provavelmente emperrados)
  4. Tudo que houver mais por prioridade

Mas

Obviamente, ter uma placa (lousa, quadro branco, parede de histórias)é um pré-requisito que nem todas as equipes terão. Nesse caso, uma estrutura pessoa por pessoa é mais apropriada.

Walk the Board tem uma tendência muito maior a sucumbir ao Reporte ao Líder se o Rotate the Facilitator ou algum outro padrão de auto-organização não for aplicado.

Onde e quando?

Conheça onde o trabalho acontece

Faça a reunião no gemba, não uma sala de conferências. – Marc Graban13

O local de trabalho tem muitos gatilhos de memória sobre o que está acontecendo.

Também não queremos que a reunião diária exija muita coordenação, localização e caminhada nas salas.

Assim sendo

Conheça onde o trabalho acontece , não em uma sala de reunião. Se você tem uma “parede de história” ou “quadro Kanban”, encontre-se em frente a isso.

Mas

Outras pessoas próximas podem achar o barulho da reunião perturbador. Isso normalmente indica um design de espaço de trabalho subjacente ruim, mas ainda deve ser reconhecido.

Mesmo Bat-Canal, Mesma Bat-Hora🦇

Queremos que a equipe tenha um senso de propriedade do stand-up. Também queremos que as partes interessadas possam aparecer para observar um stand-up para evitar a necessidade de agendar outra reunião de status. Isso é difícil se qualquer membro específico da equipe puder forçar um atraso ou uma mudança de local do stand-up.

Assim sendo

Faça com que a equipe concorde e execute o stand-up diário no mesmo local, na mesma hora . Não espere por retardatários, incluindo arquitetos e gerentes. A reunião é para toda a equipe, não para qualquer indivíduo em particular. Isto é especialmente importante se você usar o Stand-up para começar o dia .

Algumas equipes mais rigorosas podem impor uma “multa” aos retardatários. Eu tenho a tendência de desconfiar de qualquer tipo de mecanismo de punição e prefiro discutir.

Mas

Mesmo Lugar, Mesmo Tempo não se destina a ser cegamente inflexível. O importante é que a hora de início seja mais consistente e o reescalonamento seja raro. Se o reagendamento for solicitado com frequência, pode ser uma indicação de que o horário de início deve mudar. Se um local específico é inconveniente para todos, provavelmente é uma indicação de que o local deve mudar.

Use o Stand-up para começar o dia

A reunião diária stand-up fornece foco e consciência de questões pendentes. Se ocorrer no final do dia, esse foco e consciência são desperdiçados.

Assim sendo

Use o Stand-up para começar o dia . Com horários de trabalho flexíveis, nem todos os membros da equipe chegam ao trabalho ao mesmo tempo. Uma prática comum com “flex-time” é usar um conjunto de horas de trabalho básicas.

O horário de início deve estar no início dessas horas de trabalho principais. Da mesma forma, se os membros da equipe precisarem chegar mais tarde por motivos pessoais (por exemplo, precisar deixar as crianças na escola), a hora de início deve ser definida para que todos possam comparecer.

Mas

Pode haver uma tendência para não trabalhar em qualquer tarefa relacionada ao projeto até o stand-up. Se a reunião stand-up começar o dia … Mais tarde, esse tempo de folga pode ser significativo.

Até certo ponto, isso pode simplesmente ser usado como uma oportunidade para verificar e-mails, preencher planilhas de horas, etc., mas pode valer a pena investigar a remoção do stand-up como um ritual de “início do dia”, agendando-o no final do dia. .

Não use o stand-up para começar o dia

O stand-up tende a servir como o ritual para definir o foco do dia, especialmente se você usar o stand-up para começar o dia . Por causa disso, os membros da equipe tendem a não trabalhar em recursos até o stand-up.

Quando a reunião não é realmente realizada em primeiro lugar, essa tendência pode ter um impacto significativo na produtividade.

Assim sendo

Não use o stand-up para começar o dia . Programe a reunião diária até o dia em que ela não estará psicologicamente associada ao início do dia.

Mas

Se a reunião diária não começar o dia, ela não poderá mais ser usada como um ritual compartilhado para definir o foco da equipe no início do dia. Dependendo da equipe, esse preço pode não valer o aparente aumento de eficiência.

Quando há muitos projetos usando stand-ups, é possível que vários stand-ups estejam ocorrendo simultaneamente. Observadores interessados ​​em múltiplos projetos podem querer mudar os tempos de stand-up para permitir que eles possam participar.

Isso é problemático, pois arrisca o senso de propriedade da equipe se um observador forçar um stand-up a se ajustar à sua agenda. No entanto, isso também deve ser uma consideração ao decidir quando ter o stand-up diário.

Como podemos manter o nível de energia?

Amontoado 👥

O problema que eu frequentemente vejo surgir é que as pessoas tendem a tratar o Daily Stand-up como simplesmente reportagem individual. “Eu fiz isso . . . Eu farei isso – então, para a próxima pessoa. A abordagem mais otimista está mais próxima de um amontoado de futebol. – Jeff Sutherland14

O volume de fala afeta a atenção, bem como a eficácia da comunicação. A distância física altera o nível de volume necessário para se comunicar bem. Algumas pessoas não falam alto e não se sentem à vontade tentando.

Assim sendo

O stand-up deve ser mais de um Huddle do que uma reunião. Se é difícil ouvir, aproxime todos. Além de permitir um volume de fala mais descontraído, estar fisicamente mais próximo tende a fazer com que os participantes fiquem mais atentos por conta própria.

Ser capaz de ficar fisicamente mais próximo também é uma expressão de maior confiança dentro da equipe. Se o stand-up é uma coisa nova, geralmente é o suficiente para usar gestos de mão para acenar para as pessoas e dizer algo para o efeito de “Vamos trazê-lo”.

Agora se o tamanho do círculo tiver sido estabelecido por algum tempo, pense em explicar as razões para fechar o círculo antes de tentar reduzi-lo.

Mas

A equipe deve equilibrar a proximidade com as zonas de conforto pessoal. Mesmo em uma equipe muito confiante, há um ponto em que as pessoas estão apenas perto demais para o conforto. Os sintomas tendem a ser participantes tensos e / ou inquietos.

Stand Up🧍‍♂️

Algumas pessoas são falantes e tendem a se perder em Story Telling . Algumas pessoas querem se envolver na Solução de Problemas imediatamente após ouvir um problema.

Reuniões que demoram muito tendem a ter baixa energia e os participantes não diretamente relacionados a uma longa discussão tendem a se distrair.

Assim sendo

Peça a todos os participantes que se levantem durante a reunião. Ficar de pé faz uma ligação física com a prontidão mental. O desconforto físico também lembrará os participantes quando uma reunião estiver demorando demais.

Sobretudo uma maneira simples de encorajar isso é simplesmente realizar a reunião onde não há cadeiras.

Mas

Levantar-se tende a fazer com que as reuniões diminuam, mas não garante que elas encurtarão para uma duração ideal. As pessoas podem aprender a lidar com o desconforto em vez de tomar uma resposta mais apropriada.

Além disso, se as reuniões não estão demorando muito, nem se afastando do assunto, ficar de pé é um ritual desnecessário.

Quinze minutos ou menos

A maioria das pessoas vai vagar mentalmente quando estão em longas reuniões. Um longo e monótono encontro é uma maneira horrível e desgastante de começar o dia.

Portanto um número específico ajuda a lembrar-nos quando considerar o ajuste para reduzir o tempo da reunião.

Entretanto

Mantenha os stand-ups diários para quinze minutos ou menos . Como regra geral, depois de quinze minutos, a mente da pessoa média vai vagar, o que não ajuda a manter o foco.

Mas

Quinze minutos podem ser longos demais para equipes menores. Por causa do efeito “Dory” (vaguear pela mente e se esquecer da busca ao Nemo), mesmo para equipes maiores, quinze minutos é um bom limite.

Além disso, também é possível ter uma reunião que é muito curta, e no final, os participantes ainda não terem ideia do que está acontecendo ou com quem conversar para descobrir.

Sinalizar o Fim🔴

Depois que a última pessoa tiver falado, a equipe pode não perceber imediatamente que a reunião acabou. A percepção gradual de que é hora de ir embora não encerra a reunião com uma nota alta e pode contribuir para a Baixa Energia.

Assim sendo

Sinalize o fim do stand-up com uma frase descartável15 (por exemplo, “Bem, aproveitem seu café/almoço”, “3…2…1….Excelsior!” ) ou alguma outra ação.

O tempo das reuniões

É difícil julgar qualitativamente se um stand-up está demorando demais, especialmente se ele só aumenta gradualmente de tamanho.

Assim sendo

Anote o tempo das Reuniões e publique os resultados. Na maioria das vezes, os participantes simplesmente não percebem o impacto do Story Telling, não estão preparados para o Take Off Offline ou não estão preparando o tempo de duração da reunião. Faça de modo quantificável.

Mas

Tal como acontece com todas as medidas, o calendário das reuniões não deve ser introduzido a menos que exista uma meta real a cumprir devido a um problema com os níveis de energia. Uma vez que o objetivo seja alcançado, a medição deve ser descartada.

Medir sem nenhuma razão específica leva à suspeita e à métrica da apatia.

O tempo é um proxy para energia, atenção e ritmo. Preste mais atenção a essas coisas do que ao tempo.

Take it Offline

Algumas pessoas querem se envolver na Solução de Problemas imediatamente após ouvir um problema. Reuniões que demoram muito tendem a ter baixa energia e os participantes não diretamente relacionados a uma longa discussão tendem a se distrair.

Ainda é importante reconhecer que mais discussões serão necessárias para resolver o problema levantado. Algumas pessoas podem achar desconfortável reforçar a estrutura do stand-up fazendo uma interrupção.

Assim sendo

Use uma frase simples e consistente como “Falamos Offline” como um lembrete de que tais discussões devem ocorrer fora do stand-up diário.

Se a discussão foi Socializar , nada mais é necessário. Se a discussão foi sobre Solução de Problemas, o facilitador (e eventualmente apenas a equipe) deve garantir que as pessoas certas sejam nomeadas ou se inscrevam para lidar com a questão mais tarde.

Alternativamente, algumas equipes usam mais sinalização indireta.

Por exemplo, Mike Cohn16 descreveu um que usa um rato de borracha para indicar “estamos caindo em um buraco” .

Já Benjamin Mitchell descreveu uma Regra de Duas Mãos17

… se alguém acha que a conversa atual saiu do assunto, ou não é mais eficaz, então eles levantam a mão. Uma vez que uma segunda pessoa levanta a mão, isso é um sinal para parar a conversa e continuar com o resto do stand up. Aqueles que falam podem continuar a conversa depois que o stand up terminar.

Mas

Existe uma diferença entre a Solução de Problemas e uma questão de esclarecimento. Informações que não são compreendidas não são úteis.

Já a extensão em que as perguntas esclarecedoras são permitidas deve variar dependendo de quão grande é a equipe, e se afetará os 15 minutos ou menos .

Como incentivamos a autonomia?

Rodízio do Facilitador 🍢

Os membros da equipe estão se reportando ao líder , ou seja, eles estão conversando apenas com o facilitador da reunião, em vez de um com o outro.

Somente o facilitador da reunião está levantando e abordando questões relacionadas ao processo de stand-up.

Da mesma forma queremos que a equipe se aproprie do stand-up e isso requer a remoção de qualquer dependência de um único facilitador.

Assim sendo

Troque sempre o Facilitador . Gire a atribuição de uma função responsável por garantir que as pessoas assistam ao stand-up e cumpram as regras acordadas.

Mas

Equipes que não são experientes com stand-ups se beneficiam muito de ter um coach experiente no processo. É mais que a equipe deva ser levada a assumir maior controle do stand-up.

Eventualmente em algum momento, nenhum facilitador explícito deve ser exigido.

Quebrar o contato visual

Os membros da equipe estão se reportando ao líder , ou seja, eles estão conversando apenas com o facilitador da reunião, em vez de um com o outro.

Queremos que a equipe se aproprie do stand-up e isso requer a remoção de qualquer dependência de um único facilitador.

Assim sendo

O facilitador deve quebrar o contato visual como uma maneira sutil de lembrar ao palestrante que ele / ela deve estar se dirigindo à equipe, não apenas a uma pessoa. Uma maneira de fazer isso é se movimentar para que o orador atual não possa ver o facilitador.

Como sabemos quando um stand-up está indo mal?

Eu suportei reuniões stand-up regulares por três anos. O que tornou as reuniões mais dolorosas foi meu chefe (vou chamá-lo de Wally). Sua principal razão para a reunião de stand-up não era aumentar a eficiência ou abraçar o XP tanto quanto encurtar a interação humana além de qualquer coisa diretamente relacionada ao produto de trabalho. … Para Wally, no entanto, a reunião stand-up (como a reunião de segunda-feira às 7 da manhã e a reunião de sexta-feira às 5 da tarde) foi um teste de lealdade destinado a reforçar a relação empregador-empregado. – Phillip A. Laplante18

Há “cheiros” quando você está de pé que são indicadores muito bons de que as coisas estão dando errado. É importante notar que, mesmo que você não tenha sentido nenhum, isso não significa que o stand-up está dando certo. Significa apenas que ele ainda não fede.

Eventualmente a maioria dos odores a seguir está vinculada aos padrões anteriores. Para aqueles que não o são, os problemas subjacentes tendem a ser mais sutis ou fora do escopo do stand-up diário, e as pessoas terão que criar suas próprias soluções.

Focado nos corredores, não no bastão

As pessoas estão muito concentradas no que estão fazendo, mas negligenciam considerar se suas atividades estão realmente progredindo no trabalho. Renove o stand-up de tal forma que seja focado no Atendimento dos Itens de Trabalho.

Reportando-se ao Líder🗣️

Os membros da equipe estão enfrentando e conversando com o gerente ou com o facilitador da reunião, em vez de com a equipe. Isso indica que o stand-up diário é para o gerente / facilitador quando na verdade deveria ser para a equipe.

Contudo existem várias maneiras de quebrar essa dependência: Troque o Facilitador , Interrompa o contato visual, mude a forma dos Obstáculos de Ontem Hoje, use Passar o Sinal, etc.

As pessoas estão …sempre… atrasadas🐢

Isto é endereçado diretamente pelo Mesmo Lugar, Mesmo Tempo , mas como mencionado pode indicar que o stand-up está sendo realizado na hora errada ou no lugar errado.

Existem outros padrões para responder a isso, como impor uma multa. No entanto, eu geralmente não os recomendaria, pois implicam que a questão é sobre motivação extrínseca quando é muito mais provável que seja outra coisa.

Stand-up de início do dia … Antes tarde do que nunca? #SóQueNão

Porque o stand-up é visto como uma boa prática para começar o dia de trabalho, nenhum trabalho é realizado antes do stand-up.

Dependendo de como é o final da manhã, isso pode ter um impacto significativo nas horas de trabalho disponíveis. Isso leva a Não usar o stand-up para começar o dia .

Socializar🤝

Um dos objetivos do stand-up é aumentar a socialização da equipe. No entanto, o stand-up diário não se destina a que os membros da equipe “acompanhem” uns aos outros sobre assuntos não relacionados ao projeto.

É difícil fornecer exemplos disso, pois o grau em que a socialização passa de criação de equipe a distração varia de equipe para equipe. O limiar pode ser detectado a partir dos comportamentos dos participantes não envolvidos diretamente na socialização.

Portanto se os níveis de energia deles permanecerem altos, então provavelmente é apenas formação de equipe; Se os níveis de energia caírem, então use o Take It Offline e talvez forneça outro fórum para atuar como um Water Cooler19.

Eu não me lembro😧

O que eu fiz ontem? … Eu não consigo lembrar … O que eu estou fazendo hoje? … Eu não sei …

A falta de preparação causa um ritmo mais lento, o que causa menos energia. Também corre o risco de falhar quinze minutos ou menos , o que reduz ainda mais os níveis de energia.

Da mesma forma, uma boa maneira de contornar esse problema é mudar para um stand-up onde os Itens de Trabalho são atendidos e Nós Walk the board.

Caso contrário, é uma questão de expectativa de responsabilidade saber as respostas para os Obstáculos Ontem de Hoje .

Narrativa (Story Telling)🎙️

Em vez de fornecer uma breve descrição de um problema, o participante fornece detalhes e contexto suficientes para fazer os outros se sintonizarem.

Então a regra geral é identificar os obstáculos durante o stand-up e discutir os detalhes após o stand-up. Isso pode ser resumido como “Diga o título, não toda a história” ou ” Take it Offline” .

Solução de problemas⚠️

É hora de levantar questões e idéias superficiais, não é hora de resolver problemas em profundidade. – Marc Graban20

Inclusive a chave para manter os Stand-up Com 15 minutos ou menos é limitar o Story Telling e não sucumbir à Solução de Problemas durante a reunião. Coloque-o offline .

Energia baixa🔋

Pode indicar um abrandamento do ritmo devido a narração de histórias, resolução de problemas, etc. Nesse caso, coloque-o offline. Poderia ser simplesmente uma questão do tamanho da equipe. Pode ser a hora do dia que sugere tentar a alternativa de usar o stand-up para começar o dia e não usar o stand-up para começar o dia .

Obstáculos não levantados📖

Também conhecido como: Travelogue21

Pode haver várias razões para os obstáculos não serem levantados. Não lembrando, o alto limiar de dor, falta de confiança em levantar questões (porque os Obstáculos não são Removidos ), nenhuma maneira conveniente de levantar questões, etc.

Contudo o facilitador deve ter o cuidado de encorajar as pessoas a levantar obstáculos.

Já a introdução de um Conselho de Melhorias também pode fornecer um meio menos confrontante. Retrospectivas são uma forma eficaz de descobrir a razão subjacente pela qual os Obstáculos não são levantados .

Obstáculos não removidos

Com a exceção de um ambiente de culpabilização, o caminho mais seguro para impedir que as pessoas levantem mais obstáculos é simplesmente não removê-las. Para dificultar o esquecimento e/ou ignorar os obstáculos, acompanhe-os publicamente com um Conselho de Melhorias .

Obstáculos só são levantados no stand-up

Os stand-ups funcionam como uma rede de segurança. Na pior das hipóteses, um obstáculo maior será comunicado à equipe um dia. No entanto, fazer stand-ups não se destina a impedir que os problemas sejam levantados e resolvidos durante o dia. A introdução de um meio alternativo para levantar obstáculos, como um Conselho de Melhorias, pode ajudar. Se não, as razões subjacentes podem ser descobertas usando retrospectivas.

Daily Assíncrona🕊️

Recentemente adotamos a daily assíncrona na Agile Practice Center. Após o hiato de 2 anos em times remotos na pandemia, e como os fusos horários são diferentes adotamos a daily escrita em uma plataforma.

Contudo

É preciso ficar de olho para não deixar pessoas de fora e tratar os impedimentos assim que possível.

Entretanto

Nem sempre podemos resolver os itens na mesma hora.

No final o que fazemos é realmente apenas ficar de pé todos os dias

Espero que este artigo forneça mais detalhes sobre os detalhes sutis de práticas de stand-up efetivas e também indicadores comuns de problemas. Deve ficar claro que um stand-up diário não é apenas ficar juntos todos os dias.

No final do dia, é importante não estar muito preocupado em ter todos os padrões ou até mesmo “sentir alguns dos cheiros”.

Lembre-se dos problemas que estamos tentando resolver. As pessoas estão energizadas? As pessoas compartilham problemas e ideias? As pessoas estão focadas em nossos objetivos? As pessoas estão trabalhando juntas como uma equipe? Todo mundo sabe o que está acontecendo?

Se você puder responder a essas perguntas afirmativamente, a reunião provavelmente está indo bem. Afinal, é só ficar de pé todos os dias.

Retrospectivas, sua importância e o que fazer depois

Sempre houve uma retrospectiva no final do ano na tv e eu quando criança achava aquilo o máximo, aí veio a agilidade e transformou a inspeção, transparência e adaptação em uma cerimônia que eu adoro!

Ao seguir práticas ágeis, alguns membros da equipe podem achar alguns processos redundantes – possivelmente porque eles não entendem sua importância. Um desses eventos é a retrospectiva, que é conduzida após cada revisão / demonstração do Sprint.

Uma vez que a equipe scrum comece a progredir no caminho da maturidade ágil, certas atividades são realizadas como uma formalidade para transmitir a adesão à mecânica ágil. Pode haver um equívoco aqui, já que a adesão a uma prática ou processo não é para um público maior, mas para o aprimoramento da equipe.

Normalmente, quando uma retrospectiva é conduzida, a equipe se concentra em três pontos principais:

1. O que foi bem?

2. O que não correu bem?

3.  Existem melhorias ou melhores práticas que podem ser implementadas (ou o que a equipe pode fazer de diferente)?

Quando uma retrospectiva é conduzida, o scrum master precisa definir o palco adequadamente para que toda a equipe esteja envolvida. Eles devem colaborar para melhorar o desempenho, discutir como percebem as metas do Sprint e determinar se alcançaram o que se comprometeram.

Não se trata apenas de desempenho, mas de como a coordenação e a colaboração entre vários stakeholders tornaram o Sprint um sucesso ou um fracasso. As retrospectivas normalmente não são uma reunião post-mortem, em que a análise da causa raiz se destina a identificar gargalos e pontos de falha.

Em vez disso, são reuniões colaborativas voltadas para o futuro para refinar as ações a fim de se alinhar aos objetivos.

O papel do scrum master em alinhar a equipe com os eventos scrum é de suma importância para que a equipe não participe dos eventos por uma questão de adesão ao processo, mas sim como um meio de colaborar, melhorar, alcançar e comemorar.

Frequentemente, uma equipe age com pressa ao passar de uma demonstração / revisão de sprint para outra iniciação de sprint.

Mas retrospectiva é tarefa indireta!??

Uma retrospectiva costuma ser vista como uma tarefa indireta, em que a equipe entra com a intenção de terminá-la rapidamente para que possa se concentrar nas metas e resultados finais do próximo sprint.

Normalmente, os sprints são contínuos por natureza (a menos que ocorram em um fim de semana ou feriado). Idealmente, as retrospectivas são conduzidas no mesmo dia em que a revisão do sprint é concluída.

Às vezes, se as histórias confirmadas não são marcadas como “concluídas” (de acordo com a definição de “pronto”) devido a funcionalidade incompleta ou bugs imprevistos, elas são transportadas para o próximo sprint (a menos que o proprietário do produto troque a priorização delas em vez de novas histórias a serem desenvolvidas).

Uma reunião de planejamento para um próximo sprint seguido por uma retrospectiva pode prejudicar a reunião de retrospectiva do sprint anterior porque a equipe, o product owner e o scrum master estão com pressa para completar suas histórias inacabadas.

Aqui, o scrum master atua como uma ponte entre a equipe e o product owner para facilitar e guiá-los na condução da retrospectiva (especialmente quando as histórias estavam inacabadas no sprint que acabou de ser concluído).

O antipadrão das retrospectivas

Um antipadrão comum seguido pelos proprietários do produto é continuar o sprint mesmo depois de sua duração definida devido a histórias incompletas e a meta não ser totalmente cumprida. Uma sprint deve terminar após revisão ou expiração de sua duração.

Este é o aspecto mais importante em termos do primeiro pilar do scrum: transparência. Quando a meta da sprint não é alcançada por qualquer motivo, a equipe, o product owner e o scrum master têm que ser transparentes e declarar que foi uma sprint com falhasem aumentar sua duração ou acarretar os bugs.

O aspecto mais importante de uma meta de sprint é permitir que a equipe e o product owner saibam que o plano de liberação pode precisar de ajustes se um impacto for considerado. Um ponto crucial a lembrar aqui é que a linha do tempo da sprint foi definida tendo em mente a complexidade e o esforço envolvidos para completar as histórias comprometidas em uma sprint com base na capacidade disponível (que normalmente é fixada entre as sprints).

Quando houver histórias inacabadas em sprints consecutivas se torna uma tendência, pode ser revisitado na reunião de retrospectiva – que pode revelar causas potenciais de falha de sprint e histórias inacabadas.

Essas causas incluem:

  • Falta de compreensão da história;
  • Teste impróprio ou bugs imprevistos que resultaram de mudanças sugeridas durante a execução da sprint;
  • Critérios impróprios de sucesso / aceitação para as histórias em questão.

Lembre-se de que uma reunião retrospectiva é para melhorar, aprender, resolver problemas e celebrar as conquistas da equipe durante a execução e revisão da sprint; eles devem ter uma abordagem motivadora.

Mas quando é visto como apenas mais uma parte da mecânica ágil, pode deixar rachaduras dentro da equipe (e entre a equipe e o scrum master e o product owner; e entre o scrum master e o product owner). Não existe uma solução única para todos, mas as retrospectivas devem ser mais participativas – e direcionadas com uma mentalidade focada no crescimento e na inovação.

A retrospectiva: uma prática essencial para equipes ágeis

Conheci muitas equipes que não realizam retrospectivas – a parte inspecionar e adaptar – da abordagem ágil. Às vezes, as pessoas acham que o retrô vai demorar muito ou que não vão aprender rápido o suficiente.

O problema é que as equipes fazem a mesma coisa continuamente. Nada muda.

Costumo recomendar a abordagem de cinco etapas nas Agile Retrospectives: Making Good Teams Great de Derby e Larson, para qualquer equipe, ágil ou não.

  1. Prepare o cenário
  2. Colete dados
  3. Gere percepções
  4. Decida o que fazer
  5. Conclua a retrospectiva

Ou você também pode saber sobre as quatro perguntas mais tradicionais:

  1. O fizemos que foi bom?
  2. Onde falhamos?
  3. O que aprendemos?
  4. O que ainda nos intriga?

Como suspeito que você conheça essas abordagens de retrospectivas, usarei uma estrutura diferente aqui para mostrar como refletir rapidamente logo após realizar algum tipo de atividade.

Essa abordagem de reflexão é extraída do livro The Art of Focused Conversation: 100 Ways to Access Group Wisdom in the Workplace, de Brian Stanfield. Costumo usar essa estrutura quando faço um balanço das experiências dos alunos (por exemplo, em uma aula de treinamento ou quando facilito a retrospectiva provisória de uma equipe).

A estrutura é chamada de ORID, como em:

  • O bter os dados
  • R efletir sobre os dados
  • I nterpretar os dados e fazer o que significa que a partir dos dados
  • D ecidir o que fazer

Você pode usar uma estrutura ORID após o planejamento do backlog ou após as histórias de workshopping. Aplique-o a um período de tempo em que a equipe gastou mais de 20 minutos, mas menos de uma ou duas semanas de trabalho.

Obtenha os dados para definir o contexto
Cada pessoa experimenta os projetos de maneira diferente. Precisamos primeiro concordar com o contexto. Os dados nos ajudam a definir o contexto.

  • Quais são os fatos?
  • O que eu vi e ouvi?
  • O que eu percebi?
  • Existe história ou outros fatos?
  • Existem palavras ou dados que se destacam?

Refletir sobre os dados
Quando refletimos sobre os dados, traçamos conexões entre dados díspares. Usamos nossas emoções para fazer essas conexões. Eu faço perguntas como estas para dados reflexivos:

  • O que me surpreendeu?
  • O que isso me lembra?
  • Achei algo refrescante?
  • O que me desafiou ou frustrou?

Interpretar o significado
Gosto de pensar que esta pergunta é o “E daí?” pergunta – o que os dados significam para mim? Que ações posso realizar ou que experimentos posso realizar com base nos dados? Aqui estão algumas perguntas interpretativas que uso:

  • O que eu aprendi?
  • O que mais eu quero explorar?
  • Eu faria algo diferente?
  • Que insights eu ganhei?
  • Existem questões subjacentes que desejo abordar?

Decida o que fazer
Agora que aprendemos, é hora de decidir o que fazer a seguir. Quando eu facilitar a retrospectiva de uma equipe, muitas vezes eu peça às equipes para considerar o que uma coisa que eles vão colocar em prática. Aqui estão algumas perguntas de decisão que uso:

  • Temos frutas ao alcance que seriam fáceis de considerar?
  • O que usaremos como base para um experimento?
  • Qual é o nosso próximo passo?
  • O que vamos parar de fazer?

Não podemos fazer tudo – não ao mesmo tempo. Podemos escolher o que fazer e quando. Posso servir a alguns de vocês escrevendo sobre essas questões. Explorar essas questões pode expandir todo o nosso aprendizado e nossas práticas.

Então, ao aplicar o ORID, espero esclarecer algumas das preocupações que muitos de vocês têm sobre a abordagem ágil para o portfólio de projetos e roteiros de produtos.

Não negligencie as ações pós retrospectiva

Na busca pela melhoria contínua da equipe, identificar ações corretivas por meio de retrospectivas é apenas o primeiro passo. Essas ações precisam ser acordadas pela equipe, tornadas visíveis e rastreadas pelo Scrum Master, revisitadas na próxima retrospectiva e celebradas após a implementação bem-sucedida.

No entanto, aprendi por experiência própria que identificar ações corretivas em uma retrospectiva é apenas parte da batalha. Para garantir que a equipe obtenha todos os benefícios de suas ações propostas, elas devem ser gerenciadas de forma adequada.

Sem esse gerenciamento, ações corretivas valiosas podem se perder ou atrasar desnecessariamente e a equipe pode perder a fé no processo retrospectivo. O resultado final pode ser uma paralisação da melhoria contínua, o que é um desastre para uma equipe ágil.

Concordando com as ações

Inicialmente o ponto de partida para o gerenciamento de ações retrospectivas está na própria retrospectiva. Se a sessão foi bem-sucedida, no final haverá um conjunto de ações corretivas que foram identificadas por um ou mais membros da equipe.

Consequentemente o Scrum Master deve passar por cada ação por vez para confirmar que toda a equipe concorda que ela é válida.

Tendo em vista que uma ação válida é aquela que irá melhorar a produtividade da equipe sem incorrer em custos indevidos. A revisão das ações reforça sua importância e faz com que todos na equipe concordem que vale a pena implementá-las.

Além disso você pode descobrir que a equipe não consegue concordar sobre quais ações valem a pena serem realizadas. Se o debate chegar a um impasse, a votação por pontos pode ser usada para desfazer o impasse. A votação por pontos também pode ser útil se houver muitas ações corretivas para uma equipe realizar. A equipe pode usar a votação por pontos para priorizar as ações mais importantes para implementação de curto prazo.

Logo as ações de baixa prioridade para as quais a equipe não tem largura de banda podem ser descartadas por enquanto. Não se preocupe em perdê-los, pois, se tiverem valor, voltarão a surgir em retrospectivas futuras, quando puderem ser mais viáveis ​​para implementação.

Quadro de ações pós retrospectivas

Nesse ponto, vi equipes criarem histórias para cada uma de suas ações que vão para o backlog do produto. Não faço isso porque as ações não são histórias. Em vez disso, são coisas que a equipe pode fazer para tornar o negócio de implementação de histórias mais rápido ou fácil. Eles podem representar documentação, mudanças no processo, ferramentas aprimoradas e assim por diante.

O que eles não são: funcionalidade para o usuário final. Eles não devem, portanto, ser priorizados com histórias.

Contudo, as ações corretivas precisam ir para algum lugar ou podem ser esquecidas e nunca implementadas. Como acredito que as ações das retrospectivas são tão importantes e sua implementação pode ser tão crucial para o sucesso de um projeto, eu as torno o mais visíveis possível usando um Quadro de Ações das Retrospectivas:

Retrospective Actions

Analogamente um quadro de ações das retrospectivas é como um quadro de tarefas físicas, exceto que os cartões nele contêm as ações retrospectivas acordadas em vez de histórias. Uma vez que as ações que não foram implementadas residem na coluna To Do, aquelas em andamento estão na coluna In Progress e aquelas que a equipe executou estão na  coluna Implemented.

Já que as ações não implementadas ficam bem na frente da equipe todos os dias, elas não podem ser esquecidas. Além disso, todos podem ver quais ações foram realizadas. Isso significa que a equipe pode ver um progresso real em direção à sua própria melhoria contínua.

Nesse sentido, a medida em que tornamos as ações visíveis, será que podemos garantir que elas realmente sejam percebidas? Cabe ao Scrum Master reforçar a mensagem de que qualquer membro da equipe pode escolher uma ação retrospectiva para implementação.

Afinal, a equipe concordou com as ações porque todos acreditavam que as ações tornariam o negócio de implementação de histórias mais rápido, fácil, simples, resultaria em menos bugs, etc. Não há nada de errado em um membro da equipe melhorar a capacidade da equipe de trabalho implementando ações enquanto, ao mesmo tempo, outros realizam esse trabalho implementando histórias.

Inicialmente, o Scrum Master pode ter que se envolver para garantir que o equilíbrio entre as ações e histórias permaneça ideal. Ter um limite de WIP na coluna Em andamento é uma maneira de fazer isso. No entanto, uma equipe auto organizada vai sempre encontrar um equilíbrio produtivo muito rapidamente e essa intervenção raramente será necessária.

Rastreamento eletrônico

Em outras palavras, o  painel de ações retrospectivas é um poderoso radiador de informações para a melhoria contínua, mas não é tudo. Além do quadro físico, acho informativo manter um histórico eletrônico das ações com as quais a equipe concorda. Faço isso porque, com um fluxo constante de ações implementadas, a coluna Implementado no quadro se enche rapidamente e precisa ser limpa.

A história do que a equipe conquistou é então perdida. Além disso, o histórico pode registrar metadados sobre ações, como quando são identificadas e quando foram implementadas. Eu chamo isso de Rastreamento de Ações Retrospectivas e é representado por uma página no wiki da equipe, uma planilha no Gdrive etc..:

Retrospective Actions tracking

Em suma a página de rastreamento é um registro permanente de cada ação retrospectiva acordada e de seu estado atual. Você pode ainda adicionar um código de cores indica as ações que estão aguardando para serem implementadas (vermelho) ou foram implementadas (verde). Além de ter o registro de onde a ação foi implantada e em qual sprint e em qual sprint ela foi acordada.

Também é interessante registrar nos sprints quanto tempo a equipe leva para cumprir as ações (Sprint Lag). Se uma equipe de sucesso precisar de um lembrete da importância das retrospectivas e de seu progresso em direção ao aprimoramento, uma rápida revisão desta página irá tranquilizá-los.

Mas a página de rastreamento também é útil para identificar ações que não estão sendo realizadas. Se uma ação não for implementada por muitos sprints depois de ter sido acordada, vale a pena perguntar por quê. Pode ser que a ação esteja bloqueada. Uma ação bloqueada não é menos impedimento para o sucesso do projeto do que uma história bloqueada e pode exigir a intervenção do Scrum Master para facilitar sua remoção. Como alternativa, você pode descobrir que a ação está simplesmente obsoleta e que a equipe não acredita mais que sua implementação valha a pena. Nesse caso, e com a concordância da equipe, a ação pode ser retirada da página de rastreamento e do quadro de ações físicas.

Ação pós implementação

Finalmente, é importante fechar o círculo na próxima retrospectiva. O Scrum Master deve revisar a página Rastreamento de Ações Retrospectivas antes da retrospectiva para ver quais ações foram implementadas no último sprint. Eles devem usar essas informações na retrospectiva para comemorar o sucesso da melhoria contínua da equipe, ao mesmo tempo em que as histórias concluídas são comemoradas.

Uma vez que isso reforça para a equipe que eles estão cumprindo as ações acordadas antes de identificar outro conjunto. Isso ajuda a manter o fluxo de ações.

Conclusão

Concluindo, às vezes, ações retrospectivas podem ser negligenciadas. Eu mesmo fiz isso com uma crença anteriormente sustentada e incorreta de que as ações seriam simplesmente realizadas porque eram obviamente importantes.

No entanto, não é tão simples assim. As ações precisam ser totalmente acordadas, tornadas visíveis, sua conclusão ativamente encorajada e sua implementação bem-sucedida celebrada.

Somente com essas etapas em vigor uma equipe pode tirar o máximo proveito das grandes ideias que têm em retrospectivas.