archivo

Archivo de la etiqueta: implantación y aceptación del sistema

En estas circunstancias es cuando se tiene buena parte del camino andado para que el proyecto tenga éxito. Y no es fácil conseguirlo.

Un product owner puede tener voluntad en hacer su trabajo de la mejor manera posible, sin embargo, la milla extra que separa un proyecto aceptable de otro con éxito se encuentra, en muchas ocasiones, en el hecho de que el product owner considere y sienta el proyecto como suyo.

El product owner es fundamental para el proyecto y así lo deben entender los desarrolladores, de manera que no lo consideren como alguien ajeno al equipo sino como una persona más dentro de él.

Para ello el product owner también tiene que poner de su parte, no obstante, si nos encontramos con dueños del producto que no tienen experiencia, tenemos que poner más del lado de los desarrolladores para conseguir ese ambiente de trabajo que favorecerá la colaboración entre todos.

Cuando el product owner se sienta parte del proyecto, defenderá el producto, lo que hará más llevadero un proceso tan complicado como es el de la implantación del sistema, en el que muchos usuarios se mostrarán contrarios a su utilización, queriendo preservar sus métodos, herramientas y procesos de trabajo.

La implantación se asocia a la puesta en producción de la primera o mínima versión viable del producto, sin embargo es un proceso que comienza antes y no me refiero a formación que haya que realizar con carácter previo, sino a todo un trabajo que comienza en las etapas iniciales del proyecto y que se extiende a lo largo de sus diferentes iteraciones.

En la mayoría de los casos la instalación de una versión del sistema en el entorno de producción es realizada por un personal distinto al que desarrolla y que se encargar de administrarlo.

También antes de proceder a la instalación en producción se realizan pruebas específicas ya sean por parte del usuario, por parte de personal de equipo de proyecto y/o por parte de un equipo de personas que realizan este tipo de tareas.

Básicamente (dependiendo de la organización con la que se trabaje estos requisitos podrán ser mayores) una entrega consistirá en la entrega del código fuente, en un sistema de control de versiones, la incorporación de las librerías dependientes en un repositorio de artefactos y la documentación necesaria para la instalación del producto y la realización de pruebas.

No es mucho, ¿verdad?, pues incluso en este tipo de circunstancias los desarrolladores realizan con demasiada frecuencia entregas deficientes que provocan retrasos en el proceso de paso a producción (vueltas a atrás por entregas defectuosas ya sea del producto y/o de la documentación) e incidencias sobre funcionalidades ya existentes en el sistema y que funcionaban bien (efecto colateral) o funcionalidades nuevas que fallan.

Esto tiene un coste importante para el proveedor y también para el cliente. En algunas ocasiones este coste puede ser incluso mayor cualitativamente y/o cuantitativamente que el esfuerzo que ha sido necesario para desarrollar esta iteración.

¿Por qué estas malas entregas? Principalmente por la falta de atención. A los desarrolladores no les motiva esos preparativos y hacer esa documentación, les aburre y mientras están trabajando en la misma en lugar de enfocar su atención a esa tarea se ponen a pensar en otra cosa o simultanearla con otros asuntos.

Con respecto a esto yo solo digo que un muy buen trabajo en el desarrollo puede quedar arruinado por una mala gestión de la entrega lo que realmente es una pena porque es como fallar un gol desde el área pequeña y sin portero.

Lo he vivido ya en más de una ocasión y lo he sufrido no durante semanas, sino meses y en algún caso hasta años.

Poner en marcha un sistema de información en su totalidad o en gran parte sin que ningún usuario lo haya utilizado en un entorno o contexto real es una condena para el propio sistema de información y para quienes lo gestionan.

Llegarán peticiones de mejora e incidencias superiores a la capacidad que se tendrá para dar respuesta (si es que dispones de esa capacidad, ya que pocas veces se prevé que lo que se desarrolla hay que mantenerlo, de hecho los responsables o directores funcionales del sistema es lo que pensarán si no se les explica de manera adecuada y con carácter previo qué es un desarrollo de software y qué consecuencias tiene los cambios en las especificaciones sobre el coste del proyecto) y la puesta en marcha del sistema se convertirá en una cuesta arriba que no parece tener fin a la vez que no termina de aflojar su pendiente.

Es la consecuencia de la aplicación de metodologías clásicas y del efecto bola de cristal donde se piensa que todo lo definido hace meses (cuando no años) por personas que lo mismo ya no trabajan en la organización o están en otro departamento sigue siendo válido cuando se pone en marcha el sistema. Esto sucederá en la mayoría de los casos incluso habiendo realizado un análisis muy riguroso (en todo caso, la calidad del análisis reducirá los problemas, algo que, sin duda, se agradece, pero que no resuelve el problema de fondo).

Cualquier cambios que se le haga a un usuario respecto a su forma de trabajar no suele ser acogido de buena gana, es más, cuando mayor sea la diferencia, mayor será su resistencia al cambio. En general, cualquier ruptura de hábitos y/o automatismos provoca estas sensaciones, a todos nos pasa, por lo que es inteligible que ese tipo de circunstancias tenga esas consecuencias.

Cuando se desarrolla un sistema de información, hay que tener en cuenta ese salto entre la situación actual y la situación objetivo, teniendo en cuenta también las características de los usuarios que va a tener la aplicación. Es importante, por tanto, que el usuario sienta la menor hostilidad con respecto al entorno, para ello es esencial la gestión del cambio, la cual puede empezar (y debe empezar) desde el mismo proceso de desarrollo y no esperar hasta que se ha realizado la implantación, como suele suceder casi siempre.

Boris Beizer es un autor e ingeniero de software americano (aunque nacido en Bélgica) especializado en el campo de la calidad del software y del testing. Sus primeras publicaciones datan de finales de la década de los cincuenta, aunque su etapa más prolífica fue en las décadas de los setenta y de los ochenta.

El testing es un campo dentro de la ingeniería del software un tanto controvertido. La mayoría de los profesionales consideramos necesarias las pruebas en el proyecto de desarrollo de software, si bien no hay coincidencia en cuanto a la intensidad, los momentos y la metodología.

Soy de la opinión de que no todos los proyectos y sistemas de información deben tener un mismo tratamiento y que independientemente de que exista una cierta metodología en las pruebas, estas deben girar alrededor del testing ágil y del exploratorio.

También soy partidario de que las clases con mayor acoplamiento sean cubiertas mediante pruebas unitarias (no necesariamente desarrollando según técnicas de desarrollo guiadas por las pruebas (TDD)) y que se deben minimizar los efectos colaterales a través de las pruebas de regresión.

En cuanto a los momentos, el testing debe aplicarse desde las etapas más tempranas del software, si bien los actores pueden ser distintos a las pruebas realizadas sobre el producto.

Y como estrategia, la utilización de integración continua permite detectar problemas de carácter unitario y de integración lo antes posible y a reducir los problemas en la fase de implantación.

Boris Beizer realiza la siguiente reflexión (traducción libre): “Una amenaza bien vale mil pruebas”.

Desgraciadamente nos acordamos de un proceso de testing bien realizado cuando ya los errores han salido a la luz y lo peor de eso, cuando su corrección requiere de un esfuerzo considerable, cuando ha impactado gravemente en el negocio o cuando nos crea un problema.

Cuando mayor sea la criticidad del sistema más peso debe tener el proceso de testing y más peso debe cobrar la metodología y sistematización.

Martin Fowler creó el concepto de integración continua como una técnica o estrategia que consiste en programar automáticamente el proceso de compilación y ejecución de pruebas unitarias de un software que se está desarrollando.

El objetivo de la técnica consiste en detectar errores unitarios y de integración lo antes posible. Si se dejan estas comprobaciones para etapas muy tardías del proyecto los costes de corrección de estas incidencias se disparan) sobre todo en equipos de proyecto de tamaño medio o grande que trabajan en diferentes localizaciones).

No es una estrategia exclusiva de metodologías ágiles (podría ser utilizada perfectamente en metodologías del proceso unificado como RUP o en la fase de construcción de metodologías clásicas como por ejemplo el ciclo de vida en cascada), si bien su aplicación en las mismas resulta de gran importancia tanto en el proceso de desarrollo como para reducir los tiempos de implantación del sistema.

Se entiende integración continua cuando el proceso se programa para que se ejecute automáticamente. También podría considerarse cuando la integración se realice de forma planificada, aunque se realice de forma manual, en intervalos razonablemente cortos de tiempo. No es integración continua si se ejecuta de manera esporádica o en momentos próximos a la entrega.

Si problemático resulta el desarrollo de software, el paso a producción en muchos casos no lo es menos. La implantación de un sistema de información con una cierta envergadura no es un proceso trivial y es necesario, en el caso de que el tiempo que se tarde no sea bueno, medir y mejorar el proceso para intentar alcanzar una mejora continua que lleve a unos umbrales aceptables.

Jim Highsmith, firmante del manifiesto ágil, hace una reflexión sobre este tema en su artículo “Shortening the tail“.

Este autor denomina como “tail” a todo el proceso posterior a que una evolución de un producto se considere terminada por parte del equipo de proyecto. En este proceso se incluirían las actividades de testing, pruebas de regresión, integración, pruebas de integración, documentación, corrección de incidencias de la entrega y paso a producción.

De hecho la definición exacta que da de tail es todavía más elocuente (voy a dejar algunas palabras en inglés para no restar significado): Es el tiempo transcurrido desde el “code slush” o “feature freeze” hasta el despliegue del producto.

Comenta Jim Highsmith que el tail más largo que encontró fue de dieciocho meses. Afortunadamente no he tenido uno tan largo, los peores tiempo con que me he encontrado han sido de tres o cuatro meses, si bien, ha sido debido generalmente a que el proceso de desarrollo lo había fraccionado en varias entregas, lo que daba lugar a que el tiempo se repartiera entre las mismas. Probablemente si sumara los tiempos de las mismas serían muy superiores a los meses que he indicado.

Tail de larga duración para entregas o evoluciones simples son un problema, ya que marcan el tiempo en el que un usuario por término medio podrá disfrutar de una evolución del producto (no cuento los posibles parches rápidos que se puedan instalar, ya que estos, generalmente tienen otro proceso de implantación).

Estas evoluciones en muchos casos no son caprichos, sino necesidades que si no son cubiertas provocan una ineficacia en el trabajo desarrollado por los usuarios y en consecuencia un impacto en los resultados del departamento y en consecuencia de la organización. Es por ello que se debe dar la importancia que se merece la optimización de estos tiempos.