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: agilista, agile 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 País das Maravilhas que precisamos ter clareza de qual é a missão e aonde 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 e 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, é:

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

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