metodologies gils n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Metodologies Àgils PowerPoint Presentation
Download Presentation
Metodologies Àgils

Loading in 2 Seconds...

play fullscreen
1 / 39

Metodologies Àgils - PowerPoint PPT Presentation


  • 70 Views
  • Uploaded on

Metodologies Àgils. Nicolás Joel Giacconi Fernández Óscar Simón Castillo. Introducció. Per tenir èxit desenvolupant software no es suficient amb notació de modelatge i eines, fa falta una metodologia de desenvolupament.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Metodologies Àgils' - zoltin


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
metodologies gils

Metodologies Àgils

Nicolás Joel Giacconi Fernández

Óscar Simón Castillo

introducci
Introducció
  • Per tenir èxit desenvolupant software no es suficient amb notació de modelatge i eines, fa falta una metodologia de desenvolupament.
  • Per fer-ho s’ha fet molt èmfasi a la rigorosa definició de rols, activitats, modelatge, documentació detallada… Per a un projecte de grans dimensions ha demostrat ser molt efectiu, però per a molts dels actuals projectes que estan en continu canvi no es massa efectiu ja que s’exigeix reduir dràsticament els temps de desenvolupament mantenint la qualitat.
  • Per a aquests tipus de projectes les Metodologies Àgils han demostrat ser una bona solució ja que simplifiquen l’entorn de desenvolupament sense sacrificar la qualitat del producte.
historia
Historia
  • Un dels passos més grans per l’industria del software va ser el model de cascada.
  • Tenir un procés de desenvolupament que ordenés el procés de desenvolupament i que sembles senzill va donar-li gran promoció
  • Però això va portar a un “congelament” del requeriment en les primeres etapes, i els canvis significaven un gran esforç de retreball.
historia1
Historia
  • A mes, la fase d’implementació del model requeria fer-se per mòduls de forma independent amb proves unitàries.
  • Això provocava que a l’hora de la integració vinguessin sorpreses.
  • Això provocava un retràs del projecte sacrificant la qualitat d’aquest.
historia2
Historia
  • Per això van anar sortint nous processos denominats iteratius que proposaven vigilar la impredictibilitat del software per prevenir riscos prematurs.
  • Aquests models van esser l’iteratiu, incremental, en espiral, basat en prototip, SLCD, MBASE, RUP, etc.
historia3
Historia
  • Amb el model en espiral es feia un anàlisis aviat per prevenir riscos.
  • Amb això es feien prototips vàlids que després de ser validats per el client, s’implementaven amb un model en cascada.
  • I aquí és un es torna a errar ja que no donava l’opció de canvis un cop començada la implementació final.
historia4
Historia

En adonar-se’n d’això es va determinar tres fets molt importants per a poder planificar i controlar un projecte tenint en compte les parts implicades:

  • Objectius del cicle de vida
  • Arquitectura del cicle de vida
  • Capacitat de l’operació inicial
historia5
Historia
  • Una de les metodologies que té en comte aquests tres fets és el RUP.
  • El RUP és una de les metodologies més emprades i una de les primeres que es venuda com a producte.
  • Però així com és efectiva per a projecte de gran envergadura, no es tan efectiu en projectes més petits ja que hi ha una cosa que no té en comte: Les Persones.
el manifest gil
El ManifestÀgil

Al març de 2001, 17 crítics de la millora del software son cridats per Kent Beck (pare de l’XP) per definir el que es coneix ara com “Mètodes Àgils”, l’alternativa a les metodologies formals considerades “pesades”.

el manifest gil1
El ManifestÀgil

Al fer-ho, es va crear el Manifest Àgil (fimat perKent Beck, MikeBeedle, Arie van Bennekum, AlistairCockburn, WardCunningham, Martin Fowler, James Grenning, JimHighsmith, AndrewHunt, RonJeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, JeffSutherland y Dave Thomas )en el que s’exposen les 4 següents valors:

el manifest gil2
El ManifestÀgil
  • Valorar més als individus i la seva interacció que els processos i les eines
  • Valorar més el software que funcioni que la documentació exhaustiva
  • Valorar més la col·laboració amb el client que la negociació contractual
  • Valorar més la resposta al canvi que el seguiment d’un pla
el manifest gil3
El ManifestÀgil

Després dels quatre valors descrits, els signants van redactar els següents, com els principis en que aquestses deriven:

  • La nostra principal prioritat és satisfer al client a través del lliurament primerenc i continu de software de valor.
  • Són benvinguts els requisits canviants, fins i tot si arriben tard al desenvolupament. Els processos àgils es dobleguen al canvi com a avantatge competitiu per al client.
  • Lliurar amb freqüència software que funcioni, en períodes d'un parell de setmanes fins a un parell de mesos, amb preferència en els períodes breus.
  • Les persones del negoci i els desenvolupadors han de treballar junts de forma quotidiana a través del projecte.
el manifest gil4
El ManifestÀgil
  • Construcció de projectes entorn d'individus motivats, donant-los l'oportunitat i el recolzament que necessiten i procurant-los confiança perquè realitzin la tasca.
  • La forma més eficient i efectiva de comunicar informació d'anada i tornada dins d'un equip de desenvolupament és mitjançant la conversa cara a cara.
  • El software que funciona és la principal mesura del progrés.
  • Els processos àgils promouen el desenvolupament sostingut. Els patrocinadors, desenvolupadors i usuaris han de mantenir un ritme constant de forma indefinida.
el manifest gil5
El ManifestÀgil
  • L'atenció contínua a l'excel·lència tècnica enalteix l'agilitat.
  • La simplicitat com a art de maximitzar la quantitat de treball que no es fa, és essencial.
  • Les millors arquitectures, requisits i dissenys emergeixen d'equips que s‘autoorganitzen.
  • En intervals regulars, l'equip reflexiona sobre la forma de ser més efectiu i ajusta la seva conducta en conseqüència.
caracter stiques de les metodologies gils
Característiques de les metodologiesàgils
  • Basades en heurístiquesprovinents de la pràctica
  • Preparadespelscanvisdurant el projecte
  • Metodologiaimposadainternament per l’equip de desenvolupament
  • Procéspoccontrolat
  • Contracte flexible
  • Clientpart de l’equip
  • Grup de desenvolupamentpetit
  • Pocsartefactes
  • Pocsrols
  • Poca èmfasi en l’arquitectura de software
per qu utilitzar metodologies gils
¿Per quèutilitzarMetodologiesÀgils?
  • NO la escollirem si:
    • Fases prèviescostoses
    • Dissenyajustat a una documentació
    • Complexitat per entendre el sistema
  • SI la escollirem si:
    • Projectesambcanvis de requisits
    • Entrega contínuad’avanços
    • Importància de la simplicitat
    • Projectesambatenciócontínua
    • Implementació de millores sobre la marxa
agile unified process
Agile UnifiedProcess
  • Basat en la metodologia RUP
  • Dos tipusd'iteracions: desenvolupament i producció
  • 7 Disciplines àgils:
        • Model
        • Implementació
        • Test
        • Desplegament
        • Administració de Configuració
        • Administració de Projecte
        • Entorn
agile unified process2
Agile UnifiedProcess
  • Les teves coses saben que estànfent
  • Simplicitat
  • Agilitat
  • Enfocamenta altnivell
  • Independènciad'eines
  • S'hauràd'adaptarl'AUP a les nostresnecessitats
lean software development
Lean Software Development
  • Eliminar desperdicis
  • Ampliar l'aprenentatge
  • Decidir el méstardpossible
  • Reaccionar el mésràpidpossible
  • Potenciar l'equip
  • Crear la integritat
  • Visió de conjunt
openup
OpenUP
  • Basada en la metodologia RUP
  • Principis:
    • Col·laboració per sincronitzarinteressos i compartir coneixement
    • Equilibrar les prioritats per maximitzar el benefici
    • Centrar-se en l'arquitectura el mésaviatpossible
    • Desenvolupamentevolutiu per obtenir una retroalimentacióconstant i una milloracontínua
xp extreme programming
XP – eXtremeProgramming
  • Primera metodologia àgil i la que dona consciencia del moviment de metodologies àgils.
  • Té un gran grup de seguidors i una gran quantitat de llibres.
  • És pot seguir en un sèrie de llibres nomenats “The XP Series”.
xp extreme programming1
XP – eXtremeProgramming

XP és un metodologia centrada en potenciar les relacions entre persones com a clau per l'èxit del desenvolupament. Es centra en:

  • Promoure el treball en equip
  • Preocupar-se de l'aprenentatge dels desenvolupadors
  • Crear un bon clima de treball
  • Realimentació continua entre client i desenvolupadors
  • Comunicació fluida entre participants
  • Simplicitat de solucions
  • Coratge per enfrontar-se als canvis.
xp extreme programming2
XP – eXtremeProgramming

Està pensada per projectes amb canvis imprecisos i molt canviants amb gran risc tècnic. Aquí podem veure el seu esquema de funcionament (comparativa)

xp extreme programming3
XP – eXtremeProgramming

XP està dividit en els quatre següents apartats:

  • Histories de l’Usuari
  • Rols
  • Processos
  • Pràctiques
xp histories de l usuari
XP – Histories de l’Usuari
  • És la tècnica per especificar els requisits del software.
  • Aquí el client descriu breument les característiques del sistema que vol, siguin requisits funcionals o no funcionals.
  • És dinàmic i flexible.
xp hist ries de l usuari
XP – Històries de l’Usuari

A la fitxa s’ha de poder reconèixer els següents continguts:

  • Data
  • Tipus d’activitat (nova, correcció, millora)
  • Prova funcional
  • Nº d'història
  • Prioritat tècnica del client
  • Referències a altres histories prèvies
xp hist ries de l usuari1
XP – Històries de l’Usuari
  • Risc
  • Estimació tècnica
  • Descripció
  • Notes i llista de seguiment
  • Estat
  • TODO
  • Comentaris
xp hist ries de l usuari2
XP – Històries de l’Usuari
  • Les histories d’Usuari poden ser d’una a tres setmanes (per no superar una iteració).
  • Son descompostes en tasques de programació i assignades als programadors per ser implementades durant l’iteració.
xp rols
XP – Rols
  • Client: Escriu les històries de l’usuari i les proves funcionals per validar. També indica les prioritats.
  • Programador: Escriu les proves unitaris i produeix el codi del sistema
  • Encarregat de proves (Tester): Ajuda al client amb les proves funcionals.
  • Encarregat de seguiment (Tracker): Proporciona la realimentació a l’equip.
  • Entrenador (Coach): Responsable de l’equip.
  • Consultor: Extern a l’equip amb coneixements específics en els temes necessaris del projecte.
  • Gestor (Big Boss): Vincle entre clients i programadors. És el coordinador.
xp processos
XP – Processos

El cicle de desenvolupament consisteix a grans trets, en els següents passos:

  • Client defineix el valor de negoci a implementar.
  • El programador estima l’esforç necessari per a la seva implementació.
  • El client selecciona que construir, d’acord amb les seves prioritats i les restriccions de temps.
  • El programador construeix el valor del negoci.
  • Tornem a començar.
xp processos1
XP – Processos

En totes les iteracions tant client com programador aprenen. Els dos punts més importants de cada iteració son:

  • No pressionar al programador per fer més feina que l’estimada perquè es perdrà qualitat i no es compliran els plaços.
  • El client està obligat a revisar cada entrega del producte perquè aquest obtingui en major valor de negoci en cada iteració.
xp pr ctiques
XP – Pràctiques
  • La principal suposició que es realitza en XP es la possibilitat de disminuir la corba exponencial del cost de canvis durant el projecte i suficient disseny evolutiu per a que funcioni.
  • Això es pot aconseguir amb les tecnologies disponible per ajudar en el desenvolupament de software i a la aplicació disciplinaria de les següents pràctiques:
xp pr ctiques1
XP – Pràctiques
  • El joc de la planificació: Comunicació frequent entre client i programadors.
  • Entregues petites: Produir ràpidament petites versions semi funcionals. Una entrega no hauria de tardar més de 3 mesos.
  • Metàfora: Nom compartits entre client i equip de desenvolupament per a nomenclatura de classes i mètodes del sistema.
xp pr ctiques2
XP – Pràctiques
  • Disseny simple: El disseny ha ser el més simple possible per a poder ser implementat en un moment de terminat del projecte.
  • Proves: La producció de codi està dirigida per les proves unitàries. Les proves son establertes pel client i son executades amb cada modificació del sistema.
  • Refactoring: Reordenar el codi per tal de facilitar posterior modificacions i el seu enteniment.
xp pr ctiques3
XP – Pràctiques
  • Programació en parelles: Els programador han de treballar en parelles.
  • Propietat col·lectiva del codi: Qualsevol programador pot canviar qualsevol part del codi en qualsevol moment.
  • Integració continua: Cada part del sistema s’integra quan està llesta.
conclusions
Conclusions
  • Les metodologiesàgils son perfectes per aplicacionsambrequeriments no moltdefinitso ambiguitats
  • Cal un equip de desenvolupamentperfectamentsincronitzati si pot ser petit
  • Es sacrifica forçala part de documentació
  • S'aposta per tècniques i einesd'altnivell per fertota la fase de disseny