Realizar el Product Backlog no fue algo especialmente complicado. No se trata de un proyecto especulativo con un “escenario siempre cambiante”, las user stories básicamente se sacaban de “lo que hace la vieja intranet que lo haga la nueva”. Por supuesto nada es tan sencillo (cada user story tiene que tener el tamaño adecuado, etc.), pero no me pararé aquí.

La priorización de las user stories se hizo pensando en la mejor forma de ponerlas en marcha. Aquí hay una cosa clave: la puesta en marcha no es “desplegarla en el servidor de producción”, sino que los usuarios realmente se pongan a utilizarla y cumplan sus necesidades. Son dos cosas muy distintas.

Una vez definidas la user stories y priorizadas, solo quedaba decidir la manera de ir poniéndolas en marcha. Aquí teníamos dos posibles filosofías para seguir:

• scrum: cada X semanas poner en producción una serie de user stories y que los usuarios comiencen a utilizarlas (desactivando la posibilidad de hacerlo en la intranet migrada).
• kanban: cada vez que una nueva user story es terminada (desarrollada, testeada, nosecuantizada…) ponerla en marcha.

Aquí entra el factor humano. Ir poniendo una a una las user stories en producción introducía mucho ruido en los usuarios (“ahora te quito un botón de aquí y te lo pongo allá”), así que comenzamos haciendo unos sprints de 3 semanas, con un periodo inicial de puesta en marcha del proyecto.

Aquí todo normal. El escenario es bastante favorable para la aplicación de métodos ágiles. Quizá la única característica algo molesta es que el presupuesto era fijo. Pero dado que el alcance también era fijo, no era uno de los principales caballos de batalla: se aplicó un “pos se tienen que poder” y punto. 

Bueno… ¿y qué es lo que los gurús nunca te cuentan sobre Kanban y SCRUM? Porque hasta ahora todo lo que he escrito es de manual.

Lo que los gurús nunca te cuentan es que para poder hacer todo esto necesitas tener un entorno de desarrollo EXCELENTE y un conocimiento TÉCNICO de ALTO NIVEL.

Detrás de tanta filosofada Lean hace falta que, a nivel técnico muchas cosas funcionen como un reloj:

1. si quieres poner en marcha nuevas funcionalidades en periodos cortos (primero igual lo haces cada tres semanas, pero luego te das cuenta de que quizá sea mejor cada dos… finalmente y cuando el proyecto ya va como un tiro… ambicionas hacer kanban) necesitas un buen sistema de integración contínua TOTALMENTE AUTOMATIZADO.
2. para automatizar algo, debes estar haciéndolo de manera manual. Si automatizas la ejecución de pruebas unitarias… pero no estabas haciendo pruebas unitarias… estarás automatizando la nada absoluta. A veces uno se pone como objetivo algo técnico “tener un hudson con un phing, que genere nosecuantas métricas inútiles y lo automatice toro toro toro”…
3. integración continua implica TDD (o al menos pruebas unitarias), que implican una MUY BUENA orientación a objetos, que implica un buen uso de patrones (sobre todo de inyección de dependencias) y un conocimiento bastante profundo de los frameworks que utilizas (tanto para pruebas como para desarrollar).
4. integración continua implica el uso de un repositorio de versiones (subversion, git, loquesea…). Pero no vale con hacer unos commits aquí y allá: seguramente vas a necesitar branches y los consiguientes merges. Y seguramente te van a surgir unos maravillosos conflictos que vas a tener que saber solucionar. El conocimiento de tu repositorio de versiones tiene que ser MUY BUENO.
5. integración continua implica la división entre el servidor de desarrollo (probablemente uno para cada programador), el de pruebas y el de producción. Lo cuál implica una MUY BUENA gestión de configuraciones y que tu aplicación sepa en cada momento si está en pruebas y debe coger la configuración de pruebas o cuál. Esto me remite al punto 1: si tienes un sistema totalmente AUTOMATIZADO de integración continua capaz de desplegar tu aplicación en el servidor de pruebas o en el de producción como si no costara, estás triunfando. En caso contrario, prepárate a perder el tiempo a base de bien.
6. integración continua implica desarrollo evolutivo del producto, lo cuál implica un MUY BUEN CLIENTE capaz de hacer piña contigo y que cuando los usuarios monten en cólera porque se sienten algo mareados al ver botones aparecer y desaparecer, al verse obligados a dar feedback, etc. esté contigo. También hace falta que tenga fe en que “la versión que hay ahora evolucionará para bien”. Si los puntos del 1 al 4 funcionan como un reloj, es posible que con el tiempo vayas ganando en credibilidad (porque al principio nadie te cree), sino prepárate para perder credibilidad hasta entre tus jefes….

O sea que necesitas un profundo conocimiento de la orientación a objetos, los patrones, las pruebas unitarias, subversion, hudson (y phing en mi caso), gestión de configuraciones, y un buen cliente. ¿Alguien da más?

A lo que voy es a que las metodologías ágiles sólo marcarán la diferencia cuando seas capaz de juntar la filosofía lean, con unas buenas prácticas de SCRUM o KANBAN y con una FORTÍSIMA CAPACIDAD TÉCNICA. Sin TÉCNICA no hay metodologías ágiles que valgan. Si cada iteración de dos semanas, tardas dos días en poner en marcha la nueva iteración, no vas a ningún lado. Tiene que ser algo AUTOMÁTICO y, para que sea automático, tiene que ser algo TÉCNICAMENTE MUY BUENO.

¿Pero entonces los métodos ágiles, la integración contínua, etc.. no valen la pena?
Valen la pena totalmente. Si te quieres a ti mismo como profesional hazlo, porque verás la luz y marcarás la diferencia.

¿Entonces primero debo ser un experto en todo eso que has dicho y luego ya me hago ágil?
No hay esa posibilidad. Intenta aplicar agilismo desde el principio en la manera en que te sea posible.

¿Entonces a dónde vas con este rant?
A que sepas que va a doler. Eso es lo que no te cuentan los gurús. Que el camino es doloroso. Podrás poner los medios para que el dolor se minimice. Vas a pasarte horas y horas pegándote con problemas técnicos porque eres incapaz de hacer un commit por un tree conflict, o porque hudson da un extrañísimo “segmentation error” a un comando de terminal que ejecutas (y que funciona de lujo en la propia terminal), y no te digo ya como te tomes Selenium en serio….

Dolerá aunque repito, vale la pena totalmente.

El Horno de las madalenas

¡pos se tiene que poder!

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…