InicioBlogGestión Un modelo razonable: aplicar metas y prácticas genéricas CMMI a las prácticas específicas ágiles
Un modelo razonable: aplicar metas y prácticas genéricas CMMI a las prácticas específicas ágiles
29.11.2009
Combinar la agilidad con un modelo de procesos puede ser estrategia o astracanada: una táctica razonada y razonable, o el disparate de un gestor engañado, o perdido por las ganas de engañar.
Los modelos de procesos como CMMI, ISO 15504, o Spice (que fue la versión beta de éste último) sirven para producción industrial, donde los protagonistas y responsables del saber hacer y de la calidad son los procesos; y donde las personas se necesitan para asistir a éstos.
"La industria manufacturera ha reconocido la importancia de la efectividad de los procesos y la eficiencia. Hoy en día, muchas organizaciones en el sector manufacturero y de servicios a reconocer la importancia de los procesos de calidad"...
En la década de 1930, Walter Shewhart comenzó a trabajar en la mejora de procesos con sus principios de control estadístico de calidad [Shewhart 1931]. Estos principios fueron refinados por W. Edwards Deming [Deming 1986], Philip Crosby [Crosby 1979], y Joseph Juran [Juran, 1988]. Watts Humphrey, Ron Radice, y otros extendido estos principios aún más y comenzó a aplicar a software en su trabajo en IBM y el SEI [Humphrey, 1989].
SEI ha tomado la premisa de la gestión sobre procesos, "la calidad de un sistema o producto es sobre todo consecuencia de de la calidad del proceso utilizado para su desarrollo y mantenimiento", y CMM se desarrolla sobre esta premisa. La creencia en esta premisa es compartida en todo el mundo por los movimientos de calidad, como lo demuestra la Comisión Electrotécnica Internacional (ISO / IEC) de la Organización Internacional de Normalización ISO..."
CMMI DEV 1.2, pág. 16
Las prácticas ágiles son exactamente lo contrario: métodos de trabajo que ayudan a los protagonistas responsables del know how y la calidad: las personas.
"Preferimos el valor de las personas y su interacción al de los procesos y las herramientas"
Manifiesto ágil.
Hay empresas o departamentos que integran o mantienen sistemas, o realizan otro tipo de tareas en las que quizá se puede externalizar en procesos el conocimiento necesario en un... ¿60, 70, 80%?.
En otros casos ocurre lo contrario.
Para no disparatar el modelo de producción conviene saber en qué caso se está, y no caer en la tentación de disolver el agua en el aceite. Los dos principios a la vez, no son posibles; sí lo es sin embargo una síntesis del conocimiento de ambos; y cuando se trata de una empresa ágil, que no busca también una evaluacion CMMI sino el conocimiento útil que de él puede emplear, este quizá sea un buen consejo:
Tomar las metas y prácticas globales de CMMI, pero olvidarse de aplicarlas a las áreas de procesos, y aplicarlas a las prácticas ágiles que emplean, porque CMMI cubre algo que las prácticas ágiles no abordan: la institucionalización y homogeneización de la forma de trabajo. Algo que llevan a cabo las metas y prácticas globales.
Se trataría de aplicar procesos para la homogeneidad en organización, la formación de las personas y la mejora de las prácticas y agilidad para la producción.
Más sobre CMMI y Agilidad, en el podcast en el que esta mañana hemos charlado Claudia , Agustín , David , JM y un servidor.
Aplicabilidad del modelo CMMI escrito por Carlos,
December 01, 2009
Hola, perdonad que me apunte a vuestro debate, pero me gustaría aclarar algunos términos sobre la aplicabilidad del modelo CMMI. CMMI como bien comienza a emplearse es un "modelo" de buenas prácticas que llevan realizando (ejecutando) multitud de compañías durante muchos años. No es un proceso, no es un procedimiento, solo un conjunto de buenas prácticas ordenadas y agrupadas por conceptos. No es secuencial, no hay que hacer todo lo que dice al pie de la letra. Generalmente las compañías interpretan mal el modelo y convierten las áreas de proceso en sus procedimientos. MAL. Los procesos de tu compañía son la descripción de como trabajas TU en tu organización, no como empleas CMMI (y creo que por ahí vas en el camino correcto). Si trabajas con SCRUM tu ciclo de vida de TU proyecto son tus sprints y eso (perdonad que no estoy muy puesto en scrum) es lo que tienes que valorar y definir. Como bien dices CMM se orienta a la gestión de los procesos. Pero es que SCRUM es otro proceso desde ese punto de vista!!! Es el proceso de producción del producto, sea software o no.
Lo que no me queda claro es como el Scrum master hace la detección de riesgos (o en Scrum no hay riesgos?) y como controla esos riesgos. Tampoco me queda claro como se gestiona en Scrum que al cliente se le entrega lo que realmente se le tiene que entregar (el software en la versión, rama o entregable que tienes que entregar). No os ha ocurrido nunca que entregas un programa fuente en la versión que no era? Cómo se gestiona el control de la configuración en las metodologías ágiles? Porque si, todos confiamos en la profesionalidad de las personas, pero gestionar las versiones de todos nuestros entregables sin un proceso creo que es complejo (y arriesgado). Y medir? como responden las metodologías ágiles a los objetivos estratégicos de la organización? cómo se relacionan? Y si en el proyecto participa un proveedor? como se gestiona desde el punto de vista de las metodologías ágiles? Y no digamos ya desde el punto de vista del tailoring. Admiten las metodologías ágiles la adaptación de la forma de trabajar?
De veras, creo que estamos comparando un ciclo de vida, esto es, una metodología de desarrollo con un ciclo de vida propuesto, con una gestión de los procesos de producción (en los que tienen cabida todos los ciclos de vida y metodologías de desarrollo), pero que su punto de vista es muuuucho más amplio.
Gracias y perdonad. Un saludo, Carlos.
Informar de comentario inadecuado
voto negativo
voto positivo
Votes: +0
Pero CMMI se auto-define como modelo para la mejora y evaluación de los procesos. escrito por Juan,
December 01, 2009
Hola Carlos,
Nada que perdonar, al contrario. Gracias por tu comentario. Coincido en que Scrum como práctica surgida de la práctica de gestión de proyectos, no cubre ni las áreas de solución teécnica ni las de gestión de la organización, como sí que cubren los modelos de procesos. Esta es la razón principal de Scrum Manager como marco global, y que se puede ver con más detalle en el curso "Introducción a Scrum Manager" de la plataforma OK (http://www.scrummanager.net/ok/)
No coincido tanto en que CMMI sea un conjunto de buenas prácticas. Creo más bien en como él mismo se define: un modelo que puede emplearse para mejorar los procesos de la empresa o para evaluar su capacidad. La única práctica que incluye es la revisión entre pares, y en su día la consultora ESI que me dio formación de CMMI, y me explicaba que no son prácticas de cómo hacer las cosas, sino un modelo de qué cosas hacer, no me supo explicar esa excepción de las revisiones de pares.
Creo, como tu, que el modelo de trabajo debe ser global, considerando todas las áreas e implicaciones en la organización, pero prefiero dar el protagonismo de los resultados a las personas, que a los procesos, como afirma CMMI en su introducción.
Combinar la agilidad con un modelo de procesos puede ser estrategia o astracanada: una táctica razonada y razonable, o el disparate de un gestor engañado, o perdido por las ganas de engañar.
RSS de los comentarios
CMMI como bien comienza a emplearse es un "modelo" de buenas prácticas que llevan realizando (ejecutando) multitud de compañías durante muchos años. No es un proceso, no es un procedimiento, solo un conjunto de buenas prácticas ordenadas y agrupadas por conceptos. No es secuencial, no hay que hacer todo lo que dice al pie de la letra.
Generalmente las compañías interpretan mal el modelo y convierten las áreas de proceso en sus procedimientos. MAL. Los procesos de tu compañía son la descripción de como trabajas TU en tu organización, no como empleas CMMI (y creo que por ahí vas en el camino correcto). Si trabajas con SCRUM tu ciclo de vida de TU proyecto son tus sprints y eso (perdonad que no estoy muy puesto en scrum) es lo que tienes que valorar y definir.
Como bien dices CMM se orienta a la gestión de los procesos. Pero es que SCRUM es otro proceso desde ese punto de vista!!! Es el proceso de producción del producto, sea software o no.
Lo que no me queda claro es como el Scrum master hace la detección de riesgos (o en Scrum no hay riesgos?) y como controla esos riesgos. Tampoco me queda claro como se gestiona en Scrum que al cliente se le entrega lo que realmente se le tiene que entregar (el software en la versión, rama o entregable que tienes que entregar). No os ha ocurrido nunca que entregas un programa fuente en la versión que no era? Cómo se gestiona el control de la configuración en las metodologías ágiles? Porque si, todos confiamos en la profesionalidad de las personas, pero gestionar las versiones de todos nuestros entregables sin un proceso creo que es complejo (y arriesgado). Y medir? como responden las metodologías ágiles a los objetivos estratégicos de la organización? cómo se relacionan? Y si en el proyecto participa un proveedor? como se gestiona desde el punto de vista de las metodologías ágiles? Y no digamos ya desde el punto de vista del tailoring. Admiten las metodologías ágiles la adaptación de la forma de trabajar?
De veras, creo que estamos comparando un ciclo de vida, esto es, una metodología de desarrollo con un ciclo de vida propuesto, con una gestión de los procesos de producción (en los que tienen cabida todos los ciclos de vida y metodologías de desarrollo), pero que su punto de vista es muuuucho más amplio.
Gracias y perdonad.
Un saludo,
Carlos.