RSSBuena metodología + buen entorno de trabajo = Un nuevo mejor adaptado
Apr 07
Formación, Java, Metodologías ágiles 4 Comments
Hace ya casi un mes que he empezado a trabajar en IPSA y ya en este tiempo he visto la diferencia que tiene la forma de trabajar con respecto a las otras tantas consultoras por las que he pasado. Lo primero es que aquí se hace producto, no se hace software a medida. Esto en sí no es mejor ni peor, es sólo un modelo de negocio.
Lo primero que sorprende a alguien como yo acostumbrado a la vorágine de las consultoras, es que aquí llevo 4 semanas haciendo pair programming. Esta me parece la mejor forma de hacer que alguien que entra nuevo aprenda más rapidamente. Estaba acostumbrado a que el “arquitecto” de turno me soltara una charla de 20 minutos sobre como está todo, y en seguida ponerme a desarrollar. Por supuesto solía ser una aplicación que tiene un diseño chusquero y los test automáticos es de esas cosas que haremos al final si da tiempo y que nunca daba tiempo porque ya íbamos con semanas/meses/años (sí sí, años!!) de retraso.
En estas semanas en IPSA he confirmado junto a Alfredo (y Xavi Gost en la semana que pasé con él) mis sospechas de que haciendo test automáticos todo es mucho más sencillo. Da igual si quito esto, si pongo esto otro aquí o si cambio esta línea por esta otra, tengo una batería de unos 3000 test (si no recuerdo mal) que respaldan que no estoy rompiendo nada. Y claro, por cada cambio que hago no voy a pasar yo a mano todos esos test, para algo está algo llamado servidor de integración contínua. En este caso usamos Hudson, pero da igual cuál de las herramientas elegir, lo importante es tener algo que nos de la tranquilidad de que si hemos roto algo con un cambio nos enteremos como mucho con 1 día de diferencia, y no a los 6 meses cuando instalemos en producción.
Otro avance importante es Scrum. Entré justo a trabajar el día de una demo de final de sprint y me sirvió para ver un poco de qué iba la herramienta. Sólo vi una parte pequeña, pero al menos me sirvió para hacerme alguna idea general. Mucho mejor una demo que el jefe de proyecto de turno te cuente durante 2 interminables horas lo que están haciendo. Además la reunión diaria ayuda para ver que está haciendo cada uno con lo que también te das cuenta de hacia donde avanza el proyecto.
Las prisas son malas consejeras. En este último sprint no entró una historia que había planificada porque faltaba por hacer una tarea de 2 puntos. Corriendo se podría haber hecho pero, ¿para qué? ¿para hacerlo corriendo y arriesgarnos a hacerlo mal?
TDD me ayuda a centrar lo que quiero hacer. Ya pensar el nombre que le voy a dar el test me obliga a tener muy claro qué es lo que quiero hacer. Si no lo tengo claro (y muchas muchas veces he empezado a desarrollar algo sin saber exactamente lo que tengo a hacer) me será imposible elegir nombre. Y lo mismo para hacer el código de ese test.
En resumen, si quieres que la gente nueva que entra en tu equipo sea productiva más rapidamente, dales el entorno adecuado para que aprendan lo más rápido posible. Si quieres que no te rompan nada mientras aprenden ten toda la aplicación a prueba de manazas como yo con test automáticos de todo lo que sea posible. Si quieres que se hagan las cosas bien, no quieras las cosas para ayer, desarrollar algo en condiciones lleva su tiempo. Y si quieres irte a casa y dormir tranquilamente, pon un Hudson (o similares) en tu vida.