Parte Vil Gestion de Proyectos Contenido Objetivos 18.4 Monitoreoy contol de proyectos. Cémo realizar el sequimiento de : proyectos utizando metodologtas ae Sirus por os pares 19.3 Conteido de a gira web de apo... Cémo realzer el soguimionto do 19.4 Referencias proyectos utiizando metodologfas giles Entender ef estado y avance de los proyectos : Qué registros construir y qué reuniones realizar Competencias * Gestionar un proyecto de desarrollo de softwara en base a su previa planifcacién0 19 - Gestidn de proyectos, Monitoreo y Control 19,1 Monitoreo y control de proyectos Cuando el proyecto ya fue acordado se comienza con el desarrollo de las tarsas quo fueron planiicadas, ‘como se describié en el capttulo anterior. A partir de este momento del ciclo de vida debe reaiizarse un seguimiento que consiste en monitorsar cada una de las actividades y controlar su evolucién tomando las facciones que se decidan necesarias, En este capitulo presentamos el seguimiento de los proyectos desde la perspectiva de los dos tipos de metocologias de trabajo [1], [6] que venimos enalzando a lo largo de los. ccapituios anteriores. 19.1.1 Métodologias conducidas por los planes ‘Se planifics que el seguimiento del proyecto se harfa a partir de reuniones de estado a las cuales asistirian los miembros del grupo de desarrollo y reuniones de evance a les cuales asistirien los responsables (gerentes. ¥y lideres) involucrados en el proyecto [1], [2]. La frecuencia da dichas reuniones se datermina en funcién de! vvolumen del proyecto, de la cantidad de personas, de si el proyecto es remoto o localizado, etcétera. 19. 1 Seguimiento del estado El ider de! proyecto facilta y conduce fa realizacién de las diferentes tareas atenciendo diariamente la evolu- cin de los riesgos detectados y analizacos. En general, una vez por semana coordina una reunién del grupo de desarroto donde se analizan diferentes ‘aspectos del proyecto que van desde lo técnico, pasando por cuestiones de relacién con los usuarios y clien- tes, asuntos personeles de los miembros, hasta cualquier otro tema vinculado a la evolucién det proyecto. Esta reuniGn puede demander unas dos o tres horas para un grupo de siete personas. Cuando se tratan los pro- bblemas surgidos es conveniente asignar un responsable dentro del grupo y una fecha estimativa de solucién. Un aspecto importante de todas estas reuniones orientadas al seguimiento es que deben estar encadenadas entre ellas [6]. De nada sive una serie de reuniones aisladas, raz6n por la cual se deben tratar los temes de la reuni6n anterior @ efectos de concluir su cierre antes de tratar los nuevos temas. Cuando en el proximo capitulo mostremos cémo aplica esto al proyecto del caso testigo, utlizaremos un informe documentado orientado a vincular esta seris de reuniones. Entre los problemas tipicos que surgen y deben resolverse se cuentan los listados mas abejo en la tabla 19.1. 19.4.4 -2 Seguimiento del avance De fa misma forma que mencionamos para las reuniones anteriores, la frecuencia de estas depende de las ismas variables, Estas reuniones estén orientadas a monitorear y controler el avance del proyecto con la Participacion de ambas partes. Pera un proyecto mediano, una frecuencia mensual suele ser comdn. A ella, ‘ssisten los responsables del proyecto por ambas partes, los gerentes responsables de amibas partes y miem- bros del grupo de desarrollo a designar dependiendo de los temas que se vayan a tratar. Puede ser el analista, si se trata de acordar cambios a los requerimientos, puede ser elider técnico si se trata de inforar o acordar ‘cuestiones de la tecnologia. Altaomega Ingenieria de Software - Pantaleo - Rinaudo331 En estas reuniones se tomas decisiones, por lo cual los asistentes deben tener poder de decision para alterar la planificacisn original y eventualmente de ser necesario replanificar tareas del proyeoto que pueden afectar los costos. Se analizan ¢ informan los avances, las horas invertidas versus las estimadas, los pagos de acuerdo al ccontrato y la evolucién futura del proyecto. Se revisan los hitos, los entregabies, la calidad de los productos generados a partir de fos resuitados de las ‘pruebas del software y e! iogro de los cbjetivos planteados en la planiicacién. { ‘Tipo de problema et Categoria } Falta de capactacion Recursos Fate de inteestructura Recursos Fels do reourses humanos Recursos Retraso en cronograa Gestion No acuerdo on requrimielos Paterdos No acuerd en tecnologia Averdos No acuerdo en metodtonla Aavardos ' Percda de visgn compartida cen ellen Auerdos Conttopersoal entre ivolucrados Grupo Desarrollo. No acuerdo conta forma de trabalo Grupo Desarrolo Luger isco de trabajo nadcuado Grupo Desarrolio “Ambiente ote nadecuado Grupo Desarrolo Es aconselable hacer coincidir algunas de estas reuniones con las fechas planificadas para hitos del pro- yecto, como [a finalizacion de fases, iteraciones y entregas parciales. 19.1.1.3 Revisi6n de fases Una de las fallas més comunes cuando se trabaja de esta forma es confundir el cronograma de la planifice- cién con la evolucién reat del proyecto. Como se describié en el capitulo 5, Metodologias conducidas por los planes, cada periodo de! ciclo de vida del proyecto tiene objetivos bien daterminados. Por ejemplo, fa ‘Concepcisn tiene como meta achicar los riesgos de! negocio a partir del relevamiento de requerimientos y la Elaboracién, los riesgos esoclados a la tecnologia proponiendo y testeando una arquitectura para ol sistema ‘en construccién. Estas fases no terminan porque lo especifique un cronograma, sino porque se logran estos cobjetivos. Ingenieria de Software - Pantaleo - Rinaudo Alfaomega392 19 - Gestién de proyectos. Monitoreo y Control En estas revisiones se comparan los resultados obtenidos con los esperados para [1]: Los requerimientos implementados. Los tiempos invertidos. Las pruebas de aceptacién, La evolucién de los riesgos. Entre los problemas tipicos que se plantean en estas revisiones suelen aparecer los sigulentes: ‘* _Inestabilidad por indefiniciones en la arquitectura. ‘+ Inestabiidad en los requerimientos por falas en el relevamiento 0 por indefiniciones por parte de los usuarios. ‘+ Alcance subdimensionado detectado al refinar los requerimientos. ‘+ Faita de recursos en la implementacién del proceso de pruebes. ‘+ Mucho reirabajo como conseouencia de cualquiera de las causas anteriores. ‘Como conclusién de la revisién de estas fases [1] debe tenerse en cuenta que: ‘+ Las Fases NO teminan si NO se aloanzan los abjetivos asoclados a los hitos de terminacion, ‘+ Una Fase evitosa (objetives eleanzados) puede significar la cancelacién del proyecto, Ej: una Concepcién puede mostrar que el proyecto es inviable en tas condiciones planteadas. Estas cuestiones son presentadas y analzadas en las reuniones de avance del proyecto con|a participacion {de los miembros del grupo de deserrollo y demés involucracios que sean necesarios para un tratamiento amplio de todos los temas. 19.1.1.4 Revision de iteraciones Si bien estas evaluaciones estan gadas al desempefio del grupo de dasarrollo, son buenas oportunidades para compattiras con les involucracios por parte del cliente en el trabajo diario del proyecto y corregir desajus- tes que de persistir pueden hacer que el proyecto tenga una evolucién no deseada, En estas rovisiones se comperan los resultados cbtenidos con los esperados para (1): Los requerimientos implementados ce acuerdo a sus prioridades. Los tiempos invertides en cada una de las tareas de desarrolio. La cantidad de errores nuevos, fjados y corregidos. La cantidad de camblos solictados, analizados e implementados. La evolucién de los riesgos. Los objetives pianteaclos para la iteracién. Los problemas tipicos que surgen en estas evaluaciones son: No lograr los objetives por falta de claridad en sus planteos, ‘+ Esfuerzo insuficiente en el proceso de pruebas hace crecer los errores no corregidos. Alfaomega Ingenieria de Software - Pantaleo - Rinaudo333 Mala administracisn del tiempo ai no contar con prioridades para cada requerimiento, Criterios poco claros de evaluacién (fata claridad en ta evidencia a generar). Alcance planificado muy grende 0 muy chico. Planeamiento muy detallado 0 de muy alto nivel. Cronogramas muy austados por presiin del negocio. Péidida de foco del grupo de desarrollo por dedicacién a mitioles tareas. ‘Como conclusion de la revision de estas iteracignes [1] debe tenerse en cuenta que: + Una iteracién exitosa siempre implica la continuacién del proyecto o su terminacién segén lo acorda- do, s + Una iteraci6n falida puede implicar la canceldcién o extensién del proyecto. * Cuando se trabaja con iteraciones de duracién fia, estas terminan en la fecha prefiada. 19.1.1.5 Replanificacin Como planteamos en fos capitulos 4 y 5, de Metodologfas, y en el! capttuio 18 de Gestién de proyectos, esta forma de trabajo basa su planificacién en un cantidad de requerimientos a implementar a fo largo de un tiem- 'p0 estimado y por cuyo trabajo se cobraré una cantidad especificada en el presunussto expresaco en la pro- puesta técnico - econémica. Sin embargo, cuando los requerimientos son refinados, durante el ciclo de vide de! proyecto, se obtiene informacién que en general determina que las estimaciones deberén ser gjustades ya ‘que el desarrollo requeriré de un mayor esfuerzo. Esta negociacién es permanente y presenta dos alternativas, ‘que son: cancelar requerimientos para que el desarrollo encaje en el tiempo estimado y presupuesto fijado 0 ‘extender o! tiempo del proyecto acompariado de un crecimiento correspondiente en el presupuesto. xisten otres causas que pueden llevar @ un cambio en la plantficacién, sin embargo esta es la més impor- tante porque implica una discusién de cusstiones cuyas causas son a veces de dificil fundamentacién. Por el ccontrario la demora en la entrega de componentes de infraestructura, la deseroién de miembros del grupo de esarroflo, la implementacién falida de determinadas cuestiones técnicas, la falta de un referente del negocio ‘con suficientes conocimientos y otros son problemas comunes que afectan a-los proyectos pero que son entendidos aunque no siempre aceptados nor las cistintas partes. Pero la ctada anteriormente como mas importante esta ligada a la esencia misma de la forma de trabajo. En a figura 19.1 se presenta en forma esquematica diferentes estrategias de replanificacién de une tarea mm. Por Absorcién: No se altera a planficaciin original y se absorbe la reaiizacién de las tareas retrasadas en €l tiempo asignado a futuras tareas. Une causa posible para a aplcacién de esta estrategia es la pércida de un miembto del grupo de desarrolo por ausencia por enfermedad y su posterior recuperacién con posiblided de ‘trabajo simulténeo con el resto dal grupo. Por Desplazamiento: La realzacién de las tareas atrasadas es asignada a tiempos futuros en la planifi- cacién del proyecto, con lo cual resulta cambiada la planificacién original en una cantidad de tiempo igual a la necesaria para realizar las tareas atrasadas, Una causa posible para la aplicacién de esta otra estrategia de Ingenierfa de Software - Pantaleo - Rinaudo Alfaomegawa 19 - Gestidn de proyectos. Monitoreo y Control replaricacién es el suceso de inconvenientes surgidos en el uso de determinada tecnologia que requir un aprencizaje previo por Gnica vez. Por Afectacién Porcentuat: La planiticacién se ve afectada a fo largo de todo el proyecto en un porcenta- je igual a las tereas atrasadas. Una causa posible pera su aplicacién es la mala estimacién previa del esfuerzo ecesario y / 0 contar con desarrolladores con poca experiencia, ‘od Custom 7 ‘Tiempo N asignado a las tareas1y2 | | pianifcacién orginal y trabajo rea) ‘Trabajo real realizado or] el tiempo N Taroat I Tareat Tarea2 N. 1 \ Replanifcacién por Absorcién SS J % i Tareas \ 1 i 4 Tareat 1 1 } ' Torea2 | T Repianifcacién por 7 Desplazamienio : Taread + j 1 1 y erent Ean Figura 19.1. Esquema que muestra ias posibles formas do replanificacién y cémo resulta afectado ol tiempo total del proyecto Atfaomega Ingenieria de Software - Pantaleo - Rinaudo19.1.2 Metodologias giles Un aspecto clave de las metodologias agiles es la gran visibidad de todos los sucesos en la evolucién de los proyectos. Por esta razén el seguimiento se base fuertemente en realizar en forma discipinada las ectividades ue generen la visibilided neoesaria. Ei otro componente fundamental de una buena gestién son las acciones orientadas a la adeptacién del proyecto a os cambios, Por esta raz6n es importante la realizacion de un ejerccio de planificacién continua que Berita aftontar estos cambios [3], [4]. En adelante asumimos que se trabeja gestionando el proyecto sogtin Scrum. Aesta visibilidad y adaptacién contribuyen tareas inelucibles como la adaptacién ciaria del Sprint Backlog con el estado de avance de las diferentes tareas. La adaptacién dal Product Backlog con los pedidos d= cambio y la realizacién de las reuniones diarias y de revisién de los Sprints donde se tomen las decisiones que cconducen el proyecto. Esto es asi ya que la no adaptacién del Sprint Backog, por ejemplo, quita visiblidad al proyecto, ocutta e! verdadero progreso y deforma la estimacién de la velocidad de desarrollo, ‘Otro aspecto importante del seguimiento de los proyectos es la forma en que se comunican al resto de la empresa los avances y logros del proyecto. Muchas veces es necesario ser cuidadoso, sobre todo cuando las gerencias poseen una visién més tradicional de la gestién de los proyectos de desarrollo. En estas situaciones es imprescindibie a traduccién dat Scrum al formato y al isioma tradicional de la gestion para publcar el pro- yecto de manera adecuada [6). 19.1.2.4 Daily Scrum I seguimiento més cercano comienza con las reuniones informales de! grupo de desarrollo en forma diaria llamades Daly Scrum. Esta es una reunién que busca la comunicacién estrecha y la generacin de un ambiente de contianza dentro del grupo de desarrollo, En estas se comparten dudas y conocimientos; se refuerzan actitudes de colaboracién y se comparten aciertos. Son coordinadas por el Scrum Master y sus caracteristicas salientes son: Frecuencia diaria. Frente al pizartén utiizado para el proyecto. ‘Con una duracién que no exceda los 15 minutos. ~ Con fos miembros del grupo parados. Con horario y puntualided administrados. Cade miembro a's turne deacibe sus acthidads del cla anterior y las programa pata el pr- sente, ‘Cada riembro adapta el estado de las Stories en desarrollo en las cueles estén trabajando, El Scrum Master compila este avance en el Sprint Backlog a efectos de mantenerlo adaptacto. Ingenieria de Software - Pantaleo - Rinaudo Alfaomega336) 19 - Gestion de proyectos. Monitoreo y Control 19.1.2.2 Sprint review meeting Un componente importante de cada Sprint es la validacién de! logro de los objetivos a partir de una demos- ‘raokén al Product Owner. Esta demostracién es una forma objetiva y conoreta de mostrar el logro de los objetivos. Los motives pera inclu dicha demostracién al final de cada Sprint son: Generar conflanza en el grupo @ partir del reconocimiento del Product Owner y el resto de la empresa. Generar un aprencizse an equipo del negocio sobre ol quo 6 est trabajando, Informar a todos los involucracos en el proyecto. Generar un emblentesinlara una entrega aunque nolo sea a efectos de crear compromiso y acitud de los desarroladores, Cbligar a demostrar con hechos la implementacisn de los requerimientos sobre los que se trabej6. Reforzar la confianza en el Product Owner y en los patrocinantes acerca de la factibiidad del proyecto. Estas presentaciones deben constituir un mecanismo de utlidad al proyecto y no un gasto init de esfuer- 0. Por esta razén se recornienda [6}: ‘+ Introducir alos presentes en el proyecto, sobre todo a aquellos que no estén directamente relaciona- dos y familarizados, No gastar esfuerzo extra en demostractones estéticas. ‘Ser eflciente y no invertr en aspectos burocréticos. Centrarse en el valor agregado al negocio y no en cuestiones técnicas. Permit interactuar a los presentes con el producto. 19.1.2.3 Sprint retrospectives Entre los aspectos importantes de estas metocologias se encuentra la promocién de la mejora continua. Con. este fn se realiza al finalizar cada Sprint una reunién en la que se analiza al comportamiento del grupo en dicha Iteracién, Los objetivos de esta autocritica son: * Lograr intalar el aprendizaje en grupo. Generar e! espacio para hacer consultas y reconocer errores. ‘+ Generar un ambiente de andiisis para hablar de les oportunidedes de mejoras. Entre las recomendaciones para la organizacién de estas reuniones se encuentran (6): La duracién no debe exceder un medio aia. Debs asegurarse fa paticipacién de todos los involucracios. Realizarias en un lugar alternativo al de trabajo pera evitar dispersiones. ‘signer a alguien o! rol de anotacor. El Scrum Master en cerécter de Ider dal grupo debe hacer un resumen del Sprint pasado, Cada asistente a su tuno hace el suyo. Analizar las diferencias de velocidad en el desarrollo con respecto a otros Sprints. Uistar las meforas propuestas para a! prdximo Sprint. Alfaomega Ingenieria de Software - Pantaleo - Rinaudo337 19.1.2.4 Informes. ‘A efectos de realizar un seguimianto de la forma en que el Sprint afect6 al proyecto se acostumbra lstar el Froduct Backlog ene nit de fos Sprinisy de esa forma poner en evdenci as Stories implementades en «ellos. De esta manera se informan también ios cambios introducidos. 19.1.2.5 Product Backlog Bun down chats Este informe consiste en un gréfico de dos dimensiones y puede mostrar la evolucién del trabajo penciente en base a los Stories no implementados del Product Backlog o del Sprint. En e! ele vertical del gréfico se repre- -senta la cantidad de esfuerzo pendiente mientras que en el ele horizontal os dies de! proyecto o del Sprint ‘segtin sea el caso. Debido a que con e! transcurso del.tiempo la cantidad de trabajo pendiente debe decrecer a medida que el proyecto avanza, la variacién de la gréfica consistiré en la unin a través de segmentos de recta de los puntos de una serie temporal deoreclente. En la figura 19.2 se muestra en forma esquernética un ejemplo de este informe. 0 aa) ‘Trabajo Pendiente Figura 19.2, Product Backlog Burn down chat para un Sprint de un proyecto Este clagrama es dit! para predecir cundo se completard todo el trabajo ya que a partir de la velocidad ‘de desarrollo de fos titimos Sprints se puede trazar una recta cuya pendiente depende do la velocidad men- clonada y asf en el punto de interseccién con el eje horizontal determiner el tiempo de terminacicn estimedo. En el préximo capitulo apicamos estos conoeptos al desarrollo del sistema del proyecto det caso testigo. 19.2 Conclusion En este capitulo so presentaron dos formas diferentes de enfocar el seguimiento de los proyectos. No se bused hacer una comparacién entre amibos sino mostrar los mecanismos utiizados por las distintas formas de trabajo. Esté claro que cualquiera sea la elegida, el monitoreo y control de los proyectos es de fundamental importancia para su evolucién. Por un lado se trabaja gestionando riesgos a efectos de faolitar el desarrollo del proyecto y negociando la replanificaoién de! proyecto en base a la cancelacién de requerimientos o la extensién del tiempo. Por otro se trabaja generendo fa mayor visibilidad posible y maximizando los requerimientos a implementar ‘en cada una de las iteraciones (Sprints) de tiempo y presupuesto fjo. Ingenieria de Software - Pantaleo - Rinaudo Alfaomega338) 19 - Gestion de proyectos, Monitoreo y Control ® jo de la pagina web de a 19.3.1 Mapa conceptual 19.3.2 Autoevaluaciones 19.3.3 Presentaciones en Power Point (exclusivo para el docente) [1] Managing iterative Software Development Projects, Kurt Bittner, lan Spence, Adcison-Wesley, 2008. [2] The Unified Software Development Process, Jacobson, Ivar, et 4l., Addison-Wesley, 1998, 3] Agile Management for Software Engineering: Applying the Theory of Constraints tor Business Rosuits, David J. Anderson, Ei Schragenheim, Prentice Hall PTR, 2003. [4] SDLC 3.0 ~ Beyond a tacit understanding of Agile, Merk Kenneley, Fourth Medium Press, 2010. [5] Calidad en e! Desarrollo de Software, Guilermo Pantaleo, AfaOmega, 2011. (6) Scrum and XP fram the Trenches - How we do Scrum, Henrik Kniberg, 2007, Free Online Version, ‘Support this work, buy the print copy: http://infoq.com/minbooks/ sorum-xptrom-the-trenches. [7] Software Project Survival Guide, Steve McConnell, Microsoitt Press, 1996, Alfaomega Ingenieria de Software - Pantaleo - Rinaudo