Metodologies gils Nicols Joel Giacconi Fernndez scar Simn

  • Slides: 39
Download presentation
Metodologies Àgils Nicolás Joel Giacconi Fernández Óscar Simón Castillo

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

Introducció O Per tenir èxit desenvolupant software no es suficient amb notació de modelatge

Introducció O Per tenir èxit desenvolupant software no es suficient amb notació de modelatge i eines, fa falta una metodologia de desenvolupament. O 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. O 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. 2

Historia O Un dels passos més grans per l’industria del software va ser el

Historia O Un dels passos més grans per l’industria del software va ser el model de cascada. O Tenir un procés de desenvolupament que ordenés el procés de desenvolupament i que sembles senzill va donar-li gran promoció O Però això va portar a un “congelament” del requeriment en les primeres etapes, i els canvis significaven un gran esforç de retreball. 3

Historia O A mes, la fase d’implementació del model requeria fer-se per mòduls de

Historia O A mes, la fase d’implementació del model requeria fer-se per mòduls de forma independent amb proves unitàries. O Això provocava que a l’hora de la integració vinguessin sorpreses. O Això provocava un retràs del projecte sacrificant la qualitat d’aquest. 4

Historia O Per això van anar sortint nous processos denominats iteratius que proposaven vigilar

Historia O Per això van anar sortint nous processos denominats iteratius que proposaven vigilar la impredictibilitat del software per prevenir riscos prematurs. O Aquests models van esser l’iteratiu, incremental, en espiral, basat en prototip, SLCD, MBASE, RUP, etc. 5

Historia O Amb el model en espiral es feia un anàlisis aviat per prevenir

Historia O Amb el model en espiral es feia un anàlisis aviat per prevenir riscos. O Amb això es feien prototips vàlids que després de ser validats per el client, s’implementaven amb un model en cascada. O I aquí és un es torna a errar ja que no donava l’opció de canvis un cop començada la implementació final. 6

Historia En adonar-se’n d’això es va determinar tres fets molt importants per a poder

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: O Objectius del cicle de vida O Arquitectura del cicle de vida O Capacitat de l’operació inicial 7

Historia O Una de les metodologies que té en comte aquests tres fets és

Historia O Una de les metodologies que té en comte aquests tres fets és el RUP. O El RUP és una de les metodologies més emprades i una de les primeres que es venuda com a producte. O 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. 8

El Manifest Àgil Al març de 2001, 17 crítics de la millora del software

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

El Manifest Àgil Al fer-ho, es va crear el Manifest Àgil (fimat per Kent

El Manifest Àgil Al fer-ho, es va crear el Manifest Àgil (fimat per Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas )en el que s’exposen les 4 següents valors: 10

El Manifest Àgil O Valorar més als individus i la seva interacció que els

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

El Manifest Àgil Després dels quatre valors descrits, els signants van redactar els següents,

El Manifest Àgil Després dels quatre valors descrits, els signants van redactar els següents, com els principis en que aquests es deriven: O La nostra principal prioritat és satisfer al client a través del lliurament primerenc i continu de software de valor. O 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. O 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. O Les persones del negoci i els desenvolupadors han de treballar junts de forma quotidiana a través del projecte. 12

El Manifest Àgil O Construcció de projectes entorn d'individus motivats, donant-los l'oportunitat i el

El Manifest Àgil O 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. O 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. O El software que funciona és la principal mesura del progrés. O Els processos àgils promouen el desenvolupament sostingut. Els patrocinadors, desenvolupadors i usuaris han de mantenir un ritme constant de forma indefinida. 13

El Manifest Àgil O L'atenció contínua a l'excel·lència tècnica enalteix l'agilitat. O La simplicitat

El Manifest Àgil O L'atenció contínua a l'excel·lència tècnica enalteix l'agilitat. O La simplicitat com a art de maximitzar la quantitat de treball que no es fa, és essencial. O Les millors arquitectures, requisits i dissenys emergeixen d'equips que s‘autoorganitzen. O En intervals regulars, l'equip reflexiona sobre la forma de ser més efectiu i ajusta la seva conducta en conseqüència. 14

Característiques de les metodologies àgils O Basades en heurístiques provinents de la pràctica O

Característiques de les metodologies àgils O Basades en heurístiques provinents de la pràctica O Preparades pels canvis durant el projecte O Metodologia imposada internament per l’equip de O O O O desenvolupament Procés poc controlat Contracte flexible Client part de l’equip Grup de desenvolupament petit Pocs artefactes Pocs rols Poca èmfasi en l’arquitectura de software 15

¿Per què utilitzar Metodologies Àgils? O NO la escollirem si: O Fases prèvies costoses

¿Per què utilitzar Metodologies Àgils? O NO la escollirem si: O Fases prèvies costoses O Disseny ajustat a una documentació O Complexitat per entendre el sistema O SI la escollirem si: O Projectes amb canvis de requisits O Entrega contínua d’avanços O Importància de la simplicitat O Projectes amb atenció contínua O Implementació de millores sobre la marxa 16

Agile Unified Process O O O Basat en la metodologia RUP Dos tipus d'iteracions:

Agile Unified Process O O O Basat en la metodologia RUP Dos tipus d'iteracions: desenvolupament i producció 7 Disciplines àgils: O O O O Model Implementació Test Desplegament Administració de Configuració Administració de Projecte Entorn 17

Agile Unified Process 18

Agile Unified Process 18

Agile Unified Process O O O Les teves coses saben que estàn fent Simplicitat

Agile Unified Process O O O Les teves coses saben que estàn fent Simplicitat Agilitat Enfocament a alt nivell Independència d'eines S'haurà d'adaptar l'AUP a les nostres necessitats 19

Lean Software Development O O O O Eliminar desperdicis Ampliar l'aprenentatge Decidir el més

Lean Software Development O O O O Eliminar desperdicis Ampliar l'aprenentatge Decidir el més tard possible Reaccionar el més ràpid possible Potenciar l'equip Crear la integritat Visió de conjunt 20

Open. UP O O Basada en la metodologia RUP Principis: O Col·laboració per sincronitzar

Open. UP O O Basada en la metodologia RUP Principis: O Col·laboració per sincronitzar interessos i compartir coneixement O Equilibrar les prioritats per maximitzar el benefici O Centrar-se en l'arquitectura el més aviat possible O Desenvolupament evolutiu per obtenir una retroalimentació constant i una millora contínua 21

XP – e. Xtreme Programming O Primera metodologia àgil i la que dona consciencia

XP – e. Xtreme Programming O Primera metodologia àgil i la que dona consciencia del moviment de metodologies àgils. O Té un gran grup de seguidors i una gran quantitat de llibres. O És pot seguir en un sèrie de llibres nomenats “The XP Series”. 22

XP – e. Xtreme Programming XP és un metodologia centrada en potenciar les relacions

XP – e. Xtreme Programming XP és un metodologia centrada en potenciar les relacions entre persones com a clau per l'èxit del desenvolupament. Es centra en: O Promoure el treball en equip O Preocupar-se de l'aprenentatge dels desenvolupadors O Crear un bon clima de treball O Realimentació continua entre client i desenvolupadors O Comunicació fluida entre participants O Simplicitat de solucions O Coratge per enfrontar-se als canvis. 23

XP – e. Xtreme Programming Està pensada per projectes amb canvis imprecisos i molt

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

XP – e. Xtreme Programming XP està dividit en els quatre següents apartats: O

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

XP – Histories de l’Usuari O És la tècnica per especificar els requisits del

XP – Histories de l’Usuari O És la tècnica per especificar els requisits del software. O Aquí el client descriu breument les característiques del sistema que vol, siguin requisits funcionals o no funcionals. O És dinàmic i flexible. 26

XP – Històries de l’Usuari A la fitxa s’ha de poder reconèixer els següents

XP – Històries de l’Usuari A la fitxa s’ha de poder reconèixer els següents continguts: O Data O Tipus d’activitat (nova, correcció, millora) O Prova funcional O Nº d'història O Prioritat tècnica del client O Referències a altres histories prèvies 27

XP – Històries de l’Usuari O Risc O Estimació tècnica O Descripció O Notes

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

XP – Històries de l’Usuari O Les histories d’Usuari poden ser d’una a tres

XP – Històries de l’Usuari O Les histories d’Usuari poden ser d’una a tres setmanes (per no superar una iteració). O Son descompostes en tasques de programació i assignades als programadors per ser implementades durant l’iteració. 29

XP – Rols O Client: Escriu les històries de l’usuari i les proves O

XP – Rols O Client: Escriu les històries de l’usuari i les proves O O O 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. 30

XP – Processos El cicle de desenvolupament consisteix a grans trets, en els següents

XP – Processos El cicle de desenvolupament consisteix a grans trets, en els següents passos: O Client defineix el valor de negoci a implementar. O El programador estima l’esforç necessari per a la seva implementació. O El client selecciona que construir, d’acord amb les seves prioritats i les restriccions de temps. O El programador construeix el valor del negoci. O Tornem a començar. 31

XP – Processos En totes les iteracions tant client com programador aprenen. Els dos

XP – Processos En totes les iteracions tant client com programador aprenen. Els dos punts més importants de cada iteració son: O No pressionar al programador per fer més feina que l’estimada perquè es perdrà qualitat i no es compliran els plaços. O El client està obligat a revisar cada entrega del producte perquè aquest obtingui en major valor de negoci en cada iteració. 32

XP – Pràctiques O La principal suposició que es realitza en XP es la

XP – Pràctiques O 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. O 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: 33

XP – Pràctiques O El joc de la planificació: Comunicació frequent entre client i

XP – Pràctiques O El joc de la planificació: Comunicació frequent entre client i programadors. O Entregues petites: Produir ràpidament petites versions semi funcionals. Una entrega no hauria de tardar més de 3 mesos. O Metàfora: Nom compartits entre client i equip de desenvolupament per a nomenclatura de classes i mètodes del sistema. 34

XP – Pràctiques O Disseny simple: El disseny ha ser el més simple possible

XP – Pràctiques O Disseny simple: El disseny ha ser el més simple possible per a poder ser implementat en un moment de terminat del projecte. O 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. O Refactoring: Reordenar el codi per tal de facilitar posterior modificacions i el seu enteniment. 35

XP – Pràctiques O Programació en parelles: Els programador han de treballar en parelles.

XP – Pràctiques O Programació en parelles: Els programador han de treballar en parelles. O Propietat col·lectiva del codi: Qualsevol programador pot canviar qualsevol part del codi en qualsevol moment. O Integració continua: Cada part del sistema s’integra quan està llesta. 36

XP – Pràctiques 37

XP – Pràctiques 37

Conclusions O O Les metodologies àgils son perfectes per aplicacions amb requeriments no molt

Conclusions O O Les metodologies àgils son perfectes per aplicacions amb requeriments no molt definits o ambiguitats Cal un equip de desenvolupament perfectament sincronitzat i si pot ser petit Es sacrifica força la part de documentació S'aposta per tècniques i eines d'alt nivell per fer tota la fase de disseny 38

¿Preguntes? 39

¿Preguntes? 39