archivo

Archivos diarios: abril 13, 2012

En un desarrollo de software se puede estar construyendo muros de defensa o apostar por la realización del producto. Prefiero lo segundo sobre lo primero.

No se trata de desarrollar sin tomar ciertas precauciones como por ejemplo que las diferentes iteraciones que se realicen estén validadas explícitamente por el responsable funcional del sistema, sino de llevar esas precauciones más allá, teniendo cada paso condicionado por las mismas y provocando un overhead de gestión que genera una resistencia fuerte a la aplicación de un enfoque ágil.

A lo anterior hay que sumar que si un equipo trabaja en un ambiente de gestión defensiva terminará adoptando esa misma actitud, no solo hacia el cliente o al usuario sino muy probablemente en su funcionamiento interno (los mantras son muy poderosos).

Por otra parte, los que aplican una gestión defensiva no generan mucha confianza ya que siempre se da la impresión de que estás trabajando con alguien que juega con dos juegos de cartas y no sabes si además, esconde algo en la bota que lo mismo termina en tu espalda.

Hace poco hice unas reflexiones sobre una cita de Olin Shivers en la que venía a expresar mi opinión de que la automatización de tareas o funciones en los sistemas de información debía medirse dentro de los parámetros coste/beneficio y dentro de los recursos existentes en el proyecto.

Jef Raskin tiene también una cita que puede parecer similar a la de Olin Shivers, pero que tiene un importante matiz a tener en cuenta: “Un ordenador no debería hacerte perder el tiempo o requerirte más trabajo que el estrictamente necesario”.

El matiz principal es “el estrictamente necesario” y tiene una orientación tanto hacia el usuario como hacia el desarrollador o la tecnología:

– Hacia el usuario: No se trata de automatizar todo lo automatizable sino de orientar las funcionalidades desarrolladas a mejorar en lo posible la productividad del usuario.

– Hacia el desarrollador o la tecnología: Se trata de dar la mejor solución posible dentro de las restricciones existentes en el momento (presupuesto, contexto, avances tecnológicos, etc…).

En cualquier caso, esta cita, como el trabajo en general de Raskin está orientado a que las TIC, los ordenadores y las aplicaciones deben prestar un servicio al usuario el cual no se entiende si la experiencia de usuario o la productividad en el uso del producto no es adecuada.

¿Sabrías de una manera objetiva indicarme la capacidad de producción de una persona de tu equipo o de algunos de tus equipos en base a algún tipo de unidad de medida (como por ejemplo, puntos de historia de usuario)?

Si no lo sabes, ¿no entiendes que existe mucho riesgo de incumplimiento de las tareas planificadas?.

Un gestor que no dirija los equipos a años luz (son menos de los que pensamos) sabe quién es más productivo y menos, tanto a nivel individual como en equipos de trabajo y considera eso como suficiente a la hora de gestionar y planificar, pero, ¿realmente es suficiente? A tenor de lo que se suele fallar en las estimaciones, parece que no.

¿Es fácil obtener una métrica objetiva?. Si la métrica se refiere a un proyecto concreto existen estrategias que permitirían obtener su valor, como por ejemplo, media por iteración o valor de la última iteración, si nos referimos en términos generales es más complicado ya que habría que armonizar los mecanismos de medición, lo que obligaría a tener como objetivo a nivel de organización la posibilidad de conocer con un umbral de error concreto la capacidad de producción individual y colectiva (hay personas que funcionan muy bien trabajando en equipo y otras que no, a lo que hay que sumar también que la capacidad de producción variará también de las personas con las que trabajes).

¿Teniendo una métrica objetiva me asegura no equivocarme? Si fuera tan sencillo todo sería maravilloso ya que si un proyecto fracasa será por otros factores no por el hecho de haber estimado y planificado de forma incorrecta. La realidad es que habría que tener un proceso muy maduro en la organización para reducir el umbral de riesgo, sin embargo a nivel de proyecto, si se divide en piezas más pequeñas y se aplica un enfoque iterativo incremental, seremos capaces a las pocas iteraciones de conocer la capacidad real del equipo.

Que sea algo difícil o si queréis en determinados contextos organizativos casi una quimera, no quiere decir que debamos renunciar a medir y a obtener información que permita conocer la capacidad de producción y no solo porque permita planificar mejor, sino porque a nivel organizativo, conocer si se mejora o se empeora la capacidad de producción global puede resultar muy importante.