Metodologies Àgils

1. Metodologies Àgils Nicolás Joel Giacconi Fernández Óscar Simón Castillo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18. Agile UnifiedProcess

19. Agile UnifiedProcess • Les teves coses saben que estànfent • Simplicitat • Agilitat • Enfocamenta altnivell • Independènciad'eines • S'hauràd'adaptarl'AUP a les nostresnecessitats

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

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

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

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

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

25. XP – eXtremeProgramming XP està dividit en els quatre següents apartats: • Histories de l’Usuari • Rols • Processos • Pràctiques

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

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

28. XP – Històries de l’Usuari • Risc • Estimació tècnica • Descripció • Notes i llista de seguiment • Estat • TODO • Comentaris

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

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

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

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

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

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

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

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

37. XP – Pràctiques

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

39. ¿Preguntes?