Débito Técnico

Na edição 29 da revista MundoJava escreví sobre o dia a dia de um agilista. Continuando uma série sobre TDD na Revista MundoJava nesta edição escreví um artigo sobre a ferramenta FIT para automação de testes. O artigo teve participação de Ivan Sanchez e James Shore.

O Ivan Sanchez foi o cara que fez o treinamento CSM junto comigo no início de 2007, e teve o azar de cair no mesmo grupo comigo! O Ivan é um agilista e grande evangelista de Coding Dojos. Atualmente trabalha na Signature Technologies no Reino Unido.

James Shore (Jim) é lider do projeto FIT (criado por Ward Cunningham), atua em projetos ágeis desde 1999 (sim, existem projetos ágeis antes do Manifesto Ágil) e escreveu o livro “The Art of Agile Development“.

Uma das coisas legais de escrever na MundoJava é ter contato com esses caras lá de fora e poder trazer estes conteúdos para nossa comunidade. Escrever com o Scott Ambler e o Jon Kern foi muito legal. Este artigo com o James Shore também foi especial. Infelizmente eu recebo mais não do que sim, mas ainda vou continuar insistindo com os mestres! Ah… vocês querem o trecho grátis do artigo, certo? Então aí vai:

Uma das questões comuns é: Quem escreve os dados de teste? Pela estratégia do FIT, os dados de teste são escritos a “oito mãos”. É comum que tudo inicie com o usuário ou cliente e com o analista de negócios, capturando cenários de teste iniciais que formatam alguns critérios de aceitação. Depois disso, um desenvolvedor pode verificar a formatação das tabelas, referenciar as Fixtures e assim obter o RED do ciclo TDD. Ao mesmo tempo os testers podem participar colocando mais cenários. Logicamente, o FIT é uma ferramenta ágil. É importante uma rica colaboração face a face de todos os envolvidos para que exista sucesso na adoção dessa abordagem.

Uma atenção especial deve ser dada ao trabalho do analista de negócios. Atualmente é comum que esses profissionais capturem requisitos em documentos texto e alguns diagramas. Geralmente este tipo de abordagem é muito pobre para o desenvolvedor, principalmente se não existe uma comunicação rica entre eles. Comunicação com documentos é uma forma muito pobre de comunicação (veja artigo “Modelagem Ágil”, MJ 27). Um modelo de requisitos em texto é muito deficiente na maioria das vezes. Pare para pensar: Não existe teste sobre documentos em texto e nem compilador para diagramas!
Rodrigo Yoshima

O que é o FIT e porque se importar com ele? O FIT é parte do seu arsenal ágil de prevenção de bugs. Diferente da abordagem tradicional para a qualidade, onde focamos em encontrar e remover defeitos, as práticas ágeis focam-se primeiramente em previnir que bugs sejam criados. Isso nos leva a alguns resultados impressionantes. Times ágeis experientes produzem poucos bugs por mês.

As “práticas ágeis de engenharia” pregadas pelo Extreme Programming (XP) são parte da solução. Essas técnicas como Test-Driven Development (TDD), programação aos pares, propriedade coletiva do código, design simples e trabalho energizado previne a maioria dos erros de programação. Elas garantem que o código faz exatamente o que os programadores pretendiam que ele fizesse.
James Shore

FIT ou Framework for Integration Testing é uma ferramenta excepcional no auxílio ao desenvolvimento de um software. O cliente (ou analista de negócio) escreve tabelas mostrando o que o sistema deve fazer através de exemplos. O desenvolvedor escreve o código das fixtures, que são as classes que ligam as tabelas com o sistema que está sendo implementado. A partir daí as tabelas se tornam “executáveis” e as regras definidas podem ser validadas de maneira automatizada.

FitNesse é a implementação mais popular de FIT, que funciona na forma de um wiki. Cada página representa um teste executável e é possível executar múltiplas páginas para validar um sistema como um todo. Além disso, por se tratar de um wiki, favorece a colaboração entre cliente e desenvolvedores, podendo servir como uma ótima base de conhecimento sobre o sistema que está sendo construído.
Ivan Sanchez

O FIT é uma ferramenta muito interessante: Uma coisa que chama a atenção em projetos onde utilizamos o FIT é que produzir as tabelas com os dados de teste é uma atividade de modelagem intensa. Modelar não é fazer diagramas, é muito mais profundo do que isso!

Já nas bancas!

Na edição atual da MundoJava (número 30) não teve artigo meu. Pedi “férias” exatamente para organizar este blog e colocar algumas outras coisas em ordem. Mesmo sem artigo tivemos na Aspercom a missão de fazer um poster com práticas ágeis para o pessoal da revista.

Nunca tinha feito um poster desses na vida, mas sabia que era um trabalho criativo, artístico… não muito diferente de modelar software e escrever linhas de código. Porém, além do poster passar informações importantes ele deveria ser bonito!

Antes de começar qualquer coisa, precisaríamos definir o que colocar no poster. O poster tem limitação de espaço e gostaríamos colocar as práticas mais importantes e não todas elas! Para fazer isso, definimos alguns post-its com o conteúdo. Decidimos colocar basicamente as práticas do Scrum.

Tinha visto algumas apresentações em eventos mostrando que o processo ágil é cíclico e não linear, assim como o famoso poster da VersionOne. O processo cíclico é uma das características mais importantes de qualquer processo ágil e não podia ficar de fora!

Estou viciado em modelagem ágil para fazer muitos tipos de trabalho. Fui influenciado pelos conceitos do Design Thinking para elaborar este poster: “Pense no processo como um conjunto de espaços e não uma sequência de passos predeterminados”. Tentamos vários “modelos” e usar post-its para testar o conteúdo na disposição do poster foi determinante. Após várias “versões” para escolher e vários rascunhos em papel A4, decidimos o melhor.

Eu e a Patricia (minha esposa, sócia da Aspercom e responsável pela parte de mídia) sentamos num único micro com o CorewDraw para passar aquilo para meio eletrônico em pair programming (neste caso, pair drawing), aonde também decidimos a imagem do fundo. Depois, foi só juntar tudo, descobrir como fazer algumas coisas no Corel, adaptar algumas idéias que não deram certo e testar o desenho o tempo todo. O resultado final foi muito bom.

Creio que na minha caixa de email deve ter pelo menos umas 300 mensagens de leitores da MundoJava e de participantes da UML-BR pedindo informações sobre a certificação UML. Como repito as mesmas coisas a cada mail que respondo creio que passar este post em link vai me ajudar um pouco a dar uma resposta melhor.

Valor de Mercado

Na minha opinião é até meio sem sentido. A certificação OCUP da OMG é uma certificação originalmente direcionada a Tool Vendors (os caras que criam ferramentas UML), mas o mercado é meio viciado em certificação, principalmente as certificações “raras”, então, a certificação UML da OMG é bem valorizada. Creio que fui um dos primeiros a obtê-la aqui no Brasil.

Como “peso” de conhecimento na minha opinião a certificação IBM Rational Solution Designer é muito melhor. Tem muito conhecimento da prova da OMG que simplesmente é dispensável para o nosso dia a dia. Geralmente digo que prova não prova nada, por esta razão, não critico tanto a certificação CSM da ScrumAlliance (a não ser pelo preço, acredite, tem gente lá fora ficando rico com isso). A certificação OCUP da OMG não prova que você sabe o que é orientação a objeto, nem que é um bom modelador. Só prova que você conhece a especificação da UML 2.

Existem 3 níveis de certificação UML: Fundamental, Intermediate e Advanced. A Fundamental representa os famosos 20% da UML que é utilizada em 90% dos projetos [Jacobson] e creio que seja o nível que todos os profissionais aqui do Brasil possuem. Não vejo muita utilidade e nem tanto valor de mercado em investir mais do que a Fundamental.

Como é a prova OM0-100 (Fundamental)?

São 84 questões onde somente 80 valem para a avaliação. As 4 questões que não valem pontos são logo no início da prova e simplemente é uma pesquisa (não perca muito tempo com elas). Todas as questões são múltipla escolha, porém, tem aquelas famosas questões onde você deve assinalar mais de uma como correta. Exemplo: What applies to a Package? (mark 2).

A prova é bem conceitual. Ela valida bem o conhecimento da UML e as perguntas são baseadas na UML Superstructure Specification, v2.0 (05-07-04). A prova não é baseada na versão mais atual da UML2.

O que cai na prova Fundamental são conceitos básicos, diagrama de classes, diagrama de atividades, diagrama de sequências e diagrama de casos de uso. Se quiser fazer a prova, preste muita atenção no seu plano de estudos porque para o nível Fundamental não é tudo que cai na prova sobre cada diagrama. Como exemplo, sobre diagrama de atividades, Forks e Joins é um assunto que não cai na prova do nível Fundamental. No site de certificação existe um PDF que diz exatamente o que cai em cada nível baseado na Superstructure. Preste atenção exatamente no que cai para não estudar mais que o necessário.

A maior dificuldade da prova é o tempo. Minha recomendação é que se você sabe um pouco sobre UML não tente fazer a prova na caruda achando que UML é fácil. A prova é baseada na especificação da UML e não simplesmente diagramas onde você vai responder “Qual elemento é o ator?” ou “O que aquela linha com seta vazada significa?”. Vou dar o meu relato: já trabalho com “UML” deste o método Booch e a OMT (alguém se lembra do CoolJex?) mesmo assim não sobrou tempo. São 80 questões para responder em 90 minutos e algumas questões sobre diagrama de sequências e casos de uso você realmente precisa parar para pensar! Uma outra recomendação é que se você tem um inglês fraco pense duas vezes antes de fazer a prova. A prova é conceitual e o inglês é formal e técnico. O tempo é o maior desafio nessa prova.

Sugestão de estudo

Um ponto interessante é que literaturas tradicionais de UML (Ambler, Fowler, “Três Amigos”, Larman) vão te ajudar muito pouco. São ótimos livros, mas não para a certificação. Uma literatura que não existia na época que me certifiquei é o UML 2 Certification Guide: Fundamental & Intermediate Exams. Não posso comentar sobre este livro pois não lí. O livro que estudei para a certificação é o UML Bible do Tom Pender. É uma literatura bem completa que uso como referência muitas vezes. Aborda questões da Superstructure, tem exemplos e fala também da UML 1.X.

Se quiser estudar pelo Tom Pender meu guia de estudo é esse:

Conceitos Gerais: Capítulo 1 a 4
Diagrama de Classe: Capítulo 5 e 6 e Diagrama de Objetos do Capítulo 7.
Diagrama de Interação: Capítulo 9 (até Interaction Occurence)
Diagrama de Use-Case: Capítulo 12
Diagrama de Atividade: Capítulo 13

Independente da literatura que você escolher, a idéia é olhar o programa da prova citado, estudar primeiramente por algum livro e logo após estudar pela própria UML Superstructure Specification, v2.0 (05-07-04). O estudo pela Superstructe é obrigatório. Mas a Superstructure é um texto bem chato de ler.

O estudo pela Superstructure é importante por duas razões. A prova é baseada nesse texto e algumas perguntas como “What is a Namespace?” não constam em literatura nenhuma. Só está na especificação. Em segundo lugar algumas questões da prova apresentam diagramas que constam na especificação. Saber os diagramas exemplo que estão na Superstructure pode ser a chave para ir bem na prova.

O curso UML da Aspercom

Nosso curso UML 2.0 & Unified Process não é focado em certificação, mas fornece uma boa base para a prova se você não quiser estudar sozinho pela literatura indicada. Nosso curso é mais focado em demonstrar 3 bases importantes para análise e design de projetos orientado a objeto: Requisitos com Casos de Uso, Modelagem e Arquitetura. Um dos nossos alunos, o Daniel Guttermeyer (Iconophobia), relatou na lista UML-BR que obteve a certificação fazendo nosso curso e estudando pela Superstructure.

A Aspercom não é uma empresa muito fã de certificações, apesar de não ser 100% contra. Somos fãs de conhecimento. Isso pode ser constatado na nossa Visão e Missão.

Simulados

Buscando por “UML” no http://exams.googletoad.com/ achei dois simulados da OM0-100 (Fundamental): O da Pass4sure e o da ActualTests. Dei uma olhada bem por cima e creio que esses simulados podem ser uma referência sobre as questões que caem na prova. Não se assuste. Como disse a prova não é ver um diagrama e mostrar qual elemento é uma classe!

Mais informações:

O preço de cada prova de certificação é US$ 200. O centro de certificação é a PearsonVue. Para mais informações visitem os links abaixo:

http://www.omg.org/uml-certification/
http://www.pearsonvue.com/omg
http://exams.googletoad.com/?examsQ=uml

Nesta semana ministrei nosso workshop Scrum para a animada equipe da agência VM2. A VM2 é uma empresa especializada em projetos de design e mídia on-line em geral. Possui uma vasta carteira de produtos e já entregou mais de 750 projetos.

É interessante ver como uma empresa que veio do mundo da publicidade é bem diferente de empresas que simplesmente são produtoras de software. No trabalho da VM2 existe o trabalho artístico de design e também o dia a dia do desenvolvedor de software, lidando com integrações, frameworks, patterns, modelagem, testes e etc… A empresa deseja utilizar o Scrum para ter uma visão única do projeto, adotando a característica multi-disciplinar da metodologia.

Uma das coisas legais do nosso workshop é o exercício de levantar as User Stories de um projeto de rede social empresarial. Nós fazemos o planejamento de um projeto partindo do zero: eu faço o papel de cliente e os alunos fazem parte do corpo técnico.

Nesta atividade os alunos devem achar as User Stories conforme a conversa com o cliente se desenvolve. Não é a primeira vez que ví um aluno fazendo isso, mas dessa vez conseguí pegar um deles no flagra.

Nós também temos atividades de modelagem ágil na concepção deste projeto, porém, intuitivamente este aluno (ele se chama Everton) estava modelando um mapa de navegação do sistema só para compreender melhor o problema, na melhor forma do “modelar com um propósito” da Agile Modeling. Ninguém tinha pedido pra ele fazer modelo algum, mas ele o fez por necessitar dele. Ele fez para o propósito de ter uma melhor visão sobre as Stories.

Creio que este é um bom exemplo dos benefícios de modelar. Um modelo não é uma especificação. Modelar deve ser uma atividade intuitiva e não uma obrigação. A formalidade do modelo costuma variar conforme a necessidade.

O que está na cartolina azul é um mistério…

Muitos outros alunos fazem outros tipos de diagramas. Alguns deles são completamente indecifráveis para quem não participou da sua elaboração. Nenhum deles são “UML compliant”. Muitos fluxogramas simples costumam aparecer. Outros (como eu) simplesmente precisam de um papel para rabiscar coisas enquanto falam.

É só afastar as cadeiras!

Parabéns e obrigado a todos da VM2 pela hospitalidade e pela troca de informações sobre PHP, Web Design, LAMP e etc… Até o próximo treinamento!

Nesta semana eu e o Phillip Calçado compartilhamos uma coisa: nós lemos artigos numa revista fora do mundo de tecnologia (se é que existe isso hoje em dia) e achamos conceitos ágeis lá. Veja este post no blog gringo dele:

BigPharma Problems & Solutions: Have You Seen This Before?

Na edição brasileira da Harvard Business Review de junho/2008, Tim Brown escreveu um artigo apresentando o “Design Thinking”. Ao ler o artigo ví que Design Thinking é recheado de conceitos ágeis. Muito recheado! É praticamente uma abordagem ágil para a inovação em todas as esferas empresariais.

A abordagem de [Thomas] Edison é um dos primeiros exemplos do que hoje se chama design thinking - metodologia que imbui todo o espectro de atividades de inovação de um etos de concepção centrado no homem… Edison não era um cientista especializado num campo apenas - era, antes, um generalista com aguçado tino comercial. Em seu laboratório em Menlo Park, New Jersey, Edison se cercava de gente com talento para improviso e experimentação. Na prática, derrubou o mito do “inventor genial e solitário” ao criar uma abordagem de equipe à inovação.

Preste atenção nesta parte:

A idéia era justamente não corroborar hipóteses preconcebidas - mas ajudar o investigador a aprender algo a cada lance iterativo.

(grifo meu)

É interessante ver como pragmatismos estão florescendo dentro no mundo empresarial das pessoas espertas e como mais e mais rigidez e controle estão obscurecendo a vida das empresas burras. Design Thinking é uma perspectiva humana para a solução dos problemas. É o envolvimento de cada indivíduo, de cada mente, na busca de uma solução viável e criativa. Isso envolve empatia, raciocínio integrativo, otimismo, experimentação e colaboração. O Design Thinking é a dinâmica de um processo colaborativo de inovação. Relatando um caso de solução para um problema de um grupo de enfermagem da Kaiser (não é a fábrica de cervejas), Tim Brown acrescenta o que colaborou para a solução:

…as equipes de inovação exploraram soluções potenciais por meio de brainstorming e prototipagem rápida… Um teste com protótipos não precisa ser complexo e nem caro. Um protótipo deve consumir apenas a quantidade de tempo, esforço e investimento necessária à geração de um feedback útil a evolução da idéia - nada mais. Quanto mais “acabado” parecer um protótipo, menor a probabilidade de que seus criadores ouçam o feedback - e se valham dele.

Olha que engraçado! A HBR, uma revista tradicionalíssima, está dizendo que meus protótipos visuais estão certos! Quando aquele gerentinho metido torcer o nariz poderei falar: “- Você leu o artigo sobre Design Thinking na Harvard Business Review?”

…o que ocorreu na equipe de enfermagem da Kaiser não foi um avanço súbito e revolucionário, nem o estalo de um gênio - foi fruto do trabalho árduo realçado por um processo criativo de descoberta centrado no ser humano, seguido de ciclos iterativos de testes com protótipos e aperfeiçoamento.

Esta é a parte que mais gostei (comentários meus entre parênteses):

O melhor jeito de descrever o processo de design é metaforicamente (Beck?) - como um sistema de espaços, em vez de uma série predefinida de passos ordenados (Gantt?). Esses espaços delimitam tipos distintos de atividades correlatas que, juntas, formam o continuum da inovação. O Design Thinking pode parecer caótico para um marinheiro de primeira viagem (seu chefe?). Mas, no decorrer de um projeto, os participantes acabam entendendo que o processo faz sentido e produz resultados (um release?), ainda que sua arquitetura seja distinta do processo linear fundado em marcos intermediários característico de outras atividades empresariais.

Este parágrafo no artigo é uma das melhores definições que já ví a respeito da natureza de um processo de design. Desenvolver software é 100% design. Isso foi tão contundente pra mim que contactei o Tim Brown - o autor do artigo - perguntando se ele tinha sido influenciado pelas práticas do Agile Software Development. Veja a resposta dele entre outras coisas:

From: Tim Brown
Date: 2008/7/2
Subject: Re: Article about Design Thinking on Harvard Business Review
To: Rodrigo Yoshima

Hi Rodrigo,
It doesn’t surprise me to hear that software design shares many of the same characteristics as design thinking. You are right that there has not been a lot of interaction between these two communities other than through the computer human interaction folks where I think a lot of these same issues have been discussed.

Thanks for making the link.

Best regards
Tim

On 6/30/08 5:53 PM, “Rodrigo Yoshima” wrote:

> Hi Tim,
> I’ve just read your article about Design Thinking and I’m
> just very very curious about how you put Design Thinking
> pratices together. Design Thinking concepts are very close
> to Agile Software Development Practices. Have you ever
> heard about it? Take a look at www.agilemanifesto.org.
>
> I see that the values of the Agile Manifesto is our flag of
> Design Thinking on Software Development. 100% of the
> software construction is design. Agile Practices are:
>
> - Human centered / Focused on Team Work
> - Iterative / Cyclical / Feed-back based
> - Use a lot of Prototypes / Sketches
> - Empirical
>
> I guess that you can really benefit from the contents
> that our community have being studying for the last 20 years.
>
> Cheers.
>
> Rodrigo Yoshima
> ASPERCOM / MundoJava

Sim! Mais uma vez provamos que o futuro do mundo empresarial é empírico e pragmático. Mais uma vez está provado que rigidez e processos inflexíveis impedem a inovação. Quem só tem martelo na mão só vê pregos pela frente… e sai martelando tudo.

Na edição 19 da Revista MundoJava em meados de 2006 iniciei a publicação dos meus trabalhos na coluna MundoOO. Este primeiro artigo publicado teve um impacto extremamente positivo e até hoje muitas pessoas comentam sobre esta publicação.

Eu já ministrava treinamentos UML há algum tempo e participava de muitos fóruns de discussão como o UML-BR e o GUJ. O mercado tem um entendimento muito ruim sobre UML e modelagem em geral, assim, o que eu já pregava nos cursos transformei em literatura.

O artigo “UML não é Documentação” demostra o uso da UML de maneira prática e concisa, bem próximo da visão de modelagem ágil de autores como Scott Ambler e Martin Fowler.

Numa iniciativa conjunta do Blog Débito Técnico e o pessoal da MundoJava, estamos deixando este artigo disponível para download no site da Aspercom na página do projeto HotMotors. Este projeto com fins acadêmicos que anda parado (e com uma arquitetura que apesar de popular em 2006 não me dá muito orgulho) ainda será reativado um dia. Minha idéia é portar isso para Seam e também Rails. Seria um ótimo comparativo! Alguém da comunidade se habilita?

Uma das perguntas que mais respondo na minha vida é “Como é que você fala tanto sobre Agilidade e dá cursos de UML?!?!”. Um dos pontos que defendo muito nos meus artigos e também nos meus cursos é que Agilidade não exclui modelagem. De fato vejo muitos agilistas modelando bastante seja nos “whiteboards”, no papel ou em ferramentas UML.

Nosso amigo Adail Retamal postou na lista Agile-Brasil um excelente artigo de Scott W. Ambler e Celso Gonzalez publicado na Better Software. Segue o link:

http://www.nxtbook.com/nxtbooks/sqe/bettersoftware0608/

No artigo citado os autores dizem que a modelagem ocorre principalmente na concepção ágil, no planejamento da iteração e homeopaticamente durante o desenvolvimento. Modelar é uma atividade em grupo focada principalmente na comunicação. Modelar algo sozinho não faz sentido na maioria das vezes.

Será que modelar está tão fora de moda assim? E a UML? O que podemos dizer sobre ela?

Durante um único dia de trabalho de uma equipe ágil temos alguns instantes que fazemos a reunião em pé do XP ou o encontro diário do Scrum. Esta mini-reunião é um ponto de sincronização do status do projeto (é uma inspeção no ciclo da iteração). O Scrum sugere que essa reunião tome o tempo máximo de 15 minutos. Dentro de um dia de trabalho de uma equipe ágil, fora desses poucos minutos preocupados com o gerenciamento a equipe trabalha no sentido de fazer incrementos de software funcionar de maneira “atômica”, isto é, um pequeno requisito é capturado e rapidamente transformado em software funcionando. Isso é o ciclo ágil de um dia. Assunto que tratarei na próxima edição da MundoJava.

Uma caracterísca marcante do ciclo ágil de um dia é que ele é não precisa ser gerenciado no nível macro, isto é, ele não pode ser tomado como base para o andamento do projeto como um todo. Somente com software funcionando e usuários felizes é que você pode dizer que o projeto andou. Este ciclo ocorre de maneira muito rápida e quem gerencia é o próprio desenvolvedor. Essa responsabilidade é uma cultura auto-organizável que faz parte do cerne do gerenciamento ágil. Gerentes de Projeto e Coordenadores não devem interferir no trabalho que é responsabilidade técnica dos desenvolvedores.

Os pontos que defendo aqui são práticas ágeis essencialmente constantes na metodologia XP e no TDD. Infelizmente essas práticas não são adotadas na maioria das equipes que tive contato. Um padrão muito comum nas equipes são práticas fantasiadas de Unified Process (ou RUP) que seguem um formato “Casos de Uso - UML - Codificação - Teste”, seguindo basicamente um processo em cascata numa escala menor. Este modelo dá a entender que requisitos estão em Casos de Uso (geralmente em documentos Word), o projeto ou arquitetura está no modelo UML (uma abstração intermediária), o código simplemente é algo que o computador compreende e, ao final, testes baseados no Caso de Uso são aplicados.

Primeiramente, gostaria de deixar claro que esta pode ser uma maneira de você implementar uma funcionalidade específica de um usuário com certo sucesso, porém, esse tipo de desenvolvimento não deve ser sequêncial e nem mesmo ser um padrão para todas as funcionalidades e nem para todos os projetos. Se a funcionalidade é simples e a expectativa do usuário está clara, documentos de Casos de Uso e modelos UML podem ser descartados. Porém, existem outras maneiras de você alcançar este mesmo objetivo! O próprio RUP não prega este tipo de prática.

Este anti-pattern causa uma cegueira técnica. O fato de sempre ter Casos de Uso, UML, Código e Testes em cascata leva a equipe a acreditar que todos os requisitos estão em casos de uso, temos que modelar tudo e codificar é uma atividade pouco criativa, assim como os testes. Porém, se verificarmos que estatisticamente somente um terço dos requisitos estão em casos de uso [Cockburn], que modelamos somente o que precisa ser modelado [Yoshima] e que todo o processo de desenvolvimento de software é uma atividade criativa (inclusive os testes [Fowler]), vemos que este padrão é muito questionável e muito dispendioso.

Você pode utilizar Casos de Uso para capturar requisitos e utilizar UML para analisar um problema. A culpa não é dessas ferramentas! O maior problema desse padrão é não conversar mais com os usuários depois que o Caso de Uso está escrito, roubando sorrateiramente a comunicação entre a equipe técnica e o cliente durante o desenvolvimento. Refinamentos surgem o tempo todo! A equipe precisa durante o desenvolvimento ligar para o cliente e tirar dúvidas! É comum que durante a codificação novos requisitos não capturados emergam. Requisitos capturados, modelados, codificados e testados podem não ser o que o usuário queria de fato, pois artefatos como Casos de Uso e modelos UML são propensos a muitas imperfeições (são abstrações e não são naturalmente executáveis).

Vejo que o padrão “Caso de Uso - UML - Codificação - Teste” é uma má influência do processo Waterfall, que declaradamente é uma péssima prática para desenvolvimento de software. Esse pensamento seqüencial é ainda mais danoso quando tentamos encaixar este padrão dentro da divisão e especialização de trabalho do Taylorismo, comum em fábricas de software. Nesse cenário, um analista de negócios escreve Casos de Uso, um analista de sistemas desenha o modelo, um programador codifica e um testador testa. Essa equipe muitas vezes utiliza artefatos para se comunicar (e logicamente, cada passo geralmente é controlado por um Gantt Chart). Antes de prosseguir, veja a citação de Kent Beck a respeito do Taylorismo:

“Especialização e rigorosamente dividir e conquistar serviu para produzir mais carros de maneira mais barata. Na minha experiência esses princípios não fazem sentido como estratégia para desenvolvimento de software. Nem para o negócio e nem para o lado humano eles fazem sentido.” Kent Beck

A base da divisão do trabalho é que é possível quebrar um determinado processo em partes menores gerenciáveis, e se cada parte for otimizada, o processo como um todo é otimizado. A especialização diz que determinado recurso efetuando uma tarefa várias vezes torna-se ótimo para esta tarefa. A questão é que para desenvolvimento de software, nem sempre a soma “Casos de Uso + UML + Código + Testes” geram algo do agrado do usuário se ele não estiver envolvido em todo o ciclo. Isso nos mostra que esses passos não são mensuráveis. Além disso, um analista de negócio não se tornará um analista de negócio melhor se ele escrever muitos Casos de Uso, assim como acontece com um Analista de Sistemas ou Programador.

Desenvolvimento de software não é um processo mecânico. Todas as metodologias atuais pregam um trabalho coletivo, em constante comunicação, entrosamento e principalmente uma visão holística sobre o projeto (o todo, e não as partes). Se apegar a rígidos papéis e responsabilidades é péssimo sob qualquer aspecto para uma equipe que desenvolve software.

Na coluna MundoOO da Revista Mundo Java deste mês (número 27) publiquei o artigo “Modelagem Ágil”, onde abordo técnicas efetivas e sem frescuras de modelar um software. Alguns tópicos abordados:

1. As três qualidades do software (qualidade interna, qualidade externa, qualidade do projeto)
2. No desenvolvimento de software não existe separação entre design e construção
3. A comunicação rica do “papel sobre a mesa”
4. Rascunhos, uma forma de modelagem eficaz
5. Aprofundar em detalhes antecipadamente é ruim!
6. Não volte para casa para escrever documentos de requisitos
7. Software funcionando é o melhor artefato para levantamento de requisitos
8. Conceitos sempre provados com código

Separei um trecho para vocês:

“Mas mais importante de tudo é focar nas atividades do desenvolvimento e não nos artefatos criados. Quando você está levantando requisitos, a atividade de conversar com o usuário, obter informações e enriquecer o conhecimento é mais importante que os casos de uso, protótipos, modelos que surgirem dessa atividade. O mesmo vale para uma modelagem de design. O importante é a criatividade para solucionar as dependências dos objetos, a separação dos conceitos, as mensagens trocadas. O modelo de design é só uma manifestação dessas decisões. A tomada dessas decisões é mais importante que a manifestação dessas decisões.”

O que foi mais legal neste artigo foi a participação do Juan Bernabó e José Paulo Papo, demonstrando como eles utilizam as técnicas de Agile Modeling no dia a dia deles.