Planejamento Dimensional no Agile

Nos últimos anos, percebi que tenho falado cada vez mais sobre "Dimensional Planning". Conheci o Dimensional Planning através de Koen van Exem, um dos primeiros agilistas belgas. Ele vem dos primórdios do movimento Agile (belga) e, infelizmente, caiu um pouco no esquecimento.

Ontem estive conversando com JB (Rainsberger) e Alistair (Cockburn) sobre isso e percebi que tenho uma história interessante para contar.

Antes de compartilhá-la com você, vou explicar brevemente os fundamentos do Dimensional Planning. A ideia por trás dele é dividir nossas Stories em diferentes dimensões de implementação. Fazemos isso porque muitos dos nossos clientes querem um Lexus no final da semana. Mas talvez não consigamos entregar isso. No entanto, podemos oferecer um Toyota já amanhã. A maioria dos clientes acha essa oferta ótima e consegue esperar até que possamos entregar o Lexus (ou seja, ROI alcançado rapidamente).

Gosto muito da forma como o Koen explica o Dimensional Planning

Imagine que o seu cliente quer uma autoestrada entre Amesterdão e Heusden. Você é bastante bom a construir autoestradas, por isso começa logo. Depois de alguns meses, termina e, cheio de orgulho, deixa o seu cliente usar a autoestrada pela primeira vez. Ele chega a Heusden, mas não parece muito feliz. Então você pergunta se as estações de serviço, as áreas de descanso e as saídas a cada poucos quilómetros estão bem. Embora o cliente confirme tudo, as suas perguntas parecem irritá-lo ainda mais. Finalmente, ele desabafa: "Este não é o lugar para onde eu queria ir!"

Você olha para a placa: Heusden. Ele não queria ir para Heusden? Sim, queria.

Mas acontece que existe outro lugar com o nome "Heusden".

Os seus advogados e os do cliente agora têm longas discussões sobre de quem é a culpa e quem deve pagar pela autoestrada errada. (Se você tiver um bom advogado, o seu cliente vai pagar e nunca mais volta…)

Neste caso, poderia funcionar bem com Dimensional Planning. Primeiro construiria uma estrada de cascalho entre Amesterdão e Heusden.

Em menos de uma semana já teria terminado e descoberto que acertou no lugar errado. Para você isso não é problema, porque sabia que haveria um ou outro mal-entendido. Você informa-se, encontra o outro Heusden e constrói uma nova estrada de cascalho. Depois de mais uma semana, essa estrada também está pronta e você descobre junto com o seu cliente que ainda é o Heusden errado. É que existem dois lugares com esse nome na Bélgica e mais um nos Países Baixos. Quem poderia adivinhar?

Depois de mais uma semana, o seu cliente está feliz por finalmente ter uma estrada de cascalho entre Amesterdão e o Heusden certo. (E isso muito mais rápido do que originalmente em vários meses.)

Embora ainda não existam todas as funcionalidades, já há um certo ganho a registar, pois o cliente agora pode deslocar-se entre as duas sedes da sua empresa. Não é uma estrada fantástica e não se pode andar muito rápido, mas é muito mais rápido do que com a estrada anterior e um desvio de 100 km.

No dia seguinte à conclusão da estrada de cascalho, você começa a trabalhar numa versão em calçada da estrada, que também termina em três semanas. Pode igualmente trabalhar numa versão de asfalto, alcatrão ou autoestrada. Na maioria dos casos, porém, os clientes já nem querem a autoestrada assim que conseguem tirar proveito das versões anteriores.

Todos sabemos que um cliente vai sempre dizer "Sim" quando lhe perguntamos se quer uma autoestrada, e que os programadores adoram trabalhar em todas as funcionalidades de uma autoestrada.

No nosso exemplo do carro, a maioria das pessoas também preferiria o Lexus ao Toyota – até chegar a hora de pagar, porque aí de repente um Toyota também serve. E da mesma forma, nem todo programador quer estar sempre a pensar em todos os detalhes que o Lexus exige.

Não é caro construir três estradas de cascalho, uma rua de paralelepípedos, uma estrada asfaltada e uma autoestrada?

Claro que é mais caro do que construir apenas uma autoestrada. Mas todos sabemos que erros acontecem e que ainda assim é mais barato do que ter que construir três autoestradas, como frequentemente acontece no desenvolvimento de produtos.  

Com o meu método, preparamo-nos tão bem que nunca cometemos erros…

Se você tem certeza e quer correr o risco, pode fazer isso, claro. E mesmo que você esteja certo (duvido que isso aconteça sempre), tenho bastante certeza de que a maioria dos clientes já terá mudado de opinião quando você começar a construir a autovia. E meses antes de você sequer começar a construir, nossas estradas de cascalho já estarão entregando retorno sobre o investimento.

Isso parece muito bom na teoria. Mas funciona mesmo na prática?

Boa pergunta! Quase esqueci; eu queria apresentar neste artigo um bom exemplo da vida real:

Alterei alguns detalhes da história para proteger o cliente.

Trata-se do site de uma empresa. Este estava localizado numa zona completamente desmilitarizada da rede corporativa. Lá tinha sido criado um pequeno produto que deveria ser comercializado pela internet. O Chief Financial Officer (diretor financeiro) era um grande defensor deste produto e queria receber regularmente os números de vendas. Para isso, no entanto, teriam que ser violadas zonas de segurança e os dados de vendas teriam que ser inseridos no sistema SAP.

Numa grande empresa, isso é um projeto bastante grande, que certamente requer seis meses de trabalho de desenvolvimento. Os preparativos começaram com reuniões com pelo menos 20 pessoas (especialistas em segurança, especialistas em SAP, desenvolvedores web e uma quantidade de gestores até ao nível abaixo do CFO).

Numa reunião seguinte, o CFO reclamou da má visibilidade da evolução das vendas do produto nos primeiros seis meses críticos. Então recomendei projetos paralelos temporários usando Dimensional Planning (como no exemplo da autoestrada).

A versão estrada de cascalho:

Todos os dias gerávamos um relatório PDF no servidor web e o guardávamos numa disquete. (Lembramo-nos que grande parte da rede não estava conectada ao servidor.) Todos os dias imprimíamos este relatório e levávamos uma cópia dos números de vendas ao escritório do CFO, onde um estagiário inseria todos os dados no nosso sistema SAP. O relatório PDF foi criado por um dos nossos desenvolvedores no mesmo dia em que o produto foi lançado. No final do dia, já tínhamos os dados para o CFO.

O primeiro problema: O CFO queria algo adicional; algo que deveria ser perguntado ao cliente no site. O desenvolvedor tinha mostrado orgulhosamente o relatório ao CFO e agora voltava ao seu posto de trabalho. Meia hora depois, a informação adicional já estava a ser solicitada no site e o novo relatório foi criado (sem os dados do primeiro dia). Logo no dia seguinte apareceu um artigo no jornal e muitos clientes compraram o produto. No dia seguinte já chegavam os primeiros números e o nosso estagiário tentou transferir os dados para o sistema SAP. Foi aqui que descobrimos o nosso segundo problema. Acontece que estávamos a usar a tabela SAP errada. Demorou alguns dias para corrigir este erro. O CFO continuou a receber o seu relatório, mas na primeira semana isso ainda não podia acontecer via SAP. Na sexta-feira da primeira semana, o estagiário conseguiu fazer o upload dos dados. No entanto, era um trabalho bastante aborrecido e absolutamente não escalável. (Tivemos alguns milhares de vendas na primeira semana.) Agora era altura da nossa:

Versão paralelepípedo:

Desta vez, criamos o relatório em formato CSV. (Lembre-se, isso foi antes do XML.) Então, toda manhã, o desenvolvedor que chegava primeiro ao escritório ia ao servidor web, gerava o relatório e copiava para um disquete. Depois pegava o disco e carregava os dados no nosso sistema SAP. Essa versão era mais escalável; não importava quanto tínhamos vendido no dia anterior, o trabalho para o nosso desenvolvedor permanecia o mesmo. Mas mesmo nessa versão tínhamos um pequeno problema. Um dos campos estava formatado como texto em vez de número. (Um bug bem comum.)

O trabalho tinha que ser feito pessoalmente por alguém todos os dias. Não era automatizado e a atualização era feita apenas uma vez por dia (referente ao dia anterior).

Então começaram as reuniões para a versão autobahn. No final de uma dessas reuniões, perguntei a um colaborador do CFO como eles usavam os dados e se estavam satisfeitos com os números. Por acaso, percebi que o CFO só olhava os dados às sextas-feiras. (Ou seja, não diariamente.) Nem sequer o incomodava não saber os números completos de vendas do dia ou da semana.

A versão autoestrada:

Felizmente, eu já tinha uma reunião agendada com o CFO e seu colaborador no dia seguinte. Conversamos sobre o progresso do projeto Autobahn e sobre como ele estava impedindo as pessoas de trabalhar em outro projeto importante. Sugeri educadamente que mantivéssemos a versão de paralelepípedos e colocássemos o projeto Autobahn em espera por enquanto. Muitas pessoas na empresa não ficaram muito felizes com isso, pois queriam muito trabalhar nesse projeto super legal. O Security Officer, no entanto, ficou bastante satisfeito, pois assim o servidor web poderia permanecer na área segura. No final das contas, a empresa economizou seis meses de trabalho de desenvolvimento em uma Autobahn que teria colocado a rede em risco e não era realmente necessária.

Alguns anos depois, encontrei o CFO novamente. Ele admitiu que o projeto Autobahn provavelmente teria sido demais, pois o produto nunca chegou nem perto de gerar o dinheiro que teria sido necessário gastar no projeto Autobahn. Graças ao projeto da estrada de cascalho, eles puderam descobrir bem cedo que ainda faltavam os endereços de e-mail dos clientes, e essa foi a melhor coisa que poderia ter acontecido. Com essa lista de e-mails, nos anos seguintes eles conseguiram vender vários outros serviços aos clientes, e isso salvou a empresa da falência.

O texto a seguir é do blog de Yves Hanoulle e foi traduzido por nós para o alemão.