{"id":177,"date":"2012-10-22T11:20:43","date_gmt":"2012-10-22T10:20:43","guid":{"rendered":"http:\/\/dev.qualilogy.com\/es\/?p=177"},"modified":"2013-01-05T11:21:23","modified_gmt":"2013-01-05T10:21:23","slug":"entregar-la-calidad-22","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/entregar-la-calidad-22\/","title":{"rendered":"Entregar la calidad (2\/2)"},"content":{"rendered":"<p><a href=\"http:\/\/vicken.deviantart.com\/\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-2457\" title=\"QualDeliverQuality2\" src=\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/10\/QualDeliverQuality21.jpg\" alt=\"Deliver Quality\" width=\"267\" height=\"401\" \/><\/a>\u00bfQu\u00e9 lecciones podemos aprender si se aplica al campo de la calidad del c\u00f3digo los principios de ITIL para la Gesti\u00f3n de la Capacidad?<\/p>\n<p>Vimos en <a title=\"Entregar la calidad\" href=\"http:\/\/qualilogy.com\/es\/entregar-la-calidad-12\" target=\"_blank\">el post anterior<\/a> que, para proporcionar la Calidad de acuerdo con los SLAs, la planificaci\u00f3n y los presupuestos, necesitamos saber lo que tenemos, es decir, conocer el portafolio de aplicaciones y tambi\u00e9n la calidad de esas mismas.<\/p>\n<p>Este conocimiento basado en los indicadores cuantitativos y cualitativos permite satisfacer mejor las necesidades de los usuarios y del negocio, como veremos en este segundo y \u00faltimo articulo de esta serie.<\/p>\n<p><!--more--><\/p>\n<h3><strong>Responder a las necesidades del negocio<br \/>\n<\/strong><\/h3>\n<p>Hacer m\u00e1s, mejor y m\u00e1s r\u00e1pido con menos es el reto principal de los equipos de proyecto actualmente. El management est\u00e1 constantemente tratando de ajustar los recursos a nivel de actividad del proyecto, especialmente en los proveedores, y no es raro ver a uno o m\u00e1s desarrolladores pasar a otro equipo al final de un proyecto. El conocimiento del c\u00f3digo se pierde, y con ello la fiabilidad en la predicci\u00f3n de las cargas y de los costes de realizaci\u00f3n de una nueva versi\u00f3n.<\/p>\n<p>Incluso cuando las especificaciones funcionales son precisas, la carga exacta puede variar de simple a doble o incluso m\u00e1s, dependiendo del tama\u00f1o del c\u00f3digo, su complejidad, su legibilidad, la dificultad con la que introducir cambios sin fallo.<\/p>\n<p>Conocer la aplicaci\u00f3n y su estado de un punto de vista cuantitativo y cualitativo permite entonces establecer una estrategia. Por ejemplo:<\/p>\n<ul>\n<li>\u00bfHay cambios en esta \u00e1rea que presenta riesgos para la mantenibilidad? Si realmente debemos tocar cualquier de estos componentes, entonces mejor planear una QA exhaustiva para cada uno de ellos y evitar regresi\u00f3n.<\/li>\n<li>Se necesita una refactorizaci\u00f3n previa en esta parte de la aplicaci\u00f3n porque hay demasiado c\u00f3digo duplicado que nos va a costar un gran esfuerzo para implementar los cambios solicitados. Es mejor volver a re-escribir algunos de esos componentes en lugar de perder tiempo para identificar todos los trozos de c\u00f3digo copiado y pegado donde introducir los cambios. Este refactoring tambi\u00e9n disminuir\u00e1 las cargas de prueba y el riesgo de error.<\/li>\n<li>Esta aplicaci\u00f3n no est\u00e1 bien documentada, con una muy baja tasa de comentarios, y hay demasiados nuevos desarrolladores en el equipo. Mejor proporcionar unos d\u00edas extra de descubrimiento del c\u00f3digo, incluso redocumentaci\u00f3n al comienzo del proyecto. Esto puede evitar sorpresas desagradables m\u00e1s adelante, y tal vez podr\u00e9mos recuperar el tiempo perdido, sobre todo en caso de cambio funcional durante el proyecto.<\/li>\n<\/ul>\n<p>No es posible definir un plan de acci\u00f3n, un nivel de recursos y un calendario sin saber lo que tenemos y la calidad de lo que tenemos.<\/p>\n<h3><strong>Optimizar la decisi\u00f3n<\/strong><\/h3>\n<p>Otra lecci\u00f3n que podemos establecer desde una analog\u00eda con la Gesti\u00f3n de la Capacidad y me parece particularmente interesante: la posibilidad de orientar una solicitud de los usuarios basandonos en datos objetivos.<\/p>\n<p>ITIL precisa que la gesti\u00f3n de la infraestructura debe hacerse:<\/p>\n<ul>\n<li>En cumplimiento de los acuerdos de nivel de servicio, que son m\u00e1s a menudo una cuesti\u00f3n de disponibilidad de recursos.<\/li>\n<li>De manera rentable: una disponibilidad de 100% no es el objetivo porque ser\u00eda demasiado costoso.<\/li>\n<\/ul>\n<p>Un ejemplo. En un departamento de marketing, los usuarios de un software de CRM (Customer Relationship Management) se quejan de las demoras y de los retrasos durante la temporada navide\u00f1a, cuando m\u00e1s se utiliza, y que los SLAs no se respetan. Piden una actualizaci\u00f3n del servidor en el entorno producci\u00f3n, y que se mantengan sus compromisos, sin costo alguno para ellos.<\/p>\n<p>El Capacity Manager luego se re\u00fane con ellos y les explica que la potencia disponible en el servidor es de 8 000 MIPS, es insuficiente para una disponibilidad \u00f3ptima en las \u00faltimas dos semanas del a\u00f1o, pero s\u00f3lo 6 000 MIPS se utilizan durante los once meces y medio restante. A lo largo del a\u00f1o, los acuerdos de nivel de servicio se cumplen.<\/p>\n<p>Con este conocimiento, se puede proponer varias soluciones:<\/p>\n<ul>\n<li>Actualizar el servidor de acuerdo con los usuarios, pero con un coste correspondiente a los recursos adicionales.<\/li>\n<li>Proporcionar 50 semanas al a\u00f1o la potencia de 6 000 MIPS, o un poco m\u00e1s con el fin de mantener un margen de seguridad, y subir a 9 000 MIPS en las 2 semanas restantes. La factura ser\u00e1 menor, incluso con el coste adicional de la intervenci\u00f3n para a\u00f1adir los MIPS que faltan y manejar esta flexibilidad adicional.<\/li>\n<li>Una otra soluci\u00f3n posible: rebajar el servidor para entregar 6 000 MIPS durante todo el a\u00f1o, a coste de la degradaci\u00f3n de los recursos a\u00fan mayores durante la temporada navide\u00f1a. Esta soluci\u00f3n podr\u00eda considerarse en caso de restricciones presupuestarias y \/ o si se reducen las acciones de marketing.<\/li>\n<\/ul>\n<p>Cuando se trata de desarrollo de aplicaciones, se asume que la calidad es necesariamente m\u00e1ximal, mientras que las prioridades son por lo general los plazos y los presupuestos que siempre se deben cumplir. Ahora sabemos bien que r\u00e1pido y barato no rima con calidad. Especialmente que el planning m\u00e1s a menudo se decide en el comienzo del proyecto, mientras que las especificaciones a\u00fan no est\u00e1n fijadas y las cargas de trabajo a menudo fluct\u00faan, siempre en aumento.<\/p>\n<p>Si esto ocurre en tu proyecto y esperas retrasos, utiliza una herramienta de an\u00e1lisis de c\u00f3digo dentro de un proceso de Integraci\u00f3n Continua lo que permite, como el Capacity Manager:<\/p>\n<ul>\n<li>Demostrar con medidas cualitativas (n\u00famero de violaciones bloquantes, criticas, etc.) que la deuda t\u00e9cnica es controlada y el nivel de calidad del c\u00f3digo se mantiene.<\/li>\n<li title=\"Permalink to La m\u00e9trique ABC\">Justificar el tiempo adicional necesitado para implementar las nuevas funcionalidades con el aumenta de la complejidad de desarrollo y de pruebas (en estos temas, ver <a title=\"Complexit\u00e9 et effort de test\" href=\"http:\/\/qualilogy.com\/es\/complejidad-y-esfuerzo-de-qa\" target=\"_blank\">Complejidad y esfuerzo de QA<\/a> et <a title=\"La m\u00e9trica ABC\" href=\"http:\/\/qualilogy.com\/es\/la-metrica-abc\" rel=\"bookmark\" target=\"_blank\">La m\u00e9trica ABC<\/a>).<\/li>\n<li>Proponer soluciones.<\/li>\n<\/ul>\n<p>Estas pueden ser m\u00faltiples:<\/p>\n<ul>\n<li>Posponer la fecha de entrega con el fin de mantener el nivel de calidad esperado, guardar el control de la deuda t\u00e9cnica y realizar un plan de pruebas completo.<\/li>\n<li>Mantener los plazos inciales pero aceptando un riesgo para la calidad y bugs potenciales para los usuarios. Probablemente se necesitar\u00e1 un refactoring ulteriormente.<\/li>\n<li>Entregar una primera versi\u00f3n de la aplicaci\u00f3n sin tener todas las caracter\u00edsticas que se esperan, pero respectando el calendario y con una calidad aceptable sin riesgos excesivos para los usuarios. Una segunda versi\u00f3n completar\u00e1 las funcionalidades en un segundo tiempo, y permitir\u00e1 corregir los errores de la primera versi\u00f3n.<\/li>\n<\/ul>\n<p>\u00ab M\u00e1s con menos \u00bb no significa producir m\u00e1s c\u00f3digo con menos recursos como a menudo veo que lo piensan muchos usuarios o clientes. Esto significa ser capaz de responder adecuadamente a las solicitudes de usuarios siempre m\u00e1s exigentes, en t\u00e9rminos de funcionalidad, plazos y presupuestos.<\/p>\n<p>Establecer un proceso de Integraci\u00f3n Continua con una herramienta de an\u00e1lisis de c\u00f3digo, una Quality Gate en QA o antes de implementar en Producci\u00f3n, y SLAs (ver <a title=\"Casos de uso\" href=\"http:\/\/qualilogy.com\/wp-admin\/qualilogy.com\/application-quality\/use-cases-working-seamlessly\/?lang=es\" target=\"_blank\">Casos de uso \u2013 Encajar a la perfecci\u00f3n<\/a>) y podr\u00e1s disponer de datos objetivos que te permitir\u00e1n ofrecer estrategias alternativas para tus clientes y tus managers, sobre la base del conocimiento y el control \u00f3ptimo de tus aplicaciones.<\/p>\n<p>Como lo demuestran los principios ITIL de la Gesti\u00f3n de la Capacidad, para satisfacer las necesidades de los usuarios y facilitar la decisi\u00f3n de los directivos se requiere datos objetivos y conocimientos cuantitativos y cualitativos de las aplicaciones.<\/p>\n<p>M\u00e1s y mejor con menos: entrega la calidad a tiempo y dentro de los presupuestos.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>\u00bfQu\u00e9 lecciones podemos aprender si se aplica al campo de la calidad del c\u00f3digo los principios de ITIL para la Gesti\u00f3n de la Capacidad? Vimos en el post anterior que, para proporcionar la Calidad de acuerdo con los SLAs, la planificaci\u00f3n y los presupuestos, necesitamos saber lo que tenemos, es decir, conocer el portafolio de [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-177","post","type-post","status-publish","format-standard","hentry","category-calidad-de-aplicaciones"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/177"}],"collection":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/comments?post=177"}],"version-history":[{"count":1,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/177\/revisions"}],"predecessor-version":[{"id":178,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/177\/revisions\/178"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/media?parent=177"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/categories?post=177"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/tags?post=177"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}