Implantando Prácticas de Arquitectura dentro de la Organización

Quienes hayan estado siguiendo las distintas entregas de ésta columna y que laboren en una organización de desarrollo de software en donde actualmente no se sigan prácticas maduras de arquitectura de software probablemente se preguntarán ¿de qué manera se puede introducir esto en mi organización? En esta columna hablaré de la implantación de prácticas de arquitectura de software dentro de una organización en base a mi propia experiencia.

Etapas del cambio
La introducción de técnicas de arquitectura de software en una organización representa una mejora o cambio organizacional que, dependiendo del tamaño de la organización y el alcance de los cambios, puede llegar a ser complicado. Por lo anterior, es conveniente realizar éste cambio siguiendo un enfoque disciplinado como el que se plantea en el área de proceso OPM (antes OID) de CMMi [1], particularmente en organizaciones de tamaño medio y grande. De forma general, las etapas que conforman un proyecto de mejora se muestran en la figura1 y se describen a continuación:

Figura 1.

Diagnóstico
El diagnóstico permite establecer una línea de base o punto de partida relativo al cambio mediante la identificación del estado actual de la práctica dentro de la organización. En relación con la arquitectura de software, es conveniente evaluar las siguientes dimensiones (que corresponden a las disciplinas del desarrollo de arquitecturas y al contexto organizacional) con preguntas como las que se muestran en la tabla 1.
La realización del diagnóstico permite elaborar un plan detallado del proyecto de mejora y, con base en este plan, se debe obtener aprobación y respaldo de la gerencia respecto a su ejecución. Ésta aprobación es el punto de revisión que permite continuar con el proyecto de mejora.

Tabla 1.

Propuesta
Esta etapa se enfoca en la definición de propuestas de mejora relativa a los procesos de la organización. En relación con la arquitectura, se enfoca en establecer métodos relacionados con el desarrollo de arquitectura de software específicos que estén alineados al contexto organizacional y partan del diagnóstico establecido.
Esta etapa es compleja, pues no basta simplemente con retomar métodos como los propuestos por el Software Engineering Institute (SEI) y adoptarlos “tal cual”. Un ejemplo de ello es el método de evaluación de arquitectura ATAM, que difícilmente puede es implantado en una organización relativamente pequeña. La adecuación de métodos de arquitectura de software debe considerar diversos aspectos que incluyen:

• El tipo de proyectos que se desarrollan dentro de la organización
• La metodología de desarrollo que se usa dentro de la organización
• El nivel de madurez de la organización en cuestiones de ingeniería de software
• Los recursos con los que cuenta la organización

Al final de ésta etapa se debe contar con una versión preliminar de métodos de desarrollo de arquitectura de software y, posiblemente, algunos artefactos asociados como pueden ser materiales de capacitación.

Piloto
Antes de permear una mejora a nivel organizacional, es conveniente realizar pruebas para 1) ver si las propuestas funcionan realmente en el contexto de un proyecto real y 2) corregir la propuesta en base a los resultados de la ejecución.
Esta etapa presenta varias dificultades, entre las cuales se encuentran el encontrar un proyecto real en donde se pueda probar algo que puede resultar totalmente nuevo, lo cual puede implicar ciertos riesgos. Otro aspecto relacionado con ésta problemática es que el proyecto de mejora se puede ver detenido pues se está esperando un proyecto para la realización del piloto. Una dificultad adicional es que la realización de un piloto requiere de un seguimiento cercano (o coaching) de los participantes en el proyecto y, principalmente, del arquitecto del equipo. Durante el piloto, el coach debe ser cuidadoso en cuanto a su nivel de involucramiento dentro del proyecto pues lo que se desea es que sea el arquitecto del equipo quien ejecute los métodos de arquitectura y no el coach.
Antes de iniciar el piloto se debe considerar la manera en que se realizará la evaluación del mismo. Esto es importante pues al final de esta fase debe haber un nuevo punto de revisión cuyo propósito es decidir si proseguir o no con la implantación de la mejora en base a la experiencia obtenida.

Implantación
En la etapa de implantación, las mejoras que fueron probadas durante el piloto y que han sido corregidas en base a los resultados del mismo, son permeadas a toda la organización. Esta etapa puede ser bastante compleja pues involucra entre otras cosas:

• Modificar los procesos organizacionales
• Desarrollar y ejecutar capacitaciones
• Proporcionar soporte a quienes hacen uso de la mejora

La implantación de la mejora es una fase que puede tomar un tiempo considerable. La capacitación de la gente se tiene que hacer de forma gradual conforme la gente vaya arrancando nuevos proyectos en donde se pretenda utilizar la mejora, que en este caso son los métodos de desarrollo de arquitectura de software. Respecto a la arquitectura, es conveniente que dentro de la organización haya un “champion” que esté velando de forma continua que se usen los métodos de desarrollo de arquitectura de software de manera adecuada y que tenga la disposición de resolver dudas.
La evaluación de la implantación, que es el punto de revisión al final de la fase, se enfoca en medir los efectos de la implantación de una mejora y, en este caso, de los métodos de arquitectura de software. Evaluar éstos efectos no es una tarea simple, sin embargo, algunas métricas que pueden ser interesantes para este efecto son:

• Defectos relacionados con arquitectura de software antes y después de la introducción de los métodos de desarrollo de arquitectura (se esperaría ver un decremento de éste tipo de defectos)
• Cambios en tiempos de pruebas (se esperaría ver una reducción de tiempo pues se realizan más actividades de diseño)

Cabe señalar que para poder medir estos efectos, se requiere que la organización en donde se va a implantar la mejora tenga datos históricos que puedan usarse como punto de referencia.

Seguimiento
El seguimiento se enfoca en mejorar continuamente el cambio que ha sido implantado exitosamente con el fin de corregirlo y adaptarlo a la evolución que existe en la organización. En ésta etapa, el “champion” sigue jugando un papel importante pues debe velar que la mejora no se diluya y que las actividades de desarrollo de arquitectura no comiencen a ser realizadas de forma mecánica como desafortunadamente sucede de forma frecuente con los procesos de desarrollo de software.

En conclusión
La introducción de cambios dentro de una organización, tales como métodos para desarrollar arquitectura de software, es una tarea compleja y particularmente si la organización en donde se pretende realizar este cambio es de tamaño considerable. Un proyecto de mejora como éste es, sin embargo, necesario si se desea que la organización madure respecto a sus prácticas de desarrollo de arquitectura. En organizaciones pequeñas la tarea puede resultar más simple, sin embargo, el reto ahí es lograr adaptar los métodos para trabajar en ambientes ‘reducidos’. Un aspecto importante para lograr la implantación de la mejora es tener apoyo de la gerencia.

Referencias:
[1] Chrissis, M. B., Konrad, M. y Shrum, S. “CMMi for Development: Guidelines for Process Integration and Product Improvement”, Addison-Wesley Professional, 3d Edition, 2011