icebergHay proyectos que gestionan los requisitos con una pila de producto, y otros emplean un SRS (Software Requirements Specification).

La pila de producto es un formato ligero de documentación empleado en gestión ágil, mientras que el SRS es un modelo formal para la especificación requisitos de un proyecto de software empleado en gestión predictiva. Pero la característica que diferencia a los dos modelos de gestión no es el usar pilas de producto o documentos de requisitos.

 La clave no está en las prácticas que emplean los modelos de gestión, sino en los principios en los que éstas se basan.


En este caso, el principio ágil que está en la base es: “desarrollo incremental”. La agilidad produce y entrega el resultado en incrementos, siguiendo la evolución y concreción parelela de los requisitos. Por esa razón resultan más apropiados formatos como pilas de producto, que facililan la adaptación continua de los requisitos.

La gestión de un proyecto no es ágil por emplear prácticas ágiles, sino por aplicar principios ágiles. En este caso, la agilidad del proyecto no se debe al uso de una pila de producto, sino a realizar el desarrollo de forma incremental.

De esta forma, la agilidad en la en la dimensión operativa (agilidad técnica) se debe a los principios de gestión empleados, y éstos se llevan a cabo mediante prácticas de trabajo. Cuanto más apropiadas al tipo de proyecto y empresa sean las prácticas, y mayor el conocimiento y la experiencia de las personas que las ejecutan, mayor será el grado de agilidad técnica.

 

agilidad: principios valores y soporte

 

 

no ganttHay dos estrategias habituales para planificar y seguir el avance de un proyecto, que no se deben emplear en scrum.

La primera es calcular la duración de las tareas empleando unidades de tiempo concretas para predecir la ejecución como si fuera un proceso, y dibujarla en un diagrama de Gantt.
Esta estrategia es coherente para planificar trabajos "mecánicos": trabajos compuestos por actividades de ejecución procedimentada, pero no es adecuada para trabajos del conocimiento ni para trabajos creativos.

novela gantt

 

 

fractalEn la empresa conviven dos dimensiones: la operativa, que realiza los productos o servicios de la compañía; y la organizativa, que define y gestiona la cultura, estructura y modelo de gobernanza con el que se dirige .

A menudo se aborda la agilidad conjuntamente en las dos dimensiones, introduciendo modificaciones tanto en la gestión de proyectos y procesos de desarrollo, como en la cultura y modelo de gobernanza  (Agilidad en la empresa: ¿en el producto, en la cultura o en todo?).

Al considerar que la agilidad implica cambios operativos y organizativos de forma simultánea, no se valora por separado:

a) Si el producto servicio o proyecto de la empresa se puede construir de forma evolutiva, y si el hacerlo proporciona ventajas a los clientes o la comercialización.
b) Si la propiedad de la empresa desea cambios en la estructura o en el modelo de gobernanza, y si es consciente de las implicaciones de esos cambios.

Cuando lo que se quiere es crear entornos potenciadores de creación de valor, basados en las personas y su motivación, pero no se necesita o no se puede entregar de forma incremental, hacer ágil la empresa no consiste en institucionalizar prácticas de desarrollo evolutivo, sino estructuras organizativas fractales y modelos de gobernanza dinámica. Es el caso, por ejemplo, de AES (sector energético, 40.000 empleados), Heiligenfeld (Hospitales de salud mental, 600 empleados) o Zappos.com (venta de zapatos on line, 1.500 empleados)  Laloux, F. (2016).



Estructuras fractales

Margaret Wheatley introduce en 1992, el concepto de organización fractal (Wheatley, 1992).

Las mejores organizaciones tienen una naturaleza fractal... El patrón de su comportamiento es coherente y predecible... Las organizaciones fractales, aunque jamás hayan oído hablar del término fractal, han aprendido a confiar en fenómenos naturales de organización"


Vas al comité:
—Entonces la decisión es esta.
—¿Pero esa decisión?
—La ha tomado Franken & Goursen.
Cuantos más apellidos tenga la consultora, más chula es la decisión; más millones inviertes.
—¡Franken & Goursen & Young!, ¡joder, pues hay que tomarla!
Luego si la decisión sale bien, te pones una medalla. La decisión es un análisis, un "benchmark"; se tiene que llamar "benchmark" no se puede llamar análisis, o... (ni me sale la palabra en español de benchmark) bueno, un contraste, ¡o como sea!
Entonces, si la decisión sale bien, te pones una medalla. La empresa se pone una medalla porque ha hecho lo que todo el mundo sabía. Si la decisión sale mal:
—¡Pero tío, han sido los consultores!
Y vas a los consultores, a los "Fransen & Goursen & Young":
—No, has implementado mal, porque el mercado ha hecho esto y ha funcionado.
Es la cobardía de que no puedes tomar una decisión que sea diferente o que sea natural por el mero hecho de que te van a poner en la calle.
Entonces si quitas todo eso la gente vuelve a descubrir un mundo normal:
—¿Y esta decisión?.
—Pues porque yo creo que es la correcta.

De la mesa redonda de Agile Spain 2014 - Pedro Serrahima - Director General Grupo Globalia.

bricks"¿Te comprarías una casa nueva en construcción sin haber visto los planos? Seguramente la respuesta es no. De hecho, seguro que al vendedor le exiges que te muestre los planos a escala de lo que va a ser tu nueva vivienda"... "Sin embargo, hasta hace poco la situación con las aplicaciones software no era así. Aunque en algunos casos la inversión en un sistema software podía ser superior al precio de una vivienda, a los ingenieros de software no se nos exigía que entregásemos los planos de la aplicación antes de empezar a construirla."

Esta cita es de un artículo publicado el pasado 21 de noviembre en El País. Una muestra de que en 2016 la Ingeniería del Software continúa insistiendo en que los programas se deben construir con la misma planificación que las casas.

Pero no nos engañemos, queremos tener los planos completos desde el principio y saber cómo va a ser toda la casa, porque es algo que nos van a entregar en una sola vez, cuando esté completamente terminada y que luego no podremos modificar.

Si las casas no fueran estructuras físicas de cemento, sino lógicas, el razonamiento sería algo así:

¿Comprarías una casa si te obligaran a firmar un proyecto con las dimensiones y todos los detalles cerrados, como si fuera un contrato en el que no pudieras cambiar nada. Y que si a mitad vieras que el comedor resulta pequeño no pudieras ampliarlo moviendo el muro exterior y quitando un poco de jardín, o incluso si necesitaras más, no pudieras pedir una planta subterránea con una bodega?
¿Comprarías una casa si te dijeran que no te la van a entregar hasta que esté toda terminada? Que no te van a dar primero el dormitorio y el baño para que puedas tener cuanto antes un mínimo viable, y luego mes a mes te irán entregando o modificando las partes que tú quieras hasta que decidas que ya está terminada.

Falacia: argumento que parece válido, pero no lo es. Algunas falacias se cometen intencionalmente para persuadir o manipular a los demás, mientras que otras se cometen sin intención debido a descuidos o ignorancia. En ocasiones las falacias pueden ser muy sutiles y persuasivas, por lo que se debe poner mucha atención para detectarlas.

(Wikipedia, Falacia, dic 2016.)

 

encaje

proyectoProyecto

Conjunto de actividades necesarias para lograr un resultado único y definible.

Proyecto delimitado1.- Proyecto delimitado

El que tiene como objetivo conseguir un resultado inicialmente acotado, claramente definido, y sin previsión de modificaciones sustanciales de la definición inicial durante la ejecución. Ejemplo: Construcción de una casa.

proyecto progresivo2.- Proyecto progresivo

El que tiene como objetivo conseguir un resultado partiendo de su idea general, que se desarrolla y perfila durante la ejecución del proyecto. Ejemplo: Construcción de una plataforma de servicios TIC on line.

 

gestion proyectosGestión de proyectos

Conjunto de las actividades organizativas de un proyecto con las que se gestiona la ejecución para lograr el mayor grado de éxito.
El éxito de los proyectos delimitados se basa en conseguir el resultado definido, con los recursos previstos y sin incumplir la fecha de fin prevista, mientras que en los proyectos progresivos consiste en la entrega temprana del mayor valor posible, y su incremento continuo y frecuente.

predictivo icon3.-Gestión predictiva

Aplicación de métodos y prácticas para lograr el éxito en los proyectos delimitados.

scrum icon4.- Gestión evolutiva

Aplicación de métodos y prácticas para lograr el éxito en los proyectos progresivos.

 

programaPrograma

Conjunto de proyectos que comparten o colaboran en el logro de un objetivo común. Los programas se pueden clasificar en delimitados o progresivos, siendo delimitados a aquellos que comienzan con la definición detallada del resultado, un tiempo de ejecución conocido y acotado. Los programas progresivos, comienzan con una definición general e incompleta del resultado final, que se desarrolla durante la ejecución; también pueden no  tener especificada la fecha de fin, de forma que se ejecutarán hasta que se decida concluirlos, o reemplazarlos.