O Fim do “Agile”

Um artigo bastante recente, publicado em agôsto de 2019 no website da Forbes declarava o fim do Agile. O autor, Kurt Cagle, é escritor, cientista de dados e futurista, com foco na interseção das tecnologias de computação e a sociedade. 

O autor inicia o artigo descrevendo a seguinte situação:

“Eu sabia que o fim do Agile estava chegando quando começamos a usar tacos de hóquei. Todas as manhãs, exatamente às oito horas, a equipe de desenvolvedores e arquitetos ficava ao redor de uma sala com painéis de quadros brancos e começava a passar um taco de hóquei de brinquedo pelos membros da equipe. Quando você recebesse o taco de hóquei, deveria lançar-se na ladainha: perdoe-me, pai, porque pequei.

- Ontem escrevi apenas dois módulos, pois era um dia de reuniões e jejum, e dependia de Joe, que está doente esta semana com pneumonia. 

O scrum master, aquele que estava sentado enquanto estávamos de pé, anotaria isso adequadamente em Rally ou Jira (eu esqueço qual), e então entoaria:

- Você está três módulos atrasados. Você acha que fará isso hoje?

- Farei os três módulos como você solicitou, scrum master, pois diminuí a média da equipe e agora sou indigno.

- Vejo que sim, meu filho, pois o sprint termina na próxima terça-feira e a chefia está assistindo.

O bastão de hóquei sagrado seria então repassado para o próximo desenvolvedor, e como monges nervosos, o resto de nós soltaria um suspiro de alívio quando pudéssemos entregar o maldito bastão ao próximo pobre idiota da fila. Isso não era mais uma metodologia de gerenciamento de projetos, tinha se tornado uma seita religiosa que não fazia muito sentido para os participantes e para quem estava de fora.

O princípio básico do Manifesto Ágil era simples – uma equipe pequena e competente trabalhando em equipe. Muitos projetos de código aberto foram realizados por pequenas equipes de desenvolvimento com tamanho entre duas e doze pessoas, sendo o tamanho ideal em torno de sete. Quando a equipe tem esse tamanho, o design pode ser feito quase como uma atividade de grupo. O Agile era moderno, era legal e envolvia números de Fibonacci. Como não gostar dele?”

O autor afirma ainda que percebeu um erro no Agile, assim descrito:  “O Manifesto Ágil entendeu errado desde o início - não era tanto o fato das pequenas equipes funcionarem melhor porque podiam seguir uma metodologia enxuta para realizar um projeto. Em vez disso, os projetos de software aberto funcionavam porque as tarefas necessárias para sua conclusão eram relativamente independentes - elas podiam ser codificadas rapidamente, a funcionalidade poderia ser mostrada dentro de algumas semanas, e, uma vez concluída, a manutenção era problema de outra pessoa”.

Na época em que o Agile surgiu, um projeto de software típico estava dentro dos parâmetros bons para o Agile e por isso se ajustou bem. Kurt Cagle ressalta que “a maioria era baseada na web, com instalação da interface da web sendo feita em alguns dias. Usavam bancos de dados como uma maneira de armazenar o estado (“storing state”), e o desenvolvedor da web geralmente tinha acesso irrestrito a esse banco de dados. Eram projetos que levavam entre quatro e seis meses (oito a doze sprints de duas semanas) para serem realizados e eram predominantemente voltados para o cliente (tanto no sentido de que as interfaces com o usuário eram uma grande parte da experiência quanto no sentido de que o cliente podia ver mudanças ocorrendo praticamente diante de seus olhos). Eram também projetos nos quais, no caso de uma funcionalidade ser cortada, o aplicativo não seria significativamente degradado por essa perda. Foi nessa época que o conceito de um produto mínimo viável começou a se estabelecer - a noção de que, além dos primeiros sprints, o produto seria útil mesmo que o desenvolvimento parasse naquele momento, por conta de alguma definição arbitrária”.

Logo o Agile virou o mantra nas empresas

“Desnecessário dizer que as empresas começaram a notar o que estava acontecendo, e logo tornar-se Agile se transformou no mantra da semana. O Agile passou de um manifesto bruto para uma metodologia formal em que um gerente de projeto (agora chamado de scrum master) trabalhava com outro gerente (dono do produto a ser desenvolvido) para criar "histórias" que descreviam o que eles desejavam que seus produtos realizassem (coisas que antes eram conhecidas como requisitos) e "tarefas" que se tornaram as etapas necessárias para concluir essas histórias e que formavam o contrato (com a intermediação do scrum master) entre um gerente/dono do produto e o desenvolvedor ou designer. Dentro dessa estrutura, a forma geral do aplicativo surgiria depois de níveis sucessivos de detalhamento e, em seguida, implementação. Ao rastrear essas informações, em teoria, era possível determinar se um projeto estava atrasado e, se houvesse atraso, alocar recursos adicionais para solucionar a área problemática causadora do atraso. Novamente, do ponto de vista dos negócios, essa era uma grande vitória, uma vez que os projetos de software são, por natureza, um pouco assustadores para os gerentes/chefes - você está investindo uma grande quantia em dinheiro, sem muita garantia de que terá algum retorno para esse investimento. Assim sendo, poder ver caixas coloridas em vermelho, amarelo e verde (meu comentário: ver “project status report”) destacadas em um gráfico é um bom calmante”.

Vejamos, a seguir, alguns problemas do Agile abordados nesse artigo:

“O problema, é claro, está nos detalhes - e na natureza do comportamento humano. Na maior parte das vezes o gerenciamento de projetos trabalha com a ideia de que as tarefas são mensuráveis, com base nas métricas definidas por outras pessoas que executam (meu comentário: ou costumam executar ou já executaram) essas mesmas tarefas. A configuração de uma linha de montagem é uma tarefa muito previsível e, como é feita com bastante frequência, é possível estimar o tempo necessário para sua execução. Infelizmente, a criação de um software não é previsível. Em quase todos os casos, geralmente é mais barato (se não necessariamente sempre melhor do ponto de vista da organização) comprar um software de prateleira, e isso ainda é válido mesmo se o preço for mais alto. A razão para isso é simples - a funcionalidade que se procura já existe e o preço pela dificuldade de criar o aplicativo pela primeira vez já foi pago.

Quanto tempo leva para criar a funcionalidade de login? Demora cerca de uma hora para codificar a interface do usuário. Pode levar trinta minutos para codificar no back-end ... ou trinta dias. Se você deseja uma integração total com o sistema de autenticação do Active Directory (meu comentário: Active Directory armazena de forma estruturada informações sobre objetos na rede) em uma plataforma não padrão que ofereça suporte apenas ao LDAP (meu comentário: Lightweight Directory Access Protocol, um protocolo que permite gerenciar diretórios) e deseja integrar um sistema de autenticação de email de duas passagens ao mix, a interface do usuário é a menor das suas preocupações. Que tal um painel bonito de gráfico de rede que mostre como todos os componentes do seu sistema estão inter-relacionados e permite operações de arrastar e soltar? Não me faça começar. Eu ainda tenho pesadelos sobre isso”.

E o autor segue com seus comentários afirmando que “existe uma falácia nos círculos de programação de computadores de que todos os aplicativos são decompostos - ou seja, você pode decompor aplicativos complexos em muitos outros mais simples. No entanto, geralmente não é possível que comportamentos mais complexos comecem a funcionar até que você tenha a combinação certa de componentes funcionando, e mesmo assim você terá problemas com a sincronização da disponibilidade de dados, uso de memória e desalocação e condições com que o programa roda - problemas que só serão evidentes quando você tiver feito a maior parte do software que estiver construindo. É por isso que a pergunta "mas será que vai escalar?" entrou no léxico dos programadores em todos os lugares. Os problemas de escala só aparecem quando você constrói o sistema quase completamente e tenta fazê-lo funcionar em condições mais extremas. (meu comentário: Em outras palavras, se surgir um problema será necessário implementar uma solução que pode demorar). As soluções geralmente envolvem a demolição de partes significativas do que você acabou de construir, para grande desalento dos gerentes/chefes em todos os lugares. Essa é uma das razões pelas quais os desenvolvedores realmente odeiam ter que colocar números nas tarefas. Isso se torna ainda mais problemático quando os desenvolvedores precisam integrar seus esforços com outros desenvolvedores, especialmente para os componentes desenvolvidos ao mesmo tempo. Se houver uma incompatibilidade entre como dois componentes interagem, redesenhar essas peças pode levar tempo e complexidade difíceis de medir. Isso também sugere que o Agile nem sempre é escalável. As dependências de integração geralmente não são rastreadas (ou são incluídas em histórias hierárquicas), mas tendem a ser um dos aspectos mais variáveis ​​de qualquer desenvolvimento de software. Realisticamente, isso não é tanto uma falha no Agile quanto nas suas ferramentas mais comuns. Tecnicamente falando, um diagrama de projeto é um gráfico de informações, não apenas uma árvore. Você tem dependências no espaço, tempo, organização, abstração e complexidade, e estimar o tempo para a complexidade geralmente é o elo mais fraco de todas essas ferramentas. Por outro lado, esse esforço também é agravado quando há muitas pessoas envolvidas nos projetos, porque a complexidade de gerenciar esses projetos aumenta geometricamente com o tempo. Uma conseqüência dessa abordagem também é que, com equipes grandes, a quantidade de tempo envolvida no planejamento geralmente pode consumir até um quarto do tempo total disponível para o desenvolvimento.

Outra questão é que a ênfase constante no produto viável mínimo significa que a qualquer momento os desenvolvedores acabam gastando uma porcentagem significativa de seu tempo construindo e demonstrando seu trabalho até aquele momento, consumindo outros dez a quinze por cento do tempo disponível, geralmente para códigos que serão jogados fora”.

E aqui o autor volta para a situação do diálogo mencionado no início de seu artigo:

“As reuniões de scrum têm a intenção de durar apenas quinze minutos, mas a realidade é que eles podem continuar facilmente quando houver problemas. Espalhar sprints por três semanas faz mais sentido, mas na prática poucas organizações adotam isso”. E complementa afirmando que “um outro efeito colateral dessas reuniões é sobre os gerentes/chefes, que por suas próprias funções geralmente estão envolvidos em scrums em vários níveis em suas organizações, o que significa que isso lhes deixa com pouco tempo para realmente liderar em um nível estratégico e os obriga a microgerenciar, normalmente com resultados sem brilho”.

E para arrematar Kurt Cagle não deixa por menos quando aponta uma contradição muito comum nas empresas, mas que passa simplesmente despercebida, que é a seguinte:

“Muitas vezes, são as organizações de consultoria (que fornecem mão-de-obra do tipo consultor/hora) que mais gostam do Agile, apesar de seu objetivo em qualquer projeto ser o de fornecer o máximo possível de profissionais desenvolvedores e equipes de suporte alocadas nos projetos. Isso é irônico, porque o que acontece é que o Agile é, portanto, empregado mais fortemente em operações onde a metodologia clássica da Waterfall, com ênfase em especificações precisas e pré-planejamento detalhado, seria realmente preferencial”.

Os projetos de software que não se enquadram no Agile

“Deve-se notar que existem classes inteiras de projetos em que o Agile tradicional é contraproducente. Os projetos de dados corporativos, em particular, não se enquadram nos critérios para serem considerados bons candidatos ágeis, por vários motivos:

·         Os sistemas de dados corporativos (EDS – Enterprise Data Systems) enfatizam bastante a modelagem de dados, cuja complexidade pode variar de alguns dias a meses, dependendo das fontes e do tamanho da organização.

·         Os projetos de EDS tendem a se concentrar em consultas, transformações e movimentação de dados, nenhum dos quais normalmente é voltado para o cliente.

·         Os projetos de EDS geralmente estão em andamento, exigindo uma mistura de ingestão automatizada de dados e curadoria ativa de dados, em oposição ao desenvolvimento de aplicativos com prazo determinado.

Devido à natureza generalizada do EDS, navegadores, bases de conhecimento, hubs de dados e aplicativos similares são mais apropriados do que aplicativos especializados, o que significa que a necessidade de desenvolvimento personalizado também é reduzida ao mínimo.

Para ser justo, embora existam algumas metodologias de desenvolvimento no espaço de conhecimento corporativo, o domínio em si é novo o suficiente para que nenhuma metodologia única se estabeleça para os sistemas de dados corporativos da maneira como o Agile se estabeleceu para o desenvolvimento de aplicativos. Isso não deveria surpreender - o foco nos dados corporativos é relativamente novo”.

O ambiente para o qual o Agile é mais adequado está desaparecendo

“O cliente como ponto terminal significa que o ambiente para o qual o Agile surgiu pela primeira vez e para o qual é mais adequado - aplicativos de código aberto independentes - está desaparecendo. Hoje, o aplicativo típico é mais provavelmente um tipo de fluxo de dados, no qual o valor não está na programação, mas nos próprios dados, com a programação consequentemente muito mais simples (e com uma matriz muito mais ampla de ferramentas existentes) do que há vinte ou dez anos atrás. 

Talvez o último grande destaque dessas aplicações seja na categoria de jogos e, mesmo nessa categoria, o surgimento de alguns conjuntos de ferramentas consistentes, como o Unreal Engine, signifique que há uma convergência crescente nos componentes técnicos, com o Agile realmente apenas sendo usado em áreas como design e criação de mídia.

O que isso aponta a longo prazo é que as metodologias de trabalho estão se movendo em direção a um modelo de evento assíncrono em que os fluxos de informações são conectados, mapeados e depois transformados em um modelo nativo de maneira imprevisível. Lançamos plataformas, depois "episódios" de conteúdo, alguns tão pequenos quanto um tweet, algumas atualizações de jogos em tamanho de gigabyte.

Embora os aspectos do Agile permaneçam, o mundo pós-Agile tem prioridades e requisitos diferentes, e devemos esperar que algum paradigma finalmente consiga lidar com o stream de informação como a unidade fundamental de informação. Portanto, o Agile não está "morto", mas está se tornando cada vez menos relevante”. 

Para mais informações acesse >> https://www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/#2edfc1442071