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.