Boa parte das pessoas que trabalham com tecnologia, mais precisamente com métodos ágeis, provavelmente já conhecem esses termos. Originados do SCRUM, eles são essenciais para o desenvolvimento do produto, pois são elementos vitais para estabelecer diretrizes claras sobre o que será desenvolvido de maneira eficiente, trazendo os desenvolvedores mais próximos do entendimento do negócio e o motivo de estarem fazendo tal funcionalidade.
Definition of Ready (DoR):
DoR, também conhecido por Definition of ready, concentra-se em garantir que um item do Product Backlog esteja preparado para entrar na sprint para desenvolvimento. Seguindo o livro do PBB (Product Backlog Building) do Paulo Caroli e Fábio Aguiar, ele deve conter os atributos do INVEST.
- Independent (Independente): A história deve ser independente de outras histórias, o que significa que ela não deve depender da conclusão de outras para ser implementada. Por exemplo, uma história que requer outra história para ser concluída primeiro não é independente. Se isso for possível, ela é independente
- Negotiable (Negociável): A história deve ser flexível e aberta a negociação com a equipe de desenvolvimento e o cliente. Isso significa que detalhes específicos podem ser discutidos e ajustados durante a sprint, à medida que mais informações surgem. Um exemplo seria uma história que descreve o comportamento geral, mas permite a adaptação de detalhes específicos durante o desenvolvimento.
- Valuable (Valiosa): A história deve agregar valor à entrega, tendo um propósito claro e impacto no negócio ou no cliente. Por exemplo, uma história que adiciona uma nova funcionalidade desejada pelos usuários ou que atende a um requisito de negócios específico é valiosa.
- Estimable (Estimável): A história deve ser capaz de ser estimada em termos de tempo e esforço para conclusão. Histórias muito grandes devem ser divididas em partes menores que possam ser estimadas com precisão. Isso ajuda na gestão do tempo e no planejamento das sprints.
- Sized Appropriately (Tamanho Adequado): A história deve ser de tamanho apropriado para ser concluída em um período de tempo definido, geralmente uma sprint. Evitar histórias muito grandes ou muito pequenas ajuda a manter o fluxo de trabalho constante e eficiente.
- Testable (Testável): A história deve ser testável, o que significa que deve ter critérios de aceitação claros que possam ser usados para verificar se a solução desenvolvida atende aos requisitos do cliente. Ter critérios de aceitação bem definidos ajuda a evitar ambiguidades e conflitos de interpretação.
Fazer uma boa história de usuário pode parecer simples, mas seguir todos os critérios acima é uma tarefa bastante difícil. Pois pode ocorrer de várias vezes, a pessoa de produto querer colocar muitas funcionalidades ou regras de negócio dentro de um único PBI (Product Backlog Items), inviabilizando alguns pontos mencionados, tais como, negociável, já que com muitas regras de negócio atreladas a uma funcionalidade, pode ocorrer de que qualquer alteração solicitada seja muito complexa para alterar.
