Metodologias geis

Pgina 1 de 18

METODOLOGIAS GEIS
O QUE UMA METODOLOGIA GIL?
DESENVOLVIMENTO AD-HOC DE SOFTWARE EM GERAL PRODUZ RESULTADOS MUITO RUINS. ESPECIALMENTE EM SISTEMAS GRANDES! ENGENHARIAS TRADICIONAIS COLOCAM GRANDE NFASE EM PROJETAR ANTES DE CONSTRUIR. VISO TRADICIONAL DA ENGENHARIA DE SOFTWARE NOS MOSTRA QUE:

QUEREMOS AGORA PODER ALTERAR SOFTWARE: NO INICIO DO PROJETO, NORMALMENTE NO SE SABE PRECISAMENTE O QUE SE QUER SOFTWARE EVOLUI PARA ATENDER AO NEGCIO SOFTWARE NUNCA FICA PRONTO PRECISAMOS PARAR DE TENTAR EVITAR MUDANAS

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM

19/11/2004

Metodologias geis

Pgina 2 de 18

MUDANAS SO UM ASPECTO INTRNSECO DA VIDA DO SOFTWARE PRECISAMOS DE UMA METODOLOGIA DE DESENVOLVIMENTO QUE NOS PERMITA ALTERAR CONSTANTEMENTE O CDIGO SEM COMPROMETER SUA QUALIDADE QUEREMOS ENXERGAR UMA VISO DIFERENTE DA ENGENHARIA DE SOFTWARE:

MTODOS GEIS (AM) SO UMA COLEO DE METODOLOGIAS BASEADA NA PRTICA PARA MODELAGEM EFETIVA DE SISTEMAS BASEADOS EM SOFTWARE. UMA FILOSOFIA ONDE MUITAS METODOLOGIAS SE ENCAIXAM. AS METODOLOGIAS GEIS APLICAM UMA COLEO DE PRTICAS, GUIADAS POR PRINCPIOS E VALORES QUE PODEM SER APLICADOS POR PROFISSIONAIS DE SOFTWARE NO DIA A DIA.

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM

19/11/2004

Metodologias geis

Pgina 3 de 18

NOS LTIMOS 10 (DEZ) ANOS, METOLOGIAS GEIS TEM SURGIDO. TEVE COMO PRINCIPAL MOTIVAO CRIAR ALTERNATIVAS PARA O MODELO DE DESENVOLVIMENTO EM CASCATA. EM NOVEMBRO DE 2001 UM GRUPO DE DEZESSETE PESSOAS, REFERNCIAS MUNDIAIS EM DESENVOLVIMENTO DE SOFTWARE, SE REUNIU PARA ENTRE OUTRAS COISAS DISCUTIREM A VIRADA DA MESA! FOI A QUE SURGIU O MANIFESTO GIL, QUE DEFINE OS SEGUINTES PRINCPIOS: INDIVDUOS E INTERAES SO MAIS IMPORTANTES QUE PROCESSOS E FERRAMENTAS. SOFTWARE FUNCIONANDO MAIS IMPORTANTE DO QUE DOCUMENTAO COMPLETA E DETALHADA. COLABORAO COM O CLIENTE MAIS IMPORTANTE DO QUE NEGOCIAO DE CONTRATOS. ADAPTAO A MUDANAS MAIS IMPORTANTE DO QUE SEGUIR O PLANO INICIAL. PODEMOS ENCARAR O O MANIFESTO GIL COMO UMA INQUIETAO MOTIVADA POR: REAO S METODOLOGIAS PESADAS MENOS ORIENTAO AO DOCUMENTO MAIS ORIENTAO AO CDIGO MTODOS CLAROS E ADAPTVEIS PROCESSOS GEIS: MINIMAMENTE CARREGADOS COM ATIVIDADES QUE CONSOMEM E NO PRODUZEM NENHUM GANHO VISVEL

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM

19/11/2004

Metodologias geis

Pgina 4 de 18

IMPORTANTE ENTERDERMOS QUE METODOLOGIAS GEIS, SO UMA ATITUDE, NO UM PROCESSO PRESCRITIVO. UM SUPLEMENTO AOS MTODOS EXISTENTES, ELE NO UMA METODOLOGIA COMPLETA. UMA FORMA EFETIVA DE SE TRABALHAR EM CONJUNTO PARA ATINGIR AS NECESSIDADES DAS PARTES INTERESSADAS NO PROJETO. UMA COISA QUE FUNCIONA NA PRTICA, NO TEORIA ACADMICA. NO UM ATAQUE DOCUMENTAO, PELO CONTRRIO ACONSELHA A CRIAO DE DOCUMENTOS QUE TEM VALOR. UTILIZAM O MODELO ITERATIVO E INCREMENTAL. O CLIENTE FAZ PARTE DA EQUIPE DE DESENVOLVIMENTO.

APRESENTAO DE ALGUMAS METODOLOGIAS GEIS

EXTREME PROGRAMMING - XP
XP UMA ABORDAGEM DELIBERADA E DISCIPLINADA PARA DESENVOLVIMENTO DE SOFTWARE. CRIADA POR KENT BAECK EM 1996 DURANTE O PROJETO DAIMLER-CHRYSLER. O SUCESSO DE XP ADVM DA INTENSA SATISFAO DO CLIENTE. CLIENTE SATISFEITO O MELHOR INDICATIVO DE SUCESSO DE UM PROJETO.

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM

19/11/2004

Metodologias geis

Pgina 5 de 18

ESTA METODOLOGIA FOI CRIADA PARA PRODUZIR O SOFTWARE QUE O CLIENTE PRECISA QUANDO ELE NECESSRIO. XP ENCORAJA OS DESENVOLVEDORES A ATENDER AS REQUISIES DE MUDANAS DOS REQUISITOS DO SOFTWARE, NO MOMENTO EM ISTO ACONTECE. EM XP ALGUNS PRINCPIOS TRADUZEM O ESPRITO DA METODOLOCIA E DEVEM SEREM RIGOROSAMENTE SEGUIDOS E PLANEJADOS. SIMPLICIDADE COMUNICAO FEEDBACK CORAGEM
SIMPLICIDADE

TENTE SEMPRE DESENVOLVER A SOLUO MAIS SIMPLES POSSVEL. MUITOS PROJETOS PERDEM MUITO TEMPO QUANDO OS DESENVOLVEDORES DESTINAM MUITO TEMPO DESENVOLVENDO UMA SOLUO GENRICA. A SOLUO DEVE RESPONDER SIMPLESMENTE UM REQUISITO DO USURIO. ALGUMAS FUNCIONALIDADES PODEM NUNCA VIR A SEREM UTILIZADAS.
COMUNICAO

CANAL ABERTO DE COMUNIO ENTRE A EQUIPE DE DESENVOLVIMENTO E COM OS USURIOS. A COMUNICAO CHAVE PARA O SUCESSO.

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM

19/11/2004

Metodologias geis

Pgina 6 de 18

FEEDBACK

FEEDBACK POSSIBILITA QUE O SOFTWARE EVOLVA PERGUNTE AO SOFTWARE, NO A UM DOCUMENTO FEEDBACK PRECISA SER: CEDO (PRA GENTE DESCOBRIR LOGO SE EST FAZENDO A COISA CORRETA) CONCRETO (FEEDBACK ORIUNDO DO CDIGO) CONSTANTE (O CICLO DE DESENVOLVIMENTO TEM QUE SER CURTO)
CORAGEM

COLOCAR O CLIENTE A PAR DO QUE T ACONTECENDO ACREDITAR NA CAPACIDADE DE RESPONDER A MUDANAS APRENDER COM OS ERROS ACREDITAR NO FEEDBACK (NO NA TEORIA) JOGAR PRA GANHAR (NO PRA TER UMA DESCULPA) FAZER O QUE PRECISA SER FEITO JOGAR FORA CDIGO RUIM O PROJETO INCIADO EM XP COM O LEVANTAMENTO DAS "ESTRIAS DOS USURIOS". CADA ESTRIA ESCRITA PELO USURIO E CONSISTE DE UM OU ALGUNS PARGRAFOS DE UM TEXTO NARRATIVO/DESCRITIVO. NO TEXTO TCNICO.

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM

19/11/2004

Metodologias geis

Pgina 7 de 18

O PROPSITO DA ESTRIA NO DEFINIR TODA A FUNCIONALIDADE DE UM CENRIO, MAS SIM, ESTIMAR COMO SER A COMPLEXIDADE DE PARTE DO SISTEMA EM QUANTO TEMPO ISSO SER DESENVOLVIDO. TODOS OS DEMAIS DETALHES DA ESTRIA SERO ESCLARECIDOS COM O CLIENTE, IMEDIATAMENTE AO INCIO DO DESENVOLVIMENTO. O PRXIMO PASSO O PLANEJAMENTO DO RELEASE, ONDE SER DEFINIDO QUAIS ESTRIAS DEVERO SER DESENVOLVIDADAS EM QUAIS RELEASES. CADA RELEASE CONSISTE DE UM NMERO DE ITERAES. CADA ITERAO TER UM CONJUNTO DE ESTRIAS IMPLEMENTADAS. EM CADA ITERAO,: PLANEJE, PARA QUE VOC SEMPRE FAA A COISA MAIS IMPORTANTE AINDA A FAZER CODIFIQUE, SENO O SOFTWARE NO SAI TESTE, SENO VOC NO SABE SE EST FUNCIONANDO REFATORE, SENO O CDIGO VAI FICAR TO RUIM QUE SER IMPOSSVEL DAR MANUTENO ESCUTE, PARA QUE VOC SAIBA QUAL O PROBLEMA A RESOLVER O REFATORAMENTO E OS TESTES AUTOMTICOS SO ATIVIDADES FUNDAMENTAIS EM XP.
REFATORAMENTO

REFATORAR MELHORAR O CDIGO SEM ALTERAR SUA FUNCIONALIDADE ANTES DE UMA MUDANA, VOC REFATORA O
file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM 19/11/2004

Metodologias geis

Pgina 8 de 18

, CDIGO PARA QUE A MUDANA SEJA SIMPLES DE FAZER REFATORAO CONTINUA POSSIBILITA MANTER UM DESIGN LEGAL, MESMO COM MUDANAS FREQENTES
TESTES AUTOMTICOS

TESTES AUTOMTICOS SO PARTE DO SOFTWARE SE VOC TEM SOMENTE A FUNCIONALIDADE, SEU SOFTWARE EST INCOMPLETO TESTES PERMITEM QUE VOC REFATORE SEM MEDO DE QUEBRAR O CDIGO TESTES REPRESENTAM UMA REDUNDNCIA LGICA QUE VOC ADICIONA AO CDIGO ESCREVENDO TESTES ANTES DA FUNCIONALIDADE, VOC CLAREIA DVIDAS SOBRE O QUE O SOFTWARE DEVE FAZER ALGUMAS PRTICAS IMPORTANTES EM XP: PROJETO MAIS SIMPLES POSSVEL PROGRAMAO EM PARES PROPRIEDADE COLETIVA DO CDIGO CLIENTE SEMPRE DISPONVEL ESTRIAS DO USURIO PLANEJAMENTO DO RELEASE
PROJETO MAIS SIMPLES POSSVEL

PROJETOS FLEXVEIS SO UMA DEFESA CONTRA MUDANAS IMPREVISTAS NO SOFTWARE PORM, PROJETOS FLEXVEIS TAMBM TM

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM

19/11/2004

Metodologias geis

Pgina 9 de 18

, CUSTOS TEMPO PARA DESENVOLVIMENTO E MANUTENO O CDIGO FICA MAIS COMPLEXO MUITA VEZES A FLEXIBILIDADE NO UTILIZADA NUNCA COMO MUDANA BARATA EM XP, VAMOS MANTER O PROJETO MAIS SIMPLES POSSVEL, MODIFICANDO-O QUANDO FOR NECESSRIO SUPORTAR MAIS FUNCIONALIDADE O MELHOR PROJETO AQUELE QUE: RODA TODOS OS TESTES NO CONTM DUPLICAO DE FUNCIONALIDADE DEIXA CLARO AS DECISES DE DESIGN IMPORTANTES TEM O MENOR NMERO POSSVEL DE CLASSES E MTODOS O MELHOR PROJETO NO AQUELE: MAIS FLEXVEL (COM MAIS GANCHOS) MAIS ABSTRATO QUE RESISTIR AO TEMPO
PROGRAMAO EM PARES

SE REVISO DE CDIGO LEGAL, VAMOS FAZ-LA O TEMPO TODO EM XP, PROGRAMAO FEITA EM PARES PARES MUDAM COM RELATIVA RAPIDEZ (EM DIAS)

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM

19/11/2004

Metodologias geis

Pgina 10 de 18

( PROGRAMAO EM PARES FAVORECE COMUNICAO E APRENDIZADO

MAS, VOC PRECISA ESTABELECER UM PADRO DE CODIFICAO H CASOS DE REDUO NO TEMPO DE DESENVOLVIMENTO COM PROGRAMAO EM PARES
PROPRIEDADE COLETIVA DO CDIGO

DESENVOLVIMENTO COM OBJETOS LEVA A ALTERAES POR TODO O CDIGO COORDENAR ALTERAES TOMA TEMPO E GERA RESISTNCIAS NO DONO DO CDIGO EM XP, "NO SE COORDENA", SIMPLESMENTE FAZSE O QUE PRECISA SER FEITO MAS INTEGRA-SE FREQENTEMENTE NO MXIMO, UMA VEZ POR DIA TODOS SO RESPONSVEL POR TODO O CDIGO QUALQUER UM QUE V UMA OPORTUNIDADE DE ADICIONAR VALOR AO CDIGO, DEVO FAZ-LO MANTENDO EM VISTA AS PRIORIDADES DO CLIENTE MANTENDO O DESIGN MAIS SIMPLES POSSVEL TESTES PROTEGEM A FUNCIONALIDADE PADRO DE CODIFICAO EVITA A GUERRA DOS PARNTESES
CLIENTE SEMPRE DISPONVEL

UM CLIENTE (USURIO DA APLICAO) DEVE TRABALHAR COM O TIME PARA ESCLARECER

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM 19/11/2004

Metodologias geis

Pgina 11 de 18

DVIDAS E ESTABELECER PEQUENAS PRIORIDADES MUITO CARO COLOCAR UM CLIENTE A DISPOSIO DO DESENVOLVIMENTO? TALVEZ ENTO NO VALHA A PENA FAZER O SISTEMA...
ESTRIAS DO USURIO

USURIOS ESCREVEM ESTRIAS DESCREVENDO A FUNCIONALIDADE QUE QUEREM DESENVOLVEDORES ESTIMAM O TEMPO NECESSRIO PARA IMPLEMENTAR CADA ESTRIA UM RELEASE UM CONJUNTO DE ESTRIAS QUE SO DISPONIBILIZADOS SIMULTANEAMENTE AS ESTRIAS MAIS IMPORTANTES E/OU MAIS DIFCEIS TEM PRIORIDADE
PLANEJAMENTO DO RELEASE
O CLIENTE DECIDE: ESCOPO PRIORIDADE COMPOSIO DO RELEASE DATA DO RELEASE OS PROGRAMADORES DECIDEM ESTIMATIVAS CONSEQNCIAS PROCESSO PLANEJAMENTO INTRARELEASE (O MAIS ARRISCADO PRIMEIRO)

XP PRECONIZA RELEASES PEQUENOS E FREQENTES (A CADA 2-3 MESES) AS QUATRO DIMENSES DO DESENVOLVIMENTO DE SOFTWARE SO CUSTO, TEMPO, QUALIDADE E ESCOPO XP TENTA MANTER ESCOPO COMO VARIVEL LIVRE RELEASES SO DIVIDIDAS EM ITERAES DE 2-3 SEMANAS

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM

19/11/2004

Metodologias geis

Pgina 12 de 18

UMA ITERAO ALCANA ALGUM OBJETIVO (TIPICAMENTE A ADIO DE NOVA FUNCIONALIDADE) NADA FEITO QUE NO SEJA IMEDIATAMENTE TIL E NECESSRIO PARA NO IMPACTAR OS PRAZOS DE DESENVOLVIMENTO PROBLEMAS EM XP CONSIDERAR TESTES COMO PARTE NORMAL DO PROCESSO DE DESENVOLVIMENTO SEMPRE FAZER A COISA MAIS SIMPLES ADMITIR QUE VOC NO SABE COLABORAR VENCER RESISTNCIA NAS PESSOAS TIMES GRANDES SITUAES EM QUE VOC NO PODE MUDAR LIVREMENTE O CDIGO

FEATURE DRIVEN DEVELOPMENT - FDD

FEATURE DRIVEN DEVELOPMENT UMA METODOLOGIA GIL CRIADA POR JEFF DE LUCA E PETER CODE. FOI RECONHECIDA EM 1997. FDD POSSUI REQUISITOS MAIS FORMAIS E MAIS PASSOS QUE XP, ALM DE POSSUIR UM MECANISMO MAIS PRECISO PARA ACOMPANHAMENTO DO PROJETO. O DESENVOLVIMENTO BASEADO EM FDD CONSISTE DE DOIS ESTGIOS PRINCIPAIS: DESCOBRIR UMA LISTA DE "FEATURES" A SEREM

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM

19/11/2004

Metodologias geis

Pgina 13 de 18

IMPLEMENTADAS. IMPLEMENTAO BASEADA EM "FEATURES". DESCOBRIR A LISTA DE "FEATURES" SEM DVIDA O PROCESSO MAIS CRTICO. A CHAVE PARA O SUCESSO DO PROJETO! A QUALIDADE COM A QUAL SE IDENTIFICA A LISTA DE "FEATURES" DEFINE QUO PRECISO O PROJETO SER CONTROLADO, QUO EXTENSVEL E MANUTENIBILIDADE O CDIGO TER. REQUER PARTICIPAO INTEGRAL DO CLIENTE JUNTO EQUIPE DE DESENVOLVIMENTO. COMO A IDENTIFICAO DA LISTA DE "FEATURES" DERIVA-SE UM DIAGRAMA DE CLASSES DE ANLISE. AS RESPONSABILIDADES DAS CLASSES DEVEM EXPRESSAR UM LINGUAJAR COMUM ENTRE DEVESENVOLVEDORES E USURIOS. POR EXEMPLO: IMAGINEM UM SISTEMA DE COMPRAS ON-LINE ONDE O CLIENTE LOGA NO SISTEMA PARA COMPRAR ALGO. O DIAGRAMA DE CLASSES DE CONTER CLASSES COMO: CARRINHO DE COMPRAS, CLIENTE E ITEM. O RESULTADO DA LISTA DE "FEATURES" DEVE INCLUIR: CRIAR UM NOVO CARRINHO DE COMPRAS PARA O CLIENTE; ADICIONAR UM NOVO ITEM NO CARRINHO DE COMPRAS; LISTAR TODOS ITENS DO CARRINHO DE COMPRAS;

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM

19/11/2004

Metodologias geis

Pgina 14 de 18

; CALCULAR O PREO TOTAL DOS ITENS DO CARRINHO DE COMRAS. A LISTA DE "FEATURES" DEVE REPRESENTAR ALGO PARA O USURIO, REFLETINDO DIRETAMENTE A FUNCIONALIDADE QUE SER DISPONIBILIZADA NA APLICAO. A LISTA DE "FEATURES" TAMBM DEVE CONTER UNIDADES DE TRABALHO PARA OS DESENVOLVEDORES, ONDE TODA "FEATURE" PEQUENA O SUFICIENTE PARA QUE O SEU DESENVOLVIMENTO SEJA FEITO EM PEQUENAS ITERAES. A IMPLEMENTAO COMEA ATRAVS DO AGRUPAMENTE DE UM CONJUNTO DE "FEATURES" RELACIONADAS EM UM PACOTE DE TRABALHO. UM PACOTE DE TRABALHO DEVE SER COMPLETAMENTE DESENVOLVIDO EM UMA ITERAO, NORMALMENTE DE 1 A 3 SEMANAS. UM PACOTE DE TRABALHO DESENVOLVIDO DEVE APRESENTAR UMA PARTE DO SOFTWARE ONDE O USURIO PODE UTILIZ-LO. CADA ITERAO INCLUI: KICK-OFF MEETING PARA UM PACOTE DE TRABALHO: DETALHES DAS "FEATURES" INCLUDAS DEVEM SER ESCLARECIDOS. PROJETO: CLASSES/MTODOS E DOCUMENTAO NECESSRIAS SO CRIADAS. REVISO DE PROJETO: UM PROJETISTA EXPERIENTE AVALIA O PROJETO FEITO, ANALISANDO-O OU REJEITANDO-O.

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM

19/11/2004

Metodologias geis

Pgina 15 de 18

DESENVOLVIMENTO: IMPLEMTAO E TESTES DE UNIDADE SO CRIADOS. REVISO DE CDIGO: UMA ESPCIE DE PROGRAMAO EM PARES. FECHAMENTO DO RELEASE: AS "FEATURES" DESENVOLVIDAS SO LIBERADAS EM UM BUILD. O FDD POSSUI 5 PRINCIPAIS PROCESSOS:

SCRUM
SCRUM UM PROCESSO PARA CONSTRUIR SOFTWARE INCREMENTALMENTE EM AMBIENTES COMPLEXOS, ONDE OS REQUISITOS NO SO CLAROS OU MUDAM COM MUITA FREQNCIA. O OBJETIVO DO SCRUM FORNECER UM PROCESSO CONVENIENTE PARA PROJETOS E DESENVOLVIMENTO ORIENTADO A OBJETOS. A METODOLOGIA BASEADA EM PRINCPIOS SEMELHANTES AOS DE XP: EQUIPES PEQUENAS, REQUISITOS POUCO ESTVEIS OU DESCONHECIDOS, E ITERAES CURTAS PARA PROMOVER VISIBILIDADE PARA O DESENVOLVIMENTO. SCRUM DIVIDE O DESENVOLVIMENTO EM SPRINTS DE 30 DIAS. EQUIPES PEQUENAS, DE AT 7 PESSOAS, SO FORMADAS POR PROJETISTAS, PROGRAMADORES, ENGENHEIROS E GERENTES DE

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM

19/11/2004

Metodologias geis

Pgina 16 de 18

QUALIDADE.

AS EQUIPES TRABALHAM EM CIMA DE FUNCIONALIDADE (OS REQUISITOS, EM OUTRAS PALAVRAS) DEFINIDAS NO INCIO DE CADA SPRINT. A EQUIPE TODA RESPONSVEL PELO DESENVOLVIMENTO DESTA FUNCIONALIDADE. TODO DIA, FEITA UMA REUNIO DE 15 MINUTOS ONDE O TIME EXPES GERNCIA O QUE SER FEITO NO PRXIMO DIA, E NESTAS REUNIES OS GERENTES PODEM LEVANTAR OS FATORES DE IMPEDIMENTO, E O PROGRESSO GERAL DO DESENVOLVIMENTO. TODOS RESPONDEM S PERGUNTAS: O QUE VOC REALIZOU DESDE A LTIMA REUNIO? QUAIS PROBLEMAS VOC ENFRENTOU? EM QUE VOC TRABALHAR AT A PRXIMA REUNIO?

ALGUMAS CONCLUSES SOBRE XP, FDD E SCRUM

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM

19/11/2004

Metodologias geis

Pgina 17 de 18

AS TRS SO METODOLOGIAS QUE UTILIZAM O MODELO ITERATIVO PARA EVITAR OS PRINCIPAIS "GARGALOS" DO MODELO EM CASCATA; AS TRS SO METODOLOGIAS GEIS, MAS O XP CONSIDERADO MUITO MAIS "LEVE" PORQUE NO PRODUZ MUITOS ARTEFATOS; XP MELHOR PARA PROJETOS QUE POSSUEM MUDANAS FREQUENTES OU "POBRE" LEVANTAMENTO DE REQUISITOS; A ESCALABILIDADE DO FDD MELHOR. EXISTE UMA HIERARQUIA DE PROCESSOS QUE PERMITE ITERAES TANTO COM EQUIPES PEQUENAS QUANTO GRANDES; FDD OFERECE UM MELHOR ACOMPANHAMENTO GERENCIAL DO PROJETO; AS TRS NECESSITAM DE DISCIPLINA, O QUE NO EXCLUI A NECESSIDADE DE UM BOM GERENTE DE PROJETOS; SCRUM FORNECE UM MECANISMO DE INFORMAO DE STATUS QUE ATUALIZADO CONTINUAMENTE; SCRUM E XP SO COMPLEMENTARES POIS SCRUM PROV PRTICAS GEIS DE GERENCIAMENTO ENQUANTO XP EST MAIS PREOCUPADO COM A PRODUO DE CDIGO; AS TRS OFERECEM TCNICAS BASTANTE TEIS E QUE PODEM SER APLICADAS EM OUTRAS METODOLOGIAS.

ALGUMAS OUTRAS METODOLOGIAS GEIS:

CRYSTAL/CLEAR DYNAMIC SYSTEMS DEVELOPMENT METHOD
file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM 19/11/2004

Metodologias geis

Pgina 18 de 18

(DSDM) ADAPTIVE SOFTWARE DEVELOPMENT (ASD)

METODOLOGIAS GEIS - programa prxima anterior

file://C:\Curso_Goiania\Material_Hilmer\UnB\2004.2\agil\agil.HTM

19/11/2004