Métodos ágeis e seus valores

De tempos em tempos a comunidade de software da qual eu também participo cria rivalidades entre conceitos e práticas que surgem, e nesse nosso meio que muda rapidamente, surgem a todo o momento.

Algumas surgem através das descobertas de pesquisas científicas, outras como resultado de uma coleta de práticas que deram certo, e que acabam por originar frameworks, metodologias, modelos e processos que passam a servir de orientação, e a serem conhecidos como um conjunto de melhores práticas em determinadas áreas do desenvolvimento de sistemas.

Podemos exemplificar estas rivalidades relembrando a discussão surgida há tempos atrás com a popularização do CMM e do PMBOK.

Vários profissionais da área de desenvolvimento de software questionaram qual seria a melhor adoção, qual proposta deveria ser adotada em detrimento da outra.

O mais intrigante neste caso é que na verdade as duas propostas são incomparáveis, pois possuem objetivos distintos, mas que se integram muito bem.

Quem trabalhou na implantação de práticas do CMM, ou que procurou se capacitar em práticas de gestão de projetos com base no PMBOK sabe muito bem disso. Mas isso já passou e já foi compreendido.

Ultimamente, a discussão entre práticas de desenvolvimento de software considerando os métodos tradicionais está sendo fortemente questionada pelos defensores dos métodos ágeis.

Já participei e ainda participo de projetos de desenvolvimento de software utilizando ciclos tradicionais de desenvolvimento e reconheço muito bem os ganhos que estes oferecem, assim como suas falhas.

Considerando por exemplo, o ciclo de vida de software Waterfall (cascata), temos fases e etapas que somente se sucederão se ao final de cada uma os produtos gerados forem validados e previamente aceitos, autorizando a finalização de uma etapa e permitindo o inicio da etapa seguinte.

Este ciclo possui um conjunto de fases e etapas bem definidas, pois se sabe claramente o objetivo de cada fase, suas entradas e saídas, o que é produzido, quem produz, quando produz.

Se a etapa receber a entrada esperada, ela produzirá a sua saída também esperada (estou falando apenas dos artefatos de software que fluem pelo processo).

E cada fase nunca vai deixar de fazer o que faz. Esta abordagem facilita o gerenciamento dos projetos, pois cada fase é visível e facilmente rastreável pelo gerente de projeto.

Então, onde está o problema desta abordagem?

O problema está no momento em que podemos identificar que um determinado requisito não está sendo atendido: somente após ele ter sido entregue como software.

O exemplo clássico disso ocorre quando desenvolvemos uma funcionalidade inteira de um sistema para somente depois apresentarmos para o demandante o resultado final.

Inimaginável nos dias de hoje, pois sabemos que se corre o risco, comprovadamente alto, da solução não atender o que se desejava, e termos que voltar para as etapas anteriores de análise, rediscutindo requisitos, e por consequência refazendo muitas linhas de código. Muitos casos práticos nos ensinaram isso.

Quanto maior for o numero de requisitos desenvolvidos desta forma, maior o risco do retrabalho, portanto, dinheiro jogado fora.

Muitos dizem que esta abordagem não funciona porque os profissionais a executam mal. Muito discutível, eu diria, mas antes disso, a questão está no risco alto que esta abordagem oferece pela sua própria concepção: ela não tolera erros.

Cada erro custa muito caro, e quanto mais tarde ele ocorrer, mais caro ele é e em proporções geométricas.
Quanto maior o numero de requisitos transformados em software de uma vez só, maior o impacto na ocorrência de um erro.

Sabemos que os demandantes, na maioria das vezes, são incapazes de definir de forma precisa os requisitos do software, não por incompetência, mas pela complexidade inerente a definição de um todo, em um só momento, e com um prazo limite.

Pois bem, a nova abordagem do método ágil, é um contraponto à abordagem clássica descrita anteriormente, e aqui nasce mais uma saudável rivalidade.

A proposta dos defensores do método ágil está em desconstruir a abordagem clássica baseada em alto esforço de documentação, especialização de funções, busca incansável pela previsibilidade, e acima de tudo intolerante a mudanças.

Por outro lado, os defensores dos processos produtivos clássicos enlouquecem quando avaliam as propostas da metodologia ágil que contrapõem as características descritas anteriormente.

Aprofundando na proposta do método ágil e somado com alguns bons anos de experiência teórica e prática, podemos tirar algumas conclusões.

Consideramos que esta rivalidade não tem muito sentido, pois a proposta dos métodos ágeis possui características dos processos clássicos aprimorados, como por exemplo, aqueles de abordagem incremental e interativa, e que foram propostos como uma melhoria ao processo de software Waterfall.

O que então vale a pena discutir na mudança proposta?

Vale a pena discutir a mudança de estratégia. A mudança de valores.

Concluímos que há no método ágil uma mudança de valores significativa, comparando-a aos métodos tradicionais de desenvolvimento de software.

Mudança de valores? Como assim?

As metodologias ágeis propõem uma série de mudanças que provocam a utilização de práticas e comportamentos que exigem do profissional, além do seu lado naturalmente técnico, o seu lado comportamental. Exige uma nova “dinâmica social no projeto”, dinâmica esta voltada com ênfase em um conjunto de valores que estão fortemente relacionados: a pró-atividade, o comprometimento, a comunicação, a cooperação, a integração e a aproximação.

Vamos analisar alguns exemplos destas mudanças de valores:
Quando o método ágil propõe que a equipe trabalhe fisicamente no mesmo local, estamos falando de aproximação, olho no olho. Modelagens e documentos devem ser utilizados na medida do necessário e não substituem uma conversa esclarecedora. Não vou entrar no mérito da documentação, pois é indiscutivelmente necessária, mas sim de quando ela é realmente necessária e o que ela deve conter.
Quando o método ágil propõe que os profissionais exerçam mais de uma função no mesmo projeto, estamos falando de multifuncionalidade.

Posso ser um analista de sistemas e também programador de software.

Posso ser arquiteto de software e programador.

Posso ser um testador de software e um analista de sistemas.

Nada impede esta multifuncionalidade.

A questão está apenas na capacitação do profissional.

Obviamente que algumas especializações, devido a complexidade de alguns assuntos, são necessárias, mas uma organização totalmente especialista deixa de ser interessante.

Atenção! Não vamos tomar como sinônimos a competência e a especialização.

Aqui a especialização é compreendida como uma divisão do trabalho, a capacidade de fazer muito bem apenas uma coisa só. É isso que a abordagem ágil não deseja, e ela também não deseja um generalista incompetente.

Gargalos e dependências em processos, retardando o fluxo de execução, são criados quanto mais especializações funcionais existirem na estrutura organizacional do projeto. Se somente um profissional souber executar funções de um DBA, por exemplo, certamente será um recurso em que suas atividades farão parte do caminho crítico no cronograma do projeto.

Quando o método ágil propõe que as comunicações verbais e visuais sejam intensificadas, estamos falando de comunicação e interação. Documentos comunicam, mas um quadro na parede com indicadores coloridos e formas visuais, são muito mais significativos e instantâneos na sua comunicação que um status report qualquer.

Não estou descartando o status report, principalmente tratando-se de públicos distantes da equipe de projeto, mas ela passa a ser uma peça auxiliar na comunicação e não a principal.

Quando o método ágil propõe a aproximação do demandante da equipe de desenvolvimento, estamos falando de cooperação e integração. Não existe negociação a distancia. Não existe negociação por documentos. Existem negociações olho no olho, lado a lado. Após a negociação existe a documentação do que foi acordado. Apenas isso.

Quando o método ágil propõe que o que vale é o acordo estabelecido diretamente entre quem demanda e quem produz, e que estes podem naturalmente serem revisados, há uma evidente cumplicidade, uma cumplicidade positiva, no sentido de que aquilo que foi acordado, pode não estar certo, mas todos estão cientes deste risco. Não se luta pelo erro zero, mas sim pela correção o mais rápido possível e em curto espaço de tempo.

Sim, encontramos na raiz da discussão apenas uma mudança de valores.

Documentos e processos não podem valer mais que a satisfação dos envolvidos.

Satisfação se obtém com a possibilidade de participação, com foco no que interessa, com agilidade, com criatividade, com comprometimento, com a aceitação da possibilidade de erro, mas que todos buscam não cometê-lo, e da sua devida e rápida correção para o bem de todos.

Ouvi há tempos atrás em uma entrevista uma frase de alto impacto neste contexto: “precisamos de menos metodologias e mais métodos (ideias)”.

A metodologia ágil poderia ser considerada apenas como mais uma metodologia dentro de tantas, mas estamos aqui dando ênfase ao que ela propõe de melhor: pessoas fazem as coisas e não os processos.

Como eu já disse, é um soco no estomago de mentes puramente cartesianas… Foi assim no meu.

Pois bem, muitos podem dizer que esta mudança de comportamento ou estes valores podem ser inseridos em qualquer projeto de desenvolvimento de software, sob qualquer metodologia. Talvez. O que o método ágil propõe atua na natureza das relações entre os envolvidos, diferente dos demais métodos.

Além disso, e não menos importante, algumas práticas muito interessantes são propostas na abordagem ágil. Vamos falar de algumas delas.

Diferente do método tradicional de desenvolvimento, onde o profissional se confunde com o produto que entrega, ou seja, estabelece uma relação de um para um, o método ágil propõe uma relação 1 para n, pois a multifuncionalidade assim propõe. Ser multifuncional dá a oportunidade da visão holística, do processo cooperativo, da inovação, da pluralização.

Quando o método ágil propõe que façamos pequenos ciclos de entrega, e que o demandante possa validar aquele pequeno conjunto de funcionalidades, diminuímos o tempo e esforço para encontrar o erro, materializamos rapidamente para o demandante o que ele estará recebendo, baixando o custo da correção, e por consequência, o custo total.

Cliente e fornecedor estão juntos, cooperados, integrados e comprometidos. Isso eleva a motivação e facilita o tratamento das expectativas, de ambos os lados.

Quando o método ágil propõe que a equipe de desenvolvimento se auto gerencie, diferente do que muitos pensam, não haverá a falta de gerenciamento, muda apenas a prática de gerenciamento.

Estamos falando de autogerenciamento.

A diferença está na ausência de um gerente de projeto, aquela figura central e no topo da hierarquia do projeto, rigorosa, que cobra avanços e resultados, e que o sucesso do projeto depende somente dele e da sua capacidade de gerenciamento.

Nada contra gerentes de projetos, pois há projetos em que a existência do gerente de projeto é fundamental, assim como há projetos que a autogestão também funciona.

No autogerenciamento a equipe acorda entre si o que fazer, quando fazer e como fazer, assim como os resultados a serem atingidos. O autogerenciamento traz a participação ativa, o comprometimento com o resultado da equipe, a inovação.

Aqui entra o compromisso do grupo com o resultado, e não o compromisso de um com o seu resultado apenas, sabidamente maléfico em qualquer situação. Já está comprovado que o foco, em resultados individuais, afeta negativamente o resultado do grupo.

Além disso, o autogerenciamento e acompanhamento constante dos resultados, seus acertos e erros, é um campo fértil para a melhoria continua.

É uma proposta diferente das abordagens tradicionais utilizadas para a produção de um bem físico, claramente baseadas em processos produtivos industriais clássicos onde cada um faz uma coisa, cada um responde por uma pequena parte do todo, e juntando tudo chegaremos ao produto final.

Isso ocorre com sucesso na produção de um bem físico que possui características pré-definidas e previamente acordadas, e que não muda. Não muda nunca.

Um carro em uma linha de produção não muda nunca. É sempre o mesmo até que uma nova versão saia da prancheta, e um novo processo produtivo inicie, e que também não mudará.

Sistemas não são concebidos assim. Não devem ser concebidos assim.

Isso é comprovadamente eficiente na indústria de bens físicos, mas que a meu ver não se aplica na produção de bens que não são materiais, os bens intelectuais, pois estes são definidos e compreendidos à medida que a sua construção acontece.

Sistemas de software amadurecem, pois não nascem prontos. Não é um carro e não devem ser produzidos como um carro em uma linha de produção.

Concluindo, estamos falando sobre métodos ágeis como um processo redesenhado, para que a atenção seja dada naquilo que está sendo solicitado, na satisfação do demandante, e que tudo seja visualizado em pequenas partes, na aceitação da possibilidade de retrabalho, com foco em anulá-lo o mais rápido possível e em curtos espaços de tempo.

Certamente o custo final será menor e a satisfação muito maior, pois não há mais a distinção clássica da relação entre cliente e fornecedor, ao contrário, há a unificação de interesses na busca de um resultado que agregue valor a todos os envolvidos.

Portanto, a rivalidade existente entre métodos ágeis e métodos tradicionais de desenvolvimento de software, não se justifica se constatarmos que os métodos ágeis propõem, apenas (risos…), uma mudança drástica de valores, (mais risos…).

[Crédito da Imagem: Métodos Ágeis – ShutterStock]