Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta CMMI. Mostrar todas las entradas
Mostrando las entradas con la etiqueta CMMI. Mostrar todas las entradas

miércoles, octubre 07, 2015

Principios para Frameworks de Procesos de Software Efectivos

Septiembre 28 de 2015, por Scott Ambler



El framework de decisión de procesos de Disciplined Agile se guía por los siguientes principios:
  1. Elegir es bueno y tomar decisiones informadas es mejor. Cada equipo es una colección única de individuos que enfrentan situaciones únicas dentro del contexto de una organización particular. Un único proceso no sirve para todo. Para facilitar la elección, el framework DA soporta varios ciclos de vida de entrega y es un proceso dirigido por metas. Y más importante, el framework DA describe las compensaciones involucradas con una gran variedad de prácticas ágiles y no ágiles que permiten a las personas a tomar decisiones inteligentes relacionadas con prácticas para adoptar la situación actual que enfrentan.
  2. Optimizar el todo. El framework DA cubre todo el ciclo de TI, mostrando como encajan todos sus elementos. Si los equipos no entienden el entorno de los procesos, corren el riesgo de optimizar localmente sus propios procesos causando detrimento en el todo. Por ejemplo, el equipo de manejo de datos puede tener su propio proceso basado en estrategias DAMA (Gestión de Datos, por sus siglas en inglés) tradicionales, mientras que el equipo de entrega puede tener el proceso basado en los principios del Manifiesto Ágil y el equipo de operaciones puede tener su proceso basado en ITIL. Las cosas así, el proceso general se vuelve inefectivo porque estas tres estrategias individuales se contradicen y se degradan unas con otras cuando se combinan.
  3. Cada equipo es dueño de su proceso. Los equipos y las personas miembros de esos equipos deben ser libres de mejorar la forma en que trabajan basados en su aprendizaje en el tiempo. En el parloteo ágil decimos que estos equipos “son dueños de sus procesos”.
  4. Mejorar continuamente. Personas, equipos y organizaciones deben esforzarse por aprender y mejorar continuamente la forma en que trabajan. El framework DA incluye la meta de proceso Mejorar el Proceso y el Entorno del Equipo, la cual describe opciones para hacer exactamente lo que esto implica. También tiene un apartado explícito para el Mejoramiento Continuo de procesos que describe las estrategias para compartir mejoras entre equipos, incrementando de esta forma la velocidad de los esfuerzos de mejora de procesos de su organización.
  5. Promover y apoyar el cambio en el proceso. Los departamentos de TI son sistemas adaptativos complejos. Una implicación de esto es que cualquier mejora que un equipo haga puede cambiar la forma en que trabajan con otros equipos, motivando mejoras de proceso dentro de esos equipos. Estos cambios a su vez pueden motivar mejoras dentro de otros equipos y así sucesivamente. Los equipos ágiles disciplinados son conscientes de su estatus corporativo y entienden que necesitan trabajar con otros equipos para ayudarlos a entender y a adoptar nuevas innovaciones y a prepararse para que otros los ayuden a hacer lo mismo.
  6. Resultados repetibles son mucho más importantes que los procesos repetibles. Los equipos efectivos se enfocan en producir resultados repetibles, tales como entregar software de alta calidad que cubra las necesidades de los interesados de manera efectiva en tiempo y en costo. Debido a que cada equipo se encuentra así mismo en una situación única, para ser más eficientes necesitan seguir un único proceso personalizado que refleje esa situación. Ese “único proceso” puede constar de un ciclo de vida relativamente estándar y de prácticas comunes tales como la ideación de la arquitectura, pruebas de regresión de la base de datos y muchas otras (asumiendo que estas prácticas también se personalicen para reflejar esa la situación). A cada equipo en su organización se le debe permitir seguir su versión del proceso, idealmente compartiendo componentes similares del proceso, definidos por un framework común de proceso, para lograr los resultados requeridos.
  7. El empirismo es mucho más importante que la teoría. Observar qué tan bien funciona una técnica en la práctica y, más importante aun, observar el contexto de las situaciones en las que (no) funciona, es de mayor valor para los practicantes que las teorías o la prognosis sobre lo que debería funcionar. La teoría tiene su lugar, pero es una prima pobre del empirismo. El framework DA se desarrolló originalmente basado en observaciones de docenas de organizaciones en todo el mundo y ha evolucionado desde entonces basado en el aprendizaje de muchas otras. Además está siendo respaldado por investigaciones en curso de nuestra industria.


Los departamentos de TI son sistemas adaptativos complejos únicos. Cualquier persona que trabaje en un ambiente así necesita un framework de proceso que sea lo suficientemente flexible como para que aborde el amplio rango de situaciones que enfrentan sus equipos. El framework de decisión de procesos DA es liviano a la vez que lo suficientemente flexible para soportar el escalamiento tanto a nivel táctico como estratégico.

-----
Nota del traductor, o sea yo:

Este artículo se publicó originalmente en inglés por Scott Ambler, bajo el título de “Principles for Effective Software Process Frameworks” que pueden encontrar en: http://www.disciplinedagiledelivery.com/software-process-framework-principles/

Publicado con permiso del autor.

jueves, abril 23, 2015

Sobre medir y controlar o de cómo Tom DeMarco admitió su equivocación

“El Control conduce al cumplimiento; la autonomía conduce al compromiso.”
Daniel H. Pink (Autor de “A Whole New Mind: Why Right-Brainers Will Rule the Future”)

Imágen tomada del artículo de Computer.org
En 1982, Tom DeMarco escribió su renombrado libro “Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982). La primera frase del libro, su primerísima idea, quedó ensamblada en los anales de la industria de software durante las siguientes décadas y nos ha llegado intacta hasta esta era. Se trata de su: “No puedes controlar lo que no puedes medir”.

Este pensamiento influyó de manera certera en los modelos de calidad, procesos de producción, enfoques de mejora* y herramientas de construcción de software, quizás como ninguna otra idea de aquellos tiempos. Pero incluso Tom DeMarco cambió de opinión. En 2009 publicó este artículo en la IEEE Computer Society: “Software Engineering: An Idea Whose Time Has Come and Gone?”  (Ingeniería de Software: ¿una idea cuyo momento ha pasado?)” que pueden encontrar haciendo clic aquí.

En el artículo, DeMarco reflexiona sobre si este consejo era correcto en ese momento, sobre si todavía era relevante (al momento de escribir ese artículo en 2009) y que si todavía creía que las métricas eran un deber ser para cualquier esfuerzo exitoso de desarrollo de software. Sus propias respuestas fueron unos tajantes no, no y no.

Es bien conocida la historia de que los enfoques rígidos más tradicionalistas adhirieron completamente a este precepto y crearon áreas de proceso y de conocimiento dedicadas en su totalidad al establecimiento, gestión y control de métricas en los proyectos (de software). A partir de allí, se empezó a medir el éxito o fracaso de los proyectos, en principio, con tres de esas medidas: el tiempo, el presupuesto y la calidad, siendo esta última un poco más abstracta y más subjetiva si se quiere. Después, con muchas otras que no vale la pena mencionar aquí.
Esa institucionalización de métricas derivó a su vez en algo que con el tiempo se convirtió en uno de los mayores desincentivos para quienes trasegamos por los laberintos azarosos de la construcción de productos de software: el trabajo intensivo, esas largas jornadas de trabajo de doce, dieciséis y más horas diarias durante largos períodos de tiempo previos a la entrega del producto. Mi amigo y colega Jorge Abad dice en su blog Lecciones-Aprendidas.info que eso trajo como consecuencia la destrucción de hogares, de familias enteras y yo le creo.

Esta forma de trabajo extrema, cuya consecuencia principal, además de la citada por Jorge, era la de un bajón en productividad, acompañado de una entrega de producto con mala o malísima calidad, con el tiempo degeneró en algo mucho más grave que es de todos conocido: desmotivó a las nuevas generaciones a estudiar carreras relacionadas con la TI: Ingeniería Informática, de Sistemas, de Software y afines. El mismo Tom DeMarco (¡otra vez!) enunció en su otro libro, “Peopleware : Productive Projects and Teams” (2ª edición, 1999), que “no trabajamos horas extras en demasía para terminar el trabajo a tiempo sino para protegernos de culpa cuando inevitablemente no conseguimos hacer el trabajo a tiempo.” En efecto, lo hacíamos simplemente para cumplir, no para ser más productivos, ni para mejorar la calidad del producto. Y a eso nos llevó la fuerza ejercida por el modelo de Comando y Control y de la medición de cosas que no reflejaban la realidad del proyecto, al menos no la realidad de las personas que ejecutaban el proyecto.

La reflexión de DeMarco en el artículo que ya he citado termina también de manera asombrosa para quienes seguimos sus cánones durante casi tres décadas: “Consistencia y predictibilidad aun son deseables, pero nunca han sido las cosas más importantes. En los últimos 40 años, por ejemplo, nos hemos torturado con nuestra incapacidad de terminar proyectos de software a tiempo y en el presupuesto. Pero esta nunca ha sido la meta suprema. La meta más importante es transformación, creando software que cambie el mundo o que transforme una compañía o cómo esta hace negocios.”

Bien sabemos ya que lo más importante en los proyectos de software es la entrega continua y frecuente de Valor al negocio, desde el inicio del proyecto. Y que nunca más apostaremos o usaremos artes adivinatorias para establecer la fecha de entrega, ni qué parte del producto entregaremos en ese momento, ni cuánto será su costo. En cambio, empezaremos con planes y alcance iniciales y nos enfocaremos en la revisión continua de esas restricciones a medida que vamos avanzando. Finalmente, nuestra meta será siempre entregar el mejor producto posible, teniendo presente que ningún método con el enfoque de receta de cocina (léase métodos tradicionalistas) hará mejor lo que es mejor. Esta es la filosofía ágil.

Coletilla

Aquella aciaga prescripción de DeMarco sobre lo que se puede medir y controlar derivó en procesos rígidos, tradicionalistas, que dieron poder solo a algunas personas en la organización; pero lo realmente hermoso, lo humanamente divino, es que los métodos y las prácticas ágiles dan poder a todo el mundo… o a nadie.



--------------------------------------------------
* Por ejemplo, H. James Harrington, reconocido autor de libros sobre mejora de procesos, calidad, desempeño y gestión del conocimiento, y fundador del laureado Instituto Harrington, extendió el pensamiento de DeMarco, diciendo: “Medir es el primer paso hacia el control y eventualmente hacia la mejora. Si no puedes medir algo, no puedes entenderlo. Si no puedes entenderlo, no puedes controlarlo. Si no puedes controlarlo, no puedes mejorarlo.”

viernes, abril 17, 2015

#RSGECU2015: Ágil es algo que eres, CMMI es algo que usas

#RSGECU2015: Ágil es algo que eres, CMMI es algo que usas
Este viernes 17 de abril, presenté en el Regional Scrum Gathering 2015, en Quito, mi disertación sobre Ágil y enfoques tradicionales. Mi asunto principal es 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, como erróneamente pregonan muchos. Los líderes de los procesos actuales pueden y deben 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 tipo 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.

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 alejado de lo que se está hablando en el  #RSGECU2015.

Hacia el final quise poner mi propio manifiesto, el ‘Ágil es algo que eres…’, se trata de la persona, no de las cosas ni de los procesos. Ya lo he dicho en otras oportunidades, ser ágil significa reemplazar la predictibilidad falsa por la eficiencia.

¿Quieres saber más?

Pueden descargar la nueva versión de la presentación haciendo clic aquí o en esta dirección: http://goo.gl/leJ5N8.


No olviden escribirme con sus inquietudes o sugerencias a lucho.salazar@gmail.com o en el foro del blog.

domingo, octubre 26, 2014

#Agiles2014: Ágil es algo que eres, CMMI es algo que usas

Ser ágil significa reemplazar la predictibilidad falsa por la eficiencia
ser ágil significa reemplazar la predictibilidad falsa por la eficiencia
Con una actualización debido al cambio de audiencia, presenté en #Agiles2014 mi disertación sobre Ágil y CMMI. Como en la versión 1.0, durante la SEPG LA 2014 en Manizales, 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 deben 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.

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 alejado de lo que se habló en el resto de #Agiles2014.

Hacia el final quise poner mi propio manifiesto, el ‘Ágil es algo que eres…’, se trata de la persona, no de las cosas ni de los procesos. Ya lo he dicho en otras oportunidades, ser ágil significa reemplazar la predictibilidad falsa por la eficiencia.

Para descargar la presentación

Puedes descargar las memorias de esta conferencia de: http://goo.gl/rhNMcf


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: