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

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

Compartilhe!

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

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?

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

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.

curso casos de uso na realLembrando 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!
Engenharia de Software

  • Raul Rocha

    Gostei do conteúdo. Realmente essa parte de analise de requisitos dentro da metodologia ágil/scrum da uma bagunçada de como fazer com qualidade.
    Já que normalmente a criação da estória não fica na mão do analista de requisitos, mas do gerente de produtos. Como você vê essa separação? Fiz seu curso de engenharia de requisitos e de casos de uso porém trabalho em metodologia Scrum que acaba ficando fora.

    • Plínio Ventura

      Olá Raul, como vai?

      Pelo que vejo no mercado, incluindo minhas experiências mais atuais, a responsabilidade pela criação da especificação funcional em contextos ágeis varia muito. Na maioria das empresas que pude acompanhar é o Analista de Requisitos (ou Negócios, ou equivalente) quem geralmente tem a atribuição de especificar.

      Mas também vejo lugares onde é o PO (Product Owner, que muitas das vezes é um Gerente de Produto, ou até mesmo, Usuário Chave).

      Na minha opinião, penso que quem deve criar as estórias (ou lidar com os requisitos/casos de uso – ainda temos muitas empresas que rodam Scrum mas não usam estória, afinal, User Story != Scrum) é o Analista (Requisitos/Negócios), pois é quem (teoricamente) está mais preparado para entender o software, no aspecto funcional, quem tem sendo crítico técnico, e “um pé” no negócio.

      Penso que não é muito produtivo uma pessoa “puramente” de negócio fazer estórias, da mesma forma que um profissional totalmente voltado “ao código” também não.

      Mas é um ponto de reflexão. Cada empresa tem sua cultura, cada cultura possui seu nível de maturidade, e cada profissional é cada profissional! 🙂

      Mas se tiver mais dúvidas estamos à disposição!

      Obs.: no segundo semestre deste ano lançaremos um curso de Estórias (História) de Usuário, fique ligado!

      Grande abraço!

  • Plínio Ventura

    Fala Armando!

    Sempre um prazer sua visita aqui no blog, muito obrigado!

    Seu comentário é totalmente pertinente, e o segundo parágrafo, totalmente coerente com o que se espera de uma organização que realmente quer se tornar ágil.

    Grande abraço, obrigado pela contribuição de qualidade!