SonarQube 4.0: ¿Technical Debt como métrica?
javaHispanoAcaba de ser publicada la versión 4.0 de SonarQube, una aplicación que permite obtener información de calidad del código escrito. En esta nueva versión han decidido sustituir en el widget Rules compliance el rules compliance index (ICR de ahora en adelante), un valor objetivo que indica el grado de cumplimiento de las reglas definidas para un perfil determinado, por el Technical Debt (TD de ahora en adelante), un valor que indica el esfuerzo a invertir en un proyecto para lograr el cumplimiento de las reglas, un valor que se calcule como se calcule considero que es subjetivo, y que depende de la habilidad del equipo de trabajo.
Considero que el ICR debería seguir presente de forma directa en el widget y en la aplicación y que el TD debería ser un dato adicional o secundario por las siguientes razones:
- El ICR es un valor objetivo, medido sobre la calidad del código real tecleado, en cuyo cálculo no intervienen valores o apreciaciones subjetivas.
- El TD es un valor subjetivo, ya que si bien depende de los mismos datos en los que se basa el ICR cuantifica el esfuerzo de corrección de los incumplimientos detectados para obtener una supuesta métrica de calidad que informa del esfuerzo medido en días u horas a invertir en el proyecto para obtener el 100% del ICR. Es precisamente esta subjetividad la que creo que disminuye su valor y utilidad como métrica, pues si bien puede ser interesante yo creo que no debería ser más que orientativa para comparaciones.
- Tanto el grado de cumplimiento de las reglas como la capacidad de la corrección dependen de la habilidad y conocimiento del equipo de trabajo. Pero a diferencia del ICR, esa subjetividad en el esfuerzo necesario para corregir un problema introduce un elemento externo al propio código escrito (la habilidad o conocimientos de un equipo de trabajo), lo que la relegaría a la categoría de estimación, no de métrica realista.
- Las métricas deben ser valores obtenidos de forma objetiva, en la que la posibilidad de subjetividad no pueda intervenir en su cálculo
- Las relaciones entre clientes y proveedores peligran cuando existe subjetividad en la forma de medir la calidad del software o cuando no se pueden cuantificar los valores, y no se pueden establecer relaciones de confianza entre ambos en las entregas de productos. Por ejemplo, es fácil y objetivo pedir un grado de cumplimiento de un conjunto de reglas (ICR) de un 90% (no voy a entrar en más detalles para no abrir una discusión que no es el objeto de este contenido), pero si ese valor se ve relegado por el TD, ¿qué le puedo exigir a mi proveedor? ¿Que el TD sea inferior a 1 día?
¿Qué opináis vosotros?
Nota: noticia enviada por Ramón Rial
Reader Comments (19)
"Las relaciones entre clientes y proveedores peligran cuando existe subjetividad en la forma de medir la calidad del software o cuando no se pueden cuantificar los valores"
Ya, el problema es que por muchos que nos gustaría no existe ninguna medida objetiva que permita medir la calidad del software. Cualquier metrica que se pueda obtener a partir de un análisis estatico del código el ICR, el TD o el VAYAUSTEASABÉ es puramente orientativa.
Estas herramientas pueden tener alguna utilidad para que el equipo detecte problemas, para ayudar a identificar ciertas areas problematicas, pero no valen absolutamente para nada si no se analizan luego por expertos de manera totalmente subjetiva, basada en su experiencia y en su criterio.
Cuando realmente peligra la relación entre clientes y proveedores es cuando no existe confianza y utilizamos estas metricas para establecer valores "objetivos" de la calidad del software. Ese es el verdadero peligro, tomarse demasiado en serio estas metricas.
Alfredo, no se trata tanto de medir la calidad del código a ojo (a groso modo calidad se define como la percepción subjetiva que tiene un cliente de un producto) sino de medir la calidad en función de un conjunto de reglas predefinidas que el proveedor conoce de antemano, y el análisis que se realiza del grado de cumplimiento determina un índice denominado ICR.
Eso es objetivo, y podremos opinar de modo diferente acerca de si tal regla es más o menos útil, o completamente inútil. Pero no interviene la apreciación subjetiva: si yo cliente te digo que el bloque de código de los if/else debe ir siempre delimitado por {} y no lo cumples, el no cumplimiento es objetivo, no subjetivo.
Cuando se establecen relaciones por medio de contratos entre clientes y proveedores yo como cliente contrato un producto y no tengo por qué fiarme de que el proveedor lo va a hacer bien, prefiero tener algún tipo de mecanismo que me permita encauzar cierto tipo de uso del lenguaje por los derroteros que yo quiero (conjunto de reglas), y asumir las consecuencias derivadas de la elección de tal conjunto de reglas. Dependiendo de mi mayor o menor conocimiento de las reglas, del lenguaje de programación, de la arquitectura... etc. ese conjunto de reglas podrá ser más o menos extenso (no activaré una regla si no sé para que vale o si no le veo utilidad práctica), pero eso no quiere decir que no valgan para nada.
Y repito, en los negocios eso de confiar puede estar bien en ciertos casos, pero no puedes dejar simplemente en la confianza el (buen) hacer de un proveedor. Ningún proveedor que haga bien las cosas pone pegas a este tipo de control (y repito, se trata de encauzar parte de su trabajo), pero este es sólo el comienzo del problema. El problema en sí es más complejo, y en el caso que me ocupa tiene que ver con la entrega, la proporción de la solución técnica, la validez de las pruebas diseñadas, la documentación, la funcionalidad, la escalabilidad, el rendimiento...
Yo sí le doy la importancia que creo que se merecen esas métricas, ya que como cliente puedo exigir que se escriba el código con un determinado estilo, por ejemplo, y no con el estilo de la empresa, con el objetivo de uniformizar la legibilidad del mismo.
Creo que el tema de calidad daría para mucho, igualmente que el tema de las métricas, y casi siempre clientes y proveedores tendremos enfoques distintos sobre su validez, cada uno por unas razones diferentes.
Evidentemente las reglas son puramente objetivas, el problema del análisis de calidad de un producto software es que es totalmente subjetivo. Intentar buscar mecanismos objetivos para medir algo que es de naturaleza puramente subjetiva no es una buena idea. Mientras estas reglas se utilicen para "orientar" a un equipo en ciertos aspectos pueden ser de utilidad, yo las utilizo de vez en cuando, si se cruza la barrera y se usan estas reglas como criterios objetivos de validación... mala cosa.
En el mejor de los casos estas reglas pueden servir para diferenciar lo malo de lo muy malo, pero poquita cosa más. Siempre me gusta recordar un caso que contaba alguien con este tema:
Un consultor llega a un equipo de trabajo, tienen muchos bugs y su código no es muy bueno, les pide que mejoren su nivel de cobertura de pruebas, algo totalmente medible. Semanas después observa orgulloso las graficas de cobertura viendo la evidente mejora, sin embargo, pasan las semanas y el nivel de bugs y el descontento de los usuarios sigue exactamente igual, entonces decide inspeccionar más el problema, y cuando empieza a leer los test descubre que todos son de este estilo:
try {
objetoAprobar.metodoAProbar(..,..)
assertTrue(true)
} catch(...) {
assertTrue(true)
}
¿La conclusión?, cobertura pedi cobertura me dieron. Si pides metricas, metricas vas a tener, ¿software de calidad?, eso como siempre, puede que si, lo más probable es que que no.
Si me quedará aqui esto sólo seria una critica destructiva y no me gusta hacer esas cosas, así que te planteo mi alternativa, cosas que yo haría:
- Antes de empezar el proyecto, entrevistar a todo el equipo de desarrollo, ver código de sus proyectos anteriores. No voy a dejar un software que es importante para mi en manos de alguien que no conozco y de los que además no puedo ver trabajos anteriores.
- Fijarme en cosas como la rotación de personal de los empleados del proveedor, fijarme en su grado de satisfacción, fijarme en si en esa empresa los técnicos hacen verdadera carrera profesional.
- Entregas cortas y un contrato que permita rescindirlo en cuanto el cliente no este satisfecho con las entregas. (entregas cada semana dos semanas máximo).
- Si es la primera vez que trabajo con ese equipo, las primeras iteraciones me integro con ellos, siendo parte del equipo, haciendo pair programming codo con codo, para ver como lo hacen de primera mano.
- En cada iteración, cojo una feature al azar, y le pido al desarrollador/es que la ha desarrollado que se siente conmigo y me cuente como lo ha echo, que decisiones ha tomado, que test a escrito o no a escrito etc,etc.
¿fantasías?, no lo creo, en mi opinión la fantasía es seguir haciendo lo mismo y esperar que de repente algún día funcione. Esto de las metricas de calidad y tal lo he visto muchas veces, lo he intentado en el pasado con más de un equipo y más de dos, y el resultado ha sido siempre el mismo, una perdida de tiempo.
Alfredo, estoy de acuerdo contigo en el ejemplo que pones, pero yo no sólo pido cobertura, sino pruebas reales, y reviso las entregas que me hacen mis proveedores. El ejemplo que pones en realidad altera el valor de las métricas, porque no se ha escrito código de prueba real, sino un código para alcanzar un nivel de cobertura. Y eso es algo que prohibimos en mi trabajo desde el día uno de inicio de un proyecto, lo que no impide que nos las intenten colar.
El ejemplo que me pones es uno de los motivos de rechazo de la entrega, ya que las pruebas han de responder a cinco principios (enumerados bajo el acrónimo FIRST):
* Serán rápidas (FAST).
* Serán independientes (ISOLATED).
* Serán repetibles (REPEATABLE).
* Informarán de su resultado (SELF-VERIFYING).
* Han de estar a tiempo (TIMELY).
A esos cinco principios yo añado siempre que han de ser válidas, acorde con el objetivo que toda prueba persigue, y el objetivo de las pruebas no es alcanzar cobertura (ese es un requisito de la entrega), sino que el objetivo de las pruebas es garantizar en un alto grado que el código funciona como se espera en el mayor número de casos posibles.
Yo llevo con este tipo de temas desde hace cinco años, intentando que los proveedores se sumasen a esta iniciativa (entonces voluntaria, para que se fuesen acercando a un escenario que valoráramos poner como obligatorio) y desde hace dos lo exigimos a nuestros proveedores, y nos va bastante bien, ya que encontramos los problemas comunes sin necesidad de que lleguen a preproducción y además de forma automática, nos permite además dedicar esfuerzos en realizar las revisiones con cierta tranquilidad en cuanto a la calidad del código (por ejemplo, revisar si las pruebas son adecuadas, hemos rechazado muchísimas entregas por el problema que comentas), podemos revisar la documentación, buscar problemáticas que no detecta el Sonar o que detecta incorrectamente, etc.
Además, el hecho de que existan las reglas no quiere decir que no puedan ser discutidas. Hay casos de falso positivo, casos donde la aplicación estricta de las reglas puede no ser posible por frameworks impuestos por nosotros o casos donde no compensen las pruebas porque (como señalan jmarranz y Abraham en su artículo) el código que escribo sólo se utilizará una vez... Para estos casos los proveedores nos envían su opinión en la casuística, nosotros la estudiamos y, de coincidir con ellos, podemos llegar a excluir código del análisis. Tampoco se trata de decir que sí a todo, sino a lo razonable. En ese sentido mi compromiso personal con ellos es que, como mínimo, me comprometo a estudiar ese tipo de problemáticas.
De todas formas el post no pretendía entrar a valorar la utilidad en sí de las métricas como herramienta de medición de calidad del software, ya que, en nuestro caso al menos (hablo del mío porque lo conozco), la medición de calidad del software contempla un escalón que es la medición automática de la calidad del software, pero es un proceso que lleva mucho tiempo y esfuerzo. Lo que pretendía con el post era recabar opiniones acerca del Technical Debt, que en SonarQube se considera como una métrica, aunque para su cálculo se tomen como parte de la fórmula unos valores que dependen de la habilidad técnica de un equipo de trabajo y que, como es lógico, difieren de uno a otro.
Sin embargo me alegra tener este tipo de intercambio de opiniones, compartir los puntos de vista creo que es enriquecedor, aunque no se alcance un acuerdo.
Y yo no he empleado la palabra fantasía, simplemente he dicho que ya que pago no entiendo por qué tengo que confiar en quien no conozco. Puedo confiar en mis amigos en muchos aspectos, y confío en que los favores que me hacen y los consejos que me dan son con la mejor intención. Pero cuando se trata de desconocidos (yo trabajo en la administración y no puedo contratar con quien quiero, que para eso debo respetar la ley de contratos en vigor; de hecho ni siquiera valoro ofertas, por lo que a mí me dicen "este es el equipo de trabajo") sólo atiendo a lo que me entregan, no entro a valorar en si saben más o menos, sino en el resultado que me entregan.
Estoy totalmente de acuerdo con Alfredo. Yo no lo hubiera dicho mejor.
Las reglas inhiben la creatividad y la creatividad es crucial si queremos hacer buen software. Es cierto que no tener ninguna norma puede afectar la productividad, por eso lo que hay que hacer es tener la reglas justas para no llegar a ese punto pero no más. Esto es la teoría del límite del caos.
Todo el tiempo y esfuerzo que dediquemos a cuplir esas reglas no lo estamos dedicando a los asuntos importantes, por ejemplo una mejor interfaz de usuario. Nuestro objetivo ha de ser que el usuario diga "Guau" no tener las mejores métricas.
Esta forma de medir la calidad del software me gusta más:
12 Steps to Better Code
javierpaniza, en lo principal estoy de acuerdo, no entender las reglas y exigir su cumplimiento sin más puede ser un problema.
Pero la creatividad es algo que requiere de una habilidad técnica para que salga bien, y no, las reglas no limitan la creatividad. Lo que las reglas pretenden evitar son malas prácticas, como por ejemplo, dependencias cíclicas entre paquetes. Cuando depuras este tipo de problemáticas te das cuenta de que el código queda mucho más limpio y más fácil de mantener, pero en ocasiones llegamos a pensar que esto no interesa a los proveedores, porque aumenta la independencia del cliente.
En Galicia, mi tierra natal, hay arquitectos muy "creativos" que levantan edificios con tejado plano, sin tejas, edificios circulares en los que se desperdicia muchísimo espacio... y a corto plazo esos edificios presentan goteras, porque llueve tanto en mi tierra que el tejado plano con tejas es el que mejor protección ofrece frente a goteras... raro es el edificio que no posee el característico tejado triangular con tejas. Y sin embargo, verás edificios planos que reciben premios, y de los que presumen los arquitectos... hasta que empiezan a gotear. ¿Creativos? Sí, pero ¿adecuados? ¿No habría sido mejor encauzarlos en los proyectos técnicos para que los diseñen de modo que sean adecuados al entorno en el que se levantan? Y no pretendo abrir un debate que involucre también a arquitectos de edificios.
Del trabajo con los proveedores estos dos años hemos sacado conclusiones tanto unos como otros, y coincidimos en lo siguiente:
1. No es lo mismo empezar de cero una aplicación y cumplir con un conjunto de reglas que asumir (heredar) una aplicación de otro equipo de trabajo y tener que elevar el cumplimiento de las reglas porque no se alcanza en el estado actual del software. Este hecho ya lo contemplamos en los niveles de exigencia, siendo estos niveles de exigencia en la casuística del software "heredado" mucho menores que en el software escrito desde cero.
2. Los equipos de desarrollo señalan que el esfuerzo para aumentar la calidad del software heredado que no ha empezado con ningún tipo de exigencias de cumplimiento de reglas, es muy elevado, sobre todo para alcanzar ciertos niveles.
3. Los equipos de desarrollo señalan que el esfuerzo dedicado a cumplir con esas mismas reglas cuando el código se escribe desde cero es despreciable en comparación a los beneficios que se obtienen a medio plazo.
4. El mayor handicap está en la escritura de casos de prueba para obtener una cobertura determinada, ya que al menos con la mayoría de proveedores de software con los que trabajamos no existe la cultura de escribir código de prueba a tiempo, ni siquiera para casos de prueba unitarios. Por lo tanto, se las pruebas las hacen manualmente... cuando las hacen.
Una cosa no entiendo ramón, si revisas las entregas manualmente, ¿entonces para que utilizas las métricas?. Puedo entender que las uses como guia inicial, por ejemplo con algo similar a los "hotspots" de sonar para partir de algún sitio en tu revisión, pero eso como guia, no como objetivo de cumplimiento obligado.
Me gusta el ejemplo de FIRST, porque precisamente me sirve para explicar muy bien lo que quiero decir, ¿cómo compruebas que se esta cumpliendo la T?, la T significa que los test se escriban en el momento adecuado, y el momento adecuado es antes del código (esa es la definición de uncle bob que es el autor del termino)
En una revisión a posteriori es bastante complejo determinar si los test han sido escritos antes o después. Con el método que te planteo es perfectamente posible analizar si los test se escriben antes o después. Te puedo asegurar que en una hora sentado con alguien del equipo haciendo pair programming te puedo decir mucho mejor que una herramienta cual es la calidad de los test que ese equipo esta produciendo.
No se trata sólo de este caso, es un ejemplo, trabajar con el equipo durante X (una iteración quizá) tiempo te puede dar una medida de la calidad que son capaces de producir infinitamente mejor que la que te va a dar cualquier herramienta de análisis estático. Y además creo que esto escala perfectamente, porque no necesito hacerlo en cada proyecto, poco a poco voy construyendo una red de proveedores de confianza y con los que ya conozco no necesito hacer esto cada vez.
Coincido plenamente contigo en que no tienes porque confiar en quien no conoces, precisamente por eso yo no pagaría por software realizado por gente que no conozco (desde el punto de vista profesional y de como realizan su trabajo se entiende claro esta). De lo que estoy hablando es justo de eso, de conocer de verdad a los equipos que van ha hacer el software, saber como trabajan, si usan o no buenas prácticas, cual es su nivel de motivación, sus condiciones laborales etc,etc.
Y Además si trabajas en la administración me preocupa más todavía, porque es software que se paga con mi dinero y que se utiliza para darme servicio. He trabajado en algún proyecto para la admin en el pasado y todos sabemos como se hacen las cosas, precisamente por eso lo que necesitamos creo va mucho más alla de elegir la metrica adecuada en el sonar, va de un cambio RADICAL en la mentalidad de como se hace el software para la administración, de los criterios de contratación, de como asegurar la verdadera calidad del software que estamos construyendo.
Pero bueno, esto es otro tema que daría para largos debates jeje. No quiero ser tan negativo, al menos estáis haciendo algo, como te decía antes quizas sirva para separar lo malo de lo muy malo, pero necesitamos mucho más.
Alfredo, intentaré contestar a las cuestiones que me planteas.
1. El por qué exijo las reglas aunque reviso manualmente es porque de ese modo estoy forzando a que se escriba el código siguiendo una serie de normas de estilo (checkstyle), por ejemplo,ya que ese es uno de los motores que se emplean en la revisión, y tenemos reglas configuradas a ese nivel. Si se alcanzase hipotéticamente hablando el 100% (que no lo exigimos, por supuesto), sabría que el estilo se estaría cumpliendo.
2. La comprobación del Timely la podemos realizar porque obligamos por contrato a que el código se escriba en nuestro SCM regularmente, y regularmente significa cada día: nada de esperar dos años a tener el código. Por lo tanto podemos revisar las pruebas en el momento que queramos. Eso no significa que se considere una entrega formal, ya que el código en ese estado tiene la consideración de "en desarrollo" (rama trunk), y sólo lo utilizamos para emitir recomendaciones y advertencias de cara a la entrega formal para que el proveedor no se lleve sustos. Aún así no siempre puedes revisar todos los aspectos en la rama trunk, pero intentamos evitar la mayor parte de inconvenientes en la entrega formal.
3. Siento repetirme, pero trabajo en la administración. Por lo tanto, esa relación de confianza que podría tener si se tratase de mi empresa, no puede existir. Las relaciones deben ser lo más asépticas posibles, entre otras cosas porque el mero hecho de que un proveedor trabaje perfectamente en uno de los proyectos que tengo o en todos, no significa nada más que eso. En la administración no se puede adjudicar a dedo, y en los últimos tiempos tampoco es que se prime la valoración técnica sobre criterios objetivos (precio, por ejemplo).
4. Los criterios de contratación están impuestos. En parte por la ley vigente, y en parte por quienes fijan el resto de criterios. Yo ahí ya no entro. Ni redacto pliegos técnicos ni los valoro.
5. Precisamente por la experiencia que tenemos con proveedores hemos decidido imponer un modelo que se aparta del típico modelo de nuestros proveedores. No tienes por qué creer mi palabra, no me conoces y por lo tanto no tienes por qué fiarte (ese era uno de mis propios argumentos), pero el paso que hemos dado (y repito que la medición automática es sólo uno de los pasos del procedimiento de calidad que estamos llevando adelante) era absolutamente necesario. Por poner un ejemplo, no concibo desarrollos en los que no existen pruebas automáticas, y nuestros proveedores no concebían desarrollos con pruebas automáticas. Así que mediante una aplicación que, entre otras cosas, mide la cobertura del código, obtengo un valor que les fuerza a escribir casos de prueba. Y a mí me queda la labor de comprobar si están bien diseñados (revisión automática y revisión manual). Y ya ni hablamos de otros tipos de prueba.
Para terminar este debate me gustaría decir que deseo encontrarme con una empresa que realmente sea capaz de hacer bien las cosas, te aseguro que cumplir con nuestras exigencias no sería para ellos un problema.
Por ejemplo, exigimos Maven para la construcción, para uniformizar las construcciones; también exigimos que las construcciones se hagan en nuestro Jenkins, y además que las construcciones de los proyectos se realicen en un entorno limpio (sin repositorio local). Y me encuentro con que el conocimiento de Maven en estas empresas brilla por su ausencia, pero todos se venden como expertos en la materia. A estas alturas el uso de Maven no debería resultar extraño para Java, pero lo es, y aún más, todo lo que se puede llegar a hacer con él... Nuestro verdadero objetivo es cambiar la mentalidad de las empresas, hacerles ver que deben cuidar sus entregables.
Un último apunte, ¿crees normal que en la entrega de un servicio web que se desplegará sobre un glassfish 2.1 -no te centres en la versión, es por un tema de plataforma- se encuentren en el WEB-INF/lib bibliotecas del glassfish de la versión 3.0, como las necesarias para despliegues? ¿O versiones duplicadas? Y esto es pecata minuta de lo que sufrimos hoy en día, porque antes, cuando no exigiamos este tipo de construcción lo que abundaban eran las construcciones cíclicas (proyecto A depende de proyecto B, y proyecto B depende de proyecto A). Al menos hemos dejado atrás esa problemática, y aunque aún nos queda camino por recorrer podemos reproducir las construcciones. Sólo por eso ya merece la pena, hemos simplificado la transferencia del conocimiento. Ahora puedes descargar la versión del SCM, ejecutar mvn clean package -por ejemplo-, y listo, ya construye.
Tampoco era el objetivo del artículo contar nuestro detalle, pero tampoco tendría inconveniente en hacerlo. Repito que la medición automática del Sonar es sólo una de las etapas. Pero las métricas son importantes, para garantizar que se van haciendo las cosas como queremos, porque creemos que así mejoraremos. Y hemos mejorado. Y nos queda mucho margen de mejora, pero ahora al menos los proveedores saben que si pagamos por un experto en JCAPS debe serlo de verdad, si pagamos por un experto en Java debe serlo de verdad, porque una vez adjudicado un concurso lo que debemos valorar es la entrega que se hace del software, la valoración de la cualificación técnica del personal ya se realizó anteriormente, en la fase de valoración de las ofertas, y ahora toca ver esa cualificación en la entrega que realiza el proveedor, y por lo tanto, comprobar con la entrega si la oferta técnica del personal se ajusta a la realidad.
Gracias por vuestra participación, son de agradecer los comentarios. De hecho no creo que hubiese problemas si queréis conocer cómo trabajamos, para que quedéis más tranquilos :), y por si os interesa presentaros a alguno de los concursos que se publican desde nuestra administración.
Hombre con nosotros tendrías algún problema, usamos gradle que mvn es una castañeja seria :P
Ramón el panorama que planteas es desolador. Proveedores que no usan ningún sistema de construcción automatica, que no hacen pruebas automaticas, dependencias cirulares (¿esto pasa en proyectos java a nivel de proyectos?, que barbaridad), me imagino que un nivel de duplicación por las nubes y habrás visto muchas otras perlas para escribir un libro. Aunque entiendo que desde tu posición haces lo que puedes, y al menos haces algo en la dirección correcta, me preocupa sobremanera que la media de empresas que desarrollan el software para la administración sea esta, si me disculpas lo voy a decir muy clarito, mierda impresentable.
Es un poco lo que te decía, esto sirve para separar lo muy (pero muy) malo del resto, es un poco como tratar de medir la calidad de una obra literaría mirando si tiene faltas de ortografía y usa correctamente los signos de puntuación, bien, es un minimo que toda obra debe cumplir pero no asegura en absoluto que se trate de un buen libro.
Como ciudadanos, no deberíamos conformarnos con esto, las empresas privadas que cada una se suicide como quiera, pero con el dinero de todos y con el software que va a gestionar nuestras administraciones deberíamos ponernos muy pero que muy serios.
Decía un buen amigo que una sociedad donde los mejores programadores esten haciendo una red social mientras que los más mediocres son los que construyen el software que gestiona nuestros hospitales o nuestros impuestos es una sociedad donde fallan muchas cosas, y cada vez que tengo la oportunidad de hablar con alguien de la administración y me recuerda como se hacen las cosas creo que tiene más razón.
Ya hago la pregunta en general ¿no podríamos hacer algo?, yo estoy dispuesto a trabajar gratis a tiempo parcial (que también tengo que comer) para hacer lo que haga falta y cambiar estas cosas, y estoy seguro que mucha gente más lo estaría.
Alfredo, yo diría que presentes ofertas para los concursos públicos. Si ganas alguno podrás dejar el pabellón muy alto. Y el hecho de que gradle sea superior no significa que tenga libertad para cambiar a esa herramienta cuando quiera, menos aún sin conocerla a fondo. He dicho que el proceso lo iniciamos hace tiempo, uno de los objetivos es cambiar la mentalidad de los proveedores. Lo que no podemos es cambiar las reglas del juego en mitad del partido, es decir, durante la ejecución de un contrato. No sería justo para ellos, así que Maven seguirá siendo nuestra baza principal. Pero somos los primeros interesados en mejorar, siempre decimos a nuestros proveedores que si conocen un mejor modo de hacer las cosas estamos dispuestos a hablarlo para ese contrato particular, siempre sin perder de vista nuestros objetivos.
Decía Martín Fowler en uno de sus artículos que es mejor tener algún sistema de IC que no tenerlo. Extrapolando, es mejor plantearse varias metas alcanzables poco a poco que una sola que las aglutine todas pero inviable. Y los tempos en la Administración Pública van ligados a la legislación vigente, y no te puedes saltar la ley...
javierpaniza, no había visto tu post. De hecho cumplimos muchos puntos que se mencionan, pero me parece escaso. De hecho es el punto de vista puramente de un proveedor, pero en nuestro caso la problemática es más compleja: proveedores y clientes, y no se nos aplican directamente todos los puntos. Por ejemplo:
* No gastamos (invertimos) dinero en comprar herramientas, mejor dicho casi no gastamos.
* No podemos entrometernos en qué condiciones los empleados del proveedor desarrollan su trabajo.
Por otro lado tenemos reuniones técnica periódicas con los proveedores (quince o treinta días, en función de la magnitud del proyecto) donde se planifica el trabajo. Y los proveedores tienen reuniones periódicas con nuestros usuarios para planificar la parte funcional.
Como decía, no era el objetivo inicial del post, pero vista la preocupación que mostráis por cómo trabajamos... voy soltando perlas a cuentagotas. :)
Hola Ramón,
Sin duda las métricas son una perversión, porque nos centramos en cumplir esas métricas y no en el principio detrás de la métrica. En este caso el nivel de cobertura no es importante, lo importante es que la aplicación no falle. Si un equipo de trabajo no escribe ni una sola prueba automática y su aplicación no falla nunca y el otro tiene una cobertura del 100% y su aplicación falla sin parar, ¿quién lo está haciendo bien? Lo importante es que la aplicación sea robusta y las pruebas automáticas pueden ser un medio para conseguirlo, no un fin.
Yo también tengo un comparación, pero esta no es mia es un ejemplo clásico que se usa en informática para hablar de los métodos, las métricas, CMM y todas esas cosas. Es el McDonalds. Con un buen manual lleno de normas McDonalds consigue que empleados con poca experiencia y nada de inspiración consiguan producir un producto de calidad predecible. Además eso resuelve el problema de confianza del que hablas, si vas a un sitio que no conoces, hay varios restaurantes y uno es el McDonalds, ya sabes exactamente como va estar la comida, sin riesgos.
Pero si yo fuera cocinero mi sueño no sería trabajar en McDonalds y si me quieres invitar a comer, por favor no me lleves al McDonalds, llevame a un buen restaurante donde el cocinero no tenga manual.
Entonces nunca conseguirás hacer software de calidad, olvidate de las métricas. ¿Has leido el libro PeopleWare? Es un libro muy, muy divertido. Si te dedicas al software tienes que leerlo.
Ramon, el tema de presentarse a una licitación, precisamente por esto te decía que el problema es más profundo y requiere un cambio radical. Es imposible para cualquier pequeña empresa presentarse a una licitación pública por los riesgos que conlleva, se pueden resumir en dos, a) la administración paga cuando le da la gana y b) Los pliegos son contratos donde se fija alcance, tiempo y dinero, con lo que todo el riesgo se carga sobre el proveedor. El resultado de esto es que sólo pueden ser proveedores de la adminstración publicada empresas con el suficiente musculo financiero para soportar estos riesgos con la esperanza de a) llevarse el siguiente proyecto gordo b) ganar pasta en las eternas fases de "mantenimiento" y ampliaciones diversas. Es un modo de trabajar imposible, además de obsceno, para cualquier pequeña empresa.
"No podemos entrometernos en qué condiciones los empleados del proveedor desarrollan su trabajo."
¿Y porque no?. Cuando el resultado de un proyecto depende de esas condiciones, y en trabajos como el nuestro claramente existe esta dependencia, estas condiciones deberían pasar a forma parte de los criterios de selección de proveedores.
javierpaniza:
Si un equipo de trabajo no escribe ni una sola prueba automática y su aplicación no falla nunca y el otro tiene una cobertura del 100% y su aplicación falla sin parar
Yo todavía en mi trabajo no he visto una sóla aplicación que no falle nunca. Tampoco he visto una aplicación con una cobertura del 100% (ni del 90%) con pruebas bien diseñadas, salvo las que hacemos un compañero y yo porque intentamos predicar con el ejemplo. Y ni así estás libre de pecado.
Pero para responder a tu pregunta:
Lo que sí he visto es que a mayor número de pruebas bien escritas y mayor cobertura menor índice de problemas que otra sin pruebas. Pero para responder a tu pregunta yo te plantearía otra:
¿Y qué pasa si, como es el caso de la administración, cambia la funcionalidad cada vez que se publica una ley? ¿Vuelves a iniciar un ciclo de pruebas manuales desde cero?
El 100% de cobertura no garantiza que la aplicación funcione correctamente, ya que 100% de cobertura != 100% funcionalidad cubierta. Pero esto último no invalida las pruebas como una herramienta más. Vuelvo a decir por enésima vez que la exigencia de las métricas no es lo único que hacemos, es sólo la parte automática. Por supuesto que probamos las aplicaciones, intentamos buscar casuísticas de fallo, las sometemos a baterías de pruebas con usuarios (por hablar del tema de pruebas).
Y respecto a la confianza vuelvo a repetirme: en la administración no podemos trabajar con relaciones de confianza, en primer lugar porque no es nuestro dinero, sino el de los contribuyentes, y segundo porque soy un cliente que paga por un producto a medida, nadie me está haciendo un favor.
Leo demasiadas cosas que no me corresponden para intentar estar al día, ese libro no lo he leído, pero desde luego que tomo nota para recomendárselo a las empresas, ya que son ellas las que deben proporcionar el software libre de defectos, no yo.
alfredocasado:
Lo que comentas es, a mi modo de ver, uno de los grandes males de la administración, en eso estoy de acuerdo contigo. Pero una cosa son las exigencias técnicas y otras las legales. Que se exijan ciertas garantías legales imposibles de cumplir para pequeñas empresas impide el acceso en igualdad de condiciones a pequeñas empresas, pero ese tema es algo que llevan los asesores legales, la ley está para cumplirla mientras no se cambie, y la ley la redactan y deshacen los políticos y establece ciertos requisitos obligatorios en los contratos. A mí me queda, dentro de mis funciones, obedecer y respetar esa ley, esté o no de acuerdo con ella. Como persona individual es otro cantar, pero para poder cambiar una situación como la que describes habría que tener una capacidad de movilización tremendamente elevada, y sólo hay que mirar a nuestro alrededor para ver que apenas nos movemos en este país ante la situación que vivimos.
Por otra parte, el tema del alcance es cierto que se suele fijar desde la administración, así como un tiempo máximo y un presupuesto máximo. El alcance es normal, defines cuál es la problemática a resolver. Y no se puede dar manga ancha en el tiempo y el presupuesto. Durante la ejecución del proyecto el contratista puede discrepar de si el tiempo y presupuestos se corresponden con el alcance, y solicitar la anulación del contrato o una modificación de las condiciones.
Aún así te podría contar absurdos de las ofertas en todos los sentidos imaginables; la realidad, como se suele decir, supera cualquier ficción. Te lo resumo diciendo que, por lo general, las empresas se torpedean a sí mismas por querer ganar un concurso, ya que sus ofertas sientan precedente para las estimaciones monetarias y temporales futuras, y si disminuyen en las ofertas dichas estimaciones éstas pueden emplearse para nuevas convocatorias de concursos similares (evidentemente hay muchos factores, como el éxito en el contrato, las ofertas medias, etc.), y a esto no los contratistas no suelen prestar mucha atención.
Con la intromisión yo me refería a que no podemos entrometernos hasta cualquier nivel de detalle, porque no tenemos una relación laboral con el equipo técnico del contratista, sólo una relación contractual con el contratista, es el contratista el que la tiene laboral con sus trabajadores; en todo caso, debería ser un trabajador el que debería denunciar a su empleador, para que la administración, al menos, iniciase una investigación. A lo más que podemos llegar como técnicos es a emitir una valoración (evidentemente subjetiva) sobre si la cualificación técnica del equipo de trabajo se corresponden con la ofertada por el contratista, y eso requiere defender esa opinión ante demasiada gente, y a solicitar en los pliegos unas determinadas condiciones de trabajo, equipamiento, características (si es necesario) del local donde desarrollar la ejecución del contrato (algo que se suele realizar explícitamente)... Pero tampoco podemos estar en las oficinas del contratista día tras día 8 horas al día para comprobar que efectivamente el trabajo se desarrolla en las instalaciones, condiciones y equipamiento que ha declarado en los pliegos.
Pero cualquier injerencia en la organización del equipo de trabajo del contratista puede llegar a considerarse cesión ilegal de trabajadores, algo que era frecuente hace unos años y que la administración intenta evitar por todos los medios. De ahí que se prohibiera, al menos en mi CCAA, que los contratistas desarrollen los contratos en dependencias de la administración.
Hola Ramón,
Pues sí. La empresa en que trabajo hace software para la administración pública y parte de ese software está escrito en RPG, incluido el SICAL. Los programadores RPG no están acostumbrados a las pruebas automáticas, así que tienen que probarlo a mano. Las aplicaciones están muy rodadas y los clientes están encantados. El truco está en programadores expertos en el dominio, cercanía con el cliente y un soporte rápido.
Yo no estoy en contra de las prueba automáticas solo quería ilustrar que hay que distinguir entre medios y objetivos, y las prueba automáticas son un medio, no un objetivo. Era solo un ejemplo.
Yo personalmente programo en Java y hago pruebas automáticas de todo, normalmente antes de escribir el código. No permito que añada funcionalidad a OpenXava sin sus correspondientes pruebas automáticas. De hecho, en mi libro tengo un capítulo entero dedicado a las pruebas y a partir de ahí todo el código que se escribe tienes sus correspondientes pruebas automáticas.
No, lo que ocurre es ese trabajado cambia de empresa. Los buenos programadores gravitan hacía las empresas con mejores condiciones.
javierpaniza
Hola, otra vez. Vaya, hacía más de veinte años que nadie me hablaba de RPG, es más, lo tengo olvidado por completo. Pero en RPG estarán los informes, ¿no es el Report Program Generator o algo así?
En nuestro caso es todo Java. Y para los informes tenemos un servidor JasperServer Reports, al que se le pasan los datos ya calculados que se emplearán en el JasperServer para generar el informe, así que pueden ser automáticas.
Yo también programo en Java, y todo lo que hago lleva sus correspondientes pruebas y cumplimiento de las mismas reglas que exijo a proveedores.
Pero para mí las pruebas son uno de los objetivos de la entrega. ¿Por qué? Porque la mayoría de mis proveedores, a diferencia de tu empresa, no escriben pruebas ni como medio ni como objetivo, simplemente no entran en ninguna de sus planificaciones, y nos entregan las aplicaciones con muy poco rigor en las pruebas realizadas (esto son las conclusiones a las que llegamos a la vista de la experiencia del trabajo con ellos). Así que en lugar de ser algo optativo para los proveedores lo hemos convertido en obligatorio, como obligatorio es que sean verdaderas las pruebas.
Es posible que esté equivocado en el enfoque si se parte de la suposición de que los proveedores lo hacen todo estupendamente y de la mejor manera posible, pero la realidad demuestra que no es así. Hay proveedores con más habilidad que otros, y hasta esto cometen errores en el análisis, el diseño o la codificación. Y yo también. La diferencia entre los proveedores, como comentaba, es que las entregas de quien desarrolla pruebas (pruebas correctamente diseñadas) son menos propensas a errores.
Los buenos programadores pueden gravitar hacia empresas con mejores condiciones incluso si están en la periferia del país, como es mi caso, pero no todos los programadores de una empresa (centrándonos en este perfil) son buenos programadores, por desgracia. Y algunos no lo son porque no se les ha dado tiempo para serlo (recién licenciados, o reciclados de una a otra tecnología). Pero el hecho es que nosotros pagamos por buenos programadores, y exigimos que los contratistas cumplan en base a ese pago.
Y dentro de un par de años puede que cambie el chip y considere que las pruebas que me tienen que entregar los proveedores pasen a ser un medio. Pero de momento mis proveedores saben que en la situación actual es uno de sus objetivos.
Por poner de manifiesto que esto no tiene que ver con "es que en españa somos muy malos", sino que pasa en todas partes, la galleta que se han pegado en los EEUU con healthcare.gov, escribía un post robert martin justo sobre esto:
http://blog.8thlight.com/uncle-bob/2013/11/12/Healthcare-gov.html
En el mismo país donde están google o microsoft, por poner un par de ejemplos cualquiera, haciendo software enormemente complejo y de calidad más que aceptable (si microsoft también, si comparamos cualquier producto de esta compañia con la calidad media del software que nos contaba ramon).
A mi me parece bastante claro que no es un problema de que no sepamos hacer software, si que sabemos, hay muchas empresas que hacen producto y lo hacen muy bien, basta con ir a ver como lo hacen. Sin embargo con los proyectos a medida esto es un desastre aquí en EEUU y en cualquier parte, quizás esas cosas "que no se pueden cambiar" con las relaciones viciadas desde contrato entre proveedor y cliente son precisamente el problema.
Los que me conocen un poco saben de que pie cojeo, y mi inclinación por el desarrollo ágil y sobre todo por el software craftmanship, respecto a esto me quedo con lo que dicen los manifiestos agil:
y ampliado en el de SC:
En mi opinión la adminstración no necesita proveedores que hagan "x proyecto" necesita partners tecnológicos que sean capaces de acompañar a la adminstración y dotarla del software que necesita (o crear su propio software, que es otra posibilidad). El software de cualquier organización compleja, y la admistración es de las más complejas, no es un conjunto de proyectos cerrados, es más bien algo que esta en constante evolución y que se tiene que ir adaptando de manera constante, es algo vivo, como decían en el libro "the phoenix project" (muy entretenido, os lo recomiendo mucho) el software es el sistema nervioso de la organización y todas las decisiones de negocio que tome esa organización tienen impacto en ese sistema nerviosos. Mientras la administración siga pensando en el software como quien compara material de oficina, otro proveedor más, esto va a seguir siendo un desastre, con métricas o sin métricas.
Perdonar por haber desviado tanto la conversación inicial, pero es un tema que me parece de importancia vital.
alfredocasado:
Yo no he dicho que en España seamos malos programadores, no fueron esas mis palabras, lo que digo es que no todos son buenos programadores, que no es lo mismo. Y a mí me interesa lo que me entregan mis proveedores, no aquellos que no lo son, puesto que debo responder (por ejemplo, ante la preocupación que mostrabas en un post anterior) por el cumplimiento del mismo.
Y por otro lado yo también abogo por el desarrollo ágil, y por metodologías por TDD, y si tu empresa posee alguna certificación CMMI también me parece muy bien, pero que yo desarrolle con metodología ágil, con TDD o que posea CMMI, o que lo gestiones con tal o cual enfoque no garantiza nada, ni el éxito ni su contrario, el fracaso.
Y siento tener que repetirme, pero en la administración hay contratos con proveedores, así que la colaboración está supeditada a lo que especifica el contrato y a la legislación vigente -por ejemplo, la ley de contratos del Sector Público-; a los proveedores les gusta hacer valer los términos de ese contrato cuando les conviene, pero no les gusta cuando nos conviene a la administración. Y eso tampoco significa que no colaboremos, quizá no has tenido suerte en tus relaciones con la administración, pero donde yo trabajo en los proyectos se pone gente técnica y gente que conoce el negocio para que el proyecto se lleve a buen puerto, no se contrata sin más para que el proveedor se busque la vida.
Quizá este tipo de intercambio de opiniones deberíamos hacerlo en un thread del foro creado expresamente para ello. Creo que tanto unos como otros (entre los que me incluyo) tenemos mucho que decir al respecto, pero no era éste el objetivo del post.