¿Dos es más del doble? ¿Quién se atreve a probarlo?

Pongámonos en situación. Supongamos un grupo de dos desarrolladores que tienen que hacer dos tareas. Las tareas no tienen nada que ver la una con la otra, incluso son de proyectos distintos. Lo único que tienen en común es que tienen que estar para ayer, es decir, el tiempo para que estén acabadas es demasiado corto y es muy probable que se llegue por los pelos o no se llegue.

Ante esta situación tenemos dos soluciones:

  1. Solución tradicional, estándar, típica y la más habitual. Cada desarrollador se pone con una tarea y hasta donde lleguen. Esto da tranquilidad aparente, puesto que ambas tareas están haciéndose y se acabarán o no dependiendo de si los desarrolladores se acordaron de traerse el gorro de dormir a la empresa.
  2. Solución ágil, moderna y a la moda. Los dos desarrolladores se ponen juntos a hacer una de las tareas. Cuando la acaban, se ponen con la otra. Desde luego, parece muy arriesgado y a algún jefe se le pueden poner los pelos de punta – ¡¡ Pero !! ..  ¿cómo?¿no estais haciendo nada de la tarea B? –

Supuestamente la solución ágil es la correcta, pero eso sólo es cierto si dos desarrolladores trabajando juntos avanzan el doble de rápido que uno solo. Pero no queda ahí la cosa. Si la solución ágil es la correcta, es porque es mejor que la solución tradicional. Eso quiere decir que dos desarrolladores juntos deberían trabajar más del doble de rápido que si trabaja uno solo.

¿Y es esto cierto? ¿dos desarrolladores juntos trabajan más del doble de rápido que uno solo?. Si tú eres uno de los desarrolladores y es a tí al que van a caer los capones si las tareas no están acabadas a tiempo, ¿te atreverías a desarrollar una en conjunto con tu compañero y abandonar temporalmente la segunda? Y si tú eres el jefe de esos dos desarrolladores y es a tí al que caen los capones ¿les animarías a trabajar juntos en una tarea dejando abandonada temporalmente la otra? ¿Y a mitad del tiempo límite darías el tipo cuando tengas que decir -La tarea B no está porque ni siquiera la hemos empezado-?

Decisión difícil que requiere valor.

Esta entrada ha sido publicada en metodologías y etiquetada como , . Guarda el enlace permanente.

6 respuestas a ¿Dos es más del doble? ¿Quién se atreve a probarlo?

  1. blaxter dijo:

    Una forma similar pero no tan radical son las code reviews, aunque para eso influye bastante que el equipo tenga ganas y aporte comentarios constructivos en las revisiones de código del resto.

    El programar en parejas, en mi opinión, influye principalmente en que es menos probable que salgan bugs (siempre se ha dicho que 4 ojos ven más que 2), por lo que a la larga si que será más rentable. Aunque nunca lo he probado, así que son solo conjeturas.

  2. DaniP dijo:

    Estoy de acuerdo con «Blaxter», desde el punto de vista de qué es ser «mejor» y qué es «terminar una tarea».
    Si terminar una tarea es que compile y que parezca que funciona, sin dudar un programador a cada tarea. Esto es lo habitual ya que es muy difícil tener métricas que indiquen cuándo se ha terminado una tarea de programación (en la construcción, todos sabemos cuándo se ha terminado de hacer una fachada o un edificio).
    Un artículo interesante con el que se puede estar más o menos de acuerdo sería del a veces polémico Ricardo Gallir:
    http://gallir.wordpress.com/2009/07/20/%c2%bfingenieria-del-software-ahora-vienen-los-mea-culpa/

    Personalmente, creo que la raíz de la mayoría de los problemas que tenemos en el mundillo de la programación están relacionados con la imposibilidad de cuantificar las cosas, ya que al ser tan difícil decir si algo está bien hecho o no, es muy difícil «vender» según qué metodologías, ya que poner a 2 personas en 1 sola tarea en lugar de 1 a cada cosa, realmente a muy pocos jefes les convence…

    Saludos

  3. Chuidiang dijo:

    Hola:

    Para poder comparar, pongámonos en igualdad de condiciones. Acabar significa en ambos casos lo mismo, dejar las tareas igual de bien hechas. Mejor es acabar antes, ya que en ambos casos las tareas van a estar igual de bien hechas.

    Si dos trabajan en pareja, trabajan más (posiblemente hagan menos descansos o se distraigan menos mirando el correo o internet) y hacen mejor código desde el principio (cuatro ojos ven más que dos), por lo que perderán menos tiempo depurando después. Pero, eso que ganamos, ¿es más del doble?

    Trabajando juntos: tarea 1 lleva 3 días, tarea 2 lleva 3 días, total 6.

    Trabajando separados y dejando todo igual que en el caso anterior, tarea 1 programador 1 debe llevar 6 días y tareas 2 programador 2 otros 6 días como mínimo para que la cosa compense.

    ¿Hacen dos programadores las cosas más del doble de rápido que uno solo?

    Esa es la cuestión.

    Sed buenos.

  4. atreyu dijo:

    Mmm no creo que se pueda responder de forma taxativa ya que hay que tener en cuenta no solo aspectos tecnicos (hay desarrollos que se ajustan mas al trabajo en comun que otros) sino sicologicos, o sea la forma de ser y la relacion de los implicados asi como sus conocimientos..si son complementarios o si tienen el mismo nivel de conocimientos para desarrolllar una comunicacion «agil».
    Yo creo que si los conocimientos de ambos se complementan y tienen la suficiente base comun y «feeling» entre ambos como para comunicarse de forma rapida la forma clasica hace que se multiplique la productividad.
    Y la forma clasica es que cada uno se encargue de lo suyo y solo cuando haya un «atasco» ambos aunen esfuerzos para avanzar.

  5. gux dijo:

    Voy a proponerte otro punto de vista:

    si le das una tarea a cada uno lo mas seguro es que ninguna de ellas llegue a tiempo, o lo haga de milagro: resultado mas probable -> nada a tiempo.

    si le das una tarea a los dos y cuando acaben les das la otra, la primera tarea va a acabar a timepo practicamente seguro, y la segunda seria un milagro que acabase a tiempo: resultado mas probable -> una tarea a tiempo.

    Con esos datos en la mano, es bastante probable que el jefe elija la segunda opcion, no creeis?

  6. jacampano dijo:

    Como indica gux en el comentario #5, la razón es porque es más probable que al realizar cada uno una tarea, no se complete a tiempo ninguna. Es preferible destinar ambos recursos a la tarea A, completarla y comenzar con la tarea B hasta donde llegue, que tener ambas tareas al 90% (sin completar y por dar un porcentaje).

    Además, los desarrolladores están implicados en ambas tareas, no se especializan en una parte de la aplicación, otra razón más.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.