Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far, the universe is winning.
Rick Cook em The Wizardry Compiled
Não se ofenda com a provocação se você for programador tampouco se for usuário. Já temos maturidade suficiente pra entender que não existe uma tradução fácil entre os idiomas do ambiente de negócios e o idioma dos ambientes de desenvolvimento. E este é o motivo que me impeliu a escrever este post. Me dê mais 2 minutos, não desista agora!
Partindo do princípio – O que é INVEST?
INVEST é mais uma daquelas siglas legais que ajudam a fixar um conteúdo relevante. Criada por Bill Wake, serve como um gentil lembrete do que um backlog de produto de qualidade precisa compreender, além disso, ressignifica a sigla SMART para o contexto de desenvolvimento de produto (de software, mas flexível o suficiente para o desenvolvimento de qualquer produto).
INVEST significa:
Independent (independente)
Negotiable (negociável)
Valuable (de valor)
Estimable (estimável)
Small (pequeno)
Testable (testável)
Vale dizer também que esta metodologia é fortemente recomendada por Mike Cohn em suas publicações (veja o livro aqui neste link. Caso prefira alguma obra em português, acesse neste link) .
Uma verdade dolorosa
Não esperamos ou não deveríamos esperar que um software seja visto por usuários e engenheiros de software da mesma maneira. Vou adiante, não deveríamos esperar que qualquer que seja o produto seja visto e avaliado da mesma maneira por quem usa e por quem fabrica.
Faça uma analogia e reflita, em um espetáculo de “mágica”, um ilusionista profissional teria a mesma experiência do restante da – leiga – plateia? Os valores percebidos seriam os mesmos?
Agora aplique isso para as relações entre médico e paciente, contador e cidadão, programador e usuário e etc. A premissa ainda é verdadeira? Pois bem, sigamos.
Converter uma expectativa em um produto viável é uma tarefa complexa e não se trata somente da produção do item desejado, precisamos entender que se trata da conversão de um domínio em outro.
Explico, trata-se da comunicação partindo da origem que fala a linguagem de um universo para o destino que fala a língua de outro universo. Cada um em uma margem diferente, separados por um oceano inteiro de experiências, preferências, histórias e por aí vai.
Cabe então a nós, que transformamos a ideia em produto, a incumbência de traduzir e fragmentar os desejos e necessidades em partes comunicáveis e factíveis, reduzindo as chances de fracassos e prejuízos ao longo do processo.
Aqui é que o INVEST faz todo o sentido.
Independent
É bem melhor concluir 80% das histórias do que 80% de cada história. Foque a conclusão das histórias.
Robert C. Martin em Desenvolvimento Ágil Limpo: De volta às origens
Tarefas independentes são fáceis de planejar sua execução e também de executar em paralelo, podendo ser um grande aliado do time do projeto, reduzindo eventuais atrasos ou ainda aumentando o acumulado de entregas.
Raramente existirá, se é que existe, projetos com tarefas unicamente independentes, Mesmo assim, tente escrever as histórias o mais independente possível. Mesmo que uma tarefa precisa esperar o momento certo de ser executada, ela precisa ter começo, meio e fim em si mesma, dessa forma tudo que precisa para compreender o início de uma tarefa e decretar que esta foi finalizada, está dentro dela mesma.
Negotiable (e negotiated)
Os detalhes de uma tarefa precisa ser cocriado com quem irá executar a tarefa. O patrocinador com certeza sabe muito bem do que precisa, mas não sabe tão bem como fazer quanto aqueles que vão fazer, logo, trabalho para várias cabeças realizar.
Defina as tarefas, negocie o seu critério de aceite, negocie como e quando e se precisar, negocie novamente. Um projeto é um organismo vivo.
Imagine que ao longo da execução do projeto, por acompanhar e aprender com o seu desenvolvimento, o patrocinador identifica uma forma de agregar ainda mais valor. Isso não deveria ser aceito de imediato? Pois então, negociem.
Agora pensem no cenário onde algo definido na fase de ideação do projeto realmente não seja possível de ser adicionado por um motivo justificável. Negocie uma saída viável.
Jamais deixe que o time de desenvolvimento estime mais do que uma sprint e meia. A chance de estimativas “perderem a validade” nestes casos é muito grande em virtude de mudanças de arquitetura, dependências, prioridades, etc é muito grande e com isso perdemos o tempo que se levou estimando.
Luis Duarte em Scrum e Métodos Ágeis: Um Guia Prático
Valuable
A story needs to be valuable. We don’t care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive
them as important.
Bill Wake em INVEST in good stories: the series
Com esta analogia, Bill Wake quer dizer que devemos “cortar na vertical” as camadas do bolo e não na horizontal, caso contrário serviríamos só a cobertura, depois só a massa, depois só o recheio e assim por diante. Isso não se parece com um bolo de aniversário, certo?
Este requisito é um grande desafio quando se precisa dividir requisitos em histórias (Épicos em Histórias, se você preferir). Bill Wake recomenda pensar em uma história como um bolo de várias camadas (um bolo de aniversário, por exemplo), quando estamos dividindo uma história é como se estivéssemos servindo um pedaço do bolo.
Pensando em um produto de software, é melhor pensar as histórias de forma que possam ser usadas pelo usuário. Criar todas as tabelas em um banco de dados mas não ter como acessá-las, pode dar muito trabalho, mas não entrega muito valor ao cliente, assim como ter uma interface de sistema desenhada mas que não pode ser utilizada pelo cliente pois não se conecta com as outras partes do sistema. Estes são exemplos de “cortes horizontais” que devem ser evitados quando queremos escrever boas histórias de usuários.
Estimable
Dizer que uma história precisa ser estimável não quer dizer que o seu valor tem que ser preciso ou que este valor deverá estar escrito na pedra, pois se fosse, o conceito de negociável não faria sentido, certo?
Uma boa história precisa ser estimada o suficiente para ajudar no ranqueamento e agendamento da sua implementação. Senão veja, 10 histórias de 5 pontos não deveriam estar juntas na mesma sprint se a capacidade de produção do time é de 30 pontos. Faz sentido? Neste caso ter estimativas nas histórias ajudarão o time a priorizar e selecionar as histórias que devem estar juntas na próxima rodada de desenvolvimento do produto (ou sprint).
Small
Boas histórias tendem a ser pequenas, suas descrições também. Não que devemos economizar informações, somente não colocar coisas que tornem a leitura e entendimento da história confusa ou ainda controversa. Alistair Cockburn descreve os cards das histórias como “fichas prometendo uma futura conversa”.
Histórias menores tendem a ter a acurácia da estimativa maior, reduzem os riscos de implementação e são mais facilmente verificáveis.
Testáveis
Se um cliente não sabe como testar alguma coisa, isso pode indicar que a história (o seu requisito) não está claro o suficiente ou que esta história não reflete algo de valor. Ou pode ainda indicar que este cliente precisa de ajuda para formular o seu pedido e consequentemente os casos de teste.
Clientes tendem a descrever somente o caminho feliz de uma atividade, se esquecendo de todas as exceções que precisam ser consideradas na rotina de alguma atividade. Preparar um produto para estas exceções pode facilmente ser o maior esforço no desenvolvimento da história e consequentemente do produto como um todo.
Finalmente
Escrever boas histórias é uma atividade multidisciplinar e para ser feita em grupo. Da ideia à execução passando pelo planejamento e estimativas requer revisões, negociações, adaptações, comparações, etc. Nada disso é possível de ser feito sem o envolvimento de quem idealiza e de quem executa.
Experimente adotar a sigla INVEST nas próximas vezes que for pensar o desenvolvimento de um produto. Se você se lembrar, volte aqui e comente sua experiência. Até a próxima.
Acesse conteúdos sobre INVEST e muito mais no site do XP123 de Bill Wake clicando aqui e faça o download do e-book sobre INVEST neste link.
