archivo

Archivos diarios: diciembre 5, 2011

Lo peor que tienen los errores es no aprender de ellos, no porque estés condenado a volver a repetirlo, sino porque esos golpes o mordiscos de realidad son los que permiten modular tus conocimientos, tus actitudes, tu enfoque, en general, tu forma de afrontar una situación personal o profesional.

Para aprender de un error es necesario reconocerlo y asumir las consecuencias del mismo. Es decir, si te equivocas, te has equivocado tú y no tienen por qué pagar terceros sus consecuencias.

Si se reconoce un error pero no se asume se está dejando de lado un aspecto que resulta importante tener presente siempre: Los errores no salen gratis.

Pero ya que no salen gratis saquémosles el mejor partido posible y aprendamos de ellos.

La mejora continua está asociada al feedback, es decir, a la capacidad de que una vez realizada una acción, un trabajo o una tarea se puedan analizar los resultados de la misma y aprender de ellos, sean buenos o malos.

Para mi, la segunda mayor aportación de los principios ágiles (la primera es considerar a las personas como eje del desarrollo de software) es darle al feedback el peso que le corresponde, acortando además, en lo posible, los períodos en que obtenemos ese conocimiento.

El feedback no es solo analizar cada iteración del producto desde el punto de vista del usuario (en busca de una mayor proximidad al umbral mínimo a partir del cual se cumplen sus expectativas) sino que se debe analizar desde todos los ángulos del proceso de desarrollo de software empezando por el mismo proceso y pasando por la comunicación entre los stakeholders, la priorización de las funcionalidades, la productividad del equipo de trabajo, los mecanismos de control de la calidad del software, el proceso de paso a producción, etc…

El desarrollo de software, sus proyectos, no son algo simple (aunque se deba tender siempre a la solución más simple que permita resolver un problema) y por tanto, sacar el máximo partido al feedback no lo es y tampoco todo es igual de prioritario, ya que si bien es importante optimizar el proceso de desarrollo, lo que realmente importa es que el producto esté cada vez más cerca de lo que el usuario final busca.

La planificación en los proyectos de desarrollo de software es un asunto controvertido, ya que por un lado las fechas están para cumplirlas pero por otro si situamos a las fechas como un fin del proyecto corremos el riesgo de perder el enfoque en lo más importante, que no es otra cosa que desarrollar un sistema que satisfaga las expectativas del usuario.

Hay que tener en cuenta que dentro de esas expectativas puede situarse que el producto esté en una fecha determinada porque fuera de ese umbral el mismo pierde o deja de tener sentido.

Son factores a tener en cuenta a la hora de calibrar el grado de flexibilidad o de rigidez de una planificación.

Sobre este aspecto Tom DeMarco y Tim Lister tienen la siguiente opinión (traducción libre): “Si no se cumple con la fecha de cumplimiento de un hito, la planificación estaba equivocada. No importa por qué no se ha cumplido con la fecha, ya que el propósito de establecer un calendario es planificar, no establecer objetivos”.

Se trata de una reflexión un tanto controvertida ya que habrá muchos que estéis de acuerdo y otros tantos que no. Y probablemente todos tengáis razón, ya que la importancia la define el proyecto y las expectativas del usuario y eso variará en cada caso.