Hyper Agile

O manifesto para o desenvolvimento ágil de software^[1], em 2001, constituiu um marco no modo de produção de sistemas de informação.

Refletindo a crescente preocupação pelo mau serviço prestado pelo software aos seus clientes, algumas das vozes mais conscientes das tecnologias da informação formularam, em quatro linhas, proposições que invertiam tudo o que era anteriormente considerado irrefutável, e declararam preferir escolher

• Pessoas e interações em vez de processos e ferramentas
• Software funcional em vez de documentação detalhada
• Colaboração com o cliente em vez de negociação de contratos
• Resposta à mudança em vez de cumprimento de um plano.

Um conjunto de princípios adicionais elucidavam claramente as consequências desta perspetiva.

Quase duas décadas passadas, o balanço é misto. Há muitas boas experiências, mas o desenvolvimento ágil não é, ainda, generalizadamente aplicado. O processo iterativo ainda não é mais usado do que a alternativa, o clássico waterfalll. “Já somos Ágil” significa, muitas vezes, ter um pequeno projeto Ágil, enquanto a maioria dos projetos segue a decomposição linear e sequencial do waterfall: requisitos > conceção > desenvolvimento > testes > instalação. É também comum, quando algo começa a correr menos bem num projeto, que as equipas (e os clientes) se refugiem em práticas waterfall. Se as promessas do Agile não se cumprem, a tendência é procurar abrigo nas velhas técnicas.

No entanto estas estão claramente ultrapassadas, devido à rápida mudança de paradigmas. Nos dias de hoje, chegamos a ver casos em que o software antes de ser terminado já se encontra obsoleto e já se sabe que não irá responder às necessidades do cliente. A realidade e as necessidades alteram-se hoje em dia mais rapidamente do que o desenvolvimento do software, quando este é realizado pela metodologia waterfall.

Por outro lado, o desenvolvimento ágil transformou-se na metodologia Agile e, de algum modo burocratizou-se. Perde-se frequentemente a noção do objetivo, passando o meio a ser identificado como o objetivo final^[2]. Alistair Cockburn, um dos subscritores do manifesto, queixava-se, no ScrumDay realizado em Lisboa^[3] em 2017, deste efeito. A certificação (de dois dias) de scrum masters e a identificação de product-owners não garante, de forma alguma, o sucesso dos projetos.

O sucesso do software não é apenas uma questão de metodologia. Seguir uma metodologia Agile, como o recente caso Lidl demonstra^[4], pode também conduzir a um desastre. E pode até ser mais difícil e demorado (e, consequentemente, mais caro) declarar um projeto ágil como falhado. É essencial que essa agilidade seja já uma caraterística técnica do software utilizado para desenvolvimento, o que, na Lidl, não era evidentemente o caso.

O software inspira outras áreas da gestão e devemos seguir com toda a atenção o projeto do BBVA de alterar a sua organização, a sua estratégia e (mais difícil ainda) a sua cultura com o objetivo “More than 30,000 people working “agile” in 2018”^[5].

A contribuição da Quidgest

Quase duas décadas depois, há que exigir mais ao Agile.

O desenvolvimento de software não se tornará efetivamente mais ágil (mais rápido) enquanto a escrita de código for realizada por humanos a uma taxa de escrita de 2 carateres por segundo e, ainda assim, sujeita a naturais erros humanos, por vezes bastante difíceis de detetar, mesmo com a prática de peer-reviewing.

Também não se torna mais ágil ou mais rápido se se aplica a uma configuração de um software standard tradicional. Estas configurações são manietadas pela componente standard (uma black box intocável), que tem uma agilidade semelhante ao betão. Neste caso, falar de conciliar Agile e um ERP standard tradicional, por exemplo, é apenas enganar o cliente^[6].

Os ganhos obtidos por apenas se proceder a uma reorganização das equipas e das tarefas (isto é, o Agile não suportado por automação da geração de código) são limitados e estão confinados a projetos de pequena dimensão e pouco complexos, de curta duração e desenvolvidos por equipas relativamente diminutas.

A realidade é que o Agile é limitado^[7], e de modo a suprir essas fragilidades e aplicando as lições aprendidas onde foi não tão bem-sucedido como se desejaria, surgiu o Scaled Agile ^[8](agora na versão SAFe 4.5). Esta metodologia incorpora um conjunto de preocupações relacionadas com níveis mais elevados de complexidade e com carteiras simultâneas de projetos, ao mesmo tempo que integra os conceitos de Lean IT.

A Quidgest é uma orgulhosa defensora do Agile e do Scaled Agile, mas tem contribuído para elevar estas metodologias a outro patamar de eficácia.

As contribuições decisivas da Quidgest para o Hyper Agile são

• • a automação: ao saltar de 2 para 1 000 000 de carateres escritos por segundo, e sem erros;
  • a modelação: o que significa um controlo a um nível mais elevado de abstração, uma representação de alto nível e uma explicitação da arquitetura do sistema de informação;
  • a eficiência das equipas: com as competências integradas no Genio as equipas são mais pequenas, há um muito elevado reaproveitamento de padrões e muito menos trabalho direto para cada projeto;
  • a redução dos ciclos de produção de software: para apenas algumas horas;
  • a comunicação e a interação com o negócio: é fácil comunicar e refletir ao nível do modelo, tarefa que é impossível ao nível do código, uma vez que as linguagens de programação (quaisquer que sejam) não são a forma adequada para conceber soluções de software ou para falar com CEO ou utilizadores-chave.

___________________

[1] http://agilemanifesto.org/
[2] Uma posição interessante https://www.lambdacambridge.com/blog/2018-05-how-scrum-destroyed-agile
[3] Em 2018, vai organizar-se o Experience Agile https://www.experienceagile.org/
[4] https://www.consultancy.uk/news/18243/lidl-cancels-sap-introduction-having-sunk-500-million-into-it notando-se que a metodologia proposta se pretendia ágil: https://www.kps.com/en.kps-transformation.html/article-2203-unternehmen-der-unterschied
[5] https://www.bbva.com/en/bbvas-journey-becoming-agile-organization/
[6] http://www.scmfocus.com/sap/2018/08/kps-continues-to-keep-promote-hana-for-retail-for-lidl-after-failure/ A este respeito, aconselhamos vivamente a opinião fundamentada e corajosa de Shaun Snapp.
[7] Por exemplo, as limitações da aplicação do Scrum estavam bem patentes no primeiro artigo sobre o tema, “The New New Product Development Game”, de Hirotaka Takeuchi e de Ikujiro Nonaka, Harvard Business Review, January 1986, muito antes de o termo ser aproveitado pela produção ágil de software.
[8] https://www.scaledagileframework.com/