¿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.