He leído en dosideas un artículo sobre cómo trabajar en paralelo de verdad. En él menciona dos posibles formas de trabajo. Una, que llamaré de ahora en adelante "trabajo en paralelo", consiste en dar a cada desarrollador una de las funcionalidades del sistema. Cada desarrollador trabaja en su funcionalidad. La otra, que llamaré "trabajo conjunto", consiste en que todos los desarrolladores trabajan conjuntamente en la misma funcionalidad hasta que se considera acabada. Luego, todos juntos, pasan a la siguiente.
En el trabajo en paralelo, aparentemente se va avanzando mas. Cada desarrollador hace una funcionalidad y cuando llega el hito de entrega, todas las funcionalidades están acabadas o casi. La pega que menciona en el artículo es que los desarrolladores, según se acercan al hito, empezarán a correr y hacer chapuzas en su código para llegar a tiempo. Nos podemos encontrar con que ninguna funcionalidad llega al hito totalmente acabada y posiblemente todas con muchos errores.
En el trabajo conjunto, al trabajar todos los desarrolladores en la misma funcionalidad, posiblemente esa primera funcionalidad se acabe mucho antes del hito y se acabe bien. La segunda también y así sucesivamente. Es posible que la última funcionalidad que se haga justo antes del hito sea un poco chapucera y también es posible que haya funcionalidades enteras que no estén.
Es interesante ver las imágenes del enlace anterior para ver ambas formas de trabajo.
Aparte del artículo en sí, yo tenía muchas dudas sobre la utilidad de algunas de las prácticas de las metodologías ágiles, sobre todo las de los desarrolladores comunicándose entre sí con mucha frecuencia. Comento a modo de ejemplo algunas de las dudas que tenía y cómo la lectura de este artículo me ha hecho ver la luz o, al menos, replantearme mis puntos de vista.
Por un lado, tenía mis dudas sobre las reuniones diarias de desarrolladores en Scrum. Si seguimos un "trabajo en paralelo" que, desgraciadamente, suele ser lo habitual en los desarrollos tradicionales, estos quince minutos de reunión diaria no son más que una cosa totalmente informativa. Si yo estoy con mi funcionalidad A, puedo tener curiosidad por ver cómo va Fulanito con su funcionalidad B, pero desde luego, no me va la vida en ello. Si hacemos "trabajo conjunto", estas reuniones cobran todo su sentido. Las tareas que tenemos dependen estrechamente unas de otras y Fulanito puede tener interés en ver cómo va mi tarea y yo puedo querer saber cuándo voy a poder usar la suya.
También con Scrum, había otro problema con las entregas cada quince días. Si cada desarrollador hace su funcionalidad, ¿qué hacemos con el desarrollador que acaba antes de tiempo la suya?. Puede ponerse a ayudar a otro, pero ya sabemos que en las cercanías de un hito poner más desarrolladores entorpece más que ayuda. Tendría que perder parte de mi escaso tiempo explicándole a Fulanito de qué va mi funcionalidad, por dónde voy y cómo puede ayudarme. Con el "trabajo conjunto", siempre puede quedar una tarea que todavía no se ha abordado, se puede echar una mano a otro desarrollador en una tarea cercana a la tarea que yo he hecho, ya que están relacionadas, se puede ir probando la integración de todas esas tareas, etc.
Con la programación extrema y en concreto, la programación en parejas, pasa algo parecido. En un "trabajo en paralelo" implica dos desarrolladores por funcionalidad. Si las parejas deben cambiar con frecuencia, quiere decir que uno de ellos tiene un cambio de contexto muy grande, ya que cambia de funcionalidad además de compañero. Si además, dentro de una funcionalidad no mantenemos a uno de los desarrolladores todo el tiempo, la siguiente pareja se encontrará una funcionalidad a medias que además les resulta nueva y no saben qué estaban haciendo los anteriores. Si usamos el "trabajo conjunto", nuevamente la programación en parejas empieza a tener sentido. Las parejas pueden cambiar con frecuencia, ya que las tareas se suponen son de más corto tiempo y están todas relacionadas. Al cambiar la pareja, al menos la funcionalidad les suena a todos, aunque empiecen a trabajar en trozos de código distinto.
En conclusión, el artículo me ha despejado muchas de las dudas (por no decir pegas) que tenía sobre las metodologías ágiles y me parece imprescindible el "trabajo conjunto" para llevar a buen puerto una metodología ágil. El "trabajo conjunto" tiene además la ventaja de que hace que realmente la gente se vea cómo un equipo, ya que trabajan codo con codo en lo mismo. El "trabajo paralelo" sí, todos los desarrolladores trabajan en el mismo proyecto, pero todos pueden ir a su bola aislados de los demás, salvo en pequeños puntos concretos. No hay con ello sensación de equipo de trabajo.
Y ya para finalizar, una pequeña pega que veo al "trabajo conjunto" basada en mi experiencia. Cuando varios desarrolladores trabajan en una misma funcionalidad, lo más posible es que acabada esa funcionalidad se quede huérfana. Si una vez acabada y los desarrolladores han pasado a otra cosa (los no fracasados ya ni siquiera codifican: son jefes de algo), salen algunas incidencias, es muy posible que ningún desarrollador de los que quede y que está liado en otra cosa quiera hacerse responsable de esa incidencia, o empiecen a pasársela unos a otros. En un "trabajo en paralelo", esto no es tan fácil. Si una funcionalidad tiene una incidencia, está claro quien es el responsable. Como digo, lo digo por experiencia. En nuestros proyectos de larga duración tenemos muchas incidencias huérfanas, que en bugzilla van cambiando de dueño todos los días de propietario, ya que unos se la pasan a otros.