Manutenção Ágil – Parte 1: Dá pra ser Ágil na manutenção de produtos de software?

O Departamento de estatísticas do trabalho nos Estados Unidos (Bureau of Labor Statistics) estimou, em 2010, que por volta de 68% dos desenvolvedores de software do país trabalham em atividades de manutenção de software. Imagino que não deve ser muito diferente no Brasil. Afinal, depois que produtos são construídos, precisam ser mantidos. E todos os dias novos produtos atingem o estágio de manutenção em todos os cantos do mundo.

Apesar disso, e estranhamente, a gestão da manutenção de produtos de software tem sido, já há muito tempo, colocada em segundo plano tanto pelas empresas, como pelas próprias comunidades de práticas. Ninguém dá muita atenção, apesar do problema desse mercado ser bem sério e de difícil solução. As dificuldades são muitas:

  • Os times vivem apagando incêndios;
  • Quando não há incêndios, tudo é urgente, e as coisas importantes só são feitas quando se tornam urgentes;
  • As interrupções são frequentes e os planejamentos nunca são seguidos;
  • É difícil prever entregas e organizar uma agenda com o cliente;
  • Raramente há engajamento e motivação, e a colaboração é praticamente inexistente. 

Por outro lado, as empresas já demonstram um grande interesse em tornar suas equipes de software Ágeis (com “A” maiúsculo mesmo). Projetos de transformação correm à solta por todo o país. Equipes de desenvolvimento adotam novas práticas de trabalho e começam a gerar bons resultados. Todos os meses surgem novos Agile Coaches para ajudar na disseminação do novo paradigma. Scrum e Kanban estão na agenda pública da TI nacional.

Enquanto isso, uma pergunta permanece sem uma resposta clara: 

– “Dá pra adotar o Ágil em times de manutenção?”

A grande maioria dos profissionais do mercado Ágil vai responder algo similar quando se depara com esse cenário:

– Sim, nesse caso a gente adota o “Kanban”!

Alguns, mais desinformados, se apoiarão na baixa sofisticação do slogan da guerra dos métodos dos anos 2010: “Kanban é para manutenção e Scrum para desenvolvimento”.

Na hora de adotar o tal “Kanban que serve para manutenção”, a pobre compreensão do método, aliada à falta de entendimento concreto da realidade costuma levar os menos avisados a descobrir que não é bem assim. Kanban pode ajudar em projetos de manutenção sim, mas será preciso ir além do método para realmente saber o que fazer nesses casos. 

Um dos problemas dessa simplificação conceitual expressada pela frase “Kanban serve a manutenção” é da forte tendência do agente de mudança focar na “implementação do método” ao invés de no “uso do método”. A diferença é sutil, mas suficientemente relevante para definir o resultado, e para nos dar um ponto de partida para o que discutiremos nesse artigo e no novo curso do Software Zen para manutenção Ágil que começará em alguns dias.

Tanto o Ágil quanto o Kanban, e outros métodos e práticas recentes usados por trabalhadores do conhecimento, estão alinhados com suas próprias estruturas de princípios. A palavra princípio vem do latim principium e, além de significar o início, a origem, também traz o significado de essência, de fundamento. A essência por sua vez é uma espécie de espírito que é frequentemente expressado pelo seu propósito. 

Eu sempre dou o exemplo que aprendi do Tomás Sedlácek, um economista tcheco, cujo trabalho eu aprecio muito. Ele conta que antigamente nossos despertadores eram uma “coisa”, um “objeto” que ficavam ao lado da nossa cama. Seu propósito era nos acordar no horário correto. Hoje ninguém mais tem despertadores físicos ao lado da cama (ok, eu sei que sempre teremos o pessoal que segue a onda vintage ou então a galera que não sabia o que fazer com o despertador, e deixou por lá mesmo só pra mostrar a hora). Mas, apesar do objeto ter sumido, o propósito do despertador continua existindo, como um espírito eterno, encarnado no seu celular. Às vezes ele até tenta ficar com a mesma cara, desenhado como um antigo despertador na sua tela. Mas, no fim, é só um algoritmo, tão abstrato quanto um poltergeist, que migra de plataforma em plataforma, encarnando-se em meios diferentes para cumprir o seu propósito.

Princípios são propositadamente abstratos, e é aí que está sua força. É importante que seja assim porque os parâmetros e decisões sobre como torná-los concretos só se tornarão conhecidos no momento da sua implementação real. A tentativa de antecipar toda essa composição lógica de parâmetros e decisões nos levaria de volta ao mundo da prescrição detalhada de processos da “Era Waterfall”.

A receita que os métodos trazem também são abstrações. Certamente são mais concretas que os princípios que definem sua essência, mas não deixam de ser abstrações. O que é concreto mesmo é o que acontece no mundo real. Os estímulos que você recebe, as ações que você executa e a maneira pela qual você as executa.

Quanto menos você conhece a sua realidade, mais dependente você estará de um método ou de uma receita externa, definida para você, e por alguém que conhece bem uma realidade que pode até ser semelhante a sua, mas não é necessariamente a sua. A diferença dessa realidade original (a que foi usada para extrair o método), com a sua própria realidade, é a impedância que você precisa resolver. Não tem jeito, essa parte está no seu colo. Somente o aprofundamento no entendimento das características específicas da realidade que você vive será capaz de resolver a impedância.

Em outras palavras, depois de um certo ponto, não adianta saber mais sobre Ágil ou sobre Kanban, ou Scrum, é preciso saber mais sobre o que você faz, como faz e porque faz. É aquela velha história: “O peixe é sempre o último a descobrir a sua água? Como é a sua água?”

Então para a pergunta “Dá pra aplicar o Ágil em um projeto de manutenção?”, a resposta é “sim!”, mas será preciso ir além das receitas. Não dá para implantar os métodos. Eles foram feitos para outros cenários. O que precisaremos fazer é usá-los. Usá-los como uma espécie de repertório para o estabelecimento de um novo design, uma nova encarnação, em um novo meio. Um design que enderece as especificidades do que acontece no mundo concreto dos projetos que envolvem manutenção. Nesse mundo é preciso:

  • Saber reagir rápido aos desastres; 
  • Ser flexível para absorver demandas urgentes;
  • Ser leve no planejamento e na entrega de releases com ajustes e melhorias;
  • E ainda garantir a entrega continuada de novos projetos de expansão do produto.

A montagem de um sistema de trabalho que enderece essas questões será o tema do mais novo curso do Software Zen que começará em breve, no dia 04/02: Gestão Ágil para Manutenção de Software.

Se a sua responsabilidade hoje é manter as coisas funcionando, é nesse curso que você tem que estar.

Abriremos as matrículas nessa segunda-feira (28/01).