Seções iMasters
Agile

Pare de contar histórias – Parte 01

Há ideias lindas e simples nos métodos ágeis de desenvolvimento de hoje que realmente funcionam muito bem. E algumas que não: como definir todos os requisitos na forma de histórias de usuários.

Eu não gosto do nome. Histórias são coisas que você conta para crianças antes de colocá-las na cama, não informação valiosa que você usa para criar um sistema complexo. Eu não gosto do formato que a maior parte dos times usa para escrever histórias, e não gosto da forma como eles utilizam os formatos.

Às vezes você precisa de histórias, às vezes de requisitos

Uma das “regras” de métodos ágeis é que histórias precisam ser pequenas – pequenas o suficiente para caber em um cartão de índice ou em um post-it. Elas têm o propósito de ser pequenas porque são supostamente para te lembrar de conversar com o cliente quando estiver pronto para trabalhar nelas:

Elas não são requisitos. Não são casos de uso. Não são ao menos narrativas. São algo muito mais simples do que isso.

Histórias são para planejamento. São descrições simples de uma ou duas linhas sobre o trabalho que o time deve produzir.

Isso não fornece detalhes suficientes para que o time implemente e entregue software que funcione, nem é essa a intenção das histórias. Uma história é um lembrete para uma discussão detalhada sobre os requisitos. Clientes são responsáveis por ter os detalhes dos requisitos disponíveis quando o resto do time precisa deles. James Shore, The Art of Agile – Stories

De acordo com Mike Cohn, em seu livro Succeeding With Agile, criar histórias pequenas força o time a mudar seu foco de escrever sobre features para conversar sobre elas. Times devem fazer issom pois conversar sobre é mais importante do que escrever sobre.

Mas essa ideia pode ser – e frequentemente é – levada longe demais. Com certeza a maioria das pessoas aprendeu que não é possível escrever especificações de necessidades compreensivas, completas e corretas para tudo logo de início. Mas há muitos momentos em que não faz sentido limitar-se a lembretes de uma ou duas linhas para algo que você espera preencher mais tarde.

Alguns requisitos não são expressões de alto nível das intenções do cliente, que podem ser ditas em conversas e demonstradas para verificar que você entendeu certo. São especificações que precisam ser seguidas linha a linha, regras que restringem o seu projeto de formas importantes, e é necessário que você compreenda isso quanto antes.

Alguns requisitos, especialmente nas áreas técnica e científica, são fundamentais para dificultar o entendimento e saem caro se mal compreendidos. Você deve obter o máximo de informações logo de início, para que desenvolvedores – e clientes – tenham a chance de estudar o problema e refletir sobre eles, compartilhar ideias, fazer perguntas e conseguir respostas, explorar opções e criar experimentos e cenários. Você quer e precisa escrever essas coisas o mais objetivamente que puder antes de começar a resolver o problema errado.

E há outros momentos, como quando você já teve a conversa – já lhe concederam uma breve janela com as pessoas que compreendem muito bem o que elas precisam e porquê. Você talvez não tenha a mesma chance com as mesmas pessoas novamente. Portanto, melhor escrever antes que não consiga mais se lembrar daquilo que eles disseram.

Pequenos roteiros de histórias para detalhar mais tarde ou requisitos bem detalhados anteriormente talvez funcionem melhor – diferentes situações e diferentes problemas necessitam de abordagens distintas.

O modelo Connextra: como {tipo de usuário} quero {alguma coisa}

Histórias começam simples, como descrições livres do trabalho que o time de desenvolvimento precisa fazer,  como um “relatório dos itens no almoxarifado”. Mas agora, o modelo Role-Feature-Reason, também conhecido como modelo/formato Connextra, (porque alguém que trabalhou lá criou isso nos idos de 2001) é a forma como dizem que todos nós devemos escrever nossos requisitos.

Como um {tipo de usuário}, quero {fazer algo}, então {motivo}

Como isso aconteceu? E por quê?

De acordo com Mike Cohn (que ajudou a popularizar esse modelo em seus livros e cursos), há algumas razões pelas quais histórias devem ser escritas dessa forma:

Motivo 1

Alguma coisa importante – e, estou tentado a dizer, mágica – acontece quando requisitos são colocados na primeira pessoa…

Motivo 2

Ter uma estrutura para as histórias na verdade ajuda o dono do produto a priorizar. Se o histórico do produto é uma bagunça do tipo:

  • manipulação de exceções de correções
  • deixar os usuários fazerem reservas
  • usuários querem ver fotos
  • opções de tamanhos do show room

…e assim por diante, o dono do produto precisa trabalhar duro para entender qual é o recurso, a quem ele vai beneficiar e qual é o seu valor.

Motivo 3

Ouvi argumentos de que escrever histórias com esse modelo na verdade inibe o conteúdo da informação da história porque há muito modelo na estrutura do texto. Se achar que isso é verdade, então corrija o modelo na maneira como você apresenta a história… (o que não é razão para usar esse modelo, mas uma “gambiarra” caso você use).

Tentar encaixar todos os requisitos nesse modelo tem seus próprios problemas:

Formato de histórias de usuários é algo estranho e pesado. “Como um ____, quero ____, para que assim eu possa ____.” O conceito é bom – sempre deve haver uma explicação de por que a tarefa é desejada, para se certificar de que o resultado preenche as necessidades atuais. Mas a quantidade de ginástica verbal que eu já vi algumas pessoas fazerem para colocar um requisito simples e óbvio em uma “história de usuário” prova que, apesar do que dizem os métodos ágeis, nem sempre eles são a melhor forma de se fazer isso. Talia Fukuroe, 6 Reasons Why Agile Doesn’t Work

Muitas pessoas têm problemas similares:

Steve Ropa na versão um (“Why I don’t Like User Story Templates”) já trabalhou com times que não compreendem ou não seguem corretamente as ideias e práticas-chave dos métodos ágeis…

Mas onde eles se sobressaem é em se certificar de que toda história seja expressada no formato Como um ____ posso ___ então ___. Não importa qual é a história, elas encontram uma forma de se encaixar nesse modelo. E é aí que as coisas começam a dar errado. A necessidade de encaixar a história no modelo se torna mais importante do que o conteúdo da história em si…

O modelo tornou-se uma norma. Meu entendimento de histórias, quando aprendi sobre elas, foi de que elas serviam para trazer a linguagem natural de volta para a conversa sobre o que o software precisa fazer. Como podemos nos afastar do formalismo de “listas de necessidades” e documentos de requisitos se estamos apenas os substituindo por modelos de histórias?

Gojko Adzic diz que seguir de forma robótica um modelo de história padronizado nos leva a histórias que “estão gramaticalmente corretas, mas são completamente falsas”:

Histórias desse tipo são falsas, levam a falsas conclusões e apenas fazem mal. Elas não fornecem um contexto para uma boa discussão ou priorização. Elas não são mais do que quebras funcionais de tarefas, embrulhadas em uma forma diferente para passar pelo escrutínio de alguém que gastou dois dias em algum curso bobo de certificação e para prover a empresa de algum falso conforto de que agora eles são, de fato, ágeis.

Na segunda parte do artigo, serão abordados o cliente e como não devemos nos apegar a histórias de usuários.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2013/12/stop-telling-stories.html

 

Qual a sua opinião?