Artigos Engenharia de Software Adaptando-se para utilizar métodos ágeis

As peças do quebra-cabeça estão no lugar, para desenvolver e manter um software precisamos:

  • De cooperação entre clientes e fornecedores, entre usuários e desenvolvedores;
  • De investir na comunicação franca, na comunicação transparente, com especial atenção ao alto valor do feedback;
  • De uma metodologia que proponha um conjunto de convenções que sejam produtivas ao trabalho das pessoas;
  • De líderes atentos e flexíveis, capazes de perceber a necessidade de adaptações e adequações ao escopo, ao método e ao time;
Quebra-cabeça Metodologia agil

Todas estas “coisas” funcionam muito bem juntas, não há dúvidas, entretanto algumas questões de controle e da forma de acompanhamento de um projeto devem estar sendo indagadas pelos experientes leitores deste artigo. Será exatamente esta a principal questão para adaptar-se na utilização de métodos ágeis? A pergunta, na radicalidade da questão, é quão “leve” ou quão “profundo” deve ser o controle de um projeto (ou de rotinas de manutenção) para ser considerado “ágil”.

Eu, particularmente, torço muito para que este artigo “toque” tantos leitores não estejam preocupados com a utopia de ser ou não ágil. Gostaria que todos estivessem mais responsabilizados com o fato se se é ou não funcional. Uma preocupação única com o presente, com o aqui e agora do projeto em curso. Mesmo assim, tenho muito interesse em explanar mais sobre o assunto, pois em minhas rápidas pesquisas não encontrei muitos autores ensinando como se adaptar aos métodos ágeis.

Controle: tem que ser leve porém suficiente

A palavra controle, tão amada pelos pensadores comprometidos com rotinas de governança, tão convencionada pelas propostas das regras PMI - Project Management Institute, também é tão assustadora as defensores dos métodos ágeis. É a mesma palavra, porém dependendo de quem escuta, traz ao ouvinte uma consciência positiva ou negativa.

Na minha leitura, existe uma nova compreensão no momento histórico que nos encontramos. Hoje, os gestores de projetos em atuação como eu sou, na grande maioria somos filhos de pais controladores e ao mesmo tempo pais permissivos de nossos filhos. Fomos criados com muitos limites e fronteiras, lutamos por liberdade e ensinamos estes valores a nova geração que nos sucede. Acreditamos mais em comunicação e parceria do que em regras rígidas.

De certa forma, é apenas uma nova definição para a palavra controle, uma revisão conceitual evolutiva. Não é anular ou desprezar procedimentos de controle, é simplesmente uma nova compreensão de responsabilidade sobre como fazer o projeto.

A ideia chave desta nova definição é refletir a cada semana sobre o que funcionou bem e o que precisa ser melhorado no projeto, com o compromisso de qualidade e atendendo a expectativa de prazo. Ao invés de seguir um plano “religiosamente”, no sentido de fixidez, como se qualquer mudança fosse considerada um pecado, um problema. É se adaptar as mudanças, é se adaptar aos acontecimentos do próprio projeto, é se adaptar as características da pessoas participantes.

Controlar, na nova essência que estamos sugerindo neste artigo, é estar junto ao projeto, é liderar para o fim esperado, é estar comprometido com o resultado.

Adaptando-se para utilizar métodos ágeis é permitir uma releitura do conceito acerca da palavra “controle”, da forma de controle dos projetos, das atividades. É uma nova compreensão, mais comprometida com o resultado do que com o plano inicial, mais comprometida com as pessoas participantes do que com os processos.

Aristocracia

A pressão para atender aos prazos e os atrasos na construção do projeto são ditadores implacáveis da profundidade de controle a ser utilizado nos mesmos. Contudo, o pensamento que para recuperar o cronograma de um projeto em atraso é necessário aumentar a carga de trabalho e o número de desenvolvedores é, na quase totalidade das vezes estudadas, um equívoco organizacional. Atender a este apelo corporativo é atuar no efeito, é aumentar o estresse, é persistir em algo que está explicitamente apresentando erro.

Os problemas podem ser tantos, os mais diversos possíveis, porém em minhas observações históricas não são nada criativos. Em todas as investigações que fiz, todos os efeitos resultam da mesma causa, provem da mesma matriz originaria: o ser humano.

O erro é consequência de uma dinâmica impropria no projeto: talvez um arquiteto de software despreparado para o desafio, talvez um cliente confuso e agressivo na comunicação com o time, e tantas outras possibilidades. Por isso que não adianta aumentar a carga horária, aumentar o time, o resultado será potencializar a dinâmica impropria.

Para ser ágil, ou simplesmente funcional, como citado no início do artigo, se faz imprescindível ter um líder experiente, um time bem preparado ou como o mercado costuma classificar: um time sênior. Agilidade não é para principiantes.

“Agilistas” são essencialmente aristocráticos, são preparados para se adaptar, para se adequar objetivando o resultado do projeto. Os praticantes de métodos ágeis devem se responsabilizar em mover tudo ao encontro do “verdadeiro bem”, conforme Platão (filósofo e matemático do período clássico da Grécia antiga - 428 AC a 347 AC) definiu a missão de um aristocrático. Ainda conforme Platão, aristocrático é um sábio, um virtuoso, um indivíduo preparado para liderar.

O líder tem o seu segundo corpo em seus dirigentes e colaboradores imediatos, são as suas mãos de confiança. Um indivíduo participante do projeto, chefe ou não, se não tem a fidelidade do seu grupo de trabalho cedo ou tarde é eliminado. A dinâmica de rejeição de um time é similar ao efeito de um câncer no corpo humano, vai apodrecendo os pontos vitais até a fatalidade.

Adaptando-se para utilizar métodos ágeis é mudar a compreensão sobre a relevância do ser humano no projeto. Os diversos efeitos são oriundos da mesma causa. O indivíduo preparado e adaptável é o diferencial. O time é mais importante que o método, que o controle, que o plano inicial. A relação entre todos os participantes, a comunicação entre todos os interessados, tudo isso já é efeito da dinâmica dos indivíduos desta empresa, desta corporação, deste projeto.

Após a compreensão desta leitura, desejo o sucesso em seus projetos.

Referência Bibliográfica:

  • MENEGHETTI, A. Psicologia Empresarial. 1ª. Edição. São Paulo, SP: FOIL, 2013.
  • SCHWABER, K. Agile Project Management with SCRUM. 1ª. Edição. Redmond, WA: Microsoft Press, 2004
  • HIGHSMITH, J. Agile Project Management. 1ª. Edição. Boston, MA: Addison-Wesley, 2004
  • ANDERSON, D. Agile Management for Software Engineering. 2ª. Edição. New York, NY: Prentice Hall Editora, 2004
  • COCKBURN, A. Agile Software Development. 2ª. Edição. Boston, MA: Addison-Wesley, 2007
  • BROOKS JR, F. The Mythical Man-Month. Anniversary Edition. Boston, MA: Addison-Wesley, 1995

Veja também