O que é e pra que serve?
Pesquisando por definições na internet encontrei essa explicação um pouco complicada da Wikipédia: “Na Engenharia de Software, um caso de uso (ou use case) é um tipo de classificador representando uma unidade funcional coerente provida pelo sistema, subsistema, ou classe manifestada por seqüências de mensagens intercambiáveis entre os sistemas e um ou mais atores.”; traduzindo, caso de uso é um canal de comunicação entre os usuários e os desenvolvedores onde se tem uma “tentativa” de criar uma especificação funcional do sistema. Foi criado na década de 80 por Ivar Jacobson, e é uma das técnicas mais populares para descrever os requisitos de um dado sistema. (Vide Wikipédia/Caso_de_uso).
Depois de mais de vinte anos de criação e com a crescente demanda de projetos usando metodologias ágeis, começam a surgir vários questionamentos a respeito da sua importância. Será que os casos de uso são realmente importantes para projetos de pequeno e médio porte? Será que tanta “burocracia” e processos extremamente complexos garantem o sucesso do projeto?
O ultrapassado modelo cascata e o sapo de papel
Após entendermos o conceito de caso de uso, vamos questioná-lo levando em consideração o contexto no qual ele é inserido. Baseado em várias discussões que observei sobre a eficácia dos casos de uso, tive a impressão de que pelo menos da maneira como nos conhecemos hoje, eles não funcionam como deveriam funcionar. Como já dito no começo desse artigo, casos de uso servem para especificar os requisitos do sistema, e o que acontece na grande maioria das empresas é que se perde um enorme tempo na fase de requisitos do projeto e quando conseguimos chegar à fase de codificação do produto, grande parte da documentação é dúbia e confusa, sempre precisamos corrigi-la e acabamos tendo um enorme esforço para manter esse amontoado de artefatos, além disso, precisamos entender que devemos sempre entregar algum valor ao cliente desde o começo do projeto (Vide Blog do Borba).
Numa das experiências citadas por um amigo de trabalho, na qual ele participou de um projeto que tinha aproximadamente 700PF (pontos de função), e durante o projeto foi convidado para ministrar um treinamento de Scrum para o cliente (que era um departamento de TI de uma grande instituição pública), ele descobriu que a fase de levantamento de requisitos e escrita dos casos de uso desse projeto durou nada menos que dois anos. Ao final de dois anos produzindo papel e nenhum valor concreto para o cliente, finalmente começou a fase de implementação do produto que já estava atrasado, necessitando um enorme esforço da equipe para implementar o produto o mais rápido possível. Como acontece na maioria dos projetos de qualquer empresa que usa a metodologia cascata tradicional, é que a documentação sempre estava com vários “furos” de especificação, e toda semana tinha uma baseline nova, ou seja, toda semana encontravam-se falhas na documentação produzida durante dois anos, e por isso tinha-se que gastar esforço para corrigi-la e entendê-la. O mais impressionante, no final do curso, foi a resposta do grupo a seguinte pergunta: vocês acham que se tivéssemos começado a implementar o projeto desde o início, aos poucos, e usando Scrum, como estaria o projeto ao final desses dois anos? Resposta: acabado. Problemas na documentação como esse citado acima, ainda são comuns na empresas de hoje. É importante salientar que o problema desse e de muitos outros projetos não está nas pessoas que escreveram os casos de uso, ou no tempo que elas tiveram, mesmo que colocasse o melhor profissional do mundo em especificação de caso de uso com o tempo de sobra, ainda sim se teria problemas. O problema está no processo, não nas pessoas.
Outra experiência relatada foi uma dinâmica realizada num treinamento de Scrum onde os participantes deveriam fazer um sapo de papel (Origami). As regras eram o seguinte:
Os participantes devem montar duplas e dividir as duplas em três grupos, grupo 1, 2 e 3;
Todas as duplas iriam receber uma folha de papel contendo a especificação (tipo um caso de uso) de como fazer o sapo origami;
O grupo 1 deveria seguir a seguinte regra: um pessoa da dupla dobra o papel e a outra dita com devem ser as dobras seguindo a especificação fornecida. Restrição: as duas pessoas devem ficar de costas uma para a outra e não podem se virar, quem esta ditando não pode olhar o sapo em construção e quem esta fazendo o sapo não pode olhar a especificação, apenas escutar.
O grupo 2 deveria seguir a mesma regra do grupo um só que com restrições diferentes. As pessoas podem estar de frente um para a outra, quem está montando o sapo pode olhar a especificação mais não pode tocá-la, quem está ditando a especificação não pode tocar no sapo que a outra pessoa esta construindo.
O grupo 3 também deveria montar o sapo só que as duas pessoas poderiam dobrar o papel e ler a especificação. Esse grupo, não tinha regras e poderiam fazer do jeito que quisessem contanto que no fim chegassem ao mesmo resultado, montar o sapo de papel origami.
Os resultados foram reveladores. O grupo 1 não conseguiu fazer o sapo, saiu de tudo, menos um sapo. O grupo 2 teve muita dificuldade, chegaram perto mais não conseguiram fazer um sapo igual ao especificado no documento. O grupo 3 foi o que obteve maior êxito e a maioria da duplas conseguiram fazer o sapo. Qual a mensagem que essa dinâmica da construção do sapo nos passa? A mensagem que ela nos passa é que devemos trabalhar mais juntos. No grupo 3, as duas pessoas colocavam a mão na massa, um ajudava o outro, a responsabilidade era a mesma para os dois, as habilidades de um completava as habilidades do outro, os dois estavam no mesmo barco. Devemos trabalhar como o grupo 3. O que acontece hoje em várias empresas, é elas ainda estão trabalhando como o grupo 1, cada um tem responsabilidades diferentes, chagamos a escutar pessoas do grupo 1 falando: “eu fiz a minha parte, ele que não soube dobrar o papel, e a outra pessoa rebateu dizendo: você que não leu o papel corretamente por isso que eu não consegui fazer”, ou seja, parece que eles tinham objetivos diferentes e um empurrava a responsabilidade do fracasso para o outro. O que aconteceu nesse experimento foi o mesmo que aconteceu no primeiro, as pessoas do grupo 3 não eram nem melhores nem piores que a do grupo 1, o fator decisivo para o fracasso do grupo foi o processo que eles estavam inseridos. Podemos fazer uma analogia desse segundo experimento com o nosso dia a dia, a especificação de construção do sapo, são as nossas especificações de caso de uso de hoje, em que os analistas ficam um longo tempo escrevendo e depois nos enviam como se o problema não fossem mais deles. Podemos trabalhar como o grupo 1 sim, estando o mais próximo possível do cliente e desburocratizando um processo que deveria ser simples e nós mesmo o complicamos.
Qual a solução?
Com certeza não é o ultrapassado modelo cascata com os complicados casos de uso que usamos hoje. Casos de uso podem ser úteis sim, para sistemas extremamente complexos ou sistemas de segurança, mas na maioria dos sistemas que desenvolvemos, nos quais produzimos funcionalidades simples como inclusão, alteração, listagem, relatórios e etc. não são necessários. E qual seria a alternativa? A proposta desse artigo é levantar esse questionamento para tentarmos buscar formas mais eficientes de construir nossos projetos. Uma possível solução poderia ser estórias de usuários, prática sugerida pelas metodologias ágeis. Recomendo fortemente o estudo dessa técnica através do livro User Stories Applied de Mike Conhn para podermos visualizar um futuro com mais sapos e menos papeis amassados.
Sobre o autor
Roberto Luiz Sena de Alencar, graduado em desenvolvimento de software pela Unibratec/PE e mestrando em engenharia de software pelo Cesar.edu. Atualmente trabalhando como desenvolvedor de sistemas Java.
