Mantenimiento:
"Modificación de un producto de software, después de su entrega para corregir errores, mejorar el rendimiento u otros atributos o adaptar el producto a cambios del entorno".
IEEE Std. 1219-1998

 En la gestión ágil de un producto de software, ¿cuándo acaba el desarrollo y empieza el mantenimiento?

En cuanto a calidad... así, así: el 46% dice que los resultados usando Scrum son los mismos o peores que con otros métodos, mientras que el 54% dice que son mejores.
Sin embargo sobre la productividad la opinión es bastante más favorable: el 74% dice que con Scrum han mejorado la productividad; y en lo que también saca buena nota es en la "simpatía" y buena disposición hacia el modelo: Le cae bien al 77%, y hace que el equipo tenga más claros sus objetivos y lo que se espera de él (80%).
 

En los cursos de formación de Scrum de Ken Schwaber en Londres en otoño de  2005, los gestores de proyectos tradicionales se quedaban a cuadros: "Entonces, si no descomponemos en un WBS, no planificamos, no asignamos el trabajo ni seguimos su evolución para arbitrar medidas de corrección... entonces ¿en qué se queda nuestro trabajo?".

Este cambio es un elemento cultural duro, pero sin embargo es una de las claves del funcionamiento de los equipos ágiles.

Este es un indicador curioso para medir el nivel de "gasolina" de los equipos ágiles: la motivación. Se trata del "Calendario de Niko-niko" (Niko-niko Calendar), una especie de "twiter" de la moral, actualizado a diario y situado en un lugar visible junto con el resto de indicadores de seguimiento diario empleados por el equipo (sprint backlog, gráfico burn down, pizarras Kanban...)  y viene a ser una cosa así: 

Esta es la comparación que Jason Gorman hace entre la propagación de los virus y los consultores de Scrum. Jason es un consultor inglés, beligerante y sarcástico con quienes, con mayor o menor conocimiento de los principios de la agilidad, dogmatizan anclados en ella.

El diseño del modelo de gestión ágil DSDM incluye antes de comenzar con las iteraciones (funcional - Diseño - e implementación), un punto de inicio representado por el triángulo de su diagrama ("el queso ") con las fases:

• Pre-proyecto
  
• Estudio de viabilildad
• Estudio de negocio

La ingeniería de procesos mide, analiza, re-diseña el proceso y lo implementa de nuevo. Los modelos tipo CMMI incluyen prácticas comunes para institucionalizar la medición el análisis e institucionalizar los resultados.

¿Y los ágiles?.

"En intervalos regulares el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia"

 Manifiesto Ágil

Safe Creative es un buen ejemplo de proyecto que pide a gritos no sólo gestión ágil para su desarrollo, sino para todo el "management" y estrategia del producto.

Necesita valor, antes que gestión predictiva.  Ofrecer valor desde el primer día, y a partir de ahí de forma iterativa e incremental con el feedback continuo del entorno; lo que Ughamwa y Baker llaman "innovación incremental":

El tipo de proyecto en el que no es realista cerrar los requisitos de cómo será el producto, y sobre ellos construir el plan;  en el que no interesa saber que el producto completo estará en la fecha tal. No necesita previsibilidad, sino valor desde el primer día, y desarrollarlo de forma incremental y continua.

No suelo mezclar blog y trabajo, pero este es el proyecto que llevo entre manos en los últimos meses y en el que estoy aplicando no ya scrum para el desarrollo sino lo que sería un "scrum management ": Un concepto ágil para toda la estrategia del producto.

Este es uno de los proyectos en los que contrasto y surgen las cosas que luego comparto por aquí, así que ya sabéis, si queréis registrar vuestros trabajos, presentaciones, partituras, novelas, proyectos, cuadros, fotos, etc. etc...

Safe Creative :-)

Dando una vuelta me he tropezado con que los chicos del capítulo de Richmond de APLN tienen en su wiki para descarga libre el artículo "The New New Product Development Game", en el que Nonaka y Takeuchi resumían en 1986 la nueva forma de trabajo observada en industrias tecnológicas,  que denominaron "campos de scrum", y en el que se definen por primera vez las características del desarrollo ágil: equipos auto-organizados, solapamiento de las fases de desarrollo, comunicación y difusión del conocimiento, y gestión "sutil".

Aunque no es muy caro, y se supone que no es de libre distribución, para los que os pueda interesar y no lo tuviérais, de momento, por alguna razón, aquí está:

•  The New New Product Development Game

Más presentaciones de congresos: esta vez las de Agile 2007 que se celebró hace un par de semanas en Washington. No son los vídeos sino los "powerpointes" empleados en algunas de ellas, o los artículos de los autores. Hay un buen montón:

• Documentación de las sesiones de Agile 2007  

"Ninguno de nosotos es tan inteligente como todos nosotros". Knute Rocke.

"Existen muy pocos Einstein entre nosotros. La brillantez surge de personas comunes trabajando en equipo de manera extraordinaria". Roger Von Oech

"La innovación sólo es un grupo inteligente divirtiéndose." Michael Nolan

Incluir dos columnas adicionales en el el product backlog, y registrar también en el sprint backog los tiempos trabajados, para que los modelos de calidad puedan realizar análisis cuantitativo y mejora del proceso.

Además de la columna de estimación inicial realizada por el propietario del producto, y propia del proceso de Scrum:

• Estimación sprint: Tiempos estimados para cada funcionallidad por el equipo en la reunión de inicio del sprint.
• Esfuerzo real: Tiempos invertidos en cada funcionalidad. (anotado en el sprint backlog y registrado en el product backlog al final de cada sprint).

Allá por 1980, el profesor de programación (COBOL) siempre que nos veía en la sala de prácticas con los terminales de aquellos equipos "Altos Europa"   nos repetía la misma cantinela:
"Cuanto antes empiecen a codificar, más tarde terminarán. ¿Ya han hecho un análisis funcional completo?. ¿Tienen el análisis orgánico?. Tengan claros los requisitos y diséñenlo bien, que si no todo será probar y cambiar.

Le fascinaba la forma de trabajar de americanos, alemanes, ingleses... Decía: "los latinos ¡siempre igual!, casi sin tener claro lo que vamos a hacer, nos ponemos ya a trabajar.  ¡Hala! empezamos y luego todo es hacer y rehacer...."

Tenía muy claro que la cultura anglo-sajona seguía el planteamiento correcto:  la planificación detallada como método para consegur que la ejecución fuera tal y como se había previsto, y se pudieran hacer las cosas bien(?) y a la primera. Mientras que en la nuestra, con eso de empezar con una idea general de lo que queremos, e ir descubriendo más por el camino, ni se puede planificar ni "na".

Y ahora el hallazgo anglo-sajón es la agilidad : Empezar a trabajar pronto, con una visión general e ir construyendo de forma iterativa, revisando y cambiando... Curioso.