archivo

Archivos Mensuales: junio 2013

Principio 6: La calidad solo la producen profesionales motivados orgullosos de su trabajo.

Asunto controvertido, pero real. Y no solo afecta a la calidad, sino a otros muchos factores en los proyectos de desarrollo de software como la productividad, la confianza, etc…

El respeto por nuestra profesión y por nosotros mismos es algo que sale de dentro de cada uno. Después hay factores que modulan su intensidad en cada momento, si bien, tienen un límite inferior que hace que determinadas personas independientemente de las circunstancias sean capaces de rendir por encima de las mismas (lo cual no quiere decir que siempre sea suficiente como para superar todos los problemas que se puedan encontrar).

Los desarrolladores que no respetan nuestra profesión, no lo harán ni en los buenos ni en los malos momentos y la calidad media de sus trabajos, sumando éxitos y fracasos, será deficiente.

Pero incluso esas personas que están motivadas de serie para tratar de hacer el mejor trabajo posible, sufren mucho y ven mermado considerablemente su potencial y rendimiento cuando muchas organizaciones (o determinados responsables dentro de las mismas), en lugar de tratar de sacar lo mejor de esas fortalezas se empeñan en debilitarlas, convirtiendo lo económico u otros intereses en la única prioridad de los proyectos y haciendo que el trabajo bien hecho (y conseguir un producto de calidad es uno de los factores para considerarlo así) queda en un muy segundo plano.

De esta manera nos encontramos proyectos mal vendidos, condenados desde un principio al fracaso (Death March Project), en los que desde un primer momento se trata de recortar alcance y calidad, para tratar de sacar algo de él.

O proyectos que tal vez sí estaban bien dotados económicamente pero que se ha gestionado negligentemente o que son vistos como una oportunidad para cumplir con determinadas aspiraciones o ambiciones personales, motivo por el cual se trata de conseguir unos beneficios por encima de los que realmente se podrían conseguir.

En ambas situaciones, no solo sufre el producto, no solo sufre el proyecto, no solo sufre el cliente (que también tiene su parte de culpa en todo eso, cuando trata de conseguir precios absolutamente fuera de mercado, aún a sabiendas de lo que eso trae consigo), sino que sufren y mucho los desarrolladores que se encuentran en medio de las líneas de presión que ejercen sus jefes y los clientes, que generalmente deben echar muchas más horas de las que le corresponden, que muy pocas veces son valorados como se merecen y que se ven obligados a desarrollar con unos niveles de calidad con los que no están en absoluto de acuerdo.

El factor clave de los proyectos de desarrollo de software son las personas. Si no están motivadas, si no creen en su trabajo, pocas posibilidades tendremos de conseguir unos resultados acordes a las expectativas que se tenían puestas.

Se cree que pagando un salario se asegura todo esto, eso tal vez funcionase hace muchos años, hoy día, las personas necesitan otro tipo de incentivos, como por ejemplo, sentir que su trabajo ha servido para mejorar algo.

Por último, es importante señalar que no solo se trata de motivación y de respeto a tu profesión, se trata también de cualificación.

La voluntad y la actitud son importantes, permiten llegar lejos, pero la experiencia (real) y la aptitud, sumadas a lo anterior, son las que permiten marcar la diferencia.

Principio 5: Ya que las pruebas solucionan solo una fracción de los defectos, debes tener pruebas de calidad.

El día que los desarrolladores asimilemos esto, las cosas empezarán a cambiar.

Tenemos un mal endémico, no probamos. Esto es así y cuando lo hacemos nuestros resultados no suelen ser buenos ya que no le prestamos a esta actividad la importancia que merece.

Para muchos desarrolladores, lo que importa es parar el reloj y dar por completada la tarea. Esto es como si un jugador de ajedrez realizara un movimiento sin haber estudiado bien la situación, es probable que la partida la lleve bien de tiempo, pero probablemente la tenga muy mal en el tablero.

Después, cuando empiezan a aparecer errores, vienen las prisas por corregirlos, las cuales traerán nuevos errores, además de los que no se han terminado de arreglar, entrando en un ciclo que hace mucho daño al proyecto y al producto, porque no solo afecta a la velocidad de desarrollo o la confianza de los usuarios en nuestro trabajo, sino que económicamente puede tener efectos devastadores para el que desarrolla, al tener que rehacer una y otra vez diversas porciones del código y para el cliente, con un sistema en producción que no puede ser utilizado de manera adecuada y/o que no se adapta a las necesidades y expectativas puestas en él.

El testing se puede hacer de muchas maneras y a diferentes escalas, intercalando procesos automáticos y manuales, interviniendo desarrolladores, usuarios y personal independiente, de manera continua durante el desarrollo y como última barrera de defensa antes de la entrega.

Y no solo se trata de testing, es necesario gestionar las expectivas de manera continua.

El esfuerzo que sería necesario dedicar al testing es potencialmente ilimitado. En ese momento entra en juego las características del sistema que estamos desarrollando y el presupuesto disponible. Se trata de ser eficiente, productivo, de aprovechar de la mejor manera posible nuestro esfuerzo. Probar por probar no sirve de nada, se tiene que hacer con intención y sabiendo muy bien lo que se hace.

Principio 4: La calidad de un producto la determina el proceso usado para desarrollarlo.

Cuando se pretende conseguir la calidad de un producto a través del proceso se cae en el error de poner el procedimiento por encima de las personas y aunque no se pretenda eso en un principio, finalmente, en la mayoría de los casos, suele terminar así.

Por eso, aunque pueda entender la intención de Humphrey: “si haces las cosas con cabeza es más probable que el producto final sea de mayor calidad”, el uso de la palabra proceso no me termina de gustar, por lo comentado en el párrafo anterior, es decir, que se empiece a pensar que la solución está en un conjunto de normas generales, independientemente de que las mismas sean adecuadas o no a las características particulares de cada proyecto (y de la evolución que siguen los mismos).

Eso no quita que no se pueda ser metódico y aplicar procesos ligeros (que deben existir dentro de cualquier organización), con determinadas normativas generales (libros blancos de desarrollo, sistemas, etc…) con un enfoque y prácticas que puedan resultar de interés para el proyecto, conviviendo con otros procesos organizativos (realizados por los equipos de desarrollo u otros) que por ejemplo midan el número de defectos de las entregas, las entregas fallidas, el incumplimiento de compromisos, etc… o que impongan unos determinados umbrales de calidad.

Todo ello sin olvidar que estamos al servicio del producto y de las expectativas que se tengan sobre él dentro del contexto en que se realiza el proyecto, a partir de ahí, cualquier estrategia válida que se vaya adaptando en función de las necesidades (no por capricho), con una intención no solo de cumplir las expectativas, sino de tener en cuenta, también, otros aspectos relacionados con la calidad que no están en el primer plano de muchos usuarios (como la mantenibilidad, la robustez, la seguridad, etc…), puede ser aceptable.

Principio 3: Para gestionar la calidad los desarrolladores deben medirla.

Ya lo dice también Peter Ducker: “Lo que se puede medir se puede mejorar” o lo que es lo mismo “lo que no se puede medir (o no se mide) no se puede mejorar”.

Si no mides (y no solo vale con eso, también hay que revisar, contrastar y analizar) no puedes saber si el trabajo está siendo efectivo y si realmente se está produciendo una mejora de la calidad del producto y si estamos, además, cumpliendo con las condiciones específicas que está imponiendo el cliente.

Con las métricas obtenidas tenemos la capacidad de poder realizar acciones correctivas y mejorar nuestros propios procedimientos y prácticas.

Obtener valores numéricos es muy útil para medir aspectos relacionados con el análisis estático de código (acoplamiento, cohesión, en general, deuda técnica y buenas prácticas de programación) y otros que tienen que ver con el número de defectos del producto o entregas que resultan fallidas.

Sin embargo deben complementarse con métricas cualitativas (que si se quiere también se pueden cuantificar) como, por ejemplo, el nivel de satisfacción que están teniendo los usuarios con el trabajo realizado y el producto resultante.

Pero además, y esto lo añado yo, quien propone las métricas y los hitos de calidad, en este caso, el cliente, también debe medir si la aplicación de las mismas realmente proporciona una mejora para la organización, porque lo mismo las normas que se están solicitando y aplicando no son buenas y/o no se adaptan a la realidad de los proyectos y presupuestaria.

Esto es importante porque la calidad tiene un coste tanto relacionado con el desarrollo (imputable a cada proveedor y que afecta a las cuentas de cada proyecto) como con el control que realiza el cliente. Hay que tener en cuenta que unos objetivos de calidad equivocados pueden tener un doble efecto negativo: no se mejora la calidad en muchos aspectos que son realmente importantes (porque se enfoca la atención a otros hitos) y además se genera un sobrecoste que podría ser aprovechado para conseguir unas aplicaciones que estén mejor rematadas.

Principio 2: Para obtener calidad de manera constante los desarrolladores deben gestionarla en su trabajo.

Debe formar, por tanto, parte del propio proceso de desarrollo y no ser considerada como una actividad que se realiza en momentos puntuales del mismo, independientemente de que ambos enfoques puedan ser complementarios e incluso recomendables.

Cuanto más próxima a su origen sea la detección y corrección de un problema menos coste supondrá. Más adelante, con más funcionalidades, con más código, con más deuda técnica todo se complica. Es cierto que el aumento de la complejidad no afecta a todo el código por igual, porque hay componentes más críticos que otros, pero en general sí que se puede afirmar que con el tiempo y la distancia los errores son más complejos de corregir.

Y no solo se trata de defectos, sino de decisiones sobre la arquitectura, modelo de datos o a nivel funcional que después orientan el desarrollo de una determinada forma, haciéndolo todo más difícil: desde el mantenimiento hasta la usabilidad y que pueden suponer, si se tarda demasiado tiempo en darle una solución, tener que tirar buena parte de la aplicación a la basura.

Si los desarrolladores no aplican buenas prácticas, que no solo están relacionadas con la programación o con la arquitectura, incluyendo la refactorizacion, sino también con el testing y con la verificación de las especificaciones funcionales independientemente de su naturaleza (requisitos, historias de usuario, etc…), no es posible alcanzar esos objetivos de calidad.

Y no es cuestión de que estén mejor o peor formados en este aspecto, que también influye, sino que el problema principal se encuentra en que no están comprometidos con este objetivo ya que su preocupación se centra en terminar las tareas que tienen asignadas, sin tener en cuenta que terminar no es que te compile la clase o que incluso te arranque la aplicación, sino que funcione y que sea mantenible (dentro de las posibilidades que se hayan tenido).

Los jefes y/o el cliente tienen mucha culpa de esto, cuando presionan a los desarrolladores con un alcance y unos plazos prácticamente imposibles y no solo en momentos puntuales sino de manera sostenida en el tiempo. Sin embargo, no es siempre la causa última que provoca ese comportamiento porque todos hemos podido comprobar que se siguen repitiendo determinadas malas prácticas en proyectos en los no que existen esas condiciones.

¿Por que es tan barato el desarrollo de software?, ¿pensáis que solo es la crisis?. En el momento en que el precio/hora se ha considerado como un elemento clave diferenciador a la hora de contratar un proyecto de desarrollo de software, se ha constatado el fracaso de un modelo en el cual muchas organizaciones dedicadas a este negocio tenían en un primerísimo plano los beneficios y en un segundísimo plano todo lo demás.

Claro que son legítimos los beneficios, como también lo son producir unos resultados acordes a la inversión realizada por el cliente.

Hay casos y casos, es decir, habrá situaciones en las que realmente se buscaba el beneficio por encima de los demás y otras en las que realmente lo que fallaba era la inexistencia de unos umbrales propios de calidad dentro de la organización, lo que se podría considerar como una extensión a nivel organizativo de este principio, es decir, si la organización no demanda calidad, probablemente los desarrolladores no la entiendan como necesario.

Afortunadamente, cada vez hay más personas que ven más clara la compatibilidad entre beneficios y trabajo bien hecho, porque aunque parezca mentira, las personas quieren que su trabajo sirva para algo, que tenga una finalidad. Se puede ganar mucho dinero, pero lo que realmente llena es ver cómo tu trabajo sirve para mejorar las cosas.

También los clientes están cada vez más concienciados en exigir a los proveedores unos determinados niveles de calidad, esto hará que paulatinamente el elemento clave a la hora de contratar sea el nivel de confianza que se consiga transmitir en la propuesta realizada por el proveedor.

La conjunción de ambos movimientos, va a llevar tarde o temprano, a una mejora en el nivel de satisfacción de los clientes y a una racionalización de los precios en el sector porque como decía antes, no se pueden demandar niveles de calidad que no estén acordes con los medios empleados en el proyecto.

Principio 1: Si el cliente no demanda calidad, probablemente no la conseguirá.

Es decir, si el cliente no la demanda, se deja todo en manos de la voluntad del desarrollador, que lo mismo, tiene, pero se encuentran atados de pies y manos ante la presión de sus jefes de tratar de sacar el máximo beneficio posible al proyecto.

Estoy totalmente de acuerdo en que el cliente debe ser responsable de exigir un determinado nivel de calidad y para ello debe proporcionar al desarrollador los medios necesarios para alcanzar ese umbral, es decir, debe existir una proporcionalidad entre lo que se demanda y el presupuesto, plazos y alcance definidos. Teniendo en cuenta que todos esos factores son ajustables, atendiendo a las demandas y contexto real del proyecto.

Si el cliente pone los medios adecuados, el desarrollador debe adaptarse a los niveles de calidad exigidos. El problema principal que se encuentran es que muchos de ellos no están acostumbrados a estos niveles de exigencia incluso en algunos aspectos primarios como por ejemplo que los desarrollos estén lo suficientemente testeados antes de ser considerados completados.

Los desarrolladores tenemos mucho camino que andar todavía en ese sentido. Hay extraordinarios desarrolladores que todavía no se han dado cuenta de la responsabilidad que tienen con respecto a sus compañeros (un software de calidad es más fácilmente mantenible) y con respecto al cliente, y tienen una visión muy cortoplacista basada en terminar las tareas que tienen asignadas lo antes posible.

A veces eso pasa, porque hay variables que no están lo suficientemente bien ajustadas en el proyecto, como por ejemplo, la capacidad que es capaz de asumir el equipo, que es consecuencia de una mala estimación de las tareas o por la presión de tratar de tener unas tareas terminadas a tiempo. Una cantidad de trabajo mayor que la que se puede asumir, termina poniendo en bandeja un comportamiento como el descrito en el párrafo anterior, si bien, hasta en los terrenos más llanos, en donde no debería haber excusas, también lo encontramos con relativa frecuencia.

Watts Humphrey fue considerado como el padre de la calidad del software por su dedicación a combatir los problemas relacionados con la crisis del software. Hasta tal punto era tal su compromiso (lo consideraba como un compromiso para cambiar el mundo de la ingeniería del software), que en el año 1986 tomó la decisión de unirse al Software Engineering Institute (SEI), instituto federal creado por el Congreso de los Estados Unidos en 1984 para la mejora en el proceso de desarrollo de software, y que dio lugar al modelo SW-CMM, que se puede considerar un precursor de CMMI.

Humphrey llegó al SEI con casi 30 años de experiencia en IBM ocupando puestos de responsabilidad, como por ejemplo los de director de programación y vicepresidente de desarrollo técnico.

En el año 2005 recibió la medalla de honor de tecnología de los Estados Unidos.

La obra de Watts Humphrey es muy amplia. En esta serie de artículos, voy a exponer los que se conocen como sus 6 principios de calidad del software.

Para contextualizar un poco los mismos, Humphrey era un defensor (vino con esa visión desde IBM) de la gestión del software por procesos, con una orientación dirigida a tratar de reaprovechar herramientas, recursos y armonizar el proceso de desarrollo.

Los lectores habituales de mi blog sabréis cuál es mi visión de los procesos: no los rechazo, me parecen interesantes en el sentido de que es necesario establecer unas reglas de juego comunes en los desarrollos de una organización, que sean las mínimas posibles para cumplir ese propósito y permitan adoptar la solución que resulte más apropiada para cada proyecto en el que estemos trabajando.

Desde mi punto de vista los procesos son una herramienta pero no pueden convertirse en una finalidad en tanto en cuanto, no pueden asegurar el éxito en un proyecto.

Me veréis discrepar con su quinto principio, como es lógico, e independientemente de la visión que yo tenga con respecto al desarrollo de software, su opinión debe pesar infinitamente más que la mía.

Existen multitud de variables que pueden echar al traste un proyecto. Una de ellas, tal vez una de las más importantes, es la falta de implicación por parte de la persona designada por el área usuaria para realizar este trabajo.

A veces, no falla la implicación y sí la actitud, cuando el responsable funcional entra en una espiral de ordeno y mando, en la que no se deja aconsejar.

El problema se hace más grande cuando, además de lo anterior, el responsable funcional no asume sus errores de manera que explícita o implícitamente hace que los mismos recaigan sobre el equipo de desarrollo.

Innumerables proyectos han fracasado por estos motivos.

Lo mejor es que desde un principio quede claro cuál es el rol del responsable funcional: definir la línea de desarrollo del producto, estableciendo prioridades y seleccionando las tareas que se hacen en cada momento, es el responsable de coordinar el área usuaria para obtener información adicional en el caso de que sea necesario (que lo será en muchos casos) y es el interfaz de comunicación entre esos usuarios y el equipo de desarrollo (lo cual no quiere decir que los usuarios sean un elemento aislado y que los desarrolladores no puedan comprobar directamente cuáles son sus sensaciones).

Teniendo muy claro que sus decisiones producen un impacto en el proyecto, es decir, si se equivoca a la hora de definir una historia de usuario o si se equivoca en las prioridades, hay repercusiones, en el sentido de que el proyecto tiene un presupuesto limitado y en cada iteración va menguando.

No se trata de que no se pueda equivocar, ya que para eso está el enfoque iterativo incremental y el feedback, sino de que las decisiones que tome las haga con intención, disminuyendo las tentativas orientadas al prueba y error.

Desde un principio hay que definir las reglas del juego y es muy probable, sobre todo para responsables funcionales sin experiencia en la participación en proyectos de desarrollo de software, que haya que ir realizando recordatorios puntuales de las mismas.

Una cosa es que desde un principio queden claras las reglas y otra que el responsable funcional las quiera cumplir. Si pasa de ellas y no se consigue normalizar la situación, no quedará otra que escalar el problema porque de lo contrario el proyecto y el producto serán los principales perjudicados.

Con el objeto de mantener un equilibrio en el proyecto es fundamental gestionar las expectativas, de manera que el responsable funcional no se lleve sorpresas. También, por nuestra parte, es importante que no nos intercambiemos los papeles, es decir, él responsable funcional debe elegir los objetivos de nuestra iteración y él no debe meterse (salvo que requiera alguna aclaración) en el esfuerzo estimado para cada una.

Es muy complicado ambas cosas, que el desarrollador no se meta a product owner y que el product owner no discuta la duración seleccionada para cada tarea, en su afán de tratar de que se asuma la mayor cantidad de trabajo posible, olvidando o ignorando que el cumplimiento de los compromisos se ve muy perjudicado cuando la capacidad del equipo de proyecto está sobresaturada.

Lo primero se resuelve aceptando cuál es el verdadero rol del equipo de desarrollo (una cosa es aconsejar y otra definir la línea de desarrollo) y la segunda con mucho diálogo y con la consolidación de una relación de confianza.

Es más difícil solucionar lo segundo que lo primero, de hecho, será complicado que con relativa frecuencia no se nos pidan explicaciones por tal o cual estimación, aceptemos que esto será así, dando las explicaciones que sean oportunas.

Otra circunstancia que puede darse es que tengamos en la pila de producto historias de usuario suficientes para completar la capacidad de trabajo del sprint, pero que muchas de ellas no se consideren prioritarias o lo sean bastante menos que otras que todavía no se han terminado de definir por completo, pero sobre las que se sabe que durante el período de ejecución del sprint van a terminar de completarse y que va a haber tiempo para abordar algunas de ellas.

No se trata en este caso, no tanto de no poder esperar sino de tratar de conseguir siempre el mayor valor posible del producto con respecto a la cantidad de esfuerzo invertido. Lo fácil sería tomar la decisión de trabajar sobre las historias de usuario que están definidas, incluso en muchos casos será la decisión acertada, pero no podemos cerrarnos a la posibilidad de que en determinadas circunstancias lo aconsejable sea dejar la pila de sprint abierta con una capacidad reservada para la realización de estas tareas.

En este caso, hay que anticiparnos con el objetivo de no desperdiciar capacidad de trabajo, de manera que si finalmente no da tiempo de definir algunas historias de usuario, se opte por trabajar con las que están definidos.

¿Y por qué no se han tenido definidas esas historias de usuario antes? Pues porque no siempre se puede, por mucha voluntad que le ponga el product owner o el equipo de desarrollo. Lo mismo uno y otros han tenido que dedicar su esfuerzo en otros objetivos del proyecto que hasta ahora han sido más prioritarios o el product owner ha tenido que consultar con terceros determinadas decisiones que le trascienden y cuya resolución se mueve en unos tiempos distintos al del proyecto y sus sprints.

Tener la pila abierta de esa manera es poco ortodoxo, lo sé, pero cada proyecto tiene sus propias circunstancias y en base a ello tanto el product owner como nosotros tenemos que tomar decisiones, con fundamento, con intención, evitando la arbitrariedad, siempre pensando en lo que más conviene al proyecto y al producto y con la mente abierta a hacer excepciones puntuales o no tan puntuales sobre la estrategia que venimos aplicando.