ESENCIA y su uso para reforzar la gestión de los proyectos de software

En el número anterior les prometí hablar de cómo usar ESSENCE (lo voy a traducir como Esencia, que suena muy bonito) en la vida diaria de los proyectos de software.

El concepto básico de la Esencia es algo llamado ‘alfa’. Su uso puede reforzar tanto la gestión tradicional de proyectos (PMBoK) como la ágil.

¿Qué es un alfa? Como lo explican Ivar Jacobson y sus allegados, es una cosa con la cual se tiene que trabajar, o en otras palabras, puntos que hay que tener muy presentes en todo momento durante un proyecto (endeavor) de desarrollo de software.

Los alfas captan los conceptos clave recogidos de la experiencia de los últimos casi 50 años de la Ingeniería de Software. No por nada, la propuesta está liderada por Ivar Jacobson, uno de los gurús más viejitos pero de estos que siguen “coleando”. Los alfas permiten dar seguimiento, evaluar el progreso y la salud de cualquier proyecto de ingeniería de software y proporcionan una base común para la definición de los métodos y prácticas de ingeniería de software.

Esencia identifica siete alfas las cuales se ubican en tres áreas de interés: cliente, solución y esfuerzo (equivalente a un proyecto). Esto se ilustra en la figura 1:

• Área del Cliente. Contiene los alfas de oportunidad (opportunity) e interesados (stakeholders).
• Área de la Solución. Contiene los alfas de requerimientos (requirements) y sistema de software (software system).
• Área del Esfuerzo/Proyecto. Esta área considera los elementos para realizar el proyecto tales como equipo (team), forma de trabajar (way of working) y trabajo (work).

Figura 1. Alfas por áreas de interés y sus relaciones.

En el área del cliente, la oportunidad representa todo lo que le da el valor al que va a invertir en el sistema. Los interesados son principalmente los que necesitan y pagan por el sistema de software, así como los que lo usarán y mantendrán.

En el área de solución no requiere mayor explicación. Lo que sí vale la pena notar es que el diseño no está explícito, sino que está “perdido (diluido) en el espacio”. En mi opinión creo que fue una concesión a los agilistas (por favor que éstos no se me ofendan).

El área de esfuerzo afortunadamente contempla a las personas (equipo), sin ellas todo lo demás es imposible ☺ (disculpen el uso exagerado de las ☺ pero últimamente ando en la onda de las UX). El alfa de la forma de trabajar es, ni más ni menos, el proceso que se va a seguir (favor de no decírselo a nadie, menos a su gestor de procesos ☺).

En resumen, el alfa de Trabajo representa la chamba del Equipo que aplica la Forma de Trabajar para implementar el Sistema de Software, que cumpla con los Requerimientos acordados por los Interesados, con el cual se logra la Oportunidad.

Esta es la esencia de los alfas de la Esencia. Pero el meollo del asunto está en que cada alfa pasa por una serie de estados secuenciales. Dichos estados reflejan la evolución deseada de los temas de los alfas desde el inicio hasta la final de un proyecto. Por ejemplo, un Equipo pasa por los estados: Sembrado, Formado, Ejecutando, Colaborando y Suspendido (este último es cuando ya el equipo dejó de trabajar en el proyecto). Y ¿cómo saber en qué estado se encuentra un alfa? Para ésto se han definido las listas de verificación (checklists) que ayudan a analizar si cumplimos los criterios para colocar un alfa en cierto estado. Estas listas de verificación de los estados de los alfas son, en mi opinión, la síntesis más importante hasta la fecha de la experiencia práctica de la Ingeniería de Software. Otra característica interesante, es que son independientes a las metodologías; no dependen de las técnicas ni procesos particulares.

Para ejemplificar, les presento la lista de verificación para constatar si el alfa del Equipo está en el estado Sembrado:

• La misión del equipo ha sido definida en términos de las oportunidades y resultados.
• Se conocen limitaciones al funcionamiento del equipo.
• Se conocen los mecanismos para hacer crecer al equipo.
• Está definida la composición del equipo.
• Están definidas las restricciones sobre dónde y cómo se llevará a cabo el trabajo.
• Están descritas las responsabilidades del equipo.
• El nivel de compromiso del equipo es claro.
• Se identificaron competencias requeridas.
• El tamaño del equipo está determinado.
• Reglas de gobierno están definida.
• Se seleccionó el modelo de liderazgo.

La práctica de reflexión

Pero me van a preguntar: ¿cómo podrían usarse los alfas, sus estados y las listas de verificación para reforzar la gestión de proyectos? La propuesta más simple es agregar las reuniones de reflexión, que se apoyen en los alfas, para complementar a las reuniones de seguimiento o reuniones diarias de Scrum.

La práctica de reflexión es la siguiente, descrita como lo propone Kuali-Beh (apéndice B de Esencia [1]).

Nombre: Reunión de Reflexión con Alfas de Esencia (Id ReflexAlfas).

Objetivo: Analizar la salud del proyecto de software usando alfas para proponer las acciones que ayuden a continuar el proyecto con éxito.

Entradas: Se reúne todo el equipo, se eligen los alfas con las se quiere trabajar (pueden ser todas o las que son importantes para el momento del avanze del proyecto), se ponen en la mesa las tarjetas impresas con los nombres de los alfas, nombres de los estados y las listas de verificación de cada estado (ver ejemplo en la fig. 2). Existen las opciones electrónicas para revisar los estados de las tarjetas en web - essence.sv.cmu.edu y la aplicación State Explorer para iPhon.

Guía de actividades

1. Para cada alfa elegido, cada miembro del equipo revisa en su cabeza las listas de verificación de los estados y decide el estado alcanzado según él.
2. Todos los miembros del equipo comparten su decisión con los demás argumentando con base en las listas de verificación.
3. En el caso de discrepancia de las opiniones, se discuten hasta lograr el consenso los elementos de las listas de verificación en los que no coinciden. En este paso se ejercita la idea de la democracia- todos tienen derecho de opinar, y de no perder el foco- sólo se discuten cumplimientos de los puntos de las listas de verificación y no los clásicos de echar la culpa unos a otros.
4. El equipo analiza cuáles de los objetivos de la lista de verificación del estado siguiente quiere alcanzar y qué acciones deben de tomarse para lograrlos.

Criterios de verificación: Todos los miembros del equipo están conformes con la evaluación de los estados alcanzados y de las acciones a tomar para avanzar a los siguientes estados.

Mediciones: Tiempo dedicado a la reunión de reflexión (horas/hombre).

Resultado:

• Lista de acciones para incluir en el plan de trabajo inmediato.
• Todos los miembros del equipo conocen el estado actual del proyecto (o un aspecto representado por un alfa) y están de acuerdo en lo que hay que hacer para avanzar con éxito en el proyecto.

A los administradores de proyectos o Scrum Masters que no se han convencido con mi explicación, les recomiendo que primero hagan este ejercicio solitos. Con quienes he visto que lo han intentado, les ha caído el veinte luego, luego (para los lectores de otros países “caer el veinte” significa entender y convencerse).

La ventaja de esta propuesta es que con pocos elementos (alfas, sus estados y listas de verificación para alcanzar los estados) tenemos resumida la sabiduría práctica de 50 años de la Ingeniería de Software lista para usarse. Qué la disfruten ☺.

Para experimentar con Esencia es suficiente leer la sección 8 del documento gratuito [1]. Para los que necesitan más explicación pueden buscar el libro The Essence of Software Engineering, Applying the SEMAT Kernel, de Ivar Jacobson y sus colegas [2] o comunicarse con Jorge López de Nueva Librería (jorge.lopez@nuevalibreria.com.ar) para conseguir la traducción al español.

No se pierdan el siguiente capítulo de la aplicación de Esencia.

>> Por Hanna Oktaba

Referencias

[1] ESSENCE - Kernel and Language for Software Engineering Methods 1.0 - Beta 2 http://www.omg.org/spec/Essence/1.0/Beta2/

[2] Ivar Jacobson and all. The Essence of Software Engineering: Applying the SEMAT Kernel, Addison-Wesley, 2013.