Universidade Federal da Paraíba

Centro de Ciências Aplicadas e Educação

Departamento de Ciência Exatas

Metodologias Ágeis
Capítulo 04
Juliana Saraiva
julianajags@dcx.ufpb.br

Disciplina: Engenharia de Software

Sumário
1. Introdução
1.1. Manifesto Ágil
2. Princípios
3. Práticas Compartilhadas
4. Metodologias
4.1 eXtreme Programming (XP)
4.2 Scrum
4.3 FDD
4.4 DSDM
4.5 TDD
4.6 Kaban
5. Tecnologias e Ferramentas
6. Dificuldades em Implantar Metodologia Ágil
7. Considerações Finais
8. Bibliografia Recomendada

2
1. Introdução
• Desenvolvimento Ágil como filosofia:
– “Desenvolvimento simples-mas-eficiente usando regras orientadas à
comunicação contínua” (Cockburn, 2001).
• Não é um processo específico (Warden & Shore, 2007)
– Existem métodos que dão suporte a esta filosofia.
• Inicialmente conhecido como Métodos Leves
– “Ligth-but-sufficient” (Cockburn, 2001)
• Manifesto Ágil (Utah - 2001)
– Encontro de 17 pesquisadores para discutir similaridades e diferenças de
metodologias leves de desenvolvimento.
3
1.1 Manifesto Ágil
Processos e
Indivíduos e Interações Ferramentas

Documentação
Software em Funcionamento Abrangente

Negociação de
Colaboração com o Cliente Contrato

Resposta às Mudanças Seguir um Plano

4
Desenvolvimento Ágil
• Uma abordagem baseada no desenvolvimento e na entrega de
incrementos de funcionalidade muito pequenos.
• Baseia-se no aprimoramento constante do código, em testes
automatizados, no envolvimento do usuário na equipe e no
desenvolvimento em pares.
• Exemplos: XP, Scrum, DSDM, FDD, TDD, Crystal Clear,
Adaptive Software Development, etc.

5
2. Princípios (Parte 01)
1. Satisfação do Consumidor
2. Mudança Constante de Requisitos
3. Entregas de Softwares Funcionais
4. Todos os Stakeholders envolvidos
5. Motivação nos projetos
6. Conversas cara-a-cara incentivadas

6
2. Princípios (Parte 02)
7. Software em Funcionamento 🡪 Medida Progresso
8. Desenvolvimento Sustentável
9. Atenção Contínua
10. Simplicidade é essencial
11. Arquiteturas e Decisões emergem de equipes
auto-organizáveis
12. Necessidade de intervalos regulares

7
3. Práticas Compartilhadas (01)
• Desenvolvimento Iterativo
• Foco na Comunicação Iterativa
• Redução de esforços para construção de artefatos
• Aplicabilidade

Cultura, Pessoal e Comunicação

8
3. Práticas Compartilhadas (02)
• Ciclo PDCA

9
4. METODOLOGIAS ÁGEIS
4.1 eXtreme Programming (XP)
• Uma das mais proeminentes metodologias
• FUNCIONAMENTO (Fases):
– Planejamento
– Análise e Projeto
– Codificação
– Teste
– Implantação

11
EXtreming Programming (XP)
XP é um processo de desenvolvimento de
softwares voltado para:
• Projetos cujos requisitos são vagos e mudam com
frequência;
• Desenvolvimento de sistemas orientados a objetos;
• Desenvolvimento incremental.

12
Estrutura da Equipe
• Gerente de projeto – assuntos administrativos
• Coach - técnico do projeto
• Analista de testes – ajuda o cliente a escrever os testes
de aceitação, detecta defeitos no sistema
• Redator técnico – ajuda na documentação do sistema
• Desenvolvedor – analisa, projeta e codifica o sistema

13
Os 5 Valores da XP
• São as diretrizes da XP
• Define as atitudes da equipe XP
– Feedback
– Comunicação
– Simplicidade
– Coragem
– Respeito

14
Princípios da XP
• Feedback rápido
– Os participantes devem estar sempre se comunicando para facilitar o
aprendizado coletivo.
• Assumir simplicidade
– Deixe o seu modelo tão simples quanto possível e assuma que a solução
mais simples é a melhor.
• Mudança incremental
– O modelo não será perfeito na primeira tentativa, ele irá mudar de
acordo com o desenvolvimento do projeto.

15
Princípios da XP
• Abraçando mudanças
– XP procura facilitar o ato de incluir alterações através do uso
de vários princípios e práticas.
– Mudanças devem ser sempre bem vindas.
– Independentemente do estágio de evolução do projeto.
• Trabalho de qualidade
– Qualidade não é um critério opcional, mas sim obrigatório.
– Sistema que atenda aos requisitos do cliente.

16
 Práticas da XP
• Processo de planejamento • Programação em pares
(Planning Game) • Propriedade coletiva do
• Releases curtos código
• Metáfora • Integração contínua
• Projeto simples • Semana de 40 horas
• Testes • On-site customer (Cliente
• Refactoring sempre presente)
• Stand up meeting • Padrões de codificação

17
4.1 PLANEJAMENTO
• Estórias de Usuário
• Cartões de Indexação
• Cliente contribui a cada estória
• Desenvolvedores atribuem um custo a cada estória

18
4.1 PROJETO
• Segue rigorosamente o KIS (Keep it Simple)
• Encoraja Refatoração
• Estimula o uso de cartões CRC (Classe, Responsabilidade
e Colaboração)

19
4.1 CODIFICAÇÃO
• Iniciar programação depois do Projeto das Estórias do
Usuário
• Testes Unitários (testar antes)
• Programação em Par

20
4.1 TESTE

• Testes Unitários
• Teste de Aceitação

21
4.1 PRÁTICAS de XP
• Pequenas versões
• Design Simples
• Programação em Par
• Desenvolvimento orientado a testes
• Refatoração
• Testes do Cliente
• Time coeso
• Código padronizado
• Código coletivo e Integração contínua
• Ritmo sustentável
• Jogo de planejamento

22
4.1 Empresas que Adotam XP
• Objective Solutions
• Improve It
• Paggo
• Caelum
• LocaWeb
• Neurobox

23
4.2 Scrum
• Foco no gerenciamento de projetos
• Baseia-se na formação Scrum do Rugby
• Artefatos Principais:
– Backlog de Produto
– Backlog de Sprint

24
Scrum
• Não tem a figura do gerente de projetos;
• Os times são auto-gerenciáveis;
• Possui características do modelo iterativo e incremental;
• É composto por papéis bem definidos;
• Possui valores, práticas e regras;
• É considerado um framework para gerência de projetos.

25
4.2 Scrum - PAPÉIS
• PRODUCT OWNER
– Intermédio entre cliente e equipe
– Atualiza e produz Backlog de Produto
– Decide as datas de lançamento
• TEAM
– Prioriza funcionalidades
– 5 a 9 pessoas
– Aceita ou rejeita os resultados dos
trabalhos – Multidisciplinar
• SCRUM MASTER – Comprometido com a meta até o fim da
Sprint
– Líder, mediador
– Assegura práticas SCRUM no processo
– Garante a colaboração entre os diversos
papéis e funções
– Escudo para interferências externas
– Mantém a produtividade do time

26
4.2 Scrum - FUNCIONAMENTO
• Definição de Backlogs
• Sprints
• Reuniões
• Revisões

27
Sprint
• É uma iteração no Scrum
• Tem duração fixa
– Normalmente de 2 a 4 semanas
• Durante a Sprint, o Scrum Master garante que não será feita nenhuma
mudança que possa afetar a Meta da Sprint
• A definição de “Pronto” deve ser estabelecida
– Quando um item do PB pode ser apresentado na Sprint Review
• A definição de “Preparado” deve ser estabelecida
– Quando um item do PB pode ser estimado na reunião de planejamento

28
Planejamento da Sprint
• Dividida em 2 partes:
– Primeira: A equipe seleciona itens do Product Backlog com os
quais compromete-se a concluir
• O Sprint Backlog é criado
– Segunda: Tarefas são identificadas e estimadas para cada
item do backlog
• Utiliza-se a técnica de estimativa Planning Poker
• O time inteiro planeja!

29
 Planning Poker
• Técnica para estimar esforço
• Utilizado no Scrum para estimar esforço das
estórias de usuários (user story)

30
Reunião de Scrum Diário (Daily Scrum Meeting)
• Todos em pé!
• Não é para solução de problemas
• As respostas não são um relatório para o ScrumMaster
• Três questões são respondidas:
– O que foi feito?
– O que será feito?
– Há algum impedimento?
• Melhora o nível de conhecimento e a comunicação da equipe
• Promove a tomada rápida de decisão

31
Sprint Review Meeting (Revisão da Sprint)
• Realizada após cada Sprint
• Todos participam
• O time apresenta o que foi realizado na sprint
• O Product Owner identifica o que foi feito e o que não
foi feito.
• É verificado se o objetivo da Sprint foi alcançado

32
Sprint Retrospective (Retrospectiva da Sprint)
• Acontece após a Revisão da Sprint e antes da próxima reunião de
Planejamento da Sprint.
• A finalidade é inspecionar como correu a última Sprint em se tratando de
pessoas, das relações entre elas, dos processos e das ferramentas.
• O Time discute sobre o que correu bem durante a Sprint e quais problemas
foram enfrentados, além de como esses problemas foram resolvidos.
– Serve como entrada para o próximo planejamento da Sprint
• A equipe discute o que gostaria de:
– Iniciar a fazer
– Parar de fazer
– Continuar fazendo

33
Artefatos no Scrum
• Sprint Burndown e Project Burndown

34
Artefatos no Scrum
• Quadro Scrum

35
Artefatos no Scrum

36
4.2 Empresas que Adotam Scrum
• Microsoft
• Yahoo
• Google
• Rede Globo (Globo.com)
• Electronic Arts
• High Moon Studios
• Lockheed Martin
• Phillips
• Siemens
• Nokia
• Capital One
• BBC

37
4.3 FDD (Feature Driven Development)
• Desenvolvimento direcionado à função/funcionalidade
– Funcionalidade “é uma função valorizada pelo cliente passível de
ser implementada em duas semanas ou menos” (Pressman, 2011)
• Filosofia segue o seguinte modelo:

• Exemplos:
– Adicione o produto ao carrinho
– Mostre as especicações técnicas do produto
– Armazene as informações de remessa para o cliente
• Está intermediária entre ágeis e tradicionais.

38
4.3 FDD PAPÉIS
• Principais • Adicionais
– Gerentes de Projeto e de – Testador
Desenvolvimento – Desenvolvedor
– Programador Chefe – Escritor Técnico
– Proprietário da Classe
– Arquiteto Chefe
• Apoios
– Gerente de Domínio e de Versão
– Especialista de Linguagem
– Administrador do Sistema
– Construtor de ferramentas CASE

39
4.3 FDD FUNCIONAMENTO

40
4.3 FDD BOAS PRÁTICAS
• Desenvolvimento por funcionalidade
• Classe proprietária
• Equipes de recursos
• Inspeção é realizada constantemente
• Gerenciamento de configuração
• Integração contínua
• Visibilidade de progressos e resultados

41
4.4 DSDM (Dynamic System Development Method)
• Dedicados a projetos com cronograma e custos apertados (Pressman,
2010)
• Tempos fixos de entrega
• Estabelece recursos para o desenvolvimento
• Usa técnica Timeboxing
• “Pouca formalidade e prazos curtos”

42
4.4 DSDM FUNCIONAMENTO
• FASE 1:
– Estudo de Viabilidade
– Estudo de Negócio
• FASE 2:
– Modelo de Iteração Funcional
• FASE 3:
– Construção da Iteração
• FASE 4:
– Implementação
43
4.4 DSDM PRINCÍPIOS
• Envolvimento
• Autonomia
• Foco nas entregas
• Eficácia
• Feedback
• Reversibilidade
• Previsibilidade
• Comunicação

44
4.4 DSDM EQUIPE
• Arquiteto
• Desenvolvedor Sênior
• Analista
• Programador
• Designer
• Usuários: embaixador, visionário e conselheiro
• Administrador de Banco de Dados
• Configurador
• Suporte Técnico
45
4.4 DSDM Empresas que Adotam DSDM

• Sema Group
• Boston Globe
• Scottish Natural Heritage

46
4.5 TDD (Test Driven Development)
• Técnica de desenvolvimento voltada à validação e
verificação.
• O teste vem primeiro, depois o código é produzido.
• Originalmente veio como uma boa prática de XP.
• Depuração de código é uma grande característica nesse
modelo.
• Testes são “Assertivas”.
47
4.5 TDD Fases

48
4.5 TDD Vantagens
• Com TDD raramente precisam usar depurador depois
que o código está pronto.
• Quando bem adotado, todo o código é coberto por
testes.
• Código modularizado e flexível.
• Identifica falhas de funcionalidades cedo.

49
4.5 TDD Limitações
• Difícil adotar em testes funcionais.
– Exs.: Interface, Banco de dados - carga, etc.
• Testes são parte da MANUTENÇÃO do sistema;
• Alto número de testes pode dar uma falsa sensação de
segurança.
– Não se pode esquecer de teste de integração, de sistema, de
usabilidade, etc.

50
4.6 BDD (Behavior Driven Development)
• Técnica que encoraja colaboração entre
desenvolvedores, setor de qualidade e stakeholders
não técnicos.
• Foco em linguagem e interação da equipe.
• Analisa o comportamento do sistema e
consequentemente das funcionalidades.

51
4.6 BDD Boas Práticas
• Envolver as partes interessadas no processo através de Outside-in
Development;
• Usar exemplos para descrever o comportamento do sistema;
• Automatizar os exemplos para prover um feedback rápido;
• Usar deve (should em inglês) na hora de descrever o comportamento de
software para ajudar esclarecer responsabilidades e permitir que
funcionalidades do software sejam questionadas;
• Usar simuladores de teste para auxiliar na colaboração entre módulos e
códigos que ainda não foram escritos.

52
4.6 BDD Desenvolvimento de fora pra dentro
• 1o desenvolvem a interface gráfica
• Cada elemento de código possui um comportamento

53
4.6 BDD Cenários BDD

54
4.6 BDD Cenários BDD - Exemplo 01

55
5. Dificuldades em Implantar Metodologia Ágil
• Empresa que não aceita mudanças.
• Locais de trabalhos não adequados à prática.
• Clientes que fazem questão de muitos artefatos.
• Sistema baseado em premiação individual.
• Contratos de escopo fechado.
• OBS.:
– Técnica de Kanban adotada no modelo Scrum.
– Lean startup e ágeis → MVP (Mínimo Produto Viável)

56
6. Considerações Finais
• Com Ágil...
– Capacita a organização a responder facilmente às mudanças.
– Entrega o código funcionando mais rapidamente e de alta
qualidade.
– Aumenta a produtividade e a satisfação do cliente.
– Fornece ambiente de satisfação na equipe de
desenvolvimento.

57
Bibliografia Recomendada
• Básica:
– Cockburn, A. (2002). Agile software development. Agile software
development series. Addison-Wesley.
– Pressman, R. (2010). Software engineering: a practitioner’s approach.
McGraw-Hill higher education. McGraw-Hill Higher Education.
– Shore, J. and Warden, S. (2007). The Art of Agile Development. O’Reilly,
first edition.
• Complementar:
– Henrik Kniberg, Scrum e XP Direto das Trincheiras
– Manifesto Ágil (http://manifestoagil.com.br/index.html )

58
Tecnologias e Ferramentas
PARA GERENCIAMENTO DE PROJETO
• XPlannerPlus (http://xplanner-plus.sourceforge.net/):
– OpenSource
– Web
– Controle de Estórias do Usuário
– Exportação de Dados XML e PDF

59
Tecnologias e Ferramentas
PARA GERENCIAMENTO DE PROJETO
• AgileFant (http://agilefant.com/):
– OpenSource
– Gestão de Backlog de Produto
– Planejamento e Controle de Iterações
– Relatórios, Gráfico e métricas
– Visualização de Daily Work da equipe

60
Tecnologias e Ferramentas
PARA GERENCIAMENTO DE PROJETO

61
Tecnologias e Ferramentas
PARA GERENCIAMENTO DE PROJETO
• Trello (https://trello.com/):
– Gerenciamento de Projeto
– Facilidade em mover tarefas entre quadros para as
reorganizar
– Integrado a serviços externos como horas

62
Tecnologias e Ferramentas
PARA GERENCIAMENTO DE PROJETO
Tecnologias e Ferramentas
PARA TESTES - JUnit
• JUnit
– Permite a escrita de código rapidamente
– É elegante e simples.
– Uma vez escritos, os testes serão executados rapidamente
– O próprio framework checa os resultados dos testes e
fornece uma resposta imediata;
– Tudo criado no JUnit é escrito puramente em Java;
– JUnit é uma ferramenta livre.
64
Tecnologias e Ferramentas
PARA TESTES - JUnit

65
Tecnologias e Ferramentas
PARA TESTES - JMeter
• JMeter

– Usado para testes de carga e de aceitação

– Ferramenta Web
– Simula diversos acessos simultâneos

66
Tecnologias e Ferramentas
PARA TESTES - JMeter
Tecnologias e Ferramentas
PARA PROGRAMAÇÃO EM PAR - PEP
• PEP (Pair Eclipse Programming)

– Sincronismo de Código
– Chats
– Concepção de novos requisitos
– Compartilhamento automatizado de projetos

68
Tecnologias e Ferramentas
PARA PROGRAMAÇÃO EM PAR - PEP

69