Planificación ágil en la vida real

Consejo inicial para el desarrollo de versiones con planificación ágil

¿Forma parte de un equipo que desea implementar una planificación ágil? ¿Está usando el desarrollo iterativo y continúa atascado haciendo "inundaciones de iteración"? En este artículo, el autor utiliza su experiencia para ayudar y capacitar a los equipos del producto de IBM para que se familiaricen con un plan de acción que responde a la siguiente pregunta: "¿Cómo comienzo a desarrollar versiones con planificación ágil?" Además, Steffan desarrolla todos los fundamentos de la planificación ágil y comparte sus conocimientos sobre qué funciona y qué no. Nota del editor: Se actualizaron las figuras 1 y 4 y se agregaron otras correcciones a pedido del autor.

Steffan Surdek, User Experience Lead, IBM

Steffan Surdek es Líder de Experiencia del Usuario y se autoproclamó Campeón Ágil para el equipo de WebSphere® Business Services Fabric. Steffan usa su experiencia para permitir que los Talleres Ágiles Grupales de Software de dos días de duración ayuden a su equipo a trabajar en la forma de mejorar sus procesos ágiles.



21-05-2009 (Primera publicación 31-03-2009)

"Somos ágiles y realizamos iteraciones". Los equipos que dicen utilizar el desarrollo ágil suelen afirmar esto con frecuencia. Pero muchos otros factores, además de realizar sus desarrollos por medio de iteraciones, son necesarios para ser realmente ágil.

Tradicionalmente, los equipos de desarrollo tienen versiones específicas con contenidos predeterminados y fechas predeterminadas. Al comienzo de cada versión, el equipo de gestión se reúne con el equipo de desarrollo para cumplir con el ritual de imponer los contenidos que desean que se incluyan y fijar la fecha de lanzamiento.

El desafío en este escenario consiste en que la gerencia está tratando de establecer tanto la fecha de lanzamiento como los contenidos que se deben incluir, mientras que el equipo de desarrollo cree que sólo pueden lograr uno de estos dos objetivos. En realidad, los contenidos pueden llegar a ser más flexibles que lo que el equipo de desarrollo cree. Desafortunadamente, los equipos de desarrollo no siempre se dan cuenta de esto y la gente comienza a trabajar excesivamente para lograr los objetivos.

Resumen de un desarrollo ágil de software

El desarrollo ágil de software es un grupo de metodologías de desarrollo de software que se basan en principios similares. Generalmente, estas metodologías promueven un proceso de gestión de proyecto que alienta la inspección y la adaptación frecuente, mejores prácticas de ingeniería que facilitan la entrega rápida de software de alta calidad y una filosofía de liderazgo / negocios que abarca el trabajo en equipo, la auto organización, la responsabilidad y el desarrollo alineado con las necesidades del cliente y los objetivos de la compañía.

Los siguientes enfoques modernos de análisis y gestión de operaciones comparten fundamentos conceptuales similares:

  • Fabricación / Producción ajustada: Una práctica de producción que considera un desperdicio la utilización de todo recurso que no cree valor para el consumidor final.
  • Metodología de sistemas leves: Un enfoque apropiado para el análisis de situaciones complejas con puntos de vista divergentes sobre la definición del problema (es decir, problemas "leves" como en el caso de "¿Cómo gestionar los desastres?").
  • Six Sigma: Un enfoque que busca identificar y eliminar las causas de los defectos y los errores en los procesos utilizando un conjunto de métodos de gestión de calidad y creando una infraestructura especial de personas (expertos en estos métodos) dentro de la organización ("Cinturones Negros", etc.).

Este artículo sirve a modo de plan de acción para ayudarlo a superar esta dificultad y hacer que su equipo pase de realizar un desarrollo iterativo plano a realizar un desarrollo ágil. El plan de acción incluye lo siguiente:

  • Sugerencias para ayudar a su equipo con la transición hacia la planificación ágil.
  • Guía sobre las iteraciones. ¿Cómo deberían ser? ¿El equipo sólo debería trabajar en las iteraciones durante una versión en particular? ¿Qué debería hacer el equipo entre versión y versión?
  • Consejos para crear historias de usuario y comprender la función del propietario del producto. ¿Qué son las historias de usuario? ¿Quién las debería redactar? ¿Cuál es la diferencia que existe entre una epopeya y una historia? ¿Cuál debería ser la longitud del trabajo incluido en la historia? ¿Quién es el propietario del producto en el proceso?
  • Consejos sobre cómo planificar y gestionar los registros a nivel del producto, la versión y la iteración. Cada nivel de planificación tiene su propio registro. ¿Qué deberían incluir estos registros diferentes? ¿Qué nivel de estimación se requiere para cada nivel de planificación?
  • Técnicas para medir e interpretar la velocidad del equipo. ¿Qué clase de información se puede extrapolar a partir de la velocidad del equipo?

Facilitar la transición

A continuación, se presentan algunos factores que se deben tener en cuenta antes de dar comienzo a la transición:

  • Comprender qué es lo que se quiere lograr con el proceso. A algunas personas les resulta muy difícil cambiar y, por lo tanto, usted debe entender en qué lugares desea hacer que las personas se comprometan al comienzo del proceso para así poder obtener los resultados deseados. Recuerde que siempre podrá pedir más una vez que haya demostrado que está obteniendo los resultados deseados. Exprese que lo que desea agregar es simplemente el próximo paso en la evolución del proceso.
  • No dé comienzo a la transición de manera repentina. Si obliga al equipo a transitar el proceso sin que éste haya recibido la capacitación necesaria, existe la posibilidad de que se cree un gran resentimiento y una falta de confianza generalizada en relación al nuevo proceso.
  • Comprenda que la educación es su amiga. Aprenda todo lo que necesita aprender y siéntase cómodo con ello. Trate de utilizar métodos ágiles en un proyecto pequeño en primer lugar para así solucionar algunos de los típicos problemas. Cuando haya aprendido todo lo necesario, eduque al resto de su equipo. Asegúrese de que todos utilicen el mismo vocabulario y comprendan el proceso antes de comenzar. Este proceso de educación lo ayudará a identificar las brechas en sus propios conocimientos.
  • Comprométase con el proceso. Una vez que haya comenzado, no mire hacia atrás. Yoda debe de haber tenido esto en cuenta cuando dijo: "Hazlo o no lo hagas... No existe intentar." Si las cosas empiezan a salir mal, realice todos los ajustes necesarios al proceso nuevo en vez de volver a lo que solía hacer antes de dar comienzo al proceso en cuestión.

Es necesario contar con el compromiso de su equipo para lograr el éxito. Para ello es necesario que usted crea en el proceso. La planificación ágil puede funcionar para su equipo si usted se compromete a hacer todo lo correcto.


Programación de sus iteraciones

Comencemos con una pregunta muy popular: "¿Cuál debería ser la longitud de sus iteraciones?" El objetivo de las iteraciones consiste en permitir que el equipo obtenga la retroalimentación necesaria en las primeras etapas del proceso y de los interesados (clientes, el propietario del producto y demás personas involucradas).

La iteración más común dura entre dos y cuatro semanas (a veces, dura hasta seis semanas). Las más cortas suelen ser más fáciles de planificar ya que el cambio rápido crea un sentido de urgencia. Aquellas más prolongadas dan la falsa impresión de que se dispone de mucho más tiempo para hacer el trabajo requerido. Esto puede resultar muy contraproducente.

Las iteraciones son el latido del corazón de su equipo. Usted siempre debería realizarlas, incluso cuando no esté trabajando en una versión. Esto hará que el equipo pueda programar tempranas investigaciones (también conocidas como clavos arquitectónicos), realizar prototipos o crear historias de usuario para la próxima versión. Realizar estas actividades antes de trabajar en las iteraciones "oficiales" correspondientes a la versión lo puede ayudar a identificar los riesgos con antelación y diseñar planes de mitigación de ser necesario.

Intente no modificar la longitud de la iteración durante una versión en particular sólo con el propósito de cumplir con una fecha de lanzamiento estipulada. Es posible que su equipo se resista al cambio. Además, si modifica la longitud de la iteración de manera muy frecuente, se estará demostrando que los líderes de su equipo no confían en el nuevo proceso. También resulta más difícil calcular la velocidad del equipo (un tema que trataremos más adelante en Medición de la velocidad) cuando las longitudes de la iteración varían, ya que no se está utilizando un período de tiempo constante para realizar la medición.

La excepción a preferir una iteración más corta es la iteración final. Si la iteración final incluye actividades, principalmente, de etapa final, tales como la globalización y la corrección de errores, al equipo le resulta menos disruptivo contar con una iteración más corta en este momento.

Como alternativa a la programación de una iteración más corta para la iteración final, usted puede programar una longitud menor (como, por ejemplo, dos semanas) para todas las iteraciones. Mediante la utilización de este enfoque, si la fecha de lanzamiento no se encuentra al final de la iteración, usted podrá finalizar el trabajo para realizar el lanzamiento una semana antes.

En el último día de una iteración, destine el tiempo que sea necesario para realizar una demostración y un análisis retrospectivo de la iteración e incluya a los desarrolladores, al equipo de gestión y a los interesados. La demostración de las características ayuda a todas las personas involucradas a ver el progreso que realizó el equipo y, además, brinda una oportunidad para obtener retroalimentación temprana, lo que podrá resultar en ajustes valiosos durante el curso de la versión.


Creación de historias de usuario

Las historias de usuario son frases ingeniosas que establecen los requisitos del cliente. Imagínelas como lo que usted le diría a un cliente para explicarle lo que está haciendo. Las historias de usuario se concentran en las necesidades del cliente y no explican los detalles de la implementación.

El propietario del producto habla con los clientes para lograr comprender sus requisitos y crea un conjunto inicial de historias de usuario de alto nivel. Para crear historias de usuario más detalladas, probablemente necesite crear un equipo de clientes que tengan un gerente de producto, testers, usuarios reales y diseñadores de interacción. Esta plantilla resulta muy útil para la redacción de historias de usuario:

En mi calidad de<cargo>, deseo <objetivo>lograr<valor de negocios>.

Las historias de usuario también pueden tener una jerarquía. Las epopeyas son aquellas historias de usuario que describen las características o las funcionalidades en un nivel más avanzado. Usted puede iterar con éstas, desglosarlas y generar nuevas historias de usuario y epopeyas. La figura 1 ilustra una epopeya que se dividió en múltiples historias de usuario.

Figura 1. Epopeya dividida en historias de usuario
An image of an epic broken into multiple user stories

Las historias de usuario representan el trabajo que el equipo debe realizar para satisfacer los requisitos del producto. ¿Cuál debería ser la longitud de las historias de usuario? En el caso de las epopeyas, realmente no tiene importancia, ya que luego se los podrá dividir en unidades más cortas. La creación de aquellas historias con las que el equipo trabajará durante la iteración deberían llevar entre dos y tres días y estar impulsadas por las funcionalidades, siempre que esto sea posible.

Nunca se debería determinar la longitud de las historias de usuario de manera tal que se adapten a una iteración. Por ejemplo: En el caso de una iteración de cuatro semanas de duración, existe la posibilidad de que se cuente con una historia larga que no se pueda incluir dentro de la iteración. Al final de la iteración, es probable que se dé cuenta de que el equipo no puede abarcar la totalidad del trabajo que se comprometió a realizar.

Es normal que el registro de su versión tenga una gran cantidad de historias de usuario. Considere esto como una verificación de la realidad. Si cuenta con menos historias de usuario pero le lleva más tiempo implementarlas, esto quiere decir que no tiene una clara idea del trabajo que necesita realizar.

Debería tratar de adoptar el enfoque de componentes fundamentales al momento de crear historias de usuario. ¿Cuál es el comportamiento funcional mínimo que puede brindar? Comience desde dicho punto. Luego, cree otra historia para el próximo conjunto de comportamientos funcionales y siga avanzando hasta que haya creado todas las historias que sean necesarias para cubrir la totalidad de esta característica.

Tenga en cuenta que las historias pueden llegar a penetrar en los diferentes componentes de su producto. En tal caso, su equipo sólo necesita crear las tareas para cada componente durante la fase de planificación de la iteración.


Identificación del propietario del producto

Lo próximo a hacer es identificar el propietario del producto. El propietario del producto es alguien que está en contacto con los clientes y comprende sus necesidades. Él identifica las características requeridas que el producto debe incluir para lograr el éxito comercial y satisfacer las necesidades de los clientes.

La relación que existe entre el propietario del producto y el equipo de desarrollo es muy similar a la relación que hay entre un cliente y su proveedor. Lo más importante a recordar sobre la planificación ágil es que el equipo de desarrollo siempre debería trabajar sobre los puntos que el propietario del producto considera importantes. Por esta razón es que tanto el registro del producto como los registros de la versión son listas que establecen prioridades.

Incluso cuando el propietario del producto sea quien toma la decisión final en relación con las prioridades, tendrá que seguir existiendo una relación saludable entre el equipo de desarrollo y el propietario del producto. El equipo debe garantizar que sus necesidades, en relación con el trabajo de arquitectura que debe figurar en el registro de la versión, se comprendan y prioricen de manera adecuada.

La responsabilidad del propietario del producto consiste en garantizar que se priorice tanto el registro del producto como el registro de la versión de forma adecuada para así garantizar que el equipo siempre esté trabajando sobre los puntos más importantes.

Registro del producto

El propietario del producto es el responsable del registro del producto, un conjunto de historias de usuario ordenadas según su prioridad que se implementará en el producto.

Es probable que su equipo ya cuente con una base de datos de requisitos o áreas de trabajo. En tal caso, estos constituyen un buen punto de partida para crear su registro del producto. Para convertir su base de datos ya existente, el propietario del producto debería revisar la base de datos de los requisitos e identificar las historias de usuarios de alto nivel relacionadas con cada uno de ellos.

Es necesario priorizar el registro, ya que esto hace que el propietario del producto pueda seleccionar las partes más importantes de un requisito a implementar. A un requisito se lo puede llegar a dividir en diez historias de usuario. Pero si el equipo de desarrollo logra completar las cinco historias más importantes, es probable que eso sea suficiente como para satisfacer los requisitos del cliente.

Figura 2. ¿Cómo alimenta el registro del producto a todos los demás?
Image showing how the product backlog feeds the release backlogs and the iteration backlogs.

Es necesario que el equipo estime las historias de alto nivel en el registro del producto utilizando puntajes. Todos los grupos involucrados en la entrega de caracterízaciones (desarrollo, seguro de calidad y documentación) participan del proceso de estimación. Estas estimaciones hacen que el propietario del producto pueda determinar el costo relativo de cada rasgo.

El registro del producto debe ser dinámico y se podrán agregar, eliminar y volver a priorizar sus elementos. Al mismo tiempo, es necesario que se lo actualice. El trabajo que representa no debería superar los 18 meses. Una vez superado dicho período de tiempo, se deberían quitar de la lista todos los elementos de baja prioridad.

¿Por qué se debería limitar la longitud del registro? Esta sugerencia resulta de los principios Sensibles (vea el Resumen del desarrollo ágil de software). No tiene sentido mantener una cantidad de trabajo en espera que usted sabe que no podrá realizar en una cantidad de tiempo razonable. Si una buena idea se quita del registro, se la volverá a incluir, si realmente es una buena idea, y usted está en contacto con las necesidades de sus clientes. Por lo tanto, permita que algunos elementos se quiten de la lista y no trate de conservarlos en otra lista de registro secreta o escondida.

Registro de la versión

Al comienzo de una versión, el propietario del producto mira el registro del producto e identifica las historias de usuario que se incluirán en la próxima versión. Luego, estos elementos pasan al registro de la versión.

Generalmente, el ritual de imposición de ideas y plazos comienza en este momento. Ahora, el equipo de desarrollo debe trabajar conjuntamente con el propietario del producto para garantizar que el trabajo identificado sea apropiado para el tamaño y la duración de la versión. El rastreo de la velocidad del equipo durante la versión ofrecerá un panorama más claro de qué proporción de todo el trabajo se llevará a cabo de manera efectiva.

Al crear el registro de la versión, divida las historias de usuario de alto nivel en historias de usuario más cortas. Para hacer esto, considere la creación de un equipo del cliente que incluya un gerente de producto, testers, usuarios reales y diseñadores de interacción.

El equipo del cliente trabaja conjuntamente con el propietario del producto con el fin de establecer la prioridad de las historias nuevas y, luego de esto, agregarlas al registro de la versión. Después de esto, el equipo de desarrollo realiza estimaciones sobre estas historias nuevas y les asigna un puntaje. El objetivo de esta etapa es que el equipo de desarrollo tenga una idea clara de lo que se requiere que figure en la versión más partes y más pequeñas para así poder realizar la estimación correspondiente.

A medida que el equipo de desarrollo trabaja con las historias de usuario durante las iteraciones, el propietario del producto y el equipo de desarrollo adquieren conocimientos. Estos conocimientos pueden llegar a generar nuevas historias de usuario o demostrar que algunas historias no son tan importantes. En el caso de las historias nuevas, el propietario del producto y el equipo de desarrollo necesitan atravesar el proceso de estimación y prioridad una vez más. El propietario del producto debería eliminar todas aquellas historias que no sean tan importantes del registro de la versión o reducir su importancia. Además, el equipo también puede utilizar estos nuevos conocimientos para modificar las estimaciones correspondientes a las historias ya existentes que figuran en el registro.

El registro de la versión es dinámico. Pero una vez que se da comienzo a la iteración, el propietario del producto ya no puede modificar el trabajo que se seleccionó para la iteración. Si, luego de que se dio comienzo al trabajo, el equipo adquiere conocimientos que revelan que ciertos elementos no entran en la versión o en la iteración, nos encontraremos ante una situación diferente (como se discute en la próxima sección). Durante la iteración, el equipo de desarrollo debe poder concentrarse en sus entregas.

Registro de la iteración

Al comienzo de la iteración, el propietario del producto puede volver a determinar la prioridad del registro de la versión con el fin de que el equipo de desarrollo tome conocimiento de los elementos con los que va a tener que trabajar. Tanto el propietario del producto como el equipo de desarrollo deberían realizar la reunión de planificación de la iteración durante la mitad del primer día de la iteración. Durante esta reunión, el equipo debería seleccionar todos los elementos de alta prioridad que pueda incluir el registro de la versión y agregarlos al registro de la iteración.

El hecho de tener listo el registro de la versión nos permite limitar esta actividad a sólo la mitad del día. Si el equipo está a cargo de crear las historias de usuario de iteración a iteración (en vez de hacerlo lo antes posible), es probable que usted pierda tiempo muy valioso y tarde más en realizar la planificación. Además, usted nunca sabrá con exactitud la cantidad de trabajo que se planificó para su lanzamiento.

Durante la reunión de planificación, por cada historia de usuario que figura en el registro de la iteración, el equipo necesita desglosar todas las tareas requeridas para que se pueda considerar la historia como completa. También es necesario identificar las tareas de todos los equipos involucrados en la historia (desarrollo, seguro de calidad, documentación). Además, el equipo necesita estimar la carga horaria correspondiente a cada una de estas tareas y, luego de esto, agregar estas estimaciones al plan.

La mayor preocupación es el compromiso excesivo. Durante sus primeras iteraciones, considere la cantidad de horas necesarias en la estimación para así poder garantizar que el trabajo se adecue al tiempo asignado para la iteración. Si el equipo termina el trabajo antes de tiempo, siempre puede volver al registro de la versión y seleccionar tareas adicionales que se puedan completar durante la iteración.

La otra preocupación consiste en no poder identificar todas las tareas requeridas para completar una historia. Desafortunadamente, esto es inevitable en sus primeras iteraciones. Estos elementos olvidados se apilan y pueden llegar a hacer que usted no pueda completar una historia en particular durante una iteración. A continuación, incluimos dos ejemplos de este error tan común:

  • Contar con un sector de almacenamiento denominado "Prueba" que no incluye el tiempo necesario para redactar los casos de prueba.
  • No incluir una tarea para que el equipo de desarrollo redacte pruebas de la unidad automatizada.

Antes de que el equipo vuelva al registro de la versión, asegúrese de que se hagan las historias que figuran en la iteración (luego de esto asegúrese de que se hagan dos veces más). Es decir, ¿se completaron todas las tareas? Si todavía queda pendiente alguna prueba para una historia de usuario, lo que más le conviene es hacer que el desarrollador ayude al tester a completar dicha prueba. Si sigue habiendo defectos en el caso de las historias de usuario desarrolladas en la iteración, corríjalos ahora antes de seguir avanzando. Contribuya con la calidad. Lo que realmente importa no es la cantidad de trabajo que realice en una iteración sino el hecho de que el trabajo entregado esté lo más libre de errores que sea posible.

Además, le conviene establecer criterios de salida para sus iteraciones. Por ejemplo, todos los defectos de alta prioridad (severidad uno y dos) se deben resolver para que se pueda considerar que la historia está completa. Todos los defectos de baja prioridad (severidad tres y cuatro) que queden sin resolver se deberán resolver en la siguiente iteración y se agregarán en la parte superior del registro de la iteración. Es muy importante no permitir que los defectos se prolonguen por un período de tiempo extenso. De esta forma, usted se encontrará en una posición mucho más favorable durante la parte final del proceso correspondiente a su lanzamiento.

Si, durante el transcurso de la iteración, el equipo se da cuenta de que una historia de usuario resulta ser más complicada que lo que se pensaba en un principio y no puede formar parte de la iteración o incluso de la versión, usted deberá presentar este problema lo antes posible. Es muy importante identificar sus opiniones. ¿Existe una forma de reducir paulatinamente la historia mientras que se sigue creando valor para el cliente en la versión actual? En tal caso, cree las historias de usuario adecuadas y discútalas con el propietario del producto. La versión reducida puede ser sólo una medida temporaria: ¿Qué haría si contase con el tiempo necesario para hacer lo correcto? Identifique las historias de usuario correspondientes a estos elementos y discútalas con el propietario del producto. Es probable que aparezcan en las versiones futuras del producto.

El equipo puede agregar todo tipo de trabajo en el plan de iteración. Si una característica en particular requiere un clavo arquitectónico, agregue una historia de usuario al registro de la versión y cuente con las siguientes tareas por ejemplo: "Diseño", "Construcción del prototipo" o "Investigación". Lo que tiene de bueno agregar una historia de usuario al registro de la versión para el clavo arquitectónico es que permite que el propietario del producto le dé prioridad. Si el propietario del producto cree que el costo de la investigación es muy elevado, la historia correspondiente al clavo arquitectónico se encontrará más abajo en la lista o se eliminará la característica de la versión.


Asignación del puntaje a las historias de usuario

En el registro del producto y en los registros de la versión, el equipo de desarrollo estima y asigna el puntaje para cada historia de usuario. ¿Por qué conviene utilizar puntajes en vez de unidades de tiempo (como, por ejemplo, las horas)? La razón principal es que, en las primeras etapas de desarrollo, usted no sabe cuánto trabajo le demandará una historia en particular. Y, si realiza todo el análisis y el diseño de antemano, es posible que evite que el diseño evolucione, ya que usted conoce más sobre la característica en cuestión.

Otra razón es que el tiempo ideal puede variar de una persona a otra. Si la persona que realiza la estimación no es la misma que hace el trabajo, existe la posibilidad de que la estimación no sea correcta.

Por último, lo que originalmente era una estimación del tiempo ideal se puede llegar a interpretar erróneamente como una estimación del tiempo transcurrido. El tiempo transcurrido es el tiempo que lleva hacer el trabajo luego de contabilizar todas las interrupciones que el empleado sufre durante un día de trabajo común y corriente. Entonces, por ejemplo, una tarea con una duración estimada de cinco días podría llevar entre ocho y nueve días reales si se toman en cuenta las reuniones diarias, los correos electrónicos, las llamadas telefónicas y las revisiones.

Cuando se utilizan puntajes, lo que se hace es comparar la complejidad relativa que existe entre dos características. Si toma una historia que tiene sólo un punto y la compara con otra que tiene cinco puntos, lo que se establece esencialmente es que la segunda historia es cinco veces más grande que la primera. Tenga en cuenta que nunca se dijo que esto necesariamente involucraría cinco veces más trabajo.

Es posible que haya historias de usuario que el equipo no pueda estimar, ya que se desconocen muchos factores. En tales casos, el equipo puede agregar una historia de usuario específica al registro para luego realizar una investigación adicional al respecto. Una vez hecho esto, el equipo puede volver a analizar la historia para asignarle el puntaje correspondiente.

Al principio, estimar los puntajes es un gran desafío, ya que su equipo no cuenta con un puntaje de referencia. A medida que el equipo realiza más y más estimaciones, la precisión de éstas irá aumentando. Para estimar los puntajes, puede usar la técnica de Planificación de Póker.

La Planificación de Póker es una técnica de estimación basada en el consenso que se utiliza para estimar el esfuerzo requerido por las tareas de desarrollo de software o su tamaño relativo. Esto busca minimizar el anclaje(comentarios tempranos que los miembros del equipo expresan a viva voz y "anclan" el tiempo que lleva una tarea). Cada miembro del equipo muestra su carta de estimación (la que expresa los valores 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40 ó 100 pero no unidades, ya que el moderador está a cargo de determinarlas) de manera tal que los demás participantes no puedan verla. Luego de que todos los participantes hayan hecho esto, todas las cartas se ponen en conocimiento de los demás al mismo tiempo.


Medición de la velocidad

La velocidades son el rastreo a largo plazo de la cantidad de trabajo que realizó un miembro del equipo por iteración. Esto se mide utilizando las mismas unidades que figuran en el registro de la versión (es decir los puntajes).

Al principio, al equipo le asigna un puntaje a cada historia en el registro de la versión. El el comienzo de cada iteración, el equipo selecciona las historias con las que trabajará durante el transcurso de la iteración. Para ganar los puntos que se asignaron a una historia en particular, el equipo debe completar todas las tareas correspondientes a dicha historia durante la iteración.

Si el equipo no completa una o más tareas correspondientes a una historia en particular, no recibirá ningún punto por dicha historia al finalizar la iteración actual y la misma pasará a la próxima iteración. El equipo ganará los puntos correspondientes a la historia en la iteración durante la que complete las tareas pendientes.

A medida que el equipo completa las iteraciones, acumula puntos y observa los datos correspondientes a las iteraciones anteriores, una imagen como la que se puede observar en la Figura 3 comienza a surgir. Tenga en cuenta cómo el equipó no gana la misma cantidad de puntos en cada iteración.

Figura 3. Velocidad a lo largo de varias iteraciones
Image of bar chart showing velocity over multiple iterations

Lo interesante sobre la velocidad es que, luego de algunas iteraciones, usted puede comenzar a utilizar las cifras que figuran en sus cuadros de rastreo para extrapolar la cantidad exacta de elementos de su registro de la versión que podrá completar.

Tabla 1. Puntaje por iteración
IteraciónPuntos
128
232
336
434
533
637
731
835

La Tabla 1 muestra los puntajes por iteración. Utilizando los datos que figuran en la Tabla 1, usted puede extrapolar la siguiente información:

  • La cantidad promedio de puntos por iteración es 33.
  • La velocidad actual del equipo es 35 puntos.
  • El promedio de las tres iteraciones más lentas es 30 puntos.

Por lo tanto, asumiendo que usted tiene 6 iteraciones pendientes en su versión, puede comenzar por realizar las siguientes suposiciones:

  • A una velocidad promedio, el equipo obtendrá 198 puntos adicionales (6 x 33).
  • A la velocidad actual, el equipo obtendrá 210 puntos adicionales (6 x 35).
  • A la velocidad más lenta, el equipo obtendrá 180 puntos adicionales (6 x 30).

En la Figura 4, se puede observar el registro de la versión dividido en tres secciones. La sección del medio representa el trabajo que se puede incluir en las últimas 6 iteraciones utilizando las suposiciones que figuran más arriba.

Figura 4. Extrapolación donde culmina el trabajo
Extrapolating where the work ends

La Figura 4 también muestra que el equipo de desarrollo no puede completar todas las historias de usuario en el registro de la versión. No obstante, si el equipo siempre comienza a trabajar con los primeros puntos que figuran en la lista, existen más posibilidades de que el equipo siempre haya trabajado con los puntos más importantes de la versión.


Conclusión

El principal objetivo de la planificación ágil consiste en que la mayor parte posible del trabajo "conocido" esté sobre la mesa a la vista de todos. Este artículo enfatiza lo "conocido" porque, a medida que usted adquiere conocimientos sobre lo que está haciendo, existe la posibilidad de que agregue historias nuevas al registro. Esto hace que el propietario del producto modifique la prioridad del registro de la versión de manera continua y garantice que el equipo de desarrollo siempre esté trabajando con los temas más importantes.

Generalmente, los propietarios de productos sobreviven incluso cuando no todas las historias llegan a formar parte de la versión. No obstante, suelen enojarse por esto cuando el equipo dedica demasiado tiempo a temas que no tienen una importancia crítica y, por lo tanto, no pueden incluir todas las historias importantes en la versión porque no les alcanza el tiempo. Por lo tanto, trate a los propietarios de productos como si fuesen sus clientes y concéntrese en priorizar las tareas que ellos consideran primordiales.

Todas las opiniones que incluí en este artículo son personales y no necesariamente compartidas con IBM.

Recursos

Aprender

Obtener los productos y tecnologías

  • Utilizando elsoftware a modo de prueba de IBM, que está disponible para bajarlo directamente desde developerWorks, construya su próximo proyecto de desarrollo en Linux.

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=390914
ArticleTitle=Planificación ágil en la vida real
publish-date=05212009