El día de hoy se llevo a cabo el Agile CoffeeCamp Tijuana, el cual duro alrededor de dos horas y media en una platica amena entre los presentes donde se expresaron dudas y experiencias sobre las metodología ágiles.
A continuación presento una recapitulación de los mas importante - desde mi punto de vista -:
1. - Primeramente se pregunto si el auge de Agile se debía a una moda o no, y de acuerdo a los comentarios, creo que coincidimos en que Agile presenta conceptos no nuevos y que de forma recurrente han aparecido en la industria del desarrollo de software, ya que muchos de ellos son mas del tipo del sentido común, por lo tanto los conceptos de alguna forma son viejos, pero el momentum de la industria de software, la mención en blogs, revistas, conferencias, etc; le ha traído gran publicidad a las metodología ágiles, lo cual ha provocado que mucha gente "brinque" y quiera ser ágil, por lo cual si podemos considerar que es una moda, pero al final, los equipos y empresas que las implementen seriamente y con conciencia, son las únicas que van a continuar utilizandolas, cuando algo mas se ponga de moda nuevamente.
Aunque el estar de moda no es necesariamente algo malo, pero también hay que comprender que no son la solución para todos los problemas del proceso de desarrollo de software y mas si consideramos que metodología como XP, de alguna forma requiere de programadores con una buen nivel de capacidad técnica y entendimiento de conceptos básicos del desarrollo de software, conceptos que para ser sincero no muchos programadores manejan de forma fluida.
2. - Sobre las pruebas de unidad, funcionales e integración; se cuestiono sobre si realmente es algo que sirva para el proyecto, como se vende al cliente, que se debe de probar.
Creo que todos coincidimos que cualquier mecanismo que permita comprobar que nuestro software funciona de acuerdo a lo esperado y que podemos detectar de forma automática si algún cambio introducido en nuestra aplicación causa algún problema en otra área y nos evita el tener que depurarla para buscar tal problema, por lo tanto las pruebas automáticas de software no deben de ser subestimadas, ni dejadas de lado.
También se menciono que como parte del presupuesto de tiempo/dinero de un proyecto, se debe de contemplar el costo de las pruebas automáticas del sistema, no tienen porque venderse a parte del proyecto, ya que estas son una parte fundamental del proyecto.
Y aun si no se usa alguna metodología para el desarrollo de software, no podemos decir que no realizamos pruebas sobre nuestro software, simplemente el lanzar la aplicación, navegar las pantallas, capturar algunos datos y revisar el resultado; estamos realizando pruebas de forma manual, las cuales pueden incluir el factor humano de error u omisión al realizarlas, por lo tanto, la pregunta es, si ya hacemos las pruebas, ¿porque no las formalizamos como parte del proyecto?, el esfuerzo puede ser importante pero el beneficio de ellas va a ser en la misma magnitud o posiblemente mayor.
Finalmente sobre que probar en nuestra aplicación, no es una pregunta con una respuesta simple, algunos van a decir que hay que probar todo, absolutamente todo, algunos otros que solo hay que probar lo que haga sentido, en lo particular opino que hay que probar únicamente nuestro código, si se usan librerías de terceros, no tenemos que probar esas librerías, únicamente nuestro código propio, y la integración de nuestra aplicación con algún otro sistema.
3. - Se pregunto la efectividad y la relación costo/beneficio de realizar programación en pareja, comentamos que uno de los beneficios de esta practica es el que al tener dos programadores trabajando sobre la misma sección de código puede ayudar a crear mejor código y con menos errores, promueve el trabajo en equipo, que la pareja de programadores alcance el mismos nivel técnico, el que se pueda lograr un mejor entendimiento de los requerimientos, el solucionar problemas en los cuales una sola persona se puede "ciclar" y tardar mas tiempo en solucionarlo.
Otro punto importante y que no se comento, es que de alguna forma se tiende a perder menos tiempo, ya que programado solo, es mas probable utilizar el tiempo para leer feeds, contestar el mensajero o correos, en cambio cuando hay dos personas es menos viable que esto suceda.
También se comento que al programar en parejas ya no únicamente un solo programador tiene el conocimiento sobre ciertas áreas del programa, ya hay mas gente con ese conocimiento; y al tener otro par de ojos revisando el código es mucho mas sencillo identificar de manera rápida errores de sintaxis y lógica y corregirlos al momento.
Si bien esta practica tiene beneficios interesantes, si creo que es un poco difícil venderla en nuestros lugares de trabajo, ya que la primera reacción va a ser la percepción de que se pierde el tiempo de un recurso al nadas sentarse y revisar el código de otro.
Aquí dejo una serie de ligas y vídeos de una compañía llamada Hashrocket que realiza programación en parejas como una practica normal de la empresa y que mencionan les ha dado buenos resultados:
Pair Programming from Hashrocket on Vimeo.
Extreme Programming from Hashrocket on Vimeo.
En fin la convivencia fue bastante buena, hubo gente nueva y gente conocida, ademas creo que la platica estuvo interesante, en relación a las dudas, los conceptos y las experiencias, @gabo nos ayudo a transmitir el audio en vivo y @webcool grabo una parte de la platica en video, así que espero que en los próximos días lo podamos publicar, por lo pronto aquí les dejo unas cuantas fotos que tomo @samaniegojessi y unas cuantas mías
