Outsourcing e proteção de dados: cinco estratégias que toda empresa de tecnologia precisa considerar
Nos últimos anos, o modelo de trabalho em outsourcing tem ganhando cada vez mais defensores…
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.
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.
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”.
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.
Ser ágil em minha opinião, é:
Pode não ser fácil, mas é simples evitar ações anti-ágeis.
Ó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.