Seções iMasters
Gerência de Projetos

Uso de Artefatos de Representação do Conhecimento na modelagem de domínio em metodologias ágeis

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.

Comente também

6 Comentários

Carlos Tristacci

Fabrício, achei interessante sua abordagem, mas não acredito muito nela. Por ter trabalhado com sistemas complexos em diversos clientes como SEBRAE, Banco do Brasil, Ministério de Minas e Energia, Ministério da Educação entre outros. Onde em algum momento utilizamos Casos de Uso e a resposta dos clientes era simplesmente, “não quero isso! Pois é complicado demais…” A descrição textual passo-a-passo é complicada para usuários não técnicos.
O que percebo aqui em Brasília em diversos órgãos e empresas é a substituição dos casos de uso por protótipos/wireframes/mock-ups. Estes mock-ups tem seus campos e comandos detalhados e regras de negócio associadas.
Estórias de usuário pela experiência que tenho no trabalho que realizo e pelos estudos que realizo na área não é simplesmente uma descrição simples, no sentido de não atender as necessidades de informação necessárias a implementação ou consultas futuras.
Estórias de usuário são compostas por três partes:
- Descrição – A descrição deve ser escrita pelo usuário para que ele possa obter maior clareza e entendimento da funcionalidade requisitada. Normalmente escrita dentro da estrutura Como [usuário/papel], quero [objetivo], para que eu possa [motivo].
- Conversação – Espaço onde a equipe de desenvolvimento detalha a descrição. Aqui são descritas as regras de negócio, inseridos mock-ups ou qualquer diagrama que for necessário para o entendimento e implementação do requisito.
- Confirmação – Espaço onde são descritos os testes de aceitação desta estória.
Acredito que por termos uma descrição que define, pré-condição, objetivo e pós-condição na descrição da estória e um detalhamento realizado de acordo com a complexidade de cada estória na conversação e ainda testes de aceitação que ajudam a identificar cenários e a abrangência dos testes, seja o suficiente para atender as necessidades de sistemas complexas.
É bom citar que Alistair Cockburn escreveu em seu livro Escrevendo Casos de Uso Eficazes: “Um casos de uso captura um CONTRATO entre os interessados de um sistema sobre seus comportamentos”
E Mike Cohn em seu livro Estórias de Usuários Aplicadas escreveu “Uma estória descreve funcionalmente o que será valioso para os usuários e aos compradores de um software”.
Vejo o primeiro como uma forma de defesa contra mudanças e o segundo como forma de descrever o que é necessário.

Fabrício Vargas Matos

Obrigado Carlos por ter compartilhado sua experiência aqui.

Primeiro acho que este artigo não deve ser lido como uma defesa a casos de uso, mas sim uma defesa à necessidade de termos artefatos sobre os quais possamos refletir, compreender e representar bem as necessidades dos usuários/clientes. Alguns desenvolvedores menos experientes costumam achar que comunicação face-a-face elimina toda necessidade de criar documentos. Estamos defendendo que o valor de artefatos vão muito além de documentar (registrar) algo, enfatizando o aspecto “compreender” e “representar” esse entendimento, para que o mesmo possa ser validado, e possa também crescer de forma consistente na medida que avançamos no desenvolvimento do sistema.

Acredito que ter no caso de uso uma forma de defesa contra mudanças seja algo extrínseco, muito mais ligado a quem está utilizando-o dessa forma, o que certamente não é o nosso caso. Se Cockburn pensa assim, não sei, mas o fato é que usar casos de uso não nos força a fugir das mudanças, isso se você concebê-los sabendo que haverá mudanças.

Mas concordo que a leitura dos casos de uso por não técnicos seja complicada, o que nós aqui resolvemos na linha do que você mesmo falou (wireframes, mock-ups, etc..).

Entendo que você pode complementar as estórias com outras informações (conversação e confirmação no seu caso). Apesar de particularmente entender que na sua origem (http://www.extremeprogramming.org/rules/userstories.html) estórias são apenas a primeira parte que chamou de “Descrição”, concordo que esse mix de ARCs (wireframes, estórias desse jeito mais completo, digamos assim, e outros) são uma boa alternativa.

Como disse, “até história em quadrinhos pode ser utilizada como ARC, se isso parecer ser o mais adequado para o projeto”.

Não temos qualquer birra com estórias de usuários. Se em um projeto nosso entendermos que será mais adequado utilizar estórias, utilizamos sem problema.

No final, essas “estórias de usuário” turbinadas com pré-condições, regras de negócio, mock-ups e testes de aceitação acabam se assemelhando muito ao que produzimos aqui, talvez não em estilo, mas em conteúdo e propósito, e por isso ousaria dizer que estamos muito mais alinhados do que parece.

Carlos Tristacci

Fabrício, concordo plenamente com você.
Muitos times “agéis” consideram que documentação é post-it, que se perdem quando caem do Kanban e o pessoal da limpeza passa…
Acredito que no manifesto ágil ao mencionar: “Software em funcionamento mais que documentação abrangente” é no aspecto que não precisamos realizar planos e documentações tentando fechar todas as lacunas e cenários imagináveis e sim criar a documentação necessária para o entendimento do que deve ser implementado, deixando espaço para o feedback, adaptação e a resolução dos impedimentos quando surgem.
A estória do usuário definida no XP realmente é mínima, inclusive o XP menciona que não deve ser estruturada, mas a comunidade vem adotando e sugerindo esse detalhamento. Acredito que vale para a contribuição deste artigo: http://www.carlostristacci.com.br/blog/estorias-do-usuario/

Carlos Tristacci

Apenas para deixar claro, não tenho nada contra casos de uso, apenas acho desnecessária a descrição de fluxos. Pois, um objetivo claro, um mock-up e uma regra de negócio bem escrita seja o suficiente para que a equipe de desenvolvimento e as demais partes interessadas tenha a compreensão do que deve ser entregue.
A parte mais interessante das estórias de usuário é que deve ser escrita pelo cliente, forçando que ele pense no que está solicitando e sinta-se responsável. O detalhamento ou conversação é escrita qdo a equipe de desenvolvimento encontra-se com o cliente para retirar dúvidas e ter a compreensão do que está sendo solicitado. Neste momento, toda a equipe e não apenas o analista de requisitos adquire a comprrensão do requisito e pode inclusive sugerir outras formas de implementá-lo, enriquecendo o requisito e gerando um entendimento coeso. Os testes de aceitação também devem ser escritos pelo cliente sob a orientação de um analista de teste, fazendo com que o cliente pense no que é necessário para que ele aceite a estória como entregue.
O grande diferencial que eu vejo nas estórias é ela ser escrita pelo cliente, pois o grande problema no desenvolvimento de software é que o cliente frequentemente não sabe o que quer, e escrevendo as estórias ele pensa melhor no que está sendo solicitado e diminui os ruídos de comunicação.
Mas mesmo assim se for necessário utilizar casos de uso e outros itens de trabalho do Processo Unificado, acho interessante o trabalho realizado pela comunidade Eclipse na definição do OpenUp (http://epf.eclipse.org/wikis/openuppt/index.htm), com qual trabalhei por algum tempo no processo de transição para metodologias ágeis que realizei em uma empresa.

Fabrício Vargas Matos

Bacana. Valeu!

Qual a sua opinião?