Conhecendo o dual track: foco na entrega de valor
O dual track vem sendo utilizado no desenvolvimento ágil como forma de organizar, planejar e dar visibilidade ao trabalho realizado pela equipe, além de diminuir os riscos de entregas mal alinhadas, gerando maior satisfação no uso do produto.
Como surgiu o termo “Dual track”
O dual track é uma estrutura ágil onde existem dois fluxos distintos, mas que funcionam simultaneamente: Discovery — etapa de descoberta e Delivery — etapa de desenvolvimento, são executados em paralelo, onde um sustenta o outro em intervalos regulares.
O termo dual track foi idealizado por Jeff Patton — Product Designer e Marty Cagan — Product Manager. Inspirado em um artigo de Desiree Sy — User-Centered Design, chamado “Adapting Usability Investigations for Agile User-centered Design” onde ela descreve o resultado de um trabalho rigoroso sobre design e validação no desenvolvimento ágil.
Para chegar ao que Jeff Patton e Marty Cagan chamaram de “dual track”, eles extraĂram um pedaço importante do artigo de DesirĂ©e Sy:
“… Trabalhamos muito próximo dos desenvolvedores através do design e desenvolvimento, embora as faixas duplas — dual track apareçam representadas separadamente, na realidade, os designers precisam se comunicar todos os dias com os desenvolvedores.”
Dessa maneira eles começaram a difundir o termo em seus cursos para gerentes de produto, e gradualmente outros profissionais começaram a utilizar o termo dual track, representando um novo método no desenvolvimento ágil.
Uma das preocupações levantadas por Jeff Patton era a de transmitir a ideia de que essa estrutura realmente deve ser chamada de dual track — faixas duplas e não duel track — faixas de duelo.
Pois as pessoas acabam interpretando que sĂŁo trabalhos diferentes para diferentes pessoas , como gerentes de produto e designers descobrindo apenas o que construir e desenvolvedores apenas construindo.
No pior dos casos Ă© possĂvel interpretar que os desenvolvedores precisam esperar semanas para que os gerentes de projeto e designers realizem suas tarefas, e na verdade nĂŁo deve ser assim.
Se todos tiverem a consciência que são responsáveis pelo sucesso do produto, a equipe entenderá e contribuirá para os dois tipos de trabalho.
A seguir apresento uma visĂŁo geral do dual track, baseada nos estudos que Jeff Patton e Marty Cagan realizaram.
Foco em engenharia
Com o objetivo de realizar entregas, o ciclo de desenvolvimento se parece com isso:
No desenvolvimento ágil, equipes falam muito sobre velocidade, e essa velocidade se refere a “velocidade de desenvolvimento”.
E elas tambĂ©m se perguntam sobre previsibilidade, ou seja, no inĂcio de um Sprint, eles estimam a velocidade e, no final, medem. Esperando que suas previsões estejam corretas.
Desenvolvedores também falam muito sobre “software potencialmente entregável”, isso pode significar que o software ainda não esteja pronto para ser entregue, mas quando fica, a qualidade tem que ser alta o suficiente para que possa ser entregue com confiança, ou seja:
“O trabalho de desenvolvimento concentra-se em qualidade e previsibilidade”
Foco em descoberta
Com o objetivo de aprender e nĂŁo entregar software, o ciclo de descoberta se parece com isso:
Para termos resultados satisfatórios pensamos em muitas estratégias no desenvolvimento de um produto, o fato é que algumas vezes não alcançamos o resultado esperado e isso acaba se tornando um problema.
Levamos tempo ao longo do desenvolvimento para aprender sobre os problemas que estamos resolvendo e assim tomarmos boas decisões sobre o que devemos construir.
O Discovery serve para fazermos isso, respondermos perguntas, testarmos ideias e evitarmos sempre que possĂvel priorizar itens que nĂŁo deveriam ser desenvolvidos.
A ideia Ă© sempre aprender o mais rápido, barato e seguro possĂvel. Portanto, a velocidade tambĂ©m Ă© importante durante a descoberta — mas isso Ă© “velocidade de aprendizado” e nĂŁo de desenvolvimento.
O trabalho de descoberta concentra-se em aprendizado e validação
Geralmente iniciamos o Discovery com alguns questionamentos:
- Que problema estamos resolvendo, e para quem?
- A solução pensada resolve o problema?
- Como podemos medir o sucesso da solução?
O resultado deve ser nossa melhor aposta, nosso melhor palpite, nossas crenças, nossas hipóteses.
Isso pode soar estranho para quem tem a convicção de estar criando a coisa certa. Só que na verdade é sempre uma aposta, sempre buscando obter o maior valor. Fazemos isso sabendo que nessas apostas existem muitas suposições e riscos.
Para melhorar nosso aprendizado, temos que assumir os riscos e suposições e seguir em frente, usando o que aprendemos e evoluindo nosso aprendizado sobre problemas e soluções.
Devemos ter em mente que não estamos apostando que podemos construir no prazo. Apostamos que as pessoas têm o problema que estamos resolvendo e que elas tentarão, usarão e adotarão nossa solução com prazer.
A maneira mais cara de testar uma ideia é testá-la em produção
Um ciclo de descoberta pode se parecer com isso:
- Faça o mais rápido quanto for possĂvel
Em horas quando possĂvel, pode levar dias, ou apenas algumas semanas. A maioria dos ciclos de descoberta devem caber em um Sprint de 2 semanas. - Descartar ideias Ă© normal
No final de cada teste você tem uma decisão a tomar: construa, descarte ou continue aprendendo — É isso, nem tudo segue em frente e isso pode deixar algumas pessoas desconfortáveis. - Controle os ciclos de descoberta
Para evitar que os custos de descoberta fiquem altos, vocĂŞ pode setar inĂcio e fim de um teste ou experimento em alguns dias. - NĂŁo Ă© fácil prever o que precisamos aprender em seguida
Não com facilidade. Quando se aprende algo valioso, isso tende a mudar nossa percepção e realmente muda, afeta nas decisões do que precisamos aprender em seguida.
Ciclos de descoberta:
É evidente que o trabalho de desenvolvimento e descoberta são fundamentais. Mas a abordagem utilizada para o trabalho e o processo de ambas são diferentes.
Tudo acontece ao mesmo tempo
O ciclo de descoberta Ă© mais enxuto e se concentra em validar as ideias, enquanto que o ciclo de desenvolvimento Ă© mais longo visando entregas com qualidade.
Seria muito legal se pudéssemos focar no discovery, depois mudar o foco para o delivery. Talvez isso até poderia funcionar se todos tivessem as mesmas habilidades. Mas sabemos que isso não acontece.
O trabalho de descoberta acontece simultaneamente e continuamente com o trabalho de desenvolvimento
O discovery usa ciclos de desenvolvimentos mais irregulares e rápidos. É “enxuto”, pois a ideia Ă© tornar esses ciclos os mais curtos possĂveis.
As ideias no discovery mudam e muitas vezes podem ser abandonadas, e isso nĂŁo quer dizer que vocĂŞ esteja fazendo algo errado. Simplesmente a ideia foi invalidada e vocĂŞ pode ter descoberto outra de maior valor nesse processo.
O discovery e o delivery sĂŁo mostrados em duas faixas porque sĂŁo dois tipos de trabalho e dois tipos de pensamentos.
ConclusĂŁo
O dual track é um método para acelerar e melhorar o desenvolvimento de produtos, gerando sintonia entre a equipe e diminuindo o risco de entregas que não estejam de acordo com as necessidades das pessoas. Isso acaba aumentando o valor do produto e consequentemente a satisfação no uso dele.
E você, como tem feito para alinhar suas entregas? Que métodos tem usado para garantir o alinhamento entre designers e desenvolvedores? Deixe seu comentário…
