No post anterior escrevi sobre alguns padrões para adoção de agilidade em um ambiente de desenvolvimento de software. Falei também que desta vez estamos utilizando uma abordagem utilizando os padrões Public Display of Agility e Iterative First, além do Start Small.

A utilização dos dois primeiros padrões impôs desafios diferentes dos encontrados na utilização dos padrões Stealth Mode e Technical Practices First (minha experiência anterior).

Uma das principais diferenças é que, por o Stealth Mode não chamar muita atenção, você tem mais liberdade para aplicar as práticas da maneira que achar melhor. Não precisa responder a muitas perguntas e nem assume de ante mão compromissos externos. Ou seja, pode trabalhar de forma bastante eficiente e não encontra muitas resistências.

Indo para o Public Display of Agility, entretanto, você estará chamando bastante atenção (como o próprio nome do padrão sugere) e, por metodologias ágeis ainda estarem longe de ser unanimidade, um certo jogo político tem que ser levado adiante. Um lado positivo é que você acaba ganhando o patrocínio das várias partes envolvidas, mas esse patrocínio as vezes vem com um preço um pouco alto. Por exemplo, algumas práticas ainda são encaradas como “muito radicais”.

Com Technical Practices First, a pesar de certas práticas “técnicas” serem bem difíceis de se dominar e possuírem certas dependências entre si, não é tão difícil sair da inercia. Por exemplo, se o time decide começar a fazer testes de unidade ou adotar integração contínua, existem disponíveis uma grande quantidade de material bem ao estilo “receita de bolo” e ferramentas bem simples de se trabalhar. Claro que leva-se algum tempo para se começar a trabalhar corretamente e entender o espírito da coisa, mas a sensação de estar perdido não é tão grande.

Porém, se o time decide ir pelo Iterative First, a adoção deve ser levada com mais cuidado e deve-se ter uma grande sensibilidade de como as práticas se encaixarão e principalmente mudarão a cultura da empresa. As primeiras práticas que serão abordadas são as gerenciais; e de gerência de projeto todo mundo entende um pouco, ou acha que entende Ou seja, é bem mais fácil encontrar resistências: infelizmente ainda há muita gente que acha que desenvolvimento de software deve ser feito de forma prescritiva e que devemos adotar as mesmas práticas gerenciais de outras engenharias. Também existem pessoas bem abertas a mudanças e enxergam as vantagens na aplicação de práticas ágeis, mas, por não terem um background sólido, não conseguem digerir os reais valores do Manifesto Ágil.

Ficamos então com o desafio de adotarmos como base uma metodologia de desenvolvimento ao mesmo tempo eficiente e que levasse em consideração todo esse cenário. Foi aí que o OpenUP se encaixou como uma luva às nossas necessidades:

• É um processo bastante enxuto e se encaixa bem em um contexto ágil (a gestão do projeto é quase que uma cópia do SCRUM). Práticas de outras metodologias também podem ser facilmente encaixadas no processo

• Por ser um Unified Process, traz possui conceitos que muitos já estão acostumados, diminuindo a resistência inicial:

• É iterativo e incremental

• É Baseado na utilização de casos de uso

• Desenvolvimento centrado na arquitetura do projeto.

• Possui foco em gestão de risco

• Mesmo sendo bem enxuto, engloba (quase) todas as disciplinas de software: Arquitetura, Gestão de Projeto, Gestão de Configuração, Desenvolvimento, Gestão de Requisitos e Testes

• Mesmo tendo que ser adaptado para a nossa realidade, é um processo que já está pronto para ser utilizado, contém um bom conjunto de práticas e artefatos, já com templates e “boas práticas” documentados

• Está todo documentado no EPF

• É disponibilizado através da Eclipse Public License: pode ser utilizado sem restrições.

OpenUP contém todas as melhores soluções para desenvolvimento de software? Acredito que não. Mas com essas características foi a solução salomônica para este momento inicial. Ainda estamos no começo (Start Small) e é difícil já fazermos algum jugamento da escolha, mas acredito que estamos no caminho certo, principalmente porque acabamos ganhando o apoio de muita gente boa.

É importante também ficar claro que a mudança de cultura de um ambiente não se trata somente de um mudança no processo ou metodologia de desenvolvimento e é um fator que também deve ser levado em conta, tendo desafios ainda maiores.

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.