ES KAsi UN blog

Blog de Unkasoft, donde hablamos de programación de juegos para móviles, advergaming, marketing móvil, la industria de los videojuegos, metodologías ágiles y todos aquellos temas que nos preocupan en nuestro día a día

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:O sea: cada cosa para lo suyo.
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:Pero hay algunas que hemos tenido que dejar a un lado:En definitiva: SCRUM por si solo se puede quedar cojo, ya que no da pautas específicas sobre cómo abordar la programación, así que combinándolo con eXtreme Programming conseguimos una metodología ágil mucho más completa.

Etiquetas: ,


Comentarios:

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
 


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
 


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!
 


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
 


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
 


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.
 


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
 


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

This page is powered by Blogger. Isn't yours?