archivo

Archivo de la etiqueta: Boehm

Me parece muy interesante la siguiente reflexión de Barry Boehm: “El cliente debe ser aconsejado suficientemente para proporcionar un feedback honesto y sustancial desde el principio del proceso de desarrollo”.

Estoy de acuerdo, pero también se tiene que generar un contexto de trabajo en el que el feedback sea más eficaz y ahí es donde entra en juego la utilización de un enfoque iterativo incremental con ciclos cortos (no especifico duración porque dependerá del proyecto e incluso dentro de él, puede ser necesario ir cambiando la misma).

Sin embargo, el feedback no debería ser el único tema sobre el que el equipo de desarrollo pueda orientar al cliente, a continuación indico algunos:

– A saber que el producto se obtiene poco a poco, que debe dejar de lado el síndrome de la última versión y el deseo de tener todo ya. Esto implicará que deberá elegir en cada momento lo que realmente le resulta prioritario (y además está empezando a tener claro).

– A ayudarle a asociar prioridad y valor, de manera que tenga presente que un factor muy importante a la hora de seleccionar las tareas de un sprint debe ser el valor que proporcionan las mismas al producto final.

– A la necesidad de tener bien definidas las historias de usuario con las que se va a trabajar. De lo contrario se desarrolla con menos intención y entra más en juego soluciones basadas en el prueba y error.

– A buscar soluciones simples que resuelvan su problemática funcional.

– A no sobrecargar la aplicación con funcionalidades que no aportan valor.

– A confiar en el equipo de proyecto cuando le informen de la complejidad de una determinada actuación.

– A no tener miedo a equivocarse.

– A que utilice las versiones que se van liberando con el objetivo de ir perfilando el producto que satisfaga sus expectativas.

Barry Boehm evolucionó su modelo en espiral hacia el modelo en espiral win & win, probablemente inspirado en sus convicciones de que las personas son las que condicionan el éxito o el fracaso de un proyecto.

Desde esta perspectiva, Boehm defiende que el equilibrio entre todas las partes implicadas se consigue a través de unas condiciones de trabajo y resultados en el que todos ganan ya que de esta forma todos enfocan sus tareas al cumplimiento de los objetivos.

La visión de Boehm, resulta racional, todos luchan por el éxito del proyecto si a través de él ganan.

Sin embargo, ¿qué sucede en la realidad? pues que resulta complicado alcanzar ese equilibrio ya que depende de dónde cada parte ponga el listón de lo que considera ganar ya que lo mismo se coloca a un nivel donde no es posible que los otros ganen.

Hay autores como Jim Camp que no creen en el ganar-ganar (su conocido libro “De entrada diga no” muestra con ejemplos, basado en su experiencia, que no es posible ganar sin que otro pierda o visto de otra manera, siempre habrá alguien que en una negociación gane más que otro) y el fundamento está en que los intereses individuales nublan o incluso anulan la empatía.

Basado en mi experiencia os comentaré que este negocio es una selva y que en ella cada cual intenta sobrevivir como puede. Este contexto no resulta el más adecuado para buscar soluciones basadas en el ganar-ganar, sin embargo, dentro de él, hay que intentar ir hacia una gestión de proyectos en la cual se intente alcanzar el equilibrio del ganar-ganar (el equilibrio difícilmente se conseguirá, pero en su búsqueda se podría llegar a alcanzar una situación en la que cada parte supere el mínimo válido para cumplir sus expectativas).

Para llegar a esto es necesario que cada parte cumpla con su cometido, con lo que ha acordado y que si las condiciones cambian por el propio devenir del proyecto, se llegue a un nuevo contexto que trate de alcanzar de nuevo el modelo del ganar-ganar.

Para que cada parte cumpla, es necesario que de manera individual funcione de forma adecuada, ya que su propio desequilibrio provocará un desequilibrio entre todas las partes y la ruptura del objetivo del ganar-ganar.

Un ejemplo de esto lo podemos tener en el caso de que el proveedor no cumpla sus objetivos de productividad y empiece a poner en riesgo sus expectativas de beneficio, en ese momento probablemente, para mitigar este efecto se empiece a ver afectado la calidad del producto y/o se solicite una ampliación del presupuesto del proyecto.

Otro ejemplo lo podemos tener desde el punto de vista del cliente, cuando se encuentra próximo a consumir el presupuesto o intentar recortarlo y sin embargo todavía no tiene listo el sistema de información (por continuos cambios en el proceso de desarrollo) o quiere mantener su alcance.

La incertidumbre inherente a los proyectos de desarrollo de software requiere que el proceso de desarrollo pueda responder de manera ágil y flexible ante ella. De lo contrario estamos abocados a desarrollos que no se adaptarán a las expectativas del usuario o que para acercarse a las mismas requieran un sobrecoste importante, así como un incumplimiento de los plazos.

¿Qué estoy exagerando? Hace poco os puse los datos publicados por el Cutter Consortium, en el que quedaba patente que la crisis del software sigue sin superarse.

Barry Boehm, uno de los mayores expertos a nivel mundial en estimación de costes software y en la aplicación de estrategias de gestión económica en los proyectos de desarrollo de software, lo manifiesta de manera patente en la siguiente reflexión (traducción libre): “Será importante tener en cuenta a la hora de organizar proyectos en el futuro contar con la agilidad suficiente como para ser capaz de adaptarse a la aparición de nuevas fuentes adicionales de cambios imprevisibles”.

Y es que los datos del Cutter Consortium son escalofriantes:

– El 62% de los proyectos superan la planificación inicial en más de un 50%.
– El 64% cuesta más del 50% de lo presupuestado.
– El 70% tenía errores críticos tras su lanzamiento.

¿Puede aguantar nuestra industria estos datos? Hasta ahora muchas empresas de desarrollo han ganado mucho dinero con este caos a la misma vez que nuestra profesión se ha desprestigiado.

El manifiesto ágil fue un acto de rebeldía ante esta situación y fue, en mi opinión, el punto de inflexión hacia otro escenario. La aportación de Barry Boehm, muchos años antes, con la publicación de su libro “Software Engineering Economics” asociando conceptos asociados a la economía al desarrollo de software, también me parece decisiva.

Pese a esto, se tardará todavía mucho tiempo en superar la crisis del software porque supone un cambio absoluto en la cultura de los desarrolladores y de las empresas.

Si lo más importante en el desarrollo de software son las personas (tal y como expone el manifiesto ágil) resulta totalmente coherente la siguiente reflexión de Barry Boehm en la que comenta que: “una buena ingeniería del software debe adaptarse a las preocupaciones humanas”.

Precisamente en los artículos:

Entorno de trabajo y la productividad
Desarrollo de software. Barry Boehm. La perspectiva del programador

Trato las dos partes en que divide Barry Boehm este concepto, la comprensión del equipo de personas que está desarrollando el proyecto y la comprensión de las personas que hacen uso o van a hacer uso del producto.

No hay ingeniería sin personas que la lleven a cabo y sin un destinatario de sus resultados, la ingeniería por sí misma no es un fin, es un medio. Por tanto no se puede supeditar todo al proceso, a las técnicas, a las herramientas, son importantes sí, pero solo si se hacen desde y para las personas.

Realizar primero aquellas funcionalidades más importantes para la aplicación y que sean más sencillas de implementar es lo que se denomina en el argot de la consultoría quick wins.

Para detectarlos Barry Boehm propone una estrategia simple, pero efectiva. Ante una funcionalidad solicitar al área usuaria que le asigne una prioridad de 1 a 10 (siendo 10 la mayor) y al equipo de desarrollo que le asigne un valor entre 1 y 10 en función de la complejidad del desarrollo (siendo un 10 la menor), ¿qué funcionalidad implementar primero? La que tenga un valor 10-10 (muy importante y sencilla de realizar) y así sucesivamente.

Cuanto más leo a Barry Boehm más me siento identificado con sus reflexiones y eso que muchas de ellas son de hace más de veinte años y es que los problemas en el desarrollo de software vienen a ser los mismos pese a lo vertiginoso cambio que tienen las tecnologías.

Esto viene a demostrar que los problemas relacionados con el desarrollo de software trascienden a la tecnología (si bien, una vez superados o contenidos los mismos, entra en juego el factor tecnológico y el impacto de sus errores).

Uno de los problemas del desarrollo de software, Boehm lo centra en la existencia de una perspectiva equivocada por parte de los programadores respecto a las expectativas del usuario y se puede resumir perfectamente en la siguiente reflexión (traducción libre): “Desde la perspectiva de la programación, tenemos que olvidar la regla de oro, que dice que haz a otros lo que otros te harían a ti, ya que para un programador, la interpretación literal de esa regla es proporcionar a otros programadores una interfaz gráfica de usuario amigable, lo cual no va a ser muy útil para una enfermera o un bibliotecario”.