Muitas vezes em nossa carreira enfrentamos as famosas  “marchas da morte” (“Death march”) que é aquela situação onde há ainda muito código para desenvolver, as histórias são alteradas ou mais são acrescentadas,  mas a data da entrega é bem antes do tempo necessário e não pode ser mudada. Nesses casos, todos entram em um ritmo frenético trabalhando horas extras e nos fins de semana, o stress aumenta, crises surgem de uma hora para outra, muitos pensam em desistir e abrir uma barraquinha de côco verde na praia.

Como manter os processos nessas situações? Não é fácil. No desespero, o bom senso vai para ralo e todos saem correndo para tudo quanto é lado. Coisas como: “Vamos abandonar o ‘daily meeting’! Não podemos perder esse tempo!”, “Vamos microcontrolar os desenvolvedores e suas tarefas!”, “Review e Restrospectiva? Nem pensar nesse prazo que temos…”, e por ai vai.

Passamos por isso recentemente. Todas essas idéias de abandonar o processo ágil surgiram nas intermináveis reuniões que fizemos para tentar endereçar o problema de entregar muito em pouco tempo.

Depois de muito pensar para defender o processo ágil que tanto apreciamos, chegamos a uma forma que, senão ideal pelo manifesto ágil, pelo menos está funcionando razoavelmente.

O projeto é grande e temos quatro times com 5 ou 6 pessoas cada trabalhando em partes do software com alguma dependência entre eles. O prazo é super apertado.

Estabelecemos dois “daily meetings”, um as nove da manhã, o que força todos a chegarem no horário de trabalho, onde cada integrante do time diz o que vai fazer naquele dia e quais são os impedimentos. As dezoito horas fazemos um novo “daily” para que todos digam se as tarefas foram ou não para o “Done” e já planejamos como endereçar as tarefas não terminadas para que no dia seguinte elas possam ser resolvidas definitivamente.

As dezenove horas fazemos um “Scrum of Scrum” com representantes de cada time trabalhando no projeto. Eles falam sobre os problemas enfrentados e sobre o que eles precisam dos outros times.

O “review” está espalhado durante o “sprint”, a cada história terminada, o PO (“Product Owner”) avalia se está “Done” mesmo. Restrospectiva foi para o saco… No final do projeto, se sobrevivermos até lá, faremos uma retrospectiva do projeto como um todo para tentar evitar essas marchas.

Horas extras rolam soltas e débitos técnicos também. Mas tudo está sendo testado exaustivamente para garantir uma qualidade aceitável. O time está ativamente discutindo as histórias tentando simplificá-las e recusando mudanças que o PO apresenta de vez em quando que possam impactar o que já foi feito.

Na correria, algumas integrações de código dão problema. O Git deveria ter um aviso: “Não use se estiver com pressa!”. Mas  toda integração só vai para homologação depois de passar por todos os testes.

Até agora, parece que vamos entregar no prazo. Vai ter muito trabalho depois do lançamento para arrumar a casa, mas o site vai estar no ar na data que o negócio precisa. Não é para isso que nos pagam?