Recentemente, tive minha primeira experiência com levantamento de requisitos sob a forma de user stories. Até então, minha experiência com o tema resumia-se a técnicas mais tradicionais, como entrevistas com usuários, desenho de processos e elaboração de casos de uso.

Achei o processo bastante interessante, que merece ser relatado. 

Trata-se de um projeto conduzido sob a metodologia ágil SCRUM. A equipe do projeto fez uma reunião com o product owner (o cliente do sistema) na qual foram escritas em fichas pautadas as estórias do sistema (pode-se considerar que equivalem a “processos” que o sistema deve suportar). Cada estória tem o formato

Como <usuário do sistema>,
quero <fazer algum processo>,
para <finalidade do processo>.

Para cada estória, o product owner fez uma breve descrição para a equipe do projeto e informações relevantes foram escritas no verso da ficha. O foco neste momento não era fazer um levantamento detalhado de requisitos, mas apenas nivelar a compreensão da equipe sobre o processo de negócio que a estória suportava.

Depois, com todas as estórias prontas, a equipe do projeto pontuou cada estória com um valor de complexidade estimada. Uma estória foi considerada como um valor referencial e as demais ganharam uma estimativa baseada na sua complexidade relativa em relação ao valor referencial. Os valores da escala são:

1, 2, 3, 5, 8, 13, 20, 40, 100

O processo de pontuação foi realizado através de um jogo de cartas. Após uma breve revisão da estória, cada integrante da equipe jogou uma carta com o valor de sua estimativa. Os que votaram com o maior e menor valor explicaram as razões de sua pontuação para os demais integrantes. Feito isso, ocorreu uma nova votação que, na maior parte das vezes, caminhou para um consenso.

Finalizada esta etapa, todas as estórias continham uma complexidade estimada pela equipe do projeto. Com essas informações, o product owner fez uma priorização das estórias para definir a ordem de construção do sistema. Obviamente, essa ordem poderá ser modificada ao longo da execução do projeto, conforme a compreensão sobre o sistema seja aprofundada, ou as necessidades de negócio mudem.

Resumidamente, este é o processo.

Socialização como fator fundamental

O que mais me impressionou foi a eficácia do processo de socialização para externalizar, compartilhar e nivelar o conhecimento tácito dos participantes, mesmo quando eles são apenas ouvintes na dinâmica. Por exemplo, o product owner não votou na complexidade das estórias, mas participou do processo como ouvinte e compreendeu o porquê de uma estória ser mais ou menos complexa que outra. 

Outro ponto muito interessante é que a priorização das estórias aconteceu de uma forma quase natural. A relevância das estórias para os objetivos de negócio que o sistema deve atender emergiu naturalmente ao longo do processo. Apesar de ser uma decisão que cabia ao product owner, surgiu um consenso implícito da equipe do projeto quanto à priorização das estórias. Vale notar que o fato de uma estória ser pouco complexa é totalmente independente de sua priorização. No projeto em questão, algumas estórias de complexidade 1 ou 2 tiveram baixíssima priorização. O fato de ser “fácil” não quer dizer que ela será feita logo — tudo depende de sua relevância para o negócio. Este é um erro muito comum em projetos: fazer logo algumas funcionalidades apenas por serem simples, sem refletir se de fato são importantes.

Finalmente, deve ser mencionada a tecnologia de apoio ao processo: fichas pautadas, canetas hidrográficas, canetas esferográficas e mesa. Isso mesmo! Nenhum computador, nenhum projetor, nenhuma planilha, nenhum software mirabolante. Apenas pessoas, foco e instrumentos adequados — não caros e sofisticados, simplesmente, adequados  —, que podem ser comprados na papelaria da esquina. A possibilidade de interagir simultaneamente, a falta de hierarquia, a comunicação direta e o compartilhamento de conhecimento entre os participantes do processo foi fundamental para a eficácia do processo. Impressionante!

Como lição e estímulo aos profissionais liberais, fica o exemplo de eficácia a baixo custo. A bem da verdade, este é um exemplo a ser seguido por empresas de quaisquer porte. Mas a restrição orçamentária para grandes investimentos em tecnologias faz parte da realidade de quase todos os profissionais liberais. Vivi um exemplo prático que me mostrou o quanto um processo eficaz (no caso, de gestão do conhecimento tácito) pode ajudar a reduzir as necessidades de investimentos tecnológicos. Espero que vocês achem útil!