Saturday, December 19, 2009

Desenvolvimento Ágil

Motivação

Vários projetos de software terminam em fracasso ou não possuem a qualidade dexigida pelo cliente.
Como resposta a isso, surgiu o movimento ágil que tenta descobrir melhores maneiras de desenvolver
um software e de ajudar a outras pessoas a fazer o mesmo.

O desenvolvimento ágil segue o conjunto de '''valores''' abaixo:
  • Indíviduos e interações mais importantes que processos e ferramentas
  • Software funcionando mais importante que documentação compreensiva
  • Colaboração com o cliente mais importante que negociação contratual
  • Responder às mudanças mais importante que seguir um caminho a risca
OBS: Embora o lado direito seja valorizado, o lado esquerdo possui mais ênfase.

A partir desses valores, '''12 princípios''' foram indentificados:
  • 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
  • Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores
  • Projetos surgem através de indivíduos motivados, e que deve existir uma relação de confiança
  • Design do software deve prezar pela excelência técnica
  • Simplicidade
  • Rápida adaptação às mudanças
  • Indivíduos e interações mais importantes do que processos e ferramentas
  • Software funcional mais do que documentação extensa
  • Colaboração com clientes mais importantes do que negociação de contratos
  • Responder a mudanças mais importantes do que seguir um plano
Metodologias

Baseadas nos princípios e valores do movimento ágil surgiram metodologias:
  • XP - Extreme Programming (Programação Extrema)
  • Scrum
  • FDD - Feature Driven Development (Desenvolvimento Orientado a Recurso)
  • Etc ....
Extreme Programming

Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.

Valores
  • Comunicação
  • Simplicidade
  • Feedback
  • Coragem
  • Respeito
Princípios Básicos
  • Feedback rápido
  • Presumir simplicidade
  • Mudanças incrementais
  • Abraçar mudanças
  • Trabalho de qualidade
Regras

Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas. Há uma confiança muito grande na sinergia entre elas, os pontos fracos de cada uma são superados pelos pontos fortes de outras.

Planejamento
  • Estórias são escritas
  • Projeto divido em interações (Cada interação produz uma versão FUNCIONAL do sistema)
  • Planejamento da interação inicia cada interação
  • Planejamento da versão cria um cronograma (Normalmente cada interação = 2 a 3 semanas)
  • Fazer releases pequenas e frequentes (Assim o cliente pode detectar erros antecipadamente)
Gerenciamento
  • Dar ao time um ambiente de trabalho aberto e dedicado
  • Atribuir um ritmo sustentável (SEM HORAS EXTRAS!)
  • Um standup meeting (reunião em pé) inicia cada dia de trabalho
  • A velocidade do projeto é medida
  • Trocar pessoas de lugar (significa revezar uma parte do sistema - todos os programares devem passar por todas as partes do sistema)
  • Consertar (modificar) o próprio XP para adequar a realidade do projeto / empresa
Desenho
  • Simplicidade
  • Escolha uma metáfora para representar o sistema
  • Utilizar cartões CRC para sessões de desenho (Ajuda no desenho de classes - CRC = Classe Reponsabilidade e Colaboração)
  • Criar soluções de ponta para descobrir respostas para as difíceis problemas técnicos ou de desenho.
  • NENHUMA funcionalidade é adicionar antecipamente (Nada de "Vai que o cliente pode sprecisar um dia ...")
  • Refatore o código quando e onde for possível (Refatorar = organizar o código-fonte)
Codificação
  • Cliente deve estar sempre disponível (em local próximo de preferência)
  • Códigos devem seguir padrões (Assim todos os programadores podem compreendê-los)
  • Codificar o testes unitário primeiro (O teste guiará a implementação da classe)
  • Toda a programação de produção deve ser feita em par (Um deve ser o instrutor e o outro o aprendiz)
  • Uma integração deve ocorrer por vez para cada par de programadores
  • Integrar o código sempre
  • Configurar um computador dedicado para integração
  • Utilizar posse coletiva (Qualquer programador pode contribuir com novas idéias para alterar ou adicionar novas funcionalidades ao código. Assim não existirão gargalos)
Testes
  • Todo o código deve ter testes unitários
  • Todo o código deve passar por testes unitários antes de passar para a produção
  • Quando um bug (erro) é encontrado, um teste unitário deve ser criado para simular essa situação
  • Testes de aceitação devem ser rodados com freqüência e a pontuação publicada