Desenvolvimento ágil

Esta pesquisa deve fornecer um conteúdo atualizado sobre o tema acima. Não esqueça de incluir as  
referëncias (fontes) no último item, reforçando que não deve ser um Copy/Paste e sim uma síntese 
das pesquisas que fizer.

Conceito

O desenvolvimento de software tradicional é uma tarefa difícil, laboriosa e possui riscos. Riscos estes que envolvem orçamento, tempo para levantamento de requisitos e planejamento que não atendem ao cronograma estipulado e que tornará o projeto ainda mais caro, etc e que ao final de um período tudo pode estar perdido devido a não solução do problema do cliente.

Pensando nisso, no início do ano de 2001, um grupo de consultores veteranos da área de engenharia de software se reuniu em Snowbird, Utah, EUA. Apesar de cada um ter aprendido segundo a cartilha tradicional, ter suas próprias práticas e teorias preferidas, concordaram que os riscos inerentes ao desenvolvimento de software tradicional só poderiam ser atenuados se houvesse uma forma diferente do existia até então para desenvolvimento. Apesar de seus métodos serem diferentes, houve consenso de que os projetos tinham em comum um pequeno conjunto de princípios e com base nisso criaram o Manifesto para Desenvolvimento Ágil de software.

Principais métodos

Mesmo antes da reunião dos consultores da área de engenharia de software em Snowbird, Utah, EUA no início do ano de 2001, já haviam definições de desenvolvimento de software ágil que evoluíram a partir de meados dos anos de 1990 como parte de uma reação contra métodos “pesados”, caracterizados por regulamentação pesada, regimentação e micro gerenciamento usando o modelo em cascata para desenvolvimento.

Inicialmente, métodos ágeis eram conhecidos como métodos “leves”. Após a reunião em Snowbird foi adotado o nome métodos ágeis, tendo publicado o Manifesto ágil, documento que reúne os princípios e práticas desta metodologia de desenvolvimento.

Os métodos ágeis iniciais – criado a priore em 2000 – incluíam:

• • XP (Extreme Programming) (1996)
  • SCRUM (1986)
  • Feature Driven Development (FDD)
  • Dynamic Systems Development Method (DSDM) (1995)
  • Lean Development
  • Crystal Clear
  • Adaptive Software Development

Princípios do Manifesto Ágil

Principais conceitos do Manifesto Ágil:

• • Indivíduos e interações mais que processos e ferramentas
  • Software em funcionamento mais que documentação abrangente
  • Colaboração com o cliente mais que negociação de contratos
  • Responder a mudanças mais que seguir um plano

"mesmo havendo valor nos itens à direita, são mais valorizados mais os itens à esquerda."

De acordo com estes conceitos, são 12 os princípios do Manifesto Ágil:

• • Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais;
  • Softwares funcionais são entregues frequentemente (semanas, ao invés de meses);
  • Softwares funcionais são a principal medida de progresso do projeto;
  • Até mesmo mudanças tardias de escopo no projeto são bem-vindas. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente;
  • Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto;
  • Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho;
  • Design do software deve prezar pela excelência técnica;
  • Simplicidade;
  • O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face;
  • Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente;
  • As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis;
  • Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Vantagens

Vantagens:

• • Redução do tempo de entrega da primeira versão do software pedido;
  • Métodos ágeis seguem processo iterativo de desenvolvimento e de sucessivas entregas ao cliente, o qual vai constatando e evolução e participando na avaliação e definição das novas funcionalidades a serem acrescentadas;
  • Aumento de controle por parte dos gestores, uma vez que se baseia no que realmente está sendo produzido e no que vai ser feito a curto prazo. Como tal, há menos especulação, há mais visibilidade e adequação das medições e avaliações do estado das funcionalidades e tarefas realizadas;
  • Por haver maior comunicação neste método, há maior aproximação entre desenvolvedores e gestores, havendo assim um ambiente propício a maior produtividade dos envolvidos. É especialmente adequado a projetos onde requisitos vão evoluindo constantemente e não se exigem muitas pessoas. A maioria dos relatórios de documentação são produzidos pelas ferramentas de trabalho, o que alivia as equipes de trabalho.

Desvantagens:

• • Uma desvantagem apontada aos Métodos Ágeis é o fato de estes não serem escaláveis. Na realidade, estes não foram desenhados para projetos muito longos existindo, contudo abordagens mais escaláveis, como o Scrum;
  • “O desenvolvimento ágil é mais difícil com equipes maiores . O projeto médio tem apenas nove pessoas , bem ao alcance dos processos ágeis mais básicas. No entanto, é interessante encontrar ocasionalmente projetos ágeis de sucesso com 120 ou até 250 pessoas”[1];
  • Menor controle de custos. Tipicamente, nesta metodologia, o projeto termina quando o cliente não levantar mais funcionalidades relevantes que deseje ver concretizadas, em oposição a ser acordado um preço e um plano. Daqui tira-se que os custos e durações podem variar e podem ser de difícil gestão para a organização;
  • Documentação do projeto tipicamente mais pobre com relação aos métodos tradicionais.

XP eXtreme Programming

Extreme Programming (XP)

Criada na década de 90, nos Estados Unidos, é uma Metodologia Ágil de desenvolvimento de software para equipes pequenas e médias que utilizam requisitos básicos e vagos e que se modificam com rapidez. É uma metodologia que tem feito sucesso em vários países por ajudar o desenvolvimento de sistemas com melhor qualidade, produzidos em tempos menores e de forma mais econômica que o habitual.

Como o principal objetivo da XP é dar agilidade ao desenvolvimento de projetos e buscar a garantia de satisfação do cliente, as práticas, regras, e os valores da XP garantem um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos por quatro princípios básicos:

• • Princípio da Comunicação - busca manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicação.
  • Princípio da Simplicidade - entende-se como simplicidade, a busca do objetivo de implementar o software com o menor número possível de classes e métodos. Outra ideia importante deste princípio é procurar implementar apenas requisitos atuais, evitando assim adicionar funcionalidades que podem ser importantes apenas no futuro. A aposta da XP é que é melhor fazer algo simples hoje do que implementar algo complicado hoje que talvez não venha a ser usado.
  • Princípio do Feedback - A prática do feedback constante significa que o desenvolvedor terá informações constantes do código e do cliente. A informação do código é dada pelos testes constantes, que indicam os erros tanto individuais quanto do software integrado.
  • Princípio da Coragem - Sabe-se que não são todas as pessoas que possuem facilidade de comunicação e têm bom relacionamento interpessoal, este princípio também dá suporte à simplicidade, pois assim que a oportunidade de simplificar o software é percebida, a equipe pode experimentar e buscar novas soluções, além disso, é preciso coragem para obter e cobrar constantemente um feedback do cliente.

Principais práticas da Extreme Programming (XP)

• • Planejamento - Define o que é ou não necessário ser feito no projeto. A XP baseia-se em requisitos atuais para desenvolvimento de software, não em requisitos futuros.
  • Entregas Frequentes - Baseiam-se no desenvolvimento de um software simples, e conforme os requisitos aparecem, há a atualização da versão do software. Cada versão entregue deve ter o menor tamanho possível, contendo os requisitos de maior valor para o negócio. É recomendado que as versões devem ser entregues a cada mês, ou no máximo a cada dois meses, aumentando a possibilidade de feedback rápido do cliente.
  • Metáfora - São as descrições de um software sem a utilização de termos técnicos com o objetivo de guiar o desenvolvimento do software com a maior transparência possível para o cliente.
  • Projeto simples - O software desenvolvido de acordo com a metodologia XP deve ser o mais simples possível e satisfazer os requisitos atuais, sem a preocupação de requisitos futuros. Eventuais requisitos futuros devem ser adicionados assim que eles realmente existirem.
  • Testes - A Extreme Programming (XP) prioriza a validação do projeto durante todo o processo de desenvolvimento. Os desenvolvedores implementam o software criando primeiramente os testes.
  • Programação em pares - A implementação do código é feita em dupla, ou seja, dois desenvolvedores trabalham em um único computador. Procurando identificar erros sintáticos e semânticos, pensando estrategicamente em como melhorar o código que está sendo implementado. Esses papéis podem e devem ser alterados sempre que possível.
  • Refatoração - Focaliza a lapidação do projeto do software e está presente em todas as etapas do desenvolvimento. A refatoração deve ser feita sempre que possível, buscando principalmente simplificar o código atual sem perder nenhuma funcionalidade.
  • Propriedade coletiva - O código do projeto pertence a todos os membros da equipe. Isto significa que qualquer pessoa que percebe que pode adicionar valor a um código, mesmo que ele próprio não o tenha desenvolvido, pode fazê-lo, desde que faça os testes necessários e não prejudique as funcionalidades atuais. Isto é possível porque na XP todos são responsáveis pelo software. Uma grande vantagem desta prática é que, caso um membro da equipe deixe o projeto antes do fim, a equipe consegue continuar o projeto sem grandes dificuldades, pois todos conhecem todas as partes do software, mesmo que não seja de forma detalhada.
  • Integração contínua - É a prática de interagir e construir o sistema de software várias vezes por dia, mantendo os programadores em sintonia, além de possibilitar processos rápidos. Integrar apenas um conjunto de modificações de cada vez é uma prática que funciona bem porque fica óbvio quem deve fazer as correções quando os testes falham. Esta prática é facilitada com o uso de apenas uma máquina de integração, que deve ter livre acesso a todos os membros da equipe.
  • 40 horas de trabalho semanal - a XP assume que não se deve fazer horas extras constantemente. Caso seja necessário trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema sério no projeto que deve ser resolvido não com aumento de horas trabalhadas, mas com melhor planejamento.
  • Cliente presente - É fundamental a participação do cliente durante todo o desenvolvimento do projeto. O cliente deve estar sempre disponível para sanar todas as dúvidas de requisitos, evitando atrasos e até mesmo construções erradas. Uma idéia interessante é manter o cliente como parte integrante da equipe de desenvolvimento (Tester).
  • Código padrão - Baseia-se na padronização da arquitetura do código, para que este possa ser compartilhado entre todos os programadores e até mesmo entre outros softwares.

Referências bibliográficas

• • http://www.desenvolvimentoagil.com.br/
  • https://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software
  • http://agilemanifesto.org/iso/ptbr/
  • https://fernandofranzini.wordpress.com/2014/06/05/desenvolvimento-agil-de-software/
  • http://www.teses.usp.br/teses/disponiveis/45/45134/tde-06072008-203515/en.php
  • http://www.devmedia.com.br/introducao-ao-desenvolvimento-agil/5916
  • http://www.dcc.ufla.br/infocomp/index.php/INFOCOMP/article/view/68/53
  • http://www.devmedia.com.br/conceitos-basicos-sobre-metodologias-ageis-para-desenvolvimento-de-software-metodologias-classicas-x-extreme-programming/10596

• • [1] Cockburn, A. e Highsmith, “Agile Software Development: The People Factor”, IEEE Computer, v.34, n.11, nov. 2001, p. 131-33