Mesmo com sua adoção crescendo ano a ano e comprovadamente trazendo ganhos de produtividade para projetos de desenvolvimento, metodologias ágeis ainda encontram bastante resistência e ainda tem uma adoção relativamente pequena aqui no Brasil. Existiria então uma forma mais indicada de transição para uma abordagem ágil de acordo com as características de cada ambiente?
O Mike Cohn documentou alguns padrões interessantes para adoção de agilidade e os dividiu em três pares antagônicos que são:
- Start Small ou Go All In?
Começar a adoção com um projeto piloto ou já começar com a grande maioria dos projetos da empresa?
- Technical Practices First ou Iterative First?
Focar primeiramente nas práticas de engenharia ou nas práticas de gestão?
- Stealth Mode ou Public Display of Agility?
Serão esperados os primeiros resultados para que a adoção seja tornada pública ou ela será divulgada de ante mão?
Dentre estes padrões, o caminho mais seguro e menos traumático é a combinação de Start Small, Technical Practices First e Stealth Mode. Foi essa combinação que funcionou muito bem em meu emprego anterior e, encontrando as mesmas condições, tentaria adotá-la em qualquer outro ambiente.
Adotando Start Small e Technical Practices First não se precisa de tanto apoio das hierarquias superiores e conseqüentemente pode-se atuar sob Stealth Mode. Como, até meio que paradoxalmente, as hierarquias superiores são as que menos conhecem e mais resistem às abordagens ágeis, o time pode evoluir sem encontrar muitas resistências nos estágios iniciais e, principalmente, sem ser talhado pela equipe de “qualidade”. Claro que vai chegar um momento em que o apoio será necessário, porém os resultados já alcançados servirão de prova de que desenvolvimento ágil não é coisa de adolescente frustrado ou programador revoltado.
Essa combinação, no entanto, possui um lado negativo considerável: é a mais lenta. Adotando-a, demoramos em torno de três anos para que começássemos a ter um impacto organizacional mais abrangente (demora também ocasionada pelo tamanho da empresa), mesmo resultados positivos tendo estado presentes desde os primeiros meses. E a razão da sua vantagem é também o motivo da sua desvantagem. Sem o apoio corporativo, o time pioneiro sente dificuldades de levar a adoção adiante e depende muito de esforços homéricos dos envolvidos para que as dificuldades naturais da adoção não comprometam o andamento do(s) projeto(s), gerando ruídos e quebrando o Stealth Mode.
Seria então está combinação a mais indicada para todos os ambientes? Acredito que não. Algumas forças devem estar presentes para que esta combinação seja a mais indicada:
-
Já existe na empresa um processo de desenvolvimento “tradicional” bem estabelecido e controlado. Geralmente em empresas que tem ou buscam o selo CMMI e que acabam considerando abordagens ágeis uma ameaça para o processo de avaliação e controle de “qualidade”.
-
O time tem um perfil técnico muito bom, os membros são proativos e comprometidos na busca de melhores formas de desenvolver software.
-
Os integrantes do time devem, em grande parte, se manter constantes.
Aqui na SEFAZ, por termos outro cenário (com vantagens e desvantagens) estamos adotando outra estratégia, mais próxima da combinação Start Small, Iterative First e Public Display of Agility. O padrão Go All In traria resultados ainda mais rápidos, mas acho demasiadamente arriscado. O ponta pé inicial ainda não foi dado, mas estou animado com o comprometimento que estamos obtendo em todos os níveis e espero que em breve eu tenha boas notícias para dar.
Tags: Desenvolvimento Ágil, Processos de software
December 9th, 2008 at 7:18 pm
Grande post Fabricio!
Acredito que a sua primeira combinação seja algo “modesto”, porém bem prático e que com certeza traz motivação e entusiasmo para equipe do projeto.
Um dos grandes problemas realmente está no hierarquia [aka gestores], como você mesmo citou, eles dificultam a adoção de uma nova metodologia, e no final das contas a iniciativa na maioria das vezes acaba -deve- partindo dos desenvolvedores.
Acredito que a equipe é o elo mais forte para a adoção da metodologia agil entre as 3 forças que você citou e que realmente deve ser o mais trabalhado e motivado.
Enfim, grande post!
December 10th, 2008 at 9:41 am
Como o Ponte falou, e acrescentando…
A equipe tem que está consciente da importância e conhecer a fundo as metodologias que querem adotar. Se não vai ser muito complicado ter argumentos suficientes para convencer os gestores e principalmente provar a sua importância.
Outra coisa interessante e que devemos pensar é o que você citou sobre CMMI. Realmente empresas que querem adotar esse selo não querem nem ouvir sobre essas práticas, já que isso “poderá” atrapalhar o processo deles. É triste mas essa é a realidade do mercado, um mercado que se importa somente com selos.
Mas será que seria possível trabalhar com metodologias ágeis em uma empresa que tenta desesperadamente ter um CMMI da vida ?
Uma empresa totalmente engessada por processos e documentos ?
Eu vejo que os desenvolvedores podem adotar internamente isso, mas acho que mesmo assim ainda ficaram “presos” aos processos…
Abraços e excelente post.
December 11th, 2008 at 7:41 pm
Handerson, realmente é complicado trabalhar de forma ágil em uma empresa que cegue o CMMI. A equipe tem que ter jogo de cintura, mas as maiores dificuldades aparecem nas práticas gerenciais, por isso que o “Technical Practices First” dá mais certo nesse caso.
E quando começamos a adotar as práticas gerenciais, tivemos que “arrodear” um pouco o CMMI, umas das saídas foram:
- O planejamento “tradicional” com Gantt Chart, super-estimativas e etc era feito em um nível BEM abstrato para que não atrapalhasse muito. O planejamento e acompanhamento do dia a dia era feito no Mural mesmo
- O processo não permitia gastar esforço em implementação até que todos os requisitos estivessem extensivamente documentados, validados, verificados e assinados pelo cliente. Mas permitia gastar esforço em prototipagem. Então para ganhar produtividade nosso esforço em prototipagem era bem maior que o de implementação. Ficava meio estranho, mas passava.
- Mudanças de requisitos eram bem controladas e desencorajadas, então quando necessárias nós as implementávamos e deixávamos para fazer a parte burocrática (documentar análise de impacto, estimativa, replanejamento, etc) na entrega do módulo e juntando todas as alterações pedidas, ao invés de fazer uma por uma antes de começar a implementar.
Essas foram só algumas dentre várias saídas que conseguimos. É chato ter tanta dificuldade para fazer um trabalho produtivo, mas o sentimento era que sempre valia a pena e eram bem evidentes os ganhos de produtividade que tivemos.
January 5th, 2009 at 8:43 am
Grande Fabrício… Excelente post!
February 17th, 2009 at 1:49 pm
Olha aê o Fabridal!
Cara, massa esse post …
Comentários:
Ao meu ver, é excelente que parta primeiro do desenvolvedor a iniciativa de ir pro ágil (ou pra qq outro processo, seja unificado ou ágil), pq sem o patrocínio deste, nenhuma metodologia adotada terá sucesso facilmente.
Agora ver um desenvolvedor vibrando pra usar o RUP e usar os cento e trinta e poucos artefatos é um negócio raríssimo!
February 17th, 2009 at 2:54 pm
Pois é Israel. Talvez seja por isso que processos burocráticos e pesados estão caindo em desuso. Sem a motivação dos desenvolvedores a coisa fica realmente impraticável.
March 5th, 2009 at 7:07 pm
[...] post anterior escrevi sobre alguns padrões para adoção de agilidade em um ambiente de desenvolvimento de [...]