peguei esse artigo do site imasters.

é mais para o pessoal do desenvolvimento , mas achei super interessante vale a pena ler

Nesse artigo vou falar um pouco sobre a metodologia ágil de desenvolvimento de software e mostrar por que vale a pena seguir essa visão nos dias de hoje.

O desenvolvimento de tecnologia de software é uma área bem diferente do desenvolvimento de coisas palpáveis, como carros e máquinas, e esse foi o erro de gerentes de projetos por muito tempo, e continua sendo em muitos casos até hoje.

Antigamente os projetos eram gerenciados de maneira totalmente arcaica, mas isso não era culpa dos gerentes, pois informática nessa época era um conceito novo, logo não tinham base suficiente para isso. Para se ter uma idéia, os desenvolvedores envolvidos nos projetos eram pagos e avaliados pelo número linhas de códigos escritos, hoje sabemos que é impossível medir desempenho de trabalho dessa maneira. Com o passar dos anos, foram corrigidos vários itens como esse. Mas muitos conceitos ainda estão fortes no mercado atual. A metodologia de desenvolvimento atual prega alguns dos itens a seguir:

• A determinação de um prazo para o projeto inteiro no início do projeto;
• Uma documentação é escrita antes do desenvolvimento e aborda todos os requisitos do mesmo;
• Ter forte ênfase nas tarefas e processos do projeto

Se o leitor estiver se perguntando: "mas o que há de errado nisso?", então ainda participa de projetos feitos à moda antiga...

Vamos analisar alguns porquês de essa visão falhar e mostrar, para cada item, como é a visão no conceito de desenvolvimento ágil.

Na prática, os prazos determinados podem falhar, principalmente quando é um projeto inovador, ou o projeto é para imbutir alguma feature em um projeto que esteja funcionando e essa feature tenha um foco totalmente bem diferente do sistema inteiro, e mesmo com todos os métodos atuais para a definição de prazos, eles continuam sendo a tarefa que mais precisa da experiência para sua ênfase, ou seja, quanto mais projetos realizados, mais próximo de um prazo certo teremos. Com métodos ágeis de desenvolvimentos, esse erro quase não ocorre, visto que os prazos dados são apenas para coisas em curto prazo do projeto, pegamos partes do projeto que são mais relevantes para o cliente, sem levar em conta a dificuldade para realizá-la, e damos um prazo estimado apenas para ela, geralmente varia entre 1 e 3 semanas, e esse prazo leva em consideração o momento atual da equipe, ou seja, como está fluindo o projeto atual naquele instante, dessa forma o prazo para uma mesma entrega pode variar dependendo da época em que foi analisada.

Sobre a documentação, não estou dizendo que é algo inútil, muito pelo contrário, documentar um projeto é bom, mas não da forma que é feita (no início e de forma global), ter um projeto documentado após um projeto é importante, mas sua realização não deve ser feita no final do projeto, pois muita coisa pode ser esquecida. A forma de documentação feita no início de projetos acarreta em tempo que em muitos projetos é perdido pelo fato de um projeto comum tomar outros rumos no decorrer do desenvolvimento, e aquela documentação perde a validade pela desatualização parcial ou total em relação ao que foi feito. Então o ideal seria uma documentação feita em paralelo ao desenvolvimento, pois assim temos uma documentação correta e sem perda de tempo. E ainda mais! A documentação que fizermos tem que ser algo útil, ou seja, não pode ser aquele tipo de documentação onde metade dela nunca mais será consultada (geralmente ocorre no modelo atual), uma documentação boa tem conteúdo relevante.

Sobre a ênfase em tarefas, esse é um dos pontos que evoluíram como os conceitos de administração de empresas, pois da mesma forma que no inicio dos conceitos administrativos tínhamos Taylor com sua administração que era voltada para os processos, (vejam no wikipedia: http://pt.wikipedia.org/wiki/Frederick_Taylor), com o passar do tempo, vieram pensadores administrativos com as idéias e pensar no funcionário, ou seja, ênfase nas pessoas (vejam no wikipedia: http://pt.wikipedia.org/wiki/Teoria_das_relações_humanas). Métodos ágeis têm foco nas pessoas e nas equipes! Um projeto é feito por pessoas, e pessoas integram equipes... para um projeto fluir bem a equipe precisa estar em sintonia e o gerente do projeto precisa pensar na equipe sempre antes de qualquer tomada de decisão.

Métodos ágeis vieram do manifesto ágil, que foi assinado em 2001 por um conjunto de profissionais de desenvolvimento de software que se reuniram para discutir as melhores formas para melhorar o desempenho de seus projetos. Os principais métodos de desenvolvimento ágil de software são Extreme Programming (XP) e Scrum.