¿Para gestionar un equipo que trabaja bajo TDD se puede añadir una columna de "refactorización" en el tablero Kanban?

Ciclo TDD

Como sabréis Test-Driven Development (TDD), una técnica de XP, se basa en la programación orientada a objetos en que se escriben las pruebas unitarias primero y se codifica después, siendo guiada la codificación por estas pruebas. El ciclo de codificación acaba cuando el código pasa todas las pruebas. Finalmente se refactoriza el código escrito para lograr un código limpio y homogéneo que funcione.

Usualmente se incluye la refactorización dentro de la programación, el que efectúa las pruebas unitarias al fin y al cabo es el programador, por tanto cuando este acaba con la codificación puede dedicarse a la refactorización para terminar la tarea. Incluir una columna de refactorización en nuestro tablero implica que se va a refactorizar cada tarea recién programada en otra etapa y esto a primera vista parece una "muda", un desperdicio.

Kanban lo que hace es gestionar flujos de trabajo, sea el que sea, por tanto una columna de refactorización puede perfectamente ser necesaria. Imaginémonos una empresa como Microsoft, que aún trabaje de forma distribuida con factorías en la India, y que cada tarea que reciba la refactoriza en la central para asegurarse que el código sigue los patrones establecidos y es homogéneo con el resto del software.

La cuestión clave a preguntarse es ¿la refactorización nos aporta valor?

¿Scrum al tratar equipos multifuncionales no requiere de especialistas?

Especialista contándoles de su especialidad
a sus compañeros de equipo

De entrada decir que no se debe de confundir equipo con persona, un especialista es una persona con conocimientos y habilidades en un determinado campo, y un equipo multifuncional es un equipo integrado por personas cuya suma de conocimientos y habilidades cubre todas las necesidades que requiere el desarrollo del producto: el equipo es quién ha de saber construir el producto, no las personas.

Más allá de esta distinción, Scrum requiere actitud además de aptitud, miembros especialistas y a la vez interesados en lo que les rodea. Entre los miembros del equipo puede haber especialistas, incluso puede ser que el proyecto requiera de especialistas muy concretos y de forma puntual. En un equipo ágil todo miembro puede en algún momento hacer cualquier tipo de tarea, sea su especialidad o no. Gracias a la autogestión es muy probable que una tarea determinada la haga quien tenga más habilidad o facilidad para ella, en este caso el especialista encuentra fácilmente su tarea, pero en situaciones de sobrecarga, el especialista debe de estar abierto a formar a un compañero para que le eche una mano, y de la misma manera, si no hay tareas de su especialidad, dedicarse a otras tareas que puedan no ser de su gusto, pero absolutamente necesarias para el sprint. Recordemos que el objetivo del sprint es un objetivo común del equipo.

De esta manera la transmisión de conocimiento se da a todos los niveles, no solo funcional sino también técnica y por tanto de especialidades. Recordar también que la multifuncionalidad del equipo permite responder a fluctuaciones en el flujo y resolver bloqueos y dependencias de una estructura horizontal como la que se crea con los departamentos (definición, desarrollo, sistemas, QA).

Una nota para los que contratéis a técnicos: la actitud es difícilmente reconducible, una persona inadecuada puede romper un equipo, la solución es crear un ambiente propicio para el cambio y si este no se produjera hay que plantearse reemplazar a la persona. En cambio la aptitud es mucho más fácil de tratar, se soluciona con simple formación, con un curso especializado.

¿De dónde viene la iniciativa de implantación de Scrum en las empresas?

A lo largo de los diferentes cursos de este año he ido preguntado, a aquellos alumnos que en su presentación mencionaban que en su empresa utilizaban Scrum, como había entrado Scrum en su empresa.

He identificado 4 vías:

Distribución de las vías de entrada de Scrum

1. Visión desde gerencia (proactive leadership): en algunos casos la implantación de Scrum forma parte de la estrategia empresarial, son los menos, pero es significativo que ya haya empresas en que la Agilidad forme parte de su naturaleza.
2. Control de una situación complicada (burning platform): en estos casos Scrum se implantó en empresas para intentar dar solución a situaciones de descontrol en la ejecución y gestión de proyectos, suelen haberse desviado en horas y haber entrado en una espiral de modificaciones constante para intentar enderezar la situación.
3. Condición del cliente: en estos casos, y cada vez más, la implementación de Scrum viene ¡como método a aplicar al proyecto solicitada por el propio cliente! Este caso está en alza, se están impartiendo cursos de Agilidad en grandes consultoras para dar cobertura a proyectos en que el cliente demanda Agilidad. Nuestros clientes necesitan ser competitivos y sobrevivir en un mercado extremadamente complejo, y son conscientes de que el producto que les hará florecer se define a medida que aprendan del mercado.
4. Prácticas desde el equipo: en muchos casos es el propio equipo el que introduce prácticas ágiles en la empresa. Es un camino arduo, ya que el proceso para convencer a la gerencia de la empresa y al cliente es lento, aunque en los casos que me han contado, siempre ha sido exitoso.

Sin duda la vía más significante es la en que el cliente solicita Agilidad, a un nivel abstracto hasta se puede hacer un paralelismo con la manufactura lean, el cliente está estirando "pull"... por tanto es el mercado el que está demandando métodos ágiles. Pienso que la crisis tiene que ver, es época de vacas flacas en la que hay que maximizar el presupuesto disponible, buscar alternativas e innovar.

¿El Propietario del Producto ha de participar en la reunión de scrum diario?

No, no es necesario que el Propietario del Producto asista al scrum diario, es una reunión propia del equipo de trabajo, en la reunión de planificación de sprint ya ha expuesto todo lo que compone la pila de sprint al detalle necesario, y no es hasta la reunión de revisión de sprint donde debe de formar parte de nuevo.

Reunión de scrum diario

Los casos en que el Propietario del Producto asiste suelen ser cuando el cliente es interno, de un departamento de la empresa, o un jefe de proyecto que representa un cliente y actúa como Propietario del Producto. En todo caso el Propietario del Producto asiste en calidad de interesado, sin voz ni voto.

Hay casos en que la asistencia del Propietario del Producto es muy positiva, puede resolver dudas del equipo y por experiencias de alguno de mis alumnos, sé de un caso en que fue muy motivante para el equipo que el Propietario del Producto los mantenga al día de las actividades comerciales relativas al proyecto y al cliente y de cómo se mueve el mercado del producto que están desarrollando.

En uno de los equipos que acompañé recientemente el Propietario del Producto venía a los scrums diarios sin interferir, y después de la reunión se quedaba un rato más mientras el equipo le enseñaba como iban avanzando con el producto, mostrando lo que estaban haciendo en un ordenador de desarrollo. No hace falta mencionar que ese proyecto fue un gran éxito, el éxito depende en gran medida de liderazgo desde el punto de vista del producto del Propietario del Producto.

Pero el Propietario del Producto que asiste debe de estar alineado con la mentalidad ágil, podría ser contraproducente que asistiera, ya que pudiera estar tentado a influir en el equipo, rompiendo la autogestión, la autoorganización, y por ende el compromiso.

¿Son más exitosos los proyectos ágiles o los tradicionales?

Uno de mis alumnos mencionó un post de Mike Cohn respecto a este tema que me pareció interesantísimo y que traduzco a continuación.

De acuerdo con el CHAOS Report de 2011 del Standish Group, los proyectos ágiles son tres veces más exitosos que los proyectos no ágiles. El informe llega tan lejos como para decir: "Los métodos ágiles son el remedio universal para el fracaso de proyectos de desarrollo de software. Las aplicaciones de software desarrolladas con métodos ágiles tienen una tasa de tres veces más éxito que cuando se aplica metodología tradicional en cascada, así como un porcentaje mucho menor en las desviaciones por exceso de tiempo y costes" (página 25).

The Standish Group define el éxito de un proyecto como entregado a tiempo, dentro del presupuesto, y con todos los requisitos y funcionalidades planificadas desarrolladas. No informa en cuántos proyectos se ha basado, pero dice que los resultados son de proyectos llevados a cabo entre 2002 y 2010. El siguiente gráfico muestra los resultados específicos reportados:

Agile Succeeds Three Times More Often Than Waterfall

¿Cómo asignar las tareas de la pila de sprint?

Decidiendo que tarea autoasignarse

Las tareas se autoasignan por el equipo o sus miembros en cada reunión de scrum diario, concretamente ocurre cuando cada miembro dice lo que va a hacer para el día siguiente. De esta forma cada miembro toma las tareas que le corresponden según su motivación, sus habilidades o su especialidad, y permite desarrollar el talento de cada persona y encontrar su lugar en el equipo.

La autoasignación también contempla que para tareas concretas, el equipo en su conjunto, decida asignar la tarea a un miembro o grupo de miembros en particular. Por ejemplo, en caso de urgencia asignarle la tarea a un experto para que la resuelva cuanto antes, o en caso de que no haya ninguna criticidad o haya tiempo, asignársela al menos experto, quizá guiado por un experto, con el fin de que el primero ruede y adquiera conocimiento (un buen nivel know-how hace, entre otras, equipos ganadores).

Cuando nos autoasignamos las tareas ante los demás miembros establecemos la conexión con los demás miembros, después del scrum diario todos sabemos lo que hacen los demás con lo que se fomentan entre otras la colaboración, la difusión y transferencia del conocimiento, el ayudar a un compañero que está en un cuello de botella y el no hacer las mismas cosas dos y más veces.

¿Cómo gestionar un bug que se ha detectado en la fase de pruebas usando un tablero Kanban con incremento continuo?

Los bugs forman parte del software

En Scrum simplemente se incorporaría el bug a la pila del producto, probablemente para tratarlo en el siguiente sprint. El caso de Kanban, gestionando incremento continuo y regulado por límites WIP, es distinto.

Dependiendo de la crititicidad del bug, este entraría en el backlog o pila de entrada del tablero, o, en caso de existir, en el carril "expedite".

La solución ideal es que bugs críticos entren en un carril de nado especial para elementos urgentes denominado "expedite", este tiene la característica de aumentar el límite WIP de todas las columnas de estado, usualmente en un +1. En cuanto un miembro del equipo queda libre se pone a trabajar en el bug, este tiene carril prioridad sobre las demás tareas. Adicionalmente se puede relacionar el bug con la tarea/historia/petición que lo ha puesto sobre la mesa.

Tablero Kanban con carril expedite y visualización de la petición que lo ha detectado

Si se tratara de un bug no crítico o no tuviéramos carril "expedite", este debería de entrar como tarea en la columna "in process" si el WIP de esta lo permitiese, sino en la columna de "backlog", y si el WIP de "backlog" tampoco lo permitiese consideraría aplazar la corrección del bug para más adelante, o sacar una tarea del backlog para colocar esta. Sería un error dejar el bug en "testing", no le corresponde ya, o ponerla en la columna "in process" o "backlog" cuando el WIP no lo permite, rompería el flujo de trabajo que trata de regular el tablero, estando este perfectamente regulado podrían aparecer de nuevo cuellos de botella y tiempos muertos.