¿CMMI o AGILE? ¿Juntos es posible?

CMMI tiene una carga y una exigencia que equipos conformados AGILE (típicamente pequeños) no pueden soportar, simplemente por que no tienen la estructura de personal. Al menos eso sucede con equipos para SCRUM.

Ejemplos sencillos son las exigencias de CMMI-2 sobre las Áreas de Proceso “Planificación de Proyectos” y “Aseguramiento de Calidad”, donde están vigentes los “Procedimientos de Planificación de Proyectos” y “Procedimientos de Estimación y Presupuestación”, como los “Procedimientos de Planificación de Calidad” y “Procedimientos de Auditoria y Revisiones”.

Estas solas áreas de procesos exigidas por CMMI-2 y sus correspondientes procedimientos pueden poner "en jacke" a quienes sostienen que con un equipo pequeño es posible certificar CMMI-2 o 3, dado que para solo cumplimentar las prácticas específicas para esos dos procedimientos que mencionas, necesitas de un equipo QA completo y al menos dos niveles de gerencia para escalar las aprobaciones.
La Planificación de Proyectos para CMMI es lo que me parece crítico y no es fácilmente adaptable a equipos SCRUM, por que es necesario formar y tener aprobado el Cronograma del Proyecto, lo cual por si mismo significa haber confeccionado un Plan de Iteraciones, Plan de Participación de los Interesados y un Plan de Integración, más un Plan de Riesgos, un Plan de Decisiones Técnicas y un Plan de Capacitaciones o certificar en una matriz de capacitaciones organizacionales, que para iniciar el proyecto el equipo del proyecto tiene las habilidades requeridas.
En lo que a calidad se refiere, debe existir documentación objetiva y sólida confeccionada por el Líder de Proyecto (no Gerente de Calidad ni Líder de Testing) sobre los Objetivos de Calidad y Performance y eventualmente utilizar procedimientos de Gestión de Cambios para modificar requerimientos u objetivos de calidad cuando existen contraposiciones y Procedimientos de Análisis y Toma de Decisiones para establecer esos cambios. Finalmente se debe registrar cuales objetivos se gestionarán estadísticamente.
Si quieres podemos hablar de las revisiones por pares, las cuales no están referidas a (pair programing) sino que son prácticas específicas para un muy alto porcentaje de los productos de software generados.
Todas estas decisiones, principalmente Gestión de Cambio y Toma de Decisiones, se realizan por comité organizacional.
Si considero interesante y posible que la agilidad se puede insertar en toda la organización con prácticas como SCRUM (…muchas otras…según), pero debemos conseguir de una vez por todas que nuestras soluciones de consultoría Agile trasciendan el ámbito del área de desarrollo, por que lamentablemente hasta el día de hoy son pocas las organizaciones que lograron traspasar esa barrera en las organizaciones de envergadura mediana o grande.
Un simple ejemplo es que ni a duras penas logran unificar un criterio para establecer prácticas en Testing o sostener un circuito de auditorías de calidad, sin pretender absorber este departamento QA hasta hacerlo desaparecer para conformarse en el equipo de desarrollo.
Para acercarme a una conclusión, estoy seguro que la simplificación de los procesos debe hacerse concienzudamente, sin ofrecer a las organizaciones "recetas de menudencias" que en un principio parecen ser buenas, pero a la larga podrían dejar el sabor insípido de la pérdida de prácticas que alimentan la base del conocimiento organizacional.

Advertisements

CMMI/Agile. Un híbrido que se viene – III

Si estamos de acuerdo, podremos admitir que la agilidad es buscada por cientos de industrias hace varias décadas y la industria del software es nada más que un aprendiz de otras mucho más desarrolladas.

El concepto de agilidad está trascendiendo las fronteras de los modelos desarrollados hasta el día de hoy, tanto es así que cada una de las organizaciones que deciden adaptar su modelo de producción, no lo hacen bajo una modalidad pura y prefiere hacerlo bajo un contexto de hibridez.

"Ambos mundos" (Waterfall – Agile), si es que se les quiere diferenciar, aportan herramientas valiosísimas al desarrollo del software.

Según comentarios, empresas puramente CMMI5 decidieron hacer pruebas pilotos con gestión SCRUM y desarrollo XP.

Los informes internos indicaron la detección de prácticas comunes con variaciones o simplificaciones por parte de SCRUM principalmente, pero también en XP. Es decir que con un espíritu diferente quizás, CMMI ya contaba con ciertas prácticas que “debieron recortar” para hacer las adaptaciones. El pasaje fue prácticamente limpio.

Los informes indicaron que con una concepción diferente, es posible que el modelo Agile en piloto, sea más adecuado para el objetivo de velocidad y respuesta a los cambios, pero no para el objetivo de repetitividad, métricas y mejora continua, mucho menos para la  transmisión de la ingeniería del producto y servicios, a otros equipos diseminados por el mundo.

Estas conclusiones restringidas a un ámbito privado de la organización, permitieron a los evaluadores realizar recomendaciones para adaptar las prácticas del modelo CMMI, tomando como referencias algunas buenas prácticas de XP para desarrollo y SCRUM para gestión, considerándolos en su modo puro, inconveniente para la organización.

Claro que el equipo piloto adoptó las prácticas Agiles guiados por la "documentación estrictamente necesaria" y focalizándose en la codificación, eliminando mucha información que la organización estaba acostumbrada a llevar, no solo para conocer el estado del proyecto, sino también para conocer el estado de la organización, donde los proyectos activos superan el número de cien (100).

Mi apreciación personal es que las metodologías puras no van a subsistir modificándose para dar surgimiento a lo que se conoce como metodologías híbridas y necesariamente, solo por lógica, serán la conjunción de las mejores prácticas de "ambos mundos" (Waterfall .  Agile).

Inicialmente Agile pareciera haber reaccionado a lo estructurado y predictivo de Waterfall, pero actualmente veo como Agile tiene adeptos rígidos a quienes les cuesta hasta interiorizarse de otras metodologías con más estructuración. También observo axiomas puristas en los que imparten ideas, descartando de llano la conjunción, las mixturas, lo adecuado a cada organización y en sus funciones de facilitadores podrían quitar de raíz prácticas avaladas con éxito en las organizaciones.

En contrapartida veo a gente del mundo Waterfall adaptando las propuestas del mundo agilista, sin dejar de lado el espíritu de la mejora continua basada en procesos.  

La evolución no se detiene, pero no vaya a ser que los que verdaderamente revolucionen la industria del software, sean los ágiles nacidos de las metodologías Waterfall.

Sea como sea nos conviene a todos.

El costo de nuestros proyectos de software – Sacar el mejor provecho según el tipo de contrato

Creo que el software y su faceta de intangible no es el problema en si mismo, sino la incapacidad que tenemos de generar modelos, métodos y técnicas de estimación en nuestra organización, que nos ayuden en esta problemática.

Las organizaciones, principalmente las PyMEs no tienen un interés bien marcado en desarrollar un estudio de sus fuerzas de producción, de los modos de utilización de sus recursos humanos y tecnológicos, y de esa manera reconocer su tiempo de respuesta, su grado de calidad, su efectividad en las soluciones generadas. Esto lleva a La Gerencia a tener creencias infundadas para establecer los contratos con sus respectivos costes y tiempos de finalización.

Las consecuencias de trabajar bajo creencias y sin lo empírico de un modelo propio de estimación, son catastróficas, principalmente para el equipo de proyecto que normalmente se encuentra ante un proyecto "vencido antes de iniciar". Hay que inyectar horas hombre para corregir los desvíos embebidos al proyecto durante los negociados de nuestros comerciales y gerentes.

En mi experiencia personal, me ha tocado trabajar en proyectos "perfectamente estructurados", bajo metodologías Waterfall y con amplio detalle previo al desarrollo y obtener al final resultados poco deseables, donde hubo que utilizar horas de la franja de garantía y soporte, para corregir los desvíos. Esto implicó decir verdades parciales a los clientes y entregar versiones incompletas, con deuda técnica que se fue corrigiendo en desfase.

También me ha tocado trabajar bajo metodologías Agile con requisitos mucho menos detallados, con planificaciones flexibles y dinámicas obtenidas casi instantáneamente en las reuniones del equipo de trabajo y también obteniendo en la mayoría de los casos un cierto porcentaje de error en lo que se entrega.

En ambos casos el fracaso es inminente, pero lo importante de ambas situaciones, es a cual le puede sacar mejor provecho.

Entonces aquí el dilema de los tipos de contratos, donde claramente puedo diferenciar, por un lado contratos rígidos orientados al control de los hitos según la planificación Waterfall, cuyos productos/servicios tienen una alta probabilidad de ser menos apreciado por nuestro cliente al ser recibido y un alto esfuerzo de parte del proveedor para re establecer cursos del proyecto en etapas tardías, respondiendo con horas de garantías y soporte para ser utilizadas en desarrollo de correcciones o modificaciones.

A este tipo de proyectos, bajo este tipo de contratos, independientemente de la planificación detallada e inclusive de una ponderación de costos bastante bien aproximada, es difícil añadirle valor agregado.

Por otro lado están los "contratos incrementales" (acabo de inventar el término) que no facilitan el control hito por hito, pero si implican entregas a corta data, donde el cliente ya puede ir valuando sus productos/servicios en porciones que puede modificar, agregar o descartar y el proveedor obtiene un feedback casi inmediato y puede ejecutar correcciones sobre el curso de los proyectos, hacerlos crecer o disminuirlos dinámicamente, según el contexto contractual.

Entiendo que para este tipo de contratos, las estimaciones y ponderación de los costos del proyecto tienen que ser obtenidas de una manera distinta, pero igual de empírica que con otros tipos de contratos.

Como ventajoso, veo que para cada incremento del producto/servicio, el valor agregado puede ser sustancialmente más alto cada vez que se entrega, principalmente al encontrarnos en etapas cercanas a la finalización del proyecto, donde la expectativa de cierre es alta, la tasa de errores ha caído abrumadoramente y las fases de garantías y soporte recién comienzan a ser negociadas, donde tal vez ya se está negociando la versión posterior.

Agile. La evolución de las metodologías tradicionales?

“Agile se ha vuelto tan popular entre los profesionales del software, que muchos se abstienen de criticarlo por miedo a ser etiquetados como “retrazados”, “de la vieja escuela”, o incluso “estúpido”.
Afortunadamente los profesionales IT con experiencia saben mejor y reconocen las limitaciones de Agile”

Así rezan las las declaraciones en un blog de Project Management, bastante conocido TheProjectManagmenteHut

Agile fue creado en gran parte en reacción al modelo predominante, WATERFALL, y en menor medida al resto de las tradicionales metodologías y aunque está en boca de todos y en manos de muchos, Agile hasta el día de hoy no ha demostrado ser superior a estas metodologías que le dieron razón y motivo para su existencia.
De hecho existe amplia y variada información que puede avalar tanto el éxito como el fracaso de las metodologías tradicionales, más su acoplamiento con los modelos y estándares de calidad reconocidos mundialmente y las culturas organizacionales más importantes del mundo, inclusive hablando de la industria del software.

Aunque no prentendo ser defensor de lo indefendible, ni “abogado del diablo” de Agile, es conveniente hacernos las siguientes preguntas:

  • cuando Agile es comparable con metodologías tradicionales?
  • cómo podemos combinar Agile con procesos tradicionales para abordar mejor una situación concreta?

Para responder a estas preguntas, es mejor reconocer las limitaciones de Agile

Un equipo de estrellas

Agile ha sido diseñado por experimentados y para experimentados.
Este es un aspecto a considerarse si se ha de intentar una incursión en las metodologías Agile, no como regla general, sino como un ítem de peso, sobre todo si se debe sostener el concepto de “equipo autogestionado”.

En lo personal y por la experiencia de participación en equipos Waterfall y en equipos en búsqueda de la agilidad, puedo decir que es mucho más dificil adaptarse a procesos Agile que a los procesos Waterfall, inclusive si se sigue un modelo de calidad como CMMI.

En los procesos Waterfall, el atributo de “equipos autogestionado” no es remarcable y aunque puede existir mucho trabajo individual, se hace bajo las premisas estrictas de la planificación, siguiendo los métodos y técnicas sugeridas y aceptadas por la organización. No se hace de otro modo o no lo estarías haciendo correctamente.

En estos procesos tradicionales, es cierto que existe también una gran carga administrativa pero en realidad no todos están afectados por ella y solo lleva una porción pequeña de tiempo y a muy baja complejidad realizarlas, principalmente para quienes no lideran los proyectos y solo rinden su progreso del día.

En los equipos Ágile, es un tanto más complicado la adaptación de las personas, siempre hablando de aquellas que no tienen la experiencia suficiente y el tren de trabajo disciplinado sin controles estrictos.
Aquí las entradas de algunos son fuertemente dependiente de las salidas de otros, no existe un trabajo individual o “individualista”, o no debería existir.

Las técnicas de gestión de tareas tradicionales pueden perder por completo su sentido y también debe existir una readaptación del mecanismo de estimación, de equilibrio de carga y del seguimiento. Los controles aunque parecieran ser menores, en realidad se incrementan por que el ciclo de vida en si mismo es mucho más corto y los cambios se presentan con mayor velocidad, pero parecieran ser de otra naturaleza y los resultados deben ser inmediatos, como también deben ser inmediatas las correcciones y a gran velocidad para que en la misma jornada laboral se tenga una aproximación del resultado, cuando no el resultado en si mismo.

El cáos está siempre al acecho…pero en que proyecto no lo está? La diferencia es la velocidad de detección de los inconvenientes, el análisis del problema y las soluciones, más su implementación, verificación y/o validación.
Entonces, preguntas simples pueden ser:

  • Tiene tu equipo el potencial para Agile?
  • Tienes el potencial para Agile?
  • Tienes la materia prima en las personas, para formar un equipo Agile?

Si la respuesta es “no” a algunas de estas preguntas, no significa que no puede transformase en Agile, solo quiere decir que puede haber algunos pasos intermedios a tomar antes de llegar allí.

Estos pasos suelen incluir la adaptación de la cultura del trabajo por equipos y la progresiva potenciación de los individuos, la formación y la contratación de las personas adecuadas.

Encaje con la cultura organizacional (los procesos son secundarios a la gente)

Habilitar el comportamiento Agile requiere de una gran dosis de libertad individual (no individualismo) y de equipo, que se traduce en una cruz funcional en constante adaptación del trabajo y funciones de conmutación, según sea necesario.

Se trata también de ajustar continuamente los procesos a fin de reflejar la situación actual. Más que nada, significa que los procesos son secundarios a la gente.

Otras organizaciones hacen incapié con estrechéz en los roles y responsabilidades, políticas y procesos, y han sido la clave de la supervivencia las mismas.

Aunque estas empresas estén bastante alejada de las dogmas de la agilidad, no es imposible que algunas unidades puedan realizar un trabajo diferenciado para experimentar, conocer y adaptar el nuevo paradigma.

Dado que la innovación es parte de la cultura de cualquier organización exitosa, entonces las personas que la integran tienen buenas habilidades y potencial para realizar “adaptaciones situacionales” y saltar de un modelo a otro.

Agile está restringido a equipos pequeños

  • Los equipos deben ser autogestionados, lo cual implica un orden eficiente emergente de un caos temporal. Este tipo de adopción del orden será mucho más prolongado en equipos grandes y perdería efectividad.
  • Los miembros del equipo de trabajo deben estar habilitados para comunicarse entre ellos espontáneamente, e inclusive con clientes y otros interesados en los proyectos.
  • La gestión diaria del equipo depende por completo de todo el equipo y no está centralizada en una sola persona. Es necesario el reconocimiento y visualización por parte de todo los miembros del equipo, de los cronogramas, tareas, cambios, impedimentos, etc.
  • Los miembros del equipo deben conocer exactamente que es lo que otros miembros están realizando, ayudar a otros que el proceso de su trabajo sea fácil, en forma colaborativa y sin un control centralizado.
  • Los miembros del equipo deben trabajar en la misma locación, facilitando el trabajo cara-a-cara y fortaleciendo los canales de comunicación inmediatos, sin tener las limitaciones típicas de las distancias, diferentes horarios e inclusive herramientas de gestión.

    Lo que se quiere expresar con estos puntos, es que equipos que superan un cierto límite en el número de integrantes (típicamente ocho) pierden eficiencia en las habilidades comunicacionales requeridas para equipos Agile. Así mismo la tarea de un Scrum Marster, se vería dificultada si tuviera que gestionar tareas, avances e inconvenientes de más cantidad de miembros y otros atributos como conocer las tareas y actividades entre todos los miembros se verían cada vez más en merma.

    Una forma de adaptación de equipos mucho más grandes, sería la división del mismo en equipos cross-funcionales más chicos y dinámicos.

    En este sentido necesariamente se deberá contar con un “nivel de gestión superior” que permita centralizar la información de todo el proyecto. Sin duda esto está lejos de ser puramente Agile, sino más bien una combinación de metodologías tradiciones y agilísmo.

    Hay que tener en cuenta también que si se divide un proyecto grande, se minimiza la dependencia arquitectónica del proyecto, para pasar de una medición del avance típicamente medido por su avances arquitectónicos, a una medición basada en la entrega de características funcionales. Esto da como resultado que la definición de “progreso” de Agile, deba ser adaptada a un nuevo contexto con un nivel de gestión superior.
    De nuevo la adaptación situacional “es un buen jugador”.

    Una gran limitación tiene que ver justamente con el especto comunicacional, dado que Agile promueve la comunicación cara-a-cara, con resoluciones dinámicas y proactivas, sin documentación más que la que oriente al desarrollo.

    El trámite comunicacional con otrás áreas es un trastorno que Agile debe aprender a dominar, puesto a que los modelos agilístas actuales exigen que otros interesados del proyecto deban siempre estar en la misma locación de trabajo, inclusive evitandose el traslado desde una oficina a otra para realizar simples consultas.

    La tecnología colaborativa y de multimedios, permiten actualmente realizar trabajos perfectamente coordinados y con esquemas de reuniones cara-a-cara, aunque virtualizadas, muy eficientes. Sin embargo esto no está bien aceptado en el mundo actual del agilísmo.

    Donde está mi metodología?

    Metodologías de desarrollo de software, tradicionalmente incluyen procesos como, Análisis, Arquitectura, Implementación, Gestión de Proyecto, Gestión de la Configuración, Gestión de Riesgos, Gestión de Cambios y una larga lista de procesos dependientes de Áreas de Procesos y Grupos de Procesos. Sin embargo, las metodologías

    Agile no promueven estos grupos de procesos y de hecho no los definen para sus marcos de trabajo, como tampoco definen un marco de gestión de proyectos.

    Esto puede verse justificado por el hecho de que las metodologías Agile tienen como insignia, que lo que demuestra y garantiza el proceso es el producto entregado y no la documentación que puedas presentarle a tu cliente.

    Las metodologías Agile delinean un marco conceptual, pero no explicitan de ninguna manera la exclusión de alguna de las prácticas tradicionales, aunque se asume que solo sobrevivirá lo estrictamente necesario para la obtención de los incrementos (entregables de software)

    Metodologías Agile completas parecen estar emergiendo y el soporte a la organización podrías ser total con adaptaciones sencillas de ambos metodologías, donde la substracción de las buenas prácticas de ambas, de como resultado el éxito y calidad total de la organización.

    Dado el contexto planteado es que me hago las siguientes preguntas para reflexionar:

    • ¿Existe la evolución de las metodologías Agiles?
    • ¿Surgieron por si solas o son adquiridas y formadas en reacción a la complejidad propuesta por las metodologías tradicionales?
    • ¿Las metodologías Agiles de alguna nueva generación no serán en si mismas las adaptaciones y evoluciones de metodologías tradicionales?

    Gestión de Proyectos

    Prácticas del PMBOK relacionadas a prácticas ÁgilesRecientemente lancé el debate en LINKEDIN en el grupo IAAP sobre cuan aplicable son las prácticas de PMI a las metodologías Ágiles. El volúmen de respuesta no fue alto pero los que quisieron aportar lo hicieron bien, y de allí rescato una lectura interesante:
    Relating PMBOK Practices to Agile Practices

    Básicamente en este artículo la autora explica como se ha relacionado de manera indebida a los procesos Waterfall con las prácticas PMI, al igual que se lo ha relacionado al CMMI de manera injustificada, cuando en realidad PMBOK es solo una guía de “mejores prácticas” y debe ser utilizado con criterio organizacional cuando se implementen sus prácticas.
    Por otro lado reprende a los practicantes de metodologías agilístas al tildarlos de “promotores del Cowboy Coding” lo cual conlleva a una situación de caos indeseada para cualquier proyecto.
    Según las observaciones de la autora, si las metodologías Ágiles son seguidas con diciplina y rigor, cumplen con el modelo CMMI y las prácticas PMBOK, tal cual como lo haría una metodología Waterfall. Indica también que más allá de lo visible, la única diferencia entre proyectos bajo controles de planificación PMI y controles de equipos autogestionados, es el momento y la manera en que se ejecutan las prácticas, las cuales son símiles difiriendo más que nada en el léxico pero no en su escencia.

    Al respecto del core de cualquier proceso a ser administrado, en el gráfico de arriba puede visualizarse el mapeo entre las convenciones PMBOK y APM o Agile Project Management Framework.
    La autora explica que existen “Seis Claves de Gestión” definidas en el PMBOK y que merecen especial atención y las cuales tienen sus relaciones en las metodologías Ágiles, aunque se diferencian en su implementación:

    • Gestión de la Integración del Proyecto
    • Ámbito de Aplicación del Proyecto de Gestión de Proyecto
    • Gestión del Tiempo
    • Gestión de la Calidad
    • Gestión de Riesgos
    • Gestión de Recursos Humanos

    Los invito a ver el artículo y sus ampliaciones y a opinar en mi blog.

    Ágile resulta más económico?

    En términos de rendimientos económicos puede demostrarse con relativa facilidad la diferencia entre modelos de gestión Ágiles y Waterfall.
    Basados en la idea de que todo proyecto tiene objetivos concretos que alcanzar en tiempos y costos limitados, es fácil observar que mientras los modelos Waterfall administran sus entregables a lo largo de una escala de tiempo significativamente grande, los modelos Ágile planifican entregas a una escala mucho más corta. Siendo así es entendible que el valor apreciativo de cada entrega pactada se devalúe con el paso del tiempo, por el solo hecho de los cambios naturales en los requerimientos de los negocios que dan vida a los proyectos. Entonces son estos mismos cambios la razón principal para que una solución ofrecida para una versión de software “X.Y.Z” en poco tiempo deje de ser una solución efectiva para el negocio.
    El “
    valor esperado para una solución de negocio” es cada vez menor por cada una de las nuevas versiones promovidas por tales cambios, y aunque esta situación está presente en cualquier modelo de trabajo, hay que hacer una comparativa de la “devaluación” de la solución esperada entre entregables.
    Los modelos Waterfall típicamente tienen espacios
    de tiempos muy grandes entre entrega y entrega, y la depreciación del valor tiende a ser mayor que el revalúo que promueven las próximas entregas. Entonces la línea de valor esperado para una solución de negocio termina siendo sensiblemente menor con el transcurrir de la variable tiempo.
    Los modelos Ágile promueven entregas en iteraciones mucho más pequeñas, con lo cual si bien el cliente puede tener una baja apreciación inicial, a corta data puede observar el verdadero valor de tener soluciones efectivas en mucho menor tiempo, y aún cuando las misma no representan en si mismas la solución general, si representan soluciones integrales que para cada entrega representan mayor revalúo que depreciación.
    En lo particular tengo alta estima por los modelos ágiles, más que nada por el valor agregado que implican las iteraciones recurrentes con el cliente, quien no solo redirecciona los pasos del proceso de construcción de las soluciones, sino que revaloriza el modelo de trabajo al promover mejores alternativas para ser utilizadas en cortos plazos de tiempo. Esta iteración magnifíca la percepción del
    valor esperado” para muchas soluciones del mismo negocio.
    GoogleTech presenta en forma sintética esta idea donde se explica gráficamente como Ágile permite generar valor agregado con iteraciones más cortas: