A las mejores prácticas debemos diseñarla “Ad-Hoc”

Como sabrás,  no dispongo de un plan genérico tipo “receta de cocina” para que puedas implementar mejores prácticas para el aseguramiento de calidad, control y Testing. De hecho para poder diseñar un plan lo óptimo es que formes un proyecto inicialmente, tal cual como lo haría un Líder de Proyectos para construir un sistema.

Tal vez sería provechoso Iniciar con observaciones de las prácticas actuales tratando de comprender sus ciclo de vida completo, teniendo en cuenta para esto cuales son los elementos de entrada y salida para poder definir en concreto que es lo que se hace con esas prácticas en particular.

Luego tomar un mes, dos o tres para analizar las prácticas relevadas, sus contextos operacionales, sus entradas y salidas, sus procesos. Hacer esto mientras se aprende cada vez más del procesos de desarrollo completo en el que opera el equipo equipo.

Esta actividad seguramente la realizarás en forma cíclica, es decir que nunca terminarás de relevar y analizar, pero debes al fin de cada fase del proyecto, determinar que elementos son útiles, cuales se pueden despreciar y cuales se pueden mejorar.

Es importante tener en mente la simpleza, sencillez y considerar que los que ejecutan esas actividades son personas, no máquinas.

Siempre pensar en el inicio y fin dentro del horario normal de trabajo y con esto estimar mejor los costos de las actividades de cada práctica y serás realista al ponderar los proyectos de calidad.

Si aún no existe un modelo de calidad al que la organización se haya adherido , es posible que solo tengan un proceso informal o semi formal, pero no es necesario que sigas al pie de la letra otros procesos conocidos, como CMMI o ISO, aunque es muy bueno comprenderlo. Lo más importante es que no hay recetas de cocina y no se debe exigir que el equipo de trabajo se amolde directamente a un modelo o una norma y todos los procesos que implican.

Las mejores prácticas debemos diseñarla.

Dada mi experiencia, puedo sugerir que esta labor nunca se haga como un trabajo en solitario, por que nadie comprenderá el trabajo y su objetivo.
Inicialmente se debe buscas el consenso de las personas más importantes, es decir la Gerencia, luego pedir el apoyo de los líderes de los equipos, por ejemplo Líder de Proyecto y Líder de Desarrollo como también y fundamentalmente el del Líder de Testing, salvo que cumplas ese rol al mismo tiempo.
Siempre se debe recalcar que el objetivo de cualquier Software Factory, empresa IT o prestadora de servicios, es brindar productos y servicios dentro de los plazos establecidos, cada día más cortos, a los costos pactados, y con la mejor calidad posible a tal punto que se perciba tanto dentro como fuera de tu organización.

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.

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

He sido participe de certificaciones CMMI 4 en una empresa del Cluster Informático de Córdoba en Argentina y actualmente estoy como Responsable de Calidad y Mejora de Procesos en una empresa donde intentamos implantar metodologías ágiles.

Conceptualmente son dos modelos distintos en cientos de aspectos, siendo imposible considerarse ágil al modelo CMMI.

Quiero ser tajante en la diferenciación de esto, pues ahora se habla mucho de CMMI Agile y tal concepto no es más que un híbrido y no está formalizado. Esto es así, por que habría que decidir que parte de CMMI utilizamos y que proceso de los existentes tomaremos para recoger lo mejor de los ágiles.

Notemos que los frameworks que la gran mayoría de las empresas ofrecen, se enfocan en uno u otro modelo.

Pero vamos a ejemplos vivos. Bajo CMMI, siendo líder de testing, no tenía más participación que la ejecución de las pruebas, previo planning encapsulado y siguiendo una estricta ERS, no era partícipe a nivel horizontal del planning inicial y los criterios de calidad no se establecían por el líder de testing sino hasta que la documentación tuviera ya un alto grado de definición (documento maduro) e inclusive la participación de mi rol seguía siendo escueta y debía tomar los criterios establecidos por el arquitecto.

Posteriormente, en CMMI, los cambios de requisitos no son aceptados con la amplia libertad con la que son aceptados en un proceso ágil y por lo general deben ser de bajo impacto para que ingresen en el catálogo de requisitos y siempre bajo un estricto circuito de análisis y revisiones de un comité de cambios, el cual está formado por una cantidad de personas y roles que en empresas que pueden seguir un proceso ágil, no hay.

Las reuniones (ICE) en CMMI tienden a ser verticales y la participación de los roles transversales no es tan significativa como lo es en un proceso ágil, es decir que las decisiones normalmente pasan por una situación elitista donde desarrolladores y testers no tienen una grandilocuencia aceptada. Esto se contrapone con el precepto que indica que para ser ágil se debe tener un fuerte énfasis en las pruebas sobre la aplicación que se desarrolla y una continua integración de sus componentes.

Con esto no pretendo decir que en CMMI no se tenga énfasis en las pruebas, pero se llega a ser tan robótico que la creatividad se destruye y proyecto tras proyecto tienes la misma documentación, los mismos estilos de pruebas, los mismos resultados y esto ya da para la desconfianza.

En procesos ágiles debes anticiparte por eso participa todo el equipo de pruebas en las primeras reuniones donde se definen criterios de calidad, métodos de pruebas posibles, modos de fallos y otros elementos que puedan definir mejor la calidad de los productos. Recuerdo que trabajando bajo el proceso CMMI todo esto me venía llovido, y se suponía que el líder del testing era yo, un elemento SQA.

Otro precepto que aleja CMMI de ágile (keep it simple).

Uno más, documentar solo lo estrictamente necesario y centrarse en lo más crítico del producto, que es el código fuente.

Por otro lado y para ir cerrando al menos este post, si un híbrido CMMI-Agile debe existir, ya sabemos que partes podemos tomar de CMMI según su nivel, pero… ¿que parte de Àgile tomamos? ¿Programación Extrema, Scrum, DSDM, Crystal Clear, …?

Hablando de Framworks, hay algunos que ofrecen la posibilidad de trabajar con una metodología Ágile con documentación formal y que mediante un esfuerzo (considerable) se podría alcanzar un nivel CMMI-3 en el mejor de los casos, utilizando otra parte del mismo Framework. Es más complejo que eso.

Pero aqui me acoplo a lo que algunos dicen por la red. Lo más importante que toda organización o persona debe tener en cuenta, es que no existe una metodología ideal para cualquier escenario en la que se aplique. La metodología de desarrollo que se seleccione, bien sea ágil o no, siempre dependerá directamente del equipo de trabajo, la cultura organizacional, lo cambiante del medio ambiente y la aceptación del usuario final.

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

Tratando de continuar con la saga CMMI/Ágile,  diré que creo que si tenemos en claro que CMMI es el modelo del proceso de desarrollo a seguir y Scrum es el modelo de gestión, entonces en teoría no habría discrepancias ni razones de frustración a la hora de intentar gestionar con Scrum mientras se siguen las prácticas sugeridas por CMMI.

Sin embargo Scrum se plantea con un conjunto de prácticas bien definidas, que bien podrían no ser compatibles con las prácticas CMMI, las cuales desde un principio parecieron ser mejor adaptadas a RUP y las “gestiones pesadas” con prácticas al estilo PMBOOK.

Habría que plantearse si eso de ligar a CMMI con RUP, PMI o procesos Waterfall, no es un fallo conceptual, puesto a que en realidad CMMI no plantea restricciones al respecto del modelo de gestión de los proyectos.

En cierto aspecto, lo interesante es tratar de respetar toda la metodología de gestión Scrum y sus roles, mientras se respetan las exigencias de los roles CMMI.
Creo que aquí es donde nos damos cuenta de la necesidad de nuevos significados para las cosas y reestructuración de los modelos, si es que los mismos debieran sostener su vigencia.

Por ejemplo yo partiría los roles en dos capas:

  • una capa de nivel “No Operativa” o administrativa donde por ejemplo, el Product Owner sería todo el Stakeholder de capa superior de los roles exigidos por CMMI (Gerencia, Gerencia Senior, Sponsor, Representante del Cliente, y Gerente QA)
  • una capa “Operativa” donde encontraríamos por ejemplo, al Team (Líder de Proyecto, Arquitecto de Sistemas, Líder de Testing, Testers, Desarrolladores) todos gestionados con Scrum, donde Scrum Master sería necesariamente el Líder de Proyectos.

Ahora bien, solo estamos hablando de gestionar roles, pero habría que profundizar en las similitudes y diferencias de las prácticas sugeridas o impuestas para cada rol y PA por cada modelo.

A mi entender por más que se gestione con Scrum, el proceso ya no sería puramente Ágile ni puramente RUP sino uno de los “hibridos que se vienen”.

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.

La importancia de las Certificaciones y evaluaciones de los SSI

Desde siempre los profesionales que prestamos servicios informáticos nos vimos en la necesidad de constante evolución y así cada vez más, se presentan situaciones en las que un estudiante universitario o terciario o idóneo, logra una certificación que lo acerca a una mejor posición a la hora de prestar sus servicios, mucho antes de finalizar su educación formalista.
En vista del auge que tienen las empresas dedicadas al SSI (Software y Servicios Informáticos) no es sorpresa que se coticen mejor aquellos RRHH que suman certificaciones y otras capacitaciones año a año. Tampoco es sorpresa que las empresas necesiten certificar sus procesos y/o productos y de esa manera acceder a mejores oportunidades de negocio en el mundo globalizado.
Muchas empresas accedieron a importantes logros a nivel de evaluaciones CMMI o certificaciones ISO, entre otras calificaciones y debo decir que ya es notable la escalada de proyectos internacionales que recaudan sus agendas de trabajo y la cartera de cliente se globaliza aún más.
El movimiento agilísta no a presentado ninguna restricción al respecto de que certificaciones y/o evaluaciones son requeridas para dar un formato cerrado de empresa SSI de calidad y garantías de satisfacción. Estos procesos y metodologóas propuestos por los movimientos Ágiles parecerieran ser solamente aditivos para mejorar en ciertos aspectos la productividad, sin representar necesariamente calidad certificada.
Entonces ¿Por que los clientes deben confiar sus requisitos a empresas que no tienen interés en certificar una norma de calidad de productos finales como ISO o ser evaluados en CMMI para sus procesos de construcción y prestación de servicios informáticos?