En nuestra metodología se facturan por los motivos que expondré luego, pero el principal de cualquier desarrollo de software es que es muy complejo hacer software con 0 bugs y hacerlo es MUY CARO tanto por tiempo como por herramientas. Cuando se empieza a desarrollar una aplicación compleja se tiene que asumir de que en algún momento surgirán bugs. Es inevitable. Un ejemplo es cualquier software desarrollado por compañías que gastan millones al año en dicha partida.
http://tecnologia.elpais.com/tecnologia/2016/02/12/actualidad/1455276316_317187.html
http://www.applesfera.com/respuestas/airplay-en-apple-tv-falla
Esos son algunos ejemplos de que los problemas que pueden tener.
Por qué se produce un BUG y por qué no se había detectado antes?
Un fallo en el software se produce por mil motivos, los principales:
- Se cambia una funcionalidad A y esos cambios afectan a una funcionalidad B.
- Se da una coincidencia única de uso que hace que el desarrollo falle.
- El software se empieza ejecutarse en condiciones que no son las iniciales (cambio de configuración del servidor, cambios en navegadores, cambios en sistemas operativos…) etc… etc…
¿Se pueden reducir?
Se pueden reducir mucho, pero la única manera de hacerlo es hacer muchas muchas pruebas, tanto manuales, como automatizadas… Testear todas las posibilidades de la aplicación. Para hacer bien esto si una aplicación nos lleva ahora 1 mes en desarrollarla tendríamos que estar otro mes probándola para entregarla lo más cerrada posible… y aún así, no estaríamos 100% seguros.
¿Cómo trabajamos ahora?
Por nuestra metodología asumimos ciertos procesos para favorecer la inversión de nuestros clientes.
Menos trabajo + resultados
Nosotros trabajamos de la manera más eficiente para el cliente. Para esto, existe cierto tiempo de pruebas que asume el cliente o ciertos fallos que asumimos, fallos que no son graves y que pueden aparecer en algún momento. En lugar de hacer todo tipo de pruebas gastamos el menor tiempo posible en probar las funcionalidades CORE de la aplicación, que todo funciona con un ritmo medio de uso y con eso lanzamos. Pensamos que es más eficiente que con el uso se vayan detectando los fallos y se arreglen en ese momento.
Pongo un ejemplo práctico de los procesos de una metodología y otra y los costes de ambas:
Tenemos una aplicación que hace dos funcionalidades. Funcionalidad A (Registro de usuarios) y Funcionalidad B (Mostrar imagen aleatoria)
a// DESARROLLO minimizando BUGS antes de la entrega al cliente
- Tiempo de desarrollo: 45 días (30 de desarrollo + 15 días de pruebas unitarias de cada funcionalidad por separado)
- Pruebas del desarrollo: 10 días
- Solución de los fallos en las pruebas: 10 días
- Refactorización del código inicial: 15 días.
- Pruebas finales: 5 días
- Tests integración: 5 días
- Solución test de integración: 5 días
- Tiempos total: 95 días para la entrega del producto.
Una vez entregamos el producto y lo subimos.. nos damos cuenta que los usuarios no tienen ningún interés en registrarse, que solo quieren ver su imagen aleatoria, pero quieren poder compartirla. Aquí han pasado varias cosas:
- Hemos perdido tiempo arreglando fallos pequeños en el proceso de registro (funcionalidad A), que finalmente se va a desechar.
- Invertimos otros 5 días en la mejora de la funcionalidad B.
- Invertimos 3 días en pruebas de la funcionalidad B y no da ningún fallo.
- Hemos tardado 103 días en poder subir la herramienta y por tanto ganar dinero con ella.
- Hemos hecho unos tests de carga para 1000usuarios y de momento solo están entrando 300.
- Digamos que a los 103 días tenemos nuestra plataforma y sabiendo que pueden salir bugs en cualquier momento también. con un coste de 100€/día supondría una inversión inicial de 10.300€ + costes de las herramientas de testing
b// DESARROLLO ágil
- Tiempo de desarrollo: 35 días (30 de desarrollo + 5 de pruebas unitarias)
- Pruebas de desarrollo simples: 5 días
- Solución problemas: 2 día
Aquí ya subiríamos la primera versión de la plataforma (BETA)
Nos damos cuenta que el registro de usuario tiene algunos fallos, pero que los usuarios no les interesa registrarse, vemos que si que quieren ver una imagen, pero que luego quieren compartirla. Así que hacemos:
- Arreglamos algunos fallos de la funcionalidad B 5 días.
- Quitamos todo el registro de usuarios de la aplicación y no nos preocupamos de los errores
- Añadimos la funcionalidad B que son 5 días probamos un poco 1 día y subimos todo de nuevo.
- En total hemos tardado en todo este proceso 53 días en tener la plataforma subida y lista, lo que supone un coste de 5.300€. Es cierto que no estará tan tan depurada como la anterior, pero nos sobran 49 días para mejorar cosas o no… porque puede que sea más importante usar ese tiempo/dinero en mejorar la aplicación con nuevas funcionalidades.
¿Cómo puedo minimizar el impacto de un bug?
Normalmente para una buena gestión de esto se contrata un mantenimiento de la aplicación. Esto incluye fundamentalmente tres cosas:
- Disponibilidad mayor para una serie de incidencias. Se reserva una serie de horas por si en algún momento se detecta algún problema en la plataforma de la naturaleza que sea.
- Revisión periódica de la plataforma por parte del equipo de desarrollo para que no exista degradación de la misma.
- Refactorizaciones del código para dotar de más estabilidad.
Paco Pereira. Capitán de la nave.
