Converter SRS tradicional em User Stories?

Muitos projetos gerenciados de forma tradicional começam com uma Software Requirements Specification (SRS). Em algum momento durante o projeto, decide-se então mudar para uma abordagem ágil. Nesse caso, surge naturalmente a pergunta se uma SRS pode servir como o novo Product Backlog ágil. Algumas equipes até consideram reescrever a SRS em um Product Backlog com User Stories. Mas isso é realmente necessário?

Antes de abordarmos essa questão, gostaria de explicar brevemente o que quero dizer exatamente com Requirements Specification ou SRS. Percebi que esses documentos podem variar bastante entre diferentes empresas. Basicamente, porém, estou me referindo a um documento típico que contém declarações como "O sistema deve…".

Meu conselho, no entanto, se aplica praticamente a todos os documentos de especificação tradicionais. Isso vale, claro, para qualquer documento com requisitos integrados e numerados, independentemente de todas as declarações terem sido realmente formuladas como "O sistema deve…".

Algumas desvantagens ao usar uma SRS como Product Backlog

Em um produto ágil, o Product Backlog tem duas funções importantes:
- Ele serve como arquivo para todo o trabalho que precisa ser realizado
- Ele facilita a priorização do trabalho

O Product Backlog indica à equipe quais trabalhos precisam ser realizados, e também pode ser usado como ferramenta de planejamento para sequenciar o trabalho. Em contraste, uma SRS tradicional apenas especifica quais trabalhos precisam ser realizados em um projeto.

Uma SRS não tem como objetivo escrever requisitos que possam ser incorporados em um Sprint, nem priorizá-los. Escrever requisitos independentes é, na melhor das hipóteses, um objetivo secundário, o que fica evidente pela organização hierárquica da maioria dos documentos SRS com seus requisitos numerados (1.0, 1.1, 1.1.1 etc.).

Enquanto uma SRS for vista como um documento puro de requisitos, isso não traz nenhum problema. Porém, se os itens de uma SRS forem usados como Product Backlog Items e priorizados, isso vai causar problemas.

Com uma SRS, muitas vezes não é possível para uma equipe desenvolver o requisito 1.1.1 sem desenvolver simultaneamente os requisitos 1.1.2 e 1.1.5. Essas dependências tornam tudo muito mais difícil do que simplesmente selecionar e trabalhar uma Story após a outra de um Product Backlog bem elaborado.

A priorização de itens subordinados é tão difícil em uma SRS quanto identificar funcionalidades subordinadas para criar um Minimum Viable Product.

Uma Software Requirements Specification funciona bem como especificação de requisitos. Ela é boa para representar o que um sistema ou produto deve fazer. (Claro que ela não aborda todos os aspectos ágeis de requisitos emergentes (Emergent Requirements), colaboração, aprendizados etc. Mas parto do princípio de que essas coisas acontecem.)

Minha recomendação sobre SRS no Sprint

Basicamente, eu não recomendaria gastar tempo reescrevendo uma SRS impecável. Claro que, considerando os problemas mencionados, poderia ser útil transformar a SRS em User Stories e um Product Backlog bem organizado, mas normalmente o esforço simplesmente não vale a pena.

Alguém teria que dedicar tempo para fazer isso, mas essa pessoa geralmente pode usar esse tempo de forma muito mais produtiva. Eu desaconselharia especialmente reescrever uma SRS se outros membros da equipe tivessem que esperar pelo novo Product Backlog para começar a trabalhar.

O Scrum Master ou outro membro da equipe precisa encontrar uma forma de medir o progresso mesmo com uma SRS, e garantir que nenhum requisito se perca. Normalmente é uma boa ideia envolver a equipe de qualidade para assegurar que tudo na SRS foi concluído ou listado no backlog.

Além disso, é importante comunicar às pessoas envolvidas na criação dos documentos SRS que, em projetos futuros, façam isso de uma forma mais compatível com Agile. Se você conseguir isso, poderá evitar no seu próximo projeto os problemas que surgem da discrepância entre Agile e um documento SRS tradicional.

Este texto foi extraído do Blog de Mike Cohn e foi traduzido por nós para o português.

Requisitos Não Funcionais

=> Descubra aqui como transformar requisitos não funcionais em User Stories.

Sprint Planning orientado a Commitment

=> Aqui você descobre por que eu prefiro o Sprint Planning orientado a commitment em vez do Sprint Planning orientado a velocity.