Discovery x Delivery

Implementar um processo iterativo-incremental como o método Scrum exige de todos nós uma mudança de modelo mental, precisamos abrir mão do domínio ilusório de um projeto waterfall, em que tentávamos antecipar longos planos de projeto, prevendo mínimos detalhes com meses de antecedência.

No Scrum, temos uma visão geral do que queremos, uma distribuição temporal, uma estimativa de complexidade e custos, mas aprofundamos o detalhamento um pouco de cada vez, suficiente para as próximas semanas, trabalhando na porção que mais agrega valor ao negócio naquele momento do projeto.

discoveryXdelivery
(*) Diagrama inspirado no de  no http://blog.polarion.com

Para tanto, é preciso criar um continuum em que sempre ao terminar um Sprint, já teremos o detalhamento do próximo para ser estimado e desenvolvido, exigindo que enquanto um Sprint esta sendo construído haja em paralelo um esforço pela definição detalhada do próximo. São dois ciclos distintos – Discovery e Delivery – que resguardam sua própria natureza, onde diferentes papéis assumem o protagonismo, fato refletido no protagonismo, artefatos, características dos quadros de tarefas e dinâmica.

No DISCOVERY usamos um quadro, sob a responsabilidade do PO, UX, SEO e SQA, em um trabalho de elicitação, entendimento e descrição daquilo que será estimado e construído na próxima Sprint. No de DELIVERY, temos um quadro “Sprint N” (1, 2, 3, …), típico para desenvolvimento de software. Enquanto a equipe técnica constrói a Sprint N, ciclo de DELIVERY, ocorre em paralelo um ciclo de DISCOVERY que estará entendendo e detalhando o próximo SPRINT.

DISCOVERY

Ciclo compreendido pelas timeboxes de Visão, Product Backlog, Release Planning, Sprint Backlog até o detalhamento das Users Stories. Possui forte atuação do Product Owner, keyusers, UX, SEO, SQA e conta com alguns momentos de integrantes da equipe técnica, como analista de sistemas, arquiteto ou engenheiro. Usa técnicas como Business Model, Story Mapping, Benchmarks, Focus Group, Pesquisas, Provas de Conceitos, Prospecção de fornecedores e parceiros, entre outras tantas, com o objetivo de ter o maior entendimento e detalhamento possível para o início da próxima Sprint.

DELIVERY

Ciclo compreendido pelas timeboxes de construção de cada Sprint, desde o Sprint Planning, Daily Meetings, Review, Entrega e Retrospectiva. Com forte atuação da equipe técnica , que trabalhará no desenvolvimento das User Stories do Sprint corrente. Aqui temos o uso de técnicas de tracking, com métricas e acompanhamento diário para antecipação ou projeção de tendências, talvez na criação de planos de ação para correção de desvios. Técnicas de engenharia ágil são bem vindas, como pair programming, testes automatizados, multidisciplinaridade, componentização e outras.

Reflexos no Planning

Se uma reunião de Sprint Planning for iniciada com muitas User Stories incompletas, sem clareza e dúvidas quanto ao valor ou desconhecimento do que se quer, melhor parar e converter a reunião em uma reunião de DISCOVERY. Não tem como estimar e começar de fato a Sprint com muitas informações insuficientes, teria tudo para dar errado.

É fundamental que durante o planejamento de cada Sprint N, seja computado o tempo de dedicação de alguns integrantes no apoio ao trabalho da próxima SPRINT, bem como garantir que haja disponibilidade do PO, SEO, UX e SQA para apoiar e dirimir dúvidas no desenvolvimento do SPRINT N.

3 comentários

    1. Oi Roberto, báh, post antigo mas estou aberto a críticas sim, se dizes é porque podes me ajudar, afora a imagem com o copyright explícito de quem são as outras imagens??? Sendo que todas foram alteradas, posto que são abordagens proposta por mim mesmo. Mas é um post de 2012, se puderes me explicar melhor teu comentário, posso analisar … quem sabe dizer que se inspirou em uma imagem que aparentemente conheces … o/

      Curtir

Deixe um comentário