Metodologias ágeis de desenvolvimento

Posted by cristianmedeiros | Posted on 11-06-2008

Category : Engenharia de Software

Tags: Metodologias, scrum, xp

Extraído integralmente de:http://simplus.com.br/artigos/a-nova-metodologia/

A Nova Metodologia

Martin Fowler

Última Atualização Significativa: Abril de 2003

Tradução em português: Luciano Passuello, Dezembro de 2005

Texto Original: The New Methodology

Nos últimos anos, vem crescendo rapidamente o interesse em metodologias ágeis (ou "leves"). Também caracterizadas como um antídoto contra a burocracia ou uma licença para "hackear", estas metodologias despertaram o interesse em toda a extensão da indústria do software. Neste artigo, eu exploro os motivos para as metodologias ágeis, focando não tanto em sua leveza, mas sim em sua natureza adaptável e na sua tendência em colocar as pessoas em primeiro lugar. Eu também apresento um sumário e referências aos processos nesta linha de pensamento ainda considero os fatores que deveriam influenciar sua decisão sobre trilhar ou não este novo caminho.

Do Nada, ao Monumental, ao Ágil
Predeterminante contra Adaptativo
Colocando as Pessoas em Primeiro Lugar
O Processo Auto-Adaptativo
As Metodologias
Você deve se tornar ágil?
Agradecimentos

Do Nada, ao Monumental, ao Ágil

A prática do desenvolvimento de software é uma atividade caótica em sua maior parte, normalmente caracterizada pela expressão "codificar e consertar". O software é escrito sem um plano definido e o projeto do sistema é repleto de várias decisões de curto prazo. Isso funciona muito bem se o sistema é pequeno – mas à medida que o sistema cresce, torna-se cada vez mais difícil adicionar novos recursos a ele. Defeitos subseqüentes se tornam cada vez mais dominantes e cada vez mais difíceis de serem eliminados. Um sinal típico de um sistema desse tipo é uma longa fase de testes depois que o sistema está "pronto". Esta longa fase de testes entra em confronto direto com o cronograma, pois testes e depuração são atividades cujos tempos são impossíveis de serem estimados.

Nós convivemos com este estilo de desenvolvimento há muito tempo, mas também temos uma alternativa há muito tempo: Metodologia. Metodologias impõem um processo disciplinado no desenvolvimento de software, com o objetivo de torná-lo mais previsível e mais eficiente. Elas fazem isso desenvolvendo um processo detalhado com uma forte ênfase em planejamento e inspirado em outras disciplinas de engenharia – por isso eu tendo a referir-me a elas como metodologias de engenharia.

Metodologias de engenharia estão disponíveis há muito tempo. Elas não têm sido percebidas como sendo particularmente bem-sucedidas. Elas têm sido notadas menos ainda por serem populares. A crítica mais freqüente é que estas metodologias são burocráticas. Há tanta coisa a se fazer para seguir a metodologia que o todo o ritmo de desenvolvimento fica mais lento.

Como uma reação a tais metodologias, um novo grupo delas surgiu nos últimos anos. Durante algum tempo elas foram conhecidas como metodologias leves, mas agora o termo mais aceito é metodologia ágil. Para muitas pessoas o apelo das metodologias ágeis é a reação delas à burocracia das metodologias monumentais. Estas novas metodologias tentam criar um equilíbrio entre nenhum processo e muito processo, provendo apenas o suficiente de processo para obter um retorno razoável.

O resultado disso tudo é que os métodos ágeis têm algumas mudanças de ênfase significativas em relação aos métodos de engenharia. A diferença mais evidente é que metodologias ágeis são menos centradas em documentação, normalmente enfatizando uma quantidade menor de documentos para uma dada tarefa. De várias maneiras, elas são mais voltadas ao código-fonte do programa: seguindo um caminho que diz que a parte-chave da documentação é o próprio código-fonte.

Entretanto, eu não acho ser este o ponto-chave das metodologias ágeis. Menos documentação é apenas um sintoma de duas diferenças mais profundas:

Metodologias ágeis são adaptativas ao invés de predeterminantes. Metodologias de engenharia tendem a tentar planejar uma grande parte do processo de desenvolvimento detalhadamente por um longo período de tempo. Isso funciona bem até as coisas mudarem. Então a natureza de tais métodos é a de resistir à mudança. Para os métodos ágeis, entretanto, mudanças são bem-vindas. Eles tentam ser processos que se adaptam e se fortalecem com as mudanças, até mesmo ao ponto de se auto-modificarem.
Métodos ágeis são orientados a pessoas ao invés de serem orientados a processos.O objetivo dos métodos de engenharia é de definir um processo que irá funcionar bem, independentemente de quem os estiverem utilizando. Métodos ágeis afirmam que nenhum processo jamais será equivalente à habilidade da equipe de desenvolvimento. Portanto, o papel do processo é dar suporte à equipe de desenvolvimento e seu trabalho.

Nas sessões seguintes irei explorar estas diferenças em mais detalhes, para que você possa entender como é um método adaptativo e centrado em pessoas, seus benefícios e inconveniências, e se é algo que você deve utilizar – seja como desenvolvedor ou como cliente do software.

Predeterminante contra Adaptativo

Separação de Design e Construção

A inspiração comum para as metodologias são as áreas da engenharia, tais como Engenharia Civil ou Mecânica. Tais áreas enfatizam o planejamento antes da construção. Engenheiros destas áreas trabalharão em uma série de desenhos que indicam precisamente o que precisa ser construído e como todas as coisas devem se encaixar. Muitas decisões de design, tais como a maneira de lidar com a carga em uma ponte, são feitas à medida que os desenhos são produzidos. Os desenhos são então entregues para um outro grupo, normalmente de outra empresa, pra serem construídos. Assume-se que o processo de construção irá seguir os desenhos. Na prática, os construtores vão se deparar com alguns problemas, mas normalmente são pequenos.

Uma vez que os desenhos especificam as partes e como elas se encaixam, eles agem como uma fundação para um plano de construção detalhado. De tal plano pode ser derivado o que precisa ser feito e quais dependências existem entre as tarefas. Isso permite um cronograma e um orçamento razoavelmente previsíveis para a construção. Ainda especifica em detalhes como as pessoas que farão a construção devem fazer seus trabalhos. Isso permite que os trabalhadores da construção possam ser menos habilidosos intelectualmente, embora freqüentemente sejam muito habilidosos manualmente.

Então, o que vemos são duas atividades fundamentalmente diferentes. Design – que é difícil prever e requer pessoas caras e criativas, e construção – que é mais fácil de prever. Uma vez que tivermos o design, podemos planejar a construção. Uma vez que tivermos o plano para a construção, nós podemos lidar com a construção de uma forma muito mais previsível. Em engenharia civil, a construção é muito maior tanto em custo como em tempo que design e planejamento.

Então, a abordagem das metodologias de engenharia de software é algo semelhante a isto: nós queremos um cronograma previsível que possamos utilizar pessoas com pouca habilidade. Para fazer isto, devemos separar as atividades de design e construção. Logo, nós precisamos descobrir como fazer o design do software de forma que a construção seja algo simples, uma vez que o planejamento esteja feito.

Então qual o formato deste planejamento? Para muitos, este é o papel de notações de modelagem, tais como a UML. Se nós conseguirmos fazer todas as decisões utilizando UML, poderemos criar um plano de construção e entregá-lo aos programadores, para uma atividade estritamente de construção.

Mas aqui se encontra a pergunta crucial: Você pode criar um design que é capaz de transformar a programação em uma atividade de construção previsível? E, em caso positivo, o custo de fazer isto é suficientemente baixo para que essa seja uma abordagem vantajosa?

Tudo isso traz à tona algumas perguntas. A primeira é a questão do quão difícil é conseguir um design estilo UML em um estado que possa ser entregue aos programadores. O problema com um design UML é que ele pode parecer muito bom no papel, e ainda ser seriamente problemático quando você tem que traduzi-lo em código-fonte. Os modelos utilizados por engenheiros civis são baseados em diversos anos de prática adquirida em códigos de engenharia. Além disso, questões-chave, tais como o modo que forças físicas atuam no projeto, são triviais à análise matemática. A única checagem que podemos fazer em diagramas UML são revisões cuidadosas. Enquanto estas são úteis, levam a erros que são freqüentemente descobertos apenas durante a codificação e testes. Até mesmo designers habilidosos, como eu me considero , são freqüentemente surpreendidos quando transformamos tais designs em software.

Outro problema é o custo comparativo. Quando se constrói uma ponte, o custo do esforço de design é aproximadamente 10% do total, com o resto sendo construção. Em software, a quantidade de tempo gasta em codificação é muito, muito menor. McConnell sugere que para um projeto de larga escala, apenas 15% do projeto é codificação e testes unitários – uma inversão quase perfeita da proporção em construção de pontes. Mesmo que você considere toda a etapa de testes como sendo construção, o design ainda representa apenas 50% do trabalho. Isso levanta uma questão importante sobre a natureza do design em software comparado com seu papel em outros ramos da engenharia.

Estes questionamentos levaram Jack Reeves a sugerir que na verdade o código-fonte é um documento de design e que a fase de construção é apenas o uso do compilador e do linker. De fato, tudo que pode ser tratado como construção pode e deve ser automatizado.

Em software, a construção é tão barata que pode ser considerada gratuita.
Em software, todo o esforço é design, logo requer pessoas criativas e talentosas.
Processos criativos não são planejados facilmente, logo a previsibilidade é provavelmente um objetivo impossível.
Nós devemos ter muito cuidado com a metáfora tradicional de engenharia para construir software. Esse é um tipo diferente de atividade e requer um processo diferente.

A Imprevisibilidade dos Requisitos

Há um comentário que eu escuto em todos os projetos problemáticos que encontro . Os desenvolvedores vêm a mim e dizem: "o problema com este projeto é que os requisitos estão sempre mudando". O que acho surpreendente a respeito dessa situação é que alguém ainda se surpreende com ela. Se mudanças em requisitos de negócio ao construir software são a regra, a pergunta é o que devemos fazer a esse respeito.

Um caminho é tratar requisitos mutantes como resultado de uma engenharia de requisitos pobre. A idéia por trás da engenharia de requisitos é a de obter uma visão completamente clara dos requisitos antes de começar a construir o software, obter uma aprovação do cliente destes requisitos, e depois implantar procedimentos que limitam mudanças nestes requisitos.

Um problema com isto é que apenas entender as opções para os requisitos já é difícil. E é ainda mais difícil pois normalmente a empresa que desenvolve o software não provê as informações do custo dos requisitos. Você acaba em uma situação onde você tem uma certa vontade de comprar um teto solar para o seu carro, mas o vendedor não pode lhe dizer se isso aumenta o custo do carro em $10 ou $10.000. Sem muita idéia do custo, como você pode decidir se realmente quer pagar pelo teto solar?

Estimativas são difíceis por vários motivos. Parte é por que desenvolvimento de software é uma atividade de design, portanto difícil de planejar ou custear. Parte é por que os materiais básicos se mantêm sempre mudando rapidamente. Parte é por que depende muito de quais pessoas estão envolvidas, e pessoas são difíceis de prever ou quantificar.

A natureza intangível do software também contribui. É muito difícil ver o valor de uma funcionalidade do software até que ela seja materializada. Apenas quando você vê uma versão preliminar do software você realmente começa a entender que funcionalidades são valiosas e quais não são.

Isso leva ao ponto irônico onde as pessoas esperam que os requisitos sejam mutáveis. Afinal de contas, o software deve ser "soft". Assim não somente os requisitos são mutáveis, mas espera-se que assim o sejam. Gasta-se muita energia para que os clientes consertem os requisitos. É ainda pior se eles já estiveram de alguma forma envolvidos em desenvolvimento de software, pois aí eles "sabem" que é fácil de modificar software.

Mas mesmo que você pudesse concordar e realmente conseguisse um conjunto preciso e estável de requisitos, ainda assim isso provavelmente não seria suficiente. Na economia de hoje, as forças de negócio fundamentais estão mudando o valor dos requisitos de software muito rapidamente. O que pode ser um bom conjunto de requisitos agora, não será um bom conjunto de requisitos em seis meses. Mesmo que os clientes possam fixar seus requisitos, o mundo dos negócios não vai parar para eles. E muitas mudanças no mundo dos negócios são completamente imprevisíveis: qualquer um que diga o contrário está ou mentindo, ou já conseguiu um bilhão de dólares no mercado de ações .

Tudo mais no desenvolvimento de software depende dos requisitos. Se você não pode obter requisitos estáveis, então você não pode ter um plano de projeto estável.

A Previsibilidade é Impossível?

Em geral, não. Existem alguns casos de desenvolvimento de software onde a previsibilidade é possível. Organizações como o grupo de software do ônibus espacial da NASA são um exemplo típico de como o desenvolvimento de software pode ser previsível. É necessário muita cerimônia, um time grande e requisitos estáveis. Existem projetos que são ônibus espaciais. Entretanto, eu não acredito que muitos sistemas se enquadrem nesta categoria. Para estes, você precisa de um tipo diferente de processo.

Um dos grandes riscos é fingir que você pode seguir um processo previsível quando você não pode. As pessoas que trabalham com metodologia não são muito boas em identificar condições-limite: os lugares onde a metodologia passa de apropriada para inapropriada. Muitos dos estudiosos em metodologias querem que suas metodologias sejam utilizadas por todos, para que eles não precisem entender ou divulgar suas condições-limite. Isso leva as pessoas a utilizar a metodologia nas circunstâncias erradas, como por exemplo, usando uma metodologia previsível em uma situação imprevisível.

Há uma forte tentação a fazer isso. Previsibilidade é uma propriedade muito desejável. Entretanto, se você acredita que pode ser previsível quando você não pode, isso leva a situações onde as pessoas constroem um plano no início e depois não conseguem lidar com a situação onde o plano falha. Você vê a realidade lentamente distanciando-se do plano. Por muito tempo, você pode fingir que o plano ainda é válido. Mas em algum ponto, o distanciamento fica muito grande e o plano simplesmente cai em pedaços. Normalmente a queda é dolorosa.

Então, se você está em uma situação que não é previsível, você não pode usar uma metodologia previsível. Essa é a dura realidade. Isto significa que muitos dos modelos para controle de projetos e muitos dos modelos para o relacionamento com clientes simplesmente não se aplicam mais. Os benefícios da previsibilidade são enormes, é muito difícil abrir mão deles. Como muitos problemas, a parte mais difícil é simplesmente perceber que o problema existe.

Entretanto, abandonar a previsibilidade não significa que você precise voltar ao caos incontrolável. Ao invés disso, você precisa de um processo que lhe dê controle sobre a imprevisibilidade. É justamente esse o ponto principal da adaptatividade.

Controlando um Processo Imprevisível – Iterações

Então como controlamos um mundo imprevisível? O mais importante, e ainda mais difícil, é saber com precisão onde estamos. Precisamos de um mecanismo honesto de feedback que possa dizer-nos com precisão qual é a situação em intervalos freqüentes.

A chave para este feedback é o desenvolvimento iterativo. Esta não é uma idéia nova. Desenvolvimento iterativo já existe por algum tempo sob vários nomes diferentes: incremental, evolucionário, em estágios, espiral… muitos nomes. A chave para o desenvolvimento iterativo é freqüentemente produzir versões que funcionam do sistema final, que contém um subconjunto dos recursos requeridos. Estas versões são bastante limitadas em funcionalidade, mas devem ser fiéis às demandas do sistema final. Elas devem ser totalmente integradas e cuidadosamente testadas como se fossem a entrega final.

O ponto é que não existe nada como um sistema testado e integrado para trazer uma dose de realidade a qualquer projeto. Documentos podem esconder todo tipo de falhas. Código-fonte não-testado pode esconder muitas falhas. Mas quando as pessoas sentam em frente a um sistema e trabalham com ele, as falhas se tornam verdadeiramente aparentes: tanto em termos de defeitos como em termos de requisitos mal-interpretados.

Desenvolvimento iterativo faz sentido em processos previsíveis também. Mas é essencial em processos adaptativos, pois um processo adaptativo precisa ser capaz de lidar com mudanças nas funcionalidades requisitadas. Isso leva a um estilo de planejamento onde os planos de longo prazo são bastante fluidos, e os únicos planos estáveis são os de curto prazo, feitos para uma única iteração. O desenvolvimento iterativo lhe dá uma fundação firme em cada iteração onde você pode basear seus planos futuros.

Uma pergunta comum é o quão longa uma iteração deve serqual o tamanho ideal para cada iteração. Pessoas diferentes darão respostas diferentes. XP sugere interações entre uma e três semanas. SCRUM sugere a duração de um mês. Em Crystal, vai ser maior. A tendência, entretanto, é fazer cada iteração o tão curta quanto possível. Isso provê feedback mais freqüente, para que você possa saber com mais freqüência onde está.

O Cliente Adaptável

Esse tipo de processo adaptativo requer um tipo diferente de relacionamento com o cliente do que as alternativas consideradas normalmente, especialmente quando o desenvolvimento é feito por outra empresa. Quando você contrata uma outra empresa para fazer o desenvolvimento do software, a maioria dos clientes prefere um contrato de custo fixo. Diga aos desenvolvedores o que quer, junte propostas, aceite uma delas, e então o ônus do desenvolvimento será da empresa que foi escolhida para desenvolver o software.

Um contrato de custo fixo requer requisitos estáveis, e, portanto, um processo predeterminista. Processos adaptativos e requisitos instáveis implicam que você não pode trabalhar com a noção habitual de custo fixo. Tentar encaixar um modelo de custo fixo em um processo adaptativo termina com uma explosão muito traumática. A pior parte dessa explosão é que o cliente sai tão prejudicado como a empresa de desenvolvimento. Afinal de contas, o cliente não iria querer o software se seu negócio não estivesse precisando dele. Se eles não têm o produto, seu negócio sai prejudicado. Então, mesmo que eles não paguem nada à empresa de desenvolvimento, eles ainda saem no prejuízo. Na verdade, eles perdem mais do que eles teriam investido pagando pelo software (por que eles pagariam pelo software se seu valor agregado fosse menor que o valor pago?).

Logo, existem perigos para ambas as partes em assinar um contrato de custo fixo em condições onde um processo predeterminista não pode ser utilizado. Isso quer dizer que o cliente tem de trabalhar de forma diferente.

Isso não quer dizer que você não possa fixar um orçamento para o software antes de desenvolvê-lo. O que significa é que você não pode fixar tempo, preço e escopo. A abordagem ágil comum é fixar tempo e preço, deixando o escopo variar de forma controlada.

Em um processo adaptativo, o cliente tem um controle muito mais refinado sobre o processo de desenvolvimento do software. Em cada iteração, podem tanto verificar o progresso como alterar a direção do desenvolvimento. Isso leva a um relacionamento muito mais próximo com os desenvolvedores do software, uma verdadeira parceria de negócios. Esse nível de engajamento não é para qualquer organização contratante, nem para qualquer desenvolvedor; mas é essencial para fazer um processo adaptativo funcionar corretamente.

Tudo isso traz diversas vantagem para o cliente. Para começar, eles obtêm um desenvolvimento de software muito mais responsivo. Um sistema mínimo, mas já utilizável, pode entrar em produção muito cedo. O cliente pode mudar as funcionalidades à medida que o negócio muda, e também aprender com a forma que o sistema é utilizado na realidade.

Tão importante quanto isso é a maior visibilidade sobre o verdadeiro estado de um projeto. O problema com métodos predeterministas é que a qualidade é medida pela conformidade com o plano. Isso torna difícil para as pessoas sinalizarem quando a realidade e o plano divergem. O resultado usualé um grande atraso no cronograma, posteriormente no projeto. Em um projeto ágil, há um constante retrabalho no plano de projeto com cada iteração. Se más notícias estão à espreita, elas tendem a chegar mais cedo, quando ainda há tempo para se fazer algo a respeito. De fato, esse controle dos riscos é uma vantagem-chave do desenvolvimento iterativo. Métodos ágeis vão um passo além, mantendo as durações dessas iterações curtas, mas também vendo estas variações como oportunidades.

Isso tem um impacto importante sobre o que constitui um projeto bem-sucedido. Um projeto predeterminista normalmente é medido em relação ao cumprimento de seu plano. Um projeto que está dentro do prazo e do custo é considerado bem-sucedido. Essa medida não faz sentido algum em um ambiente ágil. Para os praticantes de metodologias ágeis, a questão é valor no negócio – o cliente obteve um software que vale mais do que o dinheiro que ele empregou em seu desenvolvimento. Um bom projeto predeterminista ocorrerá conforme o plano, um bom projeto ágil irá construir algo diferente e melhor que o plano original previu.

Colocando as Pessoas em Primeiro Lugar

Executar um processo adaptativo não é fácil. Particularmente, exige uma equipe bastante eficaz de desenvolvedores. A equipe precisa ser efetiva tanto na qualidade de seus indivíduos, quanto em como essa equipe interage como um time de verdade. Existe também uma sinergia importante: não apenas a adaptatividade requer uma equipe mais forte, mas também a maioria dos bons desenvolvedores prefere um processo adaptativo.

Conecte 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 tais processos, você pode tratar pessoas como recursos que estão disponíveis de várias formas. Você tem um analista, alguns programadores, alguns especialistas em testes, um gerente. Os indivíduos não são tão importantes, somente suas funções. Desta forma se você planeja um projeto, não importa qual analista ou quais especialistas em testes você vai ter, apenas que você saiba quantos deles você terá, para saber o quanto o número de recursos afetará seu planejamento.

Mais isso levanta uma questão-chave: as pessoas envolvidas em um desenvolvimento de software são peças substituíveis? Uma das principais características das metodologias ágeis é que elas rejeitam tal premissa.

Talvez a rejeição mais explícita ao tratamento de pessoas como recursos seja por Alistair Cockburn. Em seu artigo Caracterizando Pessoas em Desenvolvimento de Software como Componentes de Primeira Ordem, Não-lineares, ele indica que processos predeterministas exigem componentes previsíveis. Entretanto, pessoas não são componentes previsíveis. Mais adiante, seus estudos de projetos de software o levaram a concluir que as pessoas são o fator mais relevante no desenvolvimento de software.

No título, [de seu artigo] eu me refiro as pessoas como "componentes". É assim que as pessoas são tratadas na literatura de processo/metodologia. O engano nesta abordagem é que "pessoas" são altamente variáveis e não-lineares, com fatores de sucesso e fracasso únicos. Esses fatores são de primeira ordem, não negligenciáveis. Falhas em levar em conta esses fatores por parte dos criadores de processos e metodologias contribuem para todo tipo de trajetórias não-planejadas que comumente vemos.
– [Cockburn, não-linear]

Alguém pode se perguntar se própria natureza do desenvolvimento de software não vai contra nós neste caso. Quando estamos programando um computador, controlamos uma máquina inerentemente previsível. Uma vez que estamos nessa profissão por sermos bons nisso, nós temos uma tendência particular em ter muitas dificuldades quando em frente a seres humanos.

Mesmo sendo Cockburn um dos mais explícitos em sua visão do desenvolvimento do software orientado a pessoas, a noção que as pessoas vêm em primeiro lugar é um tema comum entre vários pensadores da área de software. O problema, na maioria das vezes, é que metodologia se opôs à noção que as pessoas são fatores de primeira ordem no sucesso de um projeto.

Isso cria um forte efeito de retro alimentação positiva. Se você espera que seus desenvolvedores sejam unidades de programação substituíveis, você não tenta tratá-los como indivíduos. Isso diminui o moral (e a produtividade). Os bons profissionais procuram um lugar melhor para trabalhar e você termina exatamente com o que você desejou: unidades de programação substituíveis.

Decidir que as pessoas devem vir em primeiro lugar é uma grande decisão, uma destas que requer muita determinação para ser levada adiante. A noção que pessoas são recursos está profundamente arraigada no pensamento de negócios, com suas raízes datando desde a época da Abordagem da Administração Científica de Frederick Taylor. Em se tratando de uma fábrica, o modelo Taylorista pode fazer sentido. Mas para trabalho altamente criativo e profissional, o que acredito que o desenvolvimento de software seja, o modelo não se sustenta. (E, de fato, até mesmo a manufatura moderna já está se afastando do modelo Taylorista).

Programadores são Profissionais Responsáveis

Um conceito-chave da noção Taylorista é que as pessoas que estão fazendo o trabalho não são as melhores pessoas para descobrir qual a melhor forma de fazer este trabalho. Em uma fábrica, isso pode ser verdade por uma série de motivos. Em parte por que muitos trabalhadores fabris não são as pessoas mais inteligentes ou criativas, em parte por que existe uma tensão entre a administração e os trabalhadores a respeito da administração ganhar mais dinheiro enquanto os trabalhadores ganham menos.

A história recente cada vez mais nos mostra o quanto isto é falso no caso do desenvolvimento de software. Cada vez mais pessoas brilhantes e capazes são atraídas ao desenvolvimento de software, atraídas tanto pela sua ostentação como pelas recompensas potencialmente grandes (Ambas as razões que me afastaram da engenharia eletrônica ). Esquemas como os de programas de distribuição de ações cada vez mais alinham os interesses dos programadores com os da empresa.

(Há provavelmente também um efeito de gerações aqui. Evidências circunstanciais me fazem pensar se pessoas mais brilhantes se aventuraram em engenharia de software nos últimos 10 anos. Se sim, essa seria uma razão do porquê há um certo culto à juventude na indústria de computadores. Assim como a maioria dos outros cultos, há de ter um pouco de verdade neste também ).

Quando você quer contratar e reter boas pessoas, você deve reconhecer que eles são profissionais competentes. Assim sendo, elas são as melhores pessoas para decidir como conduzir seus trabalhos técnicos. A noção Taylorista de um departamento de planejamento que decide como as coisas são feitas, só funciona se os planejadores entenderem melhor o problema do que as pessoas o executando. Se você tem pessoas brilhantes e motivadas executando o trabalho, isso não se sustenta.

Gerenciando um Processo Orientado a Pessoas

A orientação a pessoas se manifesta de várias formas em processos ágeis. Isto leva a diversos efeitos, nem todos consistentes.

Um dos elementos-chave é o de aceitação do processo, ao invés da imposição do processo. Normalmente, processos de software são impostos pela administração. Desta forma, estes processos freqüentemente sofrem resistência, particularmente quando a administração está há muito tempo distante da atividade do desenvolvimento de software. Aceitar um processo requer comprometimento, e como tal precisa do envolvimento ativo de toda a equipe.

Isso resulta no fato que apenas os próprios desenvolvedores podem optar por seguirem um processo adaptativo. Isso é particularmente verdade para XP, que requer muita disciplina para ser executado. Isso é onde Crystal é um complemento efetivo, já que objetiva ser minimamente disciplinado.

Outro ponto é que os desenvolvedores devem ser capazes de tomar todas as decisões técnicas. XP vai direto a esse ponto, já que em seus processos de planejamento apenas os desenvolvedores podem fazer estimativas de tempo sobre uma determinado tarefa que será executada.

Tal liderança técnica é uma grande mudança para muitas pessoas em posições gerenciais. Tal abordagem exige um compartilhamento de responsabilidade onde desenvolvedores e gerência têm uma divisão igual na liderança do projeto. Perceba que eu digo igual. A gerência ainda exerce um papel, mas reconhece o conhecimento dos desenvolvedores.

Uma razão importante para essa divisão é a velocidade de mudança das tecnologias em nossa indústria . Depois de poucos anos, o conhecimento técnico se torna obsoleto. Esta meia-vida das habilidades técnicas não tem paralelo em nenhuma outra indústria. Até mesmo os técnicos têm que reconhecer que, ao entrar na área gerencial, suas habilidades técnicas se tornarão obsoletas. Ex-desenvolvedores precisam reconhecer que suas habilidades técnicas desaparecerão rapidamente e precisam confiar nos desenvolvedores atuais.

A Dificuldade de Medição

Se você tem um processo onde as pessoas que dizem como um trabalho deve ser feito não são as mesmas que executam o trabalho de fato, os líderes precisam de alguma forma de medir o quão efetivos são os trabalhadores. Na Administração Científica existia uma forte tendência a desenvolver abordagens objetivas para a medição da produtividade das pessoas.

Isto é particularmente relevante para software, devido à dificuldade de aplicar medições. Mesmo com nossos melhores esforços, somos incapazes de medir até mesmo as coisas mais simples a respeito de software – como por exemplo, produtividade. Sem boas medidas para estas coisas, qualquer tipo de controle externo estará fadado ao fracasso.

Introduzir gerenciamento por medidas, sem boas medidas, leva aos seus próprios problemas. Robert Austin discutiu isso de forma brilhante. Ele aponta que, quando medindo desempenho, você deve levar todos os fatores importantes em conta. Qualquer fator que seja deixado de fora, traz o inevitável resultado de que os trabalhados irão alterar o que produzem para melhor conformidade com as melhores medidas – mesmo que isso claramente reduza a verdadeira efetividade daquilo que fazem. Essa disfunção causada pela medição é o calcanhar de Aquiles do gerenciamento por medidas.

A conclusão de Austin é que você deve escolher entre gerenciamento por medidas e gerenciamento delegativo (onde os trabalhadores decidem como fazer o trabalho). O gerenciamento por medidas é mais adequado para trabalhos simples e repetitivos, com poucos requisitos de conhecimento e com produção facilmente mensurável – exatamente o oposto do desenvolvimento de software.

O ponto disso é que os métodos tradicionais têm operado sob a premissa que o gerenciamento por medidas é a maneira mais eficiente de se gerenciar. A comunidade ágil reconhece que as características do desenvolvimento de software são tais, que o gerenciamento por medidas leva a altos índices de disfunção nestas medidas. Na verdade, é mais eficiente utilizar um estilo delegativo de gerenciamento – este é o tipo de abordagem que está no centro focal das metodologias ágeis.

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 nas necessidades de negócio. Isso leva a outro aspecto importante dos processos adaptativos: eles precisam de contato próximo ao conhecimento de negócio.

Isso vai além do envolvimento do negócio usual na maioria dos projetos hoje. Equipes ágeis não podem existir com comunicação ocasional. Elas precisam de acesso contínuo ao conhecimento de negócio. Além disso, este acesso não é algo que é administrado em nível gerencial, e sim algo que está presente para cada desenvolvedor. Uma vez que os desenvolvedores são profissionais capazes em suas próprias áreas de conhecimento, eles precisam trabalhar como iguais com os outros profissionais das outras áreas de conhecimento.

Uma grande parte disso, é claro, é devido à natureza do desenvolvimento adaptativo. Uma vez que toda a premissa do desenvolvimento adaptativo é que as coisas mudam rapidamente, você precisa de contato constante para tornar as mudanças visíveis a todos.

Não há nada mais frustrante para um desenvolvedor que alguém ver seu trabalho duro desperdiçado. Então, é importante assegurar que conhecimento de negócio de qualidade esteja não só disponível ao desenvolvedor, mas que também seja de suficiente qualidade para que seja confiável.

O Processo Auto-Adaptativo

Até agora, eu falei sobre adaptatividade no contexto de um projeto adaptando seu software para atender aos requisitos mutáveis de seus clientes. Entretanto, há um outro ângulo para a adaptatividade: o próprio processo mudar ao longo do tempo. Um projeto que se inicia utilizando um processo adaptativo não terá o mesmo processo um ano depois. Com o tempo, a equipe vai encontrar aquilo que funciona para ela, e alterar o processo de acordo.

A primeira parte da auto-adaptatividade são revisões regulares do processo. Normalmente você as faz ao fim de cada iteração. No fim de cada uma delas, tenha uma reunião curta e faça as seguintes perguntas (coletadas por Norm Kerth):

O que fizemos bem?
O que aprendemos?
O que podemos fazer melhor?
O que nos intriga?

Estas perguntas levarão a idéias para mudar o processo para a próxima iteração. Desta forma, o processo que inicia com problemas pode melhorar à medida que caminha, adaptando-se de forma melhor à equipe que o utiliza.

Se a auto-adaptatividade ocorre dentro de um projeto, ela é ainda mais marcante dentro da organização. Para aprofundar o processo de auto-adaptatividade, eu sugiro que as equipes façam uma revisão mais formal ao final de grandes marcos do projeto, seguindo as sessões retrospectivas descritas por Norm Kerth. Essas retrospectivas envolvem um encontro de 2 a 3 dias fora da empresa, com um facilitador treinado. Elas não somente ensinam a equipe, mas também ensinam a organização como um todo .

A conseqüência da auto-adaptatividade é que você nunca deveria esperar encontrar uma metodologia corporativa única. Ao invés disso, cada equipe deve, não apenas escolher seu próprio processo, mas também ativamente ajustar seus processos à medida que avançam no projeto. Processos publicados e a experiência de projetos anteriores podem agir como inspiração e uma linha-mestre, mas é responsabilidade profissional dos desenvolvedores adaptarem o processo à tarefa atual.

Essa auto-adaptatividade é mais marcante em ASD e Crystal. As regras rígidas do XP parecem proibi-la, mas isso é apenas uma impressão superficial, uma vez que XP, de fato, estimula ajustes no processo. A principal diferença é que seus proponentes sugerem segui-la literalmente por diversas iterações, antes de adaptá-la. Além disso, revisões não são nem encorajadas, nem são parte do processo, apesar de haver sugestões que revisões sejam incorporadas como umas das práticas do XP.

As Metodologias

Várias metodologias estão dentro da categoria ágil. Enquanto todas elas compartilham algumas características, também existem algumas diferenças significativas entre elas. Eu não posso ilustrar todos os pontos importantes neste breve estudo, mas pelo menos posso apontar alguns lugares para buscar mais informações. Eu também não posso falar com experiência significativa sobre a maioria destas metodologias. Eu trabalhei muito baseado em XP, e vi diversas formas de RUP mas, para a maioria das outros pessoas, meu conhecimento acadêmico não é o mais adequado.

XP (Programação Extrema)

De todas as metodologias ágeis, essa é a que atrai mais atenção. Parcialmente pela notável habilidade de seus líderes, particularmente Kent Beck, de atraírem atenção. É também pela habilidade de Kent Beck em atrair pessoas para sua abordagem, e exercer um papel de liderança nela. De alguma forma, entretanto, a popularidade do XP se tornou um problema, já que deixou de atrair pessoas para as outras metodologias e suas idéias valiosas.

As raízes do XP estão na comunidade Smalltalk, e em particular na colaboração estreita entre Kent Beck e Ward Cunningham no final da década de 1980. Ambos refinaram suas práticas em diversos projetos durante a década de 90, estendendo suas idéias para uma abordagem do desenvolvimento de software que fosse tanto adaptativa, quanto orientada a pessoas.

O passo crucial para a passagem da prática informal para metodologia ocorreu na primavera de 1996. Kent foi chamado para revisar o progresso no projeto C3, o controle de folha de pagamento da Chrysler. O projeto estava sendo desenvolvido em Smalltalk por uma empresa terceirizada, e estava em problemas. Devido à baixa qualidade do código, Kent recomendou jogar tudo fora e reiniciar do zero. O projeto então foi reiniciado sob sua liderança e, desde então, se tornou a bandeira e o campo de treinamento para o XP.

A primeira fase do C3 foi muito bem-sucedida e este entrou em produção no início de 1997. O projeto continuou desde então e entrou em dificuldades posteriormente, o que resultou no cancelamento de qualquer desenvolvimento adicional em 1999 (o que, se nada mais, pelo menos prova que XP não é garantia de sucesso).

XP começa com quatro valores: comunicação, feedback, simplicidade e coragem. Depois disso, são construídas 12 práticas que os projetos XP devem seguir. Muitas dessas práticas são técnicas antigas e testadas, entretanto muitas vezes esquecidas por muitos – inclusive pela maioria dos processos planejados. Além de ressuscitar essas técnicas, XP as tem como um todo sinérgico, onde cada técnica reforça as outras.

Uma das técnicas mais notáveis, pelo menos inicialmente atraente para mim , é a forte ênfase nos testes. Enquanto todos os processos mencionam a verificação através de testes, a maioria a faz de forma pouco enfática. Entretanto, XP a coloca na base do desenvolvimento, com cada programador escrevendo testes à medida que escrevem código de produção. Os testes são integrados em um processo de integração contínua e construção (build), o que leva a uma plataforma altamente estável para desenvolvimento futuro.

Nesta plataforma, XP constrói um processo de design evolutivo que se baseia em refactoring de uma base de código simples a cada iteração. Todo o design é centrado na iteração atual, sem que nada seja feito para necessidades futuras antecipadas. O resultado é um processo de design que é disciplinado, e ainda mais, combinando disciplina com adaptatividade – de uma forma que pode ser considerada a mais bem desenvolvida de todas as metodologias adaptativas.

XP desenvolveu uma liderança muito ampla, muitos destes líderes provenientes do projeto C3 original. Como resultado, existem muitas fontes para mais informações. Kent Beck escreveu Extreme Programming Explained, o manifesto-chave para XP, que explica todo o raciocínio por trás da metodologia e contém explicações suficientes para que as pessoas saibam se estão interessadas em seguir adiante. Nos últimos anos houve um crescimento epidêmico de livros de XP, vários deles muito similares, no sentido que descrevem todo o processo do ponto de vista dos vários pioneiros na adoção do XP.

Assim como livros, há um número razoável de recursos na Web. Para encontrar uma abordagem mais estruturada ao XP, é melhor começar pelos dois sites dos ex-participantes do C3: xProgramming.com , de Ron Jeffries e extremeProgramming.org , de Don Wells. Muitas das descobertas e idéias iniciais ocorreram na wiki de Ward Cunningham , um ambiente web de escrita colaborativa. A Wiki se mantém como um lugar fascinante para descobertas, mesmo com sua natureza divagante, que acaba muitas vezes envolvendo um pouco demais. Existe um grupo de discussão ativo e freqüentemente interessante. Uma das visões mais interessantes "de fora" do XP é a de Mark Paulk, um dos líderes da comunidade CMM – seu artigo analisa XP de uma perspectiva CMM.

Família Crystal de Cockburn

Alistair Cockburn trabalha com metodologias desde que foi contratado pela IBM para escrever sobre o assunto, no início da década de 90. Sua abordagem difere da utilizada pela maioria dos estudiosos de metodologias. Ao invés de acumular experiência pessoal e construir uma teoria de como as coisas devem ser feitas, ele suplementa sua experiência direta com uma busca ativa por pesquisar projetos e ver como eles funcionam. Além disso, ele não tem medo de alterar suas visões baseado em suas descobertas: tudo isso o fez meu estudioso de metodologias favorito.

Seu livro, Sobrevivendo a Projetos Orientados a Objetos, foi seu primeiro conselho sobre como executar projetos, e continua como minha recomendação número um sobre como executar projetos iterativos. Mais recentemente, Alistar escreveu um livro com uma visão geral de desenvolvimento de software ágil que analisa os princípios fundamentais por trás dessas metodologias.

Depois deste livro, ele explorou metodologias ágeis ainda mais, criando a família Crystal de metodologias. É uma família, pois ele acredita que diferentes tipos de projetos exigem diferentes tipos de metodologias. Ele olha para esta questão sob dois eixos:pelo número de pessoas no projeto e pelas conseqüências dos erros. Cada metodologia se encaixa em uma parte diferente do gráfico, logo um projeto de 40 pessoas que pode perder dinheiro indiscriminadamente tem uma metodologia diferente de um projeto tipo missão-crítica de seis pessoas.

As metodologias Crystal compartilham a orientação humana tal como XP, mas sua orientação a pessoas é feita de forma diferente. Alistar considera que pessoas consideram difícil seguir um processo disciplinado, então ao invés de seguir a rígida disciplina do XP, Alistar explora o método menos disciplinado possível que possa ainda assim ser bem sucedido, conscientemente trocando produtividade por facilidade de execução. Assim, ele considera que apesar do Crystal ser menos produtivo que XP, mais pessoas estarão aptas a segui-lo.

Alistair atribui muita importância às revisões no final das iterações, assim encorajando o processo a ser auto-melhorável. Sua afirmação é que desenvolvimento iterativo existe para detectar problemas cedo, e então habilitar as pessoas a corrigi-los. Isso coloca mais ênfase em pessoas monitorando e ajustando o processo à medida que se desenvolvem.

Código Aberto

Talvez você esteja surpreso com este título. Afinal, código aberto é um estilo de software, não muito um processo. Entretanto, definitivamente existe um jeito de se fazer as coisas na comunidade do código aberto, e muito de sua abordagem é aplicável para projetos de código fechado também. Em particular, seus processos são habilitados para equipes fisicamente distribuídas, o que é importante, pois a maioria dos processos adaptativos são focados em equipes locais.

A maioria dos projetos de código aberto tem um ou mais mantenedores. Um mantenedor é a única pessoa permitida para efetivar uma mudança no repositório do código aberto. Entretanto, outras pessoas, que não o mantenedor, podem mudar o código. A diferença-chave é que as outras pessoas precisam mandar suas mudanças a ele, que revisa e então as efetiva. Normalmente essas mudanças são feitas no formato de arquivos depatch com a correção, o que facilita o processo. O mantenedor então é responsável por coordenar essas correções e manter a coesão do design do software.

Projetos diferentes lidam com o papel do mantenedor de formas diferentes. Alguns têm um mantenedor para todo o projeto, alguns dividem o projeto em módulos e têm um mantenedor por módulo; alguns revezam o mantenedor; alguns têm múltiplos mantenedores para o mesmo código; outros combinam essas idéias. Muitas das pessoas que trabalham com código aberto não o fazem em período integral. Logo, existem problemas sobre o quão bem tais equipes poderiam ser coordenadas em um projeto de tempo integral.

Uma característica própria do desenvolvimento de código aberto é que a depuração é altamente passível de ser realizada em paralelo. Muitas pessoas podem estar envolvidas na depuração. Quando elas encontram um defeito, mandam uma correção ao mantenedor. Esta é uma boa regra para não-mantenedores, já que a maior parte do tempo gasto é para encontrar o defeito. Também é bom para as pessoas envolvidas que não têm muita habilidades em design.

O processo utilizado em código aberto ainda não está bem descrito. O artigo mais famoso é o de Eric Raymond, A Catedral e o Bazar, que enquanto excelente ainda é razoavelmente breve. O livro de Karl Fogel sobre o repositório CVS também contêm uma séria de bons capítulos a respeito do processo em código aberto, que seriam interessantes mesmo para aqueles que jamais utilizaram o software CVS.

Desenvolvimento de Software Adaptativo de Highsmith

Jim Highsmith passou diversos anos trabalhando com metodologias predeterministas. Ele desenvolveu, instalou, ensinou e concluiu que tais metodologias são profundamente falhas: particularmente para empresas modernas.

Seu livro mais recente foca na natureza adaptativa de novas metodologias, com uma ênfase particular em aplicar idéias originantes do mundo dos sistemas complexos adaptativos (comumente conhecidos como teoria do caos). A metodologia não provê práticas detalhadas como o XP faz, mas traz o fundamento do porquê o desenvolvimento adaptativo é importante, e as conseqüências nos níveis organizacionais e administrativos mais profundos.

No coração do ASD (Adaptative Software Development) estão três fases não-lineares e sobrepostas: especulação, colaboração e aprendizado.

Highsmith vê o planejamento como um paradoxo em um ambiente adaptativo, uma vez que os produtos são naturalmente imprevisíveis. No planejamento tradicional, desvios dos planos são enganos e devem ser corrigidos. Em um ambiente adaptativo, entretanto, desvios nos guiam à solução correta.

Neste ambiente imprevisível você precisa de pessoas colaborando de forma rica pra lidar com a incerteza. A atenção da administração é menor a respeito de dizer às pessoas o que fazer, e maior a respeito de estimular a comunicação, para que as pessoas possam criar soluções criativas por conta própria.

Em ambientes predeterministas, o aprendizado normalmente é desestimulado. As coisas são planejadas de antemão e depois seguem o design estipulado.

Em um ambiente adaptativo, o aprendizado desafia todos os envolvidos no projeto – desenvolvedores e seus clientes – a examinar suas premissas e a utilizar os resultados de cada ciclo de desenvolvimento para adaptar o seguinte.
– [Highsmith]

Dessa forma, o aprendizado é uma característica contínua e importante, que assume que os planos e designs devem mudar à medida que o desenvolvimento avança.

O benefício principal, poderoso, indivisível, e predominante do ciclo de vida do Desenvolvimento Adaptativo é que ele nos força a confrontar nossos modelos mentais, que estão na raiz de nossas próprias ilusões. Ele nos força a estimar nossa habilidade de forma mais realista.
– [Highsmith]

Com esta ênfase, o trabalho de Highsmith foca diretamente em abordar as partes difíceis do desenvolvimento adaptativo, em particular em como lidar com a colaboração e o aprendizado dentro do projeto. Desta forma, seu livro ajuda a prover idéias para explorar essas áreas "soft", o que faz que seja um bom complemento para as abordagens baseadas em práticas fundamentadas, tais como XP, FDD e Crystal.

Scrum

Scrum está presente ha algum tempo em círculos da comunidade de orientação a objetos, entretanto confesso que não tenho muito conhecimento de sua história ou desenvolvimento. Novamente, foca que processos definidos e repetíveis só funcionam para atacar problemas definidos e repetíveis com pessoas definidas e repetíveis em ambientes definidos e repetíveis.

Scrum divide um projeto em iterações (chamadas de sprints) de 30 dias. Antes de iniciar um sprint, você define a funcionalidade requerida para o sprint e então deixa a cargo do time para implementar tais funcionalidades. O ponto é estabilizar os requisitos durante o sprint.

Entretanto, a administração não perde o envolvimento durante o sprint. Todo dia, a equipe tem uma pequena reunião (15 minutos), chamada de scrum, onde ela passa por tudo que vai fazer no próximo dia. Em particular, eles fazem transparecer os impedimentos administrativos: impedimentos que dificultam o avanço, e que a gerência precisa resolver. Eles também reportam o que está sendo feito para que a gerência tenha uma atualização diária sobre em que ponto o projeto se encontra.

A literatura sobre Scrum foca principalmente no planejamento iterativo e em processos de acompanhamento. É muito parecida com outras metodologias ágeis em diversos aspectos, e deve funcionar bem com as práticas de programação do XP.

Depois de muito tempo sem um livro, Ken Schwaber e Mike Beedle escreveram o primeiro livro sobre Scrum. Ken Schwaber também administra o site controlchaos.com, que é provavelmente a melhor visão geral do Scrum. Jeff Sutherlan sempre teve um site bastante ativo sobre tecnologia de objetos e inclui uma sessão sobre Scrum. Há também uma boa visão geral das práticas do Scrum no livro PloPD4. Scrum também tem um grupo de discussão no Yahoo.

Desenvolvimento Orientado a Funcionalidades

(Feature Driven Development, FDD) foi desenvolvido por Jeff De Luca e pelo, a longo tempo guru de orientação a objetos, Peter Coad. Assim como as outras metodologias adaptativas, foca em iterações curtas e em entregar funcionalidade tangível. No caso do FDD, as iterações têm duas semanas de duração.

FDD tem cinco processos. Os três primeiros são executados no início do projeto:

Desenvolver um modelo geral;
Construir uma lista de funcionalidades;
Planejar por funcionalidade.

Os dois últimos são feitos em cada iteração:

Design por funcionalidade;
Construção por funcionalidade.

Cada processo é dividido em tarefas e lhe são atribuídos critérios de validação.

Existem então dois tipos de desenvolvedores: os proprietários de classes e os programadores-chefe. Os programadores-chefe são os desenvolvedores mais experientes. A eles são atribuídos funcionalidades a serem construídas. Entretanto, eles não as constroem sozinhos. Ao invés disso, o programador-chefe identifica quais classes estão envolvidas para se desenvolver a funcionalidade e reúne seus proprietários de classes, criando uma equipe para desenvolver aquela funcionalidade. O programador-chefe age como um coordenador, designer líder e mentor, enquanto os proprietários de classes fazem a maior parte da programação das funcionalidades.

Até recentemente, a documentação do FDD era muito escassa. Finalmente há um livro completo sobre FDD. Jeff De Luca, o inventor principal, agora tem um portal com artigos, blogs e painéis de discussão. A descrição original está no livro UML em Cores, de Peter Coad. A sua empresa, TogetherSoft, também dá consultoria e treinamento em FDD .

DSDM (Método para Desenvolvimento de Sistemas Dinâmicos)

DSDM (Dynamic System Development Method) começou na Inglaterra em 1994 como um consórcio de empresas britânicas que queriam construir algo em cima do conceito de RAD (Rapid Application Development, ou Desenvolvimento Rápido de Aplicações) e desenvolvimento iterativo. Começando com 17 fundadores, agora tem mais de mil membros e cresceu além de suas raízes britânicas. Sendo desenvolvida por um consórcio, ela parece diferente das outros metodologias ágeis. Há uma organização em tempo integral por trás dela dando suporte, com manuais, programas de certificação, e similares. Há também um custo associado, o que limitou minhas investigações na metodologia. Entretanto, Jennifer Stapleton escreveu um livro que dá uma visão geral da metodologia.

Utilizar o método começa com um estudo de viabilidade e um estudo de negócio. O estudo de viabilidade considera se o DSDM é adequado ao projeto em questão. O estudo de negócio é uma pequena série de workshops para entender a área de negócio sobre a qual o desenvolvimento acontecerá. Ele também propõe esboços da arquitetura do sistema e um plano de projeto.

O resto do processo forma três ciclos interligados: o ciclo do modelo funcional, onde se analisa a documentação e protótipos; o ciclo de design e construção, onde o sistema é construído para uso operacional; e o ciclo de implementação, onde é resolvido o problema da implantação para uso operacional.

DSDM tem princípios básicos que incluem interação ativa do usuário, entregas freqüentes, equipes autônomas, e testes ao longo do ciclo. Como outras metodologias ágeis, usa ciclos de tempo fixo entre duas e seis semanas. Há uma ênfase na alta qualidade e na adaptabilidade para requisitos mutáveis.

Eu não tenho visto muitos indícios de seu uso fora do Reino Unido, mas DSDM é notável por possuir bastante da infra-estrutura das metodologias mais tradicionais, enquanto segue os princípios das abordagens ágeis. Parece existir uma questão se seus materiais encorajam uma maior orientação a processo e mais cerimônia que eu gostaria .

O Manifesto para Desenvolvimento Ágil de Software

Com tantas similaridades entre essas metodologias, houve um razoável interesse em alguma forma de trabalho coletivo. Dessa forma, os representantes de cada uma dessas metodologias foram convidados para um workshop de dois dias em Snowbird, Utah em fevereiro de 2001. Eu assisti, sem muitas expectativas. Afinal, quando você coloca alguns estudiosos de metodologias em uma sala, civilidade é normalmente o melhor que você pode esperar.

O resultado final é que acabei me surpreendendo . Todos estavam conscientes do fato de haver muito em comum, e esse reconhecimento era muito maior que as diferenças entre os processos. Então, assim como um contato útil entre os líderes dos processos, ainda havia a idéia de fazer uma declaração única – um chamado a favor de mais processos de software ágeis (nesta ocasião também concordamos em usar o termo "ágil" para nossas idéias em comum.)

O resultado é o Manifesto para Desenvolvimento Ágil de Software, uma declaração de valores comuns e princípios de processos ágeis. Há também um desejo de colaborar ainda mais no futuro, para encorajar não somente tecnólogos, mas também pessoas de negócios para usar e requerer abordagens ágeis para o desenvolvimento de software. Há um artigo em uma revista de desenvolvimento de software que é um comentário e explicação sobre o manifesto.

O manifesto era apenas isso, uma publicação que agia como um ponto de partida para aqueles que compartilhavam as mesmas idéias básicas. Um dos frutos deste esforço foi a criação de uma entidade mais permanente, a Aliança Ágil. A Aliança Ágil é uma organização sem fins lucrativos que procura promover o conhecimento e discussão sobre todas as metodologias ágeis. Muitos dos líderes do movimento ágil que mencionei, são também membros da Aliança Ágil.

Verificação Orientada ao Contexto

Desde o início, tem sido os desenvolvedores que conduzem a comunidade ágil. Entretanto, muitas das outras pessoas envolvidas em desenvolvimento de software são afetadas por este novo movimento. Um desses grupos óbvios são os especialistas em testes, que freqüentemente vivem em um mundo contido no pensamento do desenvolvimento em cascata. Com direcionamentos comuns que dizem que o papel dos testes é de assegurar que o software está de acordo com a especificação prévia, o papel dos especialistas em testes em um mundo ágil fica longe de estar claro.

De fato, várias pessoas na comunidade de testes têm questionado muito do pensamento vigente sobre testes por algum tempo. Isso levou a um grupo conhecido como verificação orientada ao contexto. A melhor descrição para isso é o livro Lições Aprendidas em Verificação de Software. A comunidade é também muito ativa na Web, veja os sites organizados Brian Marick (um dos autores do manifesto ágil), Brett Pettichord, James Bach e Cem Kaner.

RUP é uma metodologia ágil?

Independentemente de quando começarmos a discutir sobre metodologias no campo da orientação a objetos, inevitavelmente nos depararemos com o papel do Rational Unified Process (RUP). O Processo Unificado foi desenvolvido por Philippe Kruchten, Ivar Jacobson e outros da Rational, como o complemento de processo ao UML. RUP é uma plataforma processual, e como tal pode acomodar uma vasta variedade de processos. De fato, essa é minha principal crítica ao RUP – algo que pode ser tudo, acaba não sendo nada. Eu prefiro um processo que lhe diga o que fazer ao invés de um que lhe ofereça opções intermináveis.

Como resultado dessa mentalidade de plataforma processual, RUP pode ser usado em uma maneira bastante tradicional, como desenvolvimento em cascata, ou também de forma ágil. Logo, como resultado você pode usar RUP como um processo ágil ou como um processo tradicional – tudo depende de como você o adapta para seu ambiente.

Craig Larman é um forte defensor de se utilizar RUP de maneira ágil. Seu excelente livro introdutório sobre desenvolvimento orientado a objetos contém um processo bastante fundamentado em seu pensamento RUP. Sua visão é que muito da corrente atual a favor das metodologias ágeis nada mais é que o aceite do desenvolvimento orientado a objetos, que já foi capturado no RUP. Uma das coisas que Craig faz é investir os primeiros dois ou três dias de uma iteração de um mês com todo o time, usando UML para esboçar o trabalho a ser feito durante a iteração. Isso não é um plano de projeto que não pode ser desviado, mas sim um esboço que dá perspectiva às pessoas de como fazer as coisas durante a iteração.

Outra abordagem ao RUP ágil é o processo dX, de Robert Martin. O processo dX é uma instância totalmente conforme com RUP, que simplesmente é idêntica ao XP (vire dX de ponta-cabeça para entender a brincadeira). dX foi projetada para pessoas que tem que usar RUP, mas gostariam de estar usando XP. Como tal, é tanto XP como RUP e, portanto, um bom exemplo de um uso ágil do RUP.

Para mim, uma das principais coisas que precisa acontecer ao RUP é que seus líderes na indústria precisam enfatizar suas abordagens ao desenvolvimento de software. Mais de uma vez eu vi pessoas utilizarem RUP juntamente com um processo de desenvolvimento estilo cascata. Graças a meus contatos na indústria, eu sei que Philippe Krutchen e sua equipe são seguidores fiéis do desenvolvimento iterativo. Tornar claro esses princípios e encorajar instâncias ágeis de RUP, tais como as de Craig e Robert, teriam um efeito importante.

Outras Fontes

Recentemente vimos dois bons livros surgirem que analisam o tópico amplo de metodologias ágeis, de Alistair Cockburn e Jim Highsmith.

Há uma série de outros artigos e discussões sobre o tema de metodologias ágeis. Enquanto estes podem não ser metodologias completas, eles oferecem insights neste campo em expansão.

As conferências Linguagem de Padrões de Programação freqüentemente têm artigos que tocam neste assunto, mesmo que somente por que muitas das pessoas interessadas em padrões também estão interessadas em métodos mais humanos e adaptativos. Um artigo pioneiro foi o de Jim Coplier na PLoP1. A linguagem de padrões Episódios, de Ward Cunningham apareceu na PloP2. Jim Complein agora mantém o site orgPatterns, uma wiki que coleta padrões organizacionais.

Dirk Riehle mandou um artigo para XP2000 que compara os sistemas de valores do XP e do Desenvolvimento de Software Adaptativo. A edição de fevereiro de 2002 do periódico de Coad compara XP a FDD. A edição de julho da IEEE Software inclui vários artigos sobre "diversidade de processos" que menciona essas metodologias.

Mary Poppendieck escreveu um artigo fascinante comparando metodologias ágeis com a manufatura estilo lean.

Você deve se tornar ágil?

Usar uma metodologia ágil não é para todos. Existem várias coisas para se ter em mente se você decidir trilhar este caminho. Entretanto, eu sem dúvida acredito que estas novas metodologias são amplamente aplicáveis e deveriam ser utilizadas por mais pessoas que hoje consideram em fazê-lo.

No ambiente de hoje, a metodologia mais comum é a de codificar e consertar. Aplicar mais disciplina que o caos certamente irá ajudar, e a abordagem ágil tem a vantagem de ser um passo muito menos largo que usar uma metodologia pesada. Aqui, uma das principais vantagens das metodologias ágeis é justamente sua leveza. Processos simples são muito mais propensos de serem seguidos quando você está acostumado a eles, do que nenhum processo.

Uma das maiores limitações destas novas metodologias é como elas lidam com times grandes. Como muitas novas abordagens, elas tendem a ser utilizadas primeiramente em pequena escala. Também freqüentemente são criadas com ênfase em equipes pequenas. Extreme Programming explicitamente diz que foi feita para equipes de até doze pessoas. Vale a pena lembrar que muitas equipes de software poderiam ser reduzidas em tamanho sem reduzir a produtividade geral.

Outras abordagens ágeis são dirigidas para equipes maiores. FDD foi originalmente projetada para um projeto de cinqüenta pessoas. A ThoughtWorks utilizou projetos influenciados por XP com uma equipe de aproximadamente 100 pessoas, em três continentes. Scrum também já foi utilizado para lidar com projetos de equipes com tamanhos similares.

Espero que uma mensagem que tenha ficado clara com este artigo é a de que processos adaptativos são bons quando os requisitos são incertos ou voláteis. Se você não tem requisitos estáveis, então você não está na posição de ter um design estável e seguir um processo planejado. Nestas situações, um processo adaptativo pode ser menos confortável, mas será mais efetivo. Normalmente aqui a maior barreira é o cliente. Na minha visão, é importante para o cliente entender que seguir um processo predeterminante quando os requisitos mudam é tão arriscado pra eles quanto para a equipe de desenvolvimento.

Se você for trilhar a rota adaptativa, você precisa confiar em seus desenvolvedores e envolvê-los na decisão. Processos adaptativos se baseiam em você confiar em seus desenvolvedores, então se você considera que seus desenvolvedores são de baixa qualidade e motivação, então você deve usar uma abordagem predeterminista.

Então, para sumarizar: os seguintes fatores sugerem um processo adaptativo:

Requisitos incertos ou voláteis;
Desenvolvedores responsáveis e motivados;
Cliente que entende e irá se envolver.

Estes fatores sugerem um processo predeterminista:

Uma equipe com mais de 100 pessoas;
Um contrato de preço fixo, ou, mais corretamente, de escopo fixo

Agradecimentos

Eu peguei muitas idéias de outras pessoas para este artigo, mais do que poderia aqui listar. Por sugestões concretas, eu gostaria de agradecer Marc Balcer, Kent Beck, Alistair Cockburn, Ward Cunningham, Bill Kimmel e Fran Westphal.

Lembre-se que este é um artigo da web em evolução e provável de ser mudado sempre que eu tiver a inclinação em assim fazer. Eu irei adicionar um registro para mudanças significativas, entretanto mudanças pequenas poderão ocorrer sem aviso.

Histórico de Revisões

Eis uma lista das revisões importantes deste artigo:

Abril de 2003: Várias sessões revisadas. Adicionada a sessão sobre dificuldade de medição e verificação orientada a contexto.
Junho de 2002: Referências atualizadas.
Novembro de 2001: Algumas referências recentes atualizadas.
Março de 2001: Atualizado para refletir a aparição da Aliança Ágil.
Novembro de 2000: Atualizada a sessão sobre ASD e adicionadas as sessões sobre DSDM e RUP.
Dezembro de 2000: Versão editada publicada na revista Software Development, sob o título de "Put your Process on a Diet".
Julho de 2000: Publicação original em martinfowler.com.

Tags BlogBlogs: metodologias, ageis, metodologias ageis, scrum, xp