um processo ágil de desenvolvimento de software Programação Radical XP ( Extreme Programming ) um processo ágil de desenvolvimento de software

Desenvolvimento Ágil de Software valoriza mais: Indivíduos e interaçãos do que processos e ferramentas Software funcionando do que documentação Parceria com cliente do que negociação de contratos Responder à mudança do que seguir um plano

Agile Software Development Manifesto for Agile Software Development Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Metodologias Tradicionais Baseadas em “Engenharia” Exibe processos detalhados, com forte ênfase no planejamento

Críticas comuns às metodologias tradicionais - Sem grandes sucessos Casos “interplanetários” Sem grande popularidade Quem utiliza? Burocráticas Muitas tarefas a realizar (vinculadas à metodologia) retardam o desenvolvimento

Reação às metodologias tradicionais Metodologias “peso-leve” (XP) Ágeis x Monumentais (Manifesto)

Metodologias Ágeis (pontos fundamentais) Métodos adaptativos, ao invés de preditivos Métodos orientados a pessoas, e não a processos

Métodos Preditivos ( tipo “engenharia” ) Tentam planejar grande parte do processo de software, com grande detalhe, para longos períodos Isto funciona... até que as coisas mudam Sua natureza é resistir à mudança

Métodos ágeis As mudanças são bem-vindas O processo se adapta à mudança Se o processo não se adapta, modifica-se o processo

Orientação a pessoas x Orientação a processos Objetivo dos métodos tradicionais: definir processos independentes de seus usuários Objetivo dos Métodos Ágeis: dar suporte à equipe, em seu trabalho (nenhum processo pode criar novas habilidades numa equipe)

Custos de Projeto Uma ponte Software Projeto 10% Construção 90% (codificação e testes de unidade)

Software: ênfase em projeto Em software, a construção tem custo quase zero (automatizada) Em software, o esforço é em projeto, o que requer gente talentosa e criativa Processos criativos não são facilmente planejáveis (a previsibilidade pode ser impossível) Portanto: A metáfora da engenharia tradicional é inadequada Fazer software requer um processo distinto

Os requisitos imprevisíveis Requisitos são difíceis de determinar Difícil estimar o valor real de um requisito É difícil associar custo a um requisito “O problema com esse projeto é que os requisitos estão sempre mudando” Sem requisitos estáveis, como ter um plano estável?

Como controlar a imprevisibilidade? Imprevisibilidade = Caos? A parte mais difícil: onde estamos? necessidade de mecanismos honestos de feedback que mostrem a situação real, em intervalos regulares

Controle do caos: iterações Desenvolvimento iterativo (incremental, evolucionário, em etapas, em espiral, etc.) Produzir freqüentes versões do sistema final - contendo um subconjunto das características desejadas - Integradas e testadas como se fossem a versão final

Desenvolvimento Iterativo - Documentos escondem falhas - Código não testado carrega bugs - Quando as pessoas começam a mexer no sistema, as falhas aparecem (tanto bugs como requisitos mal-compreendidos) Nada como um sistema testado e integrado para dar um banho de realidade em um projeto

O Sistema de Cooperação Wiki Diego Abadan – equipe Edugraf A seguir: Twiki O Sistema de Cooperação Wiki Diego Abadan – equipe Edugraf

Metodologias Tradicionais Críticas comuns às metodologias tradicionais Reação às metodologias tradicionais Metodologias Ágeis (pontos fundamentais) Métodos Preditivos ( tipo “engenharia” ) Métodos ágeis Orientação a pessoas x Orientação a processos Custos de Projeto Software: ênfase em projeto Os requisitos imprevisíveis Como controlar a imprevisibilidade? Controle do caos: iterações Desenvolvimento Iterativo A seguir: Twiki