Rafa Nascimento

Manifesto Ágil, explicado

Posted in ágil, manifesto by Rafa Nascimento on 14/03/2011

Os Valores Ágeis

O importante de compreender sobre os quatro valores ágeis é que enquanto você deve valorizar os conceitos sobre o lado direito, você deve valorizar as coisas do lado esquerdo ainda mais. A boa maneira de pensar sobre o manifesto é que o mesmo define preferências, não alternativas, estimulando um foco em determinadas áreas, mas não eliminando 
em outras. Os valores do Manifesto Ágil são:

Indivíduos e interações sobre processos e ferramentas
Times de pessoas desenvolvem software, e para isso eles precisam trabalhar de forma eficaz – incluindo, mas não limitado, a programadores, testadores, gerentes de projetos, modeladores, e seus clientes. Quem você acha que desenvolveria um sistema melhor: cinco desenvolvedores de software com suas próprias ferramentas de trabalho juntos em uma sala ou cinco pessoas com poucas qualificações, com um processo bem definido, as ferramentas mais sofisticadas, e os melhores escritórios que o dinheiro poderia comprar? Se o projeto for razoavelmente complexo meu dinheiro seria sobre os desenvolvedores de software, e o seu? O ponto é que os fatores mais importantes que você precisa considerar são as pessoas e como elas funcionam juntas, porque se não acertar nisso, as melhores ferramentas e processos serão desnecessários. Ferramentas e processos são importantes, não me interpretem mal, só que eles não são tão importantes quanto trabalhar em conjunto de forma eficaz. Basta lembrar o velho ditado: um tolo com uma ferramenta ainda é um tolo. Como Fred Brooks pontua em “O mítico homem-mês”, isso pode ser difícil para a gestão de aceitar porque eles muitas vezes querem crer que as pessoas e o tempo, ou os homens e os meses, são intercambiáveis.

Software funcionando sobre documentação abrangente
Quando você pergunta a um usuário se ele gostaria de ter um documento de cinquenta páginas descrevendo o que você pretende construir ou o software em si, o que você acha que ele escolheria? Meu palpite é que 99 vezes entre 100 ele vai escolher software funcionando. Se for esse o caso, não faz mais sentido trabalhar de forma que você produza software de forma rápida e, muitas vezes, dando aos usuários o que eles preferem? Além disso, eu suspeito que os usuários teriam uma facilidade maior de compreender qualquer software que você produz no lugar de diagramas técnicos complexos descrevendo o seu funcionamento interno ou descrevendo uma abstração de sua utilização, não é? Documentação tem o seu lugar, por escrito corretamente é um guia valioso para a compreensão das pessoas de como e porque um sistema é construído e como trabalhar com o sistema. No entanto, nunca esquecer que o principal objetivo do desenvolvimento de software é criar o software, e não documentos – caso contrário, seria chamado desenvolvimento de documentação, não seria?

Colaboração do cliente sobre negociação de contrato
Apenas o seu cliente pode dizer o que ele quer. Sim, ele provavelmente não tem habilidades para especificar exatamente o sistema. Sim, ele provavelmente não sabe o que quer de primeira. Sim, ele provavelmente vai mudar de ideia. Trabalhar juntamente com seu cliente é difícil, mas essa é a realidade do trabalho. Ter um contrato com seu cliente é importante, ter uma compreensão dos direitos e responsabilidades de cada um pode formar a fundação do referido contrato, mas um contrato não é um substituto para a comunicação. Desenvolvedores de sucesso trabalham em estreita colaboração com seus clientes. Eles investem o esforço para descobrir o que seus clientes necessitam, e eles educam os seus clientes ao longo do caminho.

Responder a mudanças sobre seguir um plano
As pessoas mudam de prioridades por uma variedade de razões. Conforme o trabalho progride em seu sistema, a compreensão do dono do projeto sobre o domínio do problema e do que você está construindo muda. O ambiente de negócios muda. A tecnologia muda ao longo do tempo, embora nem sempre para melhor. Alterar é uma realidade de desenvolvimento de software, uma realidade que o seu processo deve refletir. Não há nada de errado em ter um plano de projeto, na verdade, eu estaria preocupado com qualquer projeto que não tenha um. 
No entanto, um plano de projeto deve ser maleável, deve haver espaço para mudar conforme a sua situação muda. Do contrário, seu plano torna-se irrelevante rapidamente.

Os Princípios Ágeis

Para ajudar as pessoas a obter uma melhor compreensão do que é o desenvolvimento ágil de software, os membros da Agile Alliance refinaram as filosofias capturadas em seu manifesto em uma coleção de 12 princípios. Estes princípios são:
Nossa maior prioridade é satisfazer o cliente através entrega breve e contínua de software de valor
Por alguma razão, muitas pessoas em TI parecem ter esquecido que o objetivo do desenvolvimento de software deve ser o desenvolvimento de software. Ou, talvez, o problema é que eles pensam que eles precisam definir tudo na frente antes que eles possam iniciar a construção do software, ao passo que uma abordagem evolutiva para o desenvolvimento parece funcionar muito melhor.

Mudanças nos requisitos são bem-vindas, mesmo que tarde. Processos ágeis absorvem mudanças em prol da vantagem competitiva do cliente
Goste ou não, os requisitos vão mudar durante um projeto de desenvolvimento de software. Desenvolvedores de software tradicionais, muitas vezes, adotam processos de gestão de mudanças que se destinam a evitar ou reduzir aumento de escopo, mas quando você pensa sobre isso, estes são realmente processos de prevenção de mudanças, e não processos de gestão de mudanças. Agilistas abraçam as mudanças e, ao invés, seguem uma abordagem de gestão ágil de mudanças que trata requisitos como priorizados em uma pilha, que pode variar ao longo do tempo.

Entregar software funcionando frequentemente, de um par de semanas a um 
par de meses, com preferência para o período de tempo mais curto
Entregas frequentes de software funcionando fornecem aos donos do projeto um feedback concreto, tornando o estado atual de seu projeto transparente e permitindo que eles forneçam um melhor direcionamento ao time de desenvolvimento.

Especialistas de negócio e desenvolvedores devem trabalhar juntos diariamente durante 
todo o projeto
Seu projeto está em sérios apuros se você não tem acesso regular aos interessados. Os desenvolvedores ágeis adotam práticas como manter o cliente no local do desenvolvimento e incentivar a participação ativa do mesmo, além de adotar ferramentas inclusivas e técnicas que permitem que os interessados se envolvam ativamente com o desenvolvimento do software.

Construir projetos em torno de indivíduos motivados. Dê-lhes um bom ambiente e o suporte que precisam, e confie neles para realizar o trabalho
Muitas organizações têm uma visão de que eles podem contratar hordas de 
pessoas relativamente não-qualificadas, dar-lhes uma descrição de processo compatível com CMMI / ISSO que eles vão desenvolver com sucesso o software. Isso não parece funcionar muito bem na prática. As equipes ágeis, por outro lado, percebem que você precisa criar equipes de pessoas que estão dispostas a trabalhar de forma colaborativa e aprender uns com os outros. Eles têm a humildade para respeitar um ao outro e perceber que as pessoas são um fator primário de sucesso no desenvolvimento de software.

O método mais eficiente e eficaz de transmitir informação para um time e dentro de um time é a conversa cara-a-cara
Para um time de desenvolvimento de software ser bem-sucedido seus membros devem se comunicar e colaborar de forma eficaz. Há muitas maneiras de as pessoas se comunicarem em conjunto, e como você já deve ter percebido, a comunicação cara-a-cara em um ambiente de desenho compartilhado (como papel ou um quadro branco) é a maneira mais eficaz de fazê-lo.

Software funcionando é a medida primária de progresso
A principal medida progresso no desenvolvimento de software deve ser a entrega software funcionando que atenda as necessidades mutáveis de seus donos, não alguma forma de mensuração de “valor agregado” com base na entrega de documentação ou na realização de reuniões.

Processos ágeis promovem o desenvolvimento sustentável. Os clientes, 
desenvolvedores e usuários devem ser capazes de manter um ritmo constante 
indefinidamente
Assim como você não pode dar um sprint por uma maratona inteira, você não pode desenvolver software com sucesso forçando as pessoas a trabalhar horas extras durante meses em um determinado momento. Minha experiência é que você só pode realizar trabalho intelectual de alta qualidade intelectual por 5-6 horas durante um dia antes de começar a se cansar. Sim, o resto do dia pode ser preenchido com e-mails, reuniões, discussões informais, e assim por diante, mas a capacidade das pessoas para fazer “trabalho real” é limitada. Sim, você pode ser capaz de fazer um trabalho de alta qualidade a 12 horas por dia, e fazê-lo por alguns dias seguidos, mas depois de algum tempo você esgota-se e tudo o que você tem são 12 horas de um trabalho medíocre por dia.

Atenção contínua à excelência técnica e bom projeto melhoram a agilidade
É muito mais fácil de compreender, manter e evoluir código-fonte de alta qualidade do que é trabalhar com código de baixa qualidade. Portanto, agilistas sabem que precisam começar com um bom código, mantê-lo bom via refatoração, e adotar uma abordagem orientada a testes de forma que eles saibam a qualquer momento que seu software funciona. Nós também adotamos e seguimos diretrizes de desenvolvimento, particularmente orientações de codificação e até mesmo diretrizes de modelagem.

Simplicidade – a arte de maximizar a quantidade de trabalho não feito – 
é essencial
Os desenvolvedores ágeis focam em atividades de alto valor. Nós nos esforçamos em maximizar o retorno sobre os investimentos em TI de nossos clientes, e cortamos ou automatizamos o trabalho pesado.

As melhores arquiteturas, requisitos, e projetos emergem de times auto-organizáveis
Este é um dos princípios mais radicais do manifesto. O Modelo de Desenvolvimento Ágil de Software (AMDD) e o test-driven design (TDD) são os enfoques principais dentro da 
comunidade ágil para garantir o surgimento de arquiteturas, requisitos e projetos eficazes.

Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, e ajusta seu comportamento em conformidade
Melhoria do processo de software (SPI) é um esforço contínuo, e técnicas como 
retrospectivas devem ser adotadas para permitir a melhoraria da sua abordagem 
ao desenvolvimento de software.

Escrito por Scott W. Ambler

Referência: http://www.ambysoft.com/essays/agileManifesto.html

Anúncios
Tagged with: ,

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: