El desarrollo de software son conversaciones (IV)

En los artículos anteriores de esta serie “El desarrollo de software son conversaciones” me he centrado en esa parte del proceso en la que fundamentalmente hablamos sobre el qué y no tanto sobre el cómo. Si haces Scrum, me refiero a todo lo que haces antes de la reunión de planificación del sprint. Si haces Kanban, seguramente llamarás upstream a toda esa parte del proceso de desarrollo. Esa misma metáfora nos lleva a hablar de “downstream” (ya trabajes por lotes o no) como a la parte del proceso que se dedica al trabajo que ya nos hemos comprometido a construir y desplegar. En este artículo empezaré a hablar de las conversaciones que tenemos en el downstream.

Para ello, voy a distinguir las siguientes fases:

  • Planificación
  • Construcción
  • Pruebas
  • Despliegue

Suena un poco waterfall, ¿verdad? En realidad, si no pensamos en lotes de trabajo sino en piezas de trabajo individuales, es más fácil ver que son simplemente las actividades por las que hacemos pasar cualquier desarrollo de software, por pequeño que éste sea. Para una simple historia de usuario necesitamos:

  • planificar el trabajo, es decir, decidir qué vamos a hacer y cómo,
  • luego construir aquellos artefactos que harán que los usuarios puedan cubrir sus necesidades,
  • asegurarnos de que la historia de usuario hace lo que se espera que haga, especialmente en conjunción con el resto del sistema, y
  • finalmente desplegarla para ponerla a disposición de los usuarios.

En el último artículo de la serie hablaré del feedback, es decir, de qué conversaciones provocan las reacciones que recibimos de los usuarios.

Dediquemos el artículo de hoy a la Planificación.

La reunión de planificación

Si trabajas por iteraciones (o sprints), seguramente harás una reunión al principio del ciclo. En Scrum la llaman Sprint Planning Meeting. Sin embargo, si haces Kanban, seguramente también harás algo parecido: el replenishment o reabastecimiento, es decir, la reunión en la que nos comprometemos con más trabajo (y rellenamos el tablero).

En realidad, en esta reunión se producen dos conversaciones bien diferentes: qué vamos a hacer y cómo lo vamos a hacer. Es muy frecuente que para responder a la una necesitemos responder también a la segunda, de ahí que tenga mucho sentido que las facilitemos como parte de la misma reunión. A mí me gusta ver esta reunión como la conclusión del Refinamiento. Llegados a este punto deberíamos tener muy claro, porque lo hemos ido hablando previamente, qué necesidad tratamos de cubrir para nuestros usuarios y apenas queda confirmarlo con un plan concreto de construcción.

Preparación de la reunión de planificación

Alguien (normalmente quien hace de Dueño de Producto) propone las historias que podrían formar parte de esa iteración y las anuncia para que todo el mundo haya tenido tiempo de echarles un vistazo antes.

Hay que tener en cuenta que el equipo ha refinado esas historias recientemente. Incluso esta reunión podría formar parte de una reunión de refinamiento. Si recuerdas del artículo anterior, yo comentaba que suele haber dos tipos de refinamiento y uno de ellos se enfoca en dejar las historias listas según el DoR (Definition of ready). Si el equipo discute sobre los detalles de la historia (p.ej. con un mockup o un wireframe en una pizarra), resulta bastante natural que a continuación se discuta sobre cómo se va a implementar e incluso se repartan tareas. Si éso quedara formalizado (en un tablero, por ejemplo), ya habríamos planificado el desarrollo de esa historia y no tendríamos que esperar a una reunión de planificación de la iteración.

Si trabajamos por lotes y además construimos un producto, soy partidario de establecer un objetivo para la iteración para tener un cierto foco. Si hemos hecho un User Story Map, es posible que coincida con una de las “lonchas” o versiones del plan, pero no es obligatorio.

Claro, como cualquier otra reunión eficaz, debería tener un inicio y duración conocidos por todos. Sin embargo, la frecuencia es discutible. Si trabajas por lotes, lo normal es que agendes la reunión con una frecuencia fija. Pero también puedes agendar la reunión cuando el inventario de historias comprometidas por el equipo haya llegado a un cierto límite mínimo. La foto que encabeza el artículo ilustra este concepto. Cuando se agota el inventario de piezas de la parte azul del contenedor, éste se debe girar para poner a disposición el inventario restante a la vez que señala que hay que reabastecerlo. Con una política como ésta, el equipo siempre tendrá historias listas de las que tirar y, además estarías aplicando una de las prácticas esenciales del método Kanban: tirar en vez de empujar. Este artículo sobre el reabastecimiento Kanban empleado en manufactura puede ser interesante para entender mejor este concepto del “Fixed Quantity, Variable Frequency”.

Durante la reunión

Como la lista de historias a revisar debería estar priorizada, podemos empezar por la primera y así hasta el final. Ojo, porque a veces intentamos planificarlas todas y corremos para cumplir con el requisito de haber hablado de ellas, pero realmente no las dejamos listas para la siguiente etapa o incluso ni hablamos de ellas. Mi consejo es planificar sólo aquellas historias de las que hayamos tenido una conversación suficiente y nos sintamos cómodos con ella. Si nos quedamos sin tiempo, siempre podemos agendar una reunión más tarde. Alargar la reunión o agendar una reunión maratoniana no es buena idea porque el resultado será mediocre. Recuerda a tu abuela: “Mejor poco pero bien que mucho pero mal”.

Si, sistemáticamente, nos quedamos sin tiempo para planificar todo lo que hemos pensado que sería planificable puede ser señal de que queremos hacer más trabajo del que somos capaces, pero en muchas ocasiones es algo tan simple como que las iteraciones son demasiado largas, lo que obliga a tener muchas conversaciones (hay que planificar mucho trabajo) y a tenerlas sobre temas que se comenzaron a hablar hace mucho tiempo y que ya muchos hemos olvidado, obligando a recordarlas y ocupando tiempo de la reunión con este retrabajo.

Otra causa por la que una conversación se puede atascar durante la planificación es que no hayamos tenido las conversaciones oportunas durante el Refinamiento. Por ejemplo, imagina que no hemos hablado de la hipótesis que tratamos de validar o refutar con una funcionalidad en concreto. Por tanto, tampoco habremos hablado de qué métricas (o KPIs) nos permitirán llegar a esa conclusión. Como consecuencia, en ningún momento consideraremos incluir nada en nuestro plan que nos permita hacer las mediciones correspondientes. Quizás nos encontremos con que hemos desarrollado una pieza de software que no nos permite llegar a ninguna conclusión para nuestra hipótesis. Claro, si hablamos de ese asunto hace meses o si forma parte de una épica muy muy grande, lo normal es que todas esas conversaciones hayan sido olvidadas por todos, si es que acaso han sido partícipes de ellas. No está de mal refrescarlas; como medida de precaución al menos.

Cuánto trabajo planificar

Es típico ver a equipos usando planning poker y otras técnicas de estimación para tratar de no comprometerse a más trabajo del que son capaces de realizar durante la iteración. Es una de las conversaciones que induce el trabajar por lotes. Un desperdicio necesario pues, durante esta conversación, el equipo entiende mejor cuál es la solución que mejor encaja para el problema en cuestión. Una discrepancia en la estimación del esfuerzo necesario para un trabajo es una conversación que mejorará el plan de trabajo. Personalmente trato de que los equipos con los que trabajo no estimen el trabajo con estos métodos sino que hagan pronósticos en base a métodos estadísticos.

Una manera de evitar este desperdicio es dejar de trabajar por lotes y buscar tener un flujo de trabajo constante, con el método Kanban, por ejemplo. En cualquier caso, tener una idea de a cuánto trabajo puede comprometerse el equipo es algo muy útil tanto si trabajas por lotes como si no. Para ello, Kanban propone una Service Delivery Review o de revisión de las políticas, en la que el equipo aprende de sí mismo a partir de diferentes métricas que explican cómo manejan el trabajo que realizan.

Trabajo no planificable

Si nos dedicamos al mantenimiento de un sistema o a dar soporte a otros equipos, suele ser más difícil planificar el trabajo, por lo que quizás habría que considerar aplicar Kanban en vez de trabajar por lotes o, al menos, una mezcla de trabajo planificado y no-planificable. En este caso, las conversaciones al inicio de la iteración son una mezcla de reabastecimiento y de revisión de las políticas. Por ejemplo, si estamos entregando poco trabajo planificado porque nos llega demasiado trabajo no-planificable, podemos revisar el número de peticiones no-planificadas que el equipo atenderá durante esa iteración. Como ese ejemplo seguro que podemos encontrar otros. La idea es, incluir en esa reunión de revisión de las políticas a todos aquellos que puedan verse afectados (stakeholders) y tener conversaciones que lleven a un acuerdo razonable para todos. Además, si somos transparentes con el uso de los datos y revisamos la eficacia de las medidas acordadas, seguro que conseguimos aumentar la confianza y mejorar la colaboración entre todos.

En la siguiente entrega hablaré de las conversaciones que suceden durante la Construcción. Espero que te esté gustando esta serie. Por favor, deja tu comentario ahí abajo.


Por cierto, antes de terminar me gustaria resaltar el enlace que puse sobre “upstream”, que seguramente pasará desapercibido para mucha gente. Se trata de un librito que acaba de publicar titulado “Essential Upstream Kanban”. Échale un vistazo y me comentas qué te ha parecido.