Engenharia de Software Desenvolvimento Ágil Capítulo 4 Engenharia de Software Roger Pressman 6a....

Engenharia de Software

Desenvolvimento Ágil

Capítulo 4 Engenharia de Software

Roger Pressman6a. Edição – McGrawHill

Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I 2

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.

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

Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda.” Aliança Ágil – 2001.


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….


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 a face


O que é agilidade?

7. Software funcionando é a principal medida de progresso.8. Processos ágeis promovem desenvolvimento sustentável.9. Atenção contínua a excelência técnica e ao bom projeto facilitam a

agilidade10. Simplicidade11. As melhores arquiteturas, requisitos e projetos surgem de equipes

auto-organizadas.12. Em intervalos regulares, a equipe reflete sobre como se torna mais

efetiva, então sintoniza e ajusta adequadamente seu comportamento.


Modelos Ágeis de Processo

Extreme Programming(XP) Desenvolvimento Adaptativo de Software Desenvolvimento Dinâmico de Sistemas SCRUM Família Crystal Desenvolvimento Guiado por

Características Modelagem Ágil

XP (eXtreme Programming)


XP - Extreme Programming

• “O XP (eXtreme 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.


Valores do XP

Comunicação; Simplicidade; Realimentação; Coragem.


Valores do XP 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 e-mail, a presença física melhor que a comunicação remota ou um código auto-explicativo melhor que uma documentação escrita;

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.


Valores do XP 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.

Coragem: É preciso ter coragem para tomar as decisões certas nas horas certas.


Práticas do XP

Cliente “on-site” Jogo de planejamento Metáfora Releases Curtos Projeto Simples Testes antes da

Codificação

Padrões Refactoring Programação em pares Propriedade coletiva Integração Contínua Semana de 40 horas


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..;

Jogo do planejamento: Conhecedores de negócio e de software decidem conjuntamente em que ordem o sistema deve ser implementado;

Metáfora: Explicação de alto nível, facilmente entendida que usa convenções de nomenclatura.

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);

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;

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.

Práticas do XP


Padrões: São definidos pela equipe e permitem que qualquer membro entenda qualquer código.

Refactoring (Refabricação): Abordagem disciplinada para reestruturação de código.

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.

Práticas do XP


Propriedade Coletiva: Qualquer um pode mudar código, e todos são responsáveis por todo o código.

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.

Semana de 40 horas: Pequenos incrementos de trabalho possibilitam que a maioria dos dias termine com a finalização de uma tarefa.

Práticas do XP


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.



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).



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).



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).


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.

“Conclusões” do XP


O que é Scrum?

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.

Nos últimos anos foi realizado desenvolvimento adicional de métodos Scrum por Scwaber e Beedle.

É um processo ágil que permite manter o foco na entrega do maior valor do negócio, no menor tempo possível.


Características do Scrum

O Scrum é consistente com o manifesto ágil:

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”;

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”;

O processo produz frequentes incrementos de software “que podem ser inspecionados, ajustados, testados, documentados e expandidos”;


Características do Scrum

O trabalho de desenvolvimento e o pessoal que o realiza é divido “partições claras, de baixo acoplamento, ou em pacotes”;

Testes e documentação constantes são realizados à medida que o produto é construído;

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 ...)”.


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

Product BacklogPendência de Produtos:

Características priorizadas do produto desejado pelo cliente

Sprint BacklogRegistro de Pendências

Características associadas aum sprint

a cada 24 horas

2 a 4 semanas

Nova funcionalidadeAo final do sprint

15 minutos de reunião diária.


Forma de trabalho do Scrum

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;



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;



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.



Novas funcionalidades: entrega o incremento de software ao cliente de modo que a funcionalidade implementada possa ser demonstrada e avaliada pelo cliente.


Equipe do Scrum

Equipe padrão de trabalho do Scrum 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; Product Owner: Representa a voz do cliente/usuário e muitas vezes é o próprio. É responsável por criar o Product Backlog; Scrum Time: Grupo de desenvolvimento do sprint (programadores, testadores e etc...).


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.

Engenharia de Software Desenvolvimento Ágil Capítulo 4 Engenharia de Software Roger Pressman 6a....

Documents

Transcript of Engenharia de Software Desenvolvimento Ágil Capítulo 4 Engenharia de Software Roger Pressman 6a....