*Publicado originalmente em 2 de dezembro de 2016, no LinkedIn
Em 12 anos de Análise de Negócio, passei pelos mais diversos projetos. Projetos grandes, projetos pequenos, programas inteiros ou apenas manutenções.
Todos eles possuem algo em comum: a grande quantidade de frameworks a serem utilizados. Casos de Uso, Tabelas de Caso de Uso, protótipos. Tudo previsto em metodologias como RUP e como o Waterfall Clássico. Mesmo assim, os problemas seguiram aparecendo: Problemas de entendimento, problemas com desenvolvimento… Já não dava mais pra seguir desse jeito. Pausa.
2016. Nesse ano eu passei a trabalhar com metodologias ágeis e as primeiras dúvidas começaram a surgir: Como escrever as histórias? Como garantir que os requisitos foram 100% capturados? Em minha mente sempre ecoou o fato de que a responsabilidade pelas perguntas certas era minha. Eu possuo o domínio da técnica. O BABOK também diz: Essa responsabilidade é do Analista de Negócios. E agora?
O costume de sempre elicitar os requisitos – e ser a única responsável por eles -, me deixava preocupada o tempo todo. Então, resolvi procurar o treinamento de Requisitos Ágeis com o Marcelo Neves. Meu objetivo com o curso era descobrir frameworks para escrita de histórias de usuário, épicos, técnicas, essas coisas.
E o que aconteceu foi um belo de um tapa na cara. Tapa na cara porque, além do INVEST, não há mais nada que determine se uma história está bem escrita ou não. Porque quem define se a história está bem escrita é o Time de Desenvolvimento. Porque no Scrum, o Time ajuda a definir se a história tem tudo o que precisa.
Porque em metodologia ágil, a interação entre pessoas é mais que processos e ferramentas.
Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano - Manifesto Ágil
Então, se você veio até aqui buscando uma indicação de framework para requisitos ágeis, eu só tenho uma ajuda pra você. O INVEST. Uma história de usuário deve ser:
Independente, Negociável, Ter Valor, Estimável, Pequena (Small) e Testável.
Já adianto que conseguir todos eles ao mesmo tempo não é uma tarefa fácil. Mas confie em você e no time. Aos poucos, a prática leva à maturidade – e à perfeição.
2 comentários em “Um framework para requisitos ágeis”