Na primeira parte, o artigo falou, entre outras coisas, sobre quando fazer histórias e quando fazer requisitos, e sobre o modelo Connextra. Nesta continuação, serão abordados o cliente e como não devemos nos apegar a histórias de usuários.

Tudo está voltado para o cliente

Também nos dizem que histórias de usuários devem estar centradas no cliente, escritas a partir do ponto de vista do cliente e sempre descrever algo que é importante para ele.

Esse argumento é construído ao redor de duas ideias centrais:

1. O time de desenvolvimento precisa ter sempre em mente que deve entregar valor ao cliente. Desde o início do projeto, o time deve entregar features que o cliente pode ver que funcionam, tocar, explorar e responder a ele.
2. O cliente/dono do produto precisa ser capaz de entender cada requisito, o que significa que cada requisito precisa estar na linguagem dele e em algo que seja caro a ele. (Esse é outro exemplo daquilo que está errado com a ideia do cliente/dono do produto no desenvolvimento ágil – que uma única pessoa possa ser responsável por definir tudo que é feito em um projeto.)

Focar exclusivamente na entrega de valor ao cliente deixa espaço para limitações e necessidades não funcionais, que são de fundamental importância na construção de um sistema real e tira a ênfase de um sistema de alta qualidade para minimizar riscos técnicos.

Isso levou a muitas discordâncias e confusões desnecessárias sobre como desenvolvedores devem lidar com limitações e necessidades não funcionais, desenvolvedores escondendo necessidades técnicas dentro de histórias de clientes ou tentando distorcer necessidades técnicas ou de arquitetura dentro de histórias no estilo de usuário, o que acaba não fazendo sentido nem para o cliente, nem para os desenvolvedores.

Trata-se de um problema especialmente no que diz respeito às necessidades técnicas de áreas como segurança, manutenção e suporte – preocupações que não fazem sentido para o cliente, mas que são restrições fundamentais que se aplicam a todo o trabalho que o time faz e como ele faz, não apenas em relação ao trabalho feito em um único Sprint.

Assim como a ideia de utilizar um modelo comum, colocar o cliente em primeiro lugar nos requisitos foi algo bem-intencionado: uma forma de trazer o time de desenvolvimento mais para perto e uma forma de certificar-se de que as pessoas que pagam pelo trabalho terão realmente aquilo que pediram. Mas insistir que essa é a única forma de enquadrar todos os requisitos cria problemas e riscos desnecessários e torna o trabalho do time mais difícil de fazer.

Não se apegue a histórias de usuários – faça aquilo que funciona

Insistir em dizer que todo o trabalho que cada time de desenvolvimento precisa fazer tem de ser definido da mesma forma é algo arbitrário, desnecessário e errado. É como voltar nos tempos do UML, quando aprendíamos que requisitos tinham que ser capturados por meio de casos de usuários. Alguém se lembra de como era estranho – e sem sentido – tentar modelar especificações funcionais usando homens de palito e balões?

Times devem usar o formato que faz sentido para a situação deles, com o mínimo ou o máximo de detalhes que a situação e o problema exigem. Há momentos em que eu prefiro trabalhar com cenários e regras detalhadas e bem definidas, que foram cuidadosamente pensadas e revisadas, ou um protótipo que foi mostrado ao cliente e melhorado gradativamente, a me limitar a uma longa lista de histórias de usuários com duas linhas e rezar para que eu consiga alguém que entende de cada requisito para preencher em detalhes as necessidades do time.

No Agile 2013, Jeff Patton esclareceu em sua palestra sobre Agile Requirements and Product Management, que modelos de histórias são uma ferramenta que deve ser utilizada por iniciantes para aprender como fazer as perguntas. Como na técnica de “snow plow” para esquiadores iniciantes – algo para ser deixado de lado uma vez que você sabe o que está fazendo. Sua recomendação é “use aquilo que você necessita para capturar as necessidades: imagens, slides, notas, testes de aceitação”. Na mesma conferência, Scott Ambler reiterou que “histórias não são o suficiente. Elas são apenas uma ferramenta, uma visualização da utilização. Há muito mais opções”.

Não se preocupe com histórias, épicos ou temas – ou temas e épicos (a comunidade ágil não consegue convergir sobre o que é um tema, o que é uma épico, e isso não importa de qualquer forma). Acrescente detalhes quando você precisa. Livre-se dos detalhes desnecessários.

Não seja pego por aquilo que Roman Pichler chama de “mania de história”:

Alguns donos de produtos e times são tão fãs de histórias de usuários que tudo é expresso em um história. Isso às vezes resulta em algumas histórias bastante pitorescas – histórias que capturam o design de interface, interações complexas do usuário e requisitos técnicos. Ou esses aspectos são simplesmente negligenciados.

Mas design de interfaces e interações complexas de usuário são melhor descritas por outras técnicas, incluindo rascunhos, mock-ups, cenários e storyboards. Complemente suas histórias de usuário com outras técnicas e não se sinta obrigado a utilizar as histórias.

Mesmo as pessoas que desenvolveram a ideia original das histórias de usuários concordam que nem tudo pode ou deve ser descrito como uma história.

Capture os requisitos da forma que funciona melhor. Mantenha os requisitos leves, claros e os mais naturais possíveis. Se você tem necessidades técnicas importantes que precisam ser trabalhadas, tome nota e não se preocupe em tentar desvirtuá-las em algum tipo de história de usuário arbitrária porque te disseram que é isso que você precisa fazer para “ser ágil”.

Vamos parar de contar histórias e fazer o trabalho.

***

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