archivo

Archivos diarios: septiembre 13, 2012

Nuestro trabajo no es conseguir imposibles.

Trabajamos con un presupuesto y tiempo limitado, es decir, trabajamos con unas restricciones. Se pueden y se deben ajustar si es necesario pero teniendo en cuenta que el chicle no se puede estirar indefinidamente.

También es frecuente que en el desarrollo normal de un proyecto nos encontremos en un momento dado con más tareas que las que podemos llevar a cabo ya sea a título individual o a nivel de equipo de proyecto.

Esto nos lleva tanto a nivel general del proyecto como a nivel de un momento determinado del mismo a una priorización de las tareas. Para ello es necesario que el área usuaria decida con criterio qué es lo más importante (teniendo en cuenta que todo tiene un coste) hasta que la dinámica de trabajo esté consolidada considerarán que todo es importante, crítico y urgente y aunque así sea (que no lo es) no tendrán más remedio que hacerlo (a veces cuesta que lo entiendan pero mejor así que darles unas expectativas que no vamos a poder cumplir). Una buena estrategia para la asignación de prioridades es la asignación por parte del usuario de un grado de importancia a la tarea del cero en adelante (la menor importancia es el cero) y sin tener la posibilidad de repetir un valor.

Hay que tener en cuenta que si aplicamos un enfoque evolutivo en el desarrollo de software el usuario irá poco a poco dándole forma a la idea general que tenía en la cabeza, la importancia de empezar por lo más prioritario permite que no se invierta el tiempo en realizar tareas secundarias dependientes de otras primarias y que podrían ser desechadas o modificadas si cambia la principal.

En eso consiste desarrollar con intención.

La visión de este problema por parte de Ken Beck y Martin Fowler la reflejan en el libro “Planning Extreme Programming” y es la siguiente (traducción libre): “Cuando estás saturado, no lo veas como que no tienes suficiente tiempo sino como si tuvieras demasiadas cosas que hacer. No podemos conseguir más tiempo pero sí tenemos la posibilidad de hacer menos, al menos por el momento”.

¿En qué consiste anticiparse?, ¿es tener preparado todo lo necesario para cuando se produzca el cambio?. No hay respuesta general a eso pero sí diferentes reflexiones:

– No puedes prever todos los cambios que pueden producirse por lo que no puedes tener preparado todo lo necesario para todas las situaciones. Ten en cuenta que esos preparativos: planes de contingencia y de trabajo, ahorro de recursos, adaptación de la aplicación para lo que pueda venir, etc… son como tener carga en una mochila, a más peso más esfuerzo se necesita para continuar con el desarrollo hasta que se llega a un punto donde será necesario quitar carga de la misma para poder seguir.

– Hay cambios que sí son muy previsibles o muy probables y en esos casos sí que es posible o incluso recomendable que los trabajos que estemos realizando y los diferentes preparativos estén orientados a eso (si hay nubes negras y además los informes meteorológicos indican una alta probabilidad de lluvia no resulta razonable que salgas de casa sin paraguas y/o el chubasquero).

– Una gestión del riesgo eficaz deberá gestionar no solo los posibles problemas del proyecto, además deberá tener en cuenta las diferentes circunstancias conocidas que pueden provocar un cambio de contexto teniendo en cuenta que una cosa es inventariarlas y asignarle un perfil de riesgo y otra implementar las contramedidas algo que se deberá hacer en aquellos casos donde exista una alta probabilidad de ocurrencia (ya sea para adaptarnos cuando suceda o para evitarlo) y en donde exista un riesgo crítico para el proyecto (en este caso la definición y puesta en práctica de contramedidas deberá valorarse en función de diferentes factores: coste de las mismas, impacto real y probabilidad de que se produzca, etc…

– Hay prácticas que facilitan la adaptación al cambio (y que pueden ser suficientes en muchos casos) y que se amortizan desde el mismo momento en que se ponen en marcha: desarrollar software con una deuda técnica adecuada a las características del proyecto e intentar conseguir una cohesión entre los equipos de trabajo y dentro del equipo de desarrollo en los que además se fomente el hecho de que los proyectos no son necesariamente lineales ya que las condiciones iniciales pueden ser distinta de las finales.