Sistema: para entendermos que o TODO deve ser maior que a soma das partes; Para fazer com que as ferramentas conversem entre si. Como o JTBD troca ideias com um OKR? De que forma eles se relacionam com épicos e histórias? Como eles apoiam a organização e priorização do backlog? Precisamos de um mapa.

Mapa Rico

São duas as principais inspirações para a sugestão que segue. A primeira é o Pensamento Sistêmico. Mais especificamente, a Rich Picture proposta por Peter Checkland somada ao DSRP. A segunda fonte de inspiração é o livro User Story Mapping de Jeff Patton (O’Reilly, 2014). Vejamos.O diagrama é formado por três camadas: Bússola, Mapa e Roteiro.

Bússola: seja dia ou noite, faça chuva ou faça sol, ela sempre nos dá o norte. Em nosso caso, ela sempre lembra as motivações do produto. Motivações, no plural, porque buscamos criar valor para o cliente (expresso no JTBD) e para o negócio (VS – Value Stories). Um GPS sempre ajuda. Aqui ele atende pela sigla OKR (Objectives and Key-Results). Você informa para onde quer ir (JTBD + VS) e ele te guia, mostrando a sua distância em relação aos Resultados-Chave. O ‘O’ de objetivo é o elo entre as três ferramentas.  

Mapa: se estamos falando de um produto ou serviço que será comercializado, faz sentido que o mapa capture toda a jornada do cliente. Por isso temos um cabeçalho identificando o que ocorre Antes, no Início, Durante e Depois da compra ou contratação. A inspiração aqui é o Service Blueprint. Na primeira linha desenhamos as ações do cliente na forma de um fluxograma. Na linha inferior colocamos o trabalho interno – tudo o que precisa ser feito para que o cliente tenha aquela experiência. Se você registrou Atividades-Chave em um Business Model Canvas, por exemplo, é nessas duas linhas que elas serão desenhadas. Se você identificou Recursos-Chave no Canvas, faz sentido explicar quando e onde eles serão necessários. Daí a terceira linha do mapa. Jeff Patton é econômico nesta camada, mas não desmerece o seu valor. Tanto que a trata como o Backbone (espinha dorsal).

Roteiro: ou, para ser menos direto, Roadmap + Product Backlog. Porque um backlog orientado pelo negócio, pela experiência do cliente, faz muito mais sentido do que uma fila indiana. Quando alguém vê um item², entende não apenas o que ele é e deve fazer mas também o seu propósito. O contexto está dado: onde e quando aquela função ou atributo é necessário. A posição vertical dos itens indica prioridades. Quanto mais alto, maior a contribuição do épico/história para a realização dos resultados descritos no OKR. Mas não ficamos só nisso. Em cada item devemos registrar o seu valor³. E, oportunamente, também o seu custo. As linhas divisórias do roteiro são traçadas em outro momento, quando já temos razoável noção do que precisa ser feito. Podemos dizer que a primeira linha representa o MVP/MVS (Minimum Viable Product / Solution). O importante é que cada linha (cada versão do produto) se comprometa com resultados. Daí o lembrete ou detalhamento de OKRs no canto direito do diagrama.

O mapa é uma ferramenta que pode acomodar, como no exemplo acima, outras ferramentas. Não é uma colcha de retalhos. É um sistema. Ou, caso queira, é uma história que deve ser contada de forma colaborativa. E iterativa. O mapa evolui na medida em que navegamos entre os trabalhos de descoberta, exploração, desenvolvimento e entrega.No exemplo acima tivemos que colocar o roteiro no lado direito. A bússola (post-its no topo e anotações no canto) foi junto.

As informações (quem, o que, quanto, onde, quando) descobertas, o conhecimento (como) desenvolvido e a compreensão (por que) alcançada com o apoio das ferramentas citadas são essenciais para o desenvolvimento de um produto. O Mapa Rico pode ser a principal ferramenta de um PO. Mas, claro, não pode ser a única.

Notas

1. E isso justifica, em partes, o intervalo de dois meses desde o último artigo. As sugestões aqui apresentadas foram testadas em uma turma da oficina FDP e com três times do Ateliê de Software, uma empresa que é 100% Ágil há dez anos. Agradeço ao pessoal do Ateliê pela oportunidade e acolhida. E ao Will pela foto.
2. O diagrama indica quatro formatos possíveis para itens: Épicos, US – User Stories, JS – Job Stories e UC – Use Cases. Poderia ter citado protótipos também. Não são variações do mesmo tema. Cada formato captura informações e perspectivas diferentes. Vale sempre lembrar: só a variedade absorve variedade. E existe coisa mais variada do que desejos, necessidades, restrições e caprichos de clientes e usuários?
3. Se você pretende utilizar um conjunto da sequência de Fibonacci ou escalas mais simples não importa. Importante é que isso seja pensado e negociado. E que a régua definida para o Valor seja a mesma utilizada na aferição dos custos. 
4. Rectilinear, de Stuart Caie, ilustra este artigo.

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

1. Neste artigo do Fabrício Teixeira há uma bela comparação entre User Stories e Job Stories.
2. 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.
3. 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.
4. A foto utilizada neste artigo foi compartilhada por Martin P. Szymczak no flickr.

Valor

O Manifesto Ágil diz que a “nossa principal prioridade é satisfazer o cliente através da entrega adiantada e contínua de software de valor”. Fica por nossa conta descobrir o que significa software de valor. E entender que existem mais valores em jogo: há o VALOR PARA O CLIENTE, claro, mas não podemos ignorar o VALOR PARA O NEGÓCIO e o possível VALOR PARA O TIME. Mais que isso, é crucial entender as relações entre esses valores.

Apesar das diversas e desastradas manifestações ao contrário¹, VALOR é o nosso mais importante sinal vital. Mas, como vimos, não há um valor único. Muito menos um entendimento compartilhado sobre o que ele significa. Vamos por partes.

Valor é a medida da importância de algo. Até que ponto aquilo que vale para o seu negócio (departamento ou time) é valorizado pelo seu cliente (ou usuário)? Convenhamos, há poucas chances de acordo ou coincidência. Por isso não devemos confundir VALOR PARA O NEGÓCIO com o VALOR PARA O CLIENTE e/ou USUÁRIO. Cada um puxará a sardinha para o seu lado. Todos repletos de razão.

O que significa VALOR PARA O NEGÓCIO? Mark Schwartz, em The Art of Business Value (IT Revolution Press, 2016), escreve 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”. Hipótese? Está aqui um terrível legado da moda Lean Startup: parece que tudo virou hipótese. O que tem valor para você é apenas uma hipótese? Duvido. Mas, como comprova o livro do Schwartz, quanto mais pessoas envolvemos, mais esse papo sobre valor fica variado, estranho e difícil.

Donald Reinertsen (em Managing the Design Factory – Free Press, 1997) tem uma navalha para cortar toda essa variedade: “somos apenas filósofos enquanto não começamos a usar números”. Então, vamos aos números!

Números

Como você mede e apresenta o VALOR PARA O NEGÓCIO? Quais números fazem mais sentido? ROI (Retorno sobre o Investimento) e NPV (Valor Presente Líquido), por exemplo, são proxies que se sustentam em previsões. Nós humanos não somos muito bons nisso, em fazer previsões. Segundo Schwartz, “ROI e NPV são o waterfall do mundo financeiro”. Ainda mais importante: o cálculo de ambos, ROI e NPV, exige um numerador que é a representação do valor. Oras, então por que não nos contentamos com ele?

O uso do Custo do Atraso (CoD – Cost of Delay) é defendido por Reinertsen e Schwartz. Mas ele também depende de uma definição prévia do Valor. Se não sabemos quanto vale, como podemos afirmar ou ao menos prever o custo de seu atraso? Estamos andando em círculos?

ROI, NPV, CoD e afins representam hipóteses. Carregam incertezas e podem, dependendo do nível de sofisticação, dificultar a comunicação entre os envolvidos em determinada iniciativa. Não pretendemos filosofar. Mas que valor tem uma sequência de cálculos que poucos entendem? É sempre bom relembrar o décimo princípio do Manifesto Ágil: “Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.” Conseguimos exprimir o VALOR PARA O NEGÓCIO de forma simples e direta?

Histórias de Valor

Como a Natureba S/A
nós precisamos de um app que permita que as nossas consultoras registrem e transmitam pedidos em tempo real
para encurtar o ciclo de vendas em 50% e cortar algo entre R$15M e R$25M dos custos anuais de processamento de pedidos.Como a Webchuteira LTDA
nós precisamos de um programa de fidelidade vinculado aos sistemas sócio-torcedor dos grandes clubes nacionais
para aumentar o nosso market share em 40% e o faturamento em, pelo menos, R$100M no próximo ano.Não é curioso que essa proposta simples, derivada do formato clássico das User Stories, seja tão pouco conhecida? Aliás, por favor, não se apegue ao formato. O importante aqui é o que essas histórias nos contam. Conversaremos mais sobre isso no próximo artigo. Porque agora é um bom momento para um autoexame.

Autoexame

Você e seu time sabem quanto VALOR estão criando e entregando?

Se sim:

• Esse entendimento é compartilhado por todas as pessoas envolvidas?
• A sequência do roteiro (roadmap e backlogs) reflete nitidamente essa preocupação com a entrega antecipada e contínua de valor?

Se não:

• O que diabos está orientando as milhares de decisões que vocês tomam todo santo dia?

Notas & Esculachos

1. D’ A Startup Enxuta, de Eric Ries (Leya, 2012), ganhamos essa perigosa e triste mania de achar que tudo é hipótese.
2. De Jeff Sutherland, cocriador do Scrum, herdamos o peso da promessa do título de seu último livro: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo. O sonho dos tayloristas deveria ser o pesadelo dos agilistas. Afinal, estes se comprometeram com outra arte, a de “maximizar a quantidade de trabalho que não precisou ser feito”.
3. No Kanban, de David Anderson (Blue Hole, 2010), aprendemos uma “Receita de Sucesso” que só permite conversar sobre VALOR no penúltimo passo de um total de seis. Orientado por uma mentalidade que não tem muito a ver com o trabalho criativo, o último passo da tal receita ainda pede que “ataquemos as fontes de variabilidade”. Não surpreende que o mesmo autor ressuscite agora uma conversa sobre Modelos de Maturidade. O Kurt Cobain vem junto? No carro preto do Ford? Nevermind…
4. Stickynotes, de Martijn Veening, ilustra este artigo.

Como já reclamei aqui em outras ocasiões, nossa área adora reinventar algumas coisas. Começar do zero, ao invés de melhorar algo que já existe. Assim nasceram as User Stories, peça fundamental da metodologia-religião popularmente conhecida como XP (eXtreme Programming). Segundo um de seus apóstolos, as User Stories são formadas por três elementos:

• Cartão: onde escrevemos as estórias ;
• Conversas: que nos levariam a entender e detalhar as estórias; e
• Confirmação: o ‘the end’, o fim da estória.

A motivação para tamanha invenção gira em torno da palavrinha ‘documentação’ (um dos pecados mortais, segundo aquela doutrina). Por isso outro apóstolo reforça: “os cartões representam os requisitos do cliente, mas não os documentam”. Vai na linha de um mestre-pacificador (mezzo tucano) que vive insistindo: “gente, modelagem não é documentação… modelagem não é documentação… isso é um mito”. Documentação parece um trauma incurável. Mas falarei mais sobre isso em outras oportunidades. A história aqui são as estórias.

No post anterior eu destaquei um probleminha com o processo adotado pela Anne: “Nós organizamos as cento e poucas estórias por processos de negócios…”. Vai na linha do problema reconhecido por aquele primeiro apóstolo (que escreveu um livro só sobre estórias) : “É difícil saber por onde começar”.

Se o trabalho começa por uma correta análise do negócio e seus processos, não devem existir dúvidas sobre o ponto de partida. Ao organizar os trabalhos de coleta e análise de requisitos a partir dos processos de negócio, não existe o trabalho de “organização de estórias”. Assim, não há justificativas para adoção do POREM (Post-it-Oriented Requirements Elicitation Method).

Ironias à parte, o fato é que as user stories, apesar de bem intencionadas, trazem mais problemas (inclusive alguns que não existiam antes) do que soluções. Sua granularidade e a doentia independência dificultam o gerenciamento; Tornam as atividades de priorização e planejamento das iterações bastante confusas. Ou seja, sua utilização em projetos médios e grandes deve ser um pesadelo .

Se começamos do começo, ou seja, pela análise do negócio e seus processos, é mais natural a adoção dos Casos de Uso como técnica para coleta, organização e análise de requisitos. Segundo seu criador , “um caso de uso é o nosso constructo para um processo de negócio”; ” descrevem o negócio e o seu ambiente”.

A adoção de casos de uso não significa, de maneira alguma, deixar de ser ágil. Aliás, se bem adotada, a técnica deve promover maior agilidade do que as estórias. As 6 qualidades das boas estórias também devem caracterizar os bons casos de uso :

• Independentes: até o limite onde a independência é desejável, ou seja, até o ponto em que ela não gere surpresas e omissões no projeto;
• Negociáveis: se o cliente e demais stakeholders não puderem negociar os casos de uso, o que sobra?
• Valiosos para Usuários e Clientes: óbvio? Nem tanto. Vide o tanto de caso de uso descrevendo CRUD’s e afins por aí.
• Estimáveis: ok, UCP‘s são frágeis. Tanto quanto todos os outros métodos conhecidos. Mas, independente do método, casos de uso são (ou deveriam ser) estimáveis.
• Pequenos: não tanto quanto uma história, mas o suficiente para representar uma unidade significativa para o negócio (seja ela uma tarefa, atividade ou processo). Se um caso de uso for grande ou de difícil leitura ele está errado – regrinha básica;
• Testáveis: wow. Outra regrinha: se não pode ser testado então não é um caso de uso. Deriva de outra regrinha que diz que : “Se um requisito não pode ser testado então ele não é um requisito”.

Resumo da ópera cômica: sejamos ecologicamente responsáveis: post-its e cartões são feitos de árvores; vamos parar com esse papo de ‘casa de ferreiro… espeto de bambu’ (bambu solta farpas); municiemos nossas equipes e stakeholders com informações consistentes, bem pensadas, analisadas e estruturadas…

… começando do começo: o Negócio.

Notas:

1. Não tenho (quase) nada contra XP e afins. Meu problema é só com os fundamentalistas mal educados e donos da verdade suprema. XP e afins foram úteis, representaram um avanço, chacoalharam o status quo. Ou seja, foram um mal necessário.
   
2. User Stories Applied: For Agile Software Development
   Mike Cohn. Addison-Wesley (2004).
   Obs: Mesmo autor do artigo sobre UCP referenciado acima.
3. Lembram-se daqueles livrinhos da Ediouro que sempre traziam uma discussão sobre “estória versus história”? Pois é, me lembrei deles na hora de traduzir stories.
4. The Power of Stories
   Rachel Davies. XP 2001.
5. Debunking Modeling Myths
   Scott W. Ambler. Software Development (Agosto/2001).
6. Deve ser (um pesadelo). Nunca testei e nunca terei coragem para tanto.
7. The Object Advantage – Business Process Reengineering with Object Technology
   Ivar Jacobson. Addison-Wesley (1995).
8. Requirements-Led Project Management
   Suzanne e James Robertson. Addison-Wesley (2005).

Um sintoma que indica que o trabalho da equipe da Anne começa ‘muito solto’ pode ser identificado na seguinte sentença: “Nós organizamos as cento e poucas estórias por processos de negócio…”

Parece que as estórias são coletadas de uma forma aleatória. Os tais ‘workshops para coleta de estórias dos usuários’ não são orientados por um estudo anterior. Parece natural que, com uma granularidade tão fina (estórias são ou devem ser pequenas), o trabalho de planejamento das iterações e priorização das estórias fique bastante confuso.

Se o AN começar seu trabalho “do início”, ele não terá o trampo de “organizar estórias por processos de negócio”. Ele realizará a coleta por processos ou atividades de negócio. Além do levantamento e classificação básica dos processos, que comentei brevemente neste post, o AN também deve determinar (claro – em conjunto com os clientes e usuários) a priorização dos processos e / ou atividades de negócio. Depois, cada workshop (ou qualquer outra técnica de levantamento) é programado para cuidar especificamente de um processo ou atividade.

Claro, as coisas nunca são assim tão simples. Processos se relacionam; atividades geram impactos em outras atividades. O AN deve ter uma clara visão dos relacionamentos e restrições. E essa visão só é possível depois de um estudo e mapeamento dos processos. Antes que gritem: não se trata de nada detalhado, de nenhum tipo de estudo que custe 2 ou 3 meses ao projeto. Um mapa em alto nível, que considere apenas os fatores fundamentais, é suficiente. E pode ser gerado em poucos dias de trabalho.

Me desculpem o rabisco, mas usando uma variação da UML o mapa de processos pode ficar mais ou menos assim:

Os objetivos ou metas de cada processo são praticamente os primeiros requisitos que um AN conhece. Eles derivam dos grandes objetivos do negócio, que podem estar documentados em planos estratégicos ou em coisinhas mais modernas como Balanced Scorecards e Mapas Estratégicos. Nossa área é estranha: já vi várias equipes de projetos trabalhando sem a mínima noção de quais eram os objetivos daquele processo de negócio que eles estavam automatizando ou otimizando. Para que exigir um mapa quando a viagem não tem destino?

Nota: Mapa = um ‘pouquinho’ de planejamento up front‘.

Mas este não foi o único probleminha que vi no depoimento da Anne. Encuco também com as ‘estórias’. Em outro post eu falarei sobre elas e as vantagens dos casos de uso.

Observações:

1. Não se trata de um trabalho isolado. O AN pode ou deve estar acompanhado de outros membros da equipe no momento da coleta, análise ou refinamento dos requisitos.
2. Todos os diagramas da apostila/livro, por enquanto, estão no padrão “rabisco”. Birra minha: queria mostrar um trabalho totalmente isento de ferramentas e seus diversos sabores.
3. EPBE, ou Eriksson-Penker Business Extensions, documentadas no livro “Business Modeling with UML“, de Hans-Erik Eriksson e Magnus Penker – Wiley/OMG (2000).