Já esbarrei com vários desenvolvedores que estranharam o fato de utilizarmos, na empresa onde trabalho, a Qualidata, metodologias ágeis e ao mesmo tempo termos atividades de elicitação de requisitos, descrições de casos de uso e modelagem de domínio antes de um sprint de construção propriamente. Para eles, a leveza do Agile parece pedir sempre a leveza das “User Stories” e da comunicação face-a-face preconizadas pelo eXtreme Programming. Mas nem sempre é assim.

Por que descrevemos casos de uso na Qualidata?

Bom, primeiramente não quero em nenhum momento dizer que use-case é melhor ou pior que user-story. São coisas totalmente distintas e servem para propósitos distintos. Discutir o que é melhor só faz sentido dentro do contexto de um projeto ou uma realidade específica. A nossa realidade na Qualidata, em geral, é o desenvolvimento de sistemas corporativos com muitas regras de negócio – e você deve manter este contexto em mente ao ler o restante deste artigo.

Nós acreditamos realmente que “software em funcionamento mais que documentação abrangente” (do manifesto ágil) seja algo muito importante. É óbvio que no manifesto ágil a parte da direita não é necessariamente banida, mas apenas a parte da esquerda é mais valorizada. Ainda assim, essa frase do manifesto pede uma discussão muito mais fundamental e que talvez seja a causa de muita das confusões em torno do assunto. Descrição de caso de uso é documentação? Parece óbvio que sim, mas depende do que entendemos por documentação.

Em geral, quando as pessoas falam de documentação de um componente de software (e de outras coisas diferentes de software), elas estão se referindo a uma representação, textual ou não, do comportamento desse componente, visando facilitar seu entendimento quando alguém precisar lidar com ele no futuro. Em outras palavras, documentação em geral é vista como uma ferramenta de comunicação e um registro para uso futuro, para facilitar a vida de quem for lidar com isso mais pra frente.

Considerando essa visão de documentação, não tratamos descrição de caso de uso como mera documentação, pois não fazemos isso pensando primariamente na comunicação e no uso futuro. Utilizá-lo na comunicação ou ter um registro para o futuro, para nós, é mais um eventual bônus do que um objetivo.

E aqui, talvez, esteja o parágrafo mais importante deste artigo. Para nós, na Qualidata, descrever casos de uso é apenas mais um tipo de instrumento que utilizamos para REFLETIR, COMPREENDER e REPRESENTAR as necessidades dos usuários e as soluções de software que acreditamos serem mais adequadas. Antes de ser um instrumento de registro (documentação), ou mesmo de comunicação, é para nós, desenvolvedores, um instrumento de trabalho; um instrumento útil para o desenvolvimento de software. E nesse sentido ele não é o único. Dependendo da situação, teremos análise de domínio com diagramas UML, wireframe de telas, ou o que mais for considerado realmente importante para o desenvolvimento.

Se você é um defensor do Agile (nós somos) e torceu o nariz neste último parágrafo, das duas uma: ou você não desenvolve sistemas com complexidade de negócio e de cliente que exijam grande esforço para elicitação de requisitos (o que não quer dizer que o sistema não possa ser complexo), e por isso não entendeu direito o nosso cenário; ou você atua em um contexto parecido com o nosso, mas encontrou um outro caminho dentro dos princípios Ágeis, o que é totalmente possível, e eu teria muito prazer em conhecer através dos seus comentários.

O fato é que quando estudamos mais profundamente sobre metodologias ágeis, vamos perceber que existem metodologias super leves e também metodologias inevitavelmente complexas e pesadas, se o contexto assim o exigir. Fazer um software para um equipamento hospitalar de suporte à vida é diferente de fazer um site para venda de equipamentos eletrônicos, por exemplo. Logo, ser ágil não é ser super leve, mas é saber aplicar os princípios apresentados no manifesto ágil numa realidade que nem sempre admite um processo super leve.

Se você ler sobre DSDM (Dynamic Systems Development Method) ou Crystal Family Methodologies, todas metodologias ágeis, vai notar que existem muitas situações que não admitem um processo baseado em comunicação face-a-face entre a equipe de desenvolvedores e o “cliente” puramente.

Resumindo, por que então descrevemos casos de uso? Porque nos ajuda a entregar um software de qualidade com um prazo/custo menor do que se deixássemos tudo emergir, confiando na refatoração de código – que apesar de ser totalmente viável, por causa do nível de desacoplamento que adotamos, tem um custo elevado dentro do processo de desenvolvimento de sistemas grandes e complexos.

Além das descrições de casos de uso, trabalhamos com outros tipos de artefatos que chamamos generalizadamente de ARCs – Artefatos de Representação do Conhecimento (evitamos propositalmente a palavra documentação), que utilizamos para construir e representar esse conhecimento que depois será mapeado em software pelos programadores – que obviamente precisarão tomar muitas decisões de construção, mas partirão de um problema discutido e mapeado previamente, consistente o suficiente para dar fluidez no planejamento da construção.

Pode parecer estranho para alguns, mas no nosso contexto é natural que existam questões que levarão muitos dias ou semanas para serem respondidas, dependendo de várias reuniões com diferentes pessoas do cliente. Independentemente de quem irá conduzir essas reuniões, o fato é que, neste caso, deixar esse problema emergir no meio da construção para, então, ser analisado me parece muito improdutivo.

É importante destacar que, para nós, descrições de casos de uso não servem para evitar comunicação face-a-face, seja com o cliente ou com analistas de negócio. Muito pelo contrário, a comunicação dos desenvolvedores com os demais envolvidos deve acontecer continuamente, tendo as descrições de caso de uso e demais ARCs sobre a mesa para permitir uma discussão mais sistemática e organizada. Mas ela precisa acontecer face-a-face. Mesmo porque os ARCs não são registros estáticos. São artefatos dinâmicos, que evoluem junto com o código e os demais artefatos. Talvez documentação seja exatamente isso, mas em geral as pessoas tendem a tratar documentação de outra forma, por isso evitamos o termo.

Se nosso argumento ainda não foi suficientemente forte, resta dizer que não estamos sozinhos nisso. Alistair Cockburn, um dos 17 desenvolvedores que redigiram o manifesto ágil, utiliza casos de uso. Aliás, “Por que eu ainda utilizo casos de uso” é um ótimo artigo para quem quer entender melhor por que user-story em nossa realidade não nos atende bem.

Também Scott Ambler, em seu livro “UML in an agile way” (p.261), defende o uso de casos de uso mas com certos cuidados:

“Utilize os artefatos corretos, crie vários modelos em paralelo, e interaja com os outros artefatos quando estiver modelando. O resultado final disso é que não tentará colocar tudo em seus casos de uso, mas utilizará cada tipo de artefato naquilo em que ele é melhor” (a tradução é minha).

E é exatamente nessa linha que trabalhamos nossos ARCs na Qualidata. Como diz nosso colaborador Marcelo Arrevabeni, “até história em quadrinhos pode ser utilizada como ARC, se isso parecer ser o mais adequado para o projeto”. Os tipos de ARC utilizados variam de projeto para projeto, pois cada realidade exige um processo de software com o peso adequado, observando sempre os princípios do manifesto ágil.

É sempre bom quando precisamos quebrar uma regra e depois vemos que não estamos sós, que a mudança realmente era necessária. Há alguns anos, tivemos que fazer alguns ajustes nas descrições de caso de uso, criando o conceito de “sub-caso de uso” para permitir que descrevêssemos os casos de uso de forma incremental e que trabalhássemos com sprints de duas semanas, pois um caso de uso grande não ficava pronto nesse tempo.

É curioso notar que Ivar Jacobson, pai do diagrama de casos de uso da UML, e um daqueles caras que aparecem em todo livro de Engenharia de Software ao lado de Rumbaugh, Booch, Ambler e outros, publicou em dez/2011 o eBook “Use-Case 2.0 – The Guide to Succeeding with Use Cases”. O principal conceito apresentado por ele nessa versão 2.0 foi, adivinhe, “use-case slice”, que nada mais é do que uma forma de dividir um caso de uso que descreve uma funcionalidade grande e complexa em partes menores, facilitando o uso de descrições de casos de uso em metodologias ágeis como o Scrum. Até a ideia de utilizar números como “7.1”, “7.2” para as partes de um caso de uso “7” foi igual ao que fizemos.

No final das contas, metodologias ágeis podem ser nada burocráticas e até mesmo, quando necessário, muito burocráticas, pois ser ágil tem mais a ver com saber aplicar os princípios do Agile do que utilizar certo grupo específico de metodologias e técnicas.

Se você trabalha em uma realidade de sistemas/clientes parecida com a que apresentei, gostaria muito de ouvir como tem lidado com essas questões, afinal, apesar de não acreditarmos em uma forma certa, buscamos sempre formas melhores de desenvolver software.