Muito tenho escutado neste últimos dias sobre a questão do sucesso ou não do uso de metodologias ágeis.Principalmente com relação a entregas. Primeiro preciso dizer que não sou um doutor no assunto, nem pretendo ser, muito menos um profundo conhecedor, mas considero que tenho uma pequena vivência no assunto que me permite tecer alguns comentários sobre o assunto.
Uma das coisas que vejo que o pessoal parece não entender em minha humilde opinião, é que usar metodologia ágil você irá entregar o sistema mais rápido que usando waterfall, por exemplo. O que acontece que, primeiro, você foca no retorno ao investimento: isso significa dizer que você irá entregar não tudo desejado mais o que tiver mais valor para o seu cliente. Isso por si só já garante, na maioria dos casos, um cliente satisfeito, pois num tempo menor ele tem um produto perto do valor desejado. Outra coisa que o ágil faz, novamente em minha visão quase sem querer, é quebrar a entrega em partes. Isso faz com que o cliente tenha uma sensação melhor pois sempre tem um coisa nova chegando, uma entrega contínua. O ágil prega essa quebra pois ele acredita que nunca se sabe de partida exatamente o que se quer e a medida que vamos vendo a coisa aparecer que temos maior clareza de objetivo e com isso vamos adaptando durante a caminhada o nosso objetivo. Um replanejamento contínuo.
A questão que ao focar nas funcionalidades que darão maior retorno imediato para o investimento fica uma brecha para um possível erro que pode ser fatal para a sobrevivência da agilidade. Isso porque, o cliente, ou o representante do cliente, devido a um lista de coisas a fazer grande, pode se dar por satisfeito por algo que ainda está incompleto e que, pode e deve ser melhorado dependendo do negócio do produto.
A percepção desse problema está muito ligada ao tipo de negócio que estamos trabalhando. Pode ser que seu cliente só sentirá falta do resto daqui a anos e assim, sem criar grandes traumas, irá solicitar as evoluções e todos seguiremos com nossas vidas felizes e satisfeitos. A coisa piora quando estamos num mercado extremamente competitivo e cujo o peso da inovação é muito grande. Mercados onde o tempo certo faz toda a diferença entre o sucesso e o fracasso tende a aumentar em 100 vezes conflitos dessa natureza.
Voltando ao que eu disse lá em cima, não acredito que ser ágil me faça entregar mais coisa em menos tempo; acredio que ser ágil me faz entregar mais valor em menos tempo. Isso faz toda a diferença. Mas quando não respeitamos a natureza incremental do processo imbutimos uma falha nele. E não adianta dizer no futuro que o problema está no processo pois “você” o subverteu. Novamente. em muitos desses casos, o que o ágil sempre acaba fazendo é mostrar esse problema e deixá-lo evidente.
A questão que ao colocarmos um produto no ar, restrigindo mais a nosso mundo de ti e a um mercado de web, o quanto antes possível com o maior valor possível, não significa que ele esteja pronto. Significa que nosso primeiro ciclo fechou. Precisamos seguir. Continuar a incrementar nossa aplicação e, em conjunto com o cliente, criar uma coisa única para o usuário. Parar no primeiro passo e o mesmo que não fazer. Vai ficar a sensação de incompleto.
Outra coisa é que quando decidimos por entregar coisas em menos tempo o fazemos por que queremos um retorno rápido. Por meio desse retorno rápido iremos ajustar nossos processos e objetivos para melhorar ainda mais o produto. Se apenas lançarmos e partirmos para fazer outra coisa estamos perdendo uma excelente oportunidade de realizar a milha extra que todos os clientes sonham.
Sei que convencer o cara que assina o cheque que antes de partimos para o próximo projeto deixe a gente invistir mais um pouco de tempo no atual é difícil. Na cabeça dele o prédio está lá e por isso a obra terminou. Mas TI não é construção de prédios… ela é mais parecida com pintura de quadros. Uma vez li ou ouvi ou vi (não sei) que um artista nunca termina nada, ele a abandona pois, sempre acredita que possa melhorá-la. Isso não significa que a partir de agora todos nós vamos abandonar nosso projetos (não se matem ainda clientes). Significa dizer que a primeira versão nunca deve ser a definitiva. Ela por si só é inacabada. Precisa de um novo ciclo.
Somente temos idéia das interações das cores num quadro depois de pintá-lo. A experiência nos ajuda a antecipar o conhecido mas sempre teremos novidades. Sempre teremos novos usos a descobrir, etc.
Parte dessa confusão reside num mal entendimento motivado por nós. Vendemos que quando usamos Scrum, Lean, ou qualquer outra nome de processo, seremos mais rápidos, mais produtivos, maior qualidadde. Vendemos um contexto utópico. Só esquecemos de dizer que isso acontece por um processo de reciclagem. Isso mesmo reciclagem. Criamos, colocarmos no ar, coletamos os dados, esmagamos e refazemos tudo. Porém nosso cliente, que ainda possui requícios de waterfall, pensa que tudo estará na primeira entrega. Ele ainda não concebe que precisamos de mais indas e vindas.
![PythonBrasil[6]](http://www.python.org.br/banners-pythonbrasil/countdown_rectangle.gif)
http://blogblogs.com.br/
Olá.
muito interessante os assuntos abosdados em seu blog, passará a ser uma referência a mim.
Eu venho a algum tempo implantando integração contínua na Empresa onde trabalho, sendo, assim estou agora planejando inserir o uso do MS Project e uso do Jira controle de issue.
Nós já utilizamos algumas práticas do Scrum, mas sem embasamento técnico na metodologia, o desenvolvimento é ad-hoc, gostaria de saber se poderia me indicar fóruns que tratam do assunto Gerenciamento de Projetos e afins.
obrigado.
Renato, primeiramente recomendo ler algo sobre assunto. Tem vários livros sobre Scrum. Outra fonte é a internet mesmo. No Brasil tem bastante gente boa escrevendo coisa super interessante sobre processos ágeis. Acredito que para projetos de TI a gestão ágil seja melhor do que PMI e afins. Dada a natureza mutante da coisa tentar fechar escopo é quase um tiro no pé. Isso é minha opnião.
Dá uma olhada no link do site para que veja mais sobre o assunto.