Grupo:Felipe de Mesquita
Philippe NorbertSilvio Carréra
• RAD• Prototipação• Metodologias Ágeis• XP• SCRUM• Pros e Cons de RAD e Ágeis• Agradecimentos e Perguntas.
• Ele surgiu para “combater” as metodologias procedurais dos anos 70.
• Criado por James Martin, nos anos 80.
James Martin
• Pequenos Ciclos ou TimeBoxes.• Uso de ferramentas CASE (Computer Aided
Software Engineering).• Construção de protótipos rapidamente.• Iterações
Protótipos são modelos construídos para simular a aparência e funcionalidade de um produto em desenvolvimento.
1. Identificar Requerimentos Básicos
2.Desenvolver Protótipo Inicial
3. Review 4. Melhora do
Protótipo
Horizontal
Foco na interação com usuário
Vertical
Foco em funções específicas
6.1 Protótipo Descartado
• Feito nas primeiras fases de desenvolvimento.
• Feito sem formalidade e rápido.
• Clientes tem feedback rápido dos requerimentos.
• Normalmente usado para desenvolvimento de interface
Define requerimentos iniciais
Design do protótipo descartado
Cliente usa protótipo e levanta requerimentos
Repete fase 2 se necessário
Define requerimentos finais
Faz o produto real
6.2 Protótipo Evolutivo
• Desenvolve-se um protótipo robusto.
• São sistemas funcionais, embora incompletos servem como base ao projeto final.
• Desenvolvedores podem focar em partes que conhecem do sistema.
• Feito com certa formalidade. Protótipo com fluxo de telas
Adicionado Tratamento de
Colisão
Adicionado Sistema de Fade-
in/out
6.3 Protótipo Incremental
• O projeto final é o conjunto de vários protótipos.
Jogo Final
Protótipo de Gerenciador de
Telas
Protótipo de Gerenciador de
Som
Protótipo de Tratamento de
Colisões
Protótipo de tratamento de
controle
• Projetos de Construção Civil
• São geralmente construídos como planejados
• Clientes acompanham a evolução
• Se algo dá errado, faz-se um relatório
• Projetos de Software
• Precisam suportar mudanças nas regras de negócio
• Clientes só vêem algo funcionando perto do fim ou em prazos longos
• Se algo dá errado, se esquece ou mascara o erro
3/26/2011 RAD x Ágeis
Algumas empresas adotam metodologias de desenvolvimento e práticas extremamente formais e controladoras, porém ainda não conseguem obter qualidade.
• Por quê?o Pouca preocupação com as pessoas e a interação entre elaso Pouca comunicação com o clienteo Custos muito altoso Excesso de formalismo
• Qual a consequência disso?o Alta rotatividadeo No fim o software não serve maiso Projeto canceladoo Prazos estourados
3/26/2011 RAD x Ágeis
Algumas empresas adotam metodologias de desenvolvimento e práticas extremamente Além disso muitas empresas vivem em uma situação de total descontrole e falta de qualidade, e não são nada ágeis, vivem o ...
3/26/2011 RAD x Ágeis
• Situação perturbadora, desmotivante;
• Utilizando processo definido ou não;
• Altos riscos nos projetos;• Custos muito altos;• Projetos sem boa qualidade
interna e externa.
Mas esse problema não é novo, em 2001, 17 caras lançaram o ...
3/26/2011 RAD x Ágeis
Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin Fowler
Robert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas
James GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian Marick
O que é isso?• Um manifesto que criticava algumas mitos/práticas da
engenharia de software e da gerência de projetos adotadas por abordagens tradicionalistas
• Foi assinado por 17 pessoas envolvidas com desenvolvimento de software, dentre eles consultores e programadores experientes
3/26/2011 RAD x Ágeis
• Indivíduos e interação entre eles 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
3/26/2011 RAD x Ágeis
12 princípios por traz do Manifesto Ágil
1. Satisfazer o cliente• As mudanças são bem vindas• Entrega periódica de funcionalidade• Todos juntos• Indivíduos Motivados• Conversas face a face• Medida primária é o software trabalhado• Manter um ritmo constante sempre• Atenção contínua, excelência técnica e bom projeto• Simplicidade• Equipes auto-organizáveis ou auto-gerenciáveis• Reflexão de melhoria regularmente
3/26/2011 RAD x Ágeis
XP – eXtreme ProgrammingSCRUMLEANCRYSTALFDD...
3/26/2011 RAD x Ágeis
Começou a engatinhar 1987 e a se estruturar em 1996 com o projeto C3 da Chrysler
Criado pro Kent Beck, que utilizou pela primeira vez em conjunto as práticas que formam a estrutura do Extreme Programming nesse projeto da Chrysler
“Jeito leve, eficiente, de baixo risco, flexível, previsível, científico e divertido de desenvolver software” – Kent Beck
3/26/2011 RAD x Ágeis
• Valores: Comunicação Simplicidade Feedback Coragem
• Abordagem Incremental
3/26/2011 RAD x Ágeis
• Refatorar• Propriedade
Coletiva• Integração Contínua• 40 horas semanais
de trabalho• Cliente presente• Padronização do
Código
• Planejamento• Entregas
Frequêntes• Metáfora• Projeto Simples• Testes• Programação em
pares
3/26/2011 RAD x Ágeis
Por quê? Gasta-se tempo fazendo coisas inúteis que
servem para aumentar o escopo, o tempo e o custo do projeto
Como? Triando o que é essencial, importante e desejável Assumindo a regra “80-20”
Entregando 80% dos benefícios
3/26/2011 RAD x Ágeis
Como? Definição de histórias Valor de negócio das histórias Definição de releases Estimativa com base nas experiências anteriores Observação de riscos Medições de progresso
3/26/2011 RAD x Ágeis
Consiste em colocar o sistema em produção com freqüência, em prazos curtos, normalmente de dois ou três meses.
Objetivos:• Feedbacks rápidos do cliente e para o cliente• Aceitação de mudanças rápidas e sem burocracia
3/26/2011 RAD x Ágeis
Utilizam as metáforas para inserir a estrutura conceitual do negócio.
Objetivos: Facilidade de entendimento e compreensão Envolvidos compreendem o que se quer, mesmo não
dominando a linguagem do negócio.
3/26/2011 RAD x Ágeis
Projete um software do jeito que o usuário espera: Primeiro que funcione E funcione corretamente Que seja fácil de utilizar (modelo mental coerente) E que possa evoluir com o tempo
3/26/2011 RAD x Ágeis
• Partindo do pressuposto que achar as causas do bug é mais difícil e demorado que corrigir
• Então vamos evitar o problema• Evitar problema é mais inteligente que resolver• TDD (Test Driven Development) consiste em escrever um
mecanismo de teste automatizado antes de codificar cada história e cada método do sistema (BECK, 2000)
3/26/2011 RAD x Ágeis
“O XP se concentra sobretudo em dois tipos de testes: o teste de unidade e o teste de aceitação. O primeiro tenta assegurar que cada componente do sistema funcione corretamente. O segundo procura testar a interação entre os componentes, as quais dão origem às funcionalidades.”
[BECK, 2000 apud TELLES, 2005]método do sistema (BECK, 2000)
3/26/2011 RAD x Ágeis
• Dois programadores continuamente colaborando no mesmo projeto, algoritmo, código e teste.
• Diminui erros de código, permite a refatoração instantânea, aprendizado contínuo, etc.
3/26/2011 RAD x Ágeis
A “refatoração é o processo de fazer mudanças em um código existente e funcional sem alterar seu comportamento externo. [...]” [ASTELS, 2003 apud TELLES,2005
Objetivos: Enxugar o código (Tornar simples e claro) Melhor a eficiência do código Minimizar chances de introduzir bugs
Garantias Melhoria interna contínua
3/26/2011 RAD x Ágeis
O desenvolvedor tem acesso a todo o códigoO código é de todos os desenvolvedores e qualquer um pode melhorar até aquilo que não fez
As alterações podem causar erros. Por segurança, é indicado adotar essa prática apenas quando se tem testes de regressão automatizados
3/26/2011 RAD x Ágeis
Os pares trabalham de forma isolada, mas integram o que produzem diversas vezes ao dia.Objetivos: Identificar conflitos cedo, para evitar futuras falhas de
integraçãoConsequência: Identificação quase que instantânea de conflito, já que se
produz pouco código em poucas horas
3/26/2011 RAD x Ágeis
3/26/2011
• Hora extra é exceção• Em atividade de 40 horas semanais já ocorre a diminuição
do fator foco• Pressões não aumentam o fator foco, pelo contrário
diminuem
RAD x Ágeis
“O melhor e mais participativo cliente não será capaz de obter o software desejado se a equipe de desenvolvimento não implementar corretamente o que é pedido e a melhor equipe não será capaz de produzir o software certo se o cliente não for capaz de especificá-lo adequadamente e prover feedback ao longo do projeto.” [TELLES, 2005]
Junte-os e terá: Feedbacks mais rápidos Mudanças rápidas sem burocracia
3/26/2011 RAD x Ágeis
“O melhor e mais participativo cliente não será capaz de obter o software desejado se a equipe de desenvolvimento não implementar corretamente o que é pedido e a melhor equipe não será capaz de produzir o software certo se o cliente não for capaz de especificá-lo adequadamente e prover feedback ao longo do projeto.” [TELLES, 2005]
Junte-os e terá: Feedbacks mais rápidos Mudanças rápidas sem burocracia
3/26/2011 RAD x Ágeis
• O nome é originado da organização de uma equipe de Rugby para o reinicio da partida.
• Formalizado e implantado no desenvolvimento de software em 1995 por Ken Shwaber
• A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software
3/26/2011 RAD x Ágeis
• O que é de fato?o É um framework de desenvolvimento de produto, sobre um
ciclo de vida interativo e incremental
• Objetivos:o Acompanhamento contínuoo Iterações curtaso Retorno mais rápido
3/26/2011 RAD x Ágeis
• Quais são os papeis envolvidos?o Product Owner (PO)o Scrum Teamo Scrum Master
3/26/2011 RAD x Ágeis
• Conhece o produto e as necessidades do cliente
• Representa o cliente• Define os requisitos do produto,
bem como sua importância e urgência
• É responsável pelo retorno do investimento
3/26/2011 RAD x Ágeis
• É o líder servidor• Responsável por remover
os impedimentos do time• Por remover interferências
externas• E por garantir o uso correto
do Scrum• Ensina Scrum aos
envolvidos
3/26/2011 RAD x Ágeis
• Fazem parte do Scrum team todos os desenvolvedores, arquitetos, analistas, ... que participam do projeto
• O time é auto-gerenciável e multifuncional ou multidisciplinar (pessoas com diferentes aptidões)
• Decidem junto com o PO o que entra no Sprint
• E são responsáveis pelas estimativas de esforço
3/26/2011 RAD x Ágeis
• São elas:o Planejamentos de Sprinto Revisões de Sprinto Retrospectivas de Sprinto Reuniões diárias
3/26/2011 RAD x Ágeis
• Product Backlogo Lista priorizada de requisitos (Lista mutável)
• Sprint Backlogo Itens que serão feitos na Sprint (Lista não
mutável)• Burndown Charts
o O trabalho acumulado ou realizado (atualizados diariamente durante um Sprint)
3/26/2011 RAD x Ágeis
3/26/2011 RAD x Ágeis
RAD x Ágeis3/26/2011
• Scrum não define técnicas de Engenharia de Software
• Foi construído inicialmente para o desenvolvimento de software
• Porém, é um framework para gerenciamento do desenvolvimento de um produto
• Por isso uma parceria de sucesso no desenvolvimento de software é:o SCRUM + XP (Algumas práticas)
3/26/2011 RAD x Ágeis
• SCRUM é uma excelente alternativa para empresas que estão no CAOS
• É interessante para equipes pequenas, onde a comunicação possa funcionar de forma tranquila
• XP define boas práticas que contribuem para uma boa comunicação e para a prevenção de problemas
• Ambas se preocupam e melhoria contínua da qualidade, através de avaliação contínua do trabalho e do processo
3/26/2011 RAD x Ágeis
“Que se move ou age com muita facilidade.”
“Que se move depressa, com muita velocidade”
Metodologias Ágeis Metodologias RAD
Alto Controle por parte dos Gestores Reutilização de Componentes
Reduz o tempo de entrega da 1ª versão Tempo de Desenvolvimento Reduzido
Planejamento Alta Interação com o Usuário
Respostas Rápidas a Mudanças
Metodologias Ágeis Metodologias RAD
Menor Controle dos Custos Reutilização não garante eficiência
Baixo Custo Pode Comprometer Qualidade
Sem Planejamento
• Aplicação puder ser modularizada• Funções devem ser desenvolvidas em até 3 meses
• Tenta diminuir o retrabalho.• Simplicidade. (Códigos Simples, porém
EFICIENTES.)