NetSaber - Artigos

Mánifesto Ágil em 10 paragrafos

            Ágil é a qualidade de ser ágil, a facilidade e desenvoltura com que se move. E é isso que a comunidade empresarial está procurando em seus processos, métodos mais rápidos para o desenvolvimento de software. A área de desenvolvimento de software não está acanhada para introduzir novas metodologias. (ABRAHAMSSON,2002)

            Um estudo realizado por Nandhakumar e Avison, argumenta que as metodologias tradicionais de desenvolvimento são tratadas como uma necessidade de apresentar a imagem de controle e para fornecer um status simbólico, ou como um mecanismo para detalhamento do processo.

            Criado em 2001, o manifesto ágil reúne um conjunto de práticas e princípios para desenvolvimento de software. Um pouco depois, um grupo de pessoas fundou uma organização não lucrativa que promove o desenvolvimento ágil, a Agile Alliance. Precisamente no dia 13 de novembro de 2001, no resort The Lodge at Snowbird nas montanhas de Utah em Wasatch, dezessete pessoas se encontraram para conversar, esquiar, relaxar, comer e tentar achar algo em comum, o que surgiu dessa reunião foi o Manifesto Ágil de Desenvolvimento de Software. Representantes do Extreme Programming como seu criador Kent Benck, do SCRUM como seu criador Ken Schwaber, e de outros processos de desenvolvimento de software foram convocados. (Agile Manifest)

            O manifesto para desenvolvimento ágil de software veio para valorizar mais os indivíduos, interações, software em funcionamento, colaboração com o cliente e responder rápido a mudanças do que a processos, ferramentas, documentação abrangente, negociação de contratos e seguir um mesmo plano. Claro que nunca desprezando os outros valores, apenas valorizando mais os citados primeiramente. (Agile Manifest)

            O manifesto ágil possui princípios, tendo como maior prioridade satisfazer o cliente. Para isso, é necessário estar aberto a mudanças nos requisitos, entrega contínua e frequente de funcionalidades e agregar valor ao software. Mudanças nos requisitos são impossíveis de evitar e os processos ágeis se saem muito bem quando se trata deste tipo de problema, com entregas frequentes de produtos funcionando em pouco tempo, variando de duas semanas a um mês com preferência para o menor tempo.

            A conversa de forma física (face a face) é o meio mais efetivo para troca de informações entre uma equipe de desenvolvimento e sempre em equipes pequenas, na qual a comunicação é direta.

            Algumas vezes, métodos ágeis são caracterizados como o oposto de metodologias baseadas em planejamento, por não possuir uma documentação detalhada e não tentar prever todos os possíveis retrabalhos. Para evitar o retrabalho, devem-se entregar um conjunto de funcionalidades do software funcionado ao final de cada ciclo, assemelhando-se assim com o desenvolvimento iterativo e incremental. A diferença entre os dois é a medida do tempo, sendo no método ágil medidos em semanas e no iterativo e incremental em meses. (BOEHM,2003)

            A escolha da equipe é muito importante, pois é necessário trabalhar com gente motivada e disposta a se comprometer. Os indivíduos devem ser auto-organizáveis, ou seja, devem fazer melhorias através dos próprios feedbacks.

            Os métodos ágeis, assim como todos os métodos, possuem desvantagens. O fato de não funcionar muito bem com equipes grandes e ter um menor controle de custos e lucro são dois exemplos, talvez por essa razão alguns profissionais que utilizam o PMBOK não aderem à prática dos métodos ágeis. É comum ouvir frases de que metodologia ágil é uma moda passageira. E por outro lado, os profissionais que utilizam os métodos ágeis acreditam que o PMBOK burocratiza demais os projetos, que tentam definir todo o software somente no início do projeto perdendo muito tempo e não chegando com um produto final esperado pelo cliente.

            O gerenciamento ágil possui um escopo definido em alto nível e os requisitos são priorizados de forma iterativa, ou seja, pode haver mudança durante o desenvolvimento. Possui uma comunicação direta e colaborativa e existe uma alta confiança entre os membros da equipe. Enquanto que no gerenciamento tradicional o escopo é bem definido nas fases iniciais do projeto e formalizado através da WBS (Work Breakdown Structure).

Para maiores informações e/ou para discutir sobre o assunto acesse: www.felipehatanaka.com.br ou www.hatanaka.com.br

Artigos Relacionados