Tag Archives: xtreme programming

Conferencia: Metodologías Ágiles en la Práctica

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.

Fuera de aburrir al personal, la charla, aunque larga (hora y media), abarcó muchos aspectos de lo que se refiere al desarrollo del software e incluí una visión práctica de cómo lo tengo montado en la empresa en la que trabajo.

Quizás una futura presentación la haga realizando un scrum de verdad seleccionando a algunos asistentes y proponiendo una actividad a realizar que, aunque no tenga que ver con la programación, se pueda llegar a emplear un tablero sin probleas, así como asumir los roles específicos de dueño de producto, scrum master y el resto de integrantes del equipo.

Dejo la presentación aquí:

NOTA: la presentación en sí, aunque tiene algunas diapositivas explicativas y un montón de imágenes, no aporta todo el texto que se dictó, por lo que, es muy posible que resulte incompleta, extraña y carente de sentido en algunas partes.

Scrum y XP desde las trincheras

Un año y medio después de haber comenzado con las tecnologías y metdologí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.

Scrum And XP From The Trenches
Henrik Kniberg; Lulu.com 2007

Este libro (y su traducción al castellano), han supuesto una guía práctica de cómo comenzar en el desarrollo ágil tomando a Scrum como referencia y empleando, en lo que se refiere a técnicas de programación, algunos ejemplos de la metodología de Xtreme Programming.

El libro brinda la visión personal de Henri, una persona que ha estado empleando estas metodologías como consultor con muchos grupos de trabajo a lo largo de muchos años de trabajo y, gracias a ello, y a su excelente labor pedagógica, ha conseguido escribir un buen libro, claro, conciso y bastante corto para todo el material que contiene. Son libros que se leen de forma rápida y te preguntas, cuando llegas a su última hoja: ¿ya se acabó?

Extreme Programming explained

Este es uno de esos libros pioneros que hacen que nos planteemos muchas de las cosas que hacemos y, sobretodo, el cómo lo hacemos.

Extreme Programming Explained
Kent Beck; Addison-Wesley Professional 1999

La metodología de la programación extrema fue acuñada por Kent Beck, como un conjunto de buenas prácticas y una forma de realizar los desarrollos, siempre basándose en dar el mayor valor al cliente, tal y cómo se supone que debe de ser siempre.

No obstante, el propio Beck sabe que esta metodología, al igual que las demás, tiene sus ventajas e inconvenientes, ya que si se intenta seguir de forma inflexible, puede resultar en que los proyectos terminen siendo, en algunos casos infructuosos. En este sentido, Beck, nos llama hacia la agilidad como una forma de sacar nuestro sentido común y emplear nuestro saber hacer, y no los procedimientos tipo que aplicar.

Buen libro, de principio a fin, enseña no solo las bases y teorías, sino que plantea, desde el comentario de cómo funcionarían equipos dentro de la metodología, escenarios de cómo se puede aplicar.

Mentalidad de Suficiencia

Citando a Kent Beck, de su libro Extreme Programming Explained:


En la Gente del Bosque y la Gente de la Montaña, el antropólogo Colin Turnbull dibuja el contraste de dos sociedades. En las montañas, los recursos eran escasos y la gente estaba siempre al borde de la hambruna. La cultura a la que evolucionaron era horrible. Las madres abandonaban a sus bebés, los entregaban a hordas de niños salvajes errantes en cuanto tenían opciones mínimas de sobrevivir. Violencia, brutalidad y traición estaban a la orden del día.

En cambio, en el bosque había plenitud de recursos. Una persona tenía solo que emplear media hora al día para cubrir sus necesidades diarias. La cultura del bosque era la imagen en el espejo de la cultura de la montaña. Los adultos compartían el cuidado de los niños, quienes eran nutridos y amados hasta que estaban preparados para cuidar de sí mismos. Si una persona, accidentalmente, mataba a otra (el crimen deliberado no se conocía), era exiliado, pero solo tenían que ir a otra parte del bosque y solo por unos meses, y la gente del bosque le llevaba comida.

Xtreme Programing es un experimento que responde a la pregunta, ¿Que pasaría si tuvieras suficiente tiempo? Ahora, no tienes tiempo extra, porque esto es un negocio, después de todo y estamos jugando a ganar. Pero si tuvieras suficiente tiempo, escribirías tests; podrías reestructurar el sistema cuando aprendieses algo; podrías hablar con muchos colegas programadores y con el cliente.

Tal mentalidad de suficiencia es inhumana, al contrario que la incesante pesadez de lo imposible, imponiendo fechas de entrega que desperdician el talento en la programación en el mundo de los negocios. La mentalidad de suficiencia es también buena para los negocios. Esta crea sus propias eficiencias, al igual que la mentalidad de escasez crea sus propios perjuicios.

Este texto explica el uso de Xtreme Programming y los beneficios que conlleva. Leyendo esta introducción, queda claro, tal y como intenta transmitir el autor, que lo que propone esta metodología, no es solo producir más rápido, sino mejor, en sentido de que los desarrolladores no terminen quemados, como suele suceder en la mayoría de los casos.

Este tipo de metodologías, contribuyen a seguir haciendo la programación divertida, incluso en el trabajo.

Agradecer a mi amigo Jonathan la ayuda en la traducción, que sin él el texto habría quedado en inglés o muy mal expresado :-P

Scrum y XP en la práctica

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.

Scrum

En la imagen se puede apreciar el cómo quedó la pared de la oficina cuando comenzamos la experiencia. Comento un poco como lo hicimos, aunque la verdad, fue algo muy básico.

Usando Scrum

Lo primero que hicimos fue localizar los grandes grupos a desarrollar. En este caso, lo que había que desarrollar, principalmente, era una interfaz web para un cliente específico. Así que nos encargamos de convertir, cada parte importante de la interfaz en un bloque de tareas.

Dentro de cada uno de los bloques (alrededor), se agrupaban las tareas que había que realizar para completar ese bloque.

Los papeles se ordenan de arriba a abajo, según su prioridad, de más alta a más baja, respectivamente. Todos ellos, a su vez, se colocan en la parte izquierda del marco que se vaya a emplear para el proyecto de scrum. La idea es que, cuando una tarea se esté realizando, se pase a una zona central y, cuando haya sido terminada, se pase a la zona derecha. Nosotros usamos la separación física existente entre vidrio y vidrio, considerando la parte central justo la línea de unión entre ambos.

¿En qué beneficia?, pues básicamente en que cuando una tarea se finaliza, todos ven que se ha finalizado y que, cuando alguien no sabe que hacer, se puede levantar y mirar las tareas que hay por realizar.

Cabe señalar dos aspectos muy importantes y a tener muy en cuenta:

  • Hay que definir, y muy bien, lo que significa terminado. Ya que alguien puede considerar una tarea terminada cuando ha terminado de codificarla (sin probarla), mientras que quien la solicita, considera que se termina cuando ya no se debe de tocar más, ha sido comprobada, validada y está lista para producción.
  • El scrum master es la única persona que debe de mover los papeles, así como agregar nuevos o eliminar, según se dé el caso. Esto es para controlar que, realmente, se ha terminado, como se decía antes, la tarea. Además, el hecho de agregar/eliminar tareas es una actividad muy sensible, que no se debe de dejar a todos, puesto que sino, podrían sucederse situaciones indeseables.

Y un poquito de Xtreme programming

Hay otra práctica que realizamos ese mismo día, y es la del empleo del Xtreme Programming, otra vez, a nivel muy básico. En esencia, se trataba de realizar la programación más costosa (o la que se hacía ya con sueño :-P ) entre dos personas, una haciendo de piloto (al teclado) y otra haciendo de navegante (cabeza pensante).

Los beneficios de esta técnica fueron la velocidad a la hora de desarrollar ciertas partes, puesto que la presión que ejerce el navegante al piloto y la dinámica que se crea, hace que el desarrollo carezca de partes de inactividad y cada tarea se acabe antes.

Algunas conclusiones

Puedo decir que la valoración acerca de estas técnicas, en sus inicios dentro de la empresa, han sido muy positivas, llegándose a conseguir los objetivos deseados, por lo que seguiremos empleando dichas técnicas, así como implementando cada una de ellas de forma más completa para ganar en eficiencia y conseguir que los proyectos se puedan medir de forma más precisa en el tiempo.

Pero de eso ya contaré más adelante… :-)

Scrum y XP

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.

Recomiendo la lectura del documento, puesto que muestra cómo funciona Scrum, XP y algunas técnicas más, en el día a día de varios grupos de desarrollo de Scrum, de la mano de un coach y gerente, encargado de llevar a cabo el desarrollo de productos dentro de una empresa.

Yo, por mi parte, en la etapa en que me encuentro, usaré lo que buenamente pueda para hacer que mi equipo de desarrollo sea más óptimo y, sobre todo, nos divierta lo que hacemos.