Buscar en Gazafatonario IT

domingo, agosto 31, 2014

Agile Open Eje Cafetero: la innovación con esencia de café


Foto: algunos de los asistentes, al cierre del Agile Open.

Existe un universo más allá de las grandes ciudades en Colombia, una órbita donde un grupo fantástico de estudiantes, jovencitos con ganas desde ya de cambiar la forma de hacer las cosas, apoyados por un grupo de empresarios también muy jóvenes, con ideas frescas que rayan en lo innovador, están decididos no solo a plantar el jardín sino a ser los mejores jardineros del ecosistema ágil mundial. Eso fue lo que encontramos los invitados, facilitadores y asistentes al Primer Agile Open Eje Cafetero, organizado por las Comunidades de Ágiles Colombia Eje Cafetero y Ágiles Colombia.

Lo que sucedió en el Abierto fue un encuentro de micro-culturas, una danza de conocimiento, experiencias y anécdotas compartidas, que se entretejieron en un escenario de networking entre quienes concurrieron solícitos a la convocatoria. Hubo conferencias, talleres, tutoriales, encuentros fortuitos en los pasillos del centro de convenciones, conversatorios y juegos ágiles, entre otros sabores y formatos de reunión. Los temas clásicos estuvieron a la orden del día:

Foto: Raúl, Natasha, Claudia, Yamit, Cristian, Luis, Julián, Jorge, Pablo, Andrés, Carlos, Robinson. Solo algunos de los facilitadores del Agile Open. También estuvieron Ana, Juliana y otros.

En total, fueron más de 40 sesiones ricas en información, rutinas, discusiones, conclusiones e ideas innovadoras que se llevaron los más de 200 asistentes a la cita. Quienes participamos de la reunión, sabemos que la innovación envuelve más que grandes ideas. Sabemos que hay que tener fe, trabajar duro y enfocarse en la meta que queremos alcanzar. Con esto sobre nuestras cabezas, estamos seguros que la mayor o menor visión de innovadores que tenemos en la Comunidad persistirá aún más allá de los muros de contención que representan el sinnúmero de obstáculos en el camino hacia el éxito.

Mientras facilitaba algunas sesiones con Jorge, observaba como los asistentes a los distintos conversatorios y talleres se deshacían de sus inhibiciones, autoimpuestas por demás. ¡Este fue otro logro de la reunión! Bien sabemos que bajo el hechizo de la inhibición, nos sentimos limitados y estancados, y liberarnos de estas limitaciones creadas por la mente, mediante la eliminación de supuestos y restricciones, es una tarea que a veces no podemos hacer solos. Nuestra meta como facilitadores fue motivar a todas las personas que nos siguieron a través de los distintos auditorios, a “pensar fuera de la caja”. Tratamos de animarlos a abrirse a nuevas ideas y soluciones sin establecer limitación de creencias antepuestas. Después de todo, la innovación es más acerca de la psicología que de la inteligencia y el conocimiento.

También pude percibir que muchos otros asistentes sintieron Curiosidad. Otra vez la innovación estaba presente. Muchos innovadores tratamos de ser simplemente personas curiosas e inquisitivas y nos gusta resolver problemas, practicamos la observación de las cosas de manera diferente. Así fue como, atendiendo a sesiones de su predilección, los asistentes al Abierto se comieron un elefante en vez de aprender a elaborar un Story Mapping, bañaron un ayé ayé y a un cocodrilo en vez de formarse en estimación ágil de proyectos, hicieron teatro y jugaron en vez de aprender Scrum, escribieron en un árbol en vez de hacerlo en tabletas o portátiles de última tecnología. ¡El ambiente era de fábula! Quizás sea por eso que la próxima vez que cualquiera de quienes estuvimos allí, veamos la solución a un problema, seguramente nos preguntaremos: “¿cuáles son algunas formas alternativas para hacer esto?”. Haremos muchas preguntas y desafiaremos las normas o los métodos existentes. ¡Qué felicidad!

En mi recorrido por los distintos espacios de entrenamiento, tuve la ligera pero absoluta esperanza de que algunos muchos trataban de encontrar, o de aprender a encontrar, patrones y con estos creaban combinaciones. Otro síntoma de innovación. Hace mucho tiempo aprendí que las ideas vienen de otras ideas. ¿Sabías que Edison no fue quien inventó la bombilla? Él fue el primero en construir un filamento de carbono viable dentro de una ampolla de vidrio, que hace que las bombillas duren más. ¡Genial! Durante los variados cónclaves en la ciudad milagro de Colombia, aumentamos nuestra exposición a nuevas ideas, buscamos patrones y vimos cómo se pueden combinar ideas para mejorar las soluciones existentes.

Foto: Gregorio, Mauricio, Pablo, Natalia, Alejandro, Diana y algunos de los voluntarios que hicieron posible el Open Space.

Al cierre todos sentíamos que habíamos cambiado algo de nuestras vidas, quienes lideramos el evento sentimos que tocamos aunque fuese de manera infinitesimal el espíritu de muchas personas. Pero quienes se llevaron todos los elogios fueron este equipo de muchachos que organizaron con lujo de detalles esta fiesta del discernimiento y la interacción: Gregorio, Mauricio, Pablo, Natalia, Alejandro, Diana y todos sus amigos, se merecen mis (nuestras) felicitaciones.

Estamos seguros que la audiencia salió esa tarde de sábado con ideas disruptivas, sintiéndose inspirados y motivados a ir más allá de lo que es posible, pero ustedes muchachos de Agiles Eje Cafetero, la tarea que emprendieron es memorable y emocionante… Adelante con ello y ¡cuenten con nosotros!

Adenda

Tiene razón Tobias, ¡que delicia es sentirse de nuevo como en el patio de la escuela!

Más fotos del evento, por Luis y algunos de los miembros del equipo organizador, las encuentran en la página de Facebook de Ágiles Colombia, haciendo clic aquí y en la página de Agiles Eje Cafetero.

Lo que viene

Sigue el Agile Open Bucaramanga en septiembre y más tarde, del 23 al 25 de octubre, en Medellín, Las VII Jornadas Latinoamericanas de Metodologías Ágiles, con una súper nómina de lujo y la presencia de los principales exponentes del enfoque ágil en Iberoamérica. ¡Los esperamos a todos!


viernes, agosto 08, 2014

La Esencia de la Ingeniería de Software: aplicando el núcleo de Semat

La Esencia de la Ingeniería de Software: aplicando el núcleo de Semat
Portada de La Esencia de la Ingeniería de Software: aplicando el núcleo de Semat. Nueva Librería.
PREFACIO A LA EDICIÓN EN ESPAÑOL
La reunión del Comité Científico de la OTAN en Garmish en 1968 dio inicio a la Ingeniería de Software como disciplina, pero no suministró bases teóricas firmes para esta naciente disciplina. Después de 45 años de esa reunión, si bien se hicieron varios intentos por generar esas bases teóricas, aún la Academia y la Industria del software no se ponen de acuerdo para darle, por fin, el carácter ingenieril que requiere esta novel ciencia. Durante estos años, los métodos surgieron por doquier, las prácticas se propagaron y las teorías se multiplicaron para explicar fenómenos aislados de la Ingeniería de Software, pero no hubo unificación alrededor de esos esfuerzos.
El surgimiento de SEMAT comenzó a brindar alguna unificación sobre estos temas. Como un acuerdo entre la Academia y los actores principales de la Industria del software (los practicantes y los clientes), los conceptos fundamentales de la Ingeniería de Software vienen cobrando creciente interés en el mundo, a tal punto que existen ya comités especializados en el tema y varios Capítulos regionales que trabajan en pro de estos esfuerzos. Latinoamérica no es la excepción y se viene vinculando a este esfuerzo transnacional para diseminar las ideas de SEMAT en toda la región. Además, el núcleo de SEMAT se viene abriendo paso como estándar en el Grupo de Gestión de Objetos (OMG por sus siglas en inglés), que tiene ya en su haber importantes estándares como UML, XML, BPMN, MDA y Corba. El Dr. Ivar Jacobson viene liderando este esfuerzo y uno de los lineamientos principales para el Capítulo Latinoamericano tiene que ver con la traducción del material relativo a SEMAT al español, con el fin de lograr la mayor accesibilidad posible a las ideas de esta iniciativa. Este libro surge como una estrategia adicional para alcanzar ese objetivo, el cual se reafirma en la necesidad sentida que venimos experimentando los traductores de este libro, como partícipes de la ideología SEMAT, al compartir estas ideas en nuestra región en diferentes eventos de nivel Latinoamericano. En efecto, la necesidad de material en español se justifica plenamente para llegar a la mayor cantidad de público de habla hispana que nos permita esclarecer las bondades que implica la utilización de las ideas de SEMAT, en particular el núcleo, que es la Esencia de la Ingeniería de Software.
Conscientes de que esta obra es tan sólo la semilla de lo que vendrá en el futuro, presentamos esta traducción al español con la certeza de que alcanzará hasta el último rincón de nuestra región y permitirá promover una discusión abierta y consciente sobre el uso y alcances de la Esencia de la Ingeniería de Software: el núcleo de SEMAT. A sólo algunos meses de la publicación del libro en inglés, tenemos la fortuna en Latinoamérica de contar con la traducción al español, accediendo sin demoras a lo más reciente que se viene discutiendo en el seno de SEMAT.
Carlos Mario Zapata – Luis Antonio Salazar

miércoles, julio 16, 2014

Certificar un proveedor como Ágil o de la 'Agile Certified Provider Alliance'

Generalmente ganamos la confianza de aquéllos en quienes ponemos la nuestra.” [Tito Livio]
Certificar un proveedor como Ágil o de la Agile Certified Provider Alliance
Hace algunos días, nuestro amigo y colega Jorge Abad decía en un mensaje a la Comunidad de Ágiles Latinoamérica:
Me hacen esta pregunta desde una empresa del estado que realiza grandes contrataciones de proveedores: ¿Existe una lista de chequeo estándar para validar si una empresa es ágil y usa las prácticas de ingeniería adecuadas para ágil?
Al margen de que sea o no una empresa del estado, la pregunta tiene su truco. En cualquier caso, esta fue mi respuesta a Jorge:

Watts Humphrey, el padre de CMMI, decía que certificarse CMMI 5 significaba que tu siguiente proyecto iba a ser exitoso. Él no decía nada de los demás proyectos. Es natural, la organización recién certificada “respiraba” CMMI, calidad, procesos, productividad y motivación, algunos de los elementos clave para el éxito de los proyectos.

¿Pero y los demás proyectos, los que siguen a continuación de ese?

Igual sucede con Ágil. Aun si el cliente visita al proveedor potencial, este último le puede demostrar a aquel (¡a no ser que sea una visita sorpresa!), que es Ágil.

¿Pero y los demás proyectos? [Acá entre nos, no existe ninguna posibilidad de que una lista de chequeo sirva para probar que un proveedor es ágil. Existen listas como esta de Henrik Kniberg (http://goo.gl/QnQUN), una herramienta para evaluar una implementación de Scrum, tratar de encontrar algo más allá es una utopía.]

Quienes hemos navegado por los vericuetos, a veces inescrutables, de las certificaciones de todo tipo, que nos proclaman como los poseedores del vasto poder del conocimiento y la experiencia, sabemos que eso no es suficiente y que, en muchos casos, eso no garantiza el éxito. Sobre todo, en nuestras economías tercermundistas, con nuestra idiosincrasia, con nuestra forma de ver el universo.

¿Qué vale entonces?

¡La confianza!

Aun una entidad del gobierno, debe dar el salto y modificar su “modus vivendi” (Sí, lo sé, no es fácil –pero igual, aun una entidad del gobierno debe saber que “ser ágil no es solo cosa de sus proveedores”, la organización también debe transformarse), para que pueda ser capaz de hacer pilotos, evaluar los resultados y luego sí, ajustar con el probable proveedor o desecharlo de una vez por todas y para siempre, condenarlo a 100 años de soledad, esa fatídica maldición de los que no tienen una segunda oportunidad sobre la tierra.

Incluso quizás unos cuantos sprints no serán suficientes. Más aun, ¿cómo comprobar al final de varios proyectos si tu proveedor es ágil? ¿Acaso es posible probar que parte del equipo no es ágil (el equipo de desarrollo –del Proveedor) y parte sí (acaso el Dueño de Producto y quizás el Scrum Master –del Cliente)?

Estaba reflexionando con toda esta perorata y mi conclusión es que no es posible, al menos no tiene mucho sentido que este cliente del estado, o cualquier otra empresa privada o de gobierno, evalúe si un proveedor es ágil.

Quizás el proveedor sí es ágil, pero cuando se junte con el cliente deje de serlo.
Quizás no lo es, pero cuando se junte con el cliente aprenda a serlo.
Quizás sí lo es y cuando se junte con el cliente, siga siéndolo.

En fin, las posibilidades son variadas.

¡Estamos de vuelta en la Confianza! Martín Alaimo, dice en su libro “Equipos #MásProductivos”, citando a su vez a Gorerg Simmel, que “La confianza es una hipótesis sobre la conducta futura del otro” y más adelante él mismo dice: “La confianza que inspiro en otros sobre mí, la construyo y la sostengo a través de mis acciones.”

Algunos miembros de la Comunidad le respondieron a Abad que era una cuestión de “feeling”. Yo, por ejemplo, tuve varias novias (2 al menos) antes de quedarme con quien es mi esposa, no era la más bonita pero sí la que más confianza me generó. Y eso, mi estimado Jorge, no se consigue con una lista de chequeo ni con una visita a casa de los padres de la novia. ¿Quién sabe? Quizás mañana me divorcie.

martes, julio 01, 2014

Respuesta al cambio sobre seguir un plan: ¡no planearás!

“El plan no es nada, la planificación lo es todo”. Eisenhower
Imagen cortesía de Vichaya Kiatying-Angs / FreeDigitalPhotos.net
Basado en hechos históricos

Natalia es gerente de proyectos de una importante compañía proveedora de servicios de tecnología. Es la encargada de la operación en uno de los clientes más grandes de la empresa: un conglomerado de telefonía móvil. Hacia el final de esta mañana la llamó el director de mercadeo de esa organización bastante alarmado:

         - Natalia, hablas con Juan Pérez de Móviles del Sur* - ¿tienes un momento?
         - Hola Juan, ¿en qué te puedo ayudar?

Lo que siguió fue toda una perorata que inquietó a Natalia. El cliente le contó cómo durante la mañana se enteró de la Promoción Rumbo al Mundial Brasil 2014 que su más encarnizado competidor sacaría a la luz la noche de ese día. Pérez sabía que de no responder efectiva y rápidamente no solo dejaría de ganar cientos o miles de clientes, sino que perdería muchos otros, lo que podría golpear severamente sus márgenes de ganancia durante el primer semestre del año. Para suerte de Natalia, el señor Pérez había hecho su tarea, ya sabía que debía actualizar las herramientas de software de mercadeo y ventas para soportar una promoción agresiva que debería estar al aire en la TV y en las redes sociales dos horas antes que la de su competidor.

Mientras Pérez hablaba, Natalia revisaba rápidamente el proceso de control de cambio de la compañía y concluyó que podría entregarle una propuesta de trabajo que incluyera el impacto de la actualización del software en costo y presupuesto a su cliente pero solo hasta el día siguiente. Era inaudito, mientras Juan Pérez estaba buscando una respuesta ágil y eficiente que concluyera con un resultado de valor en las próximas 8 horas, Natalia se enfrentaba a la disyuntiva de seguir un proceso clásico de estimación a priori y modificación del plan de trabajo, previo análisis de impacto y de costos, que redundaría en una pérdida tanto para su compañía como para la de su cliente, o simplemente responderle firme y positivamente que cumpliría la meta establecida para las siguientes horas.

El Manifiesto por el Desarrollo Ágil de Software (aka: la solución del proveedor)

Por suerte para Natalia, ella también había hecho su tarea. En los últimos tiempos había empezado un proceso de transformación en sus equipos que incluía una forma de ver el mundo de manera distinta a como lo venían haciendo en la compañía. Se trataba de todo un ecosistema basado en una cadena de valores y principios que rompían con los esquemas tradicionales de hacer software. Todo empezaba con el así llamado Manifiesto por el Desarrollo Ágil de Software o, simplemente, Manifiesto Ágil, el cual le daría la clave para ganar ese día:

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.
El Manifiesto Ágil por el Desarrollo de Software. Fuente: http://www.agilemanifesto.org/iso/es.

Este pedazo de esfuerzo mental, fruto de la colaboración de 17 personajes reconocidos en la industria del software en 2001, serviría a Natalia como pilar fundamental para encontrar una solución de valor para su cliente. Los Valores y Principios Ágiles enfatizan en la importancia de colaboración e interacción en el desarrollo de software y, de otro lado, el trabajo creativo involucra comúnmente alguna forma de colaboración y puede entenderse como una interacción entre un individuo y un contexto sociocultural.

Los proyectos tradicionales están plagados de equipos conducidos-por-gerentes, organizados en una estructura jerárquica con múltiples capas de autoridad. Esta gerencia es del estilo de “comando y control” y los roles se basan en tareas funcionales que, en el caso del software, son los programadores, los diseñadores, los analistas, etc. El trabajo se delega a los miembros del equipo por sus jefes. Las prácticas en estos equipos incluyen copiosa documentación, especificaciones previas y planeación detallada. Las líneas de comunicación son indirectas entre las distintas capas de la jerarquía organizacional y el empoderamiento es algo invisible para la mayoría de los participantes, lo mismo que el estado general del proyecto.
Imagen cortesía de Salvatore Vuono / FreeDigitalPhotos.net
El primero de los valores “Individuos y sus interacciones”, le indicaba a Natalia que necesitaba un equipo cooperativo, multi-funcional y auto-suficiente, experto, altamente productivo y creativo que se comunicara con su cliente y trabajara con él el resto de la tarde, no solo en la extracción de conocimiento típica de los proyectos actuales, sino en todo el ciclo de producción que le permitiera a Móviles del Sur poner en funcionamiento una solución automatizada que soportara su ambicioso programa de retención y captura de clientes con motivo del evento mundialista de los próximos meses. Recordó así uno de los Principios que acompañaban a esos valores ágiles:

Principio Ágil # 1: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

Natalia sabía que la filosofía ágil tiene la habilidad de amplificar la productividad de los equipos de software hasta una escala de gran magnitud, a través del empoderamiento de las personas, fomentando un entorno orientado-al-equipo y enfocándose en la transparencia del proyecto y en los resultados. Estos proyectos pasaron de ser dirigidos-por-el-plan a estar enfocados en el producto, uno priorizado por y de valor para el cliente. Estos equipos se identifican a sí mismos como una unidad social dentro de la organización de la cual hacen parte y a quienes se les confía la ejecución del trabajo y se les proporciona el entorno y el apoyo que necesitan, para mantenerlos motivados, como invoca otro de los principios del Manifiesto Ágil, y para aumentar su apego emocional a la empresa.

Si bien se trata de un conjunto de Valores, el último de estos, pero no por eso menos importante, no devalúa la planificación, en la práctica solo se adhiere al plan. La planificación es valiosa en sí misma; y dado que el plan nos asiste en la tarea de reconocer cuándo las cosas han cambiado, también nos ayuda a entender las implicaciones del cambio, cómo tenemos que ajustarnos y cuál es el costo probable. Lo importante es que, a medida que hacemos planes, entendamos que el plan puede cambiar. La planificación es una actividad continua que incluye:
  • Reuniones de planificación de iteración
  • Reuniones diarias
  • Reuniones de revisión
  • Retrospectivas
  • Evaluación de riesgos

Planificación clásica versus planificación ágil y un mito que se niega a desaparecer
Imagen cortesía de hin255 / FreeDigitalPhotos.net
Cada una de esas ceremonias sirve para no solo para planear sino también para inspeccionar el estado del proyecto y crear mecanismos de adaptación en caso de ser necesario. El grueso de los practicantes de la industria y quienes la miran desde los tejados, cree que los equipos ágiles son desorganizados, informales, que no documentan y sobre todo que no planean. Todo eso se debe en parte a la mala lectura que le dan al mismísimo Manifiesto Ágil. Pero no es así. Contrario a lo que ocurre en los modelos tradicionales de planificación, donde se planea al comienzo, se elaboran planes de 2, 3 o más niveles, y se hace seguimiento a ese plan durante el resto del proyecto, un seguimiento que raya en el acoso, los equipos ágiles planean todos los días.

En parte eso se debe a que los equipos ágiles saben que los cambios hacen parte inherente, son constituyente primario del ADN, del ciclo de vida del software. Los cambios pueden ocurrir en cualquier momento, desde las etapas iniciales del proyecto, aun cuando apenas se están conociendo las necesidades del usuario, hasta las fases tardías del proyecto, quizás cuando estamos a punto de salir a producción. Si son bien manejados, los cambios brindan muchos beneficios a los usuarios, el primero de ellos, ventaja competitiva. Los cambios son una herramienta invaluable para crear productos inmejorables. Era precisamente lo que necesitaba Juan Pérez ese día. Otro de los principios ágiles llevó a Natalia a esa conclusión:

Principio Ágil # 2: Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

En cambio, los enfoques tradicionales de gerencia de proyectos presentan los cambios como un monstruo con el que hay luchar a sangre y fuego. Los procedimientos rigurosos de control de cambio, típicos de estos enfoques, causan la pérdida de oportunidad que los clientes tienen para ganar más mercado y para crear mejores productos. En general, a medida que el tiempo avanza, la habilidad de hacer cambios disminuye y cuesta más. Esto es lo que enfrentan los procesos ágiles, aunque sin dejar de planear. Los métodos ágiles promueven planes más livianos y de alto nivel a largo plazo, mientras que atienden la elaboración de agendas bien detalladas a corto plazo, las de la iteración actual, que solo tarda unos pocos días o muy pocas semanas. En Scrum, por ejemplo, las iteraciones tardan máximo 4 semanas y con frecuencia mucho menos que eso.

Al principio de los proyectos ágiles se planean las entregas o salidas a producción tempranas, beneficio primario que nos traen los procesos ágiles. Estas salidas a producción pueden ser cada tres meses, pero hoy contamos con la tecnología y plataformas lo suficientemente maduras como para hacer continuous delivery o entregas continuas. Amazon, por ejemplo, la vendedora al detal más grande del mundo, sale a producción cada 11,6 segundos, algo absolutamente asombroso si tenemos en cuenta la cantidad de clientes recurrentes simultáneos que tiene su sitio Web cada segundo. Natalia sabía todo eso, entonces no dudó que podía tener un producto funcionando para antes de las 8 de la noche de ese día, meta principal de su cliente.

Resultado final

Mientras hacia un recorrido por los acontecimientos de la hora, Natalia convocó a un equipo idóneo, uno que sabía capaz de elaborar un producto que generara resonancia no solo en su cliente sino en sus usuarios, uno que haga que la gente experimente distintas reacciones de gozo al usarlo, sin hablar de los ingresos en que redundaría su uso. No se trataba solo de actualizar un pedazo de software existente, sino de producir algo no ordinario que tuviera la capacidad de atraer a una audiencia cada vez mayor. Otro de los principios ágiles fue el último consejo que le dio al equipo antes de despedirlo hacia lo que seguramente sería un éxito total:

Principio Ágil # 10: La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

¿Quieres saber más?

Sobre otros mitos y leyendas relacionadas con los métodos ágiles puedes leer:
Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum: http://goo.gl/PIfZpx

Sobre planificación ágil, estos 2 artículos:
Planificación del Sprint: el primer paso para producir el máximo efecto: http://goo.gl/9TO7FF
Compendio Sobre el Scrum Diario: http://goo.gl/GG7id1

Sobre cultura ágil y transformación a ágil, estos 2 artículos:
Cultura ágil: ese oscuro objeto del deseo: http://goo.gl/IuJIlY
Sí, usted está listo para implementar un proyecto ágil: http://goo.gl/19Hcnz


domingo, junio 22, 2014

Ecos del SEPG Latino América 2014

Manizales, en los alrededores de la sede de la SEPG LA
Para quienes no están familiarizados, SEPG es la serie de conferencias premier en gestión de procesos de software y sistemas. Cada conferencia brinda desarrollo profesional en mejoramiento de procesos a través de sesiones técnicas enfocadas en tecnologías como CMMI, People CMM, PSP, TSP, Agile, ISO y Six Sigma; también aborda los enfoques para implementar alta madurez, técnicas efectivas de adquisición, desarrollo y entrega de servicios, entre otros temas de relevancia para la industria.
En Latinoamérica este año la edición de la conferencia, SEPG LA, se llevó a cabo en Manizales, en un ambiente natural, rodeado de montañas y termales de aguas que provienen directamente de las entrañas de la tierra, nos reunimos 2 o 3 centenares de personas que llegamos de latitudes tan diversas como España, USA, Chile, México y Colombia. Como era de esperarse, el programa de la Conferencia se combinó con un ambiente de networking entre los asistentes, condición sine qua non el evento no hubiese colmado las expectativas de quienes acudimos a la cita.
El Programa
Cuando me enteré que el llamado de artículos incluía entre sus temas principales la combinación de disciplina con métodos ágiles pensé que era una forma peyorativa de nombrar los métodos y prácticas con enfoque ágil. Eso me motivó a participar. Involucrado como he estado en los últimos años con la agilidad y lo que yo llamo la Cultura Ágil, liderando el proceso de transformación de una compañía con un alto nivel de madurez, he aprendido que los dos ecosistemas, el de procesos prescriptivos tipo CMMI, y el de procesos generativos tipo Scrum, se pueden “aprovechar” uno del otro. Con ello en mente, preparé mi ponencia “Ágil es algo que eres, CMMI es algo que usas”, pero eso es algo a lo que llegaré más adelante.
  • El resto del programa incluía temas como:
  • Competitividad y supervivencia en un mercado globalizado (Visión estratégica del sector TI)
  • Mejora de procesos en entornos diversos (pequeños, pymes y grandes empresas)
  • Alcanzando y trabajando en entornos de alta madurez
  • Mejorando la capacidad de la prestación de servicios TI
  • Industrializando la producción de Software
  • Retos en las arquitecturas y nuevos modelos de negocio TI (Arquitectura Empresarial, Cloud, Big Data, Movilidad, Seguridad, entre otros), y
  • Marca y normatividad sectorial de Software
El plato estaba servido, mi artículo había sido aceptado en la Conferencia, así es que viajamos a Manizales en compañía de algunos colegas y amigos de la industria. Al ver la fascinación que representaban las cordilleras colombianas, mientras repasaba lo que había escrito para la ponencia sobre lo que significa ser ágil, recordé a uno grande de la industria, Steve Jobs, diciendo que ese precisamente había sido uno de sus mantras – foco y simplicidad.
Tenía razón Jobs, lo simple puede ser más difícil que lo complejo. Tienes que trabajar duro para lograr que tus pensamientos sean limpios y poder alcanzar así la simplicidad. Pero vale la pena, porque una vez allí, puedes mover montañas. En ágil, la simplicidad el arte de maximizar el trabajo no realizado, es esencial. O así lo invoca el Manifiesto Ágil.
El Evento
El Ministro TIC de Colombia, Dr. Diego Molano Vega
El inicio del evento supuso un acto protocolario algo extenso para mi gusto – qué le vamos a hacer, ¡tenía que decirlo! –, que incluyó al Ministro de las TIC en Colombia, Dr. Diego Molano, y al alcalde de Manizales, con presentaciones bastante enérgicas, lo mismo que a la Dra. Elena Schaeidt Ayarza, Directora de Desarrollo Corporativo e Internacional de TECNALIA y al Dr. Albeiro Cuesta Mesa, Director de Políticas y Desarrollo TI hablando sobre cómo se está transformando la industria TI en Colombia.
A continuación, el Dr. Kirk Botula, CEO del CMMI Institute, rama recién desprendida del SEI, nos habló de cómo hacer para que la industria de TI latinoamericana trabaje mejor. En su presentación, el Dr. Botula hablaba de como la misión del CMMI Institute era hacer que el mundo trabaje mejor, hacer que el mundo del trabajo, funcione mejor. La razón por la que la gente adopta CMMI, decía Botula, o de preocuparse por esos marcos de trabajo o las evaluaciones CMMI o el entrenamiento en esas áreas, es debido a los buenos resultados que todo eso lleva a las organizaciones e instituciones que lo usan.
Pero el Dr. Botula también le abrió las puertas a la filosofía ágil. Afirmó que con técnicas ágiles ganamos el 5% más de velocidad que con CMMI y 2% más que con TSP, aunque dijo también que los costos de desarrollo son los mismos. ¿Qué si ágil es la dirección correcta? No, según Botula todavía no, pero igual pensé que el haberlo mencionado ya era un hito.
Al día siguiente, la contraparte de Botula, el Dr. Paul Nielsen, CEO del SEI, habló de la calidad del software y de su impacto en la ciberseguridad. Mostró datos nada nuevos para quienes estamos involucrados en el tema: que el 70% de los defectos del software se introducen en las primeras etapas del desarrollo y que solo se encuentran el 3,5% de los errores en esas mismas etapas (requisitos, diseño, arquitectura y diseño de componentes). El mensaje de Nielsen es que sigamos adoptando un enfoque centrado en la arquitectura, nada que no hayamos estado haciendo hará ya una década y media con la guía de procesos como el Unified Process.
Además hubo una mesa redonda moderada por la Viceministra de TI de Colombia, la señora María Isabel Mejía, con un panel compuesto por los directores de los clusters de empresas de TI en Colombia, como Lina Taborda, Directora de Intersoftware, y María Victoria Gara, Directora de CaribeTIC, entre otras personas. El panel versó sobre la oferta y la demanda de las TIC en Colombia en el que se dijo que necesitamos más talento calificado, más programas específicos de desarrollo de las TIC para las regiones, etcétera.
La Viceministra de TI, María Isabel Mejía
A propósito de la Viceministra, tuve la oportunidad de almorzar con ella y con Lina Taborda de Intersoftware (por invitación de esta última). El objetivo inicial era presentarle las VII Jornadas Latinoamericanas de Metodologías Ágiles que serán en octubre en la ciudad de Medellín y de cuyo equipo organizador hago parte, pero el almuerzo se extendió gratamente y tuvimos la oportunidad de hablar largamente de métodos y prácticas ágiles y de la presentación que yo haría un par de horas más tarde sobre la cultura ágil, al cierre del evento.
Las Conferencias
El resto de ponencias transcurrieron en un ambiente ponderado. Algunas de buena calidad, otras no tanto o, al menos, esas fueron las notan predominantes durante los 2 días del evento. La lista de conferencias la encuentran en:
http://www.sepgla.com.co/programa/
Y finalmente, al cierre, mi presentación, “Ágil es algo que eres, CMMI es algo que usas”. Pero antes de ir a ese punto específico, quisiera hacer mención de una de las conferencias, no porque las demás no lo merezcan, sino porque no hay espacio para mucho más. Me llamó la atención el tema que presentó Luz Adriana Sepúlveda sobre los significados acerca del proceso de implementación de un modelo de mejoramiento de procesos.
Luz Adriana nos habló de los resultados obtenidos durante una investigación que condujo. Algunos de sus planteamientos vienen de Deming y de Crosby, entre otros. Dejó asomar lemas como el de Tomas Gilb que señalan que el personal que no está motivado no avanza, ofrece resistencia y niega el cambio. Algunos datos interesantes como que más de la mitad de 100 esfuerzos de transformación corporativa no sobrevivieron el arranque inicial, o así se desprende de un estudio de John Kotter de Harvard. Sepúlveda nos mostró algunas de las causas de todo esto:
  • Falta de compromiso de la Alta Dirección
  • Falta de continuidad por no contar con estructura de soporte
  • No tomar en cuenta las limitantes que pueden afectar el proceso.
  • Cambio en los sistemas sin cambio en el operador (no existe cambio en la manera de pensar)
Sobre su estudio, Luz Adriana enfatiza en los factores motivantes de rechazo a un Sistema de Gestión de Calidad:
  • Miedo a lo desconocido
  • Resistencia a experimentar
  • Aumento /Disminución de las responsabilidades laborales
  • Falta de información – Desinformación
  • Amenazas al pago y otros beneficios
  • Factores históricos
  • Amenazas al estatus
  • Miedo al fracaso
  • Temor a no poder aprender las nuevas destrezas requeridas
Y señala algunos elementos que contrarrestan esas aprehensiones:
  • Sensibilización/Capacitación/Información
  • Participación en el proceso
  • Construcción colectiva del sistema
  • Experiencia adquirida
  • Acompañamiento por parte de los líderes
  • Planeación del proceso
  • Conceder tiempo al personal para participar activamente en el sistema.
Los dejo con los datos de Luz Adriana por si quieren contactarla. 
Ágil es algo que eres, CMMI es algo que usas
Algunos momentos de mi conferencia. Foto de María Clara López.
En este SEPG LA Se habló mucho de calidad, pero no se habló de las personas. Y mucho menos de sus interacciones. Pensé entonces que el enfoque de mi discurso era precisamente el que quería. Mi asunto principal era que los métodos ágiles no tienen por qué entrar en conflicto con otros modelos o enfoques de construcción de software, no es la idea de ser ágil o, al menos, no está en el flujo de un proceso de transformación a ágil echar tierra a las prácticas existentes en una organización. Los líderes de los procesos actuales deberían trabajar en conjunto con los nuevos líderes para que estos últimos obtengan los beneficios de ambos universos y aprovechar esa sinergia para mejorar dramáticamente el rendimiento del negocio.

Para apoyar este concepto, expliqué que los modelos como CMMI, PMI e ISO nos dan una idea de cuales procesos son necesarios para mantener una organización madura y disciplinada, capaz de predecir y mejorar el desempeño de la organización misma y de los proyectos. Entre tanto, las técnicas ágiles proporcionan guías para un manejo eficiente de los proyectos de una manera que permite alta flexibilidad y adaptabilidad. Al mezclar los dos enfoques, la filosofía ágil asegura que los procesos se implementen eficientemente a la vez que aceptan los cambios; y los modelos tradicionales aseguran que se consideren todos los procesos relevantes.

Pero de inmediato fui al centro de mi exposición: una de las grandes diferencias, radicales por demás, entre los métodos tradicionales y los ágiles es que estos últimos son generativos, no prescriptivos. Los procesos necesitan evolucionar según las necesidades, no prescritos con anticipación. Un enfoque prescriptivo genera procesos complejos y complicados, mientras que un enfoque generativo comienza con un conjunto de procesos simples y adiciona otros a medida que se requieren.

La filosofía ágil reconoce que los procesos de software más efectivos no pueden definirse por adelantado; es un proceso continuo. Los métodos tradicionales se enfocan en definir y reforzar procesos y gastan muy poco tiempo en identificar y entregar lo que los usuarios necesitan. Aunque su propósito es mejorar la consistencia y la calidad, esto muchas veces se consigue a expensas de la productividad y la entrega. El enfoque tradicional de procesos tipo CMMI también usa herramientas monolíticas y pesadas que causan construcciones frágiles y traspasos inefectivos entre desarrollo, pruebas, despliegue y operaciones.

A esta altura de mi coloquio, la suerte estaba echada. Decir eso en una Conferencia dedicada a adorar a los procesos y a modelos tipo CMMI podría tomarse como sacrilegio. Lo que siguió fue enfatizar en lo que significa ser ágil: específicamente, la interiorización y la práctica de los Valores y Principios del Manifiesto Ágil, nada de lo que no haya hablado en algunos de mis artículos citados más abajo en las referencias.

Pero contrario a mi desazón, la reacción de mis oyentes fue bastante positiva. Era el final del evento, todos estábamos cansados, pero muchos quisieron ir más allá y tuve la oportunidad de compartir experiencias luego de mi charla con muchos de los presentes. La misión, la mía, estaba cumplida: sembrar una semilla, una llama que motive a los colegas a mirar en otra dirección. Por supuesto que dije que ágil no era la solución, pero sí una muy buena alternativa, una que nos está permitiendo volver a amar la profesión, volver a querer que sea lunes en el trabajo, para seguir innovando con cada interacción.

Referencias

Las diapositivas de la conferencia la pueden descargar de: