O manifesto ágil é visto hoje em dia como o responsável por uma mudança de paradigma no mundo do desenvolvimento de software. A meu ver a mudança de paradigma é inevitável e não depende da existência de dito manifesto. Aliás, dito manifesto pode ser até um entrave à mudança de paradigma em curso. Na realidade não se trata bem de uma mudança de paradigma verdadeira, é mais uma volta às raizes.

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.