viernes, 18 de julio de 2014

¿1 punto de historia = 1 día ideal?

En charlas, foros y otros ambientes de discusión, hay debates sobre la unidad a utilizar para estimar el tamaño de las historias de usuarioXP, eXtreme Programming, por ejemplo, utiliza el punto de historia, y lo define como la cantidad de trabajo que se realiza en un día: 1 punto = 1 día ideal.

Realmente la unidad que se utilice es irrelevante. Lo que importa es que el equipo la conozca y la tenga interiorizada, signifique lo mismo para todos y que todo miembro sepa estimar con esa misma unidad.

Usar el tiempo, en el caso de XP los días, también es tema de debate, ya que en los proyectos medimos tamaño en unidad de tiempo, usualmente en horas/hombre o días/hombre. Algún comercial o jefe de proyecto podría, o bien de forma inconsciente o bien caer en la tentación de hacerlo conscientemente, condicionar al equipo en la estimación de las tareas. Cuantas veces nos han dicho al estimar "el proyecto han de ser tantas horas aproximadamente, por encima de eso el cliente no lo aceptará....". Por otro lado solemos caer en considerar la medida de trabajo "tiempo ideal" equivalente a la medida de tiempo real o duración, no es fácil entender que por ejemplo 4 horas de tiempo ideal se han realizado en 6 horas reales, aunque eso pueda ser una muy buena productividad.

Página de login, algo común a muchas aplicaciones
Lo ideal es que cada equipo defina el punto de historia como algo que le sea representativo, cualquier elemento con el que el equipo se sienta cómodo es válido; por ejemplo en pantallas maestro-detalle, en listados de 10 columnas y totales, páginas de login... Toda aplicación suele tener una página de login, por tanto es un buen referente común de los equipos para una unidad de tamaño. He trabajado con un cliente con una buena experiencia en que un punto de historia de partida fue media jornada y que consideró la jornada de 6 horas en tiempo ideal, por tanto razonablemente realizable en 8 horas reales.

Una vez hayamos empezado a rodar el punto de historia toma su significado, y probablemente no represente ese tiempo ideal con el que el equipo ha comenzado. Es momento de desacoplar, no mirar atrás, permitir que el sistema recalibre el punto de historia a lo que le llevado la mejora continua del marco de Scrum.

martes, 15 de julio de 2014

¿En qué poder apoyarse para registrar la evolución de los sprints de un proyecto?

Evolución de un sprint en forma de gif animado
Por diversos motivos puede ser interesante registrar como van evolucionando los sprints, ya sea por trazabilidad o por necesidad de reporting a una oficina de proyectos o directamente a la gerencia, como podría ser en caso de empresas de pequeña envergadura.

Tradicionalmente cogeríamos nuestros inventarios de tareas, con la situación diaria de las mismas, y las pondríamos sobre la mesa para responder a las peticiones y preguntas que nos harían. En el marco de Scrum podríamos pensar en el diagrama burndown, pero este es una representación gráfica de la evolución del trabajo dentro de un sprint dado, da información pero no de la evolución completa, puede ser útil, pero sería parcial.


Una solución simple y fácil de implementar es tomar una foto del tablero Kanban con una cámara digital todos los días. Quien tenga interés en la trazabilidad o analizar la evolución de los sprints tiene así una excelente fuente de información visual y diaria. Reportaríamos en base a una serie de fotografías que mostrarían la situación día a día.

Evolución de un sprint con fotografías periódicas

lunes, 14 de julio de 2014

¿Si Kanban es para incremento continuo, quiere esto decir que no debe usarse Kanban cuando se aplica Scrum con incremento por sprints?

En ambos marcos ágiles, Scrum y Kanban, se utilizan tableros. Aunque existe el término de tablero Scrum o scrumboard, usualmente se habla en ambos casos de tableros Kanban, lo que puede llevar a confusión. Lo importante es que en ambos casos se usan tableros como gestión visual para irradiar la información sobre lo que haya en marcha, así como para visualizar el flujo o la evolución del sprint.

En el caso de Scrum, caso iterativo, el tablero contiene todas las tareas del sprint, y durante el mismo progresan de columna de la pila de sprint a la columna de terminado. Con un vistazo al tablero se ve la situación global del sprint, tablero que suele incluir el gráfico burndown, que es propio de Scrum.

El caso de Kanban es distinto, se trata de incremento continuo. Continuamente entran elementos en la columna de tareas pendientes. En este caso la función principal del tablero es la de regular el flujo de trabajo. Eso se traduce en hacer que los elementos, tal como entren, se ejecuten lo antes posible, y progresen a la columna de terminado de la forma más optima posible, evitando cuellos de botella y tiempos de espera. Esta regulación se consigue ajustando el WIP (Work in Progress) de alguna o todas las columna del tablero. El WIP indica cuantos elementos pueden estar en una columna determinada a la vez. El ajuste del WIP dependerá de las formas de hacer cada empresa y puede requerir algunos meses de rodaje.
Ejemplo de tablero Kanban para desarrollo continuo con TDD - cortesía de Scrum Manager
La gran diferencia es la regulación, Kanban regula para que los elementos fluyan como en una balsa de aceite, mientras que en Scrum, representa la situación actual del sprint.

Para profundizar más en el tema recomiendo la lectura de "Kanban y Scrum - obteniendo lo mejor de ambos" de Henrik Kniberg & Mattias Skarin.

viernes, 11 de julio de 2014

¿Pero cual es la diferencia a grandes rasgos entre metodología tradicional y ágil?

Para los que se interesan por primera vez por Scrum, que hayan navegado un poco por internet y que hayan decidido apuntarse al curso de ScrumManager, y para los que el concepto de Agilidad aún les es confuso, he preparado esta analogía que ayuda a aclarar los conceptos que hay detrás. Como se suele decir, más vale una imagen que mil palabras.

Todos hemos jugado con puzzles y legos, y todos hemos experimentado que son dos formas muy distintas de construir. En el caso del puzzle la imagen está totalmente definida, se sabe de antemano que se obtendrá, como el puente de la foto del ejemplo a la izquierda y cuya construcción se basa en colocar las piezas de forma que todas encajen. En el caso del legos solemos empezar por una construcción inicial, como una casa, y luego añadimos otras casas, vías, coches... y poco a poco se alza ante nosotros una ciudad, que no hemos diseñado de entrada, pero que es reflejo de La Ciudad que nos gusta.

Puzzle - Metodología tradicional
Las metodologías tradicionales, predictivas, son análogas al puzzle. El producto final está definido al 100% desde el principio, y el proyecto trata de construir la imagen a través de las piezas haciendo que encajen todas ellas y buscando la forma más optimizada de hacerlo. Es interesante observar que si introducimos una variación en el puzzle, buena parte del mismo se desmonta, y es muy costoso volver a construir piezas que encajen perfectamente dentro de este marco tan rígido. En los proyectos con metodologías tradicionales esto pasa de forma análoga, un cambio o una buena idea a mitad de proyecto puede convertirse en una pesadilla.

Lego - Método ágil
Los métodos ágiles, evolutivos, son análogos al lego. La construcción de la ciudad es incremental, un crecimiento evolutivo, empezamos por aquella casa o edificio que más nos gusta y por tanto más valor tiene para nosotros, aquel que es representativo de lo que queremos construir. Luego poco a poco vamos añadiendo aquí y allá, según lo que nos motive. Y si una casa no nos gusta, la cambiamos o desmontamos en el mismo momento, en el que se produce el cambio. No es costoso porque el conjunto no está acabado y si se introduce una modificación es sobre algo de lo que no tenemos una imagen final, por tanto simplemente modificamos y construimos hacia lo que realmente queremos. En los proyectos ágiles pasa de forma análoga, construimos por incrementos, y, sin saber de antemano cómo será el producto final, revisamos al final de cada iteración, y nos adaptamos para seguir construyendo por ahí donde marca el mercado, por ahí donde le damos más valor al producto.

Como curiosidad mencionar, que si preguntáis a la gente que os rodea, os daréis cuenta de que generalmente preferimos uno u otro juego antes que el otro, podríamos decir que somos puzzleistas o legolistas. :-)

miércoles, 9 de julio de 2014

¿La pila de sprint es un subconjunto de la pila de producto?

Si, es una descomposición. La diferencia conceptual es que la pìla de producto refleja los requisitos vistos desde el punto de vista del cliente. Está formada por una lista de funcionalidades o "historias de usuario" que desea obtener el cliente. En cambio la pila de sprint refleja los requisitos vistos desde el punto de vista del equipo de desarrollo. Está formada por la lista de tareas, en las que se han descompuesto las historias de usuario, que se van a llevar a cabo en el sprint. También incluye las historias de usuario seleccionadas, aunque lo que recorre el scrumboard solo sean las tareas.

Historias de usuario y tareas
Para hilar más fino cualquier elemento de la pìla de producto representa valor para el cliente. Por ejemplo historias de usuario serian "Como lector quiero poder acceder al los foros de libros para poder conocer opciones de qué libro leer" o "Como padre de familia quiero explorar la tienda on-line para poder hacer pedidos sin tener que desplazarme y estar con mi familia". Son siempre historias desde el punto de vista de un cliente y lo que este quiera obtener.

La pila de sprint está formada por las tareas necesarias para que el equipo pueda construir el producto. Pueden ser tareas de preparación, de maquetación, de diseño, de programación, de front, de back, de pruebas... todo lo necesario para resolver y garantizar dar solución a las necesidades del cliente a través de las historias de usuario de la pila de sprint.

En la imagen de la izquierda se muestra un tablero Kanban con la descomposición de historias de usuario (post-its largos con identificadores USx) en sus tareas (post-its cuadrados de colores representando la naturaleza de la tarea: A-análisis, D-desarrollo y P-pruebas).

viernes, 4 de julio de 2014

¿Se pueden calcular las horas/hombre de un proyecto bajo Scrum y calcular el precio final?

Scrum es un marco ágil y flexible para trabajar en entornos inestables o entornos con una alta variabilidad como suelen ser los proyectos de TI. Se aplica en escenarios donde el cliente conoce la visión de su producto pero no puede detallar cómo será el producto final, por tanto no tiene sentido hablar de un proyecto cerrado en alcance que se pueda evaluar en horas.

Bajo Scrum se va iterando y dirigiendo el proyecto por aquellas funcionalidades donde el valor de negocio es máximo en cada momento. Una y otra vez se ajusta el proyecto a la experiencia aprendida adquirida, a las variaciones del mercado y a las oportunidades emergentes; en definitiva es lo que hace que la compañía sea más competitiva. El final del proyecto lo marca el cliente con la limitación de su presupuesto. Por tanto, lo que se fija en un proyecto bajo Scrum son los costes, y estos a su vez, fijan el tiempo, ya que un sprint es valorable (los recursos y el tiempo son conocidos). Se podrán hacer tantos sprints como lo permita el presupuesto.

En proyectos ágiles se utiliza lo que se denomina la contratación ágil, donde el cliente lo que contrata es un número de sprints. Una imagen que ayuda a comprender mejor este concepto es la imagen del triángulo de hierro, que muestra metodología tradicional (cascada) versus ágil.
El triángulo de hierro
En las metodologías tradicionales lo único que es fijo es el alcance, y aunque se establezcan el tiempo y el precio en el contrato, el tiempo siempre es estimado y por tanto los costes también lo son.

En los proyectos ágiles tanto el tiempo como los costes son fijos y lo que es variable es el alcance. Esto puede dar a entender que puede que no se cumpla con toda la funcionalidad, pero si se prioriza correctamente, las funcionalidades más importantes, incluso las sobrevenidas por variaciones del mercado, estarán completas y funcionando correctamente, se garantiza la construcción del mejor producto para un presupuesto dado.


Podemos decir que los proyectos bajo esta perspectiva son proyectos que están time-boxed. Imaginemos que a un departamento determinado se le aprueba un proyecto cuyo límite es una duración de 6 meses, solo puede construir durante esos 6 meses. Ese enfoque tiene consecuencias deseables directas, dado el tiempo limitado el departamento, o Propietario del Producto del mismo, sentirán la presión del tiempo limitado, se espabilaran para liderar su proyecto y priorizarán las funcionalidades que deseen construir guiados por valor de negocio.

martes, 1 de julio de 2014

¿Se pueden mezclar epics e historias de usuario en la pila de producto?

Pila de producto con epics e historias de usuario
Entendiendo un epic como una historia de usuario de gran tamaño, que dividida resulta en una serie de historias de usuario que individualmente representan los pasos de algún flujo de trabajo, si, se pueden mezclar epics e historias de usuario.

La pila de producto debe de estar ordenada por prioridad y la granularidad o nivel de detalle de cada elemento va en relación a la posición del mismo dentro de la pila. En una lista larga, algo muy poco prioritario no tiene sentido tenerlo al detalle, porque probablemente cambiará a lo largo del proyecto, e incluso puede que ni se desarrolle. Las personas nos anclamos a esfuerzos hechos, por tanto si detallamos mucho los epics nos resistiremos a incorporar información fresca cuando esta ocurra.


Muy al final de la lista, donde está lo menos prioritario, ahí es el lugar de los epics. A medida que nos acercamos a los elementos más prioritarios, el detalle aumenta. Los elementos susceptibles de entrar en el próximo sprint, a parte de ser historias de usuario, deben de tener suficiente detalle para que en la reunión de planificación de sprint el equipo tenga toda la información necesaria y pueda desglosarlas en todas las tareas necesarias para ponerlas en producción.