Qual a diferença entre requisitos tradicionais e User Stories?
Hoje em dia é natural realizar uma transição entre um ambiente tradicional para um ambiente ágil. Por exemplo, um profissional trabalha como Analista de Requisitos e recebe a oportunidade de ser um Product Owner, porém quais são as grandes diferenças em relação aos requisitos?
Nos ambientes tradicionais, os requisitos seguem normalmente um processo mais burocrático e robusto, por exemplo, normalmente as seguintes etapas são encontradas:
- Identificação: entendimento dos requisitos com as partes interessadas;
- Documentação: elaboração dos artefatos para a implementação do requisito;
- Aprovação: aprovação formal do solicitante ou patrocinador do requisito;
- Versionamento: todo o requisito deve ser versionado, tal que o histórico de modificações seja mantido;
- Liberação para desenvolvimento: com a aprovação, o gerente de projetos pode planejar o desenvolvimento;
- Planejamento dos testes: o time de testes define como poderá testar os requisitos;
- Validação: o time de teste realiza os testes para validar a implementação do requisito.
Vejam que pode ser um processo muito árduo e envolver muitas etapas bem como pessoas. É normal que a transição de um ambiente tradicional para um ambiente ágil seja um grande choque, pois as diferenças são gritantes, um Product Owner tem muito mais flexibilidade e na maioria dos casos não há nenhuma etapa de aprovação. Mas como seria o cenário no geral?
- Identificação da necessidade: o PO identifica a necessidade com o cliente ou usuário;
- User Story: esta representa o requisito, porém é mais simples e é composta de três partes:
Proposta de Valor: determina o por que da User Story existir e o que deve ser resolvido;
Critérios de Aceitação: determina como verificar se o objetivo foi atingido;
Comunicação com o time: refinamento com o time de desenvolvimento para entender qual o melhor caminho a ser seguido.
- Validação: após a implementação, o time de desenvolvimento apresenta os resultados para o Product Owner, o qual verifica se o objetivo foi atingido.
Notem que há etapas com o mesmo propósito, porém a execução é onde ocorrem as maiores diferenças.
Em metodologias ágeis a comunicação é mais importante que a documentação, diante disso o Product Owner deve sempre aprimorar a sua comunicação.
Eu particularmente fiz a transição de um ambiente tradicional para o ágil, no começo foi de fato muito estranho, pois era acostumado a escrever extensas documentações e passar por etapas de aprovações. Aprendi que devemos ser aberto ao novo, devemos estar dispostos a testar e aprender novas abordagens.
Hoje em dia eu entendo claramente os benefícios do ambiente ágil. Em resumo o aprendizado é mais rápido e fica extremamente mais fácil adaptar a direção durante o caminho evitando assim desperdícios. O mais importante é quão rápido podemos aprender sobre o de fato importa para o público alvo!
Quer saber mais sobre este tema? Se inscreva em meu curso Como ser um Product Owner.
