archivo

Archivos diarios: abril 20, 2013

Es muy interesante tener en cuenta a la hora de realizar cualquier tipo de estimación lo que enuncia la Ley de Hofstadter (Douglas Hofstadter): “Siempre se tarda más de lo esperado, incluso cuando tienes en cuenta la Ley de Hofstadter”.

Las estimaciones suelen ser demasiado optimistas incluso en aquellos casos en los que no se cuenta con suficiente conocimiento como para hacerla y/o en aquellos casos donde el tamaño de la historia de usuario, requisito o tarea que se estima es demasiado grande.

Además de la posible falta de información, de la incertidumbre de la tarea o de su complejidad, uno de los principales problemas suele ser también que se suele estimar considerando situaciones ideales: que no nos vamos a encontrar con ningún problema en esta o en otra que impliquen un mayor esfuerzo que el esperado, que la capacidad de trabajo por parte del equipo va a estar disponible tal y como estaba previsto, etc…

¿Se debe creer en las estimaciones? La respuesta es que depende. Si es sobre un conjunto de trabajo moderado, la estimación solo debe ser considerada como una referencia, pero nada más. Tienes la opción de creerla y en base a ella gestionar el triángulo de hierro, más adelante te darás cuenta de que tendrás que renunciar a uno o más de los vértices del mismo: alcance, coste o plazos y/o reducir la calidad final del producto.

Pero incluso en tareas pequeñas, la estimación puede fallar de manera sensible y ponerte en un serio problema a la hora de satisfacer los compromisos del sprint. Una mala estimación siempre hace daño.

Debemos partir de la base de que no es fácil estimar, pero resulta necesario si se quieren definir unos compromisos en un margen de tiempo determinado. Esto hace que se deba mejorar de manera continua los procesos de estimación: reduciendo el alcance de lo que se estima, implicando a maś personas en las mismas, principalmente a los desarrolladores, ya que van a ser ellos los que se enfrentan después a su realización.

Los procesos dan un orden, armonizan actuaciones. Sobre esta base no podemos decir que, en esencia, sean perjudiciales. De hecho pese a que he pasado del amor al desamor con respecto a ellos siempre comento que siguen siendo necesarios pero como background en el que tengan un núcleo mínimo, que sean flexibles y admitan excepciones justificadas.

Cuando se cree que el éxito está tras los procesos es cuando se cae en el error. De ser cierto que aseguran el éxito bastaría con seguir su receta para conseguir desarrollar productos software que satisfagan las expectativas de los usuarios. ¿Alguien cree que si fuera así de fácil existiría hoy día la crisis del software?.

No niego que determinados procesos puedan ser efectivos en condiciones muy específicas pero no creo que en procesos que se consideran martillos de oro o solucionadores universales para todo tipo de desarrollos en todo tipo de contextos.

Cuando un proceso no funciona (en enfoques de desarrollo de software dirigidos por procesos) siempre se le suele echar la culpa al desarrollador: “el proyecto ha ido mal porque no has seguido bien el proceso o porque no se han ejecutado adecuadamente los hitos” o a que el proceso no está lo suficientemente desarrollado lo que da lugar a que se entre en un mayor nivel de detalle y se convierta en una solución más rígida que, por supuesto, funcionará igual de mal o peor (que es lo más posible) que la versión anterior.

La mayoría de los procesos son ad-hoc, lo cual en sí no es malo ni bueno (generalmente las implementaciones de metodologías ágiles suelen ser ad-hoc) pero sí que se debe ser prudente por parte de quien o quienes lo han hecho de considerarlo soluciones universales por mucho que sean el resultado (o se venda así) de años de feedback en proyectos reales.

¿Por qué lo digo? Pues porque la mayoría nos hemos encontrado con las siguientes situaciones: Proyectos que han salido adelante cuando no se ha seguido a rajatabla un proceso que provocaba bloqueos y resistencia y proyectos que han fracasado o que no han tenido el éxito esperado precisamente por seguir procesos rígidos que no se adaptaban a la realidad de los mismos.

Es cierto que no es justo echarle toda la culpa a los procesos cuando algo sale mal (no podemos escondernos tras ellos) pero sí que es verdad que si te exigen trabajar de una manera y no existe flexibilidad tu margen de maniobra queda reducido y se trabaja mucho peor que si tuvieras los pies y las manos liberados.