archivo

Archivos diarios: febrero 1, 2013

Queda poco tiempo para la entrega de un sprint y detectamos que no vamos a llegar al cumplimiento de los compromisos definidos en el mismo. Esta iteración es importante porque existe el compromiso de pasar a producción una serie de funcionalidades que la organización, el cliente o el área usuaria necesita.

¿Qué se puede hacer?

Supongamos que nos encontramos viajando en un helicóptero y el piloto nos dice que se está quedando sin combustible y que tenemos que realizar un aterrizaje forzoso porque de lo contrario caeremos al mar.

Una primera solución puede ser aligerar la carga, arrojando al exterior todo aquello que sea prescindible (en función de lo crítica que sea la falta de combustible será mayor o menor el número de enseres prescindibles que podamos conservar).

El piloto nos podrá decir si con los kilos arrojados es suficiente o no. Tal vez nos diga que podemos arriesgarnos un poco más y que dentro de poco nos comentará si tenemos que continuar arrojando carga o si tenemos que hacer el aterrizaje de emergencia.

Y efectivamente, el piloto nos dice que tenemos que seguir vaciando el helicóptero, pero resulta que ya solo queda lo esencial, las personas, ya no queda más prescindible que poder tirar. En ese momento tenemos la idea de llamar al destino a ver si es posible aterrizar lo más cerca posible de la playa, aunque eso implique contravenir determinadas normas, quién tiene que autorizar o no el aterrizaje tendrá que analizar si es más importante la norma o tratar por todos los medios que el helicóptero llegue (siempre y cuando no genere un riesgo mayor).

Al igual que antes, el piloto podrá tomar la decisión de arriesgar un poco más o indicar que sigue sin ser suficiente. Supongamos que decide continuar y que llegado el momento vuelve a decir que no cree que podamos llegar al destino y que o tomamos la decisión de hacer un aterrizaje de emergencia en otro islote o ya sería demasiado tarde.

Ya solo queda prescindir de lo esencial y ese no es el camino salvo que algunos de los pasajeros decida que para salvar al resto y cumplir el objetivo ellos tratarán de llegar a la orilla del otro islote a nado.

Y se repetirá la situación anterior y cuando no ya no hay más posibilidades y ya no se puede esperar más, solo quedará dos opciones arrojar la toalla y aterrizar en el islote o arriesgar y tratar de llegar al destino. Mi recomendación es hacer el aterrizaje de emergencia en el islote.

La clave de toda esta metáfora es la existencia de funcionalidades esenciales que si no llegan completas o con un funcionamiento adecuado a producción puede provocar situaciones críticas para el proceso de negocio que se informatiza. Yo soy partidario de completar los sprints y hasta donde llegue se llegó, pero en este tipo de circunstancias, en las que todas las contramedidas adoptadas no terminan de dar con la solución, ese camino no vale y solo queda retrasar la entrega (aterrizar de emergencia).

Planificar a largo plazo puede ser esfuerzo invertido en vano. Sí que me parece interesante tener marcados objetivos e hitos, pero no me lo parece tanto, tener un nivel de detalle importante más allá de lo que se considere el corto/medio plazo (que sea uno u otro dependerá del nivel de incertidumbre que exista).

Es importante saber y poder reaccionar ante el cambio y no cerrarnos en un guión preestablecido ya que la película es otra.

Para Peter Drucker: “Tratar de predecir el futuro es como intentar conducir de noche por un camino rural con las luces apagadas mientras miras por la ventana de atrás”.

Una planificación detallada a largo plazo pretende dar una sensación de control: “si doy todos estos pasos conseguiré los objetivos”, pero en realidad es una falsa sensación de control porque para empezar no sabes si tu plan es bueno o no (por mucho que confíes en él) y tampoco si se van a mantener constantes en el tiempo el contexto o condiciones en las que se ha realizado el mismo (pero es importante tener en cuenta que el problema no suele ser fallar en la planificación, sino como dije antes, ser poco flexible a los cambios cuando resulta necesario).

Precisamente por eso los enfoques predictivos o clásicos en el desarrollo de software no suelen dar buenos resultados porque se especula con una solución basada en un conocimiento limitado de los usuarios del producto que quieren (el conocimiento real se obtiene con el tiempo conforme ellos vayan viendo materializadas sus ideas a lo largo del proceso de desarrollo), dado que estas estrategias prevén estabilidad en las especificaciones, todo empieza a desmoronarse cuando se rompe ese requisito y es demasiado tarde para que los cambios en las especificaciones tengan un impacto leve en el esfuerzo disponible del proyecto.

Llegado a ese punto solo se podrá salvar la situación si cliente y proveedor entienden el problema y tratan de buscar una solución flexibilizando el objeto del contrato, intercambiando tareas y aportando más presupuesto por parte del cliente en el caso de que sea necesario.

El prototipado puede ir desde fórmulas muy simples como dibujos realizados a mano alzada a desarrollos que tienen una cierta lógica implementada. Son muy útiles ya que permiten trabajar sobre algo material y no sobre ideas de carácter abstracto. Nunca van a poder sustituir a la funcionalidad una vez implementada en toda su extensión pero sí que permiten desarrollar con más intención.

Este antipatrón surge cuando no se hace un uso adecuado del prototipo, no se interpreta o se comunica adecuadamente su función y utilidad, pudiendo abarcar diferentes áreas:

– El responsable funcional aprueba el prototipo pero no se ha llegado a un suficiente nivel de detalle en el comportamiento, esto puede provocar que una vez implementado no se alcancen (incluso nos hayamos quedado bastante lejos) las expectativas puestas en la funcionalidad. También puede pasar que se piense que el desarrollo es más simple o más complejo que lo que realmente es.

– En entornos de negociación cerrados, en los que solo existe el contrato como objeto de debate, si se cierran términos del mismo (alcance y coste) en base a un prototipo con muchos detalles por concretar, se corre el riesgo de que las estimaciones realizadas sean fallidas y el cliente se niegue a replantear el alcance del proyecto alegando que se conocía perfectamente el alcance ya que había un prototipo que respondía a todas las dudas.

– Los clientes también incurren en un riesgo importante si consideran un prototipo como la base fundamental para realizar una valoración del alcance, sin haber evaluado si el conocimiento que proporciona es suficiente como para hacerla reduciendo la probabilidad de que haya desviaciones sensibles.

En los dos casos anteriores, el problema lo tenemos por un lado en la falta de flexibilidad a la hora de abordar cambios en el alcance y/o de aportar más recursos económicos al proyecto (y esto ocurre trabajando con o sin prototipos) y por considerar los prototipos como una versión real pero de juguete del producto final, algo que no será así porque a lo largo del proceso de desarrollo los usuarios cambiarán de prioridades, descubrirán nuevas funcionalidades a implementar, etc…, es más, incluso en el caso de que el prototipo sea de una funcionalidad, la implementación real sacará a la luz problemas: de carácter tecnológico, de integración, funcional, etc…, muchos de los cuales son complicados de prever cuando se está trabajando con el prototipo.

Es decir, el prototipo es un facilitador para desarrollar con intención pero nadie (cliente y proveedor) debe tomarlo como la verdad absoluta y que en base a ellos se tomen decisiones inamovibles.

– Si se dedica mucho esfuerzo al prototipo es posible que se caiga en la tentación de convertirlo en el producto definitivo. Esto supone un riesgo importante porque lo más posible es que su desarrollo se haya realizado sin tener en cuenta aspectos relacionados con la calidad y mantenibilidad del software, lo que después puede dar lugar a importante costes de evolución del producto, falta de robustez, efectos colaterales en cada versión, etc…