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 TimeBox, 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 TimeBox 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!