{"id":1707,"date":"2015-12-07T11:30:25","date_gmt":"2015-12-07T10:30:25","guid":{"rendered":"http:\/\/qualilogy.com\/es\/?p=1707"},"modified":"2015-12-07T16:19:06","modified_gmt":"2015-12-07T15:19:06","slug":"software-quality-maturity-model-technical-debt","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/software-quality-maturity-model-technical-debt\/","title":{"rendered":"Software Quality Maturity Model & Technical Debt"},"content":{"rendered":"

\"Software<\/a>Creo que todos vosotros conoc\u00e9is CMMI.<\/span> Este modelo desarrollado por<\/span> el Software Engineering Institute<\/span> ofrece<\/span> cinco<\/span> niveles de madurez<\/span> con el fin de<\/span> medir la<\/span> calidad de los servicios<\/span> de TI y<\/span> mejores<\/span> pr\u00e1cticas asociadas<\/span> con esta<\/span> escala de niveles<\/span>. <\/span><\/p>\n

No voy a<\/span> escribir<\/span> un post entero<\/span> sobre este modelo<\/span>, ya que no es el objetivo<\/span> de este art\u00edculo,<\/span> sino que simplemente<\/span> lo presentar\u00e9<\/span> como yo pudiera<\/span> resumirlo<\/span> a alguien<\/span> que no sabe nada<\/span> acerca de la<\/span> gesti\u00f3n de<\/span> proyectos y<\/span> del desarrollo de aplicaciones. <\/span><\/span><\/p>\n

CMMI, los diferentes niveles<\/h2>\n

El modelo empieza en el nivel 1, donde no hay ning\u00fan proceso definido. <\/span>Esto es lo que yo llamo \u00abel nivel de los campeones\u00bb o, \u00abthe stuff of heroes\u00bb, \u00abelegidos para la gloria\u00bb, ya que el \u00e9xito de un proyecto depende de la presencia de un campe\u00f3n, como un experto de las tecnolog\u00edas empleadas o un director de proyecto con experiencia <\/span>. <\/span>En resumen, al menos una persona, generalmente bien reconocida, siempre deseada y que va a terminar con m\u00e1s frecuencia asignada a proyectos prioritarios. <\/span>El fracaso de otros proyectos no anima a la organizaci\u00f3n a mejorar.<\/span><\/span><\/p>\n

El objetivo de nivel 2 (\u00abManaged\u00bb en la terminolog\u00eda CMMI) es poner en marcha procesos que permitan precisamente superar a los campeones y garantizar el \u00e9xito del proyecto por cualquier equipo que los implementa. <\/span>Esto es lo que yo llamo ‘repetir el \u00e9xito’, independientemente de los individuos.<\/span><\/p>\n

Estos procesos se ajustan posteriormente (Nivel 3 \u00abDefined\u00bb), es decir, se adaptan seg\u00fan el proyecto, con bucles de mejora para sacar provecho de cada experimento y mejorar. <\/span>El nivel 4 (\u00abQuantitatively Managed\u00bb) implementa m\u00e9tricas y mediciones estad\u00edsticas para controlar los procesos, y as\u00ed sentar las bases del nivel 5 (\u00abOptimized\u00bb) en el que la organizaci\u00f3n trabaja en un proceso de constante optimizaci\u00f3n.<\/span><\/p>\n

CMMI, nivel cero<\/h2>\n

Siempre me ha sorprendido que el modelo se inicia en el nivel 1, ya que, de hecho, a este nivel, no hay nada, ning\u00fan proceso, es amateurismo perfecto. <\/span>Pero me permiti\u00f3 definir lo que yo llamo el \u00abCMMI nivel cero\u00bb, que conviene a algunas organizaciones que he conocido, cuando la cultura de la empresa promueve y apoya la aparici\u00f3n de campeones. <\/span>En lugar de tratar de progresar a nivel 2, donde la \u00abgente indispensable\u00bb no se necesita para el \u00e9xito de un proyecto, los managers m\u00e1s bien tienen una mala opini\u00f3n de cualquier intento de creaci\u00f3n de un peque\u00f1o proceso un poco <\/span>organizado, y por ejemplo consideran una p\u00e9rdida de tiempo cualquier documentaci\u00f3n para replicar las tareas usuales del proyecto y asegurar su continuidad en la ausencia de \u00abcampeones\u00bb. Incluso ayudan a crear situaciones inextricables y extremadamente dif\u00edcil de superar con el objetivo de demostrar que son del \u00abstuff de los heroes\u00bb. <\/span>Como<\/span> \u00abVamos a cambiar todo a \u00faltima hora y trabajar durante toda la noche para entregar ma\u00f1ana a toda prisa.\u00bb<\/span><\/span><\/p>\n

En general, esos managers dividen el mundo entre los \u00abwinners\u00bb \u2014 grupo en que obviamente consideran que pertenecen \u2014<\/span> y \u00abloosers\u00bb, esos pobres infelices d\u00e9biles y caprichosos que posiblemente pudieran, pero en general reh\u00fasen, a trabajar en el caos permanente generado por una jerarqu\u00eda elitista <\/span>. <\/span>Esos managers no quieren progresar hacia el nivel 2 sino por contrario evolucionaer hacia abajo: un nivel cero de la Calidad donde cualquier idea de mejora es sospechosa y fantasiosa.
\n<\/span><\/p>\n

Un modelo de madurez de<\/span> la calidad del software<\/span><\/h2>\n

El modelo<\/span> CMMI<\/span> ha perdido<\/span> popularidad desde<\/span> que algunas empresas<\/span> supuestamente<\/span> certificadas<\/span> en el nivel<\/span> m\u00e1s alto<\/span> han demostrado en realidad ser<\/span> incapaces de<\/span> ofrecer una<\/span> calidad de servicio<\/span> correcta<\/span>. Pero tiene la<\/span> ventaja para<\/span> m\u00ed de ser<\/span> l\u00f3gico y<\/span> f\u00e1cilmente comprensible<\/span> por todos,<\/span> y en muchas \u00e1reas<\/span>.
\n<\/span><\/p>\n

As\u00ed que imagin<\/span>\u00e9<\/span> el siguiente modelo<\/span><\/a> que propongo<\/span> para los clientes<\/span> que quieren<\/span> medir su<\/span> nivel de madurez en<\/span> la Calidad de software<\/span>.
\n<\/span><\/p>\n

\"Qualilogy_Modelo_Madurez_Calidad_Software\"<\/a><\/p>\n

En el primer nivel, no hay procesos o estructura de gesti\u00f3n de la calidad del software. <\/span>Eso no quiere decir que no hay iniciativas, pero es s\u00f3lo por unos campeones que deciden por s\u00ed mismos de instalar en su proyecto una herramienta de an\u00e1lisis de c\u00f3digo, controlar <\/span>versiones o hacer un seguimiento de los bugs y de Change Requests.
\n<\/span><\/span><\/p>\n

El nivel dos se caracteriza por una actitud reactiva a los problemas de calidad: la organizaci\u00f3n busca identificar defectos de software, el incumplimiento de las buenas pr\u00e1cticas de programaci\u00f3n que puedan afectar a los usuarios y poner en peligro el negocio de la empresa, o <\/span>causar retrasos en la entrega de aplicaciones y incrementar los costes de mantenimiento. <\/span>En este nivel, la gesti\u00f3n de la calidad del software usualmente se conf\u00eda a una estructura espec\u00edfica, que instala y gestiona de manera centralizada una plataforma de Calidad que consta con herramientas que pueden utilizar los proyectos, pero con procesos obligatorios y no siempre muy flexibles<\/span>. <\/span>Este equipo realiza a petici\u00f3n Quality Gates, por lo general para aprobar o rechazar la entrega de una nueva versi\u00f3n de aplicaci\u00f3n por un proveedor externo, y a veces lleva a cabo auditor\u00edas a petici\u00f3n del management.
\n<\/span><\/span><\/p>\n

El nivel tres permite cambiar a una actitud proactiva en la que ya no se contenta simplemente de identificar y responder a defectos en la calidad del software, sino de prevenirlos, y tan pronto como sea posible en el ciclo de vida del <\/span>proyecto. <\/span>Esto requiere un proceso de Integraci\u00f3n Continua y por lo general algunas pr\u00e1cticas \u00c1giles.<\/span><\/span><\/p>\n

En el nivel cuatro, las m\u00e9tricas de calidad se utilizan para medir y controlar la calidad del software en todos los aspectos de la gesti\u00f3n de proyectos. <\/span>Los outsourcers deben cumplir con los SLA (Service Level Agreement o Acuerdo de Nivel de Servicio) que se basan en estas m\u00e9tricas. <\/span>Se hacen benchmarkings para comparar los proveedores y situarlos en un ranking muy apreciado por los servicios de Compras: \u00abSe\u00f1or, usted pas\u00f3 de quinto a s\u00e9ptimo lugar este trimestre. Se necesita hacer algo. Espero de usted un esfuerzo<\/span>\u00ab. <\/span>Las organizaciones de TI utilizan medidas de calidad con el fin de elaborar un mapa de sus sistemas de informaci\u00f3n y definir una estrategia para cada bloque de aplicaciones.<\/span><\/p>\n

En el nivel cinco, se anima a los proyectos para optimizar la gesti\u00f3n de la Calidad con la experimentaci\u00f3n de nuevas pr\u00e1cticas, como revisiones de c\u00f3digo por pares, el desarrollo basado en pruebas (Test Driven Development) o Extreme Programming (XP <\/span>). <\/span>Los resultados en calidad de c\u00f3digo se miden y se comparan para determinar cu\u00e1les de esas pr\u00e1cticas son m\u00e1s fructiferas en el corto, medio o largo plazo. <\/span>Formaciones y talleres (workshops) se llevan a cabo para difundir las mejores pr\u00e1cticas y fomentar su adopci\u00f3n.<\/span><\/p>\n

Madurez y Deuda T\u00e9cnica<\/span><\/span><\/h2>\n

La medici\u00f3n de la Deuda T\u00e9cinca puede utilizarse en todos los niveles del modelo. <\/span>No en el nivel uno, claro, excepto por unos campeones que conocen la met\u00e1fora, pero esto ser\u00eda iniciativas aisladas, y, adem\u00e1s, no siempre entendidas por el management. <\/span><\/span><\/p>\n

Las auditor\u00edas a nivel 2 pueden basarse en una evaluaci\u00f3n de la deuda t\u00e9cnica, sobre todo cuando el management tiene preguntas en cuanto a la estrategia que escoger para una aplicaci\u00f3n. <\/span>He utilizado con frecuencia la evaluaci\u00f3n de la Deuda T\u00ebcnica durante assessments, en conjunto con ciertos criterios, como la criticidad de la aplicaci\u00f3n y su alineaci\u00f3n con el negocio. <\/span>Por ejemplo, dentro de la misma empresa, encontrar\u00e9mos nuevos mercados de alto crecimiento que dan lugar a nuevas aplicaciones en las que el time-to-market, la fiabilidad y el rendimiento son fundamental para diferenciarse de la competencia y ganar preciosas <\/span>cuotas de mercado. <\/span>En los mercados m\u00e1s antiguos, la estrategia se centrar\u00e1 en el mantenimiento de los m\u00e1rgenes, y por lo tanto el cumplimiento de los presupuestos de TI: entonces nuestra evaluaci\u00f3n de la Deuda T\u00e9cnica se alinea con la capacidad de mantenimiento de aplicaciones.
\n<\/span><\/span><\/p>\n

Siempre es importante alinear la Deuda T\u00e9cnica con el negocio para responder a las preguntas formuladas por la direcci\u00f3n TI\u00a0 y ofrecer diferentes estrategias y planes de acci\u00f3n: externalizaci\u00f3n de aplicaciones, transferir el conocimiento a un otro equipo interno (posiblemente compuesto de <\/span>desarrolladores externos), refactorizaci\u00f3n, reingenier\u00eda (ver nuestra serie de posts<\/a> sobre el tema). <\/span>Para un assessment de la calidad de una aplicaci\u00f3n, la evaluaci\u00f3n de la Deuda T\u00e9cnica representa un verdadero valor a\u00f1adido para el cliente.
\n<\/span><\/span><\/p>\n

En el nivel 3, la Deuda T\u00e9cnica se mide diariamente o al menos de manera frecuente por el equipo del proyecto, para evitar la inflaci\u00f3n de la deuda y de sus intereses. La <\/span>Deuda t\u00e9cnica se gestiona en cada iteraci\u00f3n del proyecto y no espec\u00edficamente al final (Quality Gate) u ocasionalmente (auditor\u00eda) como en el nivel 2.
\n<\/span><\/span><\/p>\n

En el nivel 4, la Deuda T\u00e9cnica se mide de manera normalizada en todos los proyectos. <\/span>Esto se traduce en los SLAs para los proveedores externos. <\/span>Por ejemplo:<\/span><\/span><\/p>\n