Esto ocurre porque la gestión de riesgos en metodologías como SCRUM no se hace explícitamente, se hace de manera integrada en el propio proceso y, por lo tanto, de manera continua.

Quizá, la parte más explícita de la gestión de riesgos sea el Impediment Backlog. Un Impediment Backlog es una lista de incidencias que tienen que ser resueltas por el equipo y que el Scrum Master debe gestionar y asignar al alguien para que trabaje en ellas, y que será revisada en la reunión SCRUM diaria, tras la pregunta: ¿Qué está bloqueando el progreso del proyecto?

Creo que no vale la pena que explique nada más aquí porque, curiosamente, he encontrado el mejor artículo sobre el tema en castellano. Se trata de un análisis exhaustivo sobre los riesgos clásicos del desarrollo de software y cómo los afronta SCRUM. Contentísimo de que la blogosfera de habla hispana de artículos de ésta calidad, oiga.

Además, describe cómo ir adoptando las prácticas ágiles de manera paulatina, en forma de iteraciones. Una lectura realmente interesante para todos aquellos que pretendemos ir introduciendo las prácticas ágiles en nuestro proceso de desarrollo.

Además, en la parte final de libro, agrupa las prácticas ágiles por Technical Clusters, esto es, conjuntos de prácticas analizadas en los capítulos anteriores.

Lectura fácil y clarificadora. ¡ya os la estáis bajando!

Kanban comparte con otras metodologías como Feature Driven Development o SCRUM la idea de crear un Backlog del producto que tenga una serie de items (user stories, features…) priorizados. Pero la principal diferencia con otras aproximaciones ágiles, es que en Kanban no existen las iteraciones.

En su lugar, Kanban se centra en controlar el WIP (Work In Progress). Esto es, cuando hay poco WIP, se añade el item más prioritario del Product Backlog, y se controla que nunca se supere una cierta cantidad de WIP.

Dadas sus características, no se adapta a un desarrollo basado en entregas, y actualmente se utiliza especialmente en entornos de mantenimiento (corrección de bugs, etc.).

Dejo a continuación un comic que he encontrado en éste artículo y que me ha parecido que explica Kanban con enorme claridad.

1. Quizá la mayor diferencia aquí sea que la “feature” normalmente es un grano más gordo que las “user stories”.
2. Hace más hincapié, a nivel de escritura de código, en Model Driven Development: Build an overall model, aunque en el resto de metodologías también recomiendan basarse en un primer diseño simple.
3. Individual code ownership, que contrasta con el Colective Code Ownership de Programación Extrema. Básicamente en FDD cada uno es responsable directo de código que escribe, o cuál es “menos ágil” que si todo el mundo es responsable de todo el código (Colective Code Ownership). Lo que pasa es que, para equipos grandes, FDD lo considera más eficaz.
4. Habla explícitamente del “Configuration Management“… aunque todas las metodlogías ágiles lo recomiendan implicitamente, FDD lo hace explícitamente, como parte esencial del desarrollo.

Todas las metodologías ágiles siguen una serie de principios que hacen que se parezcan entre sí. FDD, concretamente, te ofrece unas cuantas claves respecto a la forma de organizar el equipo y la forma de programar el código, que la hacen especialmente viable para equipos de desarrollo grandes desarrollando software complejo.

La razón por la que utilizamos Google Docs y no la clásica pizarra de SCRUM es porque el equipo no se encuentra físicamente en el mismo sitio. Quizá en el futuro utilicemos herramientas más específicas para la gestión de las user stories, iteration backlog e increment … pero a día de hoy éste sistema nos está funcionando por lo sencillo y visual que es.

El objetivo de la gestión es planificar, ejecutar y controlar. Veamos a continuación cómo planificamos, ejecutamos y controlamos el valor funcional de la aplicación.

Algunos apuntes sobre la ejecución:

• El documento recoge tanto el Iteration Backlog como el Increment. Pero es un documento que sólo ve el equipo. El cliente puede ver el Product Backlog (que está en un documento a parte) y se le envía una versión “más redactada” del Increment.
• Cada iteración está en una tabla. Las tablas se guardan todas en el mismo documento, de tal manera que si vamos bajando por el documento podremos ver el backlog de las anteriores iteraciones. Las iteraciones se nombran con el primer día que se ejecutan (Iteración 18-05-2009) . Suelen ser de dos semanas.
• Todos los proyectos son gestionados desde el mismo Iteration Backlog.
• Marcamos la prioridad de una funcionalidad dentro de una iteración con [1],[2] y [3].
• Se puede saber en qué estado está una Iteración porque:
  • Si está a la izquierda y sólo pone la prioridad([1]), es que está sin empezar.
  • Si está a la izquierda pero pone la prioridad  y un dueño ([1][Luis]), es que está empezada y la está haciendo Luis.
  • Si está a la derecha, es que está terminada.
• En el incremento, además de los items terminados en la iteración, se añaden los unplanned items ([U]), defectos ([D]) y cuestiones técnicas abordadas ([T]). Supongo que para los defectos sería mucho mejor utilizar un Issue Tracker, pero normalmente los clientes suelen querer comunicarse solo por teléfono, y bastante cuesta ya hacerles escribir un mail… como para intentar que se peguen con un Issue Tracker…
• Los defectos tienen siempre prioridad sobre el desarrollo de nuevas funcionalidades.
• La trazabilidad del proyecto es enorme, no sólo porque así tenemos un histórico de todas las iteraciones, sino porque el Google Docs guarda versiones de cada cambio que se hace.. así que podríamos retrotraernos a cualquier situación pasada del documento.

Forma de detectar cómo va la iteración (controlar):

• Si se están generando muchos Unplanned Items ([U]) es que algo se diseñó mal.
• Si se están generando muchos Defectos ([D]) es que la aplicación no está suficientemente probada.
• Si se están atacando funcionalidades de prioridad [2] sin haber terminado las de prioridad [1], o se están atacando funcionalidades sin haber corregido los Defectos, probablemente se esté programando en el orden incorrecto.
• Otras cuestiones muy relacionadas con las funcionalidades, las iteraciones, sería el control de costes y plazos: lo voy a dejar fuera del artículo por no extenderme.

Algunos apuntes sobre planificación de las funcionalidades que se incluyen en cada iteración. En cada iteración se meten una serie de funcionalidades de el/los Product Backlog. Esas funcionalides cumplen que:

• Es la mayor cantidad de funcionalidades que se pueden hacer en dos semanas.
• Son las funcionalidades que más valor añaden a la aplicación.
• Camino crítico: desarrollar esas funcionalidades ayudan a descubrir posibles nuevos requisitos de forma lo más temprana posible (aunque no sea la que más valor añade), eliminar incertidumbres y hacer pensar al cliente (feedback) en qué es lo que quiere realmente. Esto también puede incluir desarrollar funcionalidades que ayuden a descubrir el diseño técnico (orientación a objetos, patrones de diseño) de la aplicación.
• La que el cliente exija (a veces no hay más remedio: hay que implementar funcionalidades que el cliente exija aunque se le argumente que no son las que más valor añaden o las que más ayudan a descubrir la forma exacta de la aplicación).
• Se evita programar funcionalides que no puedan probarse o ponerse en producción cuanto antes. Ejemplo: “Informe anual de ventas”, implementar éste informe en la primera iteración del producto, cuando todavía la empresa no ha introducido ni una sola venta, hará que no pueda probarse correctamente y traerá problemas meses después.
• Resolver defectos tiene más prioridad que desarrollar nuevas funcionalidades, aunque dependerá de la gravedad del defecto. Los defectos son difíciles de planificar porque no sabes ni cuando ni cómo saldrán.
• Es importante saber dividir o juntar funcionalidades para poder adaptarlas al tamaño de la iteración. No sirve para nada hacer “Listar facturas”, si no tienes un “añadir facturas”. Deberán ir en la misma iteración. Quizá “buscar facturas” pueda ir en la siguiente iteración, pese a que todo ello fuera planificado originalmente como “gestionar facturas (listar, añadir, modificar, eliminar, buscar)”.

• Planning: user stories, release planning, small releases, project velocity, iterations, iteration planning, move people around, stand-up meetings
• Designing: simplificity, system metaphor, CRCcards, spike solutions, no funcionality added early and refactor.
• Testing: unit testing, acceptance test, etc.
• Coding: integración continua y TDD.

Cualquiera de las metodologías ágiles puede cumplir la parte de planning, designing y testing. Es más, por seguir esos principios generales podrás decir que estás siguiendo una metodología ágil, pero nadie podrá adivinar cual exactamente. Como se explica en el artículo más completo que yo he leído sobre todas los métodos ágiles que hay, programación extrema sería una metodología más centrada en la solución técnica que en la gestión de proyectos. Por eso es tan fácil combinarla con metodologías más enfocadas a la gestión de proyectos como SCRUM.

Respecto a la parte de coding, tenemos dos técnicas: Test Driven Development (TDD) e Integración continua.  Recordemos que hacer TDD es escribir las pruebas unitarias ANTES de escribir las clases que prueban. O sea que si utilizamos un servidor de integración continua y hacemos pruebas unitarias DESPUES de escribir las clases, no estaremos haciendo Programación Extrema.

El propio Ken Beck, en su libro Extreme Programming Explained, afirma que no hay en su metodología ninguna práctica revolucionaria, que sólo es la combinación de una serie de prácticas y su seguimiento de “manera extrema” (muy estricta).

Me queda la sensación de que “Programación extrema” fue una manera de llamar originariamente que a día de hoy está obsoleta y que se ha dividido en :

1. las “prácticas ágiles básicas” (iterativo, incremental, fortalecer la comunicación directa, pruebas unitarias, funcionales, etc.)
2. integración contínua
3. TDD

Si sigues los puntos 1 y 2, y haces pruebas unitarias después de escribir la clase, puedes estar siguiendo casi cualquier metodología ágil. Y si haces el punto 3, estarás haciendo Test Driven Development, que queda mucho más claro que decir “Programación extrema”.

¿Qué opináis vosotros? ¿Tiene cabida el término Programación Extrema?

• Convertirse en un lenguaje común por el que pasar especificaciones de programas entre programadores.
• A partir de los diagramas generados, “pulsar un botón” y generar el código de tu aplicación.
• A partir del código, “pulsar un botón” y generar la documentación de tu aplicación en UML.

Sin embargo, por mucho que indago me quedan las siguientes sensaciones:

• No existen herramientas eficaces que permitan generar código útil a partir de diagramas.
• Las que existen, se centran en el Modelo de dominio (que no es poco), pero desde luego no hay nada que coja un caso de uso, y lo convierta en código….
• Especificar lo suficiente un diagrama UML para poder generar código medianamente definido es un infierno. Da la sensación de que se tarda menos en programarlo.
• El UML puede servir para transmitir ideas informales entre programadores (esquemas rápidos) pero nunca servirán para transmitir esas ideas a un cliente profano en el tema. Y como la documentación para el cliente es totalmente inevitable, vale más la pena que los programadores se entiendan leyendo la documentación que también es para el cliente (SCRUM y su Product Backlog, por ejemplo).
• ¿Por qué a la gente le gusta tan poco codificar y tanto hacer dibujitos?

Y, por último, una serie de preguntas, a ver quién me arroja algo de luz:

• ¿En qué escenarios utilizáis UML? ¿Utilizáis UML?
• ¿Es un UML totalmente especificado o sólo un esquema?
• ¿Utilizáis alguna herramienta que genere código a partir de UML?
• ¿Y alguna de reverse engineering que a partir del código genere documentación?
• ¿Alguien utiliza RUP (Rationa Unified Process), que supuestamente es la metodología alrededor del UML, junto con UML?
• ¿Alguien combina UML con alguna metodología ágil como SCRUM? ¿Se puede ser ágil diagramando con UML?

Gracias adelantadas a el lector que se anime a comentar un poco el tema…

He encontrado pocos artículos que comenten ésta situación. El más interesante es éste.

¿Alguna experiencia con éste escenario? ¿Cómo lo solucionáis?

Si os preguntáis cómo puede utilizar las dos metodologías a la vez, como el mismo dice: “Scrum focuses on management and organization practices while XP focuses mostly on actual programming practices. “

Descargar el documento.