Engenharia de Software

Transcrição

1 Engenharia de Software Metodologias para Desenvolvimento de Software XP e SCRUM Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com

2 Agenda Desenvolvimento Ágil de Software extreme Programming SCRUM Comparações Conclusão

3 Manifesto Ágil Indivíduos e interação entre eles 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.

4 extreme Programming -XP Método de desenvolvimento de software; Conjunto de valores, princípios e práticas; Ciclo de desenvolvimento curtos e releases frequentes; Permite respostas rápidas a mudanças de requisitos em qualquer etapa do desenvolvimento; Enfatiza o trabalho em equipe que se autoorganiza em que todos são iguais num trabalho colaborativo.

5 extreme Programming Metodologia ágil para equipes pequenas a médias desenvolvendo software com requesitosvagos ou que mudam freqüentemente. [Beck 2000] Em XP, codificação é principal tarefa Baseia-se em revisão permanente do código, testes freqüentes, participação do usuário final,refatoraçãocontínua, refinamentocontínuoda arquitetura, integração contínua, planejamento, projeto e reprojeto a qualquer hora

6 Metodologia Ágil Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar: 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. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

7 Partes do XP 1. Values (valores): estabelecem a forma do desenvolvimento XP Principles (princípios): guiam o desenvolvimento do software Activities (atividades): devem ser executadas por todo o ciclo de vida XP Practices (práticas): são utilizadas pelas equipes XP para desenvolver sistemas

8 XP -Valores Simplicidade; Comunicação; Feedbacks; Coragem;

9 Simplicity (simplicidade) XP incentiva ao extremo práticas que reduzam a complexidade do sistema A solução adotada deve ser sempre a mais simples que alcance os objetivos esperados Use as tecnologias, algoritmos e técnicas mais simples que permitirão atender aos requisitosdo usuário-final Design, processo e código podem ser simplificados a qualquer momento

10 XP: Simplicidade Não tente prever o futuro! Comece por soluções simples e que funcionem. Melhorias são adicionadas depois.

11 Communication (comunicação) Várias práticas do XP promovem uma maior comunicação entre os membros da equipe A comunicação não é limitada por procedimentos formais. Usa-se o melhor meio possível, que pode ser Uma conversa ou reunião informal Um , um bate-papo, um telefonema O próprio código Preferência à comunicação mais ágil

12 XP: Comunicação Todos são parte do time, inclusive o cliente! Contato diário e face a face. Pair programming.

13 Feedback (retroalimentação) Várias práticas dexp garantem um rápido feedback sobre várias etapas/partes do processo Feedbacksobre qualidade do código (testes de unidade, programação em pares, posse coletiva) Feedback sobre estado do desenvolvimento (estórias do usuário-final, integração contínua, jogo do planejamento) Permite maior agilidade Erros detectados e corrigidos imediatamente Requisitos e prazos reavaliados mais cedo Permite estimativas mais precisas

14 XP: Feedbacks Testes: Cliente: Unitários; Integração. Testes funcionais. Membros do time: Quando um novo requisito chega o time estima quanto tempo será necessário.

15 Courage (coragem) Testes, integração contínua, programação em pares e outras práticas dexp aumentam a confiança do programador e ajudam-no a ter coragem para melhorar o código que está funcionando para torná-lo mais simples investir tempo no desenvolvimento de testes mexer no design em estágio avançado pedir ajuda aos que sabem mais abandonar processos formais e ter o projetoe a documentação em forma de código

16 XP: Coragem Não deixe para amanha o que pode ser feito agora! Não ficou bom?! Refaça o quanto necessário! Se não precisa, jogue fora!

17 XP -Práticas Process On-site customer (cliente no local), testing (testes), small releases (versões pequenas), planning game (planejamento do jogo) Programming Simple design (projeto simples), testing (testes), refactoring(reconstrução), coding standars(código padrão) ; Team Collective ownership (código coletivo), continuous integration (integração continua), metaphor (metáfora), pair programming (programação em par), small releases (versões pequenas) ;

18 2. Princípios XP Rapid Feedback -(retorno rápido) Assume Simplicity -(simplicidade) Incremental Change -(mudanças incrementais) Embrace Change -(aceitar mudanças) Quality work -(trabalho de qualidade)

19 Rapid Feedback(retorno rápido) O retorno entre os desenvolvedores é rápido Cliente sabe se o produto que está sendo desenvolvido atende às suas necessidades Modele um pouco, mostre ao cliente e então modele novamente. Garante que o seu modelo será preciso enquanto seu conhecimento do projeto aumenta

20 AssumaSimplicity (simplicidade) Deixe o seu modelo tão simples quanto possível e assuma que a solução mais simples é a melhor O design do sistema deve ser feito para a iteração corrente. Não deve ser feito design sobre uma possível necessidade futura.

21 Incremental Change (mudanças incrementais) O modelo não será perfeito na primeira tentativa, ele irá mudar de acordo com o desenvolvimento do projeto Os problemasdevem ser solucionados com um conjunto de pequenas modificações

22 Embrace Change (aceitar mudanças) Mudanças ocorrerão no projeto de acordo com o crescimento do entendimento do mesmo Aceite as mudanças e tenha coragem para reconstruir

23 Quality work (trabalho de qualidade) A qualidade do trabalho nunca deve ser comprometida XP eleva a importância da codificação e do teste antes da programação test-first programming

24 3. Atividades XP Listening -(escutar) Testing -(testar) Coding -(codificar) Designing (projetar)

25 Listening (escutar) XP é baseado em comunicação Menor importância na documentação formal, maior necessidade de uma comunicação verbal de qualidade Além de dizer que os desenvolvedores devem escutar os clientes, XP tem práticas que dirigem e guiam para uma comunicação melhor

26 Testing (testar) Teste é um passo integrado no processo de desenvolvimento Desenvolvedores escrevem os teste antes de desenvolverem o código

27 Coding (codificar) Escrever código que é refinado através de práticas como: Refactory - refatoração Pair programming programação em pares Code review revisão de código

28 Designing (projetar) O design não é estático nem designado a um cargo (pessoa), ele é dinâmico e de responsabilidade de toda equipe XP aceita a evolução natural do sistema, o que implica em mudanças constantes

29 4. Práticas XP Whole Team Equipe Plannig Game Jogo do planejamento Customer Tests Testes de aceitação Small releases Versões pequenas Simple Design Projeto simples Pair programming Programação em pares Test-driven Development Desenvolvimento orientado a testes (TDD)

30 Práticas XP Refactoring Refinamento do projeto Continuos Integration Integração contínua Collective Ownership Posse coletiva Coding Standards Padrões de codificação Metaphor Metáfora Sustainable Place Ritmo saudável

31 A equipe (Whole Team) Todos em um projeto XP são parte de uma equipe. A equipe deve incluir um representante do cliente: estabelece os requisitosdo projeto define as prioridades controla o rumo do projeto Outros papéis assumidos pelos integrantes da equipe: programadores testadores (que ajudam o cliente com testes de aceitação) analistas (que ajudam o cliente a definir requerimentos) gerente (garante os recursos necessários) coach (orienta a equipe, controla a aplicação dexp) tracker (coleta métricas)

32 Jogo do Planejamento (Planning Game) Dois passos chaves: Planejamento de um release Cliente propõe funcionalidades desejadas (estórias) Programadores avaliam a dificuldade de implementálas Planejamento de uma iteração Cliente define as funcionalidades prioritárias para a iteração; Programadores as quebram em tarefas e avaliam o seu custo (tempo de implementação)

33 Teste de aceitação (Customer Tests) Testes de aceitação são elaborados pelo cliente São testes automáticos Quando rodarem com sucesso, funcionalidade foi implementada Devem ser rodados novamente em cada iteração Oferecem feedback: pode-se saber, a qualquer momento, quanto do sistema já foi implementado e quanto falta.

34 Versões Pequenas(Small Releases) Disponibiliza, a cada iteração, software 100% funcional Benefíciosdo desenvolvimento disponíveis imediatamente Menor risco(se o projeto não terminar, parte existe e funciona) Cliente pode medir com precisão quanto já foi feito Feedbackdo cliente permitirá que problemas sejam detectados cedo e facilita a comunicação entre o cliente e os desenvolvedores Lançamento pode ser destinado a usuário-cliente (que pode testá-lo, avaliá-lo, oferecer feedback) usuário-final (sempre que possível)

35 Design simples (Simple Design) Design está presente em todas as etapas no XP Projeto começa simples e se mantém simples através de testes e refinamento do design (refactory). Não é permitidoque se implemente nenhumafunção adicional que não será usada na atual iteração Implementação ideal é aquela que Roda todos os testes Expressa todas as idéias que você deseja expressar Não contém código duplicado Tem o mínimo de classes e métodos

36 Programação em duplas (Pair programming) Todo o desenvolvimento em XP é feito em pares Um computador, um teclado, dois programadores Um piloto, um co-piloto Papéis são alternados freqüentemente Pares são trocados periodicamente Benefícios Melhor qualidade do design, código e testes Revisão constante do código Nivelamento da equipe Maior comunicação

37 TDD(Test-driven Development) "Test first, then code" Programadores XP escrevem testes primeiro, escrevem código e rodam testes para validar o código escrito Cada unidade de código só tem valor se seu teste funcionar 100% Testes são a documentação executável do sistema

38 Refatoração(Refactoring) Não existe uma etapa isolada de projeto em XP O código é o projeto! O projeto é melhorado continuamente através de refactory Mudança proposital de código que está funcionando Objetivos: melhorar o design, simplificar o código, remover código duplicado, aumentar a coesão, reduzir o acoplamento Realizado o tempo todo, durante o desenvolvimento

39 Integraçãocontínua Projetos XP mantêm o sistema integrado o tempo todo Integração de todo o sistema pode ocorrer várias vezes ao dia (pelo menos uma vez ao dia) Todos os testes (unidade e integração) devem ser executados Benefícios Expõe o estado atual do desenvolvimento (viabiliza lançamentos pequenos e freqüentes) Estimula design simples, tarefas curtas, agilidade Oferece feedback sobre todo o sistema Permite encontrar problemas de design rapidamente

40 Posse coletiva(collective Ownership) Em um projeto XP qualquer dupla de programadores pode melhorar o sistema a qualquer momento. Todo o código em XP pertence a um único dono: a equipe Todo o código recebe a atenção de todos os participantes resultando em maior comunicação Maior qualidade (menos duplicação, maior coesão) Menos riscos e menos dependência de indivíduos Todos compartilham a responsabilidade pelas alterações

41 Padrões de codificação (Coding Standards) O código escrito em projetos XP segue um padrão de codificação, definido pela equipe Padrão para nomes de métodos, classes, variáveis Organização do código (chaves, etc.) Código com estrutura familiar facilita e estimula Posse coletiva Comunicação mais eficiente Simplicidade Programação em pares Refinamento do design

42 Metáfora ( Metaphor) Pode ser uma analogia com algum outro sistema (computacional, natural, abstrato) que facilite a comunicação entre os membros da equipe e cliente Facilita a escolha dos nomes de métodos, classes, campos de dados, etc. Serve de base para estabelecimento de padrões de codificação

43 Ritmo saudável (Sustainable Place) Projetos com cronogramas apertados que sugam todas as energias dos programadores não são projetos XP "Semanas de 80 horas" levam à baixa produtividade Produtividade baixa leva a código ruim, relaxamento da disciplina (testes, refactoring, simplicidade), dificulta a comunicação, aumenta a irritação e o stress da equipe Tempo "ganho" será perdido depois Eventuais horas extras são aceitáveis quando produtividade é maximizada ao longo prazo

44 Dificuldades Vencer barreiras culturais Deixar alguém mexer no seu código Trabalhar em pares Ter coragem de admitir que não sabe Pedir ajuda Vencer hábitos antigos Manter as coisas simples (e não tentar prever o futuro escrevendo "design flexível") Jogar fora código desnecessário Escrever testes antes de codificar Refactory com freqüência (vencer o medo)

45 SCRUM Framework iterativo e incremental para desenvolvimento ágil de sofware; Não há prática de engenharia pré-definida; Conjunto de práticas e papéis predefinidos; Sprints (iterações);

46

47 SCRUM

48 Quadro KANBAN

49 SCRUM: Planejamento, Product Backlog Product Backlog é criado; Data de entrega do produto final é definida; Componentes do sistema são priorizados; Custo e riscos são estimados; Cliente participa.

50 SCRUM: Sprints Ciclo iterativo de desenvolvimento; 1 a 4 semanas de duração (o time define); Um subconjunto do Product Backlog é selecionado para fazer parte do Sprint atual (Sprint Backlog) ; Durante o sprint, nenhuma funcionalidade deve ser adicionada; no entanto as existentes no Sprint Backlog podem ser atualizadas ou alteradas.

51 SCRUM: Papéis Dono do produto (Product Owner); ScrumMaster; Equipe.

52 Dono do Produto Define as funcionalidades do produto e as prioriza; Responsável pela visão de negócios do projeto; Aceita ou rejeita resultados dos trabalhos; Cliente + Analista de Requisitos.

53 ScrumMaster Facilitador: responsável por remover obstáculos do time e assegurar que as práticas estão sendo executadas corretamente; Escudo contra interferências externas.

54 Reuniões Sprint Planning 1 Product Backlog (Todos participam); Sprint Planning 2 (Cliente não parzcipa) Sprint Backlog; Daily Scrum (Time + ScrumMaster) Sprint Review/Reflection (30 dias).

55 Daily Scrum Reunião curta (15 min); ScrumMaster é o responsável e pergunta a cada membro do time: O que fez ontem? O que fará hoje? Existe algum obstáculo?

56 XP vs SCRUM Semelhanças: Ambos não prevêem o futuro (não definem todos os requisitos já de início); Ambos produzem software que funcionam a cada iteração; Comunicação é essencial (Reuniões diárias).

57 XP vs SCRUM Diferenças: SCRUM tem papéis pré-definidos; XP a validação do software é feita a todo instante (Testes); SCRUM somente ao final de cada Sprint; XP adota a programação em par como prática fundamental; XP é um método e SCRUM é um FRAMEWORK?!

58 Quando não usar XP Equipes grandes e espalhadas geograficamente Comunicação é um valor fundamental dexp Não é fácil garantir o nível de comunicação requerido em projetos XP em grandes equipes Situações onde o feedback é demorado Testes muito difíceis, arriscados e que levam tempo Programadores espalhados em ambientes físicos distantes e sem comunicação eficiente

59 Conclusões Extreme Programming (XP) é uma metodologia de desenvolvimento de software baseada nos valores simplicidade, comunicação, feedback e coragem. Para implementar XP não é preciso usar diagramas ou processos formais. É preciso fazer uma equipe se unir em torno de algumas práticas simples, obter feedback suficiente e ajustar as práticas para a sua situação particular. XP pode ser implementada aos poucos, porém a maior parte das práticas é essencial. Nem todos os projetos são bons candidatos a usar uma metodologia ágil como XP. XP é mais adequado a equipes pequenas ou médias.

60 Conclusões Ambas abordagens XP e SCRUM procuram resolver limitações dos métodos tradicionais de desenvolvimento ; Reduzir custos com mudanças de requisitos ao longo do desenvolvimento; Reduzir tempo de entrega do produto final ao cliente. Embora SCRUM seja mais abrangente; ambas dependem de uma avaliação do contexto para serem utilizadas.

61 Referências Extreme Programming Explained: Embrace Change, Kent Beck;

62 Obrigado! Edilberto Silva