Metodologias Agiles vs 4.0

7/24/2019 Metodologias Agiles vs 4.0

1/29

Facultad : Facultad de Ingeniera Industrial y deSistemas

Escuela : Ingeniera de Sistemas

Curso : Gerencia de Proyectos de Tecnologa de

Informacin Y Comunicaciones

Profesor : Javier Canchano !iguel "ui#one$

Tema : !etodologas %giles

Alumnos : & Chero 'argas Guido Fernando & Cuevas Tito( !ario

& Pinedo )elgado( Fermn *rlando

2015

!etodologas %giles P+gina ,

-niversidad .acional

Federico 'illarrealAo de la Diversicacin Productiva del Fortalecimiento de la

Educacin!


2/29

INDICE

INTRODUCCIN..3

METODOLOGIAS AGILES.4

KAMBAN9

EXTREMA PROGRAMACION XP11

SCRUM..............13

!etodologas %giles P+gina /


3/29

INTRODUCCIN

En los ltimos aos se ha percatado que muchos proyectos pblicos y privados, se hanpuesto en cuestin, producto de los modelos, mtodos, tcnicas tradicionales, queescapaban casi siempre de la realidad operativa; y es hoy donde se pone en manifiestouna nueva tendencia, la denominada el cuerpo de conocimiento de la Gestin de

proyectos !ro"ect #ana$ement%&

'i bien es claro que las metodolo$(as tradicionales en la $estin de proyectos, tuvo susor($enes en el sector industrial, y lue$o fueron e)tendindose a otros *mbitos y condcadas en el sector servicios y tambin en el sector soft+ares;, se ha demostrado

menos eficaces cuando la $estin de un proyecto presenta ya desde su mismaconcepcin- un $rado importante de incertidumbre en su desarrollo que finalmente nopermite una planificacin adecuada y lineal; y ante todos estos fracasos demostradoscon altos costos y fracasos or$ani.acionales un sector fue quien decidi apostar por undenominador diferente y de ries$o y que hoy se est* convirtiendo el perfilor$ani.acional y el de los nuevos profesionales en donde los resultados y el tiempo/portunidad% priman en el )ito o fracaso&

0a hoy tan llamada a$ilidad de proyectos, es el competidor fuerte del )ito o fracaso,aunque no se ten$an muchas e)periencias documentadas y en el mercado se encuentrandistintos modelos y tcnicas, todas ellas a$rupadas en un con"unto de e)periencias y

modelos que resumen solo la practicidad en el enfoque y desarrollo colaborativo&

!etodologas %giles P+gina 0


4/29

,10234alterShe5hart6ro6oneelciclo7Planear7(78acer7(79studiar7y7%ctuar7

,12 3Taiichi*hnoinventaelm;todo9l?ean!anufacturing@!anufacturaes=eltaAesunafuentedeins6iraciny6recursordelmovimiento+gil>

,1B 3-nPa6erde9>%>9dmonds6resentaelconce6tode7Procesode)esarrollodeSoft5are%da6tativo7en,1B>%simismo(tam=i;ndurantelosB2(TomGild6u=licaconce6tosso=relaGestindeProyectos9volutiva@9'*A>

,11/ 3!;todosCrystal(el6untodeiniciodelaevolucindelasmetodologasdedesarrollodesoft5areueeventualmenteresultaronenlouehoyseconocecomoelmovimiento+gil>

,11D 3Scrum:Ideado6or

,111 3)esarrollodeSoft5are%da6tativo:?aideaevolucionohacialasmetodoligiasde)esarrollloFa6idode%6licaciones@F%)A(lametodologia6ro6oneunciclodevidade0fases:79s6eculacion(Cola=oraciony %6rendi$ae7>

,111 3Programacion9Htrema@PA:?ametodologiaes6eciLca=uenas6racticas6arala6laniLcacion(gestion(dise#o(codiLcaciony6rue=as>

/22, 39l!aniLesto%gil:9nglo=ametodologiasuehastaesemomentoseleconociacomo7!etodologiasde)esarrollodeSoft5arede6esoliviano7

METODOLOGAS AGILES

0as metodolo$(as a$iles hace referencia atcnicas que nos permiten optimi.ar la$estin de proyectos, cuyo nacimiento seori$ina con el fin de buscar nuevasalternativas y de"ar atr*s los mtodoscl*sicos, como por e"emplo1 El #odelo de#adure. o 2apability #aturity #odel2##%&

Lne !e T"e#$% Me&%!%'%() A("'e)

!etodologas %giles P+gina


5/29

#anifiesto 3$il1 'ur$e de una reunin que fue convocada por 4ent 5ec6, a travs de lacual 78 cr(ticos buscaron una alternativa de solucin frente a las metodolo$(as formalescomo es el caso de 2##, ya que las consideraban herramientas demasiadocomplicadas y r($idas por su car*cter normativo&

0os cuatro postulados que manifiestan son los si$uientes1

1. *'%+#%) #,) '%) "n!"-"!%) / ) "n&e+00"n 2e '%) $+%0e)%) / ')e++#"en&)

E)isten muchas tareas que requieren talento ynecesitan personas que lo aporten y por endetraba"en con una actitud adecuada&

El 6no+ ho+ o saber cmo hacer los procesos

tiene un valor muy importante es por ello quese le da el mayor prota$onismo a losindividuos, sin de"ar de lado la eficiencia quetienen las herramientas utili.adas&

5. *'%+#%) #,) e' S%6&7+e 2e 6n0"%n 2e ' !%0#en&0"n e8)&"-

'e lo$ra un efectivo y enriquecedor 9eedbac6 cuandose anticipa cmo ser* el funcionamiento del producto

final, observando prototipos previos o partes yaelaboradas&

El manifiesto *$il no da por intil la documentacin, solola documentacin que es innecesario, as( mismo losdocumentos permiten la transferencia de conocimiento,re$istran la informacin histrica y en muchas cuestionesle$ales o normativas son obli$atorios&

0a comunicacin a travs de documentacin no ofrece la

rique.a y $eneracin de valor que lo$ra la comunicacindirecta entre las personas, por eso siempre que sea

posible debe preferirse reducir al m(nimo el uso dedocumentos&

!etodologas %giles P+gina D


6/29

3. *'%+#%) #,) ' 0%'%+0"n 0%n e' 0'"en&e 2e ' ne(%0"0"n0%n&+0&'

0as practicas a$iles est*n destinadas para productos cuyo detalle resulta dif(cilprever al principio del proyecto; y si se

detallara al inicio, el resultado final tendr(amenos valor&

El ob"etivo de un proyecto *$il no es controlarla e"ecucin conforme a procesos ycumplimiento de planes, sino proporcionar elmayor valor posible al producto&

En conclusin es recomendable una relacinde implicacin y colaboracin continua con elcliente; m*s que una contractual de delimitacin de responsabilidades&

4. *'%+#%) #,) ' +e)$e)& ' 0#"% 2e e' )e("#"en&% !e n $'n

0os principales valores de la $estin *$il son la anticipacin y la adaptacin,diferentes a los de la $estin de proyectos ortodo)a1 !lanificacin y control queevite desviaciones del plan&

!etodologas %giles P+gina M


7/29

3 Prioridad satisfacer al cliente mediante la entrega tem6rana

y continua de soft5are de valor,3 %ce6tamos Cue lso reCuisitos cam=ien( incluso en eta6as tardias del

desarrollo> ?os 6rocesos %giles a6rovechan el cam=io 6ara 6ro6orcionarventaGa com6etitiva al cliente

/3 9ntregamos soft5are funcional frecuentemente( entre dos

semanas y dos meses( con 6referencia al 6eriodo de time6o mascorto 6osi=le>

03 ?os res6onsa=els de negocio y los desarrolladores

tra=aGamos Guntos de forma cotidiana durante todo el6royecto>

:3 ?os 6royectos se desarrollan en torno a individuos motivados> 8ay

Cue darles el entorno y el a6oyo Cue necesitan y conLarles laeGecucion del tra=aGo>D3 9l m;todo m+s eLciente y efectivo de comunicar informacin al

eCui6o de desarrollo y entre sus miem=ros es la conversacin caraa cara>

M3 9l soft5are funcionando es la medida 6rinci6al de 6rogresoB3 ?os 6rocesos Ogiles 6romueven el desarrollo sosteni=le> ?os 6romotores(

desarrolladores y usuariosnde=emosser ca6aces de mantener un ritmoconstante de forma indeLnida

3 ?a atencin continua a la eHcelencia t;cnica y al =uen

dise#o meGora la %gilidad13 ?a sim6licidad( o el arte de maHimi$ar la cantidad de tra=aGo

no reali$ado( es esencial,23 ?as meGores arCuitecturas( reCuisitos y dise#os emergen de

eCui6os auto&organi$ados,,3 % intervalos regulares el eCui6o reQeHiona so=re cmo ser m+s

efectivo 6ara a continuacin aGustar y 6erfeccionar sucom6ortamiento en consecuencia

,/

P+"n0"$"%) !e' Mn"6"e)&% :("';


8/29

7& Econmicas1 !ermiten reducir el nmero de actores implicados en un proyecto ysuele contar con tiempos de entre$a bastante a"ustados que un desarrollotradicional, lo cual va a disminuir precios&

:& *pidas1 9ocali.an su estructura a disponer un producto m(nimo viable el cualpuede ser probado por el usuario en el menor tiempo posible, construye toda laempresa en torno a esta premisa& !ermite lan.ar al mercado productos desoft+are a una $ran velocidad

naor$ani.acin sencilla elimina niveles de administracin y control y acerca m*s alcliente final y al equipo de desarrollo&

?& @mplica m*s a todo el equipo1 0os inte$rantes implicados en el proyecto tienenen mayor medida una visin $lobal del proyecto& El )ito de un desarrollo *$ilesta en evitar la encapsulacin de responsabilidades, contrario a lo que sucedecon las metodolo$(as tradicionales&

A& El producto final se a"usta m*s a lo que quiere el cliente1 0a principalproblem*tica del desarrollo tradicional es que se reali.a una captura derequisitos al principio y el cliente no puede comprobar que si$nifica laimplementacin de lo que l ha pedido hasta la entre$a del primer prototipo del

proyecto& 'in embar$o, en muchos mtodos de desarrollo *$il est* contempladoel feedbac6 del cliente como parte estructural del proceso de desarrollo, lo cualva a favorecer el producto final se a"uste a las necesidades del cliente&

!etodologas %giles P+gina


9/29

KANBAN

Es la metodolo$(a *$il para $estin de proyectos creada en Bapn en la empresa Coyota,que si$nifica Car"etas Disuales&

'e utili.a para controlar cmo avan.a el proceso de traba"o en la produccin de unproducto o servicio&

'e basa en la !"-")"n !e' &+?% en $e2e@) &+e) que van representadas en unatar"etas que contienen adem*s de la descripcin del traba"o, el tiempo de duracin de latarea, etc& Gracias a una pi.arra, puede -")'"+)e e' &+?% a reali.ar en todomomento, pudiendo determinar en cada momento qu tareas est*n reali.*ndose y cu*les

hay que reali.ar&

5*sicamente las tareas se establecen tres columnas1 Pen!"en&e) En $+%0e)% Te+#"n!

!rimero, las tareas que est*n por reali.ar van en la columna de pendientes& 2uandoal$uien est haciendo dicha tarea pasar(a a la columna de en proceso y una ve. sehaya acabado esta tarea, la tar"eta pasa a la columna de terminadas&

En caso de que no se haya podido acabar al$una tarea por cualquier motivo, se marcancon una cru. ro"a o se ponen una cuarta columna de impedidas&

!udiendo tener m*s columnas dependiendo de los estados a los que pasan las tareas1

!etodologas %giles P+gina 1


10/29

5*sicamente lo que necesitas para definir una tarea es1

ombre descriptivo& Fescribe precisamente la tarea&

Fescripcin de la tarea&

9echa de entre$a de la tarea&

!ersona asi$nada&

R%ne) $%+ ') 2e )+ Knn

Pe+#"&e -")'"+ e' &+?% !e n )"#$'e -")&%.

dem*s, te permitir* detectar a tiempo ciertos problemas en tu flu"o de traba"o como1saturacin de al$n miembro de tu equipo, tareas cr(ticas, flu"o m*)imo de traba"o que

puedes asumir, conflicto entre tareas,H

Pe+#"&e 6%0'"+&e en ' e?e00"n !e &+e) "n!e$en!"en&e#en&e.

!ermitir* saber mucho me"or qu es lo que se tiene que hacer&

0a definicin de tareas debe ser @ndependientes, ne$ociables, valorables, estimables,verificables testable%&

Pe+#"&e #'&"$'e) -+"0"%ne) / e-%'0"%n+ Knn ') ne0e)"!!e) !e 'e#$+e) % e2"$%.

0a metodolo$(a es clara pero es adaptable a cada equipo o proyecto& !odr*s modificar,quitar o poner casi cualquier cosa si respetas la metodolo$(a&

!etodologas %giles P+gina ,2


11/29

!odr(a que necesitaras m*s columnas para diferencias otros estados de las tareas& /podr(as ser que necesitaras utili.ar los colores no para diferencias proyectos sinosubtareas de una misma tarea, por e"emplo& Codo es v*lido&

P%+2e &e $e+#"&e -e+ (+n!e) -n0e) en e' $+%/e0&%

l final de la semana cuando se ve la evolucin del tablero 4anban, se ver* qu se hahecho e)actamente y que has avan.ado mucho&

EXTREME PROGRAMMING XP

!or sus si$las en in$ls, !ro$ramacin E)trema es una metodolo$(a *$il enfocada aldesarrollo de soft+are creada por 4ent 5ec6 in$eniero de soft+are estadounidense en7III&

Este mtodo trata las relaciones entre las personas como clave para el )ito en eldesarrollo del proyecto, teniendo como base la interaccin continua entre el cliente y elequipo&

9omenta la interaccin permanente entre ambos, que facilita la introduccin de cambiosy minimi.a las posibilidades de error& equiere de la or$ani.acin de los equipos en

pequeas clulas, con un nmero de inte$rantes limitado, no demasiado amplio; por loque no es recomendable para proyectos de lar$a duracin&

Es especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes,y donde e)iste un alto ries$o tcnico&

!/2E'/

!etodologas %giles P+gina ,,


12/29

JKu conse$uimosL

OBETI*OS

D%#"n+ '%) 0#"%)que aparecen en todo proyecto, estableciendo un sistema

de resolucin de los mismos&

Me?%++ ' $+%!0&"-"!! / e' 0%n&+%' !e' &"e#$% requerido para reali.ar elproyecto&

G+n&"+ ' 0'"!! / ' )&")600"n !e' 0'"en&e, hacindolo part(cipe delproceso&

Pe!e !+n%) )%'0"%ne)

etrasos en la produccin1 Ma que las acciones son cortas y continuas&

2ancelacin del proyecto1 'e tiene una constante interaccin con el cliente&

2ostos por los cambios que sur$en en el proyecto

'i el producto no cumple con las necesidades del cliente1 El cliente es parte delequipo y est* presente en la toma de decisiones&

i$ide. frente a los cambios1 0os cambios son tomados como parte natural delproceso&

O&+%) E?e#$'%)

!etodologas %giles P+gina ,/


13/29

Cambin se disponen de metodolo$(as espec(ficas para el desarrollo de soft+are quepretenden ser alternativas a est*ndares como @'/N@E2 7??O=, @'/N@E2 7::O8 y 2##@&!or e"emplo1

Fynamic 'ystems Fevelopment #ethod F'F#%1 #etodolo$(a *$il m*s

veterana y la que m*s se apro)ima a los mtodos tradicionales&

9eature Friven Fevelopment 9FF%1 #etodolo$(a de desarrollo de soft+areorientada a la $eneracin de valor para el cliente&

$ile #odelin$1 #etodolo$(a para el modelado y la $eneracin dedocumentacin que se encuentra alineado con los principios del desarrollo *$il yque puede ser utili.ado como substituto del >#0 est*ndar&

daptative soft+are development 'F%1 eempla.a el ciclo tradicional decatarata, con una serie de procesos de especulacin&

Ciene tres caracter(sticas principales que son1

Especulacin 2olaboracin y prendi.a"e&

2rystal 2lear1 Est* enfocada en la eficiencia de las personas talentos,interacciones, comunicacin% y no tanto de los procesos&

!etodologas %giles P+gina ,0


14/29

METODOLOGAS SCRUM

An&e0e!en&e) ")&+"0%)

0os primeros en introducir el trmino 'crum en desarrollos de nuevos productoscomerciales, fueron Pirota6a Ca6euchi e @6u"iro ona6a en el ao 7IQA& Ellosdescribieron un nuevo enfoque sobre del proceso de desarrollo7& El mismo indicaba quelas distintas fases del proceso de desarrollo pueden solaparse y todo el proceso puedeser llevado a cabo por un solo equipo que est a car$o de las distintas fases del proceso

de desarrollo& En aquella poca esto marcaba una $ran diferencia con el proceso dedesarrollo tradicional, dnde cada fase del proceso era reali.ada por un $rupo distinto de

personas con especialidades diferentes&

partir de esta diferenciacin, Ca6euchi y ona6a lle$aron a las si$uientes analo$(as1

7 El sistema de desarrollo tradicional es an*lo$o a una carrera de relevos&

: El nuevo enfoque propuesto es an*lo$o a un scrum de ru$by&

En el ao 7IIO 4en 'ch+aber emple las tcnicas mencionadas por Ca6euchi y

ona6a en su compa(a& dvanced Fevelopment #ethods& l mismo tiempo Beff'utherland desarroll, en Easel 2orporation, un enfoque similar al propuesto por'ch+aber y fue el primero en darle el nombre 'crum&

9inalmente en el ao 7II? 'ch+aber, con la ayuda de 'utherland, present unpaper formali.ando el proceso 'crum para la industria del soft+are& El mismo fuepresentado en la conferencia //!'0RI? /b"ect-/riented !ro$rammin$, 'ystems,0an$ua$es S pplications%&

En los aos si$uientes, 'ch+aber y 'utherland si$uieron colaborando "untos

para inte$rar sus escritos, e)periencias y pr*cticas su$eridas para terminar de definir loque hoy se conoce como 'crum&

,

!etodologas %giles P+gina ,


15/29

De)0+"$0"n !e S0+#

'e$n sus creadores, 'crum es un proceso *$il que puede utili.arse paraadministrar y controlar desarrollo de soft+are utili.ando pr*cticas que involucraniteraciones con incremento de funcionalidad&

ROLES

En un proyecto scrum, a las personas que participan en el mismo, las podemosdividir en dos $randes $rupos1 !i$s que son todas aquellas personas comprometidascon la reali.acin del proyecto y las pr*cticas de scrum y 2hic6ens que son aquellas

personas que no forman parte del proceso de 'crum pero que son importantes ynecesarias en el proyecto dado que pueden ocupar roles como especialistas del ne$ocio

o de al$una tecnolo$(a particular& Esta divisin tiene su ori$en en un vie"o chiste sobre!i$s S 2hic6ens&

pi$ and a chic6en are +al6in$ do+n a road& Che 2hic6en loo6s at the pi$ and saysTPey, +hy donUt +e open a restaurantLT Che pi$ loo6s bac6 at the chic6en and saysTGood idea, +hat do you +ant to call itLT Che chic6en thin6s about it and says TVhydonUt +e call it UPam and E$$sULT T@ donUt thin6 soT says the pi$, T@Ud be committed butyouUd only be involvedT

!ara la descripcin de scrum, solamente se hablar* sobre los !i$s y los distintos

roles que ellos pueden adquirir& 0os mismos se dividen, se$n sus responsabilidadesdentro del proceso scrum, en tres roles que se detallan a continuacin1

PRODUCT ONER

'e encar$a de crear una versin inicial muy $eneral de los requerimientos,ob"etivos sobre el retorno de la inversin y planes de entre$a& Este rol se encar$a deestablecer prioridades sobre los requerimientos ase$ur*ndose que la funcionalidad m*s

valiosa e importante se produ.ca en tiempo y forma como es debido& En scrum no e)istenin$n criterio para la definicin de los requerimientos; lo importante es que losmismos se encuentren relacionados con el sistemaNaplicacin a desarrollar&

SCRUM MASTER

Es responsable de velar por la correcta implementacin del proceso scrum& Febe

ensear a toda persona involucrada en el proyecto, las tcnicas y procedimientos descrum teniendo en cuenta, que los mismos no deben estar desalineados con las pol(ticas,

!etodologas %giles P+gina ,D


16/29

pr*cticas y cultura de la empresa en la cual se est* llevando a cabo el proyecto&simismo debe ase$urarse que las pr*cticas y procedimientos reali.ados produ.can los

beneficios esperados&

!ara cumplir con todas estas e)i$encias, el 'crum #aster deber* estar al tanto de

los avances y del d(a a d(a de las actividades de los miembros del Ceam&

El 'crum #aster debe actuar como intermediario entre el !roduct /+ner y elCeam, por lo tanto no se recomienda que la persona que ocupe este puesto posea,adem*s del rol de 'crum #aster, otro rol dentro del mismo proyecto& Es decir, no esaconse"able que una misma persona sea 'crum #aster y analista funcionalNarquitecto desistemas en el mismo proyecto&

TEAM

Es un $rupo de personas encar$adas de desarrollar e implementar lafuncionalidad pactada& El equipo se auto administra y auto or$ani.a& 0as personas quelo componen, deben utili.ar su in$enio para incrementar la funcionalidad cumpliendocon los requerimientos a lo lar$o de cada iteracin& 0os miembros del equipo sonresponsables del )ito de cada sprint&

0a auto administracin y auto or$ani.acin es un aspecto crucial en 'crum& Es

indispensable que todos los miembros del Ceam estn comprometidos con su traba"o ypara ello es necesario contar con la motivacin de los mismos& En un Ceam que se autoor$ani.a y auto administra, no hay una persona encar$ada de controlar que todos losmiembros estn cumpliendo sus tareas en tiempo y forma& 'ino que cada uno de losinte$rantes es responsable de reali.ar sus tareas y adem*s debe ase$urarse que el restode los miembros ha$an lo propio con sus tareas respectivas& El Ceam debe traba"ar encon"unto como un bloque& 'us resultados son producto del traba"o colectivo y no deesfuer.os individuales&

@dealmente, se recomienda que el Ceam est formado por no m*s de sietepersonas& medida que el Ceam aumenta en cantidad de personas, aumenta laposibilidad que el Ceam no funcione como tal, dado que habr* miembros que perder*nla motivacin y el compromiso necesario para el correcto funcionamiento del Ceam&

En al$unas situaciones, cuando se cuente con un Ceam formado por m*s de die.personas, es recomendable dividir este equipo en distintos sub equipos& 0a subdivisinpuede hacerse se$n las responsabilidades un equipo de desarrolladores, un equipo deqa, un equipo de analistas funcionales% o se$n las necesidades del ne$ocio en sub

equipos que incluyan todos los roles& 2uando se armen sub equipos formados solamentepor desarrolladores, qa o analistas funcionales, es necesario encontrar una forma para

!etodologas %giles P+gina ,M


17/29

hacer interactuar a los distintos sub equipos& !ara ello puede reali.arse, semanalmente,una reunin de 'crum con un representante de cada sube quipo& Fe esta forma losequipos estar*n al tanto de las actividades de los otros equipos&

0a composicin del Ceam es al$o que no puede ser absoluta, dado que cadaproyecto de soft+are tiene sus propias caracter(sticas& Es decir al$unos proyectosnecesitar*n mayor presencia de personas para ocupar ciertos roles que otros& !ore"emplo, en un proyecto relacionado a data #in$, es necesario contar con al$n e)pertoen dicha tecnolo$(a y un administrador de bases de datos, pero en un proyectoempresarial estos roles pueden no ser necesarios& E)iste la posibilidad que el ob"etivo deun sprint sea Encontrar la mayor cantidad de fallas en el sistema, con lo cual en esecaso, el Ceam puede estar formado solamente por personal de testin$& Cambin puedeser factible, que el ob"etivo de un sprint sea !resentar el diseo de la refactori.acinnecesaria para utili.ar una nueva librer(a de un tercero, por lo tanto en ese caso, es muy

probable que el Ceam est formado por un $rupo de arquitectos, diseadores ydesarrolladores sin contar con analistas funcionales ni personal de testin$&

'in embar$o, para proyectos involucrados en aplicaciones empresariales, unequipo podr(a estar compuesto de la si$uiente manera1 un analista funcional, undiseador, tres desarrolladores y dos quality assurance&

El rol de analista funcional se encar$a de definir los requerimientos del ne$ocio&Es importante que sepa diferenciar entre requerimientos funcionales y no funcionales&

0a persona que ocupe el puesto de diseador deber* establecer los distintoscomponentes y sus colaboraciones que el sistema debe poseer&

!or su parte losNlas desarrolladores se encar$an de desarrollar el soft+are queformar* el sistema o producto& 'i$uiendo las buenas pr*cticas deben reali.ar pruebas deunidad para $aranti.ar el correcto uso de los componentes que desarrollan&

0as personas que ocupan el puesto de quality assurance deben ase$urar lacalidad del producto o sistema& Est*n encar$adas de verificar y validar la funcionalidaddel producto, ya sea mediante testin$ manual o automati.ado&

unque cmo se mencion anteriormente, no e)iste un absoluto para lacomposicin del Ceam, cada proyecto demandar* un Ceam concreto que sea capa. deresponder a sus necesidades&

!etodologas %giles P+gina ,B


18/29

CICLO DE *IDA

El ciclo de vida de 'crum puede verse en la si$uiente ima$en obtenida de+++&controlchaos&com sitio creado y mantenido por el creador de scrum 4en'ch+aber%&

Codo proyecto se divide en una o m*s iteraciones denominadas sprints queconsisten de un con"unto de actividades de desarrollo llevadas a cabo a lo lar$o de un

per(odo de tiempo preestablecido& Es aconse"able que cada sprint, posea una duracin de


19/29

2ada sprint tiene como ob"etivo brindar un incremento de funcionalidad& continuacindefino los pasos que deben cumplirse en cada sprint&

7& !laneamiento del sprint&:& @mplementacin del sprint&


20/29

Ceam; es decir sus su$erencias de arquitectura no deben ser impuestas a los inte$rantesdel Ceam&

I#$'e#en&0"n !e' )$+"n&

En esta etapa, los miembros del equipo se encar$aran de proveer un incremento

de funcionalidad del producto o sistema, tomando como entrada, aquellosrequerimientos provenientes del !roduct 5ac6lo$ con los cuales han asumido elcompromiso de implementarlos en la reunin de planeamiento del sprint& !ara ello ser*necesario uno o m*s equipos reali.ando las si$uientes tareas1

Fesarrollo Feployment de una versin con sus elease notes& evisiones "ustes

!ara la reali.acin de las mismas deben tenerse en cuenta las si$uientesconsideraciones1

>na ve. comen.ado el sprint, est* prohibido reali.ar cualquier tipo de cambio al!roduct 5ac6lo$&

0os miembros del Ceam pueden buscar informacin, o solicitar soporte y ayuda;pero nin$una persona puede ni debe interferir con el traba"o del Ceam&

l$unas formas de interferir con el traba"o del Ceam, son1 solicitarle uno o m*s de losmiembros del Ceam la reali.acin de tareas no contempladas en el 'print 5ac6lo$, darinstrucciones sobre cmo reali.ar su traba"o, o reunir al equipo para indicarle qu se

pretende de l&

unque esto no es deseado y deber(a evitarse con un correcto planeamiento, si elsprint no es viable, ya sea por una tecnolo$(a incompatible, por cambios en el ne$ocioque har(an que la funcionalidad del sprint no produ.ca valor al$uno o porque una

persona e)terior al Ceam interfiere con su traba"o, el 'crum#aster es el nico quecuenta con la autoridad necesaria para dar por finali.ado el sprint& 'i bien el

'crum#aster es la nica persona que puede reali.ar este cambio, puede hacerlo se$nsu propio criterio o se$n la recomendacin de al$n miembro del equipo o del !roduct/+ner&

'in embar$o, en al$unas ocasiones e)iste la posibilidad que el Ceam no puedacompletar todo el 'print 5ac6lo$ asumido en la reunin de 'print !lannin$& 'i estoocurre el Ceam puede consultar al !roduct /+ner si e)iste la posibilidad de removeral$unos (tems y rele$arlos para el sprint futuro& En el caso que la cantidad de (tems aremover sea muy elevada el 'print habr* perdido su si$nificado, y el 'crum#aster

puede terminar el sprint se$n se ha mencionado anteriormente&

En el caso opuesto, en el que el Ceam haya cumplido con toda la funcionalidadpactada en una fecha anterior a la finali.acin del 'print, el mismo puede darse por

!etodologas %giles P+gina /2


21/29

terminado o puede consultarse con el !roduct /+ner si es conveniente a$re$ar al sprintal$n (tem del !roduct 5ac6lo$&

lo lar$o de todo el sprint, adem*s de sus tareas correspondientes an*lisis,diseo, desarrollo, testin$% los miembros del Ceam cuentan con dos tareasadministrativas& >na de ellas es asistir a las reuniones diarias de scrum scrum dailymeetin$s o stand up meetin$% y mantener actuali.ado el 'print 5ac6lo$&

0as reuniones de stand up o daily scrum deben llevarse a cabo, como sudenominacin lo indica, diariamente& ella asisten el !roduct /+ner, el 'crum#aster yel Ceam& l ser reuniones diarias, las mismas no deben durar m*s de 7? minutos& Endicha reunin cada inte$rante debe responder las si$uientes pre$untas1

JKu he estado haciendo desde la ltima stand up meetin$ hasta ahoraL

JKu planeo hacer desde ahora hasta la pr)ima stand up meetin$L

JE)iste al$una complicacin o impedimento que no me permita reali.ar loscompromisos asumidos para este sprintL

Estas reuniones tienen como propsito sincroni.ar el traba"o de todas las personascomprometidas con el proceso de scrum& simismo, brindar una herramienta para lo$rarmayor cohesin y compromiso en los miembros del equipo permitiendo su interaccin ycooperacin entre s(&

Re-")"n !e' )$+"n&

2onsiste de una reunin en la cual se presenta al !roduct /+ner y a lossta6eholders el incremento de funcionalidad que ha sido implementado a lo lar$o dedicha iteracin& 0a reunin comien.a con un miembro del Ceam presentando el ob"etivodel sprint, el !roduct 5ac6lo$ comprometido y el !roduct 5ac6lo$ implementado&

0a funcionalidad debe presentarse en las estaciones de traba"o de los miembrosdel Ceam simulando un ambiente muy cercano al ambiente de produccin& Fe nin$unamanera puede presentarse un prototipo o una presentacin con diapositivas&

lo lar$o de la presentacin, los sta6eholders y el !roduct /+ner puedenreali.ar las pre$untas que consideren necesarias& 0as mismas deber(an referirse a la

presentacin o a los cambios de funcionales productos del incremento de funcionalidadprovisto mediante la implementacin del sprint& simismo, tambin deben mencionartoda nueva funcionalidad que se les ocurra mientras est*n viendo la presentacin& Estanueva funcionalidad debe a$re$arse al !roduct 5ac6lo$&

l finali.ar la presentacin, es importante que los destinatarios de la mismaprovean feedbac6 a los miembros del equipo, dado que ello puede servir como un

!etodologas %giles P+gina /,


22/29

primer paso para la definicin de (tems potenciales del !roduct 5ac6lo$ del pr)imosprint&

Canto el !roduct /+ner como los sta6eholders destinatarios de la presentacinpueden identificar funcionalidad que no haya sido implementada o que no haya sidoimplementada de la manera esperada& 'i esto ocurriese, dicha funcionalidad debeincluirse nuevamente en el !roduct 5ac6lo$ para que sea implementada en el pr)imosprint& Es responsabilidad del !roduct /+ner, la asi$nacin de la prioridadcorrespondiente&

Este tipo de reuniones no deber(a durar m*s de cuatro horas, aunque la duracinde la misma va a estar condicionada por la duracin del sprint y el incremento defuncionalidad implementada en el mismo&

Dale la pena destacar, que no debe perderse tiempo en presentar la funcionalidadque se encuentre a medio implementar& Es decir si no se han completado todas las tareasnecesarias para brindar la funcionalidad correspondiente a un (tem del !roduct 5ac6lo$

pero se ha lle$ado a implementar parte de esa funcionalidad, la misma no debe serpresentada&

Fado que uno de los lemas de las tecnolo$(as *$iles es utili.ar la mayor cantidadde tiempo en hacer y no planear lo que hay hacer se aconse"a que el Ceam nodedique demasiado tiempo a la preparacin de dicha presentacin& >na hora deber(a serm*s que suficiente&

!or ltimo, el 'crum#aster es el encar$ado de a$endar y pro$ramar esta reunininvitando a los participantes correspondientes&

!etodologas %giles P+gina //


23/29

A"TEFACT#$ DE $C"%&

P+%!0& B0'%(

0os requerimientos a desarrollar se encuentran definidos en el !roduct 5ac6lo$& El

mismo consiste de una planilla que representa los requerimientos iniciales del proyecto&0os requerimientos que inte$ran esta lista no poseen $ran detalle, pero si son losuficientemente claros para servir como punto de partida para que el Ceam pueda sercapa. de des$losarlos en tareas a reali.ar& Es muy importante remarcar que losrequerimientos deben estar ordenados se$n su prioridad, los primero (tems de la listason lo que poseen mayor prioridad&

El !roduct 5ac6lo$ evoluciona constantemente se$n las necesidades del ne$ocio&'in embar$o, debe tenerse en cuenta que todo cambio al mismo debe estar

documentado& continuacin se presentan al$unos e"emplos de !roduct 5ac6lo$&

E"emplo 71

4en 'ch+aber propone la si$uiente planilla para utili.ar como !roduct 5ac6lo$&

En dicha planilla, los (tems est*n separados por los 'prints en los cuales fueron

reali.adas& Es decir todas las filas que se encuentran arriba de 'print-7 corresponden arequerimientos que fueron reali.ados en el 'print-7& 0os (tems que se encuentran por

!etodologas %giles P+gina /0


24/29

deba"o de la fila con t(tulo 'print-7 y por encima de la fila con t(tulo 'print-:corresponden a requerimientos que fueron reali.ados en el 'print-: y as( sucesivamente&

0as primeras cuatro columnas se refieren a1 una descripcin del (tem, un tiempoestimado inicial, un factor de a"uste y un tiempo estimado a"ustado& 0as columnassi$uientes representan los 'prints en los cuales el !roduct 5ac6lo$ es desarrollado&2uando un (tem es identificado e in$resado en el !roduct 5ac6lo$, el tiempo estimado

para implementarlo se a$re$a en la columna correspondiente al 'print actual& Cal cualpuede apreciarse en el e"emplo anterior todos los (tems, salvo !ublish 9acility 9orEntire !ro"ect, !ublishin$ @t s PC#0 Veb !a$es que fue identificado en el 'print-


25/29

B+n!%7n C+&

>n $r*fico de burndo+n indica la cantidad de traba"o pendiente a lo lar$o deltiempo& !ara la cantidad de traba"o pendiente suele utili.arse d(as como unidad,mientras que para el tiempo suelen utili.arse los 'prints como unidad&

El mismo sirve como una forma de visuali.ar la correlacin entre la cantidad detraba"o requerida y el pro$reso del Ceam reduciendo dicha cantidad& Este $r*fico no

slo representa el traba"o reali.ado, sino la velocidad con la cual se reali.a elmismo&

continuacin se presenta el $r*fico de burndo+n correspondiente al E"emplo 7del apartado !roduct 5ac6lo$&

!etodologas %giles P+gina /D


26/29

S$+"n& B0'%(

El 'print 5ac6lo$ es una lista de tareas que el Ceam se ha comprometido a reali.ar alo lar$o del 'print& epresenta el traba"o necesario para implementar los requerimientosdel !roduct 5ac6lo$ correspondientes al corriente 'print& Esta lista de tareas es

confeccionada en la se$unda etapa de la reunin de planeamiento del 'print y la mismaes actuali.ada d(a a d(a por los miembros del Ceam a lo lar$o de todo el 'print&

0as tareas deben ser definidas de forma tal que todos los miembros del Ceamentiendan de qu se tratan y 'crum su$iere que cada tarea posea una duracin de = a 7Ahoras; es decir no m*s de dos d(as& 0as tareas que requieran m*s de 7A horas sonconsideradas como tareas que todav(a no han sido des$losadas lo suficientemente paraque todos los miembros del Ceam entiendan de qu se tratan& 'in embar$o esto es unasu$erencia y no debe tomarse como un absoluto&

continuacin se presenta un e"emplo de 'print 5ac6lo$& 0as filas representan lastareas, quin fue la persona que la propuso, la persona a car$o de reali.arla, el estado dela misma y la cantidad de traba"o pendiente para desarrollarla&

E"emplo 71

!etodologas %giles P+gina /M


27/29

0a primera columna representa una descripcin de la tarea& 0a se$unda y tercera

columna representan la persona que propuso la tarea y la persona que est* a car$o de lareali.acin de la misma respectivamente& 0a cuarta columna se refiere al estado de latarea& Esta columna solamente puede tomar los si$uientes valores1 'in 2omen.ar, En

pro$reso o 2ompleta& 0as columnas subsi$uientes representan los d(as del 'print& Encada uno de ellos, debe indicarse la cantidad de traba"o pendiente para completar cadauna de las tareas& Es decir si una tarea requiere A horas y la misma permanece en elestado 'in 2omen.ar hasta el d(a


28/29

E"emplo :1

D/)

D&eL%((e! De)0+"$&"%n 1 5 3 4 F H 9 1J

7-9eb-7? >@ /b"ect #odel : 7 O O

7-9eb-7? >@ 9rame+or6 < 7 7 : O O ? : 7 O

7-9eb-7? 0earn 'trutsNCiles pi < < O

:-9eb-7?

'etup developer

environment = O O:-9eb-7? 'etup testin$ environment ? < O O

:-9eb-7? Fesi$n Fb #odel 8 : O O


29/29

BIBLIOGRAA

$ilelliance +ebsite http1NN+++&a$ilealliance&or$

@5# 'taff& ational 'oft+are Vhite !aper& ational >nified !rocess 5est !racticesfor 'oft+are Fevelopment Ceams& ev& 77NO7

4rebs, Boe& >! in the Fialo$ue +ith 'crum& :OO?&

http1NN+++-7:Q&ibm&comNdeveloper+or6sNrationalNlibraryNfebO?N6rebsNW7O7A:

4ruchten, !hilippe& Che ational >nified !rocess1 n @ntroduction,

Metodologias Agiles vs 4.0

Documents

Transcript of Metodologias Agiles vs 4.0