Skip to content
Gestor de Projetos estudando sobre Agile e Anti-Ágil, digitando com um relógio de pulso para ilustrar o artigo

O anti-ágil: quais as práticas que te afastam do Agile

No mercado de desenvolvimento de software, muito se fala em agilidade e seus princípios. Temos também papéis dentro da organização ficando mais comuns, como: agilistaagile coach, agile máster, entre outros derivados da “agilidade”. 

Pois bem, aqui gostaria de falar o que não é ser ágil. Polêmico, certo? Bom, a ideia aqui é comentar a respeito do que eu vivenciei na prática. Contarei situações em que as pessoas pensaram que se encaixavam em ágil, mas não eram de fato. 

Entregas contínuas: é preciso focar aonde quer chegar 

Em um dos princípios de agilidade falamos sobre entrega contínua. Você já se deparou com a situação onde era imaginado apenas o processo de como seria a entrega, e não o fim do projeto?  

É, eu sei, algumas vezes podemos cair na cilada onde esquecemos que parte da jornada é o fim, como diria nosso querido Iron Man, e pensamos apenas na próxima entrega. Esquecemos do propósito de toda aquela solução ser construída. Aprendemos com Alice no Pais das Maravilhas que precisamos ter clareza de qual é a missão e onde queremos chegar, senão qualquer caminho serve. 

Requisitos: detalhes não podem ser nem demais, nem de menos 

Palavra pequena, porém, poderosa… Pode parecer meio clichê o que vou comentar, mas sempre que olho para um requisito, eu penso: “Equilíbrio”.  

No dia a dia, o time em sua maioria vai querer saber detalhadamente o que deve ser feito. Já o cliente, na maioria das vezes, vai achar que um documento simples que ele possui, ou até uma reunião com ele, pode ser o suficiente para se estimar e começar a desenvolver. Pois bem, e agora? O que faremos?  

Bom, o que tive na prática e deu certo foi buscar o equilíbrio em detalhar minimamente o que se espera, o que deve ser feito e como a aplicação irá se comportar, agrupando por módulo pensando em evitar ao máximo o retrabalho 

Excesso de detalhes ou pecar em informações pertinentes não ajudará em sua agilidade, pois um se tornará um moroso e com excesso de informação, e o outro provavelmente irá te gerar um retrabalho. 

Sempre que vejo a palavra requisito me norteio por meio de uma frase do finado General Patton, atuante na segunda guerra mundial: “Um plano razoavelmente executado hoje é melhor que um plano que sempre fica para a semana que vem. 

Mudança: ela sempre vem, então como amenizá-la? 

Falar em mudança sempre pode causar desconforto, pois normalmente na prática podemos ter retrabalho, desgaste numa negociação, busca por culpados ou quem errou no processo…O que na minha visão não seria ágil.  

Envolva o time e pergunte: como resolvemos isso? A única coisa que você pode ter certeza em um projeto, por mais detalhado que ele seja, é que algo vai mudar sim. Seja escopo, pessoas designadas a uma determina tarefa ou o tempo estimado será maior ou menor. Caso contrário, meu querido amigo, algo muito errado está no seu processo e talvez de fato ele seja anti-ágil.  

Ok, então o que seria ser ágil na sua visão em relação a mudança?  

Pois bem, primeiro foco na missão e ver a mudança como uma bela oportunidade de puxar o freio e refletir, rever os conceitos e caminhos que pensamos antes de começar, pois também mudar por mudar não faria sentido. 

 

Conclusão 

Ser ágil em minha opinião, é: 

  1. Ter clareza e foco na missãoou seja, onde queremos chegar? 
  2. Confie no time e gere entrosamento, o como são eles quem definem! 
  3. Ter maneira simples de como vou medir se estou no caminho certo; 
  4. Regras do jogo bem definidas. 

 

Pode não ser fácil, mas é simples evitar ações anti-ágeis. 

Graduado em Análise de Sistemas pela FATEC, especialista em Gerenciamento de Projetos práticas PMI pelo SENAC, Profissional Técnico Certificado em Gerenciamento de Projetos®(CAPM) e Profissional Certificado para Engenharia de Requisitos (CPRE-FL).

Comments (1)

  1. Ótimo artigo Cassio, mudanças serão sempre bem-vindas, aproveito para completar que, como profissionais ágeis devemos criar códigos que sejam fáceis de se alterar no futuro, justamente por causa das mudanças de escopo de projeto, que é frequente.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

O Tech Journey é o blog da DB1 Global Software. Focado em informações sobre o mercado de tecnologia, é feito com a participação de colaboradores e convidados.

Redes Sociais

Política de Privacidade

Canal de Ética

Uma Marca:

Selos e certificados:

Back To Top