300 likes | 391 Views
Visão Geral sobre o XP – eXtreme Programming. Alexandre Monteiro. Manifesto Ágil [1/5]. Assinado por 17 desenvolvedores com reconhecimento mundial em Utah em fevereiro/2001. Declaração de 4 valores http://www.agilemanifesto.org/. Manifesto Ágil [2/2].
E N D
Visão Geral sobre o XP – eXtreme Programming Alexandre Monteiro
Manifesto Ágil [1/5] • Assinado por 17 desenvolvedores com reconhecimento mundial em Utah em fevereiro/2001. • Declaração de 4 valores • http://www.agilemanifesto.org/
Manifesto Ágil [2/2] “Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a entender que: • Indivíduos e interações são mais importantes que processos e ferramentas. • Software funcionandoé mais importante do que documentação completa e detalhada. • Colaboração com o cliente é mais importante do que negociação de contratos. • Adaptação a mudanças é mais importante do que seguir o plano inicial. Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda. “
Metodologias Ágeis • eXtreme Programming • FDD • Lean Software Development • Cristal Family • Scrum • (...)
O surgimento do XP • Em meados de 1990, Kent Beck procurou formas mais simples e eficientes de desenvolver software • Identificou o que tornava simples e o que dificultava o desenvolvimento de software • Em Março de 1996, ele iniciou um projeto com novos conceitos que resultaram na metodologia XP - eXtreme Programming
O que é eXtreme Programming? “Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança” Kent Beck
Programando ao Extremo • Levar todas as boas práticas ao Extremo • Se testar é bom, vamos testar toda hora!! • Se projetar é bom, vamos fazer disso parte do trabalho diário de cada pessoa! • Se integrar é bom, vamos integrar a maior quantidade de vezes possível! • Se iterações curtas é bom, vamos deixar as iterações realmente curtas!
Mudanças sempre ocorrem • Clientes não sabem o que querem no início • Desenvolvedores não sabem qual a melhor maneira de fazer o software no início • Medo da mudança trava o desenvolvimento
Avanços • Nos últimos 30 anos... • Melhoria nos processos • Iterativo Incremental • Melhorias nas ferramentas • IDEs, automação... • Maior abstração no desenvolvimento • Orientação a Objetos • Orientação a Aspectos • Orientação a ...
Mudar não é tão caro custo t Requisitos Análise Projeto Implementação Testes Produção
XP inclui... • Comunicação • Coragem • Feedback • Simplicidade • Respeito
Comunicação • Soluções de problemas normalmente já são conhecidas... • O problema é a solução chegar a quem precisa • Comunicação face a face é a maneira mais rápida de “espalhar” conhecimento
Coragem • Extreme Programming é novo e diferente • Atitude é mais importante que processo • Coragem pra dizer a verdade, para recomeçar do zero, para inovar
Feedback • Feedback <-> Comunicação • Feedback aumenta aprendizado e produtividade
Simplicidade • Regra geral • Pensar sempre : “ O que pode ser feito que seja o mais simples que funciona?” • Simplicidade normalmente gera mais valor Geração de valor overhead Simplicidade
Respeito • Coragem, Feedback, Simplicidade, Comunicação... • Respeito é necessário para tirar o máximo desses valores • Respeito pelo próximo • Feedback, Comunicação • Respeito por si mesmo • Coragem, Simplicidade
Test First Design Refactoring Stand-up Meeting Continuous Integration Boas Práticas A criação de testes leva em conta não o tempo ganho com a criação dos mesmos antes da codificação, mas conhecer previamente as possíveis falhas do seu sistema. A reconstrução baseia-se na remoção de redundância, eliminação de funcionalidades inúteis, e reconstrução de projetos obsoletos. Reuniões rápidas e diárias com a equipe Os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários.
Pair Programming Move People Around CollectiveCodeOwnership CodingStandards Boas Práticas Todo código de produção é desenvolvido por duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor. As duplas de programação são revezadas em média a cada 2h. E equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo. Todo código é desenvolvido seguindo um padrão.
The Customer is Always Available Small Release Simple Design Boas Práticas O cliente está sempre disponível para resolver dúvidas, alterar o escopo de uma iteração e definir prioridades. O software é entregue em pequenas versões para que o cliente possa obter o seu ganho o mais cedo possível e para minimizar riscos. O código está, a qualquer momento, na forma mais simples que passe todos os testes.
40-Hour Week On-Site Customer Acceptance Tests Ter um papel de cliente na equipe XP em tempo integral para responder as perguntas Boas Práticas Cada programador trabalha 40 horas por semana. Se o horário for flexível, deve-se respeitar o horário do par naquele período, senão enquanto um trabalha o outro vai pra casa . São definidos pelo usuário e são os critérios de aceitação do software.
System Metaphor Boas Práticas Ajuda a manter todos os desenvolvedores em sintonia com o projeto quando dando nomes a objetos ou classes. A idéia é que exista um objeto "produto" que sofre várias modificações ao longo da "linha de montagem", onde outros objetos trabalham sobre o produto. A vantagem é que é simples adicionar "máquinas novas" a linha de montagem. A Fábrica Quando o "produto" precisa passar pela mão de várias pessoas, às vezes para conhecimento, aprovação ou modificação do conteúdo. Podem existir modificações feitas pelo sistema, nesse caso, existem "destinatários virtuais" que recebem a mensagem, analisam e despacham para quem deve. A diferença básica do Correio para a Fábrica é que ele não segue uma linha. O Correio O objeto é um "turista", o Servlet e o Banco são hospedagens, os dados são a bagagem, o objeto que tira os dados do "turista" e coloca ou no Servlet (em XML) ou no Banco são "carregadores de bagagem". Quando a "bagagem" está guardada no hotel "Banco de Dados" o "turista" recebe um ticket da bagagem para poder pegar ela depois (o Identificador único da tabela). Turista
Papéis no XP Big Boss / XpManager • Deve fazer: • Agendar reuniões; • Escrever atas; • Manter o XP Tracker informado dos acontecimentos das reuniões • Não deve fazer: • Deixar que problemas externos interfiram no desenvolvimento • Dizer quando as coisas devem acontecer • Dizer às pessoas o que fazer • Cobrar das pessoas
Papéis no XP Xp Gold Owner (Cliente - O proprietário do ouro) É quempaga pelo sistema, geralmente o dono da empresa. Xp Goal Donor • Deve fazer: • Escrever User Stories • Definir prioridades • Definir testes de aceitação • Validar testes de aceitação • Esclarecer dúvidas • Não deve fazer: • Implementar código • Definir quanto tempo uma tarefa leva para ser feita
Papéis no XP Coordenadores Xp Coach Xp Tracker Responsável pela negociação com o cliente quanto ao escopo e pela coordenação do Planning Game. • Deve fazer: • Coletar métricas • Manter todos informados do que está acontecendo • Definir testes de aceitação • Tomar atitudes diante de problemas • Sugerir sessões de CRC (Class, Responsabilities , Collaboration) métricas
Papéis no XP Programador (Driver/Partner) • Deve fazer: • Estimar prazos de User Stories • Implementar código de produção • Trabalhar em par • Fazer refactoring • Corrigir bugs • Não deve fazer: • Criar/Alterar novas funcionalidades • Escrever testes de aceitação
Planejamento das iterações • Divida o projeto em etapas de 1 ou 2 semanas; • Considere prazos fixos e escolha um dia da semana para integrações e entregas; (segunda ou sexta-feira); • Planeje reuniões diárias para acompanhar a evolução do projeto (“stand-up”, meeting matinal); • As iterações serão as unidades de referência para fazer estimativas; • Entre no jogo para entregar um produto a cada iteração.
Conclusão • Extreme Programming • Atitude • Disciplina • Mudança é algo normal • Aceitar, não fugir • Conjunto de boas práticas
Referências • XPRecife – Grupo de Estudos de Métodos Ágeis de Recife • www.cin.ufpe.br/~xprecife • Xispê – Portal Brasileiro de XP • www.xispe.com.br