Antes de começar o post quero deixar claro que não sou contra metodologias ágeis, muito pelo contrario a 6 anos que adotamos vários princípios ágeis para trabalhar na equipe que gerencio (Basix).
No inicio do projeto Basix há 6 anos (Novembro de 2004) decidimos adotar a transparência como pedra fundamental da parceria que estava surgindo para desenvolver o novo produto, a Voice entrou como Desenvolvedor, e nosso parceiro uma operadora de telefonia Japonesa como investidor, uma das discussões que tivemos com o saudoso professor Antonio Mesquita foi sobre como lidaríamos com os bugs do sistema que estávamos começando a desenvolver, havia duas opções:
- A primeira abrir a cozinha e possibilitar o parceiro investidor ver todos os bugs, criticar, priorizar, questionar, etc.
- A segunda abrir a lista de problemas somente com a entrega de uma versão, e deixando o parceiro longe do processo de desenvolvimento.
A nossa foi decisão por abrir a cozinha (o professor Mesquita foi determinante nesta decisão), pois queríamos ser o mais transparente possível nesta nova parceria, havíamos até criado uma conta corrente específica para movimentar todo o dinheiro do projeto, então porque não abrir a cozinha do nosso desenvolvimento.
Naquele momento ainda não tínhamos muito contato com o Scrum (na verdade o próprio Scrum estava começando), mas este principio que adotamos tinha na verdade o intuito de trazer o parceiro para dentro do processo de desenvolvimento uma das bases do Scrum (e de qualquer outra metodologia agil).
Após o projeto ter chegado ao seu final (estamos em fase de operação deste produto), hoje posso olhar para trás e ver que o nosso parceiro não estava preparado para este modelo, a questão da cozinha aberta neste projeto gerou muitos desgaste, a cada novo bug detectado por nós no processo de desenvolvimento, para nós era uma alegria pois sabíamos que detectamos um problema antes de o software está sendo utilizado pelo cliente, já para o nosso parceiro a visão muitas vezes era pô este software não está legal toda hora o pessoal de testes encontra bug.
E para piorar um pouco este processo as pessoas do nosso parceiro são Japoneses e moram no Japão, e o Japonês não tem o costume de questionar, de falar o que pensa, estamos a milhares de quilômetros do Japão, e com uma diferença de fuso horário de 12 horas, por conta disto tudo demoramos muito para detectar este GAP entre as visões dos dois lados.
O projeto de desenvolvimento com este parceiro foi finalizado em Novembro de 2009, no momento continuamos desenvolvendo o Basix por demandas do mercado, e parceiros Brasileiros, mas esta questão dos bugs (product backlog do Scrum) não foi o fator preponderante para a finalização do projeto de desenvolvimento com este parceiro Japonês, mas com certeza foi um gerador de desgaste desnecessário para o processo como um todo.
Por isso que digo Agile não é para todos e em todas as circunstâncias, antes de implementar um método Ágil veja se todos os envolvidos estão preparados, e caso não esteja avalie se é possível criar interfaces para possibilitar a utilização de métodos Ágeis no desenvolvimento, e continuar se relacionando com o cliente de uma forma mais tradicional, neste caso o Product Owner deverá ser o responsável por gerenciar esta interface.
Gostaria de chamar o pessoal que participou do projeto para deixar o seus comentários é muito importante temos outras visões deste processo, para aprendermos e em próximos projetos melhorarmos!
Abraços,
Antonio Anderson Souza
agile · basix · metodologia · scrum
Agile não é para todos! - Antonio Anderson Souza · 07/03/2010 at 13:23
[...] 0 Comments | Posted by antonioams in basix, voice technology Este post foi publicado por mim no Blog da Voice Technology. [...]
Fabrício Ferrari de Campos · 07/03/2010 at 16:11
Concordo Antonio, quando você diz que “Agile não é para todos”, não é mesmo, e diria ainda, que vendo a realidade das empresas hoje (por meio de eventos, discussões, conversas com outros profissionais, etc) Agile é para poucos.
Mas agora falando especificamente do projeto Basix, que tive o enorme prazer de participar (não tô falando isso porque o blog é da Voice não [rs], e sim porque o projeto era um desafio e tanto e pude aprender MUITA coisa no pouco mais de 1 ano que participei), analisando com os valores ágeis do Manifesto Ágil:
- “Individuals and interactions over processes and tools” -> sem dúvidas o valor mais praticado pela equipe do Basix!
- “Working software over comprehensive documentation” -> mais um valor, que foi praticado no projeto, talvez não da maneira mais correta, mas a geração de documentação realizada, tinha como foco o cliente;
- “Customer collaboration over contract negotiation” -> esse é um valor, que depende dos dois lados, e no caso do Basix, havia ainda a dificuldade da distância e a cultura ser bem diferente;
- “Responding to change over following a plan” -> no tempo que estive no projeto, vi esse valor se praticado muitas vezes.
Nessa breve análise, acredito que conseguimos tirar bons resultados com a tentativa de adotar Agile, logicamente, que tivemos problemas e nem todas decisões se revelaram as mais sábias no final, mas conseguimos enfrentar esse desafio e desenvolver um software que soluciona os problemas de muitos clientes.
Ahh Antonio, fique sabendo que um dos maiores obstáculos quando implantamos Agile é conseguir colocar em prática o terceiro valor (“Customer collaboration over contract negotiation”), aqui no Brasil por exemplo, muitos clientes gostam de “barrigar” as coisas.
Abraços!
Author comment by andre · 07/03/2010 at 16:38
Belo post Antonio.
E muito boa a comparação Fabrício.
Falando especificamente do projeto do Basix, onde participei efetivamente só no final, adicionaria mais alguns itens:
- Demorávamos para conseguir uma definição clara do que deve ser feito (Product Backlog). As vezes ficávamos discutindo itens mais técnicos e não definíamos o Backlog.
- Testávamos muito, mas na maioria das vezes de forma manual. E como o cliente não via o quanto testamos, quando acontecia algum problema, achava que não havia sido feito teste. Se a gente tivesse produzido mais testes automatizados poderíamos ter conquistado um pouco mais de confiança do cliente.
Etá bem legal este blog da Voice!
Author comment by antonio · 07/03/2010 at 16:57
Obrigado pelos comentários André e Fabricio, muito bem colocado todos os pontos que vocês levantaram.
Fernando Fontes · 09/03/2010 at 13:07
Antonio, agile não é para todos mas mesmo quando o cliente não está preparado os frutos chegam, eu me lembro do que aconteceu com projetos grandes que não adotaram agile por lá: morreram antes de nascer.
Author comment by antonio · 09/03/2010 at 19:13
Fontes,
Obrigado pelo comentário e também concordo com a sua colocação, inclusive eu recebi um comentário (via email) do nosso parceiro relativo a este post que fiz, e no comentário o mesmo dizia que a transparência foi bem produtiva sim, mas forma com que a informação chegava e para quem que foi fonte de desgaste (nem todos que recebiam as infos estavam preparados para tal).
Por isso que eu sou totalmente a favor, Agile Sempre!!! o único detalhe é ver qual é melhor forma de mostrar a agilidade para o cliente, cada um pode demandar uma forma especifica.
Abraços,
Antonio