A Nova Metodologia

por Martin Fowler*

Provavelmente a mudança mais notável na ideia de processo de software nos últimos anos tem sido o surgimento da palavra ‘ágil’. Falamos de metodologias de software ágeis, de como introduzir agilidade em uma equipe de desenvolvimento ou de como resistir à iminente tempestade de agilistas determinados a mudar práticas bem estabelecidas.

Este novo movimento surgiu a partir dos esforços de várias pessoas que lidaram com o processo de software na década de 1990, querendo e procurando uma nova abordagem para o processo de software. A maioria das idéias não eram novas, na verdade muitas pessoas acreditavam que softwares muito bem sucedidos tinham sido construídos dessa forma por um longo tempo. Havia, entretanto, uma opinião que estas idéias tinham sido sufocadas e não foram tratadas com seriedade suficiente, particularmente por pessoas interessadas em processo do software.

Este artigo foi originalmente parte deste movimento. Eu o publiquei originalmente em julho de 2000. Eu o escrevi, como a maioria de meus artigos, como parte de tentar compreender o tema. Naquela época eu tinha usado Extreme Programming por vários anos depois que tive a sorte de trabalhar com Kent Beck, Ron Jeffries, Don Wells e acima de tudo o resto da equipe Chrysler C3 em 1996. Eu tinha tido conversas e lido livros com outras pessoas que tinham ideias semelhantes sobre o processo de software, mas não necessariamente queria seguir o mesmo caminho que o Extreme Programming. Então eu quis explorar quais eram as semelhanças e diferenças entre essas metodologias neste artigo.

Minha conclusão, à época, que eu ainda acredito agora, é que haviam alguns princípios fundamentais que uniam essas metodologias, e esses princípios tinham um contraste notável com as premissas das metodologias estabelecidas.

Este artigo continuou a ser um dos artigos mais acessados no meu site, o que significa que eu me sinto um pouco convidado a mantê-lo atualizado. Em sua forma original, o artigo explorou essas diferenças de princípios e forneceu um levantamento de metodologias ágeis conforme eu os entendia. Muito tem acontecido com métodos ágeis desde então para eu conseguir acompanhar a parte da pesquisa, embora eu forneça alguns links para que você possa continuar suas explorações. As diferenças de princípios ainda permanecem, e essa discussão eu mantive.

Do Nada, até o Monumental, até o Ágil

A maior parte do desenvolvimento de software é uma atividade caótica, frequentemente caracterizada pela frase “desenvolver e corrigir”. O software é escrito sem um planejamento básico, e o projeto do sistema é feito em cima de muitas decisões de curto prazo. Isso funciona muito bem quando o sistema é pequeno, mas a medida que o sistema cresce fica cada vez mais difícil de adicionar novas funcionalidades. Além disso, bugs se tornam cada vez mais predominantes e cada vez mais difíceis de corrigir. Um sinal típico desse tipo de sistema é uma longa etapa de testes depois que o sistema foi “desenvolvido”. Essa longa etapa de testes acaba com o planejamento pois é impossível planejar o tempo de testes e correção de bugs.

O movimento original que tentou mudar isso introduziu a noção de metodologia. Essas metodologias estabeleceram um processo disciplinado no desenvolvimento de software com o objetivo de fazer o desenvolvimento de software mais previsível e mais eficiente. Elas fizeram isso ao desenvolver um processo detalhado com uma forte ênfase no planejamento inspirado por outras disciplinas de engenharia — é por isso que eu prefiro me referir a elas como metodologias de engenharia (outro termo amplamente usado é metodologias orientadas a planejamento).

As metodologias de engenharia existem há muito tempo. Elas são conhecidas não por serem um tremendo sucesso. Elas são ainda menos conhecidas por serem populares. O criticismo mais frequente dessas metodologias é que elas são burocráticas. Existem tantas coisas a se fazer para seguir a metodologia que todo o ritmo do desenvolvimento de software diminui.

As metodologias ágeis foram criadas como uma reação a essas metodologias. Para muita gente, o apelo dessas metodologias ágeis é a resposta contra a burocracia das metodologias de engenharia. Esses novos métodos tentam ser algo entre não ter processo nenhum e ter muitos processos, fornecendo o suficiente para ganhar uma recompensa razoável.

O resultado disso tudo é que as metodologias ágeis possuem mudanças significativas na ênfase comparado com os métodos de engenharia. A diferença mais direta é que elas são menos orientadas a documentação, geralmente enfatizando uma quantidade menor de documentação para uma determinada tarefa. De muitas maneiras elas são orientadas a código: seguindo um caminho que diz que a parte chave da documentação é o código fonte.

Entretanto eu não penso que esse é o ponto chave sobre as metodologias ágeis. Falta de documentação é um sintoma de duas diferenças mais profundas:

• As metodologias ágeis são mais adaptativas do que previsíveis. As metodologias de engenharia tendem a tentar planejar uma grande parte do processo de software em muitos detalhes para um período longo de tempo, isso funciona bem até que alguma coisa mude. Assim a natureza delas é resistir a mudanças. As metodologias ágeis, entretanto, aceitam mudanças. Elas tentam ser processos que se adaptam e são bem sucedidas na mudança, mesmo até o ponto de mudar elas mesmas.
• As metodologias ágeis são orientadas a pessoas ao invés de orientada a processos. O objetivo das metodologias de engenharia é definir um processo que funcione bem independente de quem as estiver usando. Os métodos ágeis declaram que nenhum processo irá substituir as habilidades de um time de desenvolvimento, dessa forma o papel de um processo é dar suporte ao time de desenvolvimento no seu trabalho.

Nas seções seguintes eu vou explorar essas diferenças em mais detalhes, assim você vai poder entender como é um processo centrado nas pessoas e adaptativo, seus benefícios e desvantagens, e se você deveria usá-lo: seja como uma pessoa desenvolvedora ou como uma pessoa que vai consumir um software.

Previsível versus Adaptativo

Separação de Projeto e Construção

As inspirações habituais para metodologias são as disciplinas de engenharia tal como engenharia civil e mecânica. Tais disciplinas colocam muita ênfase no planejamento antes de você construir. Esses engenheiros vão trabalhar em uma conjunto de desenhos que de uma maneira precisa indicam o que precisa ser construído e como essas coisas precisam ser reunidas. Muitas decisões de projeto, tais como se deve lidar com a carga em uma ponte, são feitas quando os desenhos são produzidos. Os desenhos são então entregues para um grupo diferente, frequentemente uma empresa diferente, para então serem construídos. É suposto que o processo de construção seguirá os desenhos. Na prática os construtores vão encontrar alguns problemas, mas geralmente eles são pequenos.

Visto que os desenhos especificam as peças e como elas precisam ser reunidas, eles atuam como a fundação para um plano de construção detalhado. Tal plano pode definir as tarefas que precisam ser feitas e qual a dependência existe entre as tarefas. Isso permite a definição de um plano previsível e um orçamento para construção razoáveis. É também dito em detalhe como as pessoas executando o trabalho de construção devem fazer seus trabalhos. Isso permite o(a) construtor(a) ser menos experiente intelectualmente, embora eles(as) são frequentemente experientes com trabalhos manuais.

Deste modo vemos aqui duas atividades fundamentalmente diferentes. O projeto que é difícil de prever e necessita de pessoas criativas e caras, e a construção que é fácil de prever. Uma vez que o projeto está pronto, pode-se planejar a construção. Uma vez que o plano de construção está concluído, podemos então lidar com a construção de uma forma muito mais previsível. A construção na engenharia civil é muito maior tanto na parte de custos e tempo comparado com o projeto e planejamento.

A abordagem para as metodologias de engenharia de software se parecem com isso: queremos um plano previsível para poder colocar pessoas com menos habilidades. Para fazer isso precisamos separar o projeto da construção. Portanto precisamos descobrir como fazer o projeto de software tal que a construção pode ser simples uma vez que o planejamento está concluído.

Assim, qual a o formato deste plano? Para muitos(as), esse é o papel das notações de projeto tal como a UML, onde podemos criar uma plano de construção e então entregar esses projetos para os codificadores(as) como uma atividade da construção.

Mas aqui reside uma pergunta crucial. Você consegue criar um projeto que é capaz de transformar a codificação em um plano de construção previsível? Se sim, o custo de fazer isso é suficientemente menor para fazer essa atividade valer a pena?

Tudo isso traz algumas perguntas a minha mente. A primeira delas é a questão de qual a dificuldade de criar um projeto no formato UML em um estado que que possa ser entregue aos programadores(as). O problema com um projeto no formato UML é que este parece muito bom no papel, ainda que seja seriamente falho quando você for efetivamente programar a coisa. Os modelos que os engenheiros civis utilizam são baseados em muitos anos de prática que são consagrados em padrões de engenharia. Além disso, as questões chaves tais como as forças que interferem no projeto, estão sujeitas a análises matemáticas. A única checagem que podemos fazer em diagramas no formato UML é a revisão feita por outra pessoa. Enquanto isso é útil, leva a erros de projeto que são frequentemente somente descobertos durante as etapas de codificação e testes. Até mesmos projetistas experientes, tal ao qual me considero ser, são frequentemente surpreendidos quando transformamos tais projetos em software.

Outra questão é o comparativo de custo. Quando você constrói uma ponte, o custo do esforço de projeto é em torno de 10%, com o restante sendo construção. Em software a quantidade de tempo despendida em codificação é muito, muito menos. McConnel sugere que para um projeto grande, somente 15% do projeto é código e testes unitários, quase uma inversão perfeita da taxa de construção da ponte. Mesmo que você inclua todos os testes como parte da construção, o projeto ainda é 50% do trabalho. Isso levanta uma questão importante sobre a natureza do projeto em software comparado com o seu papel em outros ramos da engenharia.

Esses tipos de questões levaram Jack Reeves a sugerir que de fato o código fonte é um documento de projeto e que a etapa de construção é na realidade o uso do compilador e do linker. De fato, qualquer coisa que você pode tratar como construção pode e deve ser automatizado.

Esse pensamento leva a algumas conclusões importantes:

• Em software: a construção é tão barata que pode ser considerada de graça
• Em software todo o esforço está em projetar, e portanto precisa de pessoas criativas e talentosas
• Processos criativos não são fáceis de planejar, e por isso previsibilidade pode ser algo impossível de alcançar
• Nós devemos ser muito cuidadosos com metáforas de disciplinas tradicionais de engenharia na construção de software. É um tipo diferente de atividade e precisa de um processo diferente

A Imprevisibilidade dos Requisitos

Há um refrão que tenho escutado em cada projeto por qual passei. Os desenvolvedores vêm até mim e dizem que “o problema com esse projeto é que os requisitos estão sempre mudando”. O que acho surpreendente sobre essa situação é que alguém fique surpreso com ela. No desenvolvimento de software, mudanças nos requisitos são a norma, a questão é o que fazemos sobre isso.

Um caminho é tratar requisitos em mudanças como resultado de engenharia de requisitos pobre. A idéia por trás da engenharia de requisitos é obter um retrato dos requisitos completamente compreendido antes de começar a construir o software, fazer com que o cliente assine esses requisitos e preparar procedimentos que limitem alterações depois da assinatura.

Um problema com isso é que apenas tentar entender as opções para os requisitos já é complicado. É ainda mais difícil porque a organização que desenvolve normalmente não provê informações de custos dos requisitos. Por fim, você fica numa situação em que você pode ter alguma vontade de ter um teto solar em seu carro, mas o vendedor não consegue te dizer se são R$10,00 a mais no custo do carro ou R$10.000,00. Sem muita idéia do custo, como você pode imaginar o quanto você está disposto a pagar pelo teto solar?

Estimar é difícil por vários motivos. Um deles é que desenvolvimento de software é uma atividade de design, e assim, difícil de planejar e pôr um preço. Outro é porque a matéria prima muda rapidamente. Outro, ainda, é de haver uma dependência tão grande de quem está envolvido, e indivíduos não são facilmente previsíveis ou quantificáveis.

A natureza intangível do software também tem sua parte. É muito difícil enxergar o quanto de valor há em uma feature até que seja usada realmente. Somente quando se vê uma versão anterior de algum software que se começa a entender que features são valiosas e quais não são.

Isso leva ao ponto irônico que as pessoas esperam que os requisitos sejam modificáveis. Afinal de contas, software deveria ser soft. Então não só os requisitos são modificáveis, eles têm de ser modificáveis. Custa muita energia fazer com que clientes de software fixem os requisitos. É ainda pior se eles algum dia estiveram envolvidos com desenvolvimento, porque eles “sabem” que software é fácil de mudar.

Mas mesmo quando você consegue passar por tudo isso e realmente consegue um conjunto de requisitos preciso e estável, ainda assim provavelmente você está condenado. Na economia de hoje, as forças de negócio fundamentais estão mudando o valor das features de software rápido demais. O que pode ser um bom conjunto de requisitos agora, pode não ser daqui a seis meses. Mesmo que os clientes possam fixar seus requisitos, o mundo dos negócios não vai parar por eles. E muitas mudanças no mundo dos negócios são completamente imprevisíveis: qualquer um que diga o contrário está mentindo ou já conseguiu um bilhão no mercado de ações.

Tudo mais em desenvolvimento de software depende dos requisitos. Se você não tem requisitos estáveis, então você não tem um plano previsível.

A previsibilidade é impossível?

Em geral, não. Existem alguns cenários de desenvolvimentos de software onde a previsibilidade é possível. Organizações como o grupo de desenvolvimento de software de ônibus espaciais da NASA são um excelente exemplo onde o desenvolvimento de software pode ser previsível. Se requer um monte de cerimônias, muito tempo disponível, um time grande e requisitos estáveis. Existem projetos por aí que são como ônibus espaciais. Entretanto, não acho que existam muitos softwares comerciais que se encaixam nessa categoria. Para esses, você precisará de um tipo diferente de processo.

Um dos grandes perigos é fingir que você pode seguir um processo previsível quando você não pode. As pessoas que trabalham com metodologias não são muito boas em identificar condições de limites: quando a metodologia deixa de ser apropriada e passa a ser inapropriada. A maioria dos metodologistas querem que suas metodologias sejam usadas por todos e, com isso, eles não entendem e nem deixam claro suas limitações. Isso leva as pessoas a usarem a metodologia em circunstâncias erradas, como usar uma metodologia previsível em uma situação imprevisível.

Há uma forte tentação para fazer isso. Previsibilidade é algo muito desejável. Porém, se você acredita que pode ser previsível quando na verdade não pode, isso leva a situações onde as pessoas criam um plano de forma antecipada e não sabem lidar com a situação quando o plano falha. Você acaba vendo o plano e a realidade se distanciando vagarosamente. Por um bom tempo você pode fingir que o plano ainda é válido. Mas em algum ponto, a diferença será muito grande e o plano falha. Geralmente essa falha é dolorosa.

Então se você está em uma situação que não é previsível você não pode usar uma metodologia previsiva. É um golpe certeiro. Isso significa que muitos dos modelos para controlar projetos e muitos dos modelos para todo o relacionamento com o cliente não são mais verdadeiros. Os benefícios da previsibilidade são tão grandes que é difícil abandoná-los. Como tantos outros problemas, a parte mais complicada é simplesmente perceber que o problema existe.

Entretanto, abrir mão da previsibilidade não significa que você precisa ceder ao caos incontrolável. Em vez disso, você precisará de um processo que possa lhe dar controle sobre uma imprevisibilidade. Isso é o que chamamos de adaptabilidade.

Controlando um Processo Imprevisível — Iterações

Então, como nós nos controlamos em um mundo imprevisível? O mais importante, e ainda mais difícil, é saber especificamente onde nós estamos. Precisamos de um mecanismo de feedback honesto que possa nos dizer precisamente em intervalos frequentes qual é a situação.

O ponto chave para esse feedback é o desenvolvimento iterativo. Esta não é uma ideia nova. Desenvolvimento iterativo existe já há algum tempo com diferentes denominações: incremental, evolucionário, escalonado, espiral… e muitos outros nomes. O ponto chave do desenvolvimento iterativo é produzir frequentemente versões operacionais de um sistema final que tem um subconjunto de funcionalidades necessárias. Estes entregáveis do sistema são pequenos em se tratando de funcionalidades, mas, no entanto, devem ser fiéis às demandas do sistema final. Eles precisam ser totalmente integrados e testados tão cuidadosamente quanto uma entrega final.

A questão nisto é que não existe nada como um sistema testado e integrado para trazer uma forte dose de realidade para qualquer projeto. Documentos podem esconder uma série de falhas. Código sem teste pode esconder uma série de falhas. Mas, quanto as pessoas sentam em frente a um sistema e trabalham com ele, então, as falhas se tornam realmente aparentes: tanto em termo de defeitos, quanto de requisitos mal entendidos.

Desenvolvimento iterativo faz sentido também em processos previsíveis. Mas, ele é essencial em processos adaptativos porque nestes é preciso saber lidar com mudanças em funcionalidades obrigatórias. Isto leva a um estilo de planejamento onde o longo prazo é fluido e os únicos planos estáveis são os de curto prazo, os quais existem para compor uma única iteração. Desenvolvimento iterativo proporciona uma fundação firme em cada iteração, base esta na qual é possível basear os planejamentos posteriores.

A pergunta chave é o quanto uma iteração deve durar. Cada pessoa dá uma resposta diferente. XP sugere iterações entre uma ou duas semanas. SCRUM recomenda a duração de um mês. Crystal pode estender um pouco mais. A tendência, no entanto, é fazer com que cada iteração seja o mais curta possível. Isto provê mais oportunidades de feedback para que você saiba com mais frequência onde você está.

O Cliente Adaptativo

Esse tipo de processo adaptativo necessita de um tipo diferente de relacionamento com um cliente comparado com aqueles que são mais comuns, particularmente quando o desenvolvimento é terceirizado. Quando se contrata uma empresa para fazer o desenvolvimento do software, a maioria dos clientes preferem um contrato de preço fechado. Explicam aos desenvolvedores o que eles precisam, pedem propostas, aceitam uma proposta, e então o ônus de construir o software está com a empresa de desenvolvimento.

Um contrato de preço fechado necessita requisitos estáveis e portanto um processo previsível. Processos adaptativos e requisitos não estáveis implicam que não se pode trabalhar com a noção habitual de preço fechado. Tentar encaixar um modelo de preço fixo a um processo adaptativo terminará em uma explosão dolorosa. A parte desagradável dessa explosão é que o cliente sofre tanto quanto a empresa desenvolvendo o software. Afinal, o cliente não estaria requisitando um software ao menos que seu negócio precisasse dele. Se eles não o recebem o seus negócios vão ser impactados. Assim, mesmo se eles não paguem nada à empresa desenvolvedora, eles ainda estariam perdendo. De fato, eles perdem mais do que eles pagariam pelo software (por que eles pagariam pelo software se o valor de negócio desse software fosse menor?).

Por isso, existem perigos para ambos os lados ao assinar um contrato tradicional de preço fechado onde um processo previsível não pode ser usado. Isso significa que o cliente precisa trabalhar de forma diferente.

Isso não significa que você não consiga estabelecer um orçamento para um software antecipadamente. O que eu digo é que você não pode estabelecer escopo, preço e tempo. A abordagem ágil comum é estabelecer tempo e preço e permitir que o escopo possa variar de uma maneira controlada.

Em um processo adaptativo, o cliente tem muito mais controle no processo de desenvolvimento. Em cada iteração ele pode tanto verificar o progresso quanto alterar a direção do desenvolvimento do software. Isso leva a uma relação mais próxima com os desenvolvedores de software, uma parceria real de negócio. Esse nível de engajamento não serve para todo tipo de organização do cliente, nem tão pouco para todo desenvolvedor de software; mas isso é essencial para fazer um processo adaptativo funcionar corretamente.

Tudo isso produz um número de vantagens para o cliente. Primeiramente, eles recebem um desenvolvimento de software muito mais responsivo. Um sistema utilizável, embora mínimo, pode ir para produção mais cedo. O cliente pode então fazer alterações de acordo com mudanças de negócio, e também do aprendizado ao utilizar o sistema.

Outro fator tão importante é uma maior visibilidade do estado real do projeto. O problema com processos previsíveis é que a qualidade do projeto é medida pela conformidade com o plano. Isso torna difícil para as pessoas sinalizarem quando a realidade e o plano divergem. O resultado comum é um grande deslize tardio no cronograma do projeto. Em um projeto ágil existe um retrabalho constante do plano a cada iteração. Se alguma notícia ruim está por vir, esta tende a aparecer mais cedo, quando ainda existe tempo para agir. De fato, esse controle de risco é uma vantagem chave do processo iterativo.

As metodologias ágeis levam isso além ao manter o tamanho da iteração pequeno, mas também ao ver essas variações de uma forma diferente. Mary Poppendieck resumiu essa diferença de ponto de vista da melhor forma, para mim, com a frase “Uma alteração tardia nos requisitos é uma vantagem competitiva”. Eu acredito que a maior parte das pessoas tem notado que é muito difícil para as pessoas de negócio realmente entenderam o que eles precisam do software no início. Frequentemente vemos que as pessoas aprendem durante o processo sobre quais elementos entregam valor e quais não entregam valor. De forma constante, as funcionalidades que mais entregam valor não são tão óbvias até o momento em que o cliente tem a chance de experimentar o software. As metodologias ágeis procuraram usar isso como vantagem, encorajando as pessoas de negócio a aprender sobre suas necessidades à medida que o sistema é construído, e ao construir o sistema de tal forma que mudanças possam ser incorporadas rapidamente.

Tudo isso são fatores importantes que constituem um projeto de sucesso. Um projeto previsível é frequentemente medido em como o plano está sendo cumprido. Um projeto que está dentro do prazo e dentro do custo é considerado um sucesso. Essa medida não tem sentido em um ambiente ágil. Para agilistas a questão é o valor de negócio — o cliente obteve um software que entrega mais valor para ele do que o custo que foi colocado no software? Um bom projeto previsível seguirá o plano, um bom projeto ágil construirá algo diferente e melhor que o plano original previa.

Colocando Pessoas em Primeiro Lugar

Executar um processo adaptativo não é fácil. Particularmente se requer um time muito eficaz de pessoas desenvolvedoras. O time precisa ser eficaz tanto na qualidade dos indivíduos quanto na maneira em que ele interage. Há também uma sinergia interessante: a adaptabilidade não só requer um time forte como também a maioria dos bons desenvolvedores prefere um processo adaptativo.

Unidades de programação compatíveis

Um dos objetivos das metodologias tradicionais é desenvolver um processo onde as pessoas envolvidas são partes substituíveis. Com tal processo você pode tratar as pessoas como vários tipos de recursos que estão disponíveis. Você tem um(a) analista, algumas pessoas que codificam, algumas pessoas que testam, um(a) gerente. Os indivíduos não são tão importantes, somente os papéis são importantes. Dessa maneira, se você planeja um projeto, não importa qual analista ou quais testadores você tem, somente quantos você tem para que você saiba como o número de recursos afeta o seu plano.

Mas isso levanta uma questão: as pessoas envolvidas no desenvolvimento de software são partes substituíveis? Uma das características chave das metodologias ágeis rejeitam essa premissa.

Talvez a rejeição mais explícita da ideia de pessoas como recursos é a de Alistair Cockburn. No seu artigo “Caracterizando Pessoas como Não-Lineares, Componente Fundamental no Desenvolvimento de Software”, ele diz que processos previsíveis requerem componentes que se comportem de maneira previsível. Entretanto pessoas não são componentes previsíveis. Além disso, seus estudos sobre projetos de software o levaram a concluir que pessoas são o fator mais importante no desenvolvimento de software.

No título, [do seu artigo] eu me refiro a pessoas como “componentes”. Isso é como as pessoas são tratadas na literatura de processo / metodologia de design. O erro nessa abordagem é que “pessoas” são altamente variáveis e não-lineares, com modos únicos de sucesso e falha. Esses fatores são fundamentais e não negligenciáveis. Falhas de projetistas de processos e metodologias em não considerá-los contribuem para as trajetórias não planejadas dos projetos que vemos com tanta frequência.

— [Cockburn não-linear]

Isso nos faz pensar se a natureza do desenvolvimento de software está contra nós aqui. Quando nós estamos programando um computador, nós controlamos um dispositivo inerentemente previsível. Já que estamos nesse negócio por sermos bons em fazermos isso, nós estamos idealmente adequados a estragar tudo quando estamos lidando com seres humanos.

Embora Cockburn é o mais explícito na sua visão de desenvolvimento de software centrado em pessoas, a noção de que pessoas deveriam estar em primeiro lugar é um tema comum entre vários pensadores em software. O problema, várias vezes, é que a metodologia se opõe à noção de pessoas em primeiro lugar quando se trata de sucesso do projeto.

Isso cria um forte efeito de feedback positivo. Se você espera que todos os seus desenvolvedores sejam unidades de programação compatíveis, vocês não os está tratando como indivíduos. Isso diminui a moral (e produtividade). As pessoas que são boas vão procurar um lugar melhor e você vai terminar com o que você quer: unidades de programação compatíveis.

Definir que as pessoas devem vir primeiro é uma grande decisão, a qual requer muita determinação para conseguir. A noção de pessoas como recursos está entranhada no pensamento empresarial, suas raízes remetem ao impacto da abordagem de Gestão Científica de Frederick Taylor. Em uma fábrica em funcionamento, a visão Taylorista faz sentido. Mas, para um trabalho profissional altamente criativo, que eu acredito que seja o caso do desenvolvimento de software, isso não se aplica. (E, na verdade, até o modelo atual de fabricação está se afastando do modelo de Taylor.)

Programadores são profissionais responsáveis

A chave do conceito Tailorista é que que as pessoas que fazem o trabalho não são as pessoas capazes de identificar a melhor forma de fazer aquele trabalho. Em uma fábrica isso pode ser verdade devido há uma série de motivos. Parte disso é que muitos trabalhadores de fábrica não são as pessoas mais criativas e inteligentes, em parte porque há uma tensão entre gestão e trabalhadores em função de que os gestores fazem mais dinheiro e os trabalhadores fazem menos.

A história recente nos mostra gradualmente como isso não é verdade para desenvolvimento de software. Pessoas brilhantes e capacitadas estão sendo cada vez mais atraídas para a área de desenvolvimento de software, seduzidas pelo brilho e por recompensas potencialmente grandes (ambas as quais me tentaram a sair da engenharia eletrônica). Apesar do recuo dos anos 2000, ainda há muito talento e criatividade na área de desenvolvimento de software.

(Pode haver um efeito geracional aqui. Algumas evidências anedóticas me fazem questionar se as pessoas mais brilhantes se aventuraram por engenharia de software nos últimos quinze anos ou mais. Se sim, esta seria uma razão pela qual há esse culto de jovens no negócio de computadores e, como a maioria dos cultos, é necessário que haja um grão de verdade nele.)

Quando você quer contratar e reter pessoas boas, você precisa reconhecer que essas pessoas são profissionais competentes. Assim como eles são as melhores pessoas para decidir como conduzir seu trabalho técnico. O conceito Taylorista, de um departamento de planejamento separado que decide como fazer as coisas, só funciona se as pessoas que planejam entenderem mais sobre como fazer o trabalho do que aqueles que o fazem. Se você tem pessoas motivadas e brilhantes fazendo o trabalho então isso não se aplica.

Gerenciando um processo orientado a pessoas

A orientação de pessoas se manifesta de diferentes maneiras em processos ágeis. Leva a diferentes efeitos, nem todos consistentes.

Um dos elementos-chave é o da aceitação do processo ao invés da imposição do processo. Frequentemente processos de software são impostos por figuras gerenciais. Como tais, usualmente enfrentam resistência, particularmente quando essas figuras gerenciais passaram um tempo significativo longe do desenvolvimento. Aceitar um processo requer comprometimento e, como tal, necessita o envolvimento ativo de todo o time.

Isso acaba tendo o interessante resultado de que somente os próprios desenvolvedores podem escolher seguir um processo adaptativo. Isso é particularmente verdadeiro para XP, por requerer muita disciplina para ser executado. Crystal, por sua vez, considera-se uma abordagem menos disciplinada, que é apropriada para um público mais amplo.

Outro ponto é que os desenvolvedores devem ser capazes de fazer decisões técnicas. XP chega ao coração disso em seu processo de planejamento ao afirmar que somente os desenvolvedores podem fazer estimativas de quanto tempo será necessário para fazer determinado trabalho.

Tal liderança técnica é uma grande mudança para várias pessoas em posições de gerenciamento. Tal abordagem requer compartilhar responsabilidades onde desenvolvedores e gerência têm igual posição na liderança do projeto. Note que eu digo igual. Gerência ainda tem seu papel, mas reconhece a perícia dos desenvolvedores.

Uma razão importante para isso é a taxa de mudanças de tecnologia em nossa indústria. Depois de alguns anos, o conhecimento técnico se torna obsoleto. Essa meia-vida de habilidades técnicas não possui paralelo em outras indústrias. Até pessoas técnicas têm de reconhecer que entrar na gerência significa que suas habilidades técnicas irão rapidamente “murchar”. Ex-desenvolvedores precisam reconhecer que suas habilidades técnicas irão rapidamente desaparecer e que necessitam confiar em desenvolvedores atuais.

A Dificuldade em Medir

Se você tem um processo onde as pessoas que dizem como o trabalho deve ser feito são diferentes das pessoas que realmente fazem o trabalho, os líderes precisam de alguma maneira de medir a efetividade dos que estão executando a tarefa. Em Gestão Científica, há uma forte tendência a desenvolver abordagens objetivas para mensurar as entregas das pessoas.

Isso é particularmente relevante em software por causa da dificuldade de se medir software. Apesar dos nossos melhores esforços, nós não somos capazes de medir as coisas mais simples de software, como produtividade. Sem boas medidas para essas coisas, qualquer tipo de controle externo está condenado à falha.

Introduzir gestão mensurável sem boas métricas leva a seus próprios problemas. Robert Austin realizou uma excelente discussão sobre isso. Ele aponta que, ao se medir performance, você precisa de todos os fatores relevantes à medida. Qualquer coisa faltando tem o resultado inevitável que os executores vão alterar o que eles produzem para produzir melhores medidas, mesmo quando isso claramente reduz a eficácia do que eles fazem. Essa disfunção na medição é o tendão de Aquiles da gestão baseada em medidas.

A conclusão de Austin é que você deve escolher entre a gestão baseada em medidas e a gestão delegatória (onde as pessoas executoras decidem como elas vão trabalhar). Gestão baseada em medidas é mais indicada para trabalhos simples e repetitivos, com baixa necessidade de conhecimento e produção facilmente mensurável — exatamente o oposto do desenvolvimento de software.

O ponto de tudo isso é que métodos tradicionais trabalham com a premissa de que a gestão baseada em medidas é a maneira mais eficaz de gestão. A comunidade ágil entende que as características de desenvolvimento de software combinadas à gestão baseada em medidas leva a níveis muito elevados de disfunção na medição. Na verdade, é mais eficaz usar a gestão delegatória, que é o tipo de abordagem que está no centro do ponto de vista agilista.

O Papel da Liderança de Negócio

Mas as pessoas técnicas não podem fazer todo o processo sozinhas. Elas precisam de orientação com relação às necessidades de negócio. Isso nos leva a outro aspecto importante sobre processos adaptativos: eles precisam de um contato muito próximo com o conhecimento de negócio.

Isso vai além da participação de papéis de negócio na maioria dos projetos. Times ágeis não podem existir com comunicação ocasional. Eles precisam de acesso contínuo ao conhecimento de negócio. Além disso, este acesso não é algo que é tratado a nível de gestão, é algo que é presente para cada desenvolvedor. Já que desenvolvedores são profissionais capacitados em sua própria disciplina, eles precisam ser capazes de trabalhar como iguais com outros profissionais de outras disciplinas.

Uma grande parte disso, é claro, se deve a natureza do desenvolvimento adaptativo. Uma vez que a premissa de desenvolvimento adaptativo é que as coisas mudam rapidamente, você precisa de contato constante para informar a todos sobre as mudanças.

Não há nada mais frustrante para um desenvolvedor do que ver seu trabalho duro ser desperdiçado. Dessa forma, é importante garantir que há boa qualidade de conhecimento de negócio, que esse conhecimento esteja disponível para o desenvolvedor e tenha qualidade o suficiente para que o(a) desenvolvedor(a) possa confiar nele.

O Processo Autoadaptativo

Até agora eu falei sobre adaptatividade no contexto de um projeto adaptando seu software frequentemente para atender às mudanças dos requisitos de seus clientes. No entanto, existe outro ângulo da adaptatividade: aquele do processo que muda ao longo do tempo. Um projeto que começa usando um processo adaptativo não terá o mesmo processo um ano mais tarde. Ao longo do tempo, a equipe irá descobrir o que funciona para eles e alterar o processo de acordo.

A primeira parte da auto-adaptatividade é a revisão regular do processo. Normalmente você faz isso a cada iteração. Ao final de cada uma, faça uma reunião curta e pergunte a si mesmo as seguintes questões (retiradas do livro do Norm Kerth):

• O que fizemos bem?
• O que aprendemos?
• O que podemos melhorar?
• O que está nos atrapalhando?

Estas questões vão orientá-lo a ideias para mudar o processo na próxima iteração. Desta forma um processo que começou com problemas pode melhorar à medida em que o projeto avança, melhor o adaptando à equipe que o usa.

Se auto-adaptatividade ocorre dentro de um projeto, ela é ainda mais acentuada através de uma organização. Uma consequência da auto-adaptatividade é que você não pode nunca esperar encontrar uma única metodologia corporativa. Em vez disso, cada equipe deve não apenas escolher seu próprio processo, como deve também ativamente ajustá-lo à medida em que eles avançam com o projeto. Enquanto tanto os processos publicados quanto a experiência de outros projetos possam servir de inspiração e ponto de partida, a responsabilidade profissional dos desenvolvedores é adaptar o processo para o trabalho em questão.

Sabores de Desenvolvimento Ágil

O termo ‘ágil’ refere-se a uma filosofia de desenvolvimento de software. Debaixo deste amplo guarda-chuva estão abordagens mais específicas como Extreme Programming, Scrum, Desenvolvimento Enxuto, etc. Cada uma dessas abordagens em particular possui suas próprias ideias, comunidades e líderes. Cada comunidade é um grupo distinto em si mas para serem corretamente chamadas de ágeis elas devem seguir os mesmos princípios gerais. Além disso, cada comunidade toma emprestada ideias e técnicas umas das outras. Muitos praticantes se movem entre diferentes comunidades espalhando diferentes ideias entre elas — no fim de contas é um ecossistema complicado mas vibrante.

Até o momento eu dei minha opinião sobre a visão geral de minha definição de ágil. Agora quero apresentar algumas das distintas comunidades ágeis. Posso apenas dar uma rápida introdução aqui, mas eu incluo referências para que você possa buscar mais detalhes se quiser.

Uma vez que estou dando mais referências, esta é uma boa altura para indicar algumas fontes de informação geral acerca de métodos ágeis. O núcleo é a Agile Alliance, uma organização sem fins lucrativos criada para estimular e pesquisar o desenvolvimento ágil de software. De livros eu sugiro os trabalhos de Alistair Cockburn e Jim Highsmith. O livro do Craig Larman sobre desenvolvimento ágil contém uma história muito útil sobre desenvolvimento iterativo. Para mais visões minhas sobre métodos ágeis, veja as seções apropriadas em meus artigos e blog.

A lista a seguir de forma alguma está completa. Ela reflete uma seleção pessoal dos sabores de ágil que mais me interessaram e influenciaram ao longo da última década.

Manifesto Ágil

O termo ‘ágil’ foi tomado para esse movimento no início de 2001 quando um grupo de pessoas que estavam ativamente envolvidas nesse trabalho se reuniram para trocar ideias e conceberam o Manifesto para Desenvolvimento Ágil de Software.

Antes desse workshop, vários grupos diferentes estavam desenvolvendo ideias similares sobre desenvolvimento de software. A maior parte desse trabalho, mas de forma alguma todo ele, surgiu da comunidade de software orientado a objetos, que há muito tempo advogava por abordagens de desenvolvimento iterativo. Este esboço foi escrito originalmente em 2000 para tentar juntar essas várias frentes. Nessa altura não havia um nome comum para estas abordagens, mas o apelido ‘leve’ tinha crescido em torno delas. Muitas das pessoas envolvidas não sentiam que esse era um termo bom porque ele não transmitia com precisão a essência do que eram essas abordagens.

Houve algumas discussões sobre questões mais amplas dessas abordagens no ano 2000 em um workshop organizado por Kent Beck no estado de Oregon. Apesar do workshop ser focado em Extreme Programming (a comunidade que na altura estava ganhando maior atenção), muitos não-praticantes de XP participaram. Uma das discussões que surgiram era sobre ser melhor ou não que o XP fosse um movimento concreto ou mais amplo. Kent preferia uma comunidade coesa e mais focada.

O workshop foi organizado, se eu me lembro corretamente, principalmente por Jim Highsmith e Bob Martin. Eles entraram em contato com as pessoas que consideravam ativas nas comunidades cujas ideias eram similares e reuniram dezessete delas para o workshop Snowbird. A ideia inicial era apenas reunir as pessoas e construir um melhor entendimento sobre as abordagens de cada uma delas. Robert Martin estava interessado em obter alguma declaração, um manifesto que poderia ser usado para reagrupar a indústria em torno deste tipo de técnicas. Nós decidimos também que queríamos escolher um nome para servir como um nome guarda-chuva para as diversas abordagens.

Durante o workshop, nós decidimos usar ‘ágil’ como nome guarda-chuva, e chegamos à parte dos valores do manifesto. A sessão de princípios foi iniciada no workshop mas a maioria foi desenvolvida mais tarde em uma wiki.

O esforço claramente colocou o dedo na ferida, eu acho que todos nós ficamos muito surpresos com o grau de atenção e simpatia que o manifesto recebeu. Apesar de o manifesto dificilmente ser uma definição rigorosa de ‘ágil’, ele fornece um resumo que ajuda a concentrar as ideias. Logo depois de concluirmos o manifesto, Jim Highsmith e eu escrevemos um artigo para a SD Magazine que oferecia alguns comentários ao manifesto.

Mais tarde naquele ano, a maioria das dezessete pessoas que escreveram o manifesto se reuniram outra vez, com muitos outros, no OOPSLA 2001. Sugeriram que os autores do manifesto deveriam iniciar algum movimento ágil, mas os autores concordaram que eles eram apenas as pessoas que por acaso foram ao workshop e acabaram produzindo o manifesto. Não havia maneira de que esse grupo pudesse reivindicar a liderança de toda a comunidade ágil. Nós tínhamos ajudado a lançar a embarcação e deveríamos deixá-la livre para quem quisesse navegar nela. Esse foi portanto o fim dos dezessete autores do manifesto como um corpo organizado.

Um passo que se seguiu depois, com o envolvimento ativo de muitos desses autores, foi a formação da Agile Alliance. Esse é um grupo sem fins lucrativos com a intenção de promover e pesquisar métodos ágeis. Entre outras coisas, ele patrocina uma conferência anual nos Estados Unidos.

XP (Extreme Programming)

Quando os métodos ágeis começaram a se difundir, no final da década de 90, o Extreme Programming foi o método que se tornou mais popular, e em muitos aspectos, continua sendo.

O XP tem suas raízes na comunidade da linguagem Smalltalk, em particular na colaboração entre Kent Beck e Ward Cunningham, no fim da década de 80. Ambos refinaram suas práticas em inúmeros projetos no começo da década de 90, estendendo suas ideias sobre uma abordagem de desenvolvimento de software que fosse adaptativa e orientada a pessoas.

Kent continuou a desenvolver suas ideias durante consultorias, em especial no projeto Chrysler C3, que desde então ficou conhecido como projeto de criação do extreme programming. Ele começou a usar o termo ‘extreme programming’ em meados de 1997. (C3 também marcou meu primeiro contato com o Extreme Programming e o início da minha amizade com Kent.)

Durante o fim da década de 90, o Extreme Programming se espalhou, inicialmente sendo descrito em fóruns e na Wiki de Ward Cunningham, na qual Kent e Ron Jeffries (um colega do projeto C3) dedicaram bastante tempo explicando e debatendo várias ideias. Por fim, diversos livros foram publicados entre os anos 90 e 2000 que detalharam vários aspectos da abordagem. A maioria deles usaram como base o livro branco do Kent Beck. Kent produziu uma segunda edição em 2004 com uma significativa rearticulação da abordagem.

XP começa com 5 valores (Comunicação, Feedback, Simplicidade, Coragem e Respeito). Em seguida, refina esses valores em 14 princípios e depois em 24 práticas. A ideia é que as práticas são coisas concretas que um time pode fazer no dia-a-dia, enquanto os valores são o conhecimento fundamental e entendimento que sustenta a abordagem. Valores sem práticas são difíceis de aplicar e podem ser aplicados de tantas formas diferentes que é difícil saber por onde começar. Práticas sem valores são atividades rotineiras sem propósito. Ambos são necessários, mas há uma grande diferença entre eles — os princípios ajudam a aproximá-los. Muitas práticas do XP são técnicas antigas, usadas e testadas, e ainda sim esquecidas por muitos, incluindo a maioria dos processo de planejamento. Além de ressuscitar tais técnicas, XP tece uma rede de sinergia, onde cada elemento é reforçado pelos outros e ganha propósito pelos valores.

Um dos mais impressionantes, bem como interessante para mim, é a forte ênfase em testes. Enquanto todos os processos mencionam testes, a maioria o faz com pequena ênfase. Entretanto, o XP coloca testes como a fundação do desenvolvimento, com cada programador escrevendo testes enquanto escrevem o seu código para produção. Os testes são integrados em um integração contínua e processo de build que constroem uma plataforma estável para desenvolvimentos futuros. A abordagem do XP aqui, geralmente descrita como “Test Driven Development” (TDD) tem causado influência até em lugares que não adotam muito do XP.

Existem várias publicações de XP. Uma área de confusão, entretanto, é a mudança entre a primeira e a segunda edição do livro branco. Eu mencionei acima que a segunda edição é uma “rearticulação” do XP, onde a abordagem ainda é a mesma mas é descrita em um estilo diferente. Na primeira edição (com quatro valores, doze práticas e alguns importantes mas geralmente ignorados princípios) teve uma grande influência na indústria de software e a maioria das descrições do XP se basearam na primeira edição do livro. Lembre-se disso quando ler material sobre XP, especialmente se foi escrito antes de 2005. Realmente, a grande maioria das descrições na web são baseadas na primeira edição.

O lugar mais natural para se descobrir mais é na segunda edição do livro branco. Esse livro explica o background e práticas XP em um pequeno pacote (160 páginas). Kent Beck editou uma série de livros multicoloridos sobre XP na virada do século e, se eu fosse forçado a escolher um, eu escolheria o livro roxo, lembre-se que assim como a maioria do material, ele é baseado na primeira edição.

Existe muito material na web sobre XP mas a grande maioria é baseada na primeira edição. Uma das poucas descrições que eu conheço que se basearam na segunda edição é o “O novo XP” (PDF) por Michele Marchesi que organizou as conferências originais de XP em Sardenha. Para discussão sobre XP há uma lista de emails no Yahoo.

O meu envolvimento no princípio e amizades na comunidade XP significam que eu tenho uma maior familiaridade distinta, carinho e viés com o XP. Eu acredito que sua influência é devida por casar os princípios ágeis de desenvolvimento com um conjunto de técnicas sólidas para executá-lo. Muitos dos primeiros escritos sobre ágil negligenciaram o último, levantando a questão se ideias ágeis eram realmente possíveis. O XP forneceu ferramentas para que as esperanças do ágil pudessem ser realizadas.

Scrum

O scrum também se desenvolveu nos anos 80 e 90, principalmente nos grupos de desenvolvimento OO, como uma metodologia de desenvolvimento altamente iterativa. Os desenvolvedores mais conhecidos foram Ken Schwaber, Jeff Sutherland e Mike Beedle.

O Scrum concentra-se nos aspectos de gestão do desenvolvimento de software, dividindo o desenvolvimento em iterações de 30 dias (chamados ‘sprints’) e aplicando um monitoramento e controle mais próximos através de reuniões diárias. O Scrum coloca pouca ênfase nas práticas de engenharia de software e muitas pessoas combinam sua abordagem de gerenciamento de projetos com as práticas de engenharia de software existentes no XP. (As práticas de gerenciamento existentes no XP não são realmente muito diferentes.)

Ken Schwaber é um dos representantes mais ativos do Scrum, seu site é um bom lugar para começar a procurar mais informações e seu livro é provavelmente a melhor referência inicial.

Crystal

Alistair Cockburn tem sido a muito tempo uma das principais vozes na comunidade ágil. Ele criou a família Crystal de métodos de desenvolvimento de software como um grupo de abordagens customizadas para times de diferentes tamanhos. Crystal é visto como uma família porque Alistair acredita que diferentes formas de pensar são necessárias quando os times variam de tamanho e a criticidade dos erros muda.

Apesar de suas variações todas as abordagens do Crystal compartilham características comuns. Todos os métodos têm três prioridades: segurança (no resultado do projeto), eficiência, habitabilidade (os desenvolvedores podem viver com Crystal). Eles também compartilham propriedades comuns, das quais as três mais importantes são: Entrega Frequente, Aperfeiçoamento Refletivo e Comunicação Próxima.

A prioridade de habitabilidade é uma parte importante do mind-set do Crystal. A busca de Alistair (como eu vejo) é pela menor quantidade de processo que você pode fazer e ainda assim ter sucesso tendo como suposição menos disciplina, o que é inevitável com seres humanos. Como resultado, Alistair vê Crystal como algo que exige menos disciplina do que o extreme programming, trocando menos eficiência por uma maior habitabilidade e reduzindo as chances de falha.

Apesar do esboço geral sobre Crystal, não há uma descrição abrangente de todas as suas manifestações. A melhor descrição é a do Crystal Clear, que tem uma descrição moderna. Há também uma wiki com mais material e discussão sobre Crystal.

Context Driven Testing

Desde o início foram os desenvolvedores de software que vinham guiando a comunidade ágil. No entanto, muitas outras pessoas estão envolvidas no desenvolvimento de software e elas também são afetadas por este novo movimento. Um grupo óbvio é o de testers, que muitas vezes se vêem presos no modo de pensar baseado no processo em “cascata”. Com esse processo que possui diretrizes comuns que afirmam que o papel do teste é garantir a conformidade do software com as especificações escritas e definidas previamente, no mundo ágil o papel dos testers está longe de ser claro.

De fato, várias pessoas na comunidade de testes vêm questionando a algum tempo a forma de pensar em testes mainstream. Isso levou a um grupo conhecido como teste baseado em contexto. A melhor descrição disso está no livro Lessons Learned in Software Testing. Esta comunidade também é muito ativa na web, dê uma olhada em sites hospedados por Brian Marick (um dos autores do manifesto ágil), Brett Pettichord, James Bach e Cem Kaner.

Desenvolvimento de Software Lean

Lembro-me, alguns anos atrás, dando uma palestra sobre métodos ágeis na “Software Development Conference” e conversando com uma mulher ansiosa sobre os paralelos entre as idéias ágeis e movimento Lean de produção. Mary Poppendieck (e seu marido Tom) passaram a apoiar ativamente a comunidade ágil, com um olhar especial para as sobreposições e inspirações entre a produção Lean e o desenvolvimento de software.

O movimento Lean em produção foi iniciado por Taiichi Ohno na Toyota e é também conhecido como “Sistema Toyota de Produção”. O Lean foi uma inspiração para muitos dos primeiros agilistas — os Poppendiecks são os mais notáveis pra descrever como essas ideias interagem. Em geral, sou muito desconfiado desse tipo de raciocínio por analogia, de fato a separação da engenharia entre design e construção foi o que nos levou a essa confusão. No entanto, analogias podem nos levar a boas idéias e acho que o Lean têm introduzido muitas idéias úteis e ferramentas para o movimento ágil.

Os pontos de partida para mais informações são obviamente o livro e o site dos Poppendiecks.

Processo Unificado (Racional) — RUP

Outro processo bem conhecido que saiu da comunidade de orientação a objeto é o Processo Unificado Racional (algumas vezes apenas referido como Processo Unificado). A ideia original foi que, assim como a UML, unified modeling languages, o Processo Unificado (ou UP, sigla em inglês) poderia unificar os processos de software. Como o RUP apareceu aproximadamente no mesmo tempo que os métodos ágeis, existe uma grande discussão sobre se os dois são compatíveis.

O RUP é uma coleção muito grande de práticas e é na realidade um framework de processos ao invés de um processo. Ao invés de oferecer um único processo para o desenvolvimento de software, ele procurar prover um conjunto comum de práticas para os times escolherem em um projeto específico. Como resultado, o primeiro passo de um time ao usar RUP deve ser a definição de seus processos específicos, ou como RUP denota, um caso de desenvolvimento.

O aspecto chave comum do RUP é que este é orientado a Caso de Uso (o desenvolvimento é dirigido através de funcionalidades visíveis ao usuário), iterativo e centrado na arquitetura (existe uma prioridade na construção de uma arquitetura no início e que vai durar todo o projeto).

Minha experiência com RUP é que o seu problema é sua variabilidade infinita. Eu já vi descrições do uso de RUP que alcançam desde “cascata” rígidas com “iterações de análise”, até a imagem perfeita do ágil. Me parece que o desejo das pessoas ao fazer marketing de RUP como um processo único os levou a um resultado onde as pessoas podem fazer qualquer coisa e chamá-la de RUP — fazendo com que o RUP seja uma frase sem sentido.

Apesar de tudo, existem algumas pessoas fortes na comunidade de RUP que estão bem alinhadas com o pensamento ágil. Eu fico impressionado em todos os meus encontros com Phillippe Kruchten e o seu livro que é o melhor ponto de partida para o RUP. Craid Larman também tem desenvolvido descrições de trabalhos utilizando RUP em um estilo ágil no seu popular livro introdutório sobre projetos OO.

Você deve ser ágil?

Usar uma metodologia ágil não é para qualquer um. Há uma série de coisas a considerar caso decida prosseguir por esse caminho. Eu acredito fortemente que estas metodologias são amplamente aplicáveis e devem ser adotadas por mais pessoas do que as que consideram utilizá-la.

Nos ambientes atuais, a metodologia mais comum é desenvolver e corrigir bugs. Aplicar alguma disciplina ao invés do caos irá certamente ajudar, uma técnica ágil tem a vantagem de que são menos passos do que um método pesado. Aqui a leveza dos métodos ágeis é vantajosa. Processos simples são mais fáceis de serem seguidos quando não é usado nenhum processo.

Para pessoas que são novas em metodologias ágeis, a questão é por onde iniciar. É preciso fazer uma avaliação ao iniciar em qualquer tecnologia ou processo. O que irá permitir ver como metodologias ágeis se encaixam no seu ambiente. Como resultado, muito do meu conselho nesse artigo segue o que falei sobre outras abordagens, me trazendo à memória de quando eu falei pela primeira vez sobre técnicas de orientação a objetos.

O primeiro passo é encontrar projetos adequados para tentar metodologias ágeis. Uma vez que métodos ágeis são fundamentalmente orientados a pessoas, é essencial que você inicie com um time que esteja disposto a tentar e trabalhar de maneira ágil. Não apenas uma equipe relutante é mais difícil de trabalhar, mas a imposição de métodos ágeis a pessoas relutantes é fundamentalmente contrária a toda noção de desenvolvimento ágil.

É valioso ter também clientes (aqueles necessitam do software) que queiram trabalhar nesse tipo de maneira colaborativa. Se os clientes não colaboram, então você não verá todas as vantagens de um processo adaptativo. Dito isso, descobrimos em várias ocasiões clientes que não queria colaborar, mas mudaram de ideia nos primeiros meses, quando começaram a entender a abordagem ágil.

Muitas pessoas afirmam que métodos ágeis não podem ser usados em projetos grandes. Nós (ThoughtWorks) tivemos sucesso em projetos ágeis com cerca de 100 pessoas e distribuído em múltiplos continentes. Apesar disso, eu sugiro escolher algo pequeno para iniciar. Grandes projetos são naturalmente mais difíceis, portanto é melhor iniciar o aprendizado em um projeto mais fácil de gerenciar.

Algumas pessoas aconselham escolher um projeto com menor impacto ao negócio, para caso haja algum problema o dano seja menor. Entretanto, um projeto sem importância frequentemente é um teste pobre porque ninguém se importa muito com o resultado. Eu prefiro aconselhar as pessoas a escolherem um projeto que seja um pouco mais crítico do que estejam confortáveis.

Talvez a coisa mais importante a se fazer seja encontrar alguém com mais experiência em projetos ágeis para ajudá-lo a aprender. Sempre que alguém faz algo novo inevitavelmente irá cometer erros. Encontrar alguém que já cometeu muitos erros pode evitar que você os cometa novamente. Isso é uma verdade para qualquer nova tecnologia ou técnica, um bom mentor vale seu peso em ouro. É claro que esse conselho é um pouco enviesado já que a ThoughtWorks e muitos dos meus amigos no mercado fazem consultoria em metodologias ágeis. O que não muda o fato de eu acreditar fortemente na importância de encontrar um bom mentor.

Uma vez que você encontre um bom mentor, siga seus conselhos. É muito fácil questionar muito disso depois de acontecer e o que aprendi da minha experiência é que muitas técnicas não podem ser compreendidas até que você tenha feito uma boa tentativa de experimentá-las. Um dos melhores exemplos que escutei foi um cliente nosso que decidiu adotar extreme programing por alguns meses. Durante esse período deixaram claro que fariam o que o mentor dissesse — mesmo que que eles considerassem uma má ideia. No fim do período experimental eles iriam parar e decidir se continuariam com algumas ideias ou iriam reverter para a forma de trabalho anterior (caso você esteja curioso, eles decidiram por continuar com XP).

Uma das questões abertas sobre metodologias ágeis é onde estão os limites. Um dos problemas com novas técnicas é que você realmente não sabe onde estão os limites até ultrapassá-los e falhar. Métodos ágeis ainda são muito recentes para visualizar onde estão as suas fronteiras. Isto é agravado ainda mais pelo fato de ser difícil decidir o que é sucesso e falha no desenvolvimento de software, assim como diversas variantes que dificultam identificar com exatidão a origem dos problemas.

Então, onde você não deve usar um método ágil? Eu penso que primeiramente depende das pessoas. Se as pessoas envolvidas não estão interessadas no tipo de colaboração intensa que métodos ágeis requerem, então vai ser um grande esforço fazê-los trabalhar com metodologias ágeis. Particularmente eu creio que isto significa que você nunca deve tentar impor ágil trabalhando em um time que não quer tentá-lo.

Há várias experiências com métodos ágeis nos últimos dez anos. Na ThoughtWorks nós sempre usamos uma abordagem ágil quando os clientes estão dispostos, o que na maioria das vezes estão. Eu, e nós, continuamos grandes fãs dessa forma de trabalho.

*Publicado originalmente aqui e traduzido por Bárbara Sanches, Francieli Viane, Isabella Barroso, Jullie Utsch, Mariana Barboza, Paola Martins, Wandecleya Martins, Alexandre Klaser, Alex Ziegler, Bruno Dias, Diego Centeno, Fabio Maia, Guilherme Prestes, Leandro Farina, Rodrigo Pinheiro e Tiago Griffo.