A agilidade de um processo não está nos artefatos gerados e sim no modelo utilizado

No segundo semestre do ano passado foi publicado no site JavaFree.org o texto Caso de Uso: Ajuda ou Atrapalha? Neste post procuro colocar meu ponto de vista sobre o assunto em questão. Reproduzo na íntegra as questões delineadas pelo texto:

“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?”

Como resposta, o autor afirma que casos de uso não funcionam como deveriam e a justifica com o seguinte trecho:

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”.

Ao analisar a justificativa proposta pelo autor, proponho a comparação entre caso de uso e cartão de estória, artefato este utilizado pelos processos ágeis.

Em um cartão de estória, o usuário expressa um requisito que deve ser atendido por um determinado software. Por exemplo: Imprima os clientes que fazem aniversário no mês de fevereiro.

Um caso de uso é um documento narrativo que descreve a seqüência de eventos de um agente externo (ator) que usa um sistema (ou software) para completar um processo. Caso de uso está relacionado com o conceito de histórias ou casos de utilização de um sistema (ou software).

Ambos os artefatos são caracterizados como documentos narrativos. O que nos leva a crer que a estrutura básica de um caso uso não difere substancialmente de um cartão de estória.

A partir dos fatos explicitados é possível concluir que:

a agilidade do processo não se encontra nos artefatos e sim no modelo de processo a ser utilizado.

É perfeitamente possível ser ágil em projetos de pequeno e médio porte utilizando caso de uso, para que isto ocorra é necessário instanciar um processo a partir do modelo evolucionário.

“O modelo evolucionário tem como base a idéia de desenvolver uma implementação inicial, expor o resultado ao comentário do cliente e fazer seu aprimoramento por meio de muitas versões, até que um sistema adequado tenha sido desenvolvido. Em vez de se ter as atividades de especificação, desenvolvimento e validação em separado, todo esse trabalho é realizado, concorrentemente, com um rápido feedback por meio dessas atividades” (SOMMERVILLE (2003) p. 39)”.

Todos sabem que o modelo de processo evolucionário alicerça o conceito de processos ágeis. A opção pelo velho modelo cascata, alinhado a produção de cartões de estórias provocarão os mesmos problemas delineados pelo autor, veja só:

… ao se perder um tempo enorme na fase de requisitos do projeto, escrevendo cartões de estórias, quando chegarmos à fase de codificação do produto grande parte da documentação será dúbia e confusa, sempre precisaremos corrigi-la e acabaremos tendo um enorme esforço para manter esse amontoado de cartões… (nas justificativas delinadas no texto citado no início do post, apenas substituí o termo caso de uso por cartões de estórias)

Por fim, gostaria de ressaltar que a opção por um processo em detrimento a outro não pode levar em conta somente questões ligadas a modismo. Certamente voltaremos a discutir este assunto…

J. A.

4 Responses to “A agilidade de um processo não está nos artefatos gerados e sim no modelo utilizado”

  1. Olá,

    Nos últimos semestres tentei aproximar minha disciplina de Administração da Produção com a de Análise de Sistemas. Ao solicitar a documentação do sistema proposto percebi que os alunos tinham muita dificuldade para usar o caso de uso e que os grupos apresentavam documentos muito diferentes. Então, solicitei a todos os grupos que apresentassem seus trabalhos e, por consenso, chegamos a um resultado único. Percebi que em uma sala de 30 alunos, apenas 3 pareciam estar seguros sobre a correta documentação.
    Daí fica a questão: o problema não estaria na falta de habilidade na utilização tanto do caso de uso quanto dos cartões de estórias?

  2. Por qual email conseguimos entrar em contato com o autor deste blog?

    Aguardamos contato.

    Att,

    DevMedia.

  3. Anna Carolina Says:

    Por qual email consigo entrar em contato com o autor deste blog?

    Aguardo resposta.

    Att.

    DevMedia.

  4. Concordo com a Eliana ao questionar a habilidade dos profissionais em conceber os Casos de Uso antes do questionar sobre a utilidade da ferramenta.

    É muito comum ainda hoje encontrar não somente estudantes, mas também profissionais graduados com enorme dificuldade em criar Use Cases.

    O que falta, segundo a minha visão, é know-how para utiliza-los, pois se bem construídos tornam-se mais que um “artefato”, mas uma referência de suma importância para o processo de desenvolvimento e validação (apuração da qualidade) do software, uma vez que podem ser, adicionalmente, utilizados para a geração dos Test Cases que guiarão a métrica da qualidade do sistema.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: