Descoberta Contínua em Scrum / Agile
Já escrevi sobre como equipes de produto ágeis ou Scrum executam Product Discovery e Product Delivery em paralelo. Além disso, escrevi sobre como equipes na Product Discovery às vezes gostam de trabalhar com Timeboxing.
Neste artigo, quero escrever sobre a tendência crescente em direção ao Continuous Delivery e Continuous Discovery.
A ideia de Continuous Delivery (entrega contínua) está se espalhando cada vez mais. Muitas equipes têm falado sobre isso nos últimos anos, mas agora também existem equipes que realmente trabalham assim.
Quase todas as equipes de produto hoje em dia trabalham com builds contínuos. O princípio por trás disso é que é melhor encontrar problemas cedo do que tarde. Por isso, os builds normalmente são iniciados assim que mudanças são feitas.
Algumas equipes de produto levaram esse princípio a um nível completamente novo. Elas aprenderam que problemas de integração consomem tempo e que, através de integração precoce e frequente (em vez de uma única fase antes dos testes), podem melhorar significativamente seu throughput geral quando minimizam o tempo em que trabalham isoladamente.
Da mesma forma, é melhor executar suítes de testes de regressão automatizados continuamente para detectar novos problemas o mais cedo possível (o que reduz significativamente o número de fontes de erro e o tempo para correção), em vez de testar tudo em uma fase no final de um ciclo de release (mesmo um ciclo de duas semanas) e descobrir todos os problemas de uma vez.
A consequência lógica disso é que algumas equipes agora fazem releases regularmente (conhecido como Continuous Deployment). Isso significa que cada mudança lógica (ou grupo de mudanças) é entregue diretamente em pequenos "micro-releases". Isso tem algumas grandes vantagens. A primeira vantagem é que esta é a estratégia definitiva para releases incrementais e, portanto, o principal mecanismo para Gentle Deployment – bom para nossos clientes e bom para nós. A segunda vantagem é que encontrar e corrigir problemas em produção é muito mais fácil quando você muda apenas uma ou poucas coisas de cada vez.
No entanto, tudo o que descrevi até agora tem a ver com Product Delivery. Mas e a Product Discovery?
Já defendo há bastante tempo o mesmo princípio quando se trata de encontrar Product Backlog Items. Em vez de uma "fase de Product Discovery" de várias semanas, onde se criam Product Backlog Items, valida-se e depois passa-se para o desenvolvimento, quero encorajar as equipes a uma Product Discovery contínua, onde identificamos, validamos e descrevemos permanentemente novos Product Backlog Items. Alguns trabalhos de Discovery levam apenas algumas horas, outros mais tempo, mas é um processo permanente de geração de ideias, validação e descrição.
No Dual-Track Scrum, Product Backlog Items são gerados continuamente no Discovery Track e no Delivery Track esses itens são continuamente construídos, testados e implantados.
Com relação à tendência de Continuous Discovery e Continuous Delivery, muitas equipes acham o processo Scrum um pouco restritivo e consideram o modelo Kanban mais adequado neste caso.
Embora nem todas as equipes tenham necessariamente mudado para Kanban, vi muitas que adaptaram o Scrum em direção ao Kanban exatamente por esse motivo. A adaptação mais comum é, em vez de fazer release após cada Sprint de duas semanas, por exemplo, fazer release de features e outras mudanças diretamente quando estão prontas – frequentemente são vários micro-releases por semana. Neste caso, as equipes usam o Timeboxing do Scrum como uma forma de estruturar seu trabalho e promover retrospectivas regulares.
Fundamentalmente, a transição para Continuous Discovery e Continuous Delivery é algo realmente bom e muitas das melhores equipes que já conheci trabalham assim; mesmo que aqui, como em todo lugar, às vezes seja necessário fazer compromissos.
Este texto é do blog de Marty Cagan e foi traduzido por nós para o alemão.
