Recentemente tivemos uma discussão na equipe da qual faço parte sobre o quão importante é a definição dos requisitos de uma história antes de iniciarmos a sua execução. A opinião de todos foi unânime: não dá para começar a desenvolver uma solicitação antes de saber quais são as necessidades envolvidas e onde se espera chegar com aquela solução. Mas como deve ser esse processo? Com que nível de detalhe essa especificação precisa ser realizada? Como ela deve ser descrita? Todos esses questionamentos, e muitos outros, possuem respostas altamente dependentes do projeto que estamos tratando. No entanto, existem alguns princípios que a gente pode adotar que acabam auxiliando qualquer equipe e qualquer demanda, além de evitar problemas recorrentes na TI.

Problema #1: O que entregamos não era o que o cliente esperava.

Esse problema é recorrente em muitos projetos de software. O Scrum já nos ajuda a evitar esse problema devido às constantes inspeções e verificações que são feitas junto ao PO, mas mesmo assim isso pode ocorrer. Pode ser que a pessoa que ficou responsável por descrever aquela demanda deixou de fora pontos que, na Sprint seguinte, podem gerar retrabalho ou até aquela sensação de “fazer tudo do zero”.

Então, para evitar ao máximo essa situação, é importante que as especificações de novas demandas sejam realizadas junto às pessoas que realmente tem conhecimento sobre o requisito. Em muitos casos essa pessoa é o próprio PO, mas não há problema algum em envolver, em uma reunião de planejamento, a área da empresa que está demandando aquela funcionalidade, por exemplo.

Trazer os interessados para as reuniões de Planejamento e Revisão faz com que o feedback e a troca de informações sejam mais rápidos e mais precisos. No final, as decisões continuam sendo do PO, mas ter a opinião de quem está diretamente envolvido com o negócio a ser tratado é muito importante e pode evitar uma série de ruídos que venham a surgir na comunicação entre interessados, PO, time de desenvolvimento e quem mais estiver envolvido.

Problema #2: Começamos a desenvolver sem ter todos os pré-requisitos definidos.

A definição de história preparada existe e deve ser respeitada. Muitas vezes as pessoas acabam passando por cima dela na intenção de antecipar o início do desenvolvimento de uma demanda devido à urgência da mesma. O problema disso é que o time de desenvolvimento acaba assumindo a existência de outros recursos e suas definições para prosseguir com o andamento da história, para ir de encontro à expectativa do PO de que fazer isso antecipará a entrega da demanda.

A questão é que, na verdade, essa estratégia pode até atrasar a entrega. Isso acontece porque diversas decisões são tomadas acreditando que existirá uma determinada estrutura de banco ou um determinado retorno de outro sistema, por exemplo, que não se concretiza. Assim, o time tem de lidar com retrabalho ou então com impedimentos que paralisam o andamento da história.

Por isso, estabeleçam e respeitem a definição de história preparada dos seus projetos. A ilusão de que começar a desenvolver sem ter todos os itens da definição prontos é realmente apenas uma ilusão e não trará bons frutos depois. Pelo contrário, pode até prejudicar o cronograma inicial estabelecido.

Problema #3: Fizemos do jeito que achamos que deveria ser, mas não era.

Esse é outro problema causado por “colocar a carroça na frente dos bois”. Se a história não está preparada e é iniciada, chegará um ponto em que a equipe terá dúvidas. Caso a resposta para essas dúvidas não venha, ou a história ficará impedida e paralisada, ou o time assumirá definições que nem sempre serão verdadeiras. Outro efeito colateral disso é que tomar decisões sobre assuntos que não se tem domínio gera extensa discussão desgastando a equipe e gerando longas reuniões ou longas trocas de e-mail.

Então, mais uma vez, vamos respeitar a definição de preparada!

Problema #4: Fizemos a funcionalidade e ninguém usa.

Isso acontece diversas vezes, infelizmente. E muitas vezes o esforço para criar aquela funcionalidade é bastante grande e acaba que, no fim, acaba sendo trabalho desperdiçado, pois ninguém usa aquilo. Outra ponto negativo é que se isso começa a acontecer com frequência, pode acabar desestimulando a equipe de desenvolvimento que espera ver seu trabalho ajudando o usuário e, no fim, descobre que aquilo nunca foi para frente.

Uma forma eficiente de acabar com este problema é envolver na especificação da demanda representantes dos usuários. Ninguém mais que eles têm conhecimento sobre o negócio e sobre as necessidades que eles têm em relação ao produto. É claro que eles não vão interferir em questões técnicas da criação da funcionalidade, mas contar com a opinião para ter detalhes sobre o funcionamento e as regras de negócio e validar, até mesmo antes de implementar, se é isso mesmo que ele espera, é fundamental para evitar este problema.

Problema #5: Ninguém sabe porque tal funcionalidade é assim.

Existe o mito de que agilidade está ligada à falta de documentação, mas isso não é verdade. Na realidade, é importante sim documentar para que exista um histórico de mudanças do produto e lá na frente, se for necessário, seja possível verificar e justificar por que determinadas funcionalidades funcionam daquela maneira.

A forma como essa documentação será realizada depende das definições de cada equipe Scrum. É legal definir isso com todos os envolvidos inicialmente e incluir essa documentação na definição de história pronta. Isso vai garantir que toda história finalizada tenha a documentação necessária criada, no nível de detalhe desejado e acordado previamente por todos. Assim a gente documenta o software, tem histórico e continua sendo ágil.

É claro que esses 5 pontos não vão resolver todos os problemas de especificação, retrabalho etc que existem em um projeto. Mas acredito que se seguirmos essas estratégias, é possível diminuir significativamente esses 5 problemas que acabam frustrando usuário e equipe Scrum.