◾ Desenvolvimento de Software

Métodos Àgeis de Tradicional

Desenvolvimento • Problemas do Desenvolvimento
de Software
Tradicional
◾ Métodos Ágeis de
Desenvolvimento
• Manifesto Àgil
• Princípios
◾ Práticas Ágeis
◾ XP
◾ Scrum
◾ Outras Metoologias

2
◾ http://www.agilcoop.org.br/curso_de_verao_2010
◾ http://www.scrumalliance.org/
◾ http://www.extremeprogramming.org/
◾ http://improveit.com.br/scrum
◾ http://visaoagil.wordpress.com/
◾ http://amagno.blogspot.com/
◾ http://www.infoq.com/br/

3
◾ Sociedade demanda
• Grande quantidade de sistemas/aplicações
• Software complexo, distribuído, heterogêneo
• Requisitos mutantes(todo ano, todo mês, toda
semana, todo dia)

5
6
7
8
9
◾ Supõem que é possivel prever o futuro.
◾ Pouca interação com os clientes.
◾ Ênfase em burocracias.
• (documentos, formulários, processos, controles
rígidos, etc...)
◾ Avaliação do progresso baseado na
evolução
da burocracia e não do código
◾ Grande quantidade de erros
◾ Falta de flexibilidade no software
desenvolvido 10
◾ Melhores tecnologias
• Padrões de projeto (reutilização de idéias)
• Componentes (reutilização de código)
• Middleware/frameworks (aumenta a abstração)

◾ Melhores metodologias
• Métodos Àgeis

11
◾ Movimento iniciado por programadores
experientes e consultores em desenvolvimento de
software.
◾
Questionam e se opõem a uma série de mitos
práticas adotadas em abordagens tradicionais de
Engenharia de Software e Gerência de Projetos.
◾ Manifesto Ágil: Assinado por 17
desenvolvedores em Utah em fevereiro/2001.
• http://agilemanifesto.org

13
◾ Indivíduos e interações são mais importantes do
que processos e ferramentas
◾ Software funcionando é mais importante do que
documentação detalhada
◾ Colaboração com o cliente é mais importante do
que negociação de contratos
◾ Adaptação às mudanças é mais importante do que
seguir um plano inicial
14
◾ Prioridade máxima: satisfazer o usuário através de
entrega rápida e contínua de software com valor.
◾ Receber bem requisitos mutantes, mesmo tarde no
desenvolvimento. Processos ágeis aguentam
mudanças para a vantagem competitiva do
consumidor.
◾ Entregar software em funcionamento com
frequência, de algumas semanas a alguns meses,
dando preferência à menor periodicidade.
15
◾ Pessoas de negócio e desenvolvedores devem
trabalhar diariamente durante o projeto.
◾ Construa projetos em volta de indivíduos
motivados. Dê a eles o ambiente e o suporte de que
eles precisam, e confie que eles farão o serviço.
◾ O método mais eficiente de passar informação para
e entre uma equipe de desenvolvimento é conversa
cara-a-cara.
16
◾ Software rodando é a principal medida de
progresso.
◾ Processos ágeis precisam de desenvolvimento
sustentável. Patrocinadores, desenvolvedores e
usuários devem aguentar manter um ritmo
constante indefinidamente.
◾ Atenção contínua à excelência técnica e
bom projeto melhora a agilidade.
17
◾ Simplicidade -- a arte de maximizar a
quantidade de trabalho não realizado -- é
essencial.

◾ As melhores arquiteturas, requisitos e projetos

emergem de equipes auto-organizadas.

◾ Em intervalos regulares, a equipe reflete sobre

como se tornar mais eficiente, e deve ajustar seu
comportamento de acordo. 18
◾ Comunicação
◾ Negociação
◾ Ciclo de Vida Iterativo
◾ Gerenciamento Ágil
◾ Modelagem Ágil
◾ Visibilidade do Projeto
20
21
◾ Evitar telefone sem fio
◾ Desenvolvedores diretamente com o cliente

22
4 VARIÁVEIS DO DESENVOLVIMENTO DE
SOFTWARE

Escop Prazo Custo Qualidade

o
Fixo Variável

Abordagem tradicional

23
 4 VARIÁVEIS DO
DESENVOLVIMENTO DE
SOFTWARE

Escop Prazo Custo Qualidade

o
Variável Fixo

Abordagem
Ágil 24
25
26
27
28
29
30
31
32
33
34
http://www.extremeprogramming.org/

http://www.scrumalliance.org/

35
Kent Beck Estados Unidos 1999

XP é leve
XP é focado no
desenvolvimento
de
software
XP funciona em times de
qualquer
tamanho
XP se adapta bem a requisitos 37
38
39
 CICLO
TRIMESTRAL
Releases

Ciclo Semanal Iterações

40
 Jogo do
Cliente escreve Estória
Planejamento

Retrospectiva
Desenvolvedores Estimam

Cliente aprova o resultado

Cliente Prioriza Estória

Desenvolvedores constroem
Desenvolvedores Implementam
tarefas

41
ESTÓRIA:

A palavra estória é um neologismo proposto por

João Ribeiro em 1919, para designar, no campo do
folclore, a narrativa popular, o conto tradicional.
Alguns consideram o termo arcaico, por ter sido
encontrado também em textos antigos, quando a
grafia história ainda não havia sido consolidada na
língua portuguesa

narrativa de cunho popular e tradicional;

◾ Estória exprimem o comportamento de uma
funcionalidade geral
◾ Estórias são escritas na linguagem natural
◾ Formato: Who – What - Why
◾ Ex:
• No papel de administrador do sistema eu quero
realizar o cadastro de usuários, para armazenar
informações de contato: nome, telefone e e-mail.
43
◾ Objetivo: Estimar custo de desenvolvimento
das estórias.
◾ Características:

 Cartas
Todos fazem estimativas para
todas as estórias
 As estimativas são individuais
 Tempo (horas/dias)
44
◾ Responsabilidade nas mãos do cliente

◾ “Aguarde e Confie”

◾ Conceito Chave no XP

◾ Limite máximo

45
◾ Ex:
• Estória: No papel de administrador do sistema eu quero
realizar o cadastro de usuários, para armazenar
informações de contato: nome, telefone e e-mail.

• Tarefas:
▪ Modelagem do banco de dados
▪ Criar Interface
▪ Implementar cadastro

46
◾ Programação em par

• Todo o código
• Um digita, outro revisa
• Redução de bugs
• Disseminação do conhecimento
• Pressão do par
• Simplicidade
• Velocidade

47
◾ Desenvolvimento dirigido a testes
◾ Propriedade coletiva do código
◾ Base de código unificada
◾ Sentar-se junto
◾ Refatoração

48
 “Se você não tiver um ambiente razoável para trabalhar, seu projeto não terá
sucesso” (Kent Beck)

◾ Quadro(s) brancos
◾ Post-it
◾ Cadeiras giratórias
◾ Jogos
◾ Comida e café
◾ Folhas em branco
◾ Privacidade

49
50
51
52
53
 •Comunicação
•Simplicidade
•Coragem
Valores •Feedback
•Respeito

Princípios

Práticas

54
 •Auto-semelhança (Self-Similarity)
• Benefício Mútuo (Mutal Benefit)
•Diversidade (Diversity)
Valores •Economia (Economics)
• Falha (Failure)
• Fluidez (Flow)
• Humanismo (Humanity)
Princípios • Melhoria (Improvement)
•Oportunidade (Opportunity)
•Passos de Bebê (Baby Steps)
•Qualidade (Quality)
• Redundância (Redundancy)
Práticas • Reflexão (Reflection)
•Responsabilidade Aceita (Accepted Respons

55
 Práticas Primárias
•Ambiente Informativo (Informative workspace)
Valores •Build de dez minutos (Ten-MinuteBuild)
•Ciclo Semanal (Weekly Cycle)
•Ciclo Trimestral (Quarterly Cycle)
•Desenvolvimento Orientado a
Testes (Test-First Programming)
Princípios •Design Incremental (Incremental
Desing)
•Equipe Integral (Whole Team)
•Folga (Slack)
•Histórias (Stories)
Práticas •Integração Contínua (Continuous
Integration)
•Programação em Par (Pair
Programming) 56
•Sentar-se junto (Sit together)
 Práticas Corolárias
• Análise da Raiz do Problema (Root-Cause Analysis)
• Base de Código Unificada (Single Code Base)
Valores • Código Coletivo (Shared Code)
• Código e testes (Code and Tests)
• Continuidade da equipe (Team Continuity)
•Contrato de Escopo Negociável
(Negotiated12 Scope Contract)
Princípios •Envolvimento do cliente Real
(Real Custumer Involvement)
• Equipes que encolhem
(Shrinking Teams)
• Implantação diária (Daily
Práticas Deployment)
• Implantação incremental
(Incremental Deployment)
• Pagar por uso (Pay-Per-Use)
57
• Pequenos ciclos de pedidos
• Escopo limitado
• Implementação das características prioritárias ao
negócio primeiro

59
• XP pede ao cliente que escolha a funcionalidade
que faça maior diferença economicamente.

60
• Muitos testes são feitos
▪ Desenvolvedores testam função por função
▪ Clientes testam funcionalidade por funcionalidade

61
• O cliente vira parte integral do time

62
• Implementação em ciclos

63
65
66
67
68
©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 16/9/2012 69
©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 16/9/2012 70
 ◾ FDD – Feature Driven Development
◾ Crystal Family
◾ DSDM (Dynamic Systems
Development Method)
◾ ASD (Adaptative Software
Development)

16/9/2012 ©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 71

◾ Estória 0:
 No papel de administrador do sistema eu quero realizar o cadastro de
usuários, para armazenar informações de contato: nome, telefone e
e-mail.

◾ Estória 1:
• O sistema deverá permitir aos usuários cadastrarem notícias. A
notícia deve ter manchete, descrição e conteúdo. O sistema deverá
listar todas as notícias.

◾ Estória 2:
• A partir da listagem das notícias, o sistema deverá permitir ao
usuário
enviar uma notícia para o e-mail de um usuário cadastrado.

©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 16/9/2012 74

©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 16/9/2012 75
◾ Seus princípios e práticas proporcionam um
equilíbrio entre as filosofias tradicionais e as
mais extremas, proporcionando uma
transição mais suave para organizações mais
conservadoras, e a retomada da
responsabilidade para as organizações que se
desiludiram com as propostas mais radicais.

©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 16/9/2012 77

◾ 1997-1998, Singapura
◾ Contexto: Desenvolvimento de um grande sistema
de empréstimos para um banco internacional
◾ Anteriormente, após 2 anos de consultoria, 3.500
páginas de casos de (in)uso e um modelo de objetos
com centenas de classes, foi avaliado como
impossível
◾ Decisão: Implantação das metodologias de OOAD
de Peter Coad e de gerência de projetos de Jeff De
Luca
◾ Resultado: 15 meses após a contratação da dupla,
2.000 features entregues por uma equipe de 50
pessoas
©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 16/9/2012 78
©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 16/9/2012 79
◾ Característica ou funcionalidade
◾
Pequena o suficiente para ser implementada
no máximo em 2 semanas
◾ Oferece valor para o cliente
◾ Mapeia passos em uma atividade de negócio
 Pode ser um passo de um caso de uso
 Às vezes pode ser o próprio caso de uso
◾
Conceito muito próximo ao de um
requisito funcional
◾ Modelo: <ação> <resultado> <objeto>
 Calcular o total de uma venda
 Autorizar uma transação com cartão de um
cliente
©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 16/9/2012 80
◾ Desenvolver um Modelo Abrangente
 Modelagem dos Processos de Negócio (BPM)
 Análise Orientada por Objetos (OOA)
◾ Construir a Lista de Features
◾ Decomposição Funcional
◾ Planejar por Feature
 Plano de Desenvolvimento
 Prioridade, Dependência, Distribuição de
Trabalho
◾ Detalhar por Feature
◾ Projeto OO (OOD), Estudo Detalhado
◾ Construir por Feature
 Programação OO (OOP)
Inspeção,
 ©2010 Testes,
| Mauricio Cesar Santos daIntegração
Purificação | Grupo DW-UFBA 81
©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 82
©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 83
©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 84
©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 85
©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 86
©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 16/9/2012 87
©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 16/9/2012 88
©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 16/9/2012 89
90
91