Engenharia de Software Desenvolvimento gil Captulo 4 Engenharia

  • Slides: 32
Download presentation
Engenharia de Software Desenvolvimento Ágil Capítulo 4 Engenharia de Software Roger Pressman 6 a.

Engenharia de Software Desenvolvimento Ágil Capítulo 4 Engenharia de Software Roger Pressman 6 a. Edição – Mc. Graw. Hill

Manifesto Ágil “Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando

Manifesto Ágil “Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar: • Interação entre pessoas 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. Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda. ” Aliança Ágil – 2001. Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn, Ward Cunningham, Ron Jeffries, Steve Mellor, Mike Beedle, Arie van Bennekum, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Brian Marick, Ken Schwaber, Jeff Shuterland, Dave Thomas Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 2

O que é agilidade? Segundo Ivar Jacobson a agilidade tornou-se uma palavra mágica que

O que é agilidade? Segundo Ivar Jacobson a agilidade tornou-se uma palavra mágica que descreve um processo moderno de software. Tudo é ágil … - Equipe ágil, capaz de responder adequadamente a modificações. - Sendo que modificações envolve todo o desenvolvimento de software, ou seja, modificações nos requisitos, membros da equipe, tecnologias. Na visão de Ivar Jacobson o acolhimento de modificações é o principal guia para a agilidade Outras definições podem ser consideradas…. Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 3

O que é agilidade? Segundo a Aliança Ágil existem 12 princípios a serem considerados

O que é agilidade? Segundo a Aliança Ágil existem 12 princípios a serem considerados para alcançar a agilidade. 1. Nossa maior prioridade é satisfazer ao cliente desde o início por meio de entregas contínua de software valioso. 2. Modificações de requisitos são bem vindas, mesmo que tardias no desenvolvimento. 3. Entrega de software funcionando ferqüentemente, a cada duas semanas até dois meses, de preferência no menor espaço de tempo. 4. O pessoal de negócio e de desenvolvimento devem trabalhar juntos diariamente durante todo o projeto 5. Contrução de projetos em torno de indivíduos motivados. 6. O método mais eficiente e efetivo de levar informação para dentro de uma equipe de desenvolvimento e a conversa face Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 4

O que é agilidade? 7. Software funcionando é a principal medida de progresso. 8.

O que é agilidade? 7. Software funcionando é a principal medida de progresso. 8. Processos ágeis promovem desenvolvimento sustentável. 9. agilidade 10. Simplicidade 11. auto-organizadas. 12. Em intervalos regulares, a equipe reflete sobre como se torna mais efetiva, então sintoniza e ajusta adequadamente seu comportamento. Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 5

Modelos Ágeis de Processo n n n n Extreme Programming(XP) Desenvolvimento Adaptativo de Software

Modelos Ágeis de Processo n n n n Extreme Programming(XP) Desenvolvimento Adaptativo de Software Desenvolvimento Dinâmico de Sistemas SCRUM Família Crystal Desenvolvimento Guiado por Características Modelagem Ágil Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 6

XP (e. Xtreme Programming)

XP (e. Xtreme Programming)

XP - Extreme Programming • • “O XP (e. Xtreme Programming) é uma metodologia

XP - Extreme Programming • • “O XP (e. Xtreme Programming) é uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança“. Kent Beck, criador da XP. É baseado em 4 valores e 12 práticas. Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 8

Valores do XP n Comunicação; n Simplicidade; n Realimentação; n Coragem. Profa. Dra. Ana

Valores do XP n Comunicação; n Simplicidade; n Realimentação; n Coragem. Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 9

Valores do XP n Comunicação: A comunicação não é limitada a procedimentos formais, há

Valores do XP n Comunicação: A comunicação não é limitada a procedimentos formais, há preferência por uma comunicação mais ágil. Como um telefonema pode ser melhor que um email, a presença física melhor que a comunicação remota ou um código auto-explicativo melhor que uma documentação escrita; n Simplicidade: A solução adotada deve ser sempre a mais simples possível que alcance os objetivos esperados. São utilizadas tecnologias, projetos, algoritmos e técnicas simples, que permitirão atender aos requerimentos do usuário final. Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 10

Valores do XP n Realimentação (Feedback): Garante que todos entendam como os resultados estão

Valores do XP n Realimentação (Feedback): Garante que todos entendam como os resultados estão satisfazendo o cliente. Permite maior agilidade: erros detectados e corrigidos imediatamente, requisitos e prazos reavaliados mais cedo, facilidade na tomada de decisão, permitem estimativas mais precisas, maior segurança e menos riscos para investidores. n Coragem: É preciso ter coragem para tomar as decisões certas nas horas certas. Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 11

Práticas do XP n n n Cliente “on-site” Jogo de planejamento Metáfora Releases Curtos

Práticas do XP n n n Cliente “on-site” Jogo de planejamento Metáfora Releases Curtos Projeto Simples Testes antes da Codificação n n n Padrões Refactoring Programação em pares Propriedade coletiva Integração Contínua Semana de 40 horas Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 12

Práticas do XP Cliente “on site” (sempre presente): O cliente fica junto com o

Práticas do XP Cliente “on site” (sempre presente): O cliente fica junto com o time de desenvolvimento, escreve cartões de estória, faz realimentação diariamente, fornece exemplos para testes de integração razoáveis, gerencia testes de aceite, etc. . ; n Jogo do planejamento: Conhecedores de negócio e de software decidem conjuntamente em que ordem o sistema deve ser implementado; n Metáfora: Explicação de alto nível, facilmentendida que usa convenções de nomenclatura. n Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 13

Práticas do XP Releases Curtos: As funcionalidades devem ser entregues tão cedo e tão

Práticas do XP Releases Curtos: As funcionalidades devem ser entregues tão cedo e tão freqüentemente quanto possível (tipicamente 3 semanas); n Projeto Simples: Toda funcionalidade deve ser implementada da forma mais simples possível. Considerações sobre projeto arquitetônico devem ser postergadas, tudo que pode ser postergado deve ser postergado; n Testes antes da codificação: Ênfase em código livre de defeitos, os testes de unidade são escritos para validar a implementação dos cartões de estória. Apenas após o primeiro teste estiver pronto é que se faz a codificação. n Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 14

Práticas do XP Padrões: São definidos pela equipe e permitem que qualquer membro entenda

Práticas do XP Padrões: São definidos pela equipe e permitem que qualquer membro entenda qualquer código. n Refactoring (Refabricação): Abordagem disciplinada para reestruturação de código. n Programação em pares: Pares de desenvolvedores em uma máquina desenvolvem todo o código de produção. Revisão acontece enquanto o código é escrito, uma pessoa lidera com teclado e mouse e a outra analisa. Os papéis são trocados periodicamente. n n Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 15

Práticas do XP Propriedade Coletiva: Qualquer um pode mudar código, e todos são responsáveis

Práticas do XP Propriedade Coletiva: Qualquer um pode mudar código, e todos são responsáveis por todo o código. n Integração Contínua: medida em que cada cartão de estórias é implementado e o código passa pelos testes de unidade, ele é imediatamente integrado e os testes de integração são executados. Os resultados podem ser visualizados por toda a equipe e pelo cliente. n Semana de 40 horas: Pequenos incrementos de trabalho possibilitam que a maioria dos dias termine com a finalização de uma tarefa. n Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 16

XP - Extreme Programming sob o ponto de vista de processo de desenvolvimento Sob

XP - Extreme Programming sob o ponto de vista de processo de desenvolvimento Sob o ponto de vista das fases clássicas de processo de desenvolvimento as atividades chaves do XP estão distribuídas da seguinte forma: Planejamento: • Criação dos cartões de estórias, escritas pelos clientes, que descrevem as características e funcionalidades do software (várias estórias devem ser contadas; • O cliente atribui uma prioridade para cada estória; • Equipe de desenvolvimento (líder) avaliam cada estória e atribuem prazo e custo. Se a estória precisar de mais de 3 semanas, geralmente pede-se ao cliente que divida a estória em estórias menores; • Cliente e equipe de desenvolvimento (líder) decidem a ordem de implementação de cada estória (versões a serem entregues). Obs: A qualquer momento o cliente pode adicionar, mudar a prioridade, alterar ou eliminar estórias. A equipe de desenvolvimento (líder) reconsidera todas as versões remanescentes e modifica os planos. Enfoque: Comunicação e Coragem. Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 17

XP - Extreme Programming sob o ponto de vista de processo de desenvolvimento Projeto:

XP - Extreme Programming sob o ponto de vista de processo de desenvolvimento Projeto: • Enfoque na simplicidade; • É projetado pela equipe de desenvolvimento (programadores) o que foi descrito (nada mais, nada menos); • Pode-se utilizar cartões CRC (Class Responsability Colaboration); • Se um problema difícil é encontrado, o XP recomenda a criação de um protótipo pela equipe de desenvolvimento (programadores) para avaliação do cliente, visando diminuir riscos; • Encoraja a refabricação; Refabricação é um processo de modificar um sistema de software de tal modo que ele não altere comportamento externo, mas aperfeiçoe a estrutura interna. É um modo adequado de limpar, alterar e simplificar o projeto interno visando minimizar defeitos, ou seja, aperfeiçoar o projeto de código depois que foi escrito. Obs: O XP praticamente não possui nenhuma metodologia, notação e documentação. Enfoque: Simplicidade e Realimentação (Feedback). Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 18

XP - Extreme Programming sob o ponto de vista de processo de desenvolvimento Codificação:

XP - Extreme Programming sob o ponto de vista de processo de desenvolvimento Codificação: • Cria-se uma série de testes unitários, pela equipe de desenvolvimento (programadores), que exercitarão cada uma das estórias antes da implementação; • Programação em pares. Enfoque: Simplicidade e Realimentação (Feedback). Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 19

XP - Extreme Programming sob o ponto de vista de processo de desenvolvimento Teste:

XP - Extreme Programming sob o ponto de vista de processo de desenvolvimento Teste: • Elaboração e execução de testes unitários, integração e validação, pela equipe de desenvolvimento (Quality Assurance); • Testes de aceitação, pelos clientes. Enfoque: Comunicação e Realimentação (Feedback). Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 20

“Conclusões” do XP n n n As propostas de XP são bastante heterodoxas; Há

“Conclusões” do XP n n n As propostas de XP são bastante heterodoxas; Há uma grande quantidade de experiências sendo realizadas no mundo todo; A definição de orçamento ainda não está resolvida; O nível de qualidade é duvidoso no XP. E possível obter uma certificação? A manutenção do sistema por outras equipes de desenvolvimento pode ser complicada; Para projetos curtos e com equipes pequenas, parece funcionar muito bem. Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 21

SCRUM

SCRUM

O que é Scrum? q O Scrum (o nome é derivado de uma atividade

O que é Scrum? q O Scrum (o nome é derivado de uma atividade do jogo de rugby) é um modelo ágil de processo que foi desenvolvido por Jeff Sutherland e por sua equipe no início da década de 1990. q Nos últimos anos foi realizado desenvolvimento adicional de métodos Scrum por Scwaber e Beedle. q É um processo ágil que permite manter o foco na entrega do maior valor do negócio, no menor tempo possível. Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 23

Características do Scrum O Scrum é consistente com o manifesto ágil: q Pequenas equipes

Características do Scrum O Scrum é consistente com o manifesto ágil: q Pequenas equipes de trabalho são organizadas de modo a “maximizar a comunicação, minimizar a supervisão e maximizar o compartilhamento de conhecimento tácito informal”; q O processo precisa ser adaptável tanto a modificações técnicas quanto de negócios “para garantir que o melhor produto possível seja produzido”; q O processo produz frequentes incrementos de software “que podem ser inspecionados, ajustados, testados, documentados e expandidos”; Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 24

Características do Scrum q O trabalho de desenvolvimento e o pessoal que o realiza

Características do Scrum q O trabalho de desenvolvimento e o pessoal que o realiza é divido “partições claras, de baixo acoplamento, ou em pacotes”; q Testes e documentação constantes são realizados à medida que o produto é construído; q O processo Scrum fornece “habilidade de declarar o produto ´pronto´ sempre que necessário (porque a concorrência acabou de entregar, porque a empresa precisa de dinheiro, porque o usuário/cliente precisa das funções, porque foi para essa data que foi prometido. . . )”. Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 25

Forma de trabalho do Scrum A figura 9 representa o fluxo de processo Scrum.

Forma de trabalho do Scrum A figura 9 representa o fluxo de processo Scrum. 15 minutos de reunião diária. Sprint Backlog Registro de Pendências Características associadas a um sprint a cada 24 horas 2 a 4 semanas Product Backlog Pendência de Produtos: Características priorizadas do produto desejado pelo cliente Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I Nova funcionalidade Ao final do sprint 26

Forma de trabalho do Scrum q Pendência de Produtos (Product Backlog): uma lista priorizada

Forma de trabalho do Scrum q Pendência de Produtos (Product Backlog): uma lista priorizada de requisitos ou características do projeto que fornecem valor de negócio para o cliente. Itens podem ser adicionados à pendência a qualquer momento (é assim que as modificações são introduzidas). O gerente de produto avalia a pendência e atualiza as prioridades quando necessário; Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 27

Forma de trabalho do Scrum q Registro de Pendências (Sprints Backlog): Consiste de unidades

Forma de trabalho do Scrum q Registro de Pendências (Sprints Backlog): Consiste de unidades de trabalho que são necessárias para satisfazer a um requisito definido na pendência que precisa ser cumprido em um intervalo de tempo pré-definido (tipicamnete de 2 a 4 semanas). Durante o sprint, os itens em pendência a que as unidades de trabalho do sprint se destinam são congeladas, ou seja não são introduzidas modificações durante o sprint. Assim, os membros da equipe trabalham em um ambiente de curto prazo, mas estável; Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 28

Forma de trabalho do Scrum q Reuniões Scrum: são reuniões curtas (normalmente de 15

Forma de trabalho do Scrum q Reuniões Scrum: são reuniões curtas (normalmente de 15 minutos) feitas diariamente pela equipe Scrum. Três questões chaves são formuladas e respondidas por todos os membros da equipe. üO que você fez desde a última reunião de equipe? üQue obstáculos você está encontrando? üO que você planeja realizar até a próxima reunião de equipe? Essas reuniões diárias ajudam a equipe a descobrir problemas potenciais tão cedo quanto possível, e promovem uma equipe auto-organizada e a socialização do conhecimento. Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 29

Forma de trabalho do Scrum q Novas funcionalidades: entrega o incremento de software ao

Forma de trabalho do Scrum q Novas funcionalidades: entrega o incremento de software ao cliente de modo que a funcionalidade implementada possa ser demonstrada e avaliada pelo cliente. Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 30

Equipe do Scrum Equipe padrão de trabalho do Scrum q Scrum Master: Auxilia no

Equipe do Scrum Equipe padrão de trabalho do Scrum q Scrum Master: Auxilia no desenvolvimento da equipe, resolvendo impedimentos e assegurando que tudo está de acordo para que o objetivo estabelecido no sprint seja alcançado e lidera a reunião diária; q Product Owner: Representa a voz do cliente/usuário e muitas vezes é o próprio. É responsável por criar o Product Backlog; q Scrum Time: Grupo de desenvolvimento do sprint (programadores, testadores e etc. . . ). Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 31

Copyright © 2007 - 2014 Profa. Ana Paula Gonçalves Serra. Todos direitos reservados. Reprodução

Copyright © 2007 - 2014 Profa. Ana Paula Gonçalves Serra. Todos direitos reservados. Reprodução ou divulgação total ou parcial deste documento é expressamente proibido sem o consentimento formal, por escrito, da Profa. Ana Paula Gonçalves Serra. Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 32