Procesos Críticos en el Desarrollo de Software

Transcripción

1 Metodología Procesos Críticos en el Desarrollo de Software Pablo Straub AgileShift Imagine una organización de desarrollo de software que consistentemente cumple los compromisos con sus clientes. Imagine además que dicha organización establece compromisos que satisfacen las expectativas de sus clientes. Soñamos? No necesariamente. Lo que sí está claro es que esa organización está muy bien encaminada hacia la excelencia, porque tiene resuelto el proceso crítico asociado a la integridad de los compromisos con el cliente. Cuántos otros procesos son realmente críticos para el desarrollo de software? Los estándares o modelos de calidad como ISO9000 y CMMI presentan requisitos sobre un conjunto de procesos que deben estar bien definidos y controlados. Hay muchos procesos, pero cuáles son realmente los críticos para el negocio de software? En esta columna postulamos que lo realmente crítico se puede resumir en tres aspectos: integridad del producto, integridad de los compromisos y aprendizaje organizacional. Integridad de los compromisos Si la organización cumple sus compromisos consistentemente es muy probable que esté en buen pie para retener y aumentar su base de clientes, los que estarán dispuestos a darles su negocio debido a las buenas experiencias en proyectos anteriores, las que por desgracia no son tan habituales en el desarrollo de software. Para lograr hacer algo consistentemente es necesario tener procesos establecidos. De ellos, el que parece entonces más importante es el de la integridad de los compromisos con el cliente. De donde se sugiere que un proceso crítico es la Gestión de compromisos con el cliente, cuyo objetivo es asumir responsablemente compromisos relevantes con los clientes y cumplirlos. Pero es imposible en un proyecto mínimamente complejo cumplir con el cliente si los miembros de la organización no cumplen sus compromisos internos. De donde se sugiere que es también un proceso crítico la Gestión de compromisos internos, cuyo objetivo es asumir compromisos relevantes entre los desarrolladores y cumplirlos. Para poder gestionar los compromisos, tanto internos como los del cliente, resulta fundamental poder responder cuánto hemos avanzado: en qué estado está el proyecto. Esto sugiere que otro proceso crítico es Estado de avance, cuyo objetivo es saber en forma cabal cuánto hemos avanzado en nuestros compromisos. Como dijimos, la única formar de hacer todo esto en forma consistente es mediante procesos establecidos. Estos procesos pueden o no estar muy formalmente definidos. Lo importante es 1 de Pablo Straub

2 que las prácticas asociadas a ellos sean seguidas en forma disciplinada. Esto sugiere el cuarto proceso crítico: Verificación de prácticas y disciplina, cuyo objetivo es verificar que las prácticas estándares de la organización se siguen disciplinadamente, pero con criterio. En resumen, la integridad de los compromisos se logra con cuatro procesos críticos: Gestión de los compromisos con el cliente Gestión de los compromisos internos Estado de avance Verificación de prácticas y disciplina El proceso de verificación de prácticas y disciplina podría considerarse como un subproceso de la gestión de compromisos internos si asumiéramos el compromiso implícito de seguir disciplinadamente las prácticas. En todo caso, es un proceso separado porque estos compromisos trascienden el proyecto y cliente específicos, puesto que son más bien compromisos organizacionales. Si tenemos establecidos buenos procesos en estas cuatro áreas podemos decir que tenemos los proyectos bajo control. Pero eso no necesariamente significa que estamos haciendo buenos productos de software. Integridad del producto Un producto íntegro es aquel que es lo que queremos y decimos que es. Esto pareciera ser un trabalenguas o una adivinanza, pero no es esa la idea. El producto es lo que hemos dicho y lo que deseamos: satisface sus especificaciones y las especificaciones son pertinentes. Tener un producto íntegro es fundamental por a lo menos tres motivos relacionados. Primero, un producto íntegro es fundamental para cumplir compromisos asociados internos: si el producto es inestable, malamente podemos estimar el esfuerzo de hacer un cambio o completar un nuevo requerimiento. Segundo, la integridad del producto es en sí un atributo de calidad del mismo. Y por último, un producto íntegro es relativamente fácil de modificar a futuro. Para que un sistema sea íntegro es fundamental que sepamos qué debe ser y hacer el sistema. En otras palabras, necesitamos tener los requerimientos del cliente al día. Esto sugiere el proceso crítico de Gestión de requisitos, cuyo objetivo es tener un acuerdo actualizado sobre que es y qué hace el sistema. Pero obviamente no basta con decir qué hace el sistema: tenemos que saber que efectivamente lo hace. Esto se logra con pruebas, inspecciones, demos y otras formas de verificación y convalidación. Lo que sugiere el proceso crítico de Control de calidad, cuyo objetivo es establecer que el sistema es y hace lo que se espera de él. Como un sistema está compuesto de muchos archivos de documentos, código, datos, etc. que deben ser consistentes entre si, es fundamental asegurar esa consistencia. Esto no es simple debido a que los archivos están en constante evolución. Por otro lado, el sistema tendrá diversas versiones las que deben mantenerse concertadamente. Debido a esto, es crítico el proceso de Gestión de configuración, cuyo objetivo es mantener las distintas versiones del software en estado conocido y consistente. 2 de Pablo Straub

3 Recuadro: Integridad del producto y software heredado Usualmente se define como software heredado a aquellos sistemas viejos y complejos que son útiles a una organización porque tienen codificada una buena parte de sus procesos de negocios. Normalmente los sistemas heredados son muy caros de mantener, pero como son útiles no se pueden desechar. Lo que aquí se postula es que la principal característica de un sistema heredado no es ser viejo, sino ser poco íntegro. A un sistema íntegro será difícil llamarlo heredado, mientras un sistema relativamente nuevo pero poco íntegro pasará muy luego a esa categoría. En resumen, la integridad del producto se logra con tres procesos críticos: Gestión de requisitos Control de calidad Gestión de configuración Aprendizaje organizacional Hasta el momento hemos definido siete procesos que esperamos sean eficientes y efectivos para cumplir compromisos y producir un producto íntegro. Lo que hoy es bueno no necesariamente es bueno mañana. Para que estos procesos sigan siendo efectivos no sólo deben ser ejecutados consistentemente sino que deben ser mejorados en forma continua. En otras palabras, si tenemos una organización que hoy tiene buenos procesos y queremos mantenerla así debemos tener una organización que aprende. La primera forma de aprendizaje es mantener y mejorar el proceso organizacional. La idea del proceso organizacional es que cada proyecto no debe reinventar la rueda en relación a las metodologías, sino reutilizar procesos que han sido efectivos. Y obviamente esos procesos deben ser mantenidos. Esto da lugar al proceso crítico de Mejoramiento del proceso organizacional, cuyo objetivo es mantener un proceso organizacional eficiente y efectivo para ser utilizado en los proyectos. Dado que hay nuevos procesos y prácticas éstas deben ser enseñadas a todo el personal para que se pongan en práctica en forma consistente. Esto da lugar al proceso crítico de Entrenamiento organizacional continuo, cuyo objetivo es mantener al personal al tanto de las mejoras de proceso y nuevas prácticas de la organización. Normalmente este entrenamiento es más bien informal, especialmente en organizaciones pequeñas. Pero la informalidad no significa que no sea crítico o que no consuma recursos. Cuando la organización contrata nuevo personal es necesario que éste pueda ejecutar el proceso organizacional. Esto da lugar al proceso crítico de Entrenamiento de inducción, cuyo objetivo es preparar a los nuevos empleados para trabajar en los proyectos utilizando prácticas y disciplinas aceptadas. Normalmente este entrenamiento tiene una parte de estudio del proceso y una parte de trabajo guiado por un colega en los primeros meses de empleo. Una diferencia fundamental entre integridad de los compromisos e integridad del producto dice relación con el tiempo: el producto queda y los proyectos (compromisos) pasan. Desde el punto de vista del mantenimiento de software es fundamental que el producto sea íntegro, 3 de Pablo Straub

4 pero es irrelevante si los compromisos del proyecto inicial de desarrollo se cumplieron o no. Por otra parte, para facilitar el mantenimiento no basta que el producto sea íntegro: se necesita un equipo de personas que están al tanto del sistema y capacitados para mantenerlo. Esto sugiere el proceso crítico de Mantenimiento de sistemas vivos, cuyo objetivo es mantener disponible en algún equipo de personas el conocimiento tácito sobre cada sistema que debe ser mantenido. Este proceso, si bien es crítico, es consistentemente ignorado por los métodos rigurosos como ISO9000 y CMMI, que se basan sólo en la detallada documentación para facilitar el mantenimiento de sistemas. En resumen, el aprendizaje organizacional se logra con cuatro procesos críticos: Mejoramiento del proceso organizacional Entrenamiento organizacional continuo Entrenamiento de inducción Mantenimiento de sistemas vivos De éstos, los primeros tres son principalmente organizacionales, mientras que el último se ejecuta a nivel de los proyectos (en estricto rigor, secuencias de proyectos asociados a cada sistema). En todo caso, la responsabilidad por mantener los sistemas vivos es de la organización y no de un proyecto específico. Relación con CMMI La relación de estos 11 procesos críticos con el Modelo de Madurez de las Capacidades Integrado (CMMI ) se puede dar principalmente intentando clasificar cada una de las áreas de proceso de CMMI en una de esas tres categorías: IP para integridad de producto, IC para integridad de los compromisos y AO para aprendizaje organizacional. Algunas áreas de proceso están relacionados con dos clases de procesos críticos y otras no parecen ser tan críticas sino sólo de apoyo. La tabla siguiente hace esa clasificación para todas las áreas de procesos de los niveles 2 y 3 de CMMI. Los nombres de las áreas de proceso han sido traducidos por el autor. Nivel Área de Proceso Clase 2 Gestión de requisitos IP, IC 2 Planificación de proyectos IC 2 Seguimiento y control de proyectos IC 2 Gestión de acuerdos con proveedores IC 2 Medición y análisis 2 Aseguramiento de calidad de proceso y producto IP, IC 2 Gestión de configuración IP 3 Desarrollo de requisitos IP 3 Solución técnica IP 3 Integración de producto IP 3 Verificación IP 3 Convalidación IP 3 Enfoque en proceso organizacional AO 3 Definición de proceso organizacional AO 4 de Pablo Straub

5 Nivel Área de Proceso Clase 3 Entrenamiento organizacional AO 3 Gestión integrada de proyectos IC 3 Gestión de riesgos IC 3 Trabajo integrado de equipos IC 3 Gestión integrada de proveedores IC 5 de Pablo Straub