archivo

Archivos diarios: abril 19, 2012

Si el usuario no tiene en cuenta lo que cuesta cambiar de opinión, equivocarse y en general la adaptación de la solución disponible en cada iteración a una que se aproxime cada vez más a sus expectativas estamos entrando en el juego peligroso de la barra libre ficticia, ya que llegará un punto donde por parte del proveedor no se pueda asumir más gasto y generalmente se avisará al cliente demasiado tarde (siempre será demasiado tarde).

Cuando se llega a esa situación el resultado en la mayoría de los casos será desgaste por ambas partes y un producto final que no dejará contento a nadie.

¿Una posible estrategia? Que el cliente (tanto el responsable técnico como los responsables usuarios) tengan conocimiento y estén de acuerdo con el coste que tiene llevar a cabo las especificaciones realizadas en cada iteración (una por una) y que como se partirá de un presupuesto de partida fijo a cambio de qué se llevan a cabo esos ajustes (ver artículos relacionados con la contratación ágil).

No se trata de poner al cliente o al usuario bajo la presión de tener que acertar siempre, eso no sería ni realista ni ágil, sino de que entiendan que se tienen que tomar muy en serio su rol en el proyecto y que la evolución del producto no se lleva a cabo mediante prueba y error, sino con intención.

La resistencia vista desde distintas perspectivas, como por ejemplo el tiempo de más que tarda en pasarse a producción un producto o todas aquellas dificultades u obstáculos extras en el proceso de desarrollo, que puede ir desde la deuda técnica hasta la falta de colaboración por parte de los usuarios, dificulta el establecimiento de ciclos cortos en un enfoque iterativo e incremental.

Esto al final es como la pescadilla que se muerde la cola, ya que cuanto más largo sea el ciclo, mayor número de funcionalidades se incorporarán o se modificarán y alimentarán, por ejemplo un paso a producción más largo.

No entro a valorar en término cuantitativo qué es un ciclo corto o qué es un ciclo largo porque opiniones hay para todos los gustos, como también las hay para determinar si todas las iteraciones dentro de un proyecto deben tener la misma duración o no.

Si se quieren ciclos cortos y que estos sean efectivos (que sean resolutivos de cara a las expectativas del usuario) hay que disminuir la resistencia y eso no es una cuestión simple, sobre todo si se parte de la base de que se intenta aplicar este enfoque de desarrollo en proyectos que se encuentran en una etapa avanzada o que se encuentran en fase de mantenimiento.

Disminuir la resistencia debe ser siempre un objetivo a tener presente, sobre todo condiciona de manera grave el proceso de desarrollo. Si es importante en todos los casos, lo es todavía más cuando se pretende liberar nuevas versiones del producto cada poco tiempo.

Disminuir la resistencia implicará actuaciones no funcionales (y eso será necesario tenerlo en cuenta y explicarlo muy bien al usuario), como por ejemplo automatizar en lo posible la instalación de la aplicación en los diferentes entornos, la automatización en la ejecución de las pruebas partiendo desde las pruebas unitarias y subiendo cuantos niveles sean precisos, la realización de pruebas manuales en aquellos casos donde no llegue o no sea rentable automatización, la refactorización, etc…

También obligará a realizar diversas tareas de gestión para intentar agilizar los procesos y las actividades de las diferentes personas y roles que participan en el proceso de desarrollo y de implantación y aceptación del sistema.