Calidad de software desde las trincheras

“Scrum and XP from the Trenches” es un pequeño libro sobre metodologías ágiles, escrito por Henrik Kniberg, y que pretende ejemplificar su aplicación práctica en una pequeña empresa desarrolladora de software, su empresa. Más que un libro, se trata de un “manual de instrucciones”, de cómo llevar al mundo real aquello que tan perfecto sonaba del mundo ágil. Kniberg, representa para mí  y para otros responsables de proyectos, un icono en el que nos vemos reflejados, por lo similar que su día a día se parece al nuestro. El libro vió la luz en 2007, en formato de descarga libre, y hoy día sigue siendo tan vigente como entonces.
He querido tomar el título de esta entrada de aquel libro, porque quisiera desde mi experiencia y desde un punto de vista totalmente práctico ofrecer algunas ideas de lo que una empresa desarrolladora debería cuidar para fabricar software de calidad.
Desarrollar software  es fácil. ¿ No vivimos acaso el “boom” de las Apps ?  Hoy en día, todo el mundo desarrolla Apps para dispositivos móviles. Y hace nada eran páginas webs.
Pero desarrollar software de calidad no es fácil. Dentro de la complejidad que entraña la ingeniería del software, nuestro compromiso profesional es entregar un producto al mundo lo más testado posible. Y eso no significa sólo el que el programador pruebe lo que ha hecho muy bien, o que al final de la cadena haya un departamento de testeo verificando lo que el programador ha hecho. Va mucho más allá, y aquí van algunas de mis “lecciones aprendidas”:

1. Tener un proceso perfectamente definido, engrasado y conocido por todas las partes.  La información debe fluir desde el cliente, que nos demanda algo hasta que éste “algo” de nuevo vuelve a él, en forma de producto terminado. El cliente y nuestra organización debe trabajar en perfecta combinación.
2. Comunicación. Entre Desarrollo y todos los interesados (“stakeholder”): departamentos de consultoría, soporte y cliente final. Totalmente relacionado con el punto anterior.
3. Planificar en detalle sólo a corto plazo, y descomponer los trabajos en pequeñas tareas. No sirve de nada intentar planificar hasta el último detalle de un desarrollo importante a medio o largo plazo, porque cuando llegue el momento de realizarlo seguro que han cambiado las condiciones iniciales. El desarrollo de software necesita la retroalimentación constante de todas las partes implicadas. Es la comunicación comentada anteriormente.
4. Formación. Los que lideramos equipos debemos ofrecer facilidades de formación a cada uno de los miembros, y éstos deben tener la actitud necesaria para proponer y dedicarse a dicha formación. Los que estamos en el mundo IT debemos ser conscientes que la formación es inversión.
5. Son necesarias las revisiones externas. No sólo de personal de la propia organización, sino que es muy aconsejable contar con “Beta Testers” externos, aunque sea necesario ofrecerle contraprestaciones por la ayuda.
6. Documentar, sin excederse, pero documentar todo lo necesario. Cada eslabón de la cadena lo debe hacer. El analista, el programador, el testeador, y la persona que elabora la ayuda que llegará al cliente.
7. Medir. ¿ Cómo saber si lo estamos haciendo bien ? Si queremos progresar, debemos medir. Horas dedicadas, bugs detectados, reclamaciones, … Se trata de medir para mejorar, y no de medir para fiscalizar el trabajo de nadie. Si lo hacemos con esta última intención fracasaremos.
8. Cada programador es responsable de su trabajo. Lo que más debemos valorar de un programador es su capacidad de pensar, de razonar sobre el problema propuesto y ofrecer la mejor solución. Y a partir de aquí, de entregar software que funcione de la forma esperada.
9. No desarrollar funcionalidades extras con el pretexto de “por si acaso…”. Introduce complejidad, errores, y posiblemente el desarrollo de cosas que nadie utilizará.  Y si lo hacemos, por favor, que sea en base a un sistema de gestión de sugerencias de clientes, en el que tengamos recogidas peticiones realizadas por éstos y podamos aprovechar para el desarrollo de las más solicitadas.
10. Las prisas y la presión en las entregas no son buenas aliadas de la calidad. Reconozcamos que son inevitables, pero intentemos establecer los plazos adecuados.

Aumentar las horas de trabajo más allá de lo razonable por intentar acabar el trabajo antes, o introducir más programadores cuando el trabajo ya está cociéndose en el horno, desemboca en trabajos mal acabados y con grandes probabilidades de errores.
Como se puede comprobar, excepto el primer punto, que habla de “proceso”, todos los demás tratan acerca de las personas y es que ellas son el activo más importante de una empresa de desarrollo que quiera realizar software de calidad. De su cuidado, de las llamadas “habilidades blandas” que el líder del equipo sepa desplegar, y de la implicación de toda la organización va a depender gran parte del éxito de esta empresa.
enlace: Scrum and XP from the Trenches

Antonio de Rojas

Director de Desarrollo y Diseño I+D en Clavei. Posee certificación como Project Management Professional

www.clavei.es