Engenharia de Software. Prof. Me. Clodoaldo Brasilino

Transcrição

1 Engenharia de Software Prof. Me. Clodoaldo Brasilino

2 Acompanhamento da Disciplina 1. Introdução à Engenharia de Software 2. Processos de Software e Projetos 3. Metodologia Ágil 4. UML 5. Git - Gerência de Configuração 2

3 Conteúdo da Aula O que é agilidade? O que é um processo ágil? Modelos de Processos Ágeis XP Scrum 3

4 O que é agilidade?

5 O que é agilidade? Em 2001, 17 grandes desenvolvedores, consultores e engenheiros de software (Agile Allegiance) assinaram o Manifesto pelo Desenvolvimento de Software Ágil Este manifesto está relacionado a uma mudança política drástica 5

6 O que é agilidade? Indivíduos e interações acima de processos e ferramentas Software funcionando acima de documentação compreensível Colaboração do cliente acima de negociação em contrato Resposta a mudanças acima de seguir um plano 6

7 O que é agilidade? É uma filosofia: encoraja a satisfação ao cliente equipes pequenas e muito motivadas métodos informais simplicidade no desenvolvimento 7

8 O que é agilidade? São orientações de desenvolvimento: Mais entregas, menos análise e projeto Comunicação ativa e contínua entre desenvolvedores e stakeholders 8

9 O que é agilidade? Foram definidos 12 princípios a serem seguidos: 1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. 9

10 O que é agilidade? Foram definidos 12 princípios a serem seguidos: 2. Mudanças nos requisitos são bemvindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. 10

11 O que é agilidade? Foram definidos 12 princípios a serem seguidos: 3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo. 11

12 O que é agilidade? Foram definidos 12 princípios a serem seguidos: 4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. 12

13 O que é agilidade? Foram definidos 12 princípios a serem seguidos: 5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. 13

14 O que é agilidade? Foram definidos 12 princípios a serem seguidos: 6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face. 14

15 O que é agilidade? Foram definidos 12 princípios a serem seguidos: 7. Software funcionando é a medida primária de progresso. 15

16 O que é agilidade? Foram definidos 12 princípios a serem seguidos: 8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. 16

17 O que é agilidade? Foram definidos 12 princípios a serem seguidos: 9. Contínua atenção à excelência técnica e bom projeto aumenta a agilidade. 17

18 O que é agilidade? Foram definidos 12 princípios a serem seguidos: 10. Simplicidade a arte de maximizar a quantidade de trabalho não realizado é essencial. 18

19 O que é agilidade? Foram definidos 12 princípios a serem seguidos: 11. As melhores arquiteturas, requisitos e designs emergem de equipes autoorganizáveis. 19

20 O que é agilidade? Foram definidos 12 princípios a serem seguidos: 12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo. 20

21 O que é um processo ágil?

22 O que é um processo ágil? Um processo ágil deve resolver 3 problemas assumidos para a maioria de seus projetos: 1. Ser difícil prever que requisitos persistirão e que requisitos mudarão. Também ser difícil prever a prioridade dos requisitos pelo cliente na duração do projeto. 22

23 O que é um processo ágil? Um processo ágil deve resolver 3 problemas assumidos para a maioria de seus projetos: 2. Para a maioria dos tipos de software, o projeto e a implementação são entrelaçados. Modelos de projeto devem ser provados na sua criação. É difícil prever quanto será necessário projetar antes da construção ser usada para provar o projeto. 23

24 O que é um processo ágil? Um processo ágil deve resolver 3 problemas assumidos para a maioria de seus projetos: 3. Análise, Projeto, Construção e Teste não são previsíveis (em termos de planejamento). 24

25 O que é um processo ágil? Com tantos aspectos imprevisíveis, como criar um processo para gerenciar a imprevisibilidade? 25

26 O que é um processo ágil? Através de um processo adaptável Modificar condições de projeto e técnicas 26

27 O que é um processo ágil? Fatores Humanos: Competência Foco comum Colaboração Habilidade de tomada de decisão Habilidade de resolver problemas imprecisos Confiança e respeito mútuo Auto-organização 27

28 extreme Programming

29 XP Primeiras ideias surgem nos anos 80 (não exatamente o XP) Criado em 1999 por Kent Beck Usa uma abordagem orientada a objetos Quatro fases principais: Planejamento, projeto, codificação e testes Valores principais: Simplicidade, Comunicação, Feedback e Coragem 29

30 30

31 XP - Planejamento Criação de user stories: descreve recursos e funcionalidades desejadas Cada história é registrada pelo cliente (Semelhante aos casos de uso) em um cartão O cliente atribui um valor ao cartão: o quanto aquela história vale para seu negócio? A equipe atribui um valor ao cartão: qual é o custo para implementar? Se levar mais de 3 semanas, deve-se dividir a história em várias outras 31

32 XP - Planejamento Clientes + equipe XP decidem como agrupar as histórias para entregar Fechado o acordo de entrega, a equipe XP decide a prioridade em uma das formas: Todas as histórias serão implementadas imediatamente Histórias com maior valor serão implementadas antes Histórias de maior risco serão implementadas antes 32

33 XP - Planejamento Após a primeira entrega, a equipe calcula a velocidade: Número de histórias entregues A velocidade é usada para: Estimar datas de entrega e escalonamento Determinar se não assumiu-se mais do que devia, atrasando a entrega ou diminuindo o conteúdo a ser entregue 33

34 XP - Projeto Princípio KIS - Keep it Simple Encorajamento de uso de Cartões CRC (Classe-Responsabilidade-Colaborador) Cartões CRC é o que é apenas esperado como artefatos da fase de projeto Se um problema difícil de projetar é encontrado, recomenda-se prototipar (spike solution) XP encoraja o uso da Refatoração 34

35 XP - Projeto Por serem pouquíssimos artefatos (CRC + spike solutions), recomenda-se a atualização da documentação durante a construção A refatoração vem para trazer pequenas modificações que impactam fortemente no projeto Refatoração pode se tornar muito custosa a medida que o sistema cresce 35

36 XP - Codificação Feito tudo isso, inicia-se a codificação através da criação de testes unitários (TDD) O programador foca em construir código que passe nos testes unitários O teste unitário provê feedback instantâneo Pair Programming: Resolução de problemas em tempo real Garantia de qualidade em tempo real Apesar de juntos, cada um pode pensar em aspectos diferentes da programação 36

37 XP - Codificação Ao finalizar o trabalho, o código é disponibilizado para integração XP encoraja a integração contínua, baseada em integrações diariamente Evita problemas de compatibilidade e interfaceamento Provê ambiente de teste de fumaça 37

38 XP - Testes Testes unitários é um elemento principal Deve-se usar um framework que permitam sua automação (JUnit por exemplo) Isso estimula o teste de regressão, que é bastante útil (garantir que o que funcionou antes não quebrou) Por serem automáticos e globais ao sistema, os testes tornam-se diários 38

39 XP - Testes Com isso temos: Fácil acompanhamento do progresso Fácil identificação de problemas emergentes Resolver pequenos problemas em várias poucas horas levam menos tempo que resolver problemas gigantes logo antes do deadline. (Wells) Testes de aceitação, baseado nas user stories são especificados pelos clientes 39

40 Scrum

41 Scrum É um método ágil de desenvolvimento iterativo e incremental Definido como estratégia de desenvolvimento flexível e holística, onde uma equipe trabalha como um todo para atingir um objetivo comum Definido em 1986 por Hirotaka Takeuchi e Ikujiro Nonaka, no artigo New Product Development Game Scrum (scrummage) é um termo oriundo do rugby 41

42 Scrum Scrum (scrummage) é um termo oriundo do rugby em 1995, Ken Schwaber e Jeff Sutherland publicam em um workshop (Business Object Design and Implementation: OOPSLA 95 Workshop Proceedings) o que seria a primeira definição do Scrum Adotado no século XXI após o livro Agile Software Development with Scrum (2001) e a fundação scrum.org (2009) 42

43 Scrum 43

44 Scrum Três aspectos principais: Scrum roles - Papéis Scrum workflow - Tarefas Scrum artifacts - Artefatos 44

45 Scrum Roles São três papéis: Product Owner Scrum Development Team Scrum Master 45

46 Scrum Roles Product Owner: É quem é responsável pelo retorno sobre o investimento no sistema Cliente, Empresa contratante, etc. 46

47 Scrum Roles Product Owner: É quem é responsável pelo retorno sobre o investimento no sistema Cliente, Empresa contratante, etc. É quem prioriza e define o Product Backlog É o árbitro final sobre os requisitos, as questões a entrega 47

48 Scrum Roles Scrum Development Team: Grupo de três a nove indivíduos autogerenciáveis Pode haver especialistas, mas é crossfunctional, podendo conter pessoas de habilidades diferentes numa mesma equipe Possui autonomia sob como atingir o Sprint Goal O sucesso da equipe depende muito da alocação unificada da equipe (mesma sala) 48

49 Scrum Roles Scrum Master: Facilita o processo Scrum Mantém os artefatos visíveis Facilita a organização do time Ajuda a resolver impedimentos Protege o time de interferências externas 49

50 Scrum Workflow 50

51 Scrum Workflow As unidades de desenvolvimento são chamadas Sprints Cada Sprint tem um tempo fixo, entre uma semana e um mês 51

52 Scrum Workflow Sprint Planning: Toda Sprint começa com um planejamento em duas fases: É definido o Sprint Backlog pelo Time e pelo Product Owner Dados os requisitos escolhidos do Product Backlog para o Sprint Backlog, são detalhadas tarefas para o Sprint Goal 52

53 Scrum Workflow Daily Scrum: Todo dia, o Time passa 15 minutos discutindo sobre os objetivos da Sprint Goal O que foi feito ontem? O que vai ser feito hoje? Que impedimentos você espera ter? O Scrum Master entra em cena para desfazer os impedimentos 53

54 Scrum Workflow Daily Scrum: Todo dia, o Time passa 15 minutos discutindo sobre os objetivos da Sprint Goal O que foi feito ontem? O que vai ser feito hoje? Que impedimentos você espera ter? O Scrum Master entra em cena para desfazer os impedimentos Geralmente se faz em pé! 54

55 Scrum Workflow Sprint Review Meeting: Ao final do Sprint, o Time demonstra o esforço de trabalho ao Product Owner Qualquer trabalho não finalizado é examinado Itens incompletos retornam ao Product Backlog e são re-estimados para futuros Sprints Feedback dos stakeholders podem se tornar novos itens do Product Backlog 55

56 Scrum Workflow Sprint Retrospective: Ao final de cada Sprint, o Time reflete no próprio processo Analisam seu comportamento próprio e tomam decisões para melhorar os próximos Sprints O que houve de bom? O que pode ser melhorado? O que aprendemos? O que ainda temos dificuldade? Que ações devemos tomar daqui pra frente? 56

57 Scrum Workflow Backlog Refinement Meeting: Acontece a qualquer momento Não é uma tarefa Scrum oficial Visa repriorizar e reorganizar o Product Backlog Itens grandes são divididos e detalhados 57

58 Scrum Artifacts São seis: Product Backlog Product Backlog Item (PBI) Sprint Backlog Sprint Task Sprint Burndown Chart Product Burndown Chart 58

59 Scrum Artifacts Product Backlog: Visível a todos os envolvidos do projeto Qualquer envolvido pode adicionar itens Priorizado constantemente pelo Product Owner Ordenado por grau de importância 59

60 Scrum Artifacts 60

61 Scrum Artifacts Product Backlog Item (PBI): Diz o que deve ser feito Não diz como deve ser feito Geralmente escrito no formato de User Story Com critérios de aceitação (Definition of Done) Esforço estimado pelo Time Valor de negócio dado pelo Product Owner 61

64 Scrum Artifacts Sprint Backlog: Uma estimativa de PBIs a serem feitos na Sprint Goal Negociado pelo Time e Product Owner Visível principalmente ao Time Diariamente analisada no Daily Scrum 64

66 Scrum Artifacts Sprint Task: Enquanto o PBI diz o que fazer, a Sprint Task diz como fazer Geralmente um dia ou menos de trabalho Esforço re-estimado diariamente, geralmente em horas Geralmente voluntários assumem a tarefa, mas o Time assume a responsabilidade como um todo 66

67 Scrum Artifacts Sprint Burndown Chart: Total remanescente de horas de tarefas dentro de uma Sprint Re-estimada diariamente, logo horas podem ser adicionadas ou removidas Feito para facilitar o auto-ajuste da equipe, não como relatório Pode ter várias unidades além de horas 67

69 Scrum Artifacts Product Burndown Chart: Total remanescente de esforço do projeto Geralmente usa-se Story Points Introduz a checagem de realidade 69