Existem muitas maneira de se especificar requisitos de um projeto, seja ele tradicional ou ágil. Alguns preferem utilizar UML, outros apenas descrevem as necessidades em documentos Word. Proveniente da metodologia ágil XP, User Story (US) passou a ser bastante difundido, e utilizado, por outras metodologias, para se especificar requisitos de um projeto.
US é uma visão superficial, e resumida, sobre aquilo que se precisa saber para atender à uma necessidade específica. Em outras palavras, é como se o desenvolvedor escrevesse um resumo de sua conversa com o cliente.
O padrão adotado, para criação de uma US é o User Story Card (USC). USC é um cartão que contém, em sua parte frontal, a necessidade, seu esforço de desenvolvimento e sua prioridade. E, na parte de trás, os detalhes da US, bem como seus requisitos para aceitação
A forma mais utilizada para se descrever a necessidade, apresentada em uma US, é: Como (papel) eu quero (algo) para que (benefício). Exemplo: Como estudante, eu quero poder acessar minhas notas online, para que eu possa ter mais controle sobre minhas notas e faltas.
É importante frisar que uma US deve ser desenvolvida em uma única iteração (falaremos sobre isso mais a frente). Em casos em que o esforço necessário, para entregar uma US, seja maior que o tamanho de uma iteração, esta deve ser dividida em uma fração que não perca sua identidade e que caiba em uma única iteração. Daí o surgimento da sigla SMART, que serve para avaliar a qualidade de uma US. SMART significa: Specific / Significant; Mensurable; Achievable; Realistic / Reasonable; Time-bound / Testable / Trackable. Em português, podemos traduzir como: Específico / Significante; Atnigível; Relalístico / Responsabilizável; Tempo Definido / Testável / Rastreável.
Uma vez escrita, a US será priorizada e seu esforço será avaliado. No início do projeto, como temos poucas informações sobre muitas US, sua prioridade e esforço serão apresentados de forma superficial. Em seguida, elas serão incluídas no Product Backlog - uma lista de todas as US que serão entregues, durante o projeto, e divididas em iterações (este processo será discutido em um post sobre planejamento ágil). E, na iteração em que ela será desenvolvida, ela será novamente discutida, entre o cliente e a equipe de desenvolvimento, para que seu entendimento seja pleno.
Por fim, são de responsabilidade do cliente apontar a prioridade, os detalhes necessários e os requisitos de aceitação, da US. E é responsabilidade da equipe de desenvolvimento, apontar o esforço necessário para entrega da US, com desenvolvimento, teste e transição para produção.
Até o próximo post.
Nenhum comentário:
Postar um comentário