APS - RAD x Ágeis

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


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


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


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


• 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


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


XP – eXtreme ProgrammingSCRUMLEANCRYSTALFDD...


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


• Valores: Comunicação Simplicidade Feedback Coragem

• Abordagem Incremental


• 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


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


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


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


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.


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


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


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


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


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


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


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

• 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


• 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


• 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


• Quais são os papeis envolvidos?o Product Owner (PO)o Scrum Teamo Scrum Master


• 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


• É 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


• 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


• São elas:o Planejamentos de Sprinto Revisões de Sprinto Retrospectivas de Sprinto Reuniões diárias


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


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)


• 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


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

APS - RAD x Ágeis

Technology

Transcript of APS - RAD x Ágeis