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 usuario. XP, eXtreme Programming, por ejemplo, utiliza el story point, 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, 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 podría, o bien 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, no es fácil entender que por ejemplo 4 horas de tiempo ideal se han realizado en 6 horas reales y que eso es puede 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, 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 es media jornada y consideran la jornada de 6 horas en tiempo ideal, por tanto realizable en 8 horas reales... para concluir cualquier elemento con el que el equipo se sienta cómodo es válido.

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 gerencia, como pordria 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 podriamos 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, 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 tareas 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 las tareas, 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 cuantas tareas 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 las tareas 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 han navegado un poco por internet, que han decidido apuntarse al curso de Scrum Manager, pero para los que el concepto de agilidad aún les es confuso, he preparado esta analogía que ayuda a aclarar las ideas. 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 de puzzle la imagen está totalmente definida, se sabe de antemano que se obtendrá el puente de la foto, cuya construcción se basa en colocar las piezas de forma que todas encajen. En el caso del lego solemos empezar por una construcción, una casa, luego añadimos otras casas, vías, coches... y poco a poco se alza ante nosotros una ciudad, que no diseñamos 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 las piezas haciendo que encajen todas ellas. 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 - Metodología ágil
Las metodologías ágiles, evolutivas, son análogas al lego. La construcción de la ciudad es incremental, un crecimiento evolutivo, empezamos por aquella casa o edificio que más nos gusta, 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 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 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 trabajo. Está formada por la lista de tareas, en las que se han descompuesto las historias de usuario, y que se van a llevar a cabo en el sprint.
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 usuario no autorizado quiero crear una cuenta para darme de alta en el foro de libros" o "Como usuario autorizado quiero acceder a la tienda on-line". Son siempre historias desde el punto de vista de un cliente y que este quiere 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 diseño, de programación, de pruebas... todo lo necesario para resolver y garantizar dar solución a las historias de usuario.

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 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 inlcuso puede que ni se desarrolle. 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.