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.

Lembrando 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