Scrum - User Stories

Por Cesar Brod

Data de Publicação: 8 de novembro de 2008

Todo bom projeto começa com o pleno entendimento, por parte de uma equipe de desenvolvimento ou de um fornecedor de soluções, daquilo que o cliente realmente deseja. Isto deveria ser trivial, simples, mas deixou de ser a partir do surgimento e domínio das tecnologias. Passamos a ter, de um lado, o usuário e, do outro, o conhecedor da tecnologia. O usuário precisa de uma solução, mas não domina a tecnologia. Quem domina a tecnologia, por outro lado, muitas vezes desconhece a real necessidade do usuário. Acabo de ler um dos textos de Platão, descrevendo um diálogo entre Sócrates e Íon, o rapsodo. Em certa parte do texto, Sócrates discute com Íon um poema de Homero, quando o pai recomenda ao filho cuidado em uma corrida de bigas. Um cocheiro entenderia muito melhor este texto do que um médico, ou um arquiteto, concordam os dois.

Ao dominarmos uma tecnologia não podemos ter a pretensão de entender integralmente o negócio ou as necessidades de nossos clientes. Ainda que nos esforcemos ao máximo para isto, é o cliente que detêm esta compreensão, devendo ser o soberano na tomada de decisões sobre a solução que deseja, mesmo que não entenda nada da técnica a ser usada na construção desta solução.

Em artigos anteriores, sobre Extreme Programming (XP) e Scrum, já mencionei User Stories, ferramenta que envolve o cliente e o fornecedor/desenvolvedor na descrição da solução. Mike Cohn, autor da clássica apresentação sobre Scrum que traduzi, é também autor de um dos melhores livros sobre User Stories: User Stories Applied. Resumindo ao extremo, as User Stories permitem àqueles que conhecem a técnica da construção de uma solução (linguagem de programação, ferramentas, bases de dados) guiar quem necessita desta solução no exercício de descrevê-la de forma simples e concisa.

David Churchville, em seu blog, nos dá excelentes dicas para escrever boas User Stories. Elas devem ter o usuário, aquele que necessita da solução, como o foco da história. Não se deve mencionar na história algo como "melhorar a indexação da tabela de pedidos". Isto será grego para um usuário leigo, mas um analista de base de dados entenderá desta forma quando ler, na linguagem do cliente: "aumentar a velocidade na impressão dos relatórios de pedidos". David ainda diz que boas User Stories são perfeitamente explicáveis em 30 segundos, entre um andar e outro, em um elevador. Cada história deve "caber" no trabalho a ser executado em uma semana pela equipe de desenvolvimento, e devem ser facilmente testáveis: o cliente deve poder acompanhar o desenvolvimento do sistema lendo a User Storie que ajudou a escrever.

Usando dois acrônimos em inglês, o pessoal do xp123 completa com mais boas dicas. INVEST in Good Stories and SMART Tasks.

INVEST vem de Independent, Negotiable, Valuable, Estimable, Small, Testable. Cada User Storie deve ser, o máximo possível, independente de outras histórias. Aquilo que ela descreve deve ser perfeitamente negociável entre o fornecedor e o cliente (de fato, ela deve poder ser traduzida, posteriormente, em um plano de trabalho ou contrato de serviços). O cliente deve perceber o valor da User Story tanto como apoio à compreensão na construção da solução quanto na percepção do resultado de seu investimento na mesma. E como já mencionei, cada história deve ser pequena e testável.

SMART vem de Specific, Measurable, Achievable, Relevant, Time-boxed. Quando auxiliamos o cliente na construção de User Stories, devemos ter em mente que elas serão atendidas, na construção da solução, com a realização de uma série de tarefas. Ao saber como devem ser as tarefas, saberemos orientar melhor cada história. Cada tarefa deve ser específica, contida em si, bem definida e também independente. A tarefa deve poder ser medida para que seu custo possa ser efetivamente avaliado. Obviamente, temos que definir tarefas que possam ser realizadas. Cada tarefa deve ser relevante à história e, se na definição das tarefas, uma delas parecer não estar relacionada com a história (uma tarefa assessória não prevista inicialmente), então a tarefa ou a história devem ser revistas. Por fim, um período de tempo deve ser definido para cada tarefa.

Muito bem, mas que tal um exemplo? O que considero mais simples, de fácil entendimento e visualização, é o desenvolvido pela Universidade Estadual da Carolina do Norte, descrevendo o projeto de uma máquina de café. Siga o link e repare também o Use Case, mostrando a interação do usuário com a máquina de café.

Até a semana que vem!