O Agile Manifesto (Manifesto Ágil) e a Empresa

publicado em 29.09.2008

Em fevereiro de 2001, dezessete programadores de software se reuniram num resort de ski, em Utah, EUA, para relaxar e trocar idéias.  O que emergiu deste encontro foi o Agile Software Development Manifesto.

Representantes das comunidades de Extreme Programming, SCRUM, DSDM, Adaptative Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, e outros simpatizantes da necessidade de uma alternativa ao desenvolvimento de processos de software pesado, e guiado por documentação, promoveram uma convenção.

A melhor definição da origem deste manifesto/movimento pode ser encontrada no blog de Martim Fowler, um dos fundadores signatários do manifesto.  Segundo ele, a   maior   parte  do  desenvolvimento  de  um  software  era  uma  atividade  caótica,

Próxima edição:

O Agile Manifesto (Manifesto Ágil) e a Empresa (parte 2)

publicada em 07.10.2008

E quais são as implicações deste novo movimento da programação de software e sistemas de informação para o design (a estruturação) das empresas start-ups (iniciantes) e on-going (em operação) que desenvolvem ou fazem uso de tecnologias de informação e comunicação- TICs?
Muito tem sido desenvolvido, em termos de iniciativas, conferências...

Edição anterior:

O Problema do Design da Empresa: Definir a Estratégia e a Organização (parte 2)

publicada em 22.09.2008

Na lettericia passada iniciamos uma discussão sobre a questão do design (projeto) da empresa, e citamos o livro "The Modern Firm: Organizational Design for Performance and Growth", produzido pelo Prof. John Roberts, da Escola de Graduação em Negócios da Universidade de Stanford, EUA, e editado pela Oxford University Press, em 2004 (este livro foi traduzido para o português no Brasil com o título..

freqüentemente caracterizada pela frase “codifique e conserte”.  O software era escrito sem um plano subjacente, e o projeto do sistema era toscamente feito junto com  muitas  decisões  de  curto  prazo.  Isto  funcionava bem quando o sistema era pequeno, mas à medida que ele crescia, aumentava-se a dificuldade de adicionar novas características ao sistema. Além do mais, bugs se tornavam prevalentes e com crescente dificuldade de conserto.

O movimento original que tentou mudar isto introduziu a noção de metodologia. Estas metodologias impunham um processo disciplinado sobre o desenvolvimento do software com o objetivo de tornar o desenvolvimento do software mais previsível e mais eficiente.  Elas fazem isto ao desenvolverem um detalhado processo com forte ênfase no planejamento inspirado por outras disciplinas da engenharia- razão pela qual Martim Fowler prefere se referir a elas como metodologias de engenharia (outro termo amplamente utilizado é o de metodologias guiadas por planos).

As metodologias de engenharia têm estado ao nosso redor por algum tempo.  Elas não têm sido notadas por terem sido terrivelmente bem sucedidas.  As mais freqüentes críticas são as de que elas são burocráticas.  Há tanta coisa a fazer para seguir a metodologia, que o passo completo do desenvolvimento é refreado.

As Agile methodologies (metodologias ágeis) foram desenvolvidas como uma reação a estas metodologias. Para muitas pessoas o apelo das metodologias ágeis reside em sua reação à burocracia das metodologias de engenharia. Estas novas metodologias (referidas acima, como representadas no encontro que deu origem ao Agile Manifesto) tentam um compromisso útil entre nenhum processo e muitos processos, oferecendo processos suficientes para ganhar uma razoável recompensa.

O resultado disto tudo é que os métodos ágeis colocaram significativas mudanças na ênfase dos métodos de engenharia.  A mais imediata diferença é que eles são menos guiados por documentação, usualmente enfatizando menos documentação para uma dada tarefa. Em muitas maneiras, eles são mais guiados por códigos: seguem uma rotina que diz que parte da documentação é o código fonte.

Para Martim Fowler, a ausência de documentação é um sintoma de duas mais profundas diferenças:

• Agile methods são adaptativos mais que preditivos: Métodos de Engenharia tendem a tentar planejar uma grande parte do processo de software em grande detalhe por um longo período de tempo, e isto funciona bem até que as coisas mudem.  Deste modo, sua natureza é resistir às mudanças.  Os métodos ágeis, no entanto, dão boas vindas às mudanças. Eles tentam ser processos que se adaptam e promovem mudanças, ao ponto de mudarem eles mesmos;

• Agile methods são orientados por pessoas mais que orientados a processos. O objetivo dos métodos de engenharia é definir um processo que funcione bem independente de quem esteja usando ele.  Os métodos ágeis asseveram que nenhum processo irá jamais produzir a habilidade do time de desenvolvimento, de modo que o papel de um processo é dar suporte ao time de desenvolvimento em seu trabalho.

E quais são as implicações deste novo movimento da programação de software e sistemas de informação para o design (a estruturação) das empresas start-ups (iniciantes) e on-going (em operação) que desenvolvem ou fazem uso de tecnologias de informação e comunicação-TICs?  É o que vamos ver na próxima letterícia!

Se sua empresa, organização ou instituição deseja saber mais sobre métodos ágeis de desenvolvimento de software e seus impactos na sua estruturação, sinta-se a vontade para nos contatar!

CREATIVANTE - www.creativante.com.br
Av. Barbosa Lima, Nº149, Sala 313-A, Bairro do Recife, Recife/PE, CEP 50.030-017
Telefone/Fax: 55-81-32242887
E-mail: creativante@creativante.com.br