O conceito de casos de uso foi criado em 1986 por Ivar Jacobson, metodologista e um dos pais do processo unificado. Depois de 25 anos, temos uma evolução na teoria de casos de uso feita pelo próprio autor, influenciado fortemente por métodos ágeis. Descrevo aqui as principais novidades do conceito de Casos de Uso 2.0, publicado pelo autor agora no fim de Setembro em um congresso do IIBA (International Institute of Business Analysts).
Abordagem Iterativa – Fatias de Casos de Uso
Um caso de uso é um conjunto de histórias estruturadas na forma de narrativas. Casos de uso complexos podem ter diversos fluxos alternativos e dezenas de casos de teste. Muitas vezes o tamanho do caso de uso é proibitivo para acomodar entregas curtas em métodos ágeis.
Uma fatia de caso de uso é criado através da seleção de uma história para implementação. É fundamental que uma fatia de caso de uso entregue “valor”, i.e, gere uma experiência de teste para o usuário.
Uma fatia de casos de uso é, então, um combinação de fluxos que permite que casos de teste sejam realizados. A figura abaixo exemplifica este conceito para um caso de uso complexo que tenha 15 fluxos alternativos (um verdadeiro épico). Ele é então fatiado em pequenos pedaços, que podem ser adequadamente mastigados pelo time.
O próprio levantamento do requisito pode ser iterativo. Isto é, não precisamos conhecer todo o caso de uso para que o fatiemos para desenho e implementação.
Fatias de Casos de Uso e o Backlog de Tarefas
A figura abaixo mostra três fatias de um caso de uso. É interessante notar que as pequenas fatias podem gerar os itens de trabalho de um backlog no nível necessário para acomodar pequenas entregas, conforme a velocidade do seu time.
O processo da narrativa do caso de uso – Foque na amplitude
É importante mencionar um aspecto também enfatizado por Jacobson, à luz do que Allistair Cockburn já fazia no livro Escrevendo Casos de Uso Eficazes, que é uma narrativa iterativa. Em outras palavras, começamos a narrativa do caso de uso de forma bem leve, sempre trabalhando em amplitude. Com a identificação dos nomes dos fluxos alternativos, por exemplo, já podemos derivar as fatias de casos de uso.
Fatias de casos devem ser unidades testáveis
O leitor mais atento já deve ter percebido isso. Casos de uso devem guiar os testes e o conceito de fatia de caso de uso é o elo para este trabalho. A figura abaixo mostra esta ligação. Uma fatia de caso de uso permite que todo o trabalho do time de desenvolvimento e testes seja acionado até que os testes passem e esta fatia de casos de uso seja marcada como realizada.
Considerações Finais
Ao final de sua apresentação, Ivar Jacobson faz o seguinte resumo:
- casos de uso ainda são casos de uso;
- eles provem contexto para nossas conversações (usuários e sistemas);
- nós devemos apenas modelar o que for importante;
- nós fatiamos os casos de uso para dirigir o desenvolvimento;
- nós eliminamos o desperdício usando o nível de detalhamento mais leve possível;
- nós definimos o caso de teste como parte do caso de uso para definir o PRONTO PARA O USUÁRIO;
- nós usamos cartões e backlogs para suportar métodos ágeis;
- nós adicionamos detalhes para lidar com comunicação distribuída (times geograficamente distribuídos)
