En este blog he escrito bastante sobre estos temas, y ahora, después de haber terminado de leer un gran libro, escrito sobre uno de los autores que más ha aportado a estas metodologías con su trabajo incansable, hablo de Henri Kniberg, me complace poder aconsejar la lectura de este libro, que se puede descargar libremente.

Ayer dicté la conferencia con el nombre del título de este post en la Universidad de Córdoba ante unos 40 alumnos y algunos profesores de la misma universidad.

Las metodologías ágiles no es un tema muy de moda en los ambientes académicos y universitarios, puesto que el desarrollo de software no es algo que se haga de forma práctica en esos entornos (se realizan más actividades de tipo docente e investigación), por lo que el tema les sonó a todos nuevo y fresco.

Vale, vale, lo sé, es un poco freaky, pero la verdad es que ayuda bastante en varios aspectos:

• Por un lado, ayuda a interiorizar el sistema, usándolo fuera del contexto habitual, dándole un matiz más desenfadado a las tareas del hogar,
• por otro lado, las tareas del hogar se hacen más dinámicas y divertidas... ¡los niños hacen lo que sea por mover ticket!

Un año y medio después de haber comenzado con las tecnologías y metodologías ágiles, no tengo más que recomendar el libro que me ayudó a comenzar y que ha sido una guía durante todo este tiempo.

El término de entrenador (coach) de desarrollo de software es un papel que suele ser muy importante en el quehacer diario de una empresa que tiene desarrollos de software, ya sean internos o para clientes externos.

Mi última entrada sobre Scrum, hablaba de la implementación del gráfico Burndown, de esto hace ya casi 3 meses, aunque realmente, comenzamos la andadura en algo antes.

En principio, tengo que tener presente que he estado usando algunas otras metodologías, como la Espiral de Boehm y Metrica-3, con lo que, he podido ver y sufrir en mis propias carnes, lo que significa e implica usar una metodología ágil, las ventajas que aporta y lo fáciles que tienden a ser, realmente.

En estos días, después de haber pasado más de 24 horas en el último Sprint, sin descansar, donde comenté la experiencia de haber usado Scrum y XP en [otro artículo][1], volvemos a la carga.

Esta vez, con dos semanas de Sprint, bastante más tiempo, podemos realizar algunas técnicas más para poder medir cuánto vamos a tardar realmente en terminar el proyecto que tenemos entre manos.

Hace un tiempo escribí sobre Srum y XP, en ese mismo artículo, comentaba que estas técnicas, tanto Scrum como XP, eran dos técnicas que me gustaban mucho y que probaría en un futuro... bueno, pues ese futuro ya es presente :-)

La semana pasada, tuvimos, en la empresa en que trabajo, la presión de entregar un proyecto de forma rápida. Pensé que, en estos casos, lo que más se necesita es, como no, la organización. No se puede estar haciendo una actividad de desarrollo entre varias personas y estar con la cabeza preguntando siempre: ¿qué queda por hacer?; así que, me lancé, cogí dos tacos de post-it, uno de tamaño normal para las partes a desarrollar y otro de tamaño más pequeño, para las tareas que hay dentro de cada una de las partes.

Después de darle un repaso al libro Scrum y XP desde las trincheras, he visto que muchas de las técnicas en las que se basa, son como las que usaban nuestros profesores dinámicos en el colegio para motivarnos a participar en clase.

En esencia, es eso, que cada analista/programador se involucre en lo que está haciendo, llegue a un diseño y una finalidad y, sobre todo, que la información sobre lo que se hace, fluya sin que las interrupciones hagan que el trabajo se pare.