Um dos valores do manifesto ágil é “Software em funcionamento mais que documentação abrangente” e devido a isso é comum escutar que ao utilizar metodologias ágeis de desenvolvimento de software não é necessário se fazer especificações das atividades que serão desenvolvidas, pois isso seria um desperdício e desperdício é anti-ágil. Mas será que isso é realmente verdade?
Antes de tudo, um breve histórico
A forma mais “tradicional” de se desenvolver software, seguindo a cartilha do PMI, diz que antes de desenvolver qualquer linha de código é necessário um processo de análise detalhado do que será feito, geralmente por um analista de negócios e/ou um analista de sistemas. Só após uma detalhada documentação ter sido elaborada é que as especificações chegarão até os desenvolvedores e, no melhor estilo watherfall, o software será desenvolvido.
Com a chegada das metodologias ágeis, principalmente do Scrum, as especificações das histórias a serem desenvolvidas começaram a ficar cada vez menores. Uma das características do agile é justamente especificar o que precisa ser desenvolvido ao longo do desenvolvimento, ou seja, de acordo com a necessidade. Dessa forma é muito comum o time de desenvolvimento receber uma atividade sem especificação alguma, indo na direção oposta ao watherfall.
Esse processo de alternância entre “tudo ou nada” é natural, aconteceu em vários outros casos, mas com o tempo as coisas tendem a encontrar um equilíbrio. Como citado neste ótimo artigo do Ben Yoskovitz um exemplo disso é o Plano de Negócio. No início, antes de abrir qualquer negócio, o primeiro passo era escrever páginas e páginas do seu Plano de Negócio, o que se mostrou um desperdício completo. No entanto não pensar nos detalhes do seu negócio e simplesmente começar a empresa também não é melhor saída. A solução foi planos de negócios mais enxutos, como o Business Model Canvas (BMC) ou o Lean Canvas, um ótimo ponto intermediário entre não conhecer nada do seu negócio e efetivamente fazer um Plano de Negócio completo.
Certo, mas especificação é mesmo um desperdício?
Sim e não, depende como for feito. Na grande maioria dos casos não vejo necessidade alguma em elaborar vastas documentações, diagramas de UML, especificação funcionais e não funcionais e por ai vai. Muito menos se você estiver utilizando algum tipo de metodologia ágil, seja Scrum, Kanban, XP ou qualquer coisa nessa linha. Mas não fazer uma documentação abrangente não significa necessariamente não fazer documentação alguma. E tão pouco significa não ter desperdício.
Como Petri Kainulainen explorou muito bem neste artigo, na inexistência de especificação, caso o time de desenvolvimento tenha alguma dúvida, existem basicamente duas opções: perguntar para o Product Owner (dependendo da estrutura da sua equipe pode ser um Gerente de Produto ou ainda um Gerente de Projeto) ou improvisar. Se a escolha for perguntar para o Product Owner isso envolve tempo tanto do Scrum Master quanto do PO e ainda pode ser necessário esperar por esta resposta caso o PO não saiba ou não esteja disponível no momento. Por outro lado, se a opção do time for por improvisar, pode ser que a decisão tomada pelo time ou pelo Scrum Master não seja a melhor opção e precise ser refeita posteriormente. Dessa forma, será que o time não saber o que fazer e ter que perguntar ou tomar a decisão errada não é mais desperdício do que se fazer uma especificação enxuta? Na minha opinião a perda é muito maior.
Mas então como fazer uma especificação de forma ágil?
Pense no seguinte, qual é o mínimo necessário para que o time de desenvolvimento possa executar uma tarefa com sucesso? Na minha experiência são basicamente quatro coisas, entender o que precisa ser feito, que problema esta sendo resolvido, quem e como irá utilizar a funcionalidade posteriormente e o que precisa ser entregue. Esses quatro aspectos eu represento da seguinte forma:
História de usuário
Toda história que entra em uma Sprint é descrita no formato de user stories ou seja, algo como “Como um <usuário>, eu gostaria de para que ”. Esse formato ajuda muito os desenvolvedores a entenderem de uma forma simples o que precisa ser feito.
O problema
Tudo que é desenvolvido precisa, necessariamente, entregar valor para alguém. Se algo esta entregando valor é porque esta resolvendo algum problema, mas que problema é esse? Defina exatamente que problema determinada história esta resolvendo, dessa forma vai ficar muito mais claro para o seu time de desenvolvimento saber se o que estão fazendo realmente vai atingir o objetivo final.
Casos de uso
Ok, nesse ponto o seu time já sabe o que precisa ser feito, para quem e porque, mas como essa funcionalidade vai ser usada depois? Defina em uma frase curta cada caso de uso da nova funcionalidade. Essa informação irá ajudar muito na hora do time escrever os testes automatizados e garantir que todos os casos foram cobertos pela funcionalidade que está sendo entregue.
Testes de aceitação
Por fim, é importante que o time saiba tudo o que precisa ser entregue. Isso pode ser feito definindo os Testes de aceitação ou Definição de pronto (DoD, Definition of Done). Isso é de fundamental importância para que o time saiba tudo o que realmente precisa entregar, que nem sempre é só a funcionalidade codificada. Alguns critérios do DoD podem ser, por exemplo, atualizar a central de ajuda, migrar dados ou ainda enviar algum email de comunicação. Deixar isso claro desde o início evita esquecimento e retrabalho.
É importante ressaltar que a especificação como descrevi não está escrita em pedra, é importante que ela seja entregue para o time de desenvolvimento de uma forma que possa ser alterada se necessário. Mas, caso isso aconteça, é necessário o alinhamento com o Scrum Master, porque essa alteração pode afetar a estimativa inicial de esforço necessária para conclusão da tarefa.
Esses quatro aspectos que destaquei a cima são como eu gosto de especificar as histórias que seleciono para o time de desenvolvimento mas, como tudo, está em evolução constante. A um ano atrás era diferente e daqui a ano com certeza não será exatamente assim. Também não uso nenhuma ferramenta específica para isso, atualmente uso o Trello mas já utilizei o Kerika, o Asana e o Pivotal Tracker também. No fim do dia o importante é você analisar exatamente qual é a sua necessidade e quais são as ferramentas disponíveis e ver o que melhor se adapta a sua necessidade, sempre com um pensamento de melhoria contínua. Mas uma coisa eu garanto, é possível fazer especificação enxutas e elas vão evitar muitos desperdícios!
