Aula - Metodologias Ágeis

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

16/9/2012 ©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 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/


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


 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

 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


 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


 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


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


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


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

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

 Comunicação
 Negociação
 Ciclo de Vida Iterativo
 Gerenciamento Ágil
 Modelagem Ágil
 Visibilidade do Projeto


 Evitar telefone sem fio
 Desenvolvedores diretamente com o cliente


4 variáveis do desenvolvimento de Software

Escop Prazo Custo Qualidade
o
Fixo Variável

Abordagem tradicional


4 variáveis do desenvolvimento de Software

Escop Prazo Custo Qualidade
o
Variável Fixo

Abordagem Ágil

http://www.extremeprogramming.org/

http://www.scrumalliance.org/


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
vagos e que mudam
16/9/2012
rapidamente
©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 37

Ciclo Trimestral Releases

Ciclo Semanal Iterações


Cliente escreve estórias Jogo do
Planejamento

Retrospectiva
Desenvolvedores Estimam

Cliente aprova o resultado
Cliente Prioriza as estórias

Desenvolvedores constroem
Desenvolvedores Implementam
tarefas


 Estórias 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.

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


 Responsabilidade nas mãos do cliente

 “Aguarde e Confie”

 Conceito Chave no XP

 Limite máximo


 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


 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


 Desenvolvimento dirigido a testes

 Propriedade coletiva do código

 Base de código unificada

 Sentar-se junto

 Refatoração


“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


•Comunicação
•Simplicidade
•Coragem
Valores •Feedback
•Respeito

Princípios

Práticas


•Auto-semelhança (Self-Similarity)
• Benefício Mútuo (Mutal Benefit)
Valores •Diversidade (Diversity)
•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 Responsa


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)
•Integração Contínua (Continuous Integration)
Práticas •Programação em Par (Pair Programming)
•Sentar-se junto (Sit together)
•Trabalho Energizado (Energized Work)


Práticas Corolárias
• Análise da Raiz do Problema (Root-Cause Analysis)
• Base de Código Uniﬁcada (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 Deployment)
• Implantação incremental (Incremental Deployment)
Práticas • Pagar por uso (Pay-Per-Use)


• Pequenos ciclos de pedidos
• Escopo limitado
• Implementação das características prioritárias ao
negócio primeiro


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


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


• O cliente vira parte integral do time


• Implementação em ciclos


 FDD – Feature Driven Development
 Crystal Family
 DSDM (Dynamic Systems Development
Method)
 ASD (Adaptative Software Development)


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


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


 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

 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

 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, Testes, Integração


Aula - Metodologias Ágeis

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Aula - Metodologias Ágeis

Mais de Mauricio Cesar Santos da Purificação

Aula - Metodologias Ágeis