Não sei se no seu “Product Backlog (PBCK)” existem várias histórias com pontuação igual ou maior do que aquela que a equipe pode produzir no decorrer de uma “sprint”. Normalmente chamamos essas histórias de épicos. O meu PBCK está recheado de épicos.

Fora o fato de não podermos desenvolvê-los durante uma única “sprint”, não existe nada de errado com eles. Esse escudo nos protege até o momento em que o Product Owner (PO) volta das férias e prioriza um monstro desse. Qual a primeira reação? Afirmar que trata-se de um tal de “Épico”. Com coragem lembramos ao PO o seu significado. O PO, também com coragem, responde… E daí?

Nesse momento temos que explicar ao representante do cliente (o tal do PO) que esse requisito, afinal uma história surge de um requisito de negócio, precisa ser dividido em vários outros, de preferência menores do que o original, para que possam ser desenvolvidos e, com sorte, ao final de algumas “sprints”, termos aquele épico, digo, requisito de negócio, desenvolvido.

E qual é a dificuldade disso? A dificuldade está no fato de que uma história necessariamente deve corresponder a um requisito que agregue valor para o cliente. Em outras palavras… O cliente precisa perceber aquilo como importante para o negócio. Adicionalmente a isso o cliente terá que aprovar o desenvolvimento. Se ele não entender o valor do trabalho e não souber como validá-lo (se está completo e sem erros) ainda não teremos uma história.

Recentemente passei por uma situação como essa. O cliente queria apenas um gráfico. Esse gráfico tinha que ser consultado através de uma aplicação que roda em “browser”. Nesse gráfico deveríamos computar o número de vezes ao longo de um período de 30 dias que uma determinada marca aparecia nos diversos blogs, revistas e jornais online. Entretanto havia um quesito adicional. Esse número diário deveria se dividido em conjuntos do tipo: economia, marketing, finanças, entre outros. Como são milhares de notícias diárias, e a marca poderia variar entre inúmeras marcas existentes, precisávamos que essa classificação, ou seja, associar uma notícia da marca desejada em um desses conjuntos, fosse feita de forma automática.

Comecei a explicação da complexidade para o PO  desmembrando o problema na necessidade de se desenvolver um “crawler” (aquele robô que vai de site em site baixando seu conteúdo). Precisaríamos desenvolver e treinar um classificador probabilístico para classificar cada documento baixado em um dos conjuntos que o cliente precisava. Depois desenvolver um mecanismos de busca e recuperação dos documentos que continha a marca desejada e finalmente estaríamos prontos para desenvolver o gráfico. Eu não percebi que depois de 10 minutos de explicação ainda não tinha chegado na explicação da dificuldade de desenvolver o gráfico propriamente dito. Mas nem tudo estava perdido. Consegui fazer com que o PO percebesse que o problema era mais complicado do que de costume. Entretanto são coisas que o PO não quer nem começar a entender. Para ele “não importava se o pato é macho ou fêmea… o importante é que ponha o ovo” na mesa dele.

Como transformar “crawler”, classificador probabilístico, mecanismo de busca e recuperação de documentos indexados em valor agregado antes de mostrar o gráfico? Procurei sem sucesso pela receita de bolo. Como não encontrei resolvi descrever nesse “post” o que fizemos.

A receita é constituída apenas de dois ingredientes. São duas perguntas e aqui vão elas:

  1. Que valor para o cliente, mesmo que seja parcial, podemos agregar com o que desenvolvemos?; e
  2. Como apresentar esse resultado incompleto, mas de uma forma que a experiência de consumi-lo seja agradável?

Com o “crawler” o cliente não fazia muita coisa. Mas contando os documentos encontrados em um dia que continham a marca já era alguma coisa que o PO entendeu o valor. Com isso respondemos a primeira pergunta. A resposta para a segunda foi mais fácil ainda. Ele gostou da ideia de receber um “tweet” diariamente com as mensagens… “ A marca (A) apareceu (X) vezes hoje. A marca (B) apareceu (Y) vezes hoje”. Para isso foi necessário que ele listasse as marcas com maior prioridade para serem monitoradas. Todos concordarão que está longe do que foi pedido, entretanto é um bom começo.

Na segunda “sprint” procuramos transformar documento classificado em valor para o cliente. Usufruindo da ideia de valor agregado anterior foi desenvolvida uma planilha, ainda com as mesmas marcas listadas na “sprint” anterior, mas agregando a classificação. Ou seja ele passou a receber na planilha quantas vezes a marca apareceu em um dia em economia, marketing ou em algum dos outros demais conjuntos. O charme estava que na planilha já havia o gráfico plotado. Chegamos mais perto do alvo, mas ainda faltava muito chão.

O valor agregado da terceira “sprint” foi eliminar a lista. Afinal com um mecanismos simples de busca e recuperação o próprio cliente digitava a marca desejada e o sistema construía a planilha. Quase lá, confirmou o PO.

Na quarta “sprint”, em adição a planilha e aos “tweets”, o sistema apresentava online o gráfico originalmente solicitado. Enfim chegamos… Depois de 4 “sprints”!

Esse processo acabou ampliando a satisfação do cliente que terminou com funcionalidades adicionais antes não previstas.

Dois princípios antigos norteiam as perguntas:

  1. Dividir para conquistar; e
  2. Exceda a expectativa do seu cliente.

Embora os princípios sejam antigo o retorno, eu garanto, é moderno. Essa foi a minha experiência. E a qual foi a sua?

Um abraço e até a próxima oportunidade.