Bons produtos e projetos não começam com hipóteses. Sua pedra fundamental é o correto entendimento dos objetivos – do valor que devem gerar. Histórias de Valor ajudam a descobrir e descrever essas informações. Elas dão sentido ao roteiro de trabalho (roadmap e backlogs) e facilitam a contagem das realizações e de outras histórias.
As Histórias de Valor, como vimos no artigo anterior, usam o formato clássico das Histórias de Usuários:
Como <organização> precisamos <criar algo> para <realizar tais objetivos>
Como finito eu preciso retomar as conversas com a comunidade Ágil para viabilizar algumas turmas da oficina FDP³.
Histórias de Valor tapam um buraco meio desconcertante dos métodos ágeis. Nessas propostas utilizamos dois catalisadores de informações nas interações com clientes e usuários: Histórias de Usuários e Épicos. Recentemente começamos a falar sobre Job Stories. Suas diferenças estão fora do escopo deste artigo¹. O que essas ferramentas não explicam é a motivação para aquele projeto ou produto. Afinal, mirando o todo, qual e quanto valor pretendemos gerar?
Você pode dizer que estamos reinventando rodas. Afinal, já temos ferramentas com esse fim: Business Cases, Project Charters, Documentos de Visão e por aí vai. O grande problema é que esses documentos são de outra era. Repare, são documentos. Por simpáticos que sejam, trazem consigo a pesada bagagem do mundo cascata. É o mesmo problema do termo requisito, por exemplo. Agregar o sobrenome “Ágil” não anula seu histórico. Quando o Scrum chegou com novos nomes – Product Owner, ScrumMaster, Sprints – foi exatamente para evitar qualquer mínimo vínculo com os métodos e modelos que pretendíamos abandonar.
História de Valor não é um documento. É um catalisador. Repito o termo. É importante explicá-lo. Catalisador, segundo nosso dicionário, é “o que estimula ou dinamiza”. Histórias, em métodos ágeis, têm essa finalidade. São o exato oposto dos documentos. Estes servem para encerrar discussões. Histórias estimulam discussões. São dinâmicas. Se prometemos receber mudanças de braços abertos, é importante que nossas ferramentas incentivem e facilitem isso.
Mapa e Bússola
Joi Ito e Jeff Howe, no excelente Whiplash², colocam que nesses novos tempos a bússola é mais importante que os mapas. O mapa é um plano. A bússola, direção. O Manifesto Ágil, em outras palavras, afirma o mesmo desde 2001: “Responder a mudanças mais do que seguir um plano”. Mas as nossas respostas não podem variar como uma biruta. Qual é a nossa bússola? As motivações expressas em cada História de Valor.
Não dispensamos os mapas. Eles seguem importantes. Mas não fazem muito sentido sem a bússola. Jeff Patton presta um serviço ímpar em User Story Mapping (O’Reilly, 2014). Ele repete, sempre que necessário, que um bom mapa de histórias é orientado por resultados. O único defeito do livro é não definir uma forma para a representação desses resultados. Histórias de Valor servem para isso. Com a vantagem de respeitar o padrão utilizado em todo o mapa.
Na Prática
A primeira coisa é não confundir Histórias de Valor com Épicos. Estes são histórias aguardando detalhamento e a inevitável quebra em mais histórias. Épicos podem representar módulos de um sistema ou funções extensas. Histórias de Valor, por outro lado, representam o negócio. Ou, melhor dizendo, um resultado esperado pelo negócio. Se esse resultado depende de uma ou mais funcionalidades – de uma ou mais histórias de usuários ou épicos – não interessa. Aliás, uma história de usuário pode colaborar em diversas Histórias de Valor. Mas ela só pode pertencer a um épico.
Histórias de Valor são o ponto de partida de qualquer produto ou projeto. Pegamos a bússola, descobrimos a direção e só então desenhamos um mapa (ou roteiro – roadmaps, Mapas de Histórias e backlogs). Por óbvio que isso soe, quantas vezes você testemunhou um projeto sendo iniciado a partir de Histórias de Usuários? Essa carroça bem adiante dos bois, infelizmente, é um mal recorrente. E causa principal de nossos problemas.
Histórias de Valor não são atômicas. Elas podem ser quebradas de forma a representar uma hierarquia de objetivos e metas. É normal que um projeto tenha algo entre cinco e dez Histórias de Valor. Essa organização facilita a elaboração de um Mapa de Histórias. Mais que isso: facilita o monitoramento dos resultados obtidos. E também pode ser registrada na forma de OKRs ou LogFrames. Pense na possibilidade: o Mapa de Histórias é o detalhamento de um ou mais OKRs. Cada entrada no OKR é uma História de Valor.
Hipóteses, de novo…
No artigo anterior critiquei a definição de Valor para o Negócio apresentada por Mark Schwartz em The Art of Business Value (IT Revolution Press, 2016). Ele escreveu que o Valor para o Negócio é “uma hipótese formulada pela liderança sobre a melhor maneira de realizar os grandes objetivos da organização”. A História de Valor nos livra dessa armadilha. O que escrevemos na frente do para não é uma hipótese. É um objetivo claro e devidamente quantificado³. É o Valor para o Negócio. A hipótese existe, mas está em outro lugar: na descrição do que nós precisamos.
Essas confusões entre o QUE e o COMO e a perigosa mania de tratar tudo como hipótese vão merecer mais conversas. No próximo artigo, a segunda parte de nosso Checkup Ágil, volto a puxar o assunto.
Notas
- Neste artigo do Fabrício Teixeira há uma bela comparação entre User Stories e Job Stories.
- Em pt-br esse livro mereceu o terrível título “Disrupção e Inovação” (Alta Books, 2017). Por isso temo pela qualidade da tradução. Falo um pouco mais sobre ele neste artigo.
- O exemplo com a FDP³ não representa um bom uso da História de Valor porque não se compromete com números. “Algumas turmas” é ambíguo demais para ser aceito em qualquer contexto ou projeto. O exemplo é interesseiro – vendi meu peixe sem meias palavras.
- A foto utilizada neste artigo foi compartilhada por Martin P. Szymczak no flickr.
