archivo

Archivo de la etiqueta: implantación

Cuando se quieren implantar estrategias ágiles de trabajo suele ser el resultado del impulso de una serie de personas que creen en ellas (otra cosa es que las entiendan, cosa que como he comentado es esencial para que a medio plazo no tengamos lo mismo que antes solo que con otros procesos, tal vez más apropiados a la naturaleza de los proyectos de desarrollo de software pero al fin y al cabo vistos exclusivamente como procesos y no como estrategias, herramientas o actitudes) y que se han preocupado de formarse por su cuenta (generalmente) o porque alguien en la organización ha tenido curiosidad y/o interés en que se formen en esto.

Todo cambio suele venir del impulso de una o varias personas, no se trata por tanto de una excepción, ¿dónde podemos encontrar el problema? Pues que la formación y el conocimiento se quede en ellas y en unas cuantas personas más que se encuentren próximas a ellas o hayan mostrado interés en esta dinámica de trabajo.

Esto no debe ser así, la implantación con efectividad de estrategias ágiles requiere que las personas que trabajan con ellas estén debidamente formadas para que puedan entender por qué se actúa de esa forma y para que ellos también puedan contribuir al correcto funcionamiento de las mismas y a su mejora. Si no lo hacemos se pierde eficiencia, el equipo está menos involucrado en la dinámica de trabajo (muchos pensarán que se trata de un capricho o de un juego) y se pierde la capacidad de que otras personas aporten su visión.

Se cree que con que unas cuantas personas estén formadas es suficiente y no es así. Es cierto que con algo hay que empezar pero tras el impulso inicial es fundamental que la formación y el conocimiento llegue al mayor número de personas posibles, priorizando aquellas que vayan a empezar a trabajar con este enfoque.

El impacto de las deficiencias funcionales tiene unas consecuencias similares a los bugs. Estas deficiencias son provocadas por especificaciones incorrectas por parte del área usuaria y/o por una mala interpretación de ellas por parte de los desarrolladores. En el caso de los bugs el peso recae principalmente sobre éstos.

Tanto unas como los otros impactan sobre el producto y sobre el proceso.

Siempre suponen un problema en la implantación de una aplicación, si se sitúan en funcionalidades críticas y/o son muy numerosos el sistema tendrá rechazo por parte del área usuaria y la presión que ejercerán los mismos no ayudará precisamente a crear el clima más adecuado para hacer las correcciones oportunas lo antes posible.

Pero no es solo eso, si la aplicación es crítica se podría poner en riesgo la seguridad de las personas o incluso la propia continuidad de una organización si el mal funcionamiento afecta a sus ingresos (ventas y/o imagen) o a procesos críticos.

En cualquier caso, una sistema que no va bien impacta en la productividad y eso se traduce en dinero que se deja de ganar o que se gasta de más.

El impacto en el proceso de desarrollo es evidente. Puedes tener una planificación a medio/largo plazo o un sprint y quedar devastados por la aparición de estas incidencias, muchas de las cuales requerirán ser corregidas con celeridad.

Recordemos que si aplicamos sprints y nos basamos en prácticas de Scrum tenemos como objetivo cumplir con lo comprometido (otra cosa es que haya causas justificadas que hagan que alguna historia de usuario no se haya podido llevar a cabo), en un contexto inestable por la aparición continua de incidencias es imposible que el equipo pueda coger un ritmo salvo que se apliquen medidas como por ejemplo crear una línea de desarrollo independiente que se encargue de tratar las incidencias que bien podría aplicar sprints, enfoques similares a Kanban o sincronizarse con el sprint de desarrollo cuando éste termine. En cualquier caso, estas medidas tienen un coste.

Ante esta perspectiva resulta no ya una situación aconsejable, sino de verdadera necesidad, minimizar el número de incidencias funcionales y bugs que llegan a producción, intentando que su detección sea lo más temprana posible.

Entregar por entregar una versión de un producto es algo que desgraciadamente estamos muy habituados a ver.

La entrega de software de baja calidad tiene consecuencias negativas, muchas más que si no hubieras entregado el producto a tiempo (por regla general):

– Cuando se entrega un software y se rechaza no solo estás perdiendo tiempo y dinero tú, sino también el cliente.

– Cuando se entrega un software con un elevado número de errores se incrementa la probabilidad de que alguno de ellos y de importancia llegue a producción, lo que puede provocar la liberación de un nuevo parche o de una serie de parches. Con eso también pierde dinero el cliente (mucho más ya que ha podido dejar bloqueado total o parcialmente un proceso, lo que ha provocado que una serie de trabajadores estén por debajo de su rendimiento habitual) y también lo perderás tú.

– Cuando se entrega un software con una deuda técnica alta estás condicionando su evolución, aquí también pierde dinero el cliente por el coste extra que tendrán las tareas de mantenimiento y por los posibles efectos colaterales que provoquen las nuevas versiones (si el software se encuentra muy acoplado y el testing no es suficiente) y también lo perderás tú, sobre todo si trabajas en proyectos a coste fijo.

Entregar software a la ligera por el simple hecho de cumplir una fecha o por pensar que no pasa nada, que ya se corregirán los defectos hace mucho daño, no solo al proyecto, ya que cuando se generalizan esas prácticas también se hace mucho daño a la profesión. Si queremos mejorar nuestras condiciones y la percepción que terceros tienen de nosotros necesitamos que no se nos vea como chapuceros.

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).

Siempre en el peor momento y después toca correr para corregirlas. El problema es cuando no hay espacio para frenar y tras él solo queda el abismo.

No somos infalibles, de hecho no debemos serlo, salvo que el sistema sea tan crítico como para que de él dependan vidas humanas o se comprometa la viabilidad económica o de negocio de una organización. Pero una cosa es saber que cometeremos errores, aceptar un determinado umbral adecuado a las características del proyecto y su presupuesto y otra que esas incidencias se produzcan de forma sistemática.

Se ha convertido ya en algo comúnmente aceptado que las entregas no sean limpias y que se tenga que iterar varias veces hasta alcanzar una versión aceptable para pasar a producción, cuando no iterar sobre versiones que han llegado a producción.

Os lo aseguro, vale la pena hacer testing (bien hecho), invertir esfuerzo en ello, el que sea necesario.

Cuántas veces se me viene a la cabeza la famosa cita de Boris Beizer: “Una amenaza bien vale mil pruebas“.

El desarrollo de software está muy lejos de conseguir el éxito a través de la utilización de una bola de cristal. Las metodologías clásicas como el ciclo de vida en cascada, donde existe mucho tiempo desde que se concibe el proyecto hasta que entra en producción presupone que los cambios que se van a producir desde la aprobación del análisis hasta la implantación van a ser mínimos, algo que todos sabemos que dista mucho de ser real.

Todos hemos sido, somos y seremos víctimas de los desarrollos en cascada porque en muchas ocasiones estamos obligados a afrontar los proyectos de esa forma. Es una pena porque la naturaleza del desarrollo de software es adaptativa de manera que mediante aproximaciones sucesivas si se trabaja de manera adecuada y los usuarios colaboran, cada vez el producto resultante estará más próximo a las expectativas del usuario, manteniendo unos umbrales de calidad por encima del mínimo exigible.

Sobre este aspecto, David Lorge Parnas, realiza la siguiente reflexión (traducción libre): “La imagen de un desarrollador obteniendo el diseño de un software a partir de un conjunto de requisitos racional y sin errores es muy irreal. Ningún sistema ha sido construido de esa manera y probablemente nunca se construirán. Incluso el desarrollo de programas pequeños que se muestran en libros y artículos son irreales, ya que son revisados y pulidos hasta que el autor nos muestra lo que el desearía haber hecho y no lo que realmente hizo”.

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.