3
respostas

HU - Como descrever os critérios de aceite

Na empresa onde trabalho, o padrão é descrever os critérios de aceite da história de usuário via no formato "Dado que....", "Quando...." "Então....".

Eu sou um desenvolvedor mainframe e me parece que este formato é muito limitado para descrever algumas regras.

O PO primeiro escreve as regras de negócio em um formato de português estruturado e então tenta adaptar ao formato de cenário, algo que tem extrema dificuldade (conforme uma reunião que participei e que observei como ele tenta fazer isto)

Tendo em vista que no formato de "Português Estruturado" o PO consegue escrever as regras e criticas a serem feitas de modo claro, há realmente necessidade de se transformar as regras que estão em Português Estruturado em um formato de "cenário" ?

3 respostas

Marcos, tudo bom?

Acho que é importante colocar, história de usuário não é uma descrição detalhada do que se tem para fazer. Apesar dos padrões, e sim eles são muito bons, a história é um lembrete do que deve ser feito pela equipe seguindo o valor do Manifesto Ágil:

"Software em funcionamento mais que documentação abrangente"

Gosto de reforçar que "documentação abrangente" não é sinônimo de ausência de documentação.

Quando exageramos nos formalismos começamos a desviar do Agile e entrar na burocracia. A regra deve ser clara para a equipe Scrum e para os demais interessados e não necessariamente descrita nos detalhes da história. Quando isso é necessário, para registro ou aprovação, é mais recomendado utilizar um documento externo que corra por fora do fluxo da equipe.

  1. A minha dúvida, no caso, não é bem sobre a história de usuário, mas sim sobre os critérios de aceite, que são usados pelo nosso gestor para indicar quais as regras de negócio.

  2. Como um desenvolvedor (e quando digo isto, significa que além da análise também efetuo a programação) concordo que o mais importante é entender o que deve ser feito, entretanto, também julgo necessário que as regras de negócio (e eventualmente formulas) estejam escritas de algum modo, pois o que está escrito pode auxiliar na codificação.

2.1. para sanar alguma dúvida de modo rápido o que está escrito pode auxiliar. Podemos, por exemplo, não lembrar como é uma formula financeira. Para um técnico, as vezes para entendermos bem o que tem de ser feito, temos de ter a comunicação falada e também a escrita. Um tipo de comunicação auxilia a outra.

  1. Isto não quer dizer que esperamos tudo estar escrito em detalhes para iniciar o desenvolvimento, entretanto, conforme você indicou, apesar do principal ser o software funcionando, isto não significa que haverá ausência de documentação.

  2. Pelo que entendi da sua resposta, então, as regras de negócio podem ser descritas em qualquer tipo de formato, seja em critérios de aceite, caso de uso, português estruturado ou qualquer outro. Que o importante é que a equipe entenda o que deve ser feito. Este entendimento está correto?

Exato Marcos, regras como as financeiras que você citou pode ficar numa documentação mais formal, ou num e-mail. Nos documentos formais com assinaturas e aceites, nos e-mails com cópias para as partes interessadas. Sabemos quem muitos casos essas regras podem ser questionadas em caso de falhas e é preciso ter isso formalizado. Foge um pouco dos conceitos do manifesto Ágil, mas na prática o juiz não leva em consideração ele na hora de decidir uma disputa judicial :-)

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software