¿El cliente prefiere que desarrolles con calidad o rapidez?

Sencillez

Generalmente son dos parámetros que se contradicen, si hago un producto más rápidamente lo hago con menos calidad y si lo hago con calidad requiere mayor tiempo de desarrollo.

Existe el factor coste, invierto más dinero y lo consigo con más calidad y menos tiempo. Pero en el mundo real con más dinero tendrás más gente, más gente es más tiempo, más gestión y posiblemente menos calidad.

Si le preguntamos al cliente te dira que lo quiere rápido, pero asume que tiene calidad, si no funciona bien, ¿para que le vale?

Una posible solución a este dilema es menos.

  • Si entregas algo con menos funcionalidades, lo podrás hacer en menos tiempo y con más calidad
  • Si tienes menos funcionalidades las podrás probar mejor
  • Si tienes menos funcionalidades tendrás menos errores
  • Si tienes menos funcionalidades tendrás menos código que mantener

Pero aunque la idea parece fácil, es extremadamente complicado saber cuales son las mínimas funcionalidades que conseguirán satisfacer las necesidades de tu cliente.

Menos, es más cálidad y más rapidez!

La calidad del software es responsabilidad de toda la empresa

Normalmente pensamos que la calidad de un software es responsabilidad exclusiva del departamento de desarrollo, ellos son los responsables de programar y de hacer un producto de calidad.

Pero en realidad el resto de departamentos son complices de la calidad del producto:

  • Si el departamento de soporte presiona para cambios rápidos y sin probar, no esta ayudando a la calidad.
  • Si la dirección estratégica de la empresa va en el camino de más y más funcionalidades, no esta ayudando a la calidad.
  • Si los comerciales piden incorporar en tiempo record las nuevas funcionalidades que tiene la competencia, no esta ayudando a la calidad.
  • Si el departamento de diseño exige que se incorporen imagen y videos super atractivos sin importar los recursos, no esta ayudando a la calidad.

¿Quien lucha por dedicar tiempo a la calidad de las apps?

Todo el equipo tiene que ser consciente que existen muchos trabajos relacionados con la programación que nos ayudan a tener un producto de calidad.

  • Mejorar la usabilidad
  • Refactorizar código
  • Quitar código obsoleto
  • Actualizar librerías
  • Mejorar la velocidad de los procesos
  • Realizar pruebas de carga
  • Automatizar procesos de prueba

Estos trabajos consumen mucho tiempo y toda la empresa debe darse cuenta que son necesarios para que el producto mejore día a día.

La calidad de un producto debería nacer desde la estrategia de la empresa e ir descendiendo por los departamentos hasta su aplicación directa en los departamentos más técnicos. No es un trabajo aislado de unos locos de la programación.

El coste de un bug

bicho-bugCuando se desarrolla software se comenten errores (bugs), esto forma parte del trabajo. Cada uno de estos errores tiene un coste, normalmente cuando más tarde se detecta, más caro nos cuesta solucionarlo.

Estos son algunos de los momentos en los que la empresa puede detectar y solucionar estos errores :

  1. En el propio desarrollador
    Un buen desarrollador con años de experiencia comete menos errores, el código que realiza se protege de los bugs. Estos programadores cobran más, pero su código es más fiable.
  2. En la integración continua
    Dentro de la integración continua se pueden usar diferentes sistemas para detectar bugs ( Pruebas unitarias, pruebas funcionales, análisis estáticos de código, etc )
    Dentro de la integración continua es muy útil tener automatizadas todas estas pruebas automáticas que detectan fallos de desarrollo y nos da garantías de que los cambios subidos no rompen nada.
    Coste*: 1 hora del desarrollador ver el log y arreglar el problema 
  3. En el equipo de desarrollo
    Ya sea por revisión por pares o por programación por parejas, se pueden detectar los bugs antes de que el código salga del departamento de desarrollo.
    Coste*: 2 h. del desarrollador que encuentra el problema y de quien lo soluciona 
  4. En el departamento de pruebas
    Si el error llega hasta el departamento de pruebas, este equipo tiene que ocuparse de detectarlo y entender como ocurre y como hacerlo reproducible. Otro elemento importante es describirlo al desarrollador que suele ser un punto de conflicto,  la comunicación debe ser muy eficaz para que el desarrollador pueda entenderlo y solucionarlo.
    Coste*:  1h. para encontrarlo y documentarlo + 1 h. en entenderlo + 1 h. para solucionarlo 
  5. Los betatesters
    Si el bug no se ha encontrado dentro de los equipos de desarrollo y pruebas, el producto con el error llega al betatester que si lo encuentra, deberá comunicarlo al departamento de pruebas, la solución a este bug debe pasar por varios departamentos e incurre en trabajo de mucha gente.
    Por otro lado, la solución al error, puede romper otro elemento, con lo que esa versión debe pasar de nuevo todas las fases previas.
    Coste*: 1h. del betatester + 1 h. para encontrarlo y documentarlo + 1 hora en entenderlo + 1 hora en solucionarlo 
  6. El usuario final
    Si el bug llega al usuario se sentirá frustrado porque la nueva versión no hace lo que debe. Del mismo modo quizá no informe correctamente al equipo. Si lo hace, debemos tener un canal por el equipo de soporte para ello. Este tipo de bugs generan mucho trabajo y mala imagen, incluso en ocasiones pueden generar un parche, con el enorme coste que esto provoca.
    Coste*: 1 h. del cliente final + 1 h. persona de soporte + 1 hora persona de pruebas + 1 h. para entenderlo + 1 h. solucionarlo 

Sacar un parche para muchos clientes no tiene precio 😉

*Coste: Es un tiempo medio, cada error es un mundo, unos se solucionan en minutos y otros en días.

Lo que el cliente no pide, pero exige

En desarrollo de software es habitual que los usuarios pidan más y más funcionalidades, si fuera por ellos una aplicación crecería en «sus» funcionalidades hasta el infinito.

Pero por otro lado el cliente asume que la aplicación será rápida, estable y segura, pero eso no se suele pedir, se asume que es así.

Muchos de los trabajos relacionados con la calidad de tu software, son trabajos ocultos para el usuario, pero que son igual o más importantes que añadir más funcionalidad.

Es labor de todo el equipo dedicarle tiempo a la calidad del producto, ya que llegado un momento nuestra deuda técnica es tan grande que empezamos a sufrir distintos problemas relacionados con la falta de calidad.

Todos estos trabajos relacionados con añadir más calidad a nuestro producto deben ir incluidos en cada una de nuestras iteraciones, no debe ser un trabajo puntual cuando las cosas vayan mal.

Jenkins como herramienta de integración continua y mucho más

Desde hace bastante tiempo venimos usando Jenkins como herramienta de integración continua.

Aunque esta orientada a desarrolladores de Java, gracias a su inmensa cantidad de plugins, puede servirte para cualquier lenguaje de programación o plataforma ( Nosotros lo usamos con C++ y Velneo )

La idea general de la integración continua es que tu producto este permanentemente pasando todos los pasos necesarios para su liberación.

Tu herramienta de integración continua es la encargada de dirigir todos los pasos intermedios desde que un desarrollador toca algo de código hasta que el instalable está disponible para descarga. Entre las tareas que debe hacer :

  • Conexión con el control de cambios (Perforce, GIT, etc )
  • Realizar los test de que todo el proyecto es coherente
  • Realizar los test necesarios de que tu proyecto no tiene errores
  • Realizar la compilación/compactación de todos los componentes
  • Probar que las diferentes partes de tu proyecto son compatibles
  • Tests para comprobar la calidad de tu proyecto (Tamaño imágenes, calidad de código, código duplicado, errores ortográficos, etc.)
  • Creación de instalables
  • Pruebas del instalable
  • Pruebas multiplataforma
  • Subida de los instalable a su repositorio final

Jenkins te permite crear trabajos (jobs) donde se detallan todas estas operaciones mediante scritps en el lenguaje que prefieras (Python, Batch, Bash, etc.)

Otras ventajas de Jenkins:

  • Multiplataforma
  • Configuración Maestro/Esclavo (Para integraciones distribuidas)
  • Cientos de plugins
  • Fácil instalación y mantenimiento
  • Multitud de idiomas ( Español incluido )

Si usas Jenkins en tu proyecto tendrás resueltos 2 de los 12 pasos hacia un código mejor de Joel Spolsky