Nesta segunda parte de um painel virtual sobre o estado do Agile, veja a opinião de dez especialistas sobre a adoção de técnicas ágeis e seus desafios, além de conhecer opiniões sobre quando o Agile não é a melhor solução.
Se uma empresa pretende adotar Agile, por onde recomenda começar?
A parte mais complexa para que o Agile dê certo é a motivação das pessoas. Então acho que informações sobre Agile, e um bom papo com as pessoas sobre o que esperar em relação a mudanças, devem ajudar a adoção.
Sugiro três dicas para os que quiserem começar com um projeto piloto:
- Escolha um projeto complexo. Para projetos simples, qualquer metodologia funciona. A solução iterativa é muito melhor que a analítica justamente quando o problema é complexo; pergunte a um matemático!
- Escolha um time comprometido e que acredite nos valores ágeis;
- Estabeleça o processo de melhoria contínua, deixando claro o espaço para experimentação.
E destaco três pontos de atenção:
- O Product Owner tem que ter a disponibilidade necessária com foco no feedback do produto e na priorização;
- A interface entre o time ágil e o mundo não ágil (interno e externo) é onde acontecem os problemas;
- Evite o "Scrum flácido", em que não há práticas ágeis de desenvolvimento tão presentes no XP, como a integração contínua e testes automatizados.
Sugiro iniciar implantando os valores e princípios, juntamente com o processo do framework. Depois que esses aspectos amadurecerem, pode-se partir para tratar de questões como processos internos ou formas de vender projetos com Scrum; ou ainda, como usar contratos para amadurecer a colaboração com clientes e fornecedores.
Recomendo começar pela essência, que é a questão cultural, também relacionada com a atitude. Considero também fundamental que um time realize eventos de retrospectiva, criando com isso uma cultura de melhoria contínua. Desse modo, de forma sistemática as equipes vão poder questionar o que estão fazendo que não está tão bom e buscar opções para melhorar. É nesse ponto que outras práticas irão começar a fazer parte do dia a dia das equipes. Na minha opinião, agilidade é atitude, foco em entrega de software, trabalho em equipe e melhoria contínua.
Adotar Scrum é uma boa forma de começar, para que logo em seguida sejam adicionadas novas técnicas de engenharia ágil, fundamentais para apoiar os novos estágios de evolução das equipes e dos projetos.
Contudo, é importante entender quais são esses estágios de evolução em uma transição para o Agile; entender que, inicialmente, a capacidade de entrega das equipes será reduzida, para só após algum tempo atingir novos patamares. Deve-se estar disposto a pagar esse preço; caso contrário, a agilidade será logo substituída pelo caos.
Um erro comum em empresas de vários portes é selecionar projetos irrelevantes como piloto de adoção do Agile. Isso é um erro, porque as interações mais complexas entre as pessoas e processos da empresa somente ocorrem em projetos relevantes. Creio que a melhor maneira de começar é selecionar um projeto com risco gerenciável e que seja realmente importante para a empresa. Além disso, é essencial ter pessoas interessadas nesse projeto e com abertura para aprender, na prática, como aplicar o Agile.
Recomendo que a adoção se inicie pela gestão executiva e os "stakeholders" (ex.: executivos, alta gerência), deixando-os imersos nas vantagens e benefícios da utilização do Agile. Depois deve-se propagar para gestores de projetos e equipes de desenvolvimento. Se não há um consenso com a gestão executiva, fica difícil você sozinho propagar a ideia, principalmente em empresas médias e grandes.
Como abordagem baseada em coaching, sempre busco fazer as pessoas entenderem qual sua maior "dor", ou então qual a causa-raiz dos seus principais problemas organizacionais. Uma vez que as pessoas tomam consciência dessas questões, fica mais natural e menos prescritivo definir por onde melhorar dentro de uma empresa.
Sugiro procurar responder todo dia a pergunta, "O que é preciso melhorar aqui hoje?". Ser honesto em reconhecer os próprios problemas é muito importante, e nenhum consultor vai poder fazer isso tão bem quanto a própria equipe. Depois de um tempo fazendo isso, com a casa em ordem e um caminho vislumbrado, vai ser muito mais fácil adotar técnicas mais avançadas e obter ganhos genuínos com a ajuda de terceiros.
Na sua opinião, existe alguma situação em que técnicas Agile não devam ser adotadas?
Heitor Roriz Filho
Penso que os valores do Agile podem e devem ser aplicados a qualquer realidade de projetos. As técnicas, porém, talvez não se apliquem. Ainda tenho certa dúvida sobre a aplicabilidade do Agile em projetos envolvendo muito software embarcado e desenvolvimento de hardware, mas estou iniciando um trabalho com um pesquisador da Georgia Tech no qual temos como objetivo encontrar oportunidades para aplicar Scrum em projetos de design e construção de aeronaves. Até agora, os resultados foram promissores.
Rafael Prikladnicki
Sempre digo nos meus cursos que é muito difícil não usar métodos ágeis na maioria dos casos, mas não apenas métodos ágeis. Acho que a primeira pergunta a se fazer é: qual é o meu problema? Isso vai guiar um conjunto de respostas, que hoje acabam envolvendo métodos ágeis na maioria dos casos, pela própria natureza dos projetos de desenvolvimento de software.
Rodrigo de Toledo
Não existe uma linha exata, a partir da qual se pode afirmar que não é possível adotar métodos ágeis. Existem projetos em que de fato não faz sentido flexibilizar o escopo; por exemplo, quando a NASA manda um robô para o espaço. Mas existem projetos e empresas em que os métodos ágeis caem como uma luva. Finalmente, há aqueles projetos em que Agile não faz muita diferença. Na computação, não existe bala de prata, como nos ensinou Frederick P. Brooks. Seja qual for a metodologia ou linguagem, desenvolvimento de software sempre será complexo.
Daniel Wildt
Acho que sempre é possível buscar técnicas para minimizar riscos, gerar mais visibilidade, e falhar mais rápido se for o caso, validar ideias de forma mais efetiva, e por aí vai. Então, independentemente do ambiente, alguma prática ágil vai fazer sentido. E existindo a possibilidade de se trabalhar a melhoria contínua, vai se ganhando espaço para testar e adotar e adaptar outras técnicas.
Paulo Rebelo
Sem dúvida, existem contextos em que o Agile não se aplicaria. O que mais tenho visto que não funciona é quando as pessoas não estão maduras o suficiente para aceitar os valores e princípios do Manifesto Ágil; a empresa não está preparada a assumir uma mudança cultural; a gestão executiva não incentiva e não apoia a adoção; enfim, é difícil lutar contra a maré, apesar de os agilistas serem os agentes de mudança.
Julio Faerman
O Agile não deve ser adotado onde não existe honestidade. Se você ou a equipe não é capaz de dizer "Não sei exatamente quanto vai levar" ou "Não consigo fazer isso hoje, vamos conversar mais amanhã?", ou ainda, "Não podemos publicar isso sem testar"... ou seja dizer o que é verdade frequentemente em software, então é melhor nem fazer Agile. Se for esse o caso, melhor ficar no jogo do "vale o que está escrito" e deixar os advogados brigarem.
Manoel Pimentel
As técnicas são somente a ponta do iceberg; fazer com que as pessoas compreendam e vivam os valores ágeis é muito mais complicado. Mesmo assim, não vejo situações onde o Agile não seria recomendado.
Sempre termino vendo vantagens, com base em minhas experiências, até em situações em que elas seriam menos percebidas; por exemplo em contextos onde a empresa adotante não precisa ter vantagem competitiva em seu mercado, ou então, quando a empresa interessada em adotar Agile não consegue ver o real motivo para fazê-lo (oriundo de dor ou desejo de melhoria).
Na verdade, uma das primeiras questões a serem respondidas por organizações interessadas em Agile é: Qual o real propósito em termos um processo ágil?
Fernando Ultremare
Modelos baseados em feedback, como é o caso das técnicas ágeis, em que a resposta à mudança é mais importante que a definição de um plano detalhado, vão apresentar melhor desempenho que outras técnicas quando aplicadas em ambientes complexos. Em se tratando do desenvolvimento de sistemas de software, essa é a regra e não a exceção.
Mas quando saímos do âmbito da solução do problema e entramos em questões comerciais, contratuais e políticas, a extensão da adoção de técnicas ágeis será limitada, uma vez que o projeto fica condicionado a um conjunto de regras que não favorecem a adaptação. Um exemplo clássico é a adoção de técnicas ágeis em projetos de escopo fechado, em que o estabelecimento de uma velocidade sustentável da equipe fica dificultada pelas questões contratuais.
Se seu ambiente não é propício para adotar técnicas ágeis no nível do time, faça-o no seu trabalho pessoal, no nível individual. Seus resultados pessoais podem ajudar a mudança de perspectiva dos outros. Pensando assim, não creio que exista situação em que o Agile não deva ser usado, apenas deve haver um ajuste à realidade e uma perspectiva de longo prazo para mudanças.