O fracasso dos processos stage-gate usados nas outras engenharias é hoje óbvio a qualquer um que tenha tido o mínimo de interesses para ler sobre o assunto ou a hombridade para olhar os resultados dos projetos em que participou nestas últimos décadas. O conceito de que projetos grandes e complexos de software podem ser tratados da mesma forma que projetos de engenharia civil ou aeronáutica ainda assombra muitos projetos hoje em dia, mas uma nova geração de desenvolvedores está entendendo que esse não é o caminho da força. O caminho da força é exatamente a disciplina e o rigor mental de um conjunto de pessoas trabalhando para e por um mesmo propósito. Os desenvolvedores finalmente entendem que sem conversar com o cliente nada acontece, ou pior, más coisas acontecem muito freqüentemente.  Conversar é a chave para um bom software.

Mas ainda existem alguns achando que tudo isto é magia e jogo de espelhos e fumaça… Entre estes existem os que enfim são incapazes de raciocinar fora da caixinha onde vivem, mas existem bastantes que ainda pensam assim por falta de lhes ser mostrado um melhor caminho, ou por descrédito de já terem ouvido esta historia antes ou terem experimentado e falhado. Esta atitude é a mesma da pessoa que pensa que se o homem da TV engole facas, ela também pode. E ao tentar, e se cortar toda, acha que o homem da TV é uma fraude, um engano e uma estupidez. O fato é que é a esta pessoa falta a destreza para entender que para chegar naquele nivel é preciso treino, esforço, compreensão dos perigos e sobre tudo : profissionalismo e dedicação.

Como saberão as disciplinas metodológicas com Lean, Kanban, Scrum, XP e outros da linha ágil, propõem o seguimento de um conjunto de práticas. Algumas ainda propoem conjuntos de regras, cerimónias, mecanismo de temporização e papeis que as pessoas devem desempenhar. Isto é o equivalente, nas artes marciais ao ensinamento dos golpes fisicos. Como, onde e quando colocar o braço, as pernas, a cabeça, etc…  como usar a espada, a vara, a faca, etc … Mas os golpes não são a razão da arte marcial, são apenas a parte observável. Aquilo que é a essência das artes marciais está no porquê daqueles movimentos.  Da mesma forma, a essência das disciplinas metodologias está no porquê das mecanicas, regras, papeis e cerimónias. Em ultima análise existe uma filosofia que guia o desenvolvimento e uso destas coisas observáveis.  Se você é um curioso destas coisas, provavelmente já notou que a maior parte das práticas já existia antes da era ágil. O murro também existia antes das artes marciais. Isso não as torna menores. A vantagem não está no murro, mas no como, quando, onde e por quê usá-lo. O mesmo para as práticas.

A existência de uma filosofia que premeira todas as práticas de um disciplina metodológica é a grande diferença para os processos clássicos (eu disse clássicos, não disse tradicionais) baseados no stage-gate como o Unified Process e seus derivados. Estes processos se baseiam em metáforas e analogias entre o mundo do software e outros mundos, especialmente os das engenharias civil e aeronáutica. Repare que não há uma filosofia ou disciplina inerente a estas engenharias. Basicamente existe uma matemática e uma ordem de dependência e precedência entras atividades. Nada mais. O fato de que a casa se constrói de baixo para cima,  é porque simplesmente as fundações são feitas no chão, não no ar. E todo o resto vai em cima disso. É simples. É sempre assim, e é simplesmente óbvio. Não há uma disciplina envolvida, porque simplesmente não ha escolhas a serem feitas.

As disciplinas metodológicas foram criadas a partir do conceito de que construir software  é uma atividade complexa. Mais complexa que engenharia civil e aeronautica e que por isso, é necessário que siga outro tipo de princípios e regras. Mas quais regras ? Ninguém sabe. Esta que é a mudança de paradigma que é dificil explicar e demonstrar para alguém que não entende que estamos falando de disciplinas e não de um bando de regras. Isto não é um jogo onde cada um aplica as regras que mais gosta. Tente fazer isso com uma arte marcial e sairá machucado.  Ninguém são, é louco, para fazer isso. Então, porque as pessoas insistem em pensar que podemos escolher um conjunto de mecanismos, ou regras, ou cerimônias das disciplinas ágeis e simplesmente criar nosso próprio processo.  Atente, com atenção, às palavras da ultima frase. As pessoas querem escolher regras para criar seu próprio processo. É só isso que um processo é: um conjunto de regras. E quem pensa assim ainda não entendeu que os processos não funcionam. Não no mundo da construção de software.  O Mundo está indo para as disciplinas metodologicas e deixando para trás o conceito de processo de produção, mas estas pessoas insistem em querer criar um processo usando as “melhores regras” que estas metodologias usam. É como querer criar uma arte marcial usando os melhores golpes das artes marciais. É possível ? É. Mas um conjunto de golpes é uma arte marcial ? Não. É apenas marcial, não uma arte. Falta personalidade, falta alma, moral, disciplina.  Falta o por quê, a razão. E principalmente falta o Objetivo.

Porque não podemos usar um quadro kanban junto com um daily meating e não usar Scrum  ? Porque não funciona. Não está a disciplina. O daily meating é vazio sem a responsabilidade partilhada que o Scrum procura. Não ha razão para conversar, em conjunto, sobre as atividades de todos, se não ha unidade.  Porque não podemos usar planning poker num projeto waterfall ? Porque o planning poker não é um jogo de numeros, é um processo de aprendizando, dialogo e acordo. Este processo visa criar a unidade em vez da impor. Visa procurar a visão do projeto como um todo e um acordo de como o executar. A disciplina está em chegar nessa unidade através da prática, da mesma forma que a arte marcial procura a clareza da mente através do movimento físico.  Para muitos um sprint é uma unidade de tempo. Ela é uma unidade de tempo, também, mas é principalmente uma unidade de foco. É um tempo onde o desenvolvedor pode desenvolver o que estava acordado, sem interrupções ou alterações do acordo. É um período importante para criar e fortalecer a responsabilidade do desenvolvedor e o respeito dos outros para com ele. Num processo tradicional pede-se que o desenvolvedor faça algo, mas nunca se respeita o pedido inicial ou o tempo que o desenvolvedor tem que ter de paz, para realmente desenvolver. Então do que serve ter um cronometro ? Só para apressar ? ( a tradução de sprint poderia ser “apressar até à meta”).  Não. “Estamos nos sprint” é a forma educada de dizer “Estamos trabalhando. Deixe-me em paz!” Mover papeizinhos num quadro branco não é kanban, nem scrum. É apenas um quadro branco com papeis em diferentes posições. Significam algo? Claro que sim. Significam o que você quiser. As cartas do tarot também significam algo quando estão em certas posições da mesa , mas e daí ? Isso basta ? Não.  O quadro branco com os papeis não é para dar visibilidade. É para dar visibilidade, também, mas principalmente é para encontrar problemas e com isso melhorar o processo. Ah! melhorar o processo.. então o processo não é fixo ? Não. O processo não é fixo. As práticas não são fixas, as regras não são fixas, a filosofia é que é. A disciplina, os objetivos. Não o caminho. O que as disciplinas metodológicas nos dão é uma filosofia e um conjunto de regras iniciais do processo, e um mecanismo para melhorar esse processo continuamente, dependendo dos intrevenientes! É um processo adaptativo por natureza.  As regras inicias são iguais para todos, mas onde cada um vai chegar é totalmente obra de melhoria continua. Exatamente como um praticante de uma arte marcial.

Então por quê não podemos simplesmente pegar uma coleção de práticas, colocá-las no mesmo saco, baralhar, e cria nosso próprio processo ? Porque estaremos apenas criando um processo, não uma filosofia. Não uma disciplina.  Uma disciplina implica que haja coerência entre as práticas, que elas se complementem e fortaleçam umas às outras e para isso é preciso um conjunto de principio maiores que as práticas em si mesmas, e isso só podemos alcançar através de uma disciplina completa.

Finalmente, queria deixar uma palavra para quem acha que pode começar a usar uma disciplina metodologia, como Scrum, ou XP, por exemplo, sem se comprometer com ela. Sem se empenhar, e sem a seguir completamente. Se você é um dos que pensa que pode começar a usar estas disciplinas “por partes”, pense no desastre que seria tentar partir um bloco de cimento com os dedos sem o devido preparo físico e mental da disciplina marcial completa. Muitos podem emitar os movimentos que veêm um mestre de artes marciais executar, mas imitar os movimentos não é praticar a arte. A arte está em entender os movimentos. Da mesma forma, a boa forma de base software está em entender os principios por detrás das disciplinas metodologia e não em imitar os movimentos das suas práticas. Ninguém aprende a partir uma pedra com as mãos por tentativa e erro. É feito com treino. E treino é algo diferente de tentativa e erro.

Para entender as disciplinas é requerido estudo. E sem estudo, tentar praticar é um insulto. É como um cara que aprendeu a imitar meia-dúzia de golpes dos filmes querer se denominar mestre de artes marciais. Não é apenas um insulto aos verdadeiros praticantes da arte, mas ao Mundo, por querer que acreditemos nesse embuste.

Se você gosta das disciplinas metodológias modernas, se realmente vê vantagens nelas, e sente que ha algum mérito nelas, antes de mais as estude. Tente entender a filosofia primeiro, para depois começar a exercitar as práticas.

O primeiro erro é confundir objeto com estrutura de dados. Em algumas linguagens não orientadas a objetos é possivel trabalhar com tipos que compoem diferentes variáveis numa variável só agrupando dados de forma mais concisa. Estas estuturas auxiliam na passagem de parametros, e até na tipagem do programa, mas  não são objetos.Contudo, é comum não conseguir diferenciá-los porque ambos têm atributos.

Objectos não são apenas formados por atributos, eles são também formados por comportamento. Este comportamento pode, ou não, depender do valor dos atributos ou operar sobre eles. Claro que é possivel também conceber objetos que apenas detêm comportamento sem nenhum atributo ou propriedade. Mas não é isto que diferencia uma estrutura de dados de um objeto.

Um objeto se diferencia de uma estrutura de dados porque têm uma responsabilidade. A responsabilidade advém do papel que o objeto representa no sistema, e esse papel advém do significado que o objeto têm no sistema. A responsabilidade do objeto leva a uma classificação do objeto por papeis no sistema e a existência de vários objetos que se auxiliam para formar o sistema induz a uma classificação hierarquizada. Portanto, uma outra forma de dizer que objetos têm responsabilidade é dizer que objetos pertencem a uma hierarquia de classificações.A existencia de hierarquia de classificação está intimiamente ligada à operação de herança ( que seria impossivel existir sem dita hierarquia).  Estruturas de dados, não pertencem a uma hierarquia, e  portanto, embora fisicamente semelhantes, estruturas de dados não são objetos.

Mas podem objetos ser estruturas de dados ? A resposta rápida é : sim. A resposta longa é : podem, mas apenas se essa for a sua responsabilidade.

Objetos não se podem eximir de possuir responsabilidade e é um desafio manter apenas uma responsabilidade por objeto. Mesmo quando o desenvolvedor é inexperiente todo o objeto usado ganha uma responsabilidade no sistema mesmo quando o desenvolvedor não é consciente disso e atribuir a responsabilidade correta é que é o real desafio da programação orientada a objetos.

A programação orientada a objetos advém dos principios de modelagem orientada a objetos que é uma atividade abstrata em si mesmo e independente de qualquer tecnologia ou linguagem de programação.  Modelar o objeto corretamente passa por definir seus atributos e métodos, mas principalmente por definir sua responsabilidade.

Se um objeto pode ser uma estrutura de dados, isso significaria que a responsabilidade  do objeto é manter referencia a dados.  Isso nos leva a duas prespetivas. A primeira é a do objeto que é apenas um cabide de dados e permite transportar os dados de forma agrupada de um ponto do sistema para o outro, sendo o objeto totalmente neutro em relação à razão dos dados estarem agrupados daquela forma e terem aqueles valores. Esta seria a melhor aproximação a uma estrutura de dados convencional, não orientada a objetos. Por outro lado, podemos pensar no objeto que atua como protetor dos dados que guarda, mantendo coerencia nos valores e com pelo conhecimento de porquê aqueles dados estão agrupados.O primeiros são meros objetos de transporte (Transport Objects, TO) e os segundos são objetos de valor (Value Objects, VO). É clara a diferença entre estes dois tipos.  Poderiamos argumentar que o objeto de valor que agrupa os valores por uma razão e com conhecimento dessa razão, acaba servindo, também, para transportar esses dados de um ponto do sistema para outro. Aqui jaz a diferenciação:  os dados que o TO transporta podem ser utilizados em diferentes pontos do sistema, como o sistema bem entender. Todos os dados são publicos e a sua manipulação é livre. Os dados que o VO contém não podem ser utilizados desassociadamente ou condicionalmente conforme os interesses do sistema. O sistema está obrigado a seguir as regras que o próprio VO impõe.

Em modelagem orientada a objetos aprendemos que os conceitos do mundo real devem ser incorporados no sistema de uma forma que a cooperação lógica entre os objetos seja equivalente à cooperação dos conceitos ( ou dos objetos reais traduzidos por eles) no mundo real. É por isto que modelamos classes Cliente, Pedido e Produto e as identificamos com os conceitos de mesmo nome no mundo real  e ao dizermos que “O cliente faz um pedido composto de produtos” não existe diferença se essas palavras se referem a objetos no sistema ou às entidades no mundo real.  Para que este mecanismo funcione, é claro que precisamos conseguir converter os conceitos reais em objetos. A este processo que usamos para criar equivalencia entre objetos e conceitos reais dá-se o nome de: Abstração.

A abstração dos conceitos reais é a fonte da origem dos objetos. Abstração não significa neste contexto fazer as coisas mais dificeis, mais universais ou mais matemáticas, mas apenas e só significa mapear os conceitos reais com os objetos que temos no modelo/sistema. Na realidade não é correto dizer que o mapeamento é entre os objetos e os conceitos, e sim que é entre os conceitos e as classes de objetos do modelo/sistema. O nome “classe” não é aleatório. Nos remete ao conceito de que todos os objetos pertecem a uma hierarquia de classificação, e portanto pertencem a uma ou a mais categorias (classes).  Portanto, modelar de forma orientada a objetos é a realidade nada mais que criar uma (grande) arvore de categorias, ou melhor, de classes.

As classes de objetos que identificamos com conceitos do mundo real podem pertencer a 3 grandes classes de objetos : Entidades, Serviços e Valores. As classes de serviços são caracterizadas por não deter atributos ou propriedades. Todos os dados necessários à sua operação vêm do seu exterior. Entidades são caracterizadas como objetos de transporte(TO) de Valores para certas propriedades espeficicas que são,também,  mapeadas do mundo real. Por exemplo, o cliente terá uma propriedade nome cujo valor será um conjunto de caracteres que, numa certa lingua, compoem o nome do cliente. Entidades podem também ter métodos que trabalham sobre as suas propriedades e/ou cujo resultado é alterado pelos valores dessas propriedades.   Valores são objetos de valor (VO) que detém a informação sobre os valores , passo o plenoasmo, das caracteristicas das propriedades.

Existe atualmente uma confusão sobre o conceito de objeto como composição de dados e comportamento na forma de que certas pessoas confundem o fato dos objetos poderem ter dados e comportamento, com a obrigatoriedade de todos os objetos deverem ter dados e comportamento.  Isto é pura e simples sandice. O que o objeto tem que respeitar é a responsabilidade ( ou responsabilidades) inerentes à(s) classe(s) a que pertence. Por este motivo, objetos da classe de serviço não detém atributos e isso é perfeitamente normal.

No mundo real, os conceitos são muito mais maleáveis que no mundo do software. Nem sempre é trivial destinguir entre o que é um objeto da classe de entidade, e o que é um objeto da classe de valores. Os exemplos classicos são o número de telefone e o endereço. Para um sistema comercial de compras e vendas o numero de telefone ou o endereço não passa de um valor de uma propriedade de alguma entidade como casa, pessoa ou cliente. Mas para o sistema dos correios o endereço é uma entidade ela mesma com propriedades e relacionamentos com outras entidades num vasto sistema de classificação completamente diferente daquele do sistema comercial. O mesmo poderiamos dizer do numero de telefone e da companhia de telefones. Portanto, se o conceito é melhor modelado como um objeto da classe de entidades ou da classe de valores não é constante entre sistemas de tipos diferentes.

Tipos Primários

Todas as linguagens orientadas a objetos oferecem em maior ou menor numero um conjunto de objetos de valor pré-prontos que podem ser usados como objetos da classes de Valores facilmente em qualquer entidade ou sistema. Estes objetos nunca serão usados como sendo da classe de entidade ou serviço, e portanto é seguro para a linguagem/plataforma de programação assumir algumas caracteristicas para estes objetos e de certa forma prover otimizações para eles. Em java estes tipos primários (não confundir com os tipos primitivos do java) são representados, por exemplo, pelas classes: String, Date, Boolean, Integer, Double e BigDecimal.

Porque estes tipos  estão sempre disponiveis e são conhecidos de todos os desenvolvedores, é comum que eles sejam usados para os valores das propriedades de objetos de transporte e/ou de valor.  O problema aqui é que quando queremos modelar o numero de telefone, por exemplo, como sendo um objeto pertencente na classe de objetos de valor, decidimos escolher um dos tipos primários em vez de criar um novo tipo ( classe) para ele. Então em vez da propriedade “telefone” do cliente ser um objeto do tipo “NumeroTelefone” é apenas um objeto String ou  Integer.   O problema com esta abordagem é a falha do processo de abstração. O erro é tão grande e grosseiro como se a pessoa aceitasse modelar o numero de telefone usando um Double( afinal todos os Integer cabem num Double e o Double permite ter uma parte decimal que poderia ser usada para o ramal … não tente isto em casa).

Para a grande maioria dos desenvolvedores parece um preço muito elevado criar uma classe com uma duzia de linhas para representar um conceito de valor. O argumento é que isso aumentaria o numero de classes no projeto, como se existisse alguma regra dizendo que o numero de classes deve ser abaixo de algum numero mágico. Não entendo isto. Realmente não consigo entender como uma desculpa destas que advem de pura preguiça pode triunfar sobre um raciocinio lógico, cientifico, e comprovado da modelagem orientada a objetos. O que a modelagem orientada a objetos sugere é que o numero de abstrações seja o minimo possivel. Sendo que as palavras chave aqui são “possivel” e “abstração”.  É o numero de mapeamentos entre o mundo real e mundo dos objetos que tem que ser minimizado. Isto porque esses mapeamentos são complexos e frageis  ( como o exemplo do endereço e telefone demonstram)  e portanto, ter mapeamentos demais apenas aumenta a complexidade e risco do modelo estar furando em algum ponto.  Porque as pessoas pessoas entender “abstração==classe” então acham que minimizar o numero de classes estão respeitando este principio.  O problema é que o principio da separação de responsabilidade é mais importante do que a sugestão que comanda o numero de abstrações.  Ou seja, quando a pessoa mapeia o numero de telefone à classe NumeroTelefone está separando a responsabilidade de descrever um numero de telefone. Usar um objeto String, poupa uma classe, mas coloca sobre a classe String a responsabilidade de além de descrever texto, também descrever numeros de telefone. E convenhamos que isto é um pouco idiota, pois se eu quiser ter um método getRamal() no numero de telefone, isto seria trivial num objeto NumeroTelefone , mas impossivel num objeto String já que ele não é extensivel. Mas mesmo que String fosse extensivel, não o poderiamos extender e criar o nosso StringTelefone pois isso significaria aumentar uma classe no nosso projeto e seria vetado pelas mesma razão (idiota) que veta a criação de NumeroTelefone em primeiro lugar.

É importante seguir principios , sugestões e boas práticas.Eu acredito muito nisto. Mas veja, existe uma ordem em que estas coisas têm que ser seguidas e  existem prioridades. O principio de separação de responsabilidade tem prioridade sobre todos  as sugestões e boas práticas que alguem imaginar.

Isto nos leva ao conceito de que, embora aos olhos destreinados pareça pequeno o ganho de criar um novo tipo (classe)  fazer isso é a única saida lógica num caso assim. Estes “pequenos  tipos” ganharam um nome – Tiny Types – exactamente para deixar clara a sua importância.  Mas entenda que a necessidade de batizar estes tipos de objetos apenas advém do desconhecimento e incompetência tecnica da maioria dos desenvolvedores que não sabe seguir os principios mais básicos da orientação a objetos. Eles esquecem que todos os conceitos reais presentes no sistema precisam ser abstraidos e que violar isto é criar buracos no modelo e por consequencia no código e no sistema.

Existem outras formas de dizer a mesma coisa e revelar a mesma importância da operação de abstração para a correta modelagem orientada a objetos.   Uma que ganhou muita fama ultimamente é chamada de “Linguagem Ubiqua” (Ubiquos  Languagem) introduzida pelo pessoal adepto da filosfia Domain Driven Development (também chamada Domain Driven Design). O conceito aqui é que os mesmos termos (conceitos) que as pessoas usam no mundo real  para se referirem aos intrevenientes no processo do mundo real que o software irá mimetizar devem ser usados no codigo. Isto é exactamente o mesmo que dizer que os conceitos devem ser abstraidos.  A diferença é que dizer “os conceitos devem ser abstraidos” é uma expressão tecnica, enquanto “os mesmos termos que as pessoas usam no mundo real  para se referirem aos intrevenientes no processo do mundo real que o software” é uma expressão usada por pessoas comuns  não-tecnicos. As pessoas que estudaram orientação a objetos e conhecem a operação de abstração e não a confundem com “tornar as coisas mais complexas” sempre souberam que é excelente ideia colocar os nomes/termos/conceitos reais no código … afinal foi por causa disso que se inventou o próprio conceito de Objeto e o paradigma de Orientação a Objetos : porque queriamos que os programas tivessesm a mesma expressividade que o mundo real. É simples desconhecimento achar que isto é algo novo, e é simples maldade se aproveitar do desconhecimento da maioria dos desenvolvedores – que teve uma fraca preparação académica – para passar a “linguagem ubiqua” como algo novo e inovador.  No fundo não passa de uma ferramenta de marketing igual ao dos Tiny  Types para fazer as pessoas aceitarem o que elas deveriam ter aprendido na escola desde o começo : abstração.

Toda e qualquer impedimento em orientação a objetos, seja modelagem, seja implementação, advém do conceito de objeto ( redundante, mas importante ter sempre isto presente). O conceito de objeto significa entender que existe uma separação de responsabilidade e que isso que define “objeto” e o destingue de “estrutura de dados”. Simultaneamente essa responsabilidade classifica o objeto em uma hierarquia e a hierarquia de responsabilidades implica em sermos capazes de classificar em qual lugar dessa hierarquia o objeto pertence. A  operação que usamos para fazer isto é a : Abstração.

A correta abstração do problema que o sistema deve resolver leva à correta hierarquia  de objetos para aquele sistema e nem sempre essa hierarquia é a mesma para sistemas diferentes. Nem sempre é claro se o conceito será mapeado como um objeto de entidade, serviço, ou um valor, um objeto de transporte ou um objeto de valor. Contudo, independentemente da classificação é mandatório que o conceito seja mapeado para um tipo, uma classe e esse é a razão por detrás dos conceitos de Tiny Type e da Linguagem Ubiqua.

O principio de separação de responsabilidade ( um dos 5 principios da orientação a objetos) tem prioridade sobre a sugestão de manter um conjunto minimo de abstrações, e por consequencia de classes e em nenhum caso o aumento do numero de classes pode ser usado como desculpa para não respeitar o principio de separação de responsabilidade.

Modele corretamente o seu sistema. Aprenda Orientação a Objetos e poderá fazer seus sistemas tranquilamente sem precisar de muletas. Não tenha medo de criar classes. Tenha apenas medo delas não representarem nada de util ou real no processo que o seu software está tentando desempenhar. Se todos seguirmos isto teremos menos buzz words para nos preocupar e poderemos tornar nossa atenção para o que realmente interessa.

O desenvolvimento de software teve a sua pré-historia quando software e harware era virtualmente indestinguiveis mas ao mesmo tempo que se criou um mercado de software distinto do de hardware, se criou a idade média do desenvolvimento.

O software clássico, ou seja, aquele que nasceu pela diferenciação entre hardware e software nasceu das mãos de engenheiros electro-electrônicos . O software contemporâneo não mais requer o mesmo leque de capacidades. Porque o software nasceu de dentro da engenharia eltro-eletrônica a forma de fazer software nasceu com a mesma metáfora da forma de fazer hardware. Um processo chamado stage-gate de que falei no post passado, mais conhecido como waterfall.  Isso faz sentido para obras de engenharia, mas o que demorámos 50 anos a perceber, é que não faz sentido para software.

Tudo o que existe, muda

O paradigma do desenvolvimento de software está, em si mesmo, evoluindo. É um alvo em movimento. Mas antevemos hoje algumas propriedades que o desenvolvimento de software tem, que mais nenhum ramo de atividade tem, e são esas propriedades que moldam um novo paradigma de desenvolvimento.  Uma destas propriedades é :

Todo o software é baseado em requisitos não estáveis.

Esta verdade universal é o grande diferencial de um artefacto de qualquer engenharia onde os requisitos são estáveis. Muitos autores já escreveram sobre este problema. Muitos já apontaram a instabilidade dos requisitos como o grande problema do desenvolvimento de software. Nada de novo ai. Qualquer um com mais de três projetos nas costas já sabe que isto é simplesmente verdade. Isto nos leva a duas escolas de pensamento:

Escola Tradicional

Para a escola tradicional, esta fato é um problema, e a forma de resolver este problema é com uma forte pressão para evitar a mudança. Esta escola de pensamento defende que a forma de lutar contra a constante mudança de requistos é proibi-la ou torná-la tão onorosa que ninguem quer realmente fazê-la. Esta escola parte do principio errado que a instabilidade acontece por responsabilidades de agentes externos  ao processo de desenvolvimento de software ( seja ele qual for) e que tal mudança não é inerente ao software em si.

Este pensamento é muito fundamentado no pensamento da engenharia de hardware e em logica determinista em que se julga ser possivel conhecer todas as variáveis e sua evolução.

A escola Tradicional faz uso de três ferramentas principais : o levantamento exaustivo de requisitos, o plano e o mecanismo de pedido de alteração (change request). Estes três mecanismos visam, no entender desta escola, esgotar as opções de possibilidade de mudança , primeiro : garantindo que todas as opções foram pensadas e analizadas com antecedencia e as melhores foram escolhidas;  segundo, documentando tudo isso, e qual o caminho a seguir : o plano;  e , terceiro : se por uma bizzarra eventualidade for possivel que algo tenha escapado e seja necessário alterar algum ponto do plano, isso tem que ser feito com todo o cuidado e controle possivel pois pode ter reprecursões e interações com os outros requisitos não previstas com antecedência.

Escola Moderna

Para a escola moderna o fato dos requitos serem instáveis é simplesmente uma caracteristica da natureza das coisas e em particular do software. Portanto ha que aceitar essa mudança com um fato e construir mecanismos, processos e ferramentas em torno dessa realidade. Porque este fato não é um problema criado por agentes externos não é concebivel criar mecanismos para o evitar, e sim, muito mais apropriado criar mecanismos para acompanhar essa mudança.

Este pensamento é baseado na filosofia clássica grega e oriental de que a única constante do universo é a mudança.

Porque esta forma de pensar implica em constantemente estarmos acompanhando a mudança, e portanto mudando a todo o momento, ela ganhou o nome de “Ágil”. Mas o nome “Ágil” não veio daqui, veio do manifesto ágil. Foi um “batismo por proximidade” , por assim dizer.

Software é um produto da mente, não da mão

Uma outra caracteristica que está sendo sendo cada dia mais visivel é que:

Software é um artefacto criado por pessoas.

Escola Tradicional

Para a escola tradicional isto significa apenas uma simples coisa : outros animais não podem fazer software, apenas o ser humano. Logo, para fazer software temos que ter o custo de contratar pessoas. Se quisermos que seja feito mais depressa, contratamos mais pessoas. Se queremos que seja feito melhor, contratamos melhores pessoas. Os tradicionalistas se referem a isto como “braço” , significando que “mais braços, mais mãos. Mais mãos, mas rápidamente se digitam coisas no teclado, logo mais depressa o codigo é escrito e portanto mais depressa o software é completado”. Simples.

Porque os requisitos não mudarão nunca ( salvo exceções devidamente contidas nos pedidos de alteração) e o plano traça o unico caminho possivel, então, seguir o caminho não é uma questão de escolha, de livre arbitrio, de experiencia, é apenas uma questão de correr mais depressa. Logo, o prazo para criar um software pode ser facilmente modificando alterando o numero de pessoas disponiveis para o escrever.

Escola Moderna

A escolha entende este fato como significando que software não poderia ser criado por acaso pela natureza, ou pelo simples esforço fisico,  mecânico , muscular ou repetitivo. Criar software é um trabalho intelectual e não muscular. Demanda criatividade, conhecimento, raciocinio e destreza mental. Portanto para fazer mais depressa precisamos de pessoas mais critivas, com mais conhecimento , com melhor raciociono ou mais destreza mental.

Porque os requisitos mudam, é necessário constantemente exercitar as celulas cinzentas para obter novas ideias que permitam alterar o software existente para cumprir as novas funcionalidades da forma mais vantajosa possivel ( leia-se “a que custa menos dinheiro”). Porque software é feito por pessoas e elas usam ideias para o criar, a comunicação dessas ideias é vital para o seu refinamento e evolução. Portanto a comunicação é vital.  É sabido que o numero de canais de comunicação aumenta na proporção do quadrado de pessoas habeis a comunica. Para ser mais exato o numero de canais é igual a p(p-1)/2 onde p é numero de pessoas. Portanto para 3 pessoas temos 3 canais para 4 temos 6 canais ( o dobro para o aumento de uma unica pessoa), para 6 pessoas temos 15 canais ( o quintopluo para o aumento de 3 pessoas). É facil de ver que quanto mais pessoas, mais dificil a comunicação e mais dificil a evolução das ideias. Portanto, o conceito da escola moderna é ter o menor numero possivel das pessoas mais capazes possivel – a equipa – e ter várias equipas. Esta simples fato é sabido desde dos anos 60 pelo lengendário livro “The mythical man month”, mas historicamente as pessoas se negam a enxergar isto, ou são oblivias a este conhecimento.

Entra a escola Ágil

Preciso esclarece que a escola ágil é apenas uma das linhas possiveis de uma escola moderna. Não é a única. Díficil de dizer que é a melhor.

A escola ágil parte dos principios do desenvolvimento de sofware visto atrás e estabelece um objetivo comercial. É importante sublinhar bem que se trata de um objetivo comercial e nada além disso. Não ha aqui nenhum tipo de valor moral maior ou grandiosidade Humana. É apenas uma questão de balanço comercial. O objetivo é simples:

Prover valor ao cliente.

O “Cliente” aqui é a pessoa que detém o poder de decidir pelo pagamento, ou não, do software. Não necessáriamente é a pessoa que o vai usar e não necessáriamente é a pessoa que realmente via pagar por ele. Por exemplo, o filho de um casal quer um novo jogo de computador ( que é um software), quem paga é o pai , mas quem permite ou não que a compra seja feita é a mãe. Neste caso, o “cliente” é a mãe. Portanto o software tem que ter caracteristicas que agradem ao filho (para que o queira usar), mas principalmente à mãe, porque será ela a realmente levar à compra. É por isto que os jogos tem um selo dizendo o nivel etário aconselhado e o tipo de contéudo presente. Esta classificação (rating) não é para o bem da humanidade ou para proteger valores da sociedade, é apenas e só, para que o produto “jogo” seja mais aceitável por quem o compra de verdade ( no caso, as mães). Não se entenda deste exemplo, se são sempre as mães. O que se precisa entender daqui é que existe papeis diferentes do ponto de vista do uso e da compra do software. O software tem que ser agradável a quem o usa (ou será rejeitado), a quem o paga ( o custo-beneficio tem que agradar ao “dono do dinheiro” também ) mas principalemente ele tem que agradar a quem tem a autoridade de negar a compra : o cliente.

O manifesto ágil nasce daqui. Da necessidade de prover valor ao cliente. “Valor” é : “o que quer que seja que o cliente usa para dedicir se compra ou se bloqueia a compra”.

Analizemos o manifesto à luz destas informações :

(1) Individuos e Interações em vez de processos e ferramentas.

A ideia do manifesto é contrapor a escola tradicional exemplificada aqui por “processos e ferramentas” à escola moderna, da qual a escola ágil faz parte. Este item resalta a importancia das pessoas em detrimento das mecânicas. Contudo passa a ideia que não precisamos de processos ou de ferramentas, o que não é verdade ( Alguem não usa uma IDE ? Claro, mas ninguem acha esses caras normais, i.e. nos 90% da curva). O ponto aqui é realmente que software é feito por pessoas, não por mecanismos.

(2) Software funcionando em vez de documentação extensiva.

Mais uma vez, a ideia da escola moderna que o objetivo é o software, não o plano. Claro que a expressão “software funcionando” é até tautologica (de que server um software não funcionando ? E um “não funcionando” pode ser considerado um software?) mas é apenas para reforçar que o objetivo de construir um software é ter um software.  Não um conjutno de documentos que não “funcionan”, ou seja, o plano não vai resolver o problema do cliente, apenas o software – funcionando – vai.

(3) Responder à mudança em vez de seguir um plano.

Aqui, de novo, a ideia de que a mudança é inivitável e que, portanto não ha valor em seguir um plano. Esta frase da a ideia de que não devemos fazer planos, o que é falso. A palavra “plano” está implicitamente atrelada ao contexto da escola tradicional em que apenas depois do plano pronto, poderiamos começar a criar o software. A ideia não é essa. A ideia é que o conjunto de requistos é um alvo, mas um alvo em movimento. Portanto a estratégia tem que estar em conformidade.  Tem que haver um plano no sentido de “tem que existir uma estratégia” – seria suicidio comercial não ter uma – mas não precisamos de um “plano” no sentido de “um mapa feito à priori que nos mostre por onde ir”

(4) Colaboração com o cliente em vez de negociação contratual

Este ultimo item ( o terceiro na lista original) deixa bem claro ao que veio a escola ágil : agradar ao cliente. O objetivo sempre será agradar ao cliente. A contraposição aqui diz respeito a ter uma lista de requisitos fechada e pedidos de alteração versus ter uma lista alterável (dinâmica) que muda conforma o “querer” do cliente. “Negociação contratual” faz alusão Às clausulas restritivas que existem nos contratos tradicionais que proibem o cliente de fazer modificações ou o oneram por isso. É um sistema de castigo contrário ao conceito de que a mudança irá sempre acontecer, então ao colocar essas clusulas a empresa está automaticamente castigando o cliente. É apenas uma quetão de tempo para acontecer, e não uma questão de se vai acontecer ou não.

Ao ler o manifesto é preciso entender que a segunda parte da frase sempre se refere ao contexto da escola tradicional. Este ultimo item não significa que não devemos fazer contratos com o cliente – é obvio que devemos – o que está sendo dito é que esses contratos não têm que ser baseados em mecanismos de castigo e recompessa e sim em mecanismos de colaboração.

A escola ágil visa maximizar o negócio que o desenvolvimento de sfotware é ao mesmo tempo que se segue o pensamento da escola moderna. Mas a escola ágil não é a única vertente moderna. Do outro lado temos a escola artesã.

Entra a Escola Artesã

É realmente dificil arranjar um bom nome para esta vertente moderna. O conceito aqui é que, dado que os principios da escola moderna são verdadeiros, não ha que esquecer de lembrar que são pessoas que constroem o software, e num ambiente de negocios, essas pessoas têm que ser Profissionais ( com P maiusculo). Estes profissionais são chamados carinhosamente de artesãos. Isto não é para dizer que a criação de software é rude e crua, mas sim para lembrar que a criação de software é baseada nas capacidades critivas de pessoas ( como uma arte, e dai o artesão) e não na força bruta ou na repetitividade de uma máquina.

O manifesto do artesanato de software ( software craftsmanship) é mais do que um compromisso com o cliente, é um compromisso de cada um de nós com o profissional que ha em nós e ha em todos os colegas de profissão. É um compromisso de qualidade, esmero, requinte e escolha do que é certo do ponto de vista da profissão e não apenas do que é certo do ponto de vista do cliente.  Então, a escola artesão evolui o manifesto ágil para um manifesto onde a qualidade é tão importante quanto o resultado.

(1) Não apenas software funcionando, mas também software bem confecionado.

A discussão é agora o que seria entendivel por “bem” e “mal” confecionado, mas em geral o que está sendo colocado aqui é : nada de gambiarra, seguir padrões ( não apenas design patterns, mas padrões de nomenclatura, de arranjo de codigo,  de trabalho, etc…) e acima de tudo respeito pelo profisional que irá dar manutenção no software depois de um tempo( que podemos ser nós mesmos, é bem comum este caso).

(2) Não apenas responder à mudança, mas também constantemente agregar valor.

E não apenas o valor que o cliente espera, mas o valor que os outros profissionais esperam. Se um produto é louvado por todos os profissionais do ramo, é bem provável que o seja pelos clientes também.

(3) Não apenas colaboção com o cliente, mas também parceria.

Parceria é diferente de colaboração. Parceria advém dos dois entenderem que estão no mesmo barco e não que um trabalha para o outro. Sim, no contrato está escrito que um é o “Contratado” e outro é o “Contratante”, mas isso são apenas termos legais. Na realidade são pessoas com um objetivo comun: criar um software.

(4) Não apenas individuos e interações, mas também uma comunidade de profissionais

Este é talvez o mais importante item que marca a diferença entre as escolas. A escola ágil aceita e entende que as pessoas são importantes e que elas devem comunicar pois isso é o motor da critiavidade necessária ao construir um software, mas é cega à qualidade inerente dessas pessoas. Em tese qualquer pessoa poderia pertencer a uma equipa da escola ágil, numa equipa artesã isso não é suficiente, é preciso que as pessoas sejam profissionais, ou pelo menos, que aspirem a o ser. Mas a “comunidade” não se esgota na equipe. Ela traspassa barreiras de equipe, empresa, e até de país e lingua. É a procupação dos desenvolvedores se ajudarem entre si, mesmo que competindo pelos mesmos clientes, ter o respeito e o fair-play necessários entre si, fora com constrangimento do mundo dos negocios.

Infelizmente, falar de profissionalismo na construção de software ainda parece uma aberração hoje em dia. Não será por muito mais tempo, porque a cada dia que passa ser rápido não é mais sufciente, tem que ser bom e rápido.  Quem aprender esta lição antes e a executar melhor, leva o cliente. Tão simples assim.

O manifesto ágil tem como pretensão escapar da máquina monstruosa e pesada com que o software era feito nos moldes tradicionais e o seu enfoque é priorizar o cliente tendo como base as propriedades canónicas do desenvolvimento de software. A preocupação era abandonar o modelo velho.

O manifesto do artesanato de software pretende chamar a atenção que quebrar o modelo tradicional não é suficiente, que seguir o modelo ágil de foco no cliente não é suficiente a longo prazo e que é necessário nos preocuparmos com a Qualidade e  a correta confeção dos software, não porque o cliente vai achar isso lindo, mas porque é uma questão de dignidade , honra e orgulho profissional. Você pode entregar o software mais util do mundo, mas se as entranhas dele forem reles, você assumiria a autoria ?

A escola ágil critica a escola tradicional porque não enxerga as propriedades do desenvolvimento do software , não enxerga os fatos e a história, mas é ingénua aos olhos da escola de artesã ou esquecer ao que viemos. Viemos para constuir software e não para chafurdar nos bits e bytes e concordar com todas a sandices que nos pedirem. Temos um dever para com o proprio software tanto quanto temos para com o cliente e abdicar disso, no entender da escola artesã é uma irresponsabilidade.

Eu me encontro no grupo de pessoas que defendem o manifesto de artesanato de software. Agil para mim não é suficiente. É necessário, mas não é suficiente. Existe esse passo a mais a se dar. Existe a necessidade de formar profissionais ( ou seja, pessoas com honra e principios de profissão) e não apenas pessoas que conhecem a parte tecnica. O que vivemos hoje é como termos uma praça de taxis onde todos os taxistas são falsos e apenas dois ou três têm a autorização de ser taxistas. Não precisamos de condutores de fim de semana que saber conduzir uma IDE ( mal, mas sem acidentes graves) , precisamos de pessoas que saibam entender software e preservar a sua consistencia ao mesmo tempo que preservam o valor para o cliente. Não é uma questão de um ou o outro, é uma questão de que um sem o outro não interessa. Pelo menos não interessa a um Profissional de verdade.

Eu sei que o manifesto ágil, e o conceito de agilidade ainda são novos para muitos. Também sei que nas escolas oficiais a imagem que se dá do software é o da escola tradicional. E também sei, que se as pessoas ainda não entenderam a diferença entre o paradigma tradicional e o moderno, então mais complexo ainda é ver a diferença entre agilidade e artesanato de software. Mais valia pregar aos peixes … mas acreditando, como acredito, nos principios por detrás do artesanato de software, não posso, em consciencia, me abster de divuldar a mensagem e esperar que mais um se junte à causa.  Para quem está saindo da faculdade ou ainda entrando nela, é importante que pense bem se quer realmente ser um profissional de software ou apenas um tecnico, ou apenas um que sabe pilotar uma IDE. Se não é para ser a sério, mais vale não ser.

Aos que já estão na profissão, perguntem-se a si mesmos se tem vergonha do código em que estão trabalhando agora. Se você não sente nada pelo seu código, pelo seu software, você não é feito para ser um desenvolvedor, e talvez seja hora de pensar em mudar de vida. Se você sente algo, então procure melhorar-se a si e aos seus colegas, para que todos juntos possar sentir menos vergonha.

Making software is not about the money, or the ride, is about the dignity of the journey.

Fiz questão de fazer um curso não programático na finada Sun exatamente para descobrir esse outro lado. No curso que era guiado principalmente pelo Processo Unificado (Unified Process, UP) era levantada a lebre de um tal de XP. Eu tinha tido contato com o XP ainda quando fazia meu estágio em física. Afinal a física prática passa pelo processamento de sinal, e este passa por usar computadores.  Com o passar do tempo as práticas que observava na realidade não batiam com o que os livros diziam e o insucesso de vários projetos me fez entender que para entrar no mundo do software antes de saber programar é preciso saber escolher entre filosofias de desenvolvimento.  O Rational UP da  Rational Rose, depois IBM no tempo do CASE lançou o mote. A ideia era ter ferramentas onde especificar o software, apertar um botão e simplesmente teriamos um software funcionando. Não resulta. Ferramentas ainda são burras e precisam de alguém que as saiba usar.  Alguém muito esperto consegue vender esta ideia imbecil de que software pode gerar software automaticamente. Ainda hoje existem tentativas de enganar os pacóvios com esta artimanha. Repare que o engano advém de quem compra e não de quem vende. É quem compra que é muito desonesto, tapado, analfabeto ou burro para não entender a enganação.

Apenas pessoas sabem fazer software e existe uma razão muito simples para isso: fazer software é um processo criativo. Criativo aqui significa tanto ser um processo onde se cria algo, como um processo em que se precisa ter imaginação. E as máquinas não têm isso ainda.

Então por que é tão difícil fazer software? Fazer software não é dificil. O que é difícil é fazer software que alguém compre e atenda a uma demanda, a uma necessidade. Para qualquer produto comercial existem duas formas de demanda. Ou quem quer comprar, compra o produto já pronto que o produtor já criou antecipadamente (retail sell – venda a varejo) ou o interessado chega junto ao produtor e pede que seja feito um produto com certas características (tailored sell – venda sob medida). Na primeira categorias podemos encontrar muitos produtos como pão, fruta, vinho, carros, casas – e inclusive software – e no segundo podemos encontrar produtos como roupa (de alfaiataria), carros (Rolls Royce), aviões e também software. Qual é a diferença? Volume.  A primeira categoria ganha em vender barato e muito. A segunda em vender caro e pouco. Ambos têm o seu quinhão de mercado. Atenhamo-nos apenas ao software feito sob medida (sob demanda – on demand, como também é chamado) para o resto da conversa.

Em tudo o que é feito sob medida, e também num software, precisamos saber como o cliente deseja que seja o resultado final. Afinal o resultado final servirá a ele e apenas a ele. Tal como um casaco ou um terno que serve apenas a uma pessoa. Pode até ser que sirva para outros, mas nunca sem ajustes. Precisamos então saber quais são os requisitos. Requisito é um conceito muito importante neste tipo de produto, porque é à medida dele que será feito o produto final.

Um outro fator na equação é como será feito o produto. A tecnologia que será usada para realizar o produto afeta o preço, a qualidade, a durabilidade, e até o aspecto e usabilidade do produto.  Existem tecidos específicos para certos tipos de roupa e circunstâncias específicas. Existem razões técnicas de porque o mesmo casaco precisa ser de algodão em umas regiões e de lã em outras.  Se formos fazer um produto que nunca ninguém fez antes ou poucos tentaram e tenhamos que experimentar diferentes tecnologias será diferente daquele que utiliza uma tecnologia já muito entendida e aperfeiçoada.

Pondo estas duas forças num gráfico obtemos um cenários mais ou menos como o mostrado na figura a seguir.

Na zona verde estão os produtos menos complexos, os mais complexos na zona vermelha. Repare que o software é algo complexo.

Muita gente – gente demais, na minha opinião – adora comparar “fazer software” com “fazer casas, carros e aviões”. Não, essas coisas não são nem de longe tão complexas. Por quê? Porque os requisitos são muito bem conhecidos e a tecnologia também. Não há surpresas – tijolo é tijolo e metal é metal. Não há mudança de ideia no último momento. Não há uma tecnologia que surgiu no último momento e tornou tudo obsoleto.  Um pouco mais semelhante seria um carro costumizado ou um avião costumizado como Air Force One. Mais próximo ainda seria um vestido de noiva. A tecnologia é muito simples e conhecida, mas os requisitos são muito voláteis. É por isso que existem costureiros de grife cobrando caro por essas coisas. Do outro lado, temos as vacinas, aqui os requisitos são simples – evitar a doença , mas a tecnologia tem que ser criada. E algumas , como a da AIDS não tiveram sucesso até hoje.  A vacina é um exemplo muito mais próximo da complexidade de fazer um software com tecnologias novas (muitos projetos de vacinas falham, como falham os projetos de software). E talvez por isso as equipes tendam a usar tecnologias velhas. Dá-lhes uma margem maior de segurança emocional (se bem que uma plataforma de aplicação velha é um empecilho em si mesmo).  Armas de energia com o phaser do Star Trek ainda são uma ilusão, mas as armas  taser estão bem perto, e cada vez mais perto de uma arma de energia. Aqui, o requisto continua simples – desabilitar o adversário, mas a tecnologia é simplesmente desconhecida. Um exemplo de algo bem complexo de criar seria uma verdadeira  TARDIS , pois não apenas ela é um ser vivo que viaja no tempo e no espaço, como é maior por dentro do que por fora. Um desafio ao raciocínio humano mais fundamental, o que dizer ao raciocínio de engenharia.

Ao fazer software é raro que tenhamos requisitos bem conhecidos, e normalmente as empresas se encarregam de estragar a outra variável não tendo uma tecnologia padrão para desenvolver o software, o que significa que a cada projeto temos que começar de novo aprendendo novas tecnologias e refazendo funcionalidades que já tinhamos antes. Isto torna a produção de software inerentemente complexa. Não somos nós que a fazemos complexa, ela é complexa por natureza. O que podemos fazer é torná-la mais ou menos complexa, mas nunca apenas complicada ou  simples. Normalmente a tornamos mais complexa do que natural.

Aceitar este princípio básico – “princípio zero”, poderíamos chamá-lo – é fundamental para conseguir fazer software. Isto era verdade a 50 anos atrás, e com a velocidade com a tecnologia evolui,  é muito mais verdade hoje. Não é por acaso que nasceram coisas como o Java e o .NET para quebrar um pouco desse escalar de tecnologia que constantemente nos exigia mudar de ferramentas para fazer software. As plataformas virtuais nos trouxeram uma âncora que nos ajuda a diminuir a complexidade. Mas a âncora não durará por muito tempo e novas âncoras precisarão ser desenvolvidas.

Entendendo que fazer software é algo complexo, as pessoas esperam que a forma de gerenciar a produção do software tenha que ser igualmente complexa. E este é outro paradigma difícil de quebrar:  o complexo pode ser gerenciado com o simples.  O truque é mantermos os olhos nos objetivos. E são estes que têm que estar claros desde o dia um, e refinados todos os dias. Como já disse Dwight D. Eisenhower ”O plano não é nada, planejar é tudo”. Ou seja, a complexidade é tratada facilmente se o plano não for fixo e evoluir conforme as circunstâncias. Mas veja, o plano muda e é descartável, mas não os objetivos  (e se você tem algum sentido de ética, nem todos os caminhos são aceitáveis).  Algumas pessoas entendem esta frase assim: “não faça planos”. É errado. A mensagem é “Faça planos, e continue fazendo planos. Não pare de fazer  planos até chegar no objetivo”. A cada plano temos um mapa do caminho para os próximos tempos  ( horas, dias, semanas, meses, anos… não interessa), quando replanejarmos teremos um plano que vai um pouco mais à frente e assim continuamente. A mal intrepretação deste simples conceito leva a aberrações como a recusa de criar uma plataforma de aplicação coerente e coesa ou simplesmente achar que é possível levantar requisitos “on-the-fly” na medida que o projeto progride.

A complexidade do software demanda o processo criativo contínuo, e isso exige a atuação de pessoas em todos os pontos desse processo. Todo o resto são ferramentas.
Será que o processo unificado (UP) ou qualquer outro processo criado antes de 1990 se baseia nestes princípios? Quero crer que não. Todos os processos clássicos se baseiam num mecanismo Stage-Gate como o usado para construir carros e aviões (!). Este tipo de processo simplesmente não funciona quando a principal energia é a criatividade,  e é por isso que muitos de projetos de software falham.  Em qualquer outro ramo de atividade, tantos projetos falharem é inadmissível. Em software, fazemos de conta que não é verdade.

O que não é admissível é que seja possível viver construindo software sem ter um processo-base para tal.  Práticas de laboratório até temos algumas (vide práticas de XP ) e temos alguns candidatos a processos de gerenciamento realista de software como Scrum. Mas ainda aguardamos o santo graal do processo de software.  O Processo Unificado não é bom o suficiente porque ele é muito semelhante a um processo Stage-Gate  e é corrompido muito facilmente se transformado num processo que tradiconalmente é usado em empresas produtoras de software. Um processo criado “in-house”, híbrido e muito parecido com um Frankeistein , um monstro fabricado de partes de outrém.

A promessa de um processo padrão moderno, confiável, honesto, que tome em consideração a complexidade, os requisitos, as tecnologias, e as pessoas ainda está por vir.  A minha aposta é que será algo muito semelhante a uma fusão de Scrum com XP e diretivas do manifesto de software craftsmaship que apela a um certo padrão de qualidade e orgulho no trabalho que fazemos – que por exemplos os alfaiates têm – que nós,  produtores de software, ainda não temos.

Software é simplesmente complexo, e é por isso que gostamos de o fazer. Aceitemos de uma vez por todas a sua complexidade natural e façamos-o com o respeito que merece.

Tiny Types

Não ha muita documentação sobre isto, porque é bastante trivial e se aprende nas primeiras páginas de qualquer livro sobre orientação a objetos : Classifique os conceitos. Ou seja, crie classes para os conceitos. Classes não são artefactos que permitem reaproveita código, elas são artefactos que nos permitem classificar o codigo, da mesma forma que os biologos classificam os seres vivos usando uma classificação em reinos, filos, etc, até as  espécies.

Apenas uma pessoa sem noção lhe dirá que exista tal coisa como “classes demais” .. acaso existem conceitos “demais” ? Podem existir conceitos que não cabem no contexto, mas não conceitos demais. Não se poupe de criar classes , por muito simples que pareça.

Java é fortemente tipado e existe uma muito boa razão porque as linguagens de propósito geral são fortementes tipadas : permitem melhor classificar conceitos e por consequência melhor polimorfismo. Use isso em sua vantagem.

Crie tipos especiais para todos os tipos de dado, objeto, conceito , etc… que não forem suportados pelos tipos básicos do Java. CPF não é um numero, não é um texto, é um código. Não existe uma classe Code no java. Crie um objeto CPF, Telefone, etc…e se quiser até um objeto Number e Text. Afinal o number do java não tem operações aritméticas básicas como somar e subtrair.

A aritmética computacional de ponto flutuante é mais complexa do que explicam na escola. Não confie nela. Use objetos especiais para frações, taxas e sobre tudo para dinheiro. Mesmos que seja apenas para uma moeda e apenas para encapsular um BigDecimal ( mas , na real, implemente o padrão Money sem BigDecimal), mas sempre crie um tipo especifico para representar dinheiro.

Datas e Tempos

Aprenda a usar Date e Calendar, mas não os use diretamente. Crie tipos especializados. Crie objetos de intervalo, muito uteis, mas inexistentes em java. Use uma API como o Joda-Time (no futuro use a API de Date & Time do java) , ou crie a sua, mas criar uma API de tempos e datas não é trivial, você precisa ter muito conhecimento de como funcionam os mecanismo. Nunca , nunca, use Calendar como um atributo de uma entidade. Isso é o equivalente a vc usar um objeto Calculadora em vez de Integer.Use Date ou um objeto que faça o mesmo que Date, ou seja, nada. É um objeto que contém um long que é o numero de milesegundos desde 1 de janeiro de 1970. Apenas isso.

Não assuma que trabalhar com tempos de datas é facil. Não cometa o erro muito básico de fazer as contas você mesmo. Nunca faça isso. Delege  a Calendar ou a uma API especilizada como o Joda-Time. Nunca faça calculos do tipo o mês tem 30*24h ou assuma que uma hora sempre têm3600 segundos e um dia tem sempre 24 horas. Crie objetos para representar a duração e o periodo independentemente. Investigue até você saber a diferença entre estes dois.

Date e Calendar não dão suporte a dias uteis que é uma demanda comum em sistema, portanto você terá que implementar essas lógicas. Não é simples. A definição de dia util depende do negócio. Nem sempre o Domingo é uma folga. Feriados normalmente são lidos de um banco. Tenha isso em atenção.

Monte uma estrutura e reuse-a. Não se contente com o simples, faça-a robusta e reutilizável em mais do que um sistema. Use muitos cenários e mantenha muitos testes. Faça-a exacta, não um tapa-buraco.

Tratamento de Exceções

Tratamento correto de exceções tem regras. Force-as. Tome atenção à camada onde a exceção será lançada, e de onde, na camada, o será. Entenda o conceito de exceção, e sobretudo a diferença prática entre exceções verificadas e não verificadas. Siga boas práticas de tratamento de exceções como se a sua vida dependense disso. Ela realmente depende. Ok, talvez não a sua vida. Mas as a sua saúde mental com certeza.

Não tente criar uma hirarquia “auxiliar” de exceções. Não faça suas exceções muito espertas, mas faça-as informativas. Enriqueça-as com parametros. FileNotFound – qual file ? ClassCastException ? qual classe ? Não use mensagens hardcoded. Use chaves de mensagem e um sistema deresource bundle para a tradução (ver internacionalização).  E nunca, nunca, pelo que lhe for  mais sagrado,  mate um stacktrace. Se vc não sabe o que isto signfica, então vá estudar mais. Você não está preparado para trabalhar com java e muito menos para criar um sistema do zero.

Internacionalização

Não confunda Internacionalização (i8n) com Localização (L10n). Internacionalização significa : “Nenhuma informação que seja passivel de ser diferentes entre culturas é hardcoded”. Localização sgnifica : “Faça todas as informações passives de serem diferentes entre culturas sejam especificas e coerentes com a cultura X, por agora”.
Não cometa a o erro de  achar que internacionalização é sobre traduzir textos. Nem pense que  não faz falta se o sistema apenas será usado em uma cultura.

Repare que eu disse cultura, e não Locale. Cultura não muda apenas entre paises e linguas. Pode mudar entre empresas e négocios e até mesmo entre departamentos da mesma empresa.

Aprenda a usar os recursos do pacote java.text como DateFormat, NumberFormat e MessageFormat. Aventure-se a criar a sua API de globalização (que soma as ferramentas para internacionalização com de localização). Crie uma convenção de nomenclatura para as chaves das mensagens. Faça-a hierarquica separando os niveis com ponto ,por exemplo: label.cliente.nome
Nunca escreva codigo de conversão de String para data ou de String para numero, etc… use formatadores. Crie formatadores para os seus tiny types. Formatações são etérias, dados são eternos.

Mas internacionalização não é apenas uma questão de estilo. O seu sistema trabalha com endereços ? Ele aceita endereços no estrangeiro ? Imagine se Amazon não aceitasse endereços no estrangeiro…
O seu sistema segue padrões internacionais ISO para pesos e medidas ? Ou é como a sonda NASA que faz metade no sistema métrico e metade no sistema de libras ? O seu sistema trabalha com dinheiro? várias moedas  ? como vc grava no banco ? com duas casas decimais ? E as moedas que não têm casas decimais ? E as que têm mais  de 2 casas ? Você grava datas no seu banco de dados ? Em qual fuso horário ? O seu banco suporta diferentes fusos horários ? Seu sistema é um site ? Ele atende vários paises ? qual é o encoding das suas páginas ? Não é UTF-8 ?

Sempre que vir o requisitos “Este sistema deve ser internacionalizado” trema de medo, porque vêm muita coisa ai. Não assuma que é simples, nem fácil, nem barato.

Validação

Validação não é o mesmo que consistência. Consistência  : garantir que o objeto não tem um estado impossivel.  Por exemplo, 30 de fevereiro é inconsistence. Validação é verificar que um objeto consistente, é usável pelas regras da aplicação/negócio.  Use uma API de validação. De preferencia faça a sua mesma. É um bom exercicio de OO. Inspire-se em bibliotecas que já existem como a Apache Validator ou a JGodies Validations. Tem a JSR de Beans Validation, dê uma olhada também… quiça faça parte do futuro do java.

Modificadores ( vulgo, setters) não fazem validação. Eles fazem consistência !

Pesquisas

Entenda que a parte que importa de um sistema de dados é pesquisa. Tenha uma API preparada para isso. Não foque apenas no CRUD, lembre-se que existem relatórios e existe importação/exportação de dados.  Faça um sistema orientado a dominio. É mais simples, mas tenha cuidado de não abusar ou confiar demais em ORM. JDBC funciona muito bem, obrigado.

Use um sistema de Critérios+Intrepretador. Mesmo se usar o Hibernate. Não crie critérios do Hibernate diretamente. Isso ajudará a manter uma API de critérios que faz oq ue você quer mesmo que o Hibernate ou o JPA não façam. Nesses casos você apela para estratégias alternativas.

Não assuma que suas tabelas têm poucos dados e nunca precisará paginá-los ou carregar mais de 10 mil registros de um só vez. Vcoê precisará. Os dados acumulam-se. Tenha isso em conta desde o inicio. Use padrões como Fastlane Reader para ler muitos dados .

Não menospreze o poder do banco de dados de fazer calculos agregados (somas, médias, etc…) aproveite-se disso para aumentar a performance, mas nunca à custa de violação de camadas.

Se está com pressa use o Hibernate como motor das pesquisas, mas faça uma casca em torno dele. Ele não é perefeito e você terá que limar algumas arestas. Aprenda a mexer com Hibernate. Não é simples. Ele é bastante complexo , mas o abandone à primeira.Se tem tempo, crie sua propria API. É ainda mais complexo do que fazer o hibernate e o risco é brutal, mas o aprendizado é grande … faça você olhar o hibernate com outros olhos .. mesmo com todas as suas falhas.

Desista de usar like para pesquisas textuais do tipo que vemos em sites de e-comerce. Aprenda a usar o Lucene.  Melhore a experiencia dos usuários.

TagLibs e TagFiles

Use-os. Não use tags de terceiros. É tentador, mas você cai no vendor lock-in que nem um patinho ( ou será como um “bobinho” ?).  Sobretudo tags relacionadas a internacionalização e acesso. Proiba todo e qualquer uso de scripts ( excepto, talvez, em tag files). Use tag files para coisas que dependem de css ou da estruura gráfica do sistema em si e taglibs ( o nome correto é tag handler, mas todo o mundo conhece como taglib) para coias mais gerais, até para coisas que mais do que um sistema poderia usar ( como o controle de acesso).

Não use includes ( se tiver que usar use a tag jsp:include e não a diretiva include). Use frameworks como o sitemesh ou o tiles  , ou desenvolva seu mecanismo. Mais uma vez, não é trivial, portanto se você não sabe, use uma API canónica. Não invente muito, use JSP e nada de velocity ou freemarker ou essas outras tecnologias de renderização. Nem sequer xml+xslt (jsp pode escrever xml também, sabia ?).

Se usa JS F ignore a parte de jsp e taglibs, mas não ignore o problema de usar componentes de terceiros.

Epilogo

Sim. É complexo. Muita coisa para começar uma aplicação decente, mas somos programadores java ou ratos ?

Existem diferentes tipos de produtora de software. Temos a produtora interna. Aqui estamos falando de um departamento da empresa que produz software para a empresa. Normalmente produz alguma ferramenta (ERP) ou um meio de comunicação com os clientes (site e-commerce). O produto de software criado assim visa ajudar a empresa no seu fim, mas o produto não é comercializado.  Temos depois as produtoras on demand que fazem software sob medida (tailored) e finalmente as que fazem software como um produto. Aqui distinguimos entre  as que fazer produtos de prateleira (compre e costumize você mesmo ) e os implantáveis (compre, e costumizamos para você antes de começar a usar). A primeira linha é muito comum para produtos ao consumidor geral (empresas e individuos) como sejam o Office, os sistemas operacionais, os anti-virus, e os tocadores de musica. No segundo bloco temos os produtos de ERP e produtos mais especializados que precisam ser condicionados ao ambiente da empresa onde serão utilizados.

Vou me concentrar nos casos dos produtos de software feitos sob encomenda e/ou sob media. Aqui temos um cliente que deseja um software, e uma empresa que provê o serviço de produzir esse software. Entre eles deverá existir um contrato. Ora, o objetivo deste contrato é a realização do software e para isso temos que saber o que “é o software?”. O software será um conjunto de funcionalidades que permitirá ao cliente atingir certos objetivos. Estes objetivos devem ser claros para cliente e produtor, ou todos estarão em problemas. Nem todas as funcionalidades que o produtor incluir no software ajudarão o cliente a alcançar os objetivos. O conjunto de todas essas funcionalidades é chamado: Escopo. Algumas funcionalidades ajudarão mais, e outras menos, e a unica forma de saber qual é qual é deixar o cliente experimentar o software e decidir.  Então como criamos um contrato que permita alcançar isso ?

Existem vários tipos de contrato no mercado. Conforme o tipo de contrato que as partes escolherem isso formará um vinculo entre eles.  Nem sempre as partes são conscientes do vinculo que estão formando e nem sempre elas se apercebem dos riscos que estão enfrentando.

É interessante olha um contrato de software à luz do Dilema do Prisioneiro sendo o cliente um dos presos e a empresa que provê a construção o outro. A “policia” seria o mercado em si. Se ambas as partes não cooperarem, ambas  terão prejuízo. Qualquer contrato de software que leve a uma relação diferente da cooperação irá beneficiar apenas um dos lados , e no extremo, nenhum dos dois.

Falarei dos contratos de forma geral, já que se aplicam no mercado a diferentes ramos e conforme diferentes objetivos, em seguida especificarei o que acontece quando usamos esse contrato para contratos de software.

O contrato mais comum  é conhecido como Time and Materials. Neste tipo de contrato o provedor do serviço de construção cobra um valor fixo por unidade de trabalho. Normalmente a hora-homem. Este contrato não impõe limite ao prazo nem ao escopo do que será feito e portanto lança todo o risco no colo do cliente. A vantagem do cliente é poder terminar o contrato quando quiser, mas a desvantagem é que o trabalho pode se arrastar indefinidamente. Este contrato cria um vinculo de indiferença. O provedor não ganha nada terminando o trabalho antes e o cliente fica sempre aguardando que o trabalho termine sem poder fazer nada. O escopo aberto parece dar ao cliente a possibilidade de cortar quando quiser, mas na prática o cliente sim tem um escopo mínimo que ele quer ver completo. No mundo do software este é o famoso “cobrar por hora e vamos ver onde chagamos…”. O produtor cobra por hora pelo resto da vida e o cliente que saiba o que quer.Se o cliente se engana e ha retrabalho, tanto melhor : mais horas. Se o produtor se engana, tanto melhor : mais horas para resolver o problema.  Porque o cliente não quer pagar pelos erros do provedor, este contrato causa muitos problemas e não cria uma relação de colaboração entre as partes – bem pelo contrário o cliente está submetido à boa vontade do provedor, porque ele pode simplesmente preferir realizar o trabalho de outro cliente que lhe paga mais por hora. Claro que o cliente pode sempre mudar de provedor, mas a realidade é que só o fará quando for realmente insuportável continuar com o atual e normalmente o provedor tem lábia suficiente para ludibriar o cliente.

Uma variante é estabelecer um teto para o custo total e fixar um escopo. Isto, claro,  funciona quando o escopo é realmente fixo. Caso contrário , porque o custo é fixo, o provedor irá resistir a qualquer alteração do escopo. No caso extremo irá cobrar extra por novas coisas, caso em que ele estimula o cliente a definir o escopo errado para depois poder cobrar alterações.  No final este tipo de contrato é ainda pior para o cliente. Para software isto é um desastre. Não apenas o provedor não tem qualquer incentivo para definir bem o escopo, ele tem incentivo para o definir mal.  O fato do custo ser fixo, que deveria proteger o cliente, acaba fazendo lhe ainda mais mal.  O resultado é o mesmo em um contrato do tipo Fixed Price, Fixed Scope , onde o cliente paga um preço, fixa um escopo e o projeto anda até que tudo esteja completo sem prazo para terminar. Mais uma vez o provedor se faz valer de uma cláusula de alterações que oneram o cliente cada vez que forem feitas. Conclusão, se o cliente não tem o escopo bem definido, o provedor não irá se esforçar para o definir, pois toda a alteração será cobrada à parte.

Alguns acham que isso pode ser resolvido fixando também o prazo. Isto nos leva ao contrato do tipo Fixed Everything em que prazo, escopo e preço estão fixos. Aqui os papeis se invertem e é o provedor que fica na mão do cliente. O cliente incha o escopo com tudo que imaginar e estabelece um prazo e um preço para tudo isso. O provedor ou aceita, ou não aceita. Se aceitar, porque o cliente que estipula o escopo, o cliente pode sempre adicionar mais detalhes ao escopo, realmente tornando-o maior na prática, mas não no papel e portanto impedindo o provedor de cobrar por isso.  Este tipo de contrato é comum em licitações em que o cliente já fixa previamente tudo, mas deixa margem para inchar os detalhes ou espera fazer pressão econômica depois, ameaçando não pagar o provedor se ele não incluir mais aquela “pequena alteração”. Em software, porque os escopo é inerentemente  variável,  o provedor está automaticamente em desvantagem. Muitos provedores aceitam este tipo de contrato com medo que a sua concorrência os aceite primeiro. Este é o erro que alimenta a prática dos clientes estipularem este tipo de contrato.  Sendo que este tipo de contrato é altamente arriscado para o provedor, o fato do concorrente o tomar deveria ser entendido como bom, já que o risco está agora no concorrente e não com o provedor. O provedor pode então procurar outro tipo de contrato com outros clientes que sejam mais proveitosos e no longo prazo desfalcar o concorrente pois ele está metido até ao pescoço num contrato sanguessuga. Mas por alguma razão juvenil de “tentar ganhar do outro” os provedores de software acham que é melhor ser sugados por clientes com contratos fixed everything do que deixar os seus concorrentes serem sugados.  Sobretudo quando estamos perante uma licitação e o cliente é o governo. Aqui todo o senso empresarial vai para o espaço, porque o provedor acha que trabalhar para o governo é seguro ( não vai ficar sem trabalho), mesmo quando  isso significa que o governo o levará à falência. No mundo do software  não existe razão comercial que suporte aceitar este tipo de contrato, seja com quem for a menos que você tiver um às na manga (mais sobre isso em outra oportunidade ).

Se reparou bem, até agora, todos os tipos de contrato oneram uma das partes. Não ha nenhum que estabeleça metas comuns. O resultado é que – no mundo do software – estes contratos sempre falharão. Cada tipo de contrato é bom para determinadas circunstâncias de escopo. Quanto mais conhecido e fixo o escopo, mais simples o contrato porque menor o risco.   O problema é que, em software, o escopo é sempre mutável.

A moral desta recapitulação é que não podemos usar qualquer contrato para serviços de construção de software. Muito menos nos podemos guiar por modelos de contratos utilizado em outros ramos de atividade onde o conhecimento dos requisitos é estável. Nada de usar contratos como se o software fosse uma casa, uma ponte ou um avião. Isso são coisas com requisitos muito estáveis, logo, com contratos mais simples.

Bom, resta então, desenhar um contrato que seja vantajoso para ambas as partes e seja compatível com um escopo variável. Para isso temos que entender que o escopo tem duas propriedades : tamanho e característica. A característica do escopo é aquilo que a funcionalidade é. O tamanho se relaciona ao esforço para  construí-lo .

A primeira aproximação é o tipo de contrato baseado em Time and Materials mas com escopo variável e custo fixo. Nste tipo de contrato o tamanho do escopo é fixo – e portanto o custo é fixo, mas a característica é variável. Ou seja, o escopo definido no inicio é a base para uma estimativa de tamanho. Essa estimativa de tamanho é usada para estimar custo e prazo, mas o cliente pode mudar a característica do escopo, ou seja, pode mudar as funcionalidades ou o que as funcionalidades fazem. Isso deve ser feito de forma controlada de forma que nunca ha aumento de tamanho. Em software, este tipo de contrato é muito usado na cena ágil porque o cliente pode modificar o escopo conforme o valor das funcionalidades e conforme vai conhecendo, vendo, e experimentando o software. Uma variante consiste em deixar aberta a possibilidade  do cliente terminar o projeto antes de utilizar todo o custo/tamanho planejado. Esta variante de Valor Máximo, divide o custo não utilizado pelo cliente e o provedor, oferecendo aos dois vantagem se o projeto não chegar no custo, e portanto, incentivo para a colaboração e o alcance do valor máximo o quanto antes. Acontece que este tipo de contrato é fortemente baseado na estimativa inicial o que significa que se o provedor estimou mal ele estará se beneficiando em detrimento do cliente.  Isto nos leva ao ultimo tipo de contrato.

Este tipo de contrato é muito semelhante mas adiciona um limite máximo de expansão do custo. O provedor estima o tamanho e o custo da mesma forma que antes, mas em seguida adiciona uma margem. Se tudo correr bem e o cliente der o projeto como terminado antes de atingir o custo, os ganhos são repartidos como antes, metade-metade. Se o projeto passar do custo estimado, e até chegar no limite da margem, o prejuízo é partilhado metade-metade. Se o custo passar do limite da margem o prejuízo é totalmente por conta do provedor (já que isso significaria que o provedor estimou mal e conduziu mal a construção).

O mecanismo de estimativa de tamanho não é relevante, o que é relevante é que o provedor tenha um bom conhecimento entre a relação desse tamanho com o custo. Em horas-homem, meses-homem ou pontos de estoria, tanto faz.  O que interessa é que haja uma unidade e uma forma de a converter em custo. Vejamos um exemplo utilizando uma aproximação mais comum hoje em dia, o custo por hora-homem.  O provedor estima o projeto em 1000 horas-homem a um custo de 80 reais por hora-homem equivale a um projeto de 80 mil reais. Se tudo correr bem, esse é preço certo do projeto. Consideremos então uma margem de 20 mill reais (250 horas-homem) . O projeto custará no máximo 100 mil reais.

No espírito do contrato anterior, temos que repartir ganhos e prejuizo até chegar em 100 mil. O cliente paga 40 mil à cabeça e 40 reais por hora-homem até atingir o valor máximo do projeto de 100 mil reais.  Veja que isso significa que se o projeto terminar no tamanho estimado, o preço pago será o estimado (40  mill + 40* 1000 horas-homem) e o cliente terá pago exatamente 80 mill reais. Se o projeto terminar antes, gasntando apenas , digamos 600 horas, porque o cliente estava pagando metade do preço-hora o projeto termina com vantagem dos dois lados. Se o projeto vai além do tamanho estimado, digamos 200 horas ambos terão prejuízo de 40*200  = 8 mil reais.

Este tipo de contrato não coloca as partes em competição mas sim em colaboração com objetivos concretos e vantagens concretas.  Repare que o tamanho do escopo é fixo, o que significa que o custo só aumenta por atraso na execução e nunca por aumento de escopo como nos outros contratos. Porque o cliente não pode aumentar o custo, e também terá prejuízo se o projeto atrasar ele é incentivado  a escolher funcionalidades mais valiosas e mais “simples”.

Obviamente este tipo de contrato só funciona se as partes  tem capacidade de entender o seu funcionamento e o conceito de que nem todas as funcionalidades têm o mesmo valor e por conseqüência as mais valiosas e importantes devem ser feitas primeiro e algumas delas não serão feitas.  Este tipo de contrato estimula também o provedor a ter que trabalhar de uma forma que lhe permita terminar o quanto antes e responder rapidamente a alterações nas características do escopo. O que é muito simples se a empresa segue práticas ágeis de gerência e desenvolvimento.

Finalmente é importante notar que o fato das empresas colaborarem obriga à comunicação sincera e isso leva à criação de vínculos de confiança que permitem novos projetos no futuro. Além disso o impacto psicológico de terminar antes do custo faz o provedor se diferenciar no mercado face a outros concorrentes e deixa o cliente contente o suficiente para recomendar aquele provedor a outros parceiros.

Se você é responsável por contratos de software, pense bem nisto, e tente melhorar a sua forma de se relacionar com o seu cliente. Ele não é seu patrão e nem você é o cafetão dele. Vocês são colaboradores.

Mas o problema vem na prática.  Na prática não é nada simples ser fiel aos 5 valores ( Compromisso, Abertura, Respeito, Foco e Coragem),  afinal, estes valores parecem escassear nos dias de hoje. Afinal não é tão simples manter backlogs. Priorizar, comparar valor, estimar tamanho… não é tão simples na prática. Afinal não é tão simples, e  o fardo começa a ficar claro quanto mais a pessoa entende scrum. Não é por acaso que “Coragem” é necessária. Sem ela a pessoa desiste antes de ver os louros.

Todos aqueles que começam a usar scrum pela primeira vez passam por este processo de ir da glória da ignorância – achando que é simples de mais- ao inferno do pesado fardo da responsabilida e do compromisso – de volta à glória da sapiencia após entender que realmente funciona.Mas é trivialmente fácil a pessoa se enganar. É muito simples a pessoa faltar ao compromisso, à responsabilidade, perder o foco, perder coragem. Afinal , qual é o castigo ? Porque perder tempo com backlogs ? porque não simplesmente mandar os rapazes fazer o que queremos ? afinal quem vai nos exigir explicações ? ora…  Porque fazer reuniões todos os dias ? afinal as pessoas têm boca é para falar, porque precisamos de uma cerimónia, porque raios as pessoas não conversam quando elas querem ?

Perguntas imbecis como estas – embecis porque existem imensos estudos e autores explicando porque essas coisas são ruins – permeiam a cabeça de todos aqueles que foram educados e tem vivencia na forma tradicional de fazer software. Daqui nasce o Scrummas. É comum , hoje em dia, ouvir respostas como “Nós usamos scrum, mas…. ” seguido de alguma desculpa esfarrapada de porque foi boa ideia eliminar algum dos principios , valorer , práticas ou cerimónias do scrum. O Scrummas  (em inglês scrum-but, que é um trocadilho com butt que significa bunda) , advém da explicita violação do primeiro valor :compromisso. Ou bem que vc se compromete a seguir o scrum, ou bem que não. E na hora que vc começa a driblar e a arrajar desculpas é uma falha no compromisso. É uma desonestidade para consigo mesmo. Se não implementamos scrum totalmente como esperamos que funcione ? Quando vc muda o pneu do seu carro vc não aperta os parafuros porque “está com pressa e tem um horário a cumprir’ ? quando vc come, vc come com os dedos porque “afinal, acabou de lavar as mãos” ?  O que é você ? Uma criança com um monte de desculpas ? E para quem são essas desculpas ? o seu pai ? … não… são para si mesmo. Para esconder a sua falta de fidelidade com os valores.

Scrummas é um cancer moral que nasce na própria mente humana. É inerente ao ser humano encontrar dualidade. Quando no caos ele procura a ordem, quando na ordem procura a revolução.  É dificil sem dúvida seguir os valores. Afinal seguir quaiquer valores é complicado. Sempre dá vontade de desistir uma hora ou outra.

A extrema simplicidade das práticas do scrum, e do agil em geral,  leva a um excesso de confiança, a uma atitude de “eu posso fazer isto, é canja”. Mas a realidade é dura, e essas mesmas práticas lhe mostrarm tudo o que ha de errado em si e nos outros , no projeto, no cliente, na sua cidade e até na sua familia. Isso é demasiado peso para uma pessoa só e quando mais ela enxerga que esse é destino final, mais ela quer desistir. Ela quer minar o sucesso do scrum porque inconscientemente ela sabe que esse sucesso será o seu fim. Ela apenas esquece que, sentir isso, é a prova que entendeu o scrum, mais: é a prova que se comprometeu com o scrum. E só então , com esse conhecimento, o mundo parecerá melhor.

Talvez a extrema simplicidade leve as pessoas a complicar a coisa um pouco “só p’ra ter graça”, ou para poder encontrar defeitos, ou auto-minar o seu sucesso. A velha conversa de “Scrum não é bala de prata” … ora, realmente scrum não é uma arma contra coisas sobrenaturais , mas sim é a forma correta de trabalhar no desenvolvimento de software. Pelo menos até que alguem imagine uma melhor. Porque este desdem, essa “falsa modéstia” ? Se temos monstros que comem o nosso lucro, a nossa paciencia, e nosso tempo, não é de uma bala de prata que precisamos ? Bom… visto assim, realmente o scrum não é uma bala, ele não mata os monstros. Ele está mais para lente de aumento ou espelho, que mostrar onde e quais são os monstros.  Tanta metáfora … Falta de abertura. Falta de dizer a verdade pura e simples : Scrum dói. Scrum é dificil. Scrum vai mudar a sua vida. Scrum precisa que você tenha coragem, que os tenha no lugar, a todo o momento. Vc vai sofrer, mas depois vai ser recompensado… e não ha garantia que esse depois chegue, então vá se preparando para o pior. E o pior é : você voltar a fazer software como fazia antes do scrum!

Os valores do scrum, não são apenas palavras, são coisas que cada desenvolvedor deve sentir e seguir. Como profissional e como pessoa. Só assim poderemos acabar com o  Scrummas e a forma imbecil de fazer software que a esmagadora maioria das empreas utiliza.

Sempre que ouvir “Fazemos scrum , mas…” e tiver um arrepiu, isso é o sinal de que você é um desenvolvedor de software moderno. Não desista agora. Porque agora  vai  ficar ainda mais dificil mas também muito mais interessante ….

Felizmente algumas pessoas entenderam o objetivo do texto: descrever uma arquitetura mais adquada para sites sem usar EJB e aumentando as capacidades de teste e robustez das aplicações. Algumas pessoas pediram um exemplo mais concreto desta arquitura. Porque isto implicariam em escrever muito codigo e seria extenso demorei um pouco. Mas já que tinha que o fazer, resolvi colocar esta arquitetura na nova seção de configurações de arquitetura. Quem estiver interessado pode ler o artigo completo. Quem ler tenha em mente que é um “work in progress” e sugestões são bem vindas. A parte com CriteriaBuilder tive que pular pois ia ocupar muito espaço e não é o foco do artigo. Cada um poderá implementar como quiser. Só uso esse objeto porque ele torna muito facil criar criterios de busca.

Espero que fique claro  desta vez porque esta arquitetura é vantajosa face às tradicionais arquiteturas acopladas ao hibernate e/ou entity manager.

No mundo real, contudo, o Product Owner tem que responder a vários stakeholders e o valor advém principalmente da expectativa e demanda que esses stakeholders têm em relação às features desenhadas nas estórias. Isto deixa o Product Owner numa posição muito subjetiva de ter que adivinhar os desejos de prioridade de todas as partes interessadas e, pior que isso, conseguir ordená-las.

O método

No seu livro “Software Requirements“, Karl Wiegers demonstra um método que poderia ajudar nesta situação. Embora o método não tenha sido desenhado para aplicar num ambiente agil,  o conceito é simples o suficiente para ser adaptado.A atratividade é uma relação entre o valor, o custo e o esforço.

O Valor

Para chegar no valor da  estoria pedimos a cada parte interessada que pontue de 1 a 9 o beneficio que aquela estoria traz, sendo 1 uma estoria com o menor beneficio e 9 com o maior beneficio. Depois pedimos que pontue de 1 a 9 a penalidade de abandonar aquela estoria, sendo 1 uma estoria que não traz penalidade abandonar ( ninguém iria sentir falta dela) e 9 uma estória que tem maior penalidade ao ser abandonada (muitas pessoas iriam reclamar).

O valor será então a soma do beneficio com a penalidade. Assim, uma estoria que tem beneficio 1 mas penalidade 9 é equivalente em valor a uma que tem beneficio 9 e penalidade 1.

Esta pontuação pode ser definida apenas pelo PO no caso em que as partes interessadas não são tão interessadas assim para as fazer responder um questionário. O PO continuará confiando no seu tato e feeling, mas pelo menos será obrigado a colocar isso numa escala. Um trabalho semelhante ao que a equipa faz para pontuar o tamanho das estorias.  No caso geral, contudo, ele elaboraria um questionário e pediria que fosse respondido pelos stakeholders. Esta é uma prática já comum na área de jogos, por exemplo, onde as features são avaliadas por questionário respondidos por potenciais jogadores antes de serem incluídas para desenvolvimento.

Este método permite ao PO atribuir ao parâmetro de valor um numero, em uma escala relativa, que está diretamente relacionada à demanda e expectativa dos stakeholders em relação à estoria.

Pode acontecer que existam poucos stakeholders com que o PO pode interagir, por limitações variadas. Neste caso o PO deve procurar por mais partes interessadas ainda que “remotamente interessadas” e atribuir pesos diferentes às opiniões dadas pelos stakeholders principais e pelos secundários.  A ideia é que o PO deve aumentar a abrangência do grupo de stakeholders de forma a ter uma melhor ideia das suas demandas e expectativas. O tamanho do grupo, os papeis que essas pessoas desempenham em relação ao produto e a forma como pesar as demandas de cada um varia conforme o produto e as próprias pessoas envolvidas. O PO deve equacionar isso quando estabelecer critérios de como será levantada a pontuação de beneficio e penalidade. No caso extremo o PO necessitará de uma equipa própria que o possa auxiliar nessas tarefas.

O Custo e o Tamanho

O custo no método descrito por Wiegers é equivalente ao conceito de Tamanho em ágil. Estamos interessados numa medida relativa do quão grande é cada estória. Então, no caso agil, o PO usará as estimativas de tamanho em pontos de estoria estimada pela equipa por métodos como o planning poker.

O Risco

O risco também é avaliado pela equipa junto com o tamanho. O risco é a probabilidade de 1 a 9 de que a estoria não vai atender à demanda dos stakholders à primeira.  O risco não está relacionado à probabilidade de completar a estoria no sprint, nem relacionado ao cone de incerteza. Este  risco do método descrito por Wiegers está relacionado  à probabilidade de, uma vez ponta, a funcionalidade incluída pela estoria não satisfaça os stakeholders interessados.

As razões para o risco são muitas. Desde de um fraco levantamento de requisitos a uma equipa inexperiente nas tecnologias necessárias passando por uma fraca usabilidade ou um aspecto gráfico “feio”.

No modelo explicado por Wiegers existe a opção deste fator ser ignorado num primeiro uso do método e integrado na medida em que descobrir que as estorias não satisfazem os stakeholders. Isso pode ser controlado pelo numero de vezes que uma mesma funcionalidade, cenário de uso, ou tecnologia usada na implementação são modificados depois de estarem pontos.

A atratividade

Baseado no valor  (calculado pela soma do beneficio com a penalidade) no tamanho e no risco , calculamos a Atractividade da estoria ( que Wiegers chama também de Prioridade,mas em agil esse nome tem outro significado). A atratividade (A)- o quanto a estória é atrativa – é calculada da seguinte forma:

Onde v é o valor da estoria, t é o tamanho da estoria e r é o risco da estoria. V é a soma de todos os valores de todas as estorias, T é a soma de todos os tamanhos e R de todos os riscos. Este conceito de “todos” pode ser aplicado ao product backlog ou ao release backlog. Estamos interessados em ter uma medida relativa. Porque as estorias no backlog mudam (entram e saiem) a atratividade irá mudar nesse momento, o que é exatamente o que seria esperado empiricamente.

Se desconsiderarmos o risco, numa primeira aproximação, a formula se transforma em :

O fator T/V será igual para todas as estorias e igual a uma constante que apenas afetará o valor numérico da Atratividade mas não o seu valor relativo. Neste caso, simples, em que removemos o fator de risco, a atratividade se resume ao quociente entre o valor e o tamanho.

Atratividade e Prioridade

A razão pela qual não podemos considerar diretamente que a atratividade é equivalente à prioridade é  que a prioridade implica num valor diferente para cada historia, coisa que a formula da atratividade não garante. Então, no fim, o PO ainda terá que desempatar algumas estorias com atratividade igual, mas pelo menos agora ele terá que fazer isso apenas em alguns casos e não em todos. A atratividade é um coeficiente que pode ajudar a guiar a decisão do PO, mas é apenas uma formula matemática que não está sujeita a pressões de stakeholders.

Adaptação

O método descrito por Wiegers usa escalas de 1 a 9 para pontuar o beneficio, a penalidade o risco. Escolher uma escala decimal é natural ao ser humano, portanto a escolha de numeros menores que 10 é muito feliz neste método. Contudo, das práticas de estatística, sabemos que escalas impares fazem com que respostas a questionários tendão para o valor central sendo sempre melhor oferecer um numero par de opções. Por estas razões poderiamos aumentar a escala até 10, diferenciando o 5 e o 6 como uma indecisão mas com peso para um dos lados.

Um outro detalhe é que o valor numérico da atractividade vai variar entre numeros menores que um ( 1/13) e maiores que 1 ( 10 /1). O que pode confundir o PO ao comparar o numero 0, 00769 com 10, por exemplo. Além de implicar em regras de arredondamento chatas. Por outro lado, como a Prioridade normalmente usa numeros bastante grandes poderiamos aplicar um fator numérico à atractividade descrita por Wiegers para ter uma escala mais “humana” apenas com números inteiros e mais próxima da escala de Prioridade. Multiplicando por 100 mil, teríamos valores mais compráveis, por exemplo 1.000.000 e 7.692 eliminando o problema do arredondamento.

A ditadura dos números

Com esta técnica não apenas ganhamos uma forma de atribuir um numero e uma escala relativa ao Valor, mas ganhamos uma forma de comparar o Valor com o Tamanho de uma forma simples, que pode atuar como uma forma rudimentar de priorização. Contudo não podemos encarar este método como uma forma à prova de falha ou que substitui o discernimento do PO. É apenas uma ferramenta auxiliar para ajudar o PO a decidir, mas de nenhuma forma pode ser considerada a resposta definitiva que dita a prioridade das estórias.

Não é porque a teoria “maistream” das metodologias ágeis ignora os problemas do dia-a-dia do Product Owner e confia no seu senso de valor que temos não podemos sugerir uma forma um pouco mais “cientifica” de fazer as coisas olhando as boas práticas das metodologias clássicas. Afinal queremos um Product Owner que tome decisões baseado em fatos, não em suposições. E definitivamente não queremos um Product God que toma controle de tudo baseado nos sues próprios interesses.

Hoje com o advento do Seam parece que EJB vai ser novamente necessário para fazer sites. Veja que Seam utiliza os EJB como back-beans do JSF o que significa que não funcionará fora de um Application Server. A maioria dos sites não precisa das capacidades contidas em  um Application Server, bastando um Web Container. A própria especificação JEE 6 vai oficializar este divisão entre o que é web site e o que é realmente uma aplicação corporativa.

Ao falar de aplicação corporativa todos imediatamente pensam em bancos de dados, ou melhor, em SGBD (Sistema Gerenciador de Banco de Dados) e imediatamente pensam em DAO e depois em Hibernate e JPA.  O problema aqui é que DAO é obsoleto, JPA é infantil e Hibernate não tem concorrência. Se você está pensando em criar um software e em usar DAO, esqueça. Isso é coisa do passado. Hibernate e JPA são encarnações no novo padrão que matou  o DAO, o DomainStore. Então é neste padrão que você deve se concentrar hoje, e não no DAO. Para web site, você precisa no máximo de um Hibernate.

Por que não JPA? Porque o JPA tem o mesmo problema do EJB 2.x. A especificação é simplista e falha. Ela viola explicitamente o propósito de mapeamento agnóstico o que significa que usando JPA você não poderá usar qualquer banco de dados. Aliás, se você usa algum tipo de SELECT esqueça JPA.  Não que o hibernate o vai liberar de criar código especial para este ou aquele banco, mas vai minimizar muito essa necessidade e adiá-la o máximo possível.  Mas o grande problema com o JPA é a criação de pesquisas. As pesquisas do JPA não são OO e não são agnósticas. As do Hibernate são OO se usar Criteria e agnósticas, quer usando Criteria ou HQL.

As pesquisas são o elemento esquecido do CRUD. O objetivo de ter um mecanismo de CRUD é poder pesquisar os dados depois. Poderíamos até argumentar que todo o objetivo de ter um banco de dados é permitir as pesquisas. E onde escrevemos estas pesquisas?

Obviamente teremos que as escrever em algum objetos cuja responsabilidade principal seja montar critérios do Hibernate. Estes objetos são os repositórios. Os repositórios concentram todas as responsabilidades CRUDL (CRUD + Listagem) e normalmente precisamos de vários deles.

É muito comum a ideia de que ao termos um mecanismo com o  Hibernate poderíamos criar um DAO para encapsular as chamadas a ele, mas isso é um erro tático e técnico muito importante. Primeiro que apenas queremos na realidade facilitar o uso de classes como a Session e talvez adicionar um pouco mais de tipagem forte. Isso não é um DAO, é no máximo um Adapter. Nada contra construir um Adapter deste tipo, mas existe um ponto mais importante aqui. Se o repositório é responsável por montar objetos de Criteria, ele já está acoplado ao Hibernate; logo criar mais um objeto no meio é fútil. Por outro lado, se quisermos desacoplar  o Hibernate dos repositórios (veja, o Hibernate é apenas um, os repositórios são vários) precisamos, na realidade, de uma estratégia para criar os Criteria sem usar as classes do hibernate e depois delegar a algum outro objeto que as traduza para essa tecnologia. A forma mais realista de fazer isto é criar um mecanismo agnóstico de Query Object e Interpreter.  Funciona assim: o repositório é agnóstico (ou seja, não depende da tecnologia de persistência) e depende de um objeto PersistanceStrategy (o nome pode variar). Este objeto é, na verdade, uma interface, um serviço, cujo contrato também é agnóstico.  PersistanceStrategy aceita entidades para operações como save e delete, e aceita objetos Query Object para pesquisas. Objetos Query Object são como os Criteria do hibernate mas sem a dependência com o Hibernate.

Depois criamos uma implementação HibernatePersistanceStrategy. Este objeto delega as operações ao Hibernate e sabe como traduzir Query Object agnóstico para Criteria do Hibernate.

Dessa forma, se um dia você quiser remover o Hibernate, você pode. E esse dia não é lá no futuro não. É amanhã, quando você começar a escrever os seus testes unitários e de integração.

Recapitulando: Repositório conversa com PersistanceStrategy através de Query Object. Repositório é responsável pelo CRUDL da Entidade.

Do outro lado, queremos manipular as entidades para conseguir criar valor. Controlar uma venda, uma compra,  uma transação de qualquer tipo. Para isso precisamos encapsular as regras para essa transação. Precisamos, principalmente, de objetos capazes de validar os dados de entrada e de objetos capazes de realizar o processo. Os primeiros são validadores e os segundos,  serviços.

Serviços seguem  o padrão interface + várias implementações e temos dois grandes grupos. Serviços de aplicação (como enviador de email) e serviços de domínio (como o que realiza a transação de compra). O próprio PersistanceStrategy de antes é um serviço de aplicação.

Validadores são usados dentro dos serviços para validar os dados de entrada. Neles mantemos todas as regras que permitem realizar a operação. Validadores podem ser usado fora dos serviços para acelerar as coisas e nem sequer chamar os serviços caso haja problema, mas devem sempre ser chamados dentro dos serviços independentemente de serem chamados antes. É como a validação javascript que não substitui a validação no servidor. Entenda-se: estes validadores não apenas validam os dados de input do usuário, mas aplicam regras de negócio a esses dados.

Recapitulando:  Serviços de Aplicação e Serviços de Domínio.  Serviços utilizam Validadores para evitar corrupção.

Finalmente, um pouco sobre actions. “Action” é qualquer classe onde você controla o fluxo de uma aplicação web. O nome ficou famoso devido ao Struts e muita gente ainda chama estas classes de controladores (quando na realidade são apenas Strategy) erradamente. Todos os frameworks web, de uma forma, ou de outra, acabam delegando a uma classe ou conjunto de classes a decisão de processamento de um certo request. Essa classe é a action.

A action só pode conversar com Serviços de Domínio e executar pesquisas em Repositórios. Não podem invocar mecanismos save/delete nos repositórios. Para não cair nesta tentação é mais seguro você criar um serviço de dominio  que medie a comunicação action-repositorio, garantindo que apenas métodos de pesquisa são invocados. A responsabilidade das actions é converter os dados da UI em dados que os serviços entendem. Isso normalmente significa Entidades, mas não apenas. Vários Value Objects como BigDecimal e Date pode necessitar de conversão também. Eventualmente a Action pode invocar validadores antes de invocar os Serviços. Isto especialmente para ser capaz de informar o usuário e proteger o sistema de dados corrompidos ou que não satisfazem as regras de negócio.

Enfim, as requisições do usuário são mastigadas nas actions onde se transformam em objetos do que os serviços aceitam. Os serviços são invocados. Os serviços chamam outros serviços e/ou têm lógicas internas que produzem alterações em objetos existentes ou criam novos objetos. Os serviços utilizam os repositórios para realizarem pesquisas e persistir as alterações.  Os repositórios delegam ações de persistência e pesquisa a implementações de PersistanceStrategy que as traduzem para ações reais sobre o banco de dados ou sobre um DomainStore como o Hibernate.

Não há por que complicar a arquitetura e design das sua aplicações web. Estes poucos elementos são normalmente  suficientes para realizar sistemas em que há muito mais leitura do  que escrita.  Mas, mesmo que você esteja desenvolvendo aplicações web-RIA (ou seja, simulando aplicações desktop de cadastro em web) esta arquitetura ainda é suficiente.

Não continue se iludindo com o uso de EJB ou desenhando aplicações como se fazia nos anos 90. Já se passaram 20 anos. Estamos em 2010.