Aplicacin de Agile EVM para mejora del control y seguimiento de proyectos con metodologa Scrum

Manuel Delgado Lpez

Universidad de Costa Rica manudeloz86@gmail.com

Rodrigo Rodrguez Ramrez

Universidad de Costa Rica rorodr@gmail.com

Introduccin
La empresa Crecimiento Acelerado (nombre ficticio para no afectar la organizacin), es una empresa dedicada al desarrollo de software a la medida para empresas del mercado norteamericano. Esta empresa utiliza una adaptacin de SCRUM para el desarrollo de sus proyectos, los cuales varan en tecnologas, complejidad y tamao. Considerando la gran variedad de proyectos, en la empresa se han realizado proyectos siguiendo diferentes tipos de contrato y con diversas formas de trabajo, siendo lo ms comn utilizar el contrato negociado de forma mixta, en la cual se realiza una estimacin inicial de los requerimientos del proyecto, se le brinda el total estimado al usuario y luego se trata de finalizar el proyecto segn el monto presupuestado. En caso de no lograrse finalizar el proyecto en el costo estimado, ya sea por causas del equipo o por razones externas, el cliente, en la mayora de los casos, pagar un costo adicional al planeado originalmente, esto previamente acordado con el cliente. Sin embargo, en la empresa se desea evitar tanto como se pueda, cobrar de ms al cliente, para ello se ha optimizado el proceso de estimacin, adems de tratar de mejorar el proceso de seguimiento y control de proyectos, sin embargo estos esfuerzos, a pesar de haber dado un aporte a la organizacin, no han sido suficientes para efectuar el cambio esperado por la organizacin. De este modo, considerando que el rea de control de proyectos debe de ser mejorada en la organizacin, el presente artculo expondr la metodologa actual de la empresa y con ello presentar la forma en que el apoyo de la metodologa de Valor Devengado ( Earned Value) pueda ayudar al control y gestin de los proyectos de la empresa.

Para ello primero se presentar una explicacin generalizada del estado actual del proceso de control y seguimiento de la empresa, luego se plantear una explicacin de Agile Earned Value como modelo para medir el avance del desarrollo y por ltimo, presentar la forma en que Valor Devengado podra aplicarse para ayudar a mejorar el control de los proyectos de la empresa.

Estado actual de la empresa

Como anteriormente se seal, la empresa Crecimiento Acelerado cuenta con una diversidad de experiencia en mltiples tecnologas, situacin que ha generado que las distintas reas de especialidad tengan una mayor cantidad de proyectos simultneamente y a la vez, sea requerido un mejor control de los distintos proyectos. Considerando esto, en la empresa se ha establecido un proceso de desarrollo basado en la metodologa SCRUM, con el cual se logra la agilidad y versatilidad deseada en el desarrollo de aplicaciones, considerando como premisa que en el transcurso de la ejecucin del proyecto los requerimientos pueden variar segn las necesidades de los clientes. La metodologa implementada en el proceso de seguimiento de ejecucin del proyecto, inicia con la creacin del listado de historias del backlog, o pila del producto, el cual es creado por el cliente o un representante del mismo, quien es tambin llamado Product Owner. Una vez obtenidos los requerimientos iniciales por medio de estas historias, se contacta un desarrollador Senior en la compaa, el cual colabore a estimar a grandes rasgos los requerimientos solicitados. Por lo general, esta estimacin se basa en experiencias semejantes de proyectos anteriores, y dado que no se tiene todos los detalles de los requerimientos, por lo general esta estimacin se convierte una base inicial de costos para el cliente. Posterior a este proceso, se realizan las negociaciones y la creacin de los bocetos de diseo, los cuales brindan mayor informacin de los requerimientos y permiten una mejor estimacin de los mismos. Para esta etapa del proyecto, la estimacin no la hace un nico experto, sino que se rene el posible equipo de desarrollo y en conjunto realizan una estimacin ms completa utilizando planning poker, un mtodo de estimacin en el que cada miembro del equipo calcula la complejidad de cada historia utilizando un nmero elegido en una baraja
2

(Mountain Goat Software, 2012). Esta ltima estimacin sera la definitiva para el cliente y es en esta etapa que se establece el precio aproximado del proyecto, aadiendo como parte del contrato, que los costos podran variar en el proceso de acuerdo a la metodologa y los cambios que sean solicitados. Llegado a este punto, el proyecto puede iniciar el desarrollo, lo que representa que se realizan iteraciones de duracin idntica (2 o 3 semanas), en cada una de ellas se realiza el sprint planning, el cual permite planear y detallar tanto como sea posible aquellas historias que pueden desarrollarse durante el sprint. Generalmente el sprint planning viene acompaado de una nueva estimacin de las historias seleccionadas, con el fin de determinar la complejidad de los requerimientos acorde con la ltima informacin recibida por parte del Product Owner. Esta estimacin en algunos casos puede diferir a la estimacin inicial, de modo que se documenta el valor original y el nuevo valor y con ello, se logra determinar las diferencias que se encontraron en el proceso. Al llegar el final de cada sprint, el equipo realiza una reunin de retrospectiva, en la que se presentan los clculos de mtricas de velocidad, defectos encontrados por historia y la eficiencia del revisor de calidad en la deteccin de defectos del sprint que recin termin. Con ello, se logra determinar la eficiencia del equipo de desarrollo en la iteracin terminada y a la vez proyectar las metas de velocidad para los sprint siguientes. A partir de estos clculos y el total de horas invertidas durante el ciclo, se realiza el clculo de la cantidad de horas restantes en el presupuesto del proyecto y se determinan las necesidades que tiene el equipo de trabajo para lograr aumentar su velocidad y capacidad para el siguiente sprint. Posteriormente, si se alcanza el punto en el que la cantidad de horas restante en el presupuesto se ve muy baja para la cantidad de trabajo pendiente en el backlog, se realiza un proceso de reestimacin de las historias pendientes, se comunican estos cambios del presupuesto al cliente, explicando los motivos del retraso e incluyendo aquellos cambios que se efectuaron durante el proceso. En el caso que el cliente est dispuesto a cubrir el tiempo adicional, se calendarizan las historias pendientes en los sprints siguientes; por el contrario si el cliente rechaza el cambio de presupuesto, se negocia el alcance nuevo y se dejan las historias pendientes, que no sean crticas, para una nueva etapa del proyecto.
3

Ahora bien, considerando la metodologa anteriormente descrita, se requiere de alguna herramienta que permita facilitar el seguimiento y coordinacin del proyecto, as como determinar el avance y el control de las historias de usuario. Para estas necesidades se utiliza RallyDev. Es una aplicacin web que segn sus creadores, alinea a todos los miembros de un proyecto con ciclos de entregables cortos y eficientes, los cuales conllevan a la innovacin y la satisfaccin de los usuarios (Rally Software, 2012, parra. 1). Segn, Schwaber & Sutherland (2001) y Scrum Alliance (2012), dicha herramienta presenta una serie de caractersticas para llevar el control de un proyecto desarrollado con metodologas giles, entre las cuales se encuentran: el control del product backlog, el seguimiento del sprint backlog y la visualizacin del burn down chart. Considerando estas funciones, se puede sealar que sta herramienta es un buen complemento a la metodologa y as es posible lograr un seguimiento adecuado para cada sprint del proyecto. Para finalizar, considerando la metodologa presentada en esta seccin, se puede afirmar que el proceso actual de seguimiento ha demostrado tener buen desempeo para llevar la visin y control del proyecto a corto plazo, sin embargo, al intentar manejar el presupuesto y el trabajo total restante del proyecto se tienen diversos problemas, pues no existe ningn proceso o accin que facilite estas mtricas desde el inicio del proyecto, sino que se detectan los problemas en etapas tardas, lo que afecta considerablemente el producto final entregado al cliente. Precisamente es por esta razn que el siguiente apartado expone la tcnica de Valor Ganado para metodologas giles, como una posible opcin para mejorar estas debilidades y lograr que la integracin con el proceso no sea tan compleja.

Control de Proyectos con AgileEVM

La metodologa tradicional de valor devengado o Earned Value (EVM) provee informacin relevante sobre el estado del proyecto de manera que los administradores pueden tomar decisiones basados en el rendimiento o las previsiones que se presentan en los diferentes ndices y mtricas. Sin embargo, EVM est orientado a procesos de desarrollo tradicionales, donde los requerimientos, tareas, costos, dedicacin, calendario y dems datos estn bien definidos en una lnea base o baseline desde el principio del proyecto, donde se busca reducir la

cantidad de variaciones dentro del ciclo de vida del mismo. Por otro lado, las metodologas giles, en este caso especfico, el framework de Scrum, son contrarias al desarrollo de software normal en el sentido de que buscan ser flexibles al cambio y por tanto no tienen un baseline propiamente dicho para el proyecto. Por tanto, dada la naturaleza de las metodologas giles se ha creado el mito de que EVM no puede ser aplicado a este tipo de desarrollos. Sin embargo, existe una variacin de EVM que ha tomado fuerza y ha logrado demostrar, incluso matemticamente una relacin entre las mtricas propias de SCRUM y el mtodo de valor devengado (Sulaiman, Barton & Blackburn, 2011). La tcnica se conoce como AgileEVM y por lo general es aplicada segn el contexto de la empresa o el proyecto, pero todos comparten el hecho de que, con los indicadores propios de la metodologa, se puede obtener el valor de EV (valor devengado), AC (costo actual) y PV (valor planeado) y a partir de estos indicadores se derivan las dems frmulas. Aunado a lo anterior, segn lo mencionado en (Sulaiman, Barton & Blackburn, 2011), es necesario medir el proceso a nivel del release en lugar de realizarlo en cada sprint, con sto se va a poder obtener valores ms acertados en la duracin total del proyecto. Sin embargo, al definirse un release como el resultado de uno o ms sprints que tienen el potencial de entregarse al cliente como un producto funcional (Scrum Alliance, 2012, p. 80), se debera de realizar mediciones de velocidad y costo actual en cada uno de los sprints, y con ello lograr llevar un seguimiento continuo y peridico del avance real del proyecto. El objetivo es que para cada release se establezca una lnea base y con esta los indicadores iniciales y con cada sprint se obtengan valores para alimentar los ndices y mtricas de AgileEVM. Rawsthorne (2010), en su artculo Monitoring Scrum Projects with AgileEVM and Earned Business Value (EBV) Metrics, establece algunos valores que pueden ser utilizados como base para adaptar AgileEVM. Uno de ellos es la velocidad de lnea base (BV), que define la cantidad promedio de puntos de historia (StoryPoints) se esperan lograr en cada Sprint. El segundo es la base de costo de cada punto de historia (BC/SP), que representa el costo que se pagar en promedio por cada StoryPoint.

Luego, para cada sprint se establecen 7 indicadores, los cuales son presentados con su definicin en la siguiente tabla: Indicador Descripcin n Nmero del sprint actual, iniciando en 1. Puntos completados en el sprint. TPC AV Total de puntos completados. Velocidad actual luego de n sprints. Costo actual del sprint, por lo general se refiere a horas hombre o costo monetario. TAC AC/SP Costo actual total. Costo actual por punto de historia. Tabla 1: Listado de indicadores. Tomado de Rawsthorne (2010). Luego de que se obtienen estos indicadores ya puede derivarse las frmulas para CPI y SPI normales de EVM. Rawsthorne (2010) propone que el CPI sera: la base de costo de cada punto de historia (BC/SP) dividido por el costo actual por punto de historia (AC/SP), es decir:

Esto tomando como base que el EV es calculado como el total de puntos completados (TPC) multiplicado por la base de costo de cada punto de historia (BC/SP) y que el AC se extrae del costo actual total (TAC). Por otro lado, el clculo del SPI lo define como la velocidad actual (AV) entre la velocidad de lnea base (BV):

En lo anterior, para definir PV, nico indicador faltante, se multiplica el nmero de sprint (n) por la velocidad de lnea base (BV) por la base de costo de cada punto de historia (BC/SP).

Por otro lado, hay mtodos ms sencillos para mostrar el valor devengado y generar datos importantes para el control del proyecto y que no incurran en clculos extensos. Uno de estos es el mtodo simplificado descrito por Rusk (2009) que se basa en la premisa de que el Burn Chart de un proyecto gil es equivalente al valor devengado. Asimismo, este autor, propone que se tracen 3 lneas por cada Burn Chart en donde se define lo siguiente:

La lnea gris muestra el progreso que se espera tener, de manera porcentual, a lo largo del proyecto, inicia en 0 y termina con el 100% al final del proyecto.

La lnea verde, muestra cunto se ha construido del producto hasta el momento como un porcentaje del total.

La lnea roja, muestra el costo incurrido hasta el momento como un porcentaje del total presupuestado.

Idealmente las lneas deben ir una sobre la otra, sin embargo, fcilmente se puede notar que si la lnea roja sobrepasa la verde hay una variacin de costo significativa (CPI menor a 1) o si la lnea verde est muy por debajo de la gris se sabe que hay problemas de tiempo (SPI menor a 1). Este tipo de tcnicas permite abstraer valores como PV, AC y EV y simplificarlo a expresiones como: "El verde est bajo", "Tenemos el rojo muy por encima del verde". Sin importar la tcnica utilizada, se puede notar que el mtodo de Valor Devengado (VD) puede adaptarse a la necesidad del proyecto y proveer los datos numricos para conocer cul es el costo estimado del trabajo completado en el proyecto. Es as como en la siguiente seccin se propone una adaptacin del mtodo de AgileEVM para la empresa "Crecimiento Acelerado".

Implementacin del EV en el proceso de la compaa

La implementacin del proceso de Agile Earned Value implica que la organizacin realice una serie de cambios en su proceso con el fin de lograr un mejoramiento del control de sus proyectos. Sin embargo, a pesar de que se tienen documentados, casos e incluso mtodos para calcular todos los valores requeridos, dicha metodologa no debera de aplicarse fielmente a como lo plantea la teora, por el contrario se debe de adaptar segn las necesidades

particulares de cada organizacin y as lograr satisfacer las necesidades sin sobrecargar el proceso de control. As, considerando la situacin actual de la empresa, lo primero que se debera de efectuar es establecer de una mejor manera el concepto de Release. Esto debido a que en la actualidad no se maneja formalmente el trmino. Como se mencion antes, un release se puede definir como un conjunto de sprints que dan como resultado un producto funcional entregable al cliente (Scrum Alliance, 2012). Con esta definicin se comprende que el release debe ser definido para cada proyecto especfico, de manera tal que se ajuste a la organizacin general que se hace del proyecto y la creacin del backlog original. Lo importante, entonces, es definir la cantidad de sprints que conforman el release y el release backlog, para de esta manera poder definir los valores estimados de puntos que se busca lograr por sprint o velocidad y el presupuesto con que se cuenta para el release. Actualmente, ambos datos ya estn siendo obtenidos, sin embargo se manejan a nivel del sprint, por lo que ser necesario escalarlos al release. Luego, al final de cada sprint, se deberan de efectuar algunos de los clculos ms importantes para la organizacin como lo son: el ndice desempeo en costo (CPI), ndice de desempeo en calendario (SPI), estimado para la completacin (ETC), estimado al completar (EAC). Para ello se podra utilizar clculos previos de la empresa para derivar las frmulas. Con lo anterior, se puede intentar definir las frmulas especficas para la empresa, por ejemplo:

Se toma cada punto del proceso de Planning Poker como un punto de historia y estos, a su vez como referencia de costo promedio. Esto da acceso al dato de costo de lnea base por punto (BC/SP) que propona Rawsthorne (2010), en este caso se le nombrar costo base promedio (CBP)

Basndose en estimados de la empresa y el juicio experto del equipo, se establece una velocidad promedio para cada punto, esto significa, cuantos puntos se esperan realizar por sprint en promedio. Este dato ya se posee o sera fcil de obtener y se representar como el velocidad base promedio (VBP)

Para cada sprint se definen los siguientes indicadores, basados en los propuestos por Rawsthorne (2010):
8

n: Nmero del sprint actual, iniciando en 1. PCn: Puntos completados en el sprint n. TPC: Total de puntos completados, es decir la sumatoria de PCn. VA: Velocidad actual luego de n sprints, definido como TPC/n CAn: Costo actual del sprint, basado en el tipo de costo definido por el CBP, ya sea monetario, esfuerzo u otros.

TCA: Total de costo actual o sea la sumatoria de CAn. CAP: Costo actual por punto de historia, definido como TCA/TPC SP: Cantidad de puntos de historia en el Release Backlog.

A partir de las definiciones anteriores se pueden definir los ndices de la siguiente manera: Mtrica Valor devengado (EV) Frmula EV = TPC(CBP) Explicacin EV sera el total de puntos realizados hasta el momento por su costo promedio asociado. El costo que se esperaba gastar al tiempo dado, esto sera el costo base promedio, luego de n sprints, a una velocidad de VBP. El costo actual en que se ha incurrido, donde para este caso sera la suma de todos los costos luego de n sprints. La cantidad de historias en el release backlog por el costo base promedio de cada punto. Costo base promedio entre el costo total por punto de historia.

Valor planeado PV = nVBP(CBP) (PV)

Costo (AC)

Actual AC = TCA

Costo total BAC = SP(CBP) esperado (BAC)

ndice de CPI = desempeo del CPI = costo (CPI)

ndice de SPI = desempeo del SPI = Calendario (SPI) Costo Total EAC = Estimado al = Completar (EAC)
= = = = = =

Velocidad actual despus de n sprints entre la Velocidad base promedio.

Total de puntos del release * Costo actual por punto

Costo Estimado ETC = = para Completar (ETC) = = =

(Costo por Punto) * (Total Puntos Release - Total de puntos completados)

Tabla 2: Frmulas de Agile EVM aplicadas al proyecto. Adaptado por los autores. A partir de los clculos recin planteados, se realiz la implementacin inicial de los clculos segn las mtricas de un los proyectos de la empresa, informacin presentada en la imagen 1.

10

Imagen 1: Implementacin de las mtricas de Valor Devengado Como se puede notar en dicha imagen, luego de cada sprint se realiza el clculo de las mtricas correspondientes al ciclo, las cuales incluyen el total de puntos completados, la velocidad del sprint (total puntos entre total de horas) y el total de horas gastadas en la iteracin, valores que ya venan siendo calculadas por la organizacin. Luego de esos valores, se agregaron algunas de las mtricas presentadas anteriormente, las cuales permitiran a la organizacin mejorar el seguimiento de costos y el tiempo y a la vez lograr detectar cuanto antes los posibles retrasos existentes en el proyecto.

Conclusiones
El desarrollo de aplicaciones con metodologas giles muchas veces ha sido criticado debido a que, se considera que la escasez de documentacin y la falta de cronograma, provocan que el control de proyectos se convierta en un proceso emprico, el cual ocasione un control inadecuado para proyectos de software. Sin embargo, segn lo expuesto en el presente artculo, existen adaptaciones que se pueden hacer a los procesos de seguimiento y control tradicionales, en este caso Manejo de Proyectos por Valor Devengado (EVM), con el fin de lograr que otras metodologas distintas a las tradicionales tengan un mejor seguimiento del avance del proyecto. Segn lo expuesto, se da a conocer una relacin directa entre el EVM normal y las mtricas que por lo general se manejan dentro de los proyectos giles. Esta relacin deriva en lo que se conoce como AgileEVM, la cual, a pesar de brindar unos lineamientos bastante completos, debe de adaptarse a las necesidades de la empresa, del proyecto y del framework gil aplicada especficamente. Esto le da mucha flexibilidad al mtodo pero tambin lo complica, pues algunos de los clculos deben realizarse especialmente para la organizacin o el proyecto. As tambin, es importante sealar que como parte de la aplicacin del mtodo de valor devengado gil, deben reforzarse muchos trminos y conocimientos en el manejo gil de aplicaciones, como por ejemplo el release, el cual es de suma importancia para definir el contexto de los clculos y, a pesar de que el manejo de proyecto por sprint tiene una gran

11

visibilidad a corto plazo, se debera de manejar el proceso a nivel de release para tener una visin general de los costos y tiempos. Por ltimo, al realizar la implementacin de la metodologa utilizando la informacin de un caso especfico, se pudo mostrar que aplicar esta metodologa no implica un cambio muy grande al proceso existente en aquellas empresas que utilizan la metodologa Scrum, y que ms bien, luego de realizar el cambio se puede llevar el control del proyecto de una mejor manera, sin requerir muchas horas adicionales para la administracin.

Referencias electrnicas
Mountain Goat Software.(2012). Planning Poker work. Accesado el 18 de junio de 2012, en: http://planningpoker.com/ Rally Software. (2012). Deliver the features users love. Faster. Accesado el 20 de junio de 2012, en: http://www.rallydev.com/platform-products/deliver-features-users-love-faster Rawsthorne, D. (2010). Monitoring Scrum Projects with AgileEVM and Earned Business Value (EBV) Metrics. Accesado el 19 de junio de 2012, en:

http://danube.com/system/files/CollabNet_WP_AgileEVM_and_Earned_Business_Valu e_Metrics_032510.pdf Rusk, J. (2009). Earned Value for Agile Development. Accesado el 19 de junio de 2012, en: http://www.agilekiwi.com/EarnedValueForAgileProjects.pdf Schwaber, K., Sutherland, J. (2001). The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game. Accesado el 20 de junio de 2012, en:

http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf Scrum Alliance. (2012). Glossary of Scrum Terms. Accesado el 18 de junio de 2012, en:

12

http://www.scrumalliance.org/articles/39 Sulaiman, T., Barton, B., Blackburn, T. (2011). Earned Value for Agile Development. Accesado el 19 de junio de 2012, en: http://agileadvantage.biz/wp-

content/uploads/2011/11/Sulaiman-Barton-Blackburn-AgileEVM.pdf

13