13 septiembre 2006
SCRUM en Unkasoft: eXtreme Programming (XP)
Desde que empezamos nuestra serie sobre SCRUM, nos han llegados algunos correos vuestros preguntando sobre eXtreme Programming. ¿Seguís usando XP? ¿Se pueden usar XP junto con SCRUM? ¿En qué lugar quedan las prácticas de XP dentro de SCRUM?
Lo primero que hay que tener claro es qué es cada cosa:
Gracias a SCRUM conseguimos hacer un seguimiento continuo del proyecto, adelantando las sorpresas desagradables, para que nos de tiempo a reaccionar ante ellas. Conseguimos crear un buen ambiente de trabajo, dando a cada uno sus responsabilidades, e intentando no crear tensiones entre el equipo (aunque algunas son inevitables).
Sin embargo, si sólo usásemos SCRUM para gestionar el proyecto,no tendríamos sin ningún control en toda la parte de programación. ¿Cómo debemos escribir el código? ¿Qué tareas debemos hacer antes de codificar? ¿Y después? Aquí es donde entra en juego XP. Con eXtreme Programming tenemos una metodología ágil para programar, que encaja perfectamente con la filosofía que propone SCRUM. Quizá por esto último, el tandem SCRUM + XP se ha empezado a aplicar en varios proyectos de Microsoft e incluso en alguna empresa de videojuegos.
Así que todo lo que hemos contado de SCRUM lo intentamos combinar con las siguientes prácticas de XP:
Lo primero que hay que tener claro es qué es cada cosa:
- eXtreme programming: es una metodología de desarrollo formada por un conjunto de prácticas de programación (y algunas de planificación). Está orientado a escribir un código lo más adaptable al cambio y libre de errores posible.
- SCRUM: es una metodología de planificación y seguimiento de proyectos (de software, de ingeniería civil o de jardinería :) con prácticas orientadas a la gestión de equipos, tareas,
funcionalidades, etc. No explica cómo tienes que escribir tu código (¡en jardinería no se escribe código!) sino cómo organizar los equipos y en general el tiempo para llegar a un buen puerto.
Gracias a SCRUM conseguimos hacer un seguimiento continuo del proyecto, adelantando las sorpresas desagradables, para que nos de tiempo a reaccionar ante ellas. Conseguimos crear un buen ambiente de trabajo, dando a cada uno sus responsabilidades, e intentando no crear tensiones entre el equipo (aunque algunas son inevitables).
Sin embargo, si sólo usásemos SCRUM para gestionar el proyecto,no tendríamos sin ningún control en toda la parte de programación. ¿Cómo debemos escribir el código? ¿Qué tareas debemos hacer antes de codificar? ¿Y después? Aquí es donde entra en juego XP. Con eXtreme Programming tenemos una metodología ágil para programar, que encaja perfectamente con la filosofía que propone SCRUM. Quizá por esto último, el tandem SCRUM + XP se ha empezado a aplicar en varios proyectos de Microsoft e incluso en alguna empresa de videojuegos.Así que todo lo que hemos contado de SCRUM lo intentamos combinar con las siguientes prácticas de XP:
- El juego de la planificación: es más o menos lo que ocurre durante la planificación del sprint: el product owner propone funcionalidades a desarrollar, y el equipo de desarrollo las estima en horas de trabajo.
- Entregas pequeñas y frecuentes: por esta razón hacemos sprints de 1-2 semanas en vez de los de 30 días de propone SCRUM.
- Historias de usuario: más o menos las distintas funcionalidades que apuntamos en el product backlog son historias de usuario.
- Diseño simple: intentamos programar siempre el mínimo código posible que implementa una funcionalidad, sin adornos ni futuribles.
- Pruebas unitarias: seguimos escribiendo nuestras pruebas antes que el propio código, al menos cuando es posible.
- Refactorizaciones: nuestro código está en continua evolución, sobre todo para intentar simplificarlo y clarificarlo.
- Integración continua: hacemos versiones frecuentes y automáticas, lanzando todas las pruebas.
- Semana de 40 horas: no tiene sentido intentar crear un buen clima de trabajo si se exprime a los trabajadores.
- Cliente in situ: nuestro product owner está siempre disponible para cualquier duda.
- Estándares de programación: intentamos seguir la guía de estilo de Sun.
- Programación en parejas: sólo trabajamos en parejas para solucionar problemas o para dar apoyo puntual. SCRUM no limita este aspecto, ya que durante el daily scrum, dos programadores pueden asignarse a una misma tarea si quieren hacerla juntos, pero la verdad es que nosotros no lo estamos haciendo, excepto cuando alguien está atascado con algún problema.
- Propiedad colectiva del código: no es que ahora tengamos módulos privados que sólo su creador puede tocar, sino que intentamos asignar distintos responsables a cada parte del código. Así, cualquiera puede cambiar cualquier código, pero el responsable de ese código debe dar su visto bueno o al menos saber de va el cambio.
Comentarios:
dice...
Discúlpame pues quizás ya lo hayas comentado en algún post pero, ¿con que sw habéis gestionado el proyecto en el que habéis utilizado SCRUM?
Gracias por compartir vuestra experiencia.
Ángel
JM dice...
Hola Ángel:
En realidad para aplicar SCRUM no necesitas ningún software, puedes hacerlo con papel y boli (:
De todas formas, siempre hay software que te puede ayudar a hacerlo de forma automática.
Nosotros por ahora usamos hojas de Excel para el product y el sprint backlog, aunque estamos evaluando alguna que otra herramienta que nos permita mantener el product y el sprint backlog, que nos genere los burndown charts, etc.
Puedes echar a las siguientes:
- XPWeb
- PPTS
- AgileTrack
Saludos!
JM
dice...
La combinación XP + Scrum es muy habitual.
De Hecho, Mike Breedle que colaboró con Ken Schwaber en la aplicación de scrum al software, ideó una metodología que denominó XBreed
(http://agile.csc.ncsu.edu/xbreed.html) que consiste en esta combinación.
En la actualidad la ha evolucionado y la llama AE (Agile Enterprise)
(http://www.e-architects.com/AE/) en la que mantiene la gestión con línea Scrum. En la dirección anterior podéis echar un vistazo a sus principios.
En realidad lo ideal (en mi opinión) es lo que hace jm. No tomar el desarrollo de software como cosa de recetario. Tomar XP o Scrum o CMM y aplicarlo tal cual. No es cuestión de adaptar la empresa a un modelo, sino al revés.
Lo que pasa es que aplicar un recetario es lo fácil, lo difícil es conocer no las formas, sino los fondos y tener buen criterio para usarlas.
¿Por qué no hacer sprints de 2 semanas?. ¿Por qué no emplear la programación de parejas cuando se necesita?...
Modelos hay muchos. Cada uno puede publicar el suyo. De hecho es lo que está ocurriendo (AE, FDD, Scrum, AM, ASD, AUP, TDD....). Lo importante es comprender los principios y conocer los modelos para poder hacer un traje a la medida de la empresa de uno.
Para la proxima semana (espero que a mitad), intentaré publicar un resumen de los principios ágiles en los posts de apuntes de síntesis de navegapolis para intentar contarlo con un poco más de orden.
Saludos!
JM dice...
Efectivamente, Juan:
Cuando empezamos esta aventura teníamos muy en mente no dejarnos llevar por modas y adoptar sólo aquello que realmente nos fuera útil.
Lo habitual, cuando no tienes experiencia con una metodología, es seguirla a pies juntillas, sin pararse a pensar en lo que estamos haciendo y el porqué de las cosas. Es lógico, también hemos pasado por ahí. Sin embargo, con un poco más de experiencia se aprende a discernir entre lo accesorio y lo esencial, y sobre todo a entender que no hay soluciones únicas, ni "silver bullets", sino que en cada caso hay que ajustar ciertos parámetros para que los engranajes encajen bien. Nosotros todavía estamos en ese proceso (:
Saludos!
JM
Drows dice...
Seguir una metodologia a ciegas tampoco lleva a ningún lado, sobre todo desde el punto de vista creativo.
Creo que Scrum es lo suficientemente ágil como para controlar el trabajo de cada uno, saber el avance y al mismo tiempo dejar creatividad en el proceso.
Para los que hacemos juegos, la creatividad de todo el equipo, programadores incluidos es algo esencial. COMo podreis apreciar en nuestro último juego que hemos terminado hace 2 días.
Saludos
chuidiang dice...
Hola:
Por un lado me alegra oíros decir que no es necesario seguir al pie de la letra las metodologías. Me gustaría aplicar XP, pero desde luego la programación en parejas sería difícil de justificar delante de los jefes, además que el entorno -una sala diáfana con sesenta personas- no parece lo más adecuado para montar el "gallinero" de gente trabajando -y hablando- de dos en dos.
Sin embargo, se me plantea una duda. Supuestamente estas metodologías están muy pensadas y probadas por expertos/gurus. ¿Se puede obtener el 100% de sus ventajas si las aplicamos a medias?. Lo de que determinada práctica no encaja con nuestra empresa, no es útil, o lo que sea, no deja de ser una opinión subjetiva nuestra, que posiblemente no se basa en medidas reales -unos años con esa práctia y otros sin ella y comparar resultados-.
Se bueno.
JM dice...
En el tema de las metodologías siempre hay que andarse con pies de plomo.
Lo gurús de turno siempre dicen que hay que aplicar la metodología al 100%, y si no, no funciona.
Yo tengo mis dudas al respecto, porque cada cultura, empresa, equipo, proyecto, etc. es un mundo, y no tiene sentido aplicar soluciones "enlatadas" sin tener en cuenta esos factores.
Utilizando tu ejemplo: Kent habla de que en XP es *obligatorio* el uso de pair-programming y que las salas deben ser diáfanas, todo el mundo a la vista para que la comunicación fluya.
Eso en España se traduce, como tú dices, en: cachondeo + gallinero.
(hombre, también hay que reconocer que en XP hablan de equipos pequeños, máximo 6-8 personas, así que una sala con 70 no es precisamente "pequeño").
Por eso yo creo que es importante *adaptar* la metodología a la cultura empresarial y a las circunstancias, siempre y cuando estemos hablando de *adaptar* y no de *transformar* (claro, para saber "adaptar sin transformar" hay que entender bien la metodología, tener experiencia implantando procesos y saber dónde puedes "meter" mano sin cargarte nada :)
Pues nada, espero que te oriente un poco.
Suerte con tus aventuras
JM
dice...
Excelente artículo, no se si lo de programación de a pares es mas bien de XP que de las metodologías ágiles en particular. Dejo otro artículo interesante que encontré en http://www.conexionit.com/blog
Publicar un comentario
<< Home
dice...Discúlpame pues quizás ya lo hayas comentado en algún post pero, ¿con que sw habéis gestionado el proyecto en el que habéis utilizado SCRUM?
Gracias por compartir vuestra experiencia.
Ángel
JM dice...Hola Ángel:
En realidad para aplicar SCRUM no necesitas ningún software, puedes hacerlo con papel y boli (:
De todas formas, siempre hay software que te puede ayudar a hacerlo de forma automática.
Nosotros por ahora usamos hojas de Excel para el product y el sprint backlog, aunque estamos evaluando alguna que otra herramienta que nos permita mantener el product y el sprint backlog, que nos genere los burndown charts, etc.
Puedes echar a las siguientes:
- XPWeb
- PPTS
- AgileTrack
Saludos!
JM
dice...La combinación XP + Scrum es muy habitual.
De Hecho, Mike Breedle que colaboró con Ken Schwaber en la aplicación de scrum al software, ideó una metodología que denominó XBreed
(http://agile.csc.ncsu.edu/xbreed.html) que consiste en esta combinación.
En la actualidad la ha evolucionado y la llama AE (Agile Enterprise)
(http://www.e-architects.com/AE/) en la que mantiene la gestión con línea Scrum. En la dirección anterior podéis echar un vistazo a sus principios.
En realidad lo ideal (en mi opinión) es lo que hace jm. No tomar el desarrollo de software como cosa de recetario. Tomar XP o Scrum o CMM y aplicarlo tal cual. No es cuestión de adaptar la empresa a un modelo, sino al revés.
Lo que pasa es que aplicar un recetario es lo fácil, lo difícil es conocer no las formas, sino los fondos y tener buen criterio para usarlas.
¿Por qué no hacer sprints de 2 semanas?. ¿Por qué no emplear la programación de parejas cuando se necesita?...
Modelos hay muchos. Cada uno puede publicar el suyo. De hecho es lo que está ocurriendo (AE, FDD, Scrum, AM, ASD, AUP, TDD....). Lo importante es comprender los principios y conocer los modelos para poder hacer un traje a la medida de la empresa de uno.
Para la proxima semana (espero que a mitad), intentaré publicar un resumen de los principios ágiles en los posts de apuntes de síntesis de navegapolis para intentar contarlo con un poco más de orden.
Saludos!
JM dice...Efectivamente, Juan:
Cuando empezamos esta aventura teníamos muy en mente no dejarnos llevar por modas y adoptar sólo aquello que realmente nos fuera útil.
Lo habitual, cuando no tienes experiencia con una metodología, es seguirla a pies juntillas, sin pararse a pensar en lo que estamos haciendo y el porqué de las cosas. Es lógico, también hemos pasado por ahí. Sin embargo, con un poco más de experiencia se aprende a discernir entre lo accesorio y lo esencial, y sobre todo a entender que no hay soluciones únicas, ni "silver bullets", sino que en cada caso hay que ajustar ciertos parámetros para que los engranajes encajen bien. Nosotros todavía estamos en ese proceso (:
Saludos!
JM
Drows dice...Seguir una metodologia a ciegas tampoco lleva a ningún lado, sobre todo desde el punto de vista creativo.
Creo que Scrum es lo suficientemente ágil como para controlar el trabajo de cada uno, saber el avance y al mismo tiempo dejar creatividad en el proceso.
Para los que hacemos juegos, la creatividad de todo el equipo, programadores incluidos es algo esencial. COMo podreis apreciar en nuestro último juego que hemos terminado hace 2 días.
Saludos
chuidiang dice...Hola:
Por un lado me alegra oíros decir que no es necesario seguir al pie de la letra las metodologías. Me gustaría aplicar XP, pero desde luego la programación en parejas sería difícil de justificar delante de los jefes, además que el entorno -una sala diáfana con sesenta personas- no parece lo más adecuado para montar el "gallinero" de gente trabajando -y hablando- de dos en dos.
Sin embargo, se me plantea una duda. Supuestamente estas metodologías están muy pensadas y probadas por expertos/gurus. ¿Se puede obtener el 100% de sus ventajas si las aplicamos a medias?. Lo de que determinada práctica no encaja con nuestra empresa, no es útil, o lo que sea, no deja de ser una opinión subjetiva nuestra, que posiblemente no se basa en medidas reales -unos años con esa práctia y otros sin ella y comparar resultados-.
Se bueno.
JM dice...En el tema de las metodologías siempre hay que andarse con pies de plomo.
Lo gurús de turno siempre dicen que hay que aplicar la metodología al 100%, y si no, no funciona.
Yo tengo mis dudas al respecto, porque cada cultura, empresa, equipo, proyecto, etc. es un mundo, y no tiene sentido aplicar soluciones "enlatadas" sin tener en cuenta esos factores.
Utilizando tu ejemplo: Kent habla de que en XP es *obligatorio* el uso de pair-programming y que las salas deben ser diáfanas, todo el mundo a la vista para que la comunicación fluya.
Eso en España se traduce, como tú dices, en: cachondeo + gallinero.
(hombre, también hay que reconocer que en XP hablan de equipos pequeños, máximo 6-8 personas, así que una sala con 70 no es precisamente "pequeño").
Por eso yo creo que es importante *adaptar* la metodología a la cultura empresarial y a las circunstancias, siempre y cuando estemos hablando de *adaptar* y no de *transformar* (claro, para saber "adaptar sin transformar" hay que entender bien la metodología, tener experiencia implantando procesos y saber dónde puedes "meter" mano sin cargarte nada :)
Pues nada, espero que te oriente un poco.
Suerte con tus aventuras
JM
dice...Excelente artículo, no se si lo de programación de a pares es mas bien de XP que de las metodologías ágiles en particular. Dejo otro artículo interesante que encontré en http://www.conexionit.com/blog
Publicar un comentario
<< Home
