XP

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Desenvolvimento Ágil
Uma Introdução
Manifesto para o Desenvolvimento Ágil de Software
Proposto em 2001 pela Aliança Ágil composta por Kent e outros 16 membros especialistas em SW 
Decorrente da busca por melhores modos de desenvolver software
Propõe a valorização de:
Indivíduos e interações em vez de processos e ferramentas
Softwares funcionando em vez de documentação abrangente
Colaboração do cliente em vez de negociação de contratos
Resposta a modificações em vez de seguir um plano rígido
Manifesto para o Desenvolvimento Ágil de Software
Um manifesto é normalmente associado a um movimento político emergente
Contrapõe-se à “velha guarda”, sugerindo mudanças revolucionárias (espera-se que para melhor)
Desenvolvimento Ágil – Considerações Iniciais
Os métodos de desenvolvimento ágil foram criados em um esforço para vencer as fraquezas percebidas e reais da Engenharia de Software convencional
Métodos de desenvolvimento tradicionais requerem disciplina na sua aplicação
O ser humano é indisciplinado por natureza…
Desenvolvimento Ágil – Considerações Iniciais
O desenvolvimento ágil pode fornecer importantes benefícios, mas não é aplicável a todos os projetos, produtos, pessoas e situações
Também não é contrário à sólida prática da Engenharia de Software
Na economia moderna é muito difícil (ou impossível) prever como um sistema de informação evoluirá com o passar do tempo
Condições de mercado voláteis
Necessidades de usuários finais evoluem
Surgem novas ameaças de competição
Etc…
Desenvolvimento Ágil – Considerações Iniciais
Em muitas situações, não podemos mais definir completamente os requisitos antes do início do projeto
Os engenheiros de software devem ser ágeis o suficiente para responder a um ambiente de negócios mutável
Tais problemas modernos não devem nos levar a descartar princípios, conceitos, métodos e ferramentas valiosos de Engenharia de Software
A Engenharia de Software deve evoluir frente à crescente e real demanda por agilidade
O que é Agilidade ?
No contexto da Engenharia de Software, conforme :
Palavra “mágica” para descrever um processo de software moderno
Nesse processo, tudo deve ser ágil
Equipe ágil é equipe especializada capaz de responder adequadamente a modificações
Modificações no sotfware, na equipe, na adoção de novas tecnologias, etc…
Requer apoio a modificações
Requer indivíduos trabalhando em equipe
O sucesso do processo depende diretamente das especialidades desses indivíduos e da sua capacidade de colaboração
Desenvolvimento Ágil
O que é ?
Quem faz ?
Por que é importante ?
Quais são os passos ?
Qual é o produto do trabalho ?
Como temos a certeza de que fizemos corretamente ?
Desenvolvimento Ágil
O que é ?
A Engenharia de Software Ágil combina uma filosofia e um conjunto de diretrizes de desenvolvimento
A filosofia:
Encoraja a satisfação do cliente e a entrega incremental de sw
Equipes de projeto pequenas e altamente motivadas
Métodos informais, formulados conforme necessidades da equipe
Produtos de trabalhos de Engenharia de Software mínimos
Simplicidade global de desenvolvimento
As diretrizes de desenvolvimento:
Enfatizam a entrega em contraposição à análise e ao projeto (apesar dessas atividades não serem desencorajadas)
Comunicação contínua, fácil e ativa entre desenvolvedores e clientes. Clientes fazem parte da equipe de trabalho.
Desenvolvimento Ágil
Quem faz ?
Todos os interessados no projeto
Engenheiros de software
Gerentes
Clientes
Usuários finais
Compõem uma equipe ágil, auto-organizada e que controla seu próprio destino
A equipe enfatiza a comunicação e colaboração entre todos que a compõem
Desenvolvimento Ágil
Por que é importante ?
O ambiente moderno de negócios é apressado e sempre mutável
As necessidades do mercado são voláteis
A Engenharia de Software Ágil mostra-se como uma alternativa razoável em relação à Engenharia de Software convencional para certas categorias de software e certos tipos de projeto de software
Caracteriza-se pela entrega rápida de sistemas, em geral bem sucedidos
Desenvolvimento Ágil
Quais são os passos ?
As atividades básicas da Engenharia de Software permanecem:
Comunicação com o cliente
Planejamento
Modelagem
Construção
Entrega
Avaliação
Tais atividades são reduzidas a um conjunto mínimo de tarefas que leva a equipe de projeto à construção e entrega como prioridades
Desenvolvimento Ágil
Qual é o produto do trabalho ?
Incremento de software que é entregue ao cliente na data de entrega combinada
Desenvolvimento Ágil
Como temos a certeza de que fizemos corretamente ?
Na medida em que os incrementos de software entregues aos clientes satisfaçam as expecitativas
Princípios para Agilidade
Foram propostos pela Aliança Ágil:
Maior prioridade é satisfazer ao cliente desde o início por meio de entregas contínuas e incrementais do sw
Modificações de requisitos são bem-vindas, mesmo que tardias. Devem ser encaradas como vantagens para a competitividade do cliente
Entrega frequente de sw funcionando a cada duas semanas até dois meses (no menor intervalo possível)
Pessoal de negócio e desenvolvedores devem trabalhar juntos diariamente durante todo o projeto
Indivíduos motivados, fornecendo ambiente e apoio de que necessitam 
Princípios para Agilidade 
Foram propostos pela Aliança Ágil (cont.):
Melhor método para captação de informação é a interação direta (face a face)
 Software funcionando é a melhor medida de sucesso
O desenvolvimento deve conter ritmo constante sempre
Atenção contínua à excelência técnica e ao bom projeto facilitam a agilidade
Simplicidade (minimização da quantidade de trabalho não efetuado) é essencial
Melhores arquiteturas, requisitos e projetos surgem de equipes auto-organizadas
Em intervalos regulares, a equipe reflete em conjunto sobre como se tornar mais efetiva. Então sintoniza e ajusta adequadamente seu comportamento.
O que é um processo ágil?
É difícil prever quais requisitos de sw vão persistir e quais serão modificados.
Como criar um processo que possa gerenciar essa imprevisibilidade?
A resposta está na adaptabilidade do processo (na capacidade de se realizar modificações rápidas do projeto e das condições técnicas)
Um processo ágil deve, portanto, ser adaptável
A adaptação deve ser contínua porém incremental
É necessário o feedback constante do cliente para que as adaptações prioritárias possam ser feitas
Para tanto, recomenda-se a utilização de protótipos
A Política de Desenvolvimento Ágil
Debate: desenvolvimento ágil x desenvolvimento convencional
No entanto, ninguém é contra a agilidade
A verdadeira questão é:
Como construir sw que satisfaçam às necessidades do cliente atual e que exibam características de qualidade que lhes permitam ser estendidos e ampliados para satisfazer às necessidades do cliente no longo prazo?
Não existem respostas absolutas
Há muito a ser ganho considerando o melhor de ambas as correntes e pouco a ser ganho denegrindo qualquer uma dessas abordagens
Fatores Humanos
Características desejáveis nas pessoas da equipe de desenvolvimento ágil:
Competência
Habilidade
Foco comum
Colaboração
Capacidade de tomada de decisão
Habilidade de resolver problemas vagos (não muito claros)
Respeito e confiança mútua
Auto-organização
Equipe ágil organiza-se para o trabalho a ser feito
Equipe organiza processo para melhor acomodar seu ambiente
Equipe organiza o cronograma de trabalho para conseguir melhor entrega do incremento de software
Metodologia de Desenvolvimento Ágil: Extreme Programing (XP)
Há diferentes modelos de desenvolvimento ágil, muitos com características comuns entre si
XP é um dos exemplos mais representativos dentre esses modelos
XP utiliza uma abordagem de desenvolvimento orientada a objetos
Inclui um conjunto de regras e práticas que ocorrem em quatro atividades: planejamento, projeto, codificação e teste
Extreme Programing (XP)
Planejamento
Começa com a criação de um conjunto de histórias que descrevem as características e funcionalidades para o sw
Cada história (semelhante aos casos de uso) é descrita pelo cliente e
colocada em um cartão de indexação
O cliente atribui um valor de prioridade para cada história em relação ao contexto global do negócio
A equipe XP avalia cada história e atribui um custo medido em semanas de desenvolvimento
Se a história precisar de mais do que três semanas de desenvolvimento, pede-se ao cliente para desmembrá-la em histórias menores
Novas histórias podem ser escritas a qualquer momento 
Extreme Programing (XP)
Planejamento
Equipe XP decide como agrupar histórias na versão seguinte a ser desenvolvida
Uma vez estabelecido um compromisso básico para a versão (histórias a serem incluídas e data de entrega), a equipe determina como as histórias deverão ser desenvolvidas (em um dos três modos):
Todas as histórias serão implementas imediatamente (dentro de poucas semanas)
Histórias com prioridade mais alta serão desenvolvidas primeiro
Histórias de maior risco (custo) serão implementadas primeiro
Após a entrega da primeira versão, a equipe XP calcula a velocidade de projeto  quantidade de histórias implementadas
Extreme Programing (XP)
Planejamento
A velocidade do projeto pode ser usada para:
Ajudar estimar as datas de entrega e o cronograma para as versões subsequentes
Determinar se houve um comprometimento efetivo foi feito sobre todas as histórias implementadas
Na medida em que o desenvolvimento prossegue, o cliente pode:
Adicionar histórias
Mudar a prioridade de uma história existente
Dividir histórias
Eliminar histórias
A equipe XP reconsidera todas as versões remanescentes e modifica seus planos adequadamente
Extreme Programing (XP)
Projeto
Segue rigorosamente o princípio KIS (keep it simple)
O XP encoraja o uso de cartões CRC (Classe-Responsabilidade-Colaboração) como mecanismo para raciocinar sobre o sw no contexto OO
Cartões CRC identificam classes oo que são relevantes para o incremento sdo sw atual
Os cartões CRC são único produto concreto gerado pela etapa do projeto XP
Caso um problema de projeto seja encontrado como parte de uma história, o XP recomenda a criação imediata de um protótipo desta parte
Denominado solução de ponta, o protótipo é implementado e avaliado
Intenção de reduzir o risco, dedicando foco e prioridade a pontos críticos
Extreme Programing (XP)
Projeto
O XP encoraja a refabricação
Refabricação é o processo de modificar um sistema de software de tal modo que ele não altere o comportamento externo do código, mas aperfeiçoe a estrutura interna. É um modo disciplinado de limpar o código, modificando/simplificando o projeto interno
Com a refabricação o projeto ocorre continuamente na medida em que o sistema é construído
Deve-se ter cuidado, no entanto, com o esforço necessário à refabricação que pode crescer muito na medida em que o tamanho da aplicação cresce
Extreme Programing (XP)
Codificação
O XP recomenda que antes da codificação, seja desenvolvida uma série de testes unitários que exercitarão cada uma das histórias incluídas na versão atual (incremento) do sw
Com os testes prontos, o desenvolvedor estará melhor preparado para focalizar no que precisa ser implementado para passar no teste unitário
Nada mais deve ser adicionado à implementação (KIS)
Uma vez completado o código, ele pode ser imediatamente submetido ao teste unitário, fornecendo feedback instantâneo ao desenvolvedor
Um conceito chave na codificação do XP é a programação em pares
Extreme Programing (XP)
Codificação
Um conceito chave na codificação do XP é a programação em pares
O XP recomenda que duas pessoas trabalhem juntas em uma estação de trabalho para criar um código correspondente a uma história
Isso fornece um mecanismo de solução de problemas e de garantia em tempo real
Mantém os desenvolvedores focados no problema
Na prática cada pessoa assume um papel diferente:
Uma pensa nos detalhes de código de uma parte específica do projeto
A outra garante que as normas do XP estejam sendo seguidas e que o código gerado vai se encaixar no projeto mais amplo da história
Extreme Programing (XP)
Codificação
Na medida em que os pares de programadores completam seu trabalho, o código desenvolvido por eles é integrado ao trabalho dos outros
Em alguns casos isso é realizado diariamente por uma equipe de integração
Em outros casos, os pares de programadores tem a responsabilidade pela integração
Essa estratégia de integração contínua, ajuda a evitar problemas de compatibilidade e interface, além de fornecer um ambiente de “teste de fumaça” que ajuda a descobrir rapidamente os erros
Extreme Programing (XP)
Teste
XP recomenda a formulação de testes unitários antes das implementações
Encoraja a adoção da estratégia de testes de regressão
Na medida em que os testes unitários são organizados, os testes de integração e validação podem ocorrer diariamente
Essa abordagem fornece um indicativo de progresso ou deterioração do processo como um todo
Os testes de aceitação XP, também chamados de testes do cliente, são especificados pelo cliente e focalizam as características e funcionalidades do sistema global que são visíveis e passíveis de revisão pelo cliente
Testes de aceitação são derivados das histórias do usuário que foram implementadas como parte de uma versão do software
Extreme Programing (XP)