¿Alguien todavía cree en el modelo de madurez de capacidades para el software?

StackOverflow https://stackoverflow.com/questions/65296

  •  09-06-2019
  •  | 
  •  

Pregunta

Hace diez años, cuando me encontré por primera vez con el MMC para software Supongo que, como a muchos, me sorprendió la precisión con la que parecía describir el caótico estado de "nivel uno" del desarrollo de software en muchas empresas, particularmente con su referencia a la dependencia de los héroes.También parecía proporcionar una guía realista para que una organización ascendiera de nivel mejorando sus procesos.

Pero si bien parecía proporcionar un buen modelo y una guía realista para mejorar, nunca fui testigo de que una adhesión a CMM tuviera un impacto positivo significativo en ninguna organización para la que he trabajado o con la que he trabajado.Conozco una gran consultora de software que afirma tener el nivel 5 de CMM, el nivel más alto, cuando puedo ver de primera mano que sus procesos son tan caóticos y la calidad de sus productos de software tan variada como otras empresas que no utilizan CMM.

Entonces me pregunto: ¿alguien ha visto un beneficio real y tangible al adherirse a la mejora de procesos según CMM?

Y si ha notado una mejora, ¿cree que la mejora fue específicamente atribuible a CMM, o un enfoque alternativo (como seis sigma) ¿han sido igual o más beneficiosos?

¿Alguien todavía cree?

Además, para aquellos que aún no lo han visto, miren este divertido porque es cierto. parodia

¿Fue útil?

Solución

Para un típico taller de programación de CMM de nivel 1, vale la pena hacer el esfuerzo para llegar al nivel 2;Esto significa que debes pensar en tus procesos y escribirlos.Naturalmente, esto encontrará resistencia por parte de los programadores vaqueros que se sienten limitados por los estándares, la documentación y los casos de prueba.

El esfuerzo por pasar del nivel 2 ("hay un proceso") al nivel 3 ("todos tienen el mismo proceso") normalmente se estanca en la guerra entre departamentos, por lo que probablemente no valga la pena comenzar.

Otros consejos

Me pareció un ejercicio de documentación inflado que se utilizaba principalmente como vehículo para adquirir/mantener contratos.Una vez que tuvimos el contrato, fue un ejercicio sortear el proceso.

Como desarrollador, no obtuve nada de esto, pero perdí MESES de mi vida profesional jugando con CMMI.

Lo mismo ocurre con 6 Sigma, al que llamé "Sentido común en una caja".No necesitaba que me capacitaran para descubrir cuál era el problema de un proceso; en general, era bastante evidente.

Para mí, los equipos pequeños y los mecanismos ágiles funcionan mucho mejor.Ciclos cortos, mucha comunicación.Puede que eso no funcione en todos los entornos, pero definitivamente funciona en el mío.

Sólo mis dos centavos.

En el meollo del asunto se encuentra este problema, claramente descrito por la propia guía CMM...

...Es necesario un buen criterio para utilizar la CMM correctamente y con perspicacia.La inteligencia, la experiencia y el conocimiento deben configurar una interpretación adecuada de la CMM en un entorno específico.Esa interpretación debe basarse en las necesidades y objetivos comerciales de la organización y los proyectos.Una aplicación del CMM de memoria y orientada a listas de verificación tiene el potencial de dañar a una organización en lugar de ayudarla...

De la página 14, sección 1.6 de El modelo de madurez de capacidades, pautas para mejorar el proceso del software por el Instituto de Ingeniería de Software de la Universidad Carnegie Mellon, ISBN 0-201-54664-7.

Si ve que CMM se ejecuta.Y corre rápido.

Tanto CMM como CMMI ofrecen algunos beneficios si su organización toma en serio las lecciones que intenta enseñar.El problema es que llegar a los niveles más altos es muy difícil y costoso, y la única vez que he visto a una organización hacer el esfuerzo es porque sus clientes no les permiten ofertar por contratos hasta que estén en un cierto nivel.

Esto tiene el efecto de que la organización hace todo lo posible para "simplemente obtener el número" sin preocuparse realmente por mejorar su proceso.

¿El extremo superior?No.Las tiendas CMM-5 no me impresionan.

¿El extremo inferior?Sí.Las organizaciones CMM-1 me asustan.

CMM puede ayudar a un equipo nuevo/novato a medirse y hacer cosas de superación personal.

CMMI no se trata realmente de mejorar su software, sino de documentar lo que ha hecho.Casi se puede estimar el nivel CMMI de una empresa por el peso de la documentación que produce.

Fondo:Estudié CMMI en mi programa de posgrado en Ingeniería de Software y trabajé en un equipo que siguió sus lineamientos.

Mi experiencia es que la CMM es tan vaga que es muy fácil de cumplir.Además, cuando vienen a certificarte, miran el proyecto que elige tu organización.Donde solía trabajar, este era el proyecto sin una fecha límite real, con mucho dinero y mucho tiempo para dedicar a cada rincón del proceso.Muchos de los otros proyectos continuaron con poca o ninguna revisión de código/diseño, a veces sin software de control de versiones.

Creo que el énfasis en la certificación CMM es desafortunado.Las empresas saben cómo funciona el sistema y lo hacen.En lugar de centrarse en una mejora real del proceso que cumpla con sus objetivos, se centran en obtener una certificación y hacer funcionar el sistema.Sinceramente, creo que la mayoría de las organizaciones preferirían dedicar tiempo a lo primero en lugar de perder tanto tiempo en lo segundo.

Realmente lo que importa es contar con personas conscientes que quieran tomar buenas decisiones de desarrollo y sepan que necesitarán ayuda para tomar esas decisiones.No hay sustituto para los programadores de calidad que saben que la programación es una actividad grupal continua en la que es tan probable que cometan un error como cualquier otra persona.

He estado realizando muchas entrevistas para equipos pequeños que realizan desarrollo iterativo.Personalmente, si veo CMM en un currículum es una gran señal de alerta que indica interés en el proceso sobre los resultados.

Existen todos los métodos formales para vender libros/cursos de formación/certificaciones, y por ningún otro motivo.Por eso existen tantos métodos formales.Una vez que te des cuenta de esto, eres libre :-)

tudon todavía cree.Pero también podría seguir creyendo que el mundo se acabará con el año 2000.

Esto no es algo en lo que personalmente pondría mucha fe o en lo que quisiera unirme en el futuro.Pero muchas veces lo nuestro no es razonar por qué...

PDAunque un poco fuera de tema, me gustaría mencionar que las certificaciones CMMI falsas son muy comunes, al igual que las certificaciones reales obtenidas mediante soborno.

CMM realmente no habla de la calidad del software, sino más bien de la documentación y la repetibilidad del proceso.En otras palabras, es posible tener un proceso de desarrollo ordenado y repetible, pero aun así crear software de mala calidad.Siempre que el proceso esté debidamente documentado, es posible alcanzar el nivel 5 de CMM.

Al fin y al cabo, CMM es otra herramienta que se puede utilizar o mal utilizar.Si el objetivo final es mejorar la calidad del software, es posible utilizar CMM para mejorar el proceso de desarrollo y mejorar la calidad del software.Si el objetivo es alcanzar un determinado nivel de CMM, lo más probable es que la calidad del software se vea afectada.

El modelo está perdiendo credibilidad, primero porque las empresas lo adoptan no buscando un modelo de desarrollo de software más maduro, sino que sea evaluado a un nivel CCMI.

Y el otro problema, el que creo que conduce a la pérdida de credibilidad, es que, como contratista, no tiene garantía de que el proyecto que le vende su proveedor de tasación CMMI se desarrollará utilizando las prácticas modelo.La etiqueta CMMi solo indica que la empresa alguna vez desarrolló proyectos que fueron evaluados como adherentes a un nivel de madurez CMMi específico.

El problema no es sólo de CMMi sino del proceso desarrollado por las empresas.El CMMi no describe el proceso en sí, sino simplemente lo que debe hacer el proceso.Tienes el mismo problema con PMBOK.En realidad, el problema no es sólo el PMBOK, sino principalmente los malos directores de proyectos que afirman seguir las declaraciones del PMI.

En la escuela me enseñaron:CMM es una buena idea, pero al carecer de certificación (cualquiera puede decir que es nivel 5 / nivel 4) termina siendo una herramienta de marketing para tiendas offshore.Entonces, sí, la idea es buena, pero ¿cómo se demuestra la adherencia?

Yo solía.Pero ahora encuentro que CMM y CMMI no encajan tan bien con los enfoques ágiles.

Oh, seguro que puedes apretar cosas para meter esa clavija cuadrada en el agujero redondo, pero a la hora de la verdad, todavía estás basando tu enfoque en la capacidad de predecir todo lo que se necesita y anticipar todo lo que se encontrará al construir una sistema de software.

¡Y todos sabemos lo bien que funciona ese enfoque en la vida real!(-:

salud,

Robar

Agile es la próxima CMM y ambas son frágiles.El campo de la consultoría de procesos y calidad es un buen negocio en cualquier industria y, al igual que los ingenieros, todos necesitan nuevas palabras de moda para mantener el flujo de dinero.

CMM, cuando surgió por primera vez del SEI, era un buen concepto basado en un sólido trabajo académico, pero pronto fue adoptado por los consultores de procesos y ahora es una certificación sin valor, que es utilizada por la mayoría de los CIO para cubrirse el trasero (nadie fue despedido por elegir una empresa CMM Nivel 5)

Agile tomará ese camino pronto y entonces podremos estar seguros de que pronto veremos la próxima solución milagrosa en el horizonte :)

Cuando trabajaba en software de vuelos comerciales, usábamos CMM y, a medida que nuestros procesos mejoraron, mejoró nuestra capacidad para predecir con precisión los tiempos de finalización.Pero este fue un proceso engorroso; otros enfoques deberían funcionar igual de bien.

Los proyectos más pequeños dependen menos del proceso para tener éxito.La métrica clave es la proporción de héroe a espectador.Cualquier proyecto con un HTBR inferior a 0,2 está en serios problemas.

Hay bastantes buenas ideas que cualquier organización puede adaptar y adoptar fácilmente por su propio bien, pero obtener una insignia es una molestia debido al requisito de todo tipo de documentación redundante.

El problema es que CMMi no es un proceso, sino simplemente una guía para cualquier proceso que elija tener y eso en sí mismo invita a que fluyan ideas a medias.

Otro punto es que la migración es un verdadero dolor de cabeza cuando estás empezando, pero supongo que es lo mismo que cualquier otro problema inicial.

El principal problema para comprender el valor de CMMi es comprender el propio CMMi.

CMMi es un enfoque documentado para la mejora continua de la producción de software.

Comprender la mejora continua con SPC ya es bastante difícil en la fabricación, pero si se añade el producto de software intangible, la dificultad es exponencial.

Recomendaría a cualquier persona u organización nueva en CMMi:documentar su proceso actual y luego observar qué resultados (costo/beneficio) se pueden medir independientemente del proceso.De esta manera, si se cambiara algún proceso o procedimiento estándar, se produciría un "mejor" resultado.El requisito previo para este ejercicio es un proceso documentado, estable y repetible, ya que es imposible medir el beneficio de cualquier cambio dentro de un entorno ad hoc, ya que no se comparan "similares".

Al centrarse inicialmente en los conceptos anteriores, la organización comenzará a comprender y adoptar el valor esencial del CMMi.

Cuenta la leyenda que el Departamento de Defensa de EE. UU., que realizó muchos contratos, descubrió que muchos de sus proyectos enfrentaban excesos de tiempo y costos, e incluso cuando se entregaron, los proyectos no eran exactamente lo que se había ordenado.

Por eso querían una manera de estar seguros de que un contratista podría realizar entregas a tiempo, dentro del presupuesto y cerca de lo requerido.Así nació el modelo de madurez de capacidades.

La tesis es que si las cosas se escriben, sobreviven al desgaste.Pero decir que anotarlo todo no sería suficiente, hay que comprobar que estén escritos correctamente.Entre otras cosas.

A lo largo de todo esto, nunca se les pasó por la cabeza considerar el costo de hacer todo esto.Porque desde el punto de vista del Departamento de Defensa, si entregó un proyecto de 1 millón de dólares para conseguir algo en un año, y acabó pagando 10 millones de dólares en 10 años y no consiguió lo que querían, y ahora, si en cambio tuvieran pagar 5 millones de dólares por eso mismo para conseguir lo que realmente querían en dos años, todavía están ahorrando 5 millones de dólares, y ni hablar de que en realidad están consiguiendo algo.

Entonces, si es contratista del Departamento de Defensa de EE. UU. o algo así, continúe y obtenga CMM, porque sería un requisito.Pero si estás compitiendo con miles de tiendas de desarrollo de software en elance, para conseguir proyectos con presupuestos limitados, tiempo limitado, etc.CMM no es una buena opción.

Dicho esto, no dudes en leer el pdf de CMMI Dev (v 1.3 al momento de escribir este artículo).Tiene muchos puntos buenos.Deconstruye muy bien la organización.Y si ves algún punto que te haga decir '¡ajá!Tengo este problema', entonces utilice esa sabiduría para resolver su problema.En nuestro caso, un pequeño cambio que hicimos fue asegurarnos de hacer una lista de todas las personas que pueden darnos requisitos.Si había más de una persona a la que se le permitía darnos requisitos, entonces cualquier requisito procedente de una fuente se hacía circular entre las demás y tenían que decir "está bien" antes de que lo añadiéramos al trabajo pendiente.Este pequeño cambio marcó una gran diferencia en cuánto trabajamos y reelaboramos.

En resumen, observe las áreas de proceso y compárelas con sus áreas de dolor, y siga las sugerencias dadas por CMM.La forma en que lo implementes es tuya.Y siempre puedes implementarlo de una manera que no te lleve demasiado tiempo ni cueste demasiado dinero.Pero supongo que lo mismo se aplica incluso a las normas ISO/IEC pertinentes.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top