Autor: Ivens Rocha, scrum master da Webjump

Na Webjump, usamos Scrum, que é um framework para desenvolver e manter produtos complexos.

Por ser uma metodologia que beneficia a agilidade, que chamamos de “metodologia ágil”, o Scrum é iterativo e incremental. De forma diferente dos modelos tradicionais de desenvolvimento em sequência, em ágil o planejamento do software acontece em pequenas partes ao longo do projeto. Isso evita que um projeto tenha documentação exagerada antes de existir uma única linha de código sequer.

É comum equipes de desenvolvedores criticarem projetos de software com centenas de páginas de documentação inúteis, mas normalmente são os próprios desenvolvedores os responsáveis, pois, quando não há colaboração com o cliente, a interação com ele poderá se resumir a ultimatos como: “ou você preenche todos os 100 casos de uso e 40 diagramas de estado, ou ficará muito caro para alterações no futuro”.

A metodologia ágil reconhece que é impossível prever e planejar tudo com antecedência e, sendo assim, divide o trabalho em pequenas tarefas e decisões que são tomadas ao longo do projeto, em vez de manter um conglomerado de resoluções feitas em um único momento, lá atrás, no início do trabalho.

Uma das principais características de um Time Scrum é sua capacidade de auto-organização, alcançada principalmente por boa comunicação. Um time que se comunica bem, sabe alinhar expectativas, entende as dificuldades e as vantagens de cada integrante, proporciona feedbacks e informações relevantes para melhoria contínua dos processos.

Um dos mecanismos usados para facilitar a comunicação do Time é quebrar decisões de um projeto em pequenas partes, que são as User stories (histórias de usuários). Pra matar a ansiedade: elas nada mais são do que cartões pregados na parede que passam informações de trabalho para a equipe. Todavia não há uma definição geral do que são user stories ou de como elas devem ser ordenadas e feitas, mas existem recomendações de profissionais referências do mundo ágil, como Ron Jeffries. Co-criador da metodologia eXtreme Programming, em 2001 ele descreveu aspectos-chave de uma história de usuário, os quais ele chamou de “os três C’s”.

Vamos a eles, então.

1. Cartão

Segundo Ron Jeffries, “as histórias de usuário são escritas em cartões, que não possuem toda informação do requisito” -, ou seja, a especificação do que o cliente quer – “mas apenas o suficiente para identificá-lo e lembrar a todos do que se trata. Nele pode conter anotações que reflitam a prioridade ou o custo da história.”

Isso é especialmente útil quando se lida com uma board Scrum. É poderoso poder interagir com uma ferramenta física que você pode mover, rabiscar ou simpĺesmente jogar no lixo.

2. Conversa

Ainda segundo Jeffries, “o requisito é comunicado pelo cliente aos desenvolvedores por meio de conversa: uma troca de pensamentos, opiniões e sentimentos. Esta conversa ocorre ao longo do tempo e é principalmente verbal, mas pode ser complementada por documentos. Os melhores complementos são exemplos e os melhores exemplos são executáveis. Estes exemplos são chamados de confirmações.”

Pense nos jogadores de vôlei quando o treinador pede tempo ao juiz. Todos os jogadores vão para fora da quadra e se reúnem em círculo. O bloqueio não está funcionando. O saque deve ser curto. Quão curto? Como deve ser o bloqueio? Times que interagem bem, compartilham informações de forma precisa, falando a mesma língua.

De acordo com o Manifesto Ágil, a interação deve ter mais valor do que processos e ferramentas, e a colaboração deve ter mais valor do que contratos. Ou seja, a conversa durante o desenvolvimento é essencial.

O cartão funciona apenas como um lembrete do que se trata a história. Imagine um desenvolvedor trabalhando em uma tarefa: é essencial que, ao mostrar uma história para o Product Owner ou outro membro do time, ambos consigam falar a mesma língua e expressar opiniões acerca dela.

É importante que a conversa faça parte de todo o processo de desenvolvimento, do contrário o Product Owner poderá se sentir desconfortável em ver poucas informações no cartão e acabará por adicionar detalhes desnecessários no momento, como documentações e diagramas gigantes.

3. Confirmação

“Este é o teste de aceitação. No começo da iteração, a cliente comunica aos desenvolvedores o que ela quer, e deixa claro como vai confirmar se foi feito o que deveria. A confirmação fornecida pelo teste de aceitação é o que torna possível o approach de ‘cartão e conversa’”, segundo Jeffries.

Se, na conversa sobre o cartão, os detalhes sobre o teste de aceitação entrarem, é este o momento que cliente e desenvolvedores fazem os acertos finais do que precisa ser feito. Quando a iteração termina e os desenvolvedores mostram o teste de aceitação rodando, o cliente vê que o time pode e irá entregar o que é necessário.”

No ensino fundamental, quando o professor nos entregava a prova, costumávamos perguntar: Posso fazer usando lápis? Posso consultar livros? É em dupla? Normalmente, nossas professoras não deixavam que fizéssemos a prova em dupla, o que era uma pena, mas definiam os testes de aceitação. Todo cliente tem uma expectativa e é isso que buscamos quando estabelecemos uma confirmação. Idealmente, esta confirmação deve constar no cartão de forma simplificada, onde o time consiga entender o que o cliente espera.

A história do usuário não deve ser vista como um requisito, mas sim como um mecanismo de comunicação que transmite informações cruciais de um requisito. O requisito pode estar mais elaborado, mais bem documentado, com diagramas, mocks de tela e tudo mais. A história do usuário é apenas a porta de entrada, um ponteiro que aponta para um requisito.