El primer flashback lo asocio con la corrección de errores de software, cuantas veces nos hemos enfrentado a un error de codificación difícil de corregir (si los famosos bugs) y le invertimos bastante tiempo, incluso días en detectar donde está el error. Muchas veces al final nos encontramos que lo que está provocando semejante error es una insignificancia, la cual nos ha costado bastante esfuerzo en depuración y un buen dolor de cabeza. Una vez corregido el error nos olvidamos de él... hasta que tiempo después vuelve a ocurrir nuevamente, y ¡ahí es donde viene el flashback! nos encontramos con un error de software que no tiene una explicación lógica, algo que funcionaba y de la noche a la mañana dejó de hacerlo, y lo peor del caso, un error similar (bueno, igual pero en otro proyecto) a uno que ya había ocurrido anteriormente y ya le habíamos dado solución. Y nos ponemos a pensar... ¡si esto ya me había pasado!, ¡si recuerdo que batalle tres días para corregirlo!, ¿alguien recuerda cómo lo solucionamos la vez pasada? Y por mas que intentamos recordar no lo logramos, entonces viene nuevamente el arduo proceso de depuración hasta llegar nuevamente a la solución, si en el camino logramos recordar cual era evitaremos seguir desperdiciando tiempo. Pero, ¿cómo llegamos a este flashback? simple, por la mala costumbre de no documentar los errores de codificación, y sobre todo las soluciones que les dimos a dichos errores. Que fácil sería abrir un libro (en el mas modesto de los casos) y localizar el error que nos acaba de ocurrir nuevamente y al que en otras ocasiones ya habíamos dado solución. El flashback sería simplemente una reunión entre los miembros del equipo para si alguien vagamente recuerde de un caso similar y proceder a revisar nuestro 'libro de registro de posibles flashbacks'. Recuerdo un proyecto en el debido a su importancia tuvimos que invertir algo de tiempo para implementar un software para seguimiento de errores, lo llamamos 'Bug Tracker' y nos fue de mucha utilidad. Si no tenemos el tiempo para diseñar un software para registro de errores bastará con llevar un registro manual de los errores en una libreta.
El segundo flashback que voy a mencionar es el que se encuentra relacionado al proceso de desarrollo de un proyecto de software, y se presenta cuando cometemos un error durante el mismo, ya sea administrativo o de ingeniería. Muchas veces nos encontramos con actividades que en vez de beneficiar al desarrollo del proceso lo complican, ya sea burocracia, detalles excesivos en el diseño, una mala planeación, omisión de tareas críticas, etc. y simplemente las vamos resolviendo 'al vuelo' y con bastantes presiones de tiempo. Una vez finalizado el proyecto nos apresuramos a darle cierre y olvidarnos para siempre de él. Mal hecho, el no realizar una reunión post-mortem del proyectos en donde documentemos las lecciones aprendidas provocará que mas adelante se puedan repetir los mismos problemas en otros proyectos, y al igual que en el primero consumirá tiempo, dinero y esfuerzo (siempre quise usar esa frase, es todo un clásico). Por lo tanto para evitar un 'esto ya lo había vivido' lo mejor será documentar nuestros éxitos y nuestros fracasos para cada proyecto de software y sobre todo ir retroalimentando nuestro proceso de desarrollo de software con el fin de evitar repetir los mismos problemas en un futuro (y tener otro flashback).
El tercer flashback del que les quiero hablar es uno que siempre debe estar presente en nuestros proyectos, las pruebas de regresión. Este flashback consiste en repetir con cada integración todas las pruebas realizadas sobre dicho software (si... TODAS). De ahí la importancia de diseñar nuestros casos de prueba y utilizar herramientas automatizadas para su ejecución. Pero ¿porqué es necesario probar todo nuevamente?, pues simple, para garantizar que todo lo que ya funcionaba siga funcionando. La integración es un proceso delicado, puede ser que entre las distintas configuraciones de software existentes se introduzca y propague un error, y podemos quizás dar por hecho de que una funcionalidad previamente probada siga cumpliendo con su cometido, y no probarla nuevamente, hasta el momento en que llegue a manos del usuario y entonces surja el error, y nuestra respuesta será... ¡si eso ya funcionaba! (vaya 2 flashbacks a la vez).
Como siempre, tomen mis opiniones para crear un caos de su proyecto, ya que nuestro objetivo del blog es desadministrar proyectos (creo que tuve un flashback).
No hay comentarios:
Publicar un comentario