Caso de Uso ou Estória de Usuário?

Caso de Uso x Estória de Usuário? Qual é melhor para

especificar software?

Em projetos ágeis ou tradicionais, é fato que precisamos ter um

modelo comportamental/funcional do software que será construído
(tanto para evolução de legado, quanto para sistemas novos).

No modelo comportamental/funcional é onde ficam as especificações

das funcionalidades.

Para a produção destas especificações, podemos usar diferentes

técnicas para produção dos artefatos.

No vídeo abaixo falamos sobre um dilema de alguns profissionais

quando o assunto é Especificação Comportamental/Funcional, em
contexto de projetos ágeis.

Após o vídeo, segue a transcrição do conteúdo.

A dúvida é: Caso de Uso ou Estória de Usuário ou para especificar o

comportamento das funcionalidades?

ABAIXO A TRANSIÇÃO DO CONTEÚDO DO

VÍDEO.
Em primeiro lugar, é importante é ficar claro que agilidade é um
conjunto de princípios e valores, é o famoso Manifesto Ágil, então
vamos separar agilidade de Scrum.

Para lidar com agilidade, temos a opção do framework Scrum, um

framework que estabelece algumas práticas para que se consiga
produzir software com agilidade.

Quando utilizamos o Scrum, nós lançamos mão de algumas

ferramentas para auxiliar na produção de software, como, por
exemplo, um artefato chamado Estória de Usuário.

Entretanto, o objetivo do Scrum não tem relação com um objetivo de 

uma Estória de Usuário.

Quando se fala sobre Engenharia de Requisitos Ágeis, é importante

ficar claro que não existe este conceito na literatura e nem no
mercado de fato que “Requisito Ágil”.

O que existe é um objetivo, com base no Time Box, onde algumas

ferramentas são mais aderentes e outras menos, então para apenas
ficar claro, em segundo lugar não existe relação direta entre estória de
usuário e scrum, ok?

E quando utilizar Estória de Usuário e

quando utilizar Caso de Uso?
/* Só para constar, em processos de desenvolvimento de
software mais tradicionais, pode-se utilizar estória também, Ok?
Não tem nenhuma restrição nesse sentido, nem sentido em
restringir isso.*/
Você pode rodar Scrum no seu processo de desenvolvimento e utilizar
Caso de Uso para poder definir, especificar o comportamento do
software, das features (funcionalidades) do software?

Sim pode.

E quando se recomenda isso?

Modelos e Agilidade

Agilidade não é produzir software com pressa, é produzir software

com velocidade, entregando valor no menor espaço de tempo possível,
e melhorando isso continuamente.

Para ser ágil, é fundamental ser eficiente.

Não é plausível falar em agilidade sem eficiência, com desperdício.

Em projetos de software, um dos maiores desafios é a

boa comunicação.

Deixar claro o que se quer, o que será entregue, como será produzido
etc. Isso não é simples quando produzimos software, devido
à complexidade inerente a esta atividade.

Quando se entende um requisito do jeito errado, sempre há o custo de

fazer errado, desfazer, e fazer certo. Obviamente, este tipo de
desperdício custa 3 vezes mais que se tivéssemos feito certo da
primeira vez.

E neste contexto, fica claro que o uso racional modelagem de software

com o objetivo de transmitir ideias entre membros de um mesmo
time, é uma ferramenta que favorece muito uma cultura ágil.
Quando se aplica usar Caso de Uso?
Recomendamos o uso de Caso de Uso quando a restrição do escopo é
forte no projeto, ou seja, o time trabalha menos orientado ao Time Box
e mais orientado ao escopo que será produzido, que é escopo
fechado.

Quando produzir com rigor um escopo detalhadamente é mais

relevante que gerar um MVP, ou produzir o escopo que couber no Time
Box do Sprint.

Neste tipo de contexto as especificações precisam ser bem rigorosas,

pois não há muita margem para erro ou para futuras refatorações
“premeditadas” (como é natural quando o foco é no MVP).

Em cenários como este o Caso de Uso é um artefato, um modelo que

se aplica muito bem.

O Caso de Uso tem regras bem definidas, fluxos claros, hierarquia

entre fluxos, várias destas regras contidas na especificação original
da UML, inclusive.

Fica mais ter uma especificação, onde uma maior cobertura de

restrições é dada, ou seja, um nível de rigor maior, garantindo assim
uma visão do escopo mais próxima do que realmente o usuário quer.

Porém, fazer um Caso de Uso detalhado leva mais tempo do que fazer
uma Estória de Usuário bem detalhada.
Quando se aplica usar Estória de Usuário?
Recomendamos o uso de Estória de Usuário quando se tem um
modelo de processo que rode Scrum.

Ainda, que nesse modelo de processo exista uma relação mais

madura entre a área de negócio/área usuária e a área de
desenvolvimento, onde exista uma cultura “de verdade”, não apenas
nos processos desenhados nos documentos da empresa, onde exista
uma cultura “de fato” de se produzir MVP (Produto Mínimo Viável) a
cada Sprint, onde não haja muito melindre em se fazer refatorações
nesse MVP a cada Sprint do projeto.

Ou seja, havendo um trabalho mais colaborativo, uma maturidade da

equipe e um foco mais na qualidade do produto do que do escopo
rígido, aí Estória de Usuário é um modelo mais fácil de trabalhar, mais
enxuto, mais rápido de se produzir.

Lembra
ndo que haverá cenários (situações), por exemplo, onde você pode
querer usar guardanapo escrito a caneta como a descrição do
comportamento da sua solução e isso não faz a mínima diferença (se
é bom ou se é ruim, se pode ou se não pode).

O melhor modelo para especificação comportamental/funcional é

aquele que gera mais valor para a equipe, é o que gera mais valor para
o cliente, é o que gera maior produtividade, maior qualidade.
Então, pode ser Caso de Uso, pode ser Estória de Usuário, pode ser
Papel de Pão, pode ser guardanapo, não interessa muito o formato, o
conteúdo é sempre mais importante.

/* Claro que não recomenda-se usar papel de pão, foi apenas

força de expressão. A ideia foi deixar claro que o conteúdo é
mais importante que a forma, e ás vezes um método simples
mas que atenda ao objetivo, pode ser melhor que técnicas mais
elaboradas e trabalhadas. */
Mas é lógico que o ideal é que você tenha algum artefato de
documentação para então começar a construção.

Isso diminui muito o problema do Cone da Incerteza e, mesmo em

contextos ágeis, é relevante que o desperdício seja o menor possível.

Conclusão
Caso de Uso ou Estória de Usuário? Como a maioria das coisas na

vida, depende! 

Grande abraço!

Junte-se a milhares de leitores inteligentes e receba nossas novidades direto no seu e-mail
(é grátis)!
Email*

CADASTRAR
Marketing by