XP como complemento a Scrum

718 views
Skip to first unread message

Jordi Pradel

unread,
Mar 12, 2009, 1:09:45 PM3/12/09
to agile-spain
Hola a todos,

Mi nombre es Jordi Pradel [0] y soy el socio de Jose Raya (al que
algunos ya conocéis). A parte de para presentarme brevemente, escribo
para debatir un tema al que últimamente he estado dando vueltas.

Scrum es, probablemente, una de las metodologías ágiles de mayor
implantación entre las grandes empresas de desarrollo de software (por
lo menos en el entorno de Internet). Por poner algunos ejemplos, tanto
Google, como Yahoo como Microsoft la utilizan [1]. Uno de los puntos
fuertes de Scrum es que, en realidad, conforma un framework que no
intenta solucionar todos los aspectos del desarrollo de software sino
que se centra en la gestión del proceso de desarrollo de una forma
ágil.

Esta razón hace que Scrum pueda y deba complementarse con técnicas en
las áreas que no detalla. Me vienen a la cabeza rápidamente las
técnicas necesarias para recogida de requisitos y creación del Product
Backlog (donde las User Stories de Mike Cohn encajan como un guante
[2]), técnicas de diseño y programación, técnicas de pruebas, etc.

Muchas de las prácticas de XP [3] son buenos complementos a Scrum como
prácticas para el diseño y programación del software **1.

En ningún orden particular, reviso las prácticas de XP en relación a
su aplicabilidad en un proyecto Scrum:

1) Refactoring, Test Driven Development, Sustainable pace, Team code
ownership, Coding standard, Simple design y Continuous integration son
técnicas adicionales a Scrum pero totalmente en sintonía con él, que
se adaptan sin dificultades. Creo que todas son bastante
imprescindibles.

2) Pair programming: Seguramente se podría añadir a la lista de
técnicas del tema 3, aunque es una técnica con mucha más controversia
que las citadas en el punto anterior.

3) Small releases: Aquí existe una primera posible diferencia.
Schwaber y Beedle insisten en iteraciones de 4 semanas (por lo menos
hasta estar familiarizado con Scrum) [4], mientras que XP recomienda
iteraciones de entre 1 y 4 semanas (y, ante la duda, quedarse con la
más corta) [2] (me haría falta una cita canónica, de los creadores de
XP). Aunque otros autores, como Mike Cohn [5], reconocen que en Scrum
son útiles las iteraciones entre 2 y 4 semanas [1].

4) Metaphor: Aunque no es una técnica de implementación o diseño no
veo que no pueda complementar a Scrum y las demás técnicas de XP.

5) El planning game queda substituido por el propio Scrum en cuanto a
gestión de la planificación

6) On-site customer no sería más que otra forma de hablar del Product
Owner

¿Qué opináis? ¿Alguna experiencia en proyectos dónde hayáis integrado
Scrum y XP que os interese comentar? ¿Qué otras técnicas usáis para
complementar Scrum?

**1 De hecho, en el marketing del libro canónico de Schwaber y Beedle
[4] se menciona "Simplify XP implementation through a SCRUM wrapper"
como una de las aplicaciones posibles de Scrum. Supongo que es de una
época en que mencionar XP para promocionar un libro de Scrum podía
aportar ventas a dicho libro.

[0] http://www.linkedin.com/pub/dir/jordi/pradel
[1] Mike Cohn, An overview of Scrum, 2002 (descargable desde
http://www.mountaingoatsoftware.com/presentations)
[2] Mike Cohn, User Stories Applied, Addison-Wesley, 2006 (http://
books.google.com/books?id=SvIwuX4SVigC)
[3] Kent Beck, Extreme Programming Explained: Embrace change, Addisson-
Wesley, 2000 (http://books.google.com/books?id=G8EL4H4vf7UC)
[4] Ken Schawber, Mike Beedle, Agile Software Development with Scrum,
Prentice Hall, 2002 (http://books.google.com/books?id=hJwMAAAACAAJ)
[5] Mike Cohn: Cofundador de la Scrum Alliance, CSM, CSP, CST (y
Máster del Universo :) ). http://www.scrumalliance.org/profiles/8-mike-cohn

Vicenç Garcia

unread,
Mar 12, 2009, 1:26:07 PM3/12/09
to agile...@googlegroups.com
Hola Jordi,

te recomiendo este articulo de Rodrigo Corral donde comenta que según su punto de vista no se puede hacer Scrum sin utilizar las buenas prácticas técnicas:

http://geeks.ms/blogs/rcorral/archive/2009/03/05/191-es-posible-scrum-ignorando-las-buenas-pr-225-cticas.aspx

Un saludo,

2009/3/12 Jordi Pradel <jordi....@agilogy.com>



--
Vicenç García
http://devnettips.blogspot.com

Juanan

unread,
Mar 12, 2009, 1:43:46 PM3/12/09
to agile-spain
Hola Jordi,

Yo creo las buenas prácticas de programación son necesarias en
cualquier proyecto de software: CI, TDD , Refactoring, etc... son
prácticas que todos los equipos deberian intentar adoptar, incluso por
delante de cualquier metodología si me apuras.

Aquí te dejo un link interesante que habla del tema de Scrum y XP:
http://geeks.ms/blogs/rcorral/archive/2009/03/05/191-es-posible-scrum-ignorando-las-buenas-pr-225-cticas.aspx

Y te dejo un link al libro de Henrik Kniberg, que fue mi toma de
contacto con el mundo de Scrum y que explica un ejemplo real de
integración de XP con Scrum (muy interesante):
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

Un saludo,
> [1] Mike Cohn, An overview of Scrum, 2002 (descargable desdehttp://www.mountaingoatsoftware.com/presentations)

Hadi Hariri

unread,
Mar 12, 2009, 2:38:55 PM3/12/09
to agile...@googlegroups.com
> 1) Refactoring, Test Driven Development, Sustainable pace, Team code
> ownership, Coding standard, Simple design y Continuous integration son
> técnicas adicionales a Scrum pero totalmente en sintonía con él, que
> se adaptan sin dificultades. Creo que todas son bastante
> imprescindibles.
>

Jordi, todos estos son prácticas que contribuyen a agilizar (como dicen en
inglés...no pun intended) la adaptación a cambios, uno de los aspectos
fundamentales de metodologías ágiles.

> 3) Small releases: Aquí existe una primera posible diferencia.
> Schwaber y Beedle insisten en iteraciones de 4 semanas (por lo menos
> hasta estar familiarizado con Scrum) [4], mientras que XP recomienda

De nuevo, fundamental en cualquier metodología ágil. Iteraciones cortas
permiten controlar el estado y el progreso, tener interacción con los
"stakeholders" (lo siento no conozco la palabra en castellano) y tomar las
acciones necesarias. Cuanto es la duración ya es cuestión de cómo funciona
mejor tu proyecto y tu equipo. Personalmente , a menos que sea una primera
iteración donde se hace más énfasis en aspectos como infraestructura, etc.,
creo que 1 semana es demasiada corta. Nosotros normalmente hacemos
iteraciones de 2 semanas.

> ¿Qué opináis? ¿Alguna experiencia en proyectos dónde hayáis integrado
> Scrum y XP que os interese comentar? ¿Qué otras técnicas usáis para
> complementar Scrum?

Hay muchas similitudes y como has visto una de las cosas que queda fuera un
poco es el aspecto de pair programming. Yo he hecho Pair Programming en
varias ocasiones y he de decir que creo que es muy productivo y algunos de
los mejores códigos que he escrito ha sido de esta forma. Pero PP solo
funciona cuando tienes a dos personas al mismo nivel o similar. De lo
contrario se convierte en una clase de formación.

Lo importante de todo esto es que se aplique lo que funciona para cada
uno/equipo y dejar fuera lo que no funciona. Eso es uno de los aspectos
fundamentales de cualquier práctica ágil. No tienes que tener la idea de que
si no aplicas los X puntos de XP ya no vale. No es así.

José Manuel Beas

unread,
Mar 12, 2009, 3:51:48 PM3/12/09
to agile...@googlegroups.com
Guau, Jordi, estupendo resumen (creo que algo te plagiaré para la presentación-resumen-brevísima que estoy preparando).

En la lista latinoamericana "laasd", Agustín Villena (chileno para más señas) hace muy poco nos explicó una experiencia muy interesante en la que introducían algo entre XP-Scrum-... y cuyos resultados indican que (sin ser Scrum o XP "canónicos"), sí funcionaron.

Os remito al "thread" en dicha lista:
http://tech.groups.yahoo.com/group/laasd/message/1280

Sólo un apunte más. Quizás podrías ampliar un poco hablando de los principios comunes en XP, Scrum y Lean y que, en todos los casos, llevan a que es vital la comunicación dentro del equipo y la inclusión del cliente dentro del mismo, y al desarrollo por pequeños y frecuentes incrementos para poder reaccionar y adaptarse cuanto antes. (Seguramente los estudiosos podrán explicar todo lo que tienen en común mucho mejor, pero creo que es innegable que existe una raiz común entre todos). En mi opinión, si conocemos los principios en los que se basan estos "marcos de trabajo", seguramente estaremos más preparados para adaptar nuestro proceso de desarrollo a nuestra realidad (siempre cambiante).

Un saludo,
Jose Manuel Beas

http://www.agile-spain.com
http://jmbeas.blogspot.com



2009/3/12 Jordi Pradel <jordi....@agilogy.com>

Joserra

unread,
Mar 12, 2009, 5:06:12 PM3/12/09
to agile-spain
Yo creo que hay un punto en que es más facil introducir Scrum de
manera radical en una organización. Al final no tengo duda en que hay
que terminar haciendo las prácticas de XP más ingenieriles para hacer
bien el SCrum, como bien te dan la referencia de Rodrigo Corral
anteriormente.
La adopción de Scrum en un equipo de perfil medio es mucho más
sencilla que XP. Desde ahí, y desde el mismo momento, puedes ir
introduciendo las técnicas paulatinamente, que requieren mucho más
tiempo de formación del equipo. Con lo que enseguida obtienes algunos
beneficios de las metodologías ágiles (principalmente la entrega
constante de valor al cliente y la comunicación/afianzamietno del
equipo). Y poco a poco técnicamente el equipo mejora por que se pone
unos retos que debe cumplir con una serie de ténicas a aprender e
implantar (integración continua, TDD,...).

Al menos este es mi enfoque en la implantación en nuestros equipos.
Introducir XP paulatinamente lo veo muy complicado. Scrum "solo", se
quedaría cojo. Scrum como cambio radical, y técnicas de XP paulatinas,
es mi apuesta ;)


On Mar 12, 8:51 pm, José Manuel Beas <jose.m.b...@gmail.com> wrote:
> Guau, Jordi, estupendo resumen (creo que algo te plagiaré para la
> presentación-resumen-brevísima que estoy preparando).
>
> En la lista latinoamericana "laasd", Agustín Villena (chileno para más
> señas) hace muy poco nos explicó una experiencia muy interesante en la que
> introducían algo entre XP-Scrum-... y cuyos resultados indican que (sin ser
> Scrum o XP "canónicos"), sí funcionaron.
>
> Os remito al "thread" en dicha lista:http://tech.groups.yahoo.com/group/laasd/message/1280
>
> Sólo un apunte más. Quizás podrías ampliar un poco hablando de los
> principios comunes en XP, Scrum y Lean y que, en todos los casos, llevan a
> que es vital la comunicación dentro del equipo y la inclusión del cliente
> dentro del mismo, y al desarrollo por pequeños y frecuentes incrementos para
> poder reaccionar y adaptarse cuanto antes. (Seguramente los estudiosos
> podrán explicar todo lo que tienen en común mucho mejor, pero creo que es
> innegable que existe una raiz común entre todos). En mi opinión, si
> conocemos los principios en los que se basan estos "marcos de trabajo",
> seguramente estaremos más preparados para adaptar nuestro proceso de
> desarrollo a nuestra realidad (siempre cambiante).
>
> Un saludo,
> Jose Manuel Beas
>
> http://www.agile-spain.comhttp://jmbeas.blogspot.com
>
> 2009/3/12 Jordi Pradel <jordi.pra...@agilogy.com>
Message has been deleted
Message has been deleted

Alfredo Casado

unread,
Mar 12, 2009, 6:21:32 PM3/12/09
to agile...@googlegroups.com
Hola a todos,

soy nuevo por aqui, mi nombre es Alfredo Casado, os dejo mi blog donde basicamente estoy intentando contar paso a paso nuestra experiencia con Scrum: http://weblogs.javahispano.org/artesanodeprimera/ , todavía no he llegado a la parte de aplicación de practicas de XP pero ire escribiendo como las utilizamos.

Coincido con lo que decis muchos, Scrum sin XP se queda cojo, llevamos practicamente un año aplicando scrum+(casi)xp y en mi opinión son totalmente complementarios y necesitan el uno del otro. Para nosotros tecnicas como las pruebas unitarias o la integración continua son fundamentales, de echo me podría plantear cambiar scrum por otro modelo de gestión pero jamas me plantearía dejar de hacer pruebas unitarias o CI si quiero producir software de calidad.

El problema es que por lo general Scrum es más facil de aplicar que las tecnicas de XP, esto nos puede llevar a equipos que practican Scrum pero no aplican ninguna de las tecnicas más ingenieriles de xp por su dificultad o su alto coste inicial (en tiempo de formación y adaptación), en mi opinión esto es un grave problema que puede hacer que en muchas organizaciones se tome el camino facil y se haga un desarrollo agil "a medias" que termine creando una opinión generalizada de que el modelo agil no funciona.

Al hilo de esta discusión me parece muy interesante este articulo:

http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html

Y esta noticia en infoQ donde se discutia el articulo anterior y los peligros de adoptar el camino facil.

http://www.infoq.com/news/2009/02/whole-enchilada-and-context

Un Saludo,

Alfredo Casado Bernardez


El 12 de marzo de 2009 22:49, Gemma <gemma....@gmail.com> escribió:

Hola,

Nosotros también hacemos prácticas de Scrum + de XP.
Comparto la opinión que sólo Scrum se queda cojo, y que la parte de
gestión de proyectos de XP es muy parecida a Scrum.
Yo creo que las 5 prácticas de XP que mejor complementan a Scrum
serían TDD, integración continua, diseño simple, refactoring y pair
programming. Aunque añadiría coding standard, collective ownership,
etc etc y ya las pondría todas, jeje!

En mi caso apuesto por la implantación que quiera hacer el equipo, que
acostumbra a ser paulatina para todo. La mayoría de equipos en los que
he ayudado a implantar prácticas ágiles no conocían Scrum ni XP.
Entonces ha sido mejor que quizá el primer sprint no hagan daily
meetings si no lo ven claro, o no midan la velocidad si no entienden
el porqué... acaba ocurriendo que de iteración a iteración se dan
cuenta por si mismos del valor de las prácticas y las acaban
incorporando.

Jordi, yo lo que sí intento evitar a toda costa es imponer prácticas a
los equipos. Eso por sí mismo ya sería contrario a Agile. Lo mejor es
dejar a los equipos que aprendan por si mismos y que cada uno haga
agile un poco a su manera, esa es la gracia de agile  ;-)  En mi
experiencia de esta forma se acaba aplicando la mayoría de prácticas y
es la única forma que te asegura que se han comprendido bien. Por
mucha formación que se de, o libros que se lean, las personas nos
creemos las cosas cuando las vivimos  :-)

Espero haberte respondido algo.

Saludos,
   Gemma



José Manuel Beas

unread,
Mar 12, 2009, 7:00:06 PM3/12/09
to agile...@googlegroups.com
Hola,

Permitidme que conteste a Alfredo y Gemma a la vez porque ambos han dicho cosas con sentido y que, más o menos, yo he vivido (eso sí, desde el fracaso).


2009/3/12 Alfredo Casado <casado....@gmail.com>


El problema es que por lo general Scrum es más facil de aplicar que las tecnicas de XP, esto nos puede llevar a equipos que practican Scrum pero no aplican ninguna de las tecnicas más ingenieriles de xp por su dificultad o su alto coste inicial (en tiempo de formación y adaptación), en mi opinión esto es un grave problema que puede hacer que en muchas organizaciones se tome el camino facil y se haga un desarrollo agil "a medias" que termine creando una opinión generalizada de que el modelo agil no funciona.

Coraje. No sé por qué, pero hoy ya he utilizado esta palabra varias veces. Creo que en la mochila de todo agilista (convencido u obligado por las circunstancias) debe estar el coraje. Scrum quizás sea más fácil porque hay más gente que lo explica y, sobre todo, porque hay un diagrama de flujo que nos hace sentirnos más seguros para saber dónde estamos en cada momento. XP es para "soldados de hierro" y no todos somos así... :-)

Las organizaciones que toman el camino fácil y hacen desarrollo ágil "a medias" no han tenido el coraje necesario (como organización). Puede que se tengan ganas de hacer las cosas bien, pero con las ganas no es suficiente: hay que tener coraje. Un bombero es muy valiente cuando se mete entre las llamas y salva a una persona, pero una madre soltera tiene mucho coraje cuando se levanta TODAS las mañanas muy temprano para arreglar a su hijo, darle el desayuno, vestirse ella, dejar al niño en el cole, ir ella al trabajo...

Hacer agilismo no quiere decir que trabajemos menos o que dejemos de hacer lo que no nos gusta. Quiere decir que hacemos lo que tenemos que hacer EN CADA MOMENTO y que no hacemos algo que no sea necesario hacer aún. Y esto requiere disciplina (que es lo que nos viene a dar Scrum) y coraje (que es lo que nos viene a exigir XP).

(Vaya, tanta metáfora para esto, ¿verdad?)

 

El 12 de marzo de 2009 22:49, Gemma <gemma....@gmail.com> escribió:


Jordi, yo lo que sí intento evitar a toda costa es imponer prácticas a
los equipos. Eso por sí mismo ya sería contrario a Agile. Lo mejor es
dejar a los equipos que aprendan por si mismos y que cada uno haga
agile un poco a su manera, esa es la gracia de agile  ;-)  En mi
experiencia de esta forma se acaba aplicando la mayoría de prácticas y
es la única forma que te asegura que se han comprendido bien. Por
mucha formación que se de, o libros que se lean, las personas nos
creemos las cosas cuando las vivimos  :-)


Pero dejar que sea el equipo el que vaya adquiriendo las buenas costumbres es como educar a un hijo. (Perdonad los que no gustéis de los paternalismos, pero es que me parece la metáfora más adecuada). Los padres pueden esperar que sus hijos se comporten bien en la mesa, pero lo cierto es que deben enseñarles a utilizar los cubiertos, de lo contrario, lo más probable es que coman con las manos toda la vida. Hay niños que adquieren el hábito con más facilidad que otros y no siempre tiene que ver con la destreza, cariño, rigor (o lo que sea) que empleen los padres para enseñarles (¿debería decir adiestrarles?). Hay veces que los niños son más díscolos y hay que castigarles para que sepan cuáles no son las conductas aceptables.

Llevando la metáfora al desarrollo de software. No siempre es posible que los equipos vayan adquiriendo las buenas prácticas  por sí solos porque frecuentemente las buenas prácticas requieren coraje, y no todos están (estamos) dispuestos a tenerlo. Hay veces que hay que forzarles a realizar el trabajo según otros criterios que no son con los que ellos se sienten cómodos.


Bueno, ya está. No más metáforas por hoy (son las 23:59)

Un saludo,
JMB

Vicenç Garcia

unread,
Mar 12, 2009, 8:25:31 PM3/12/09
to agile...@googlegroups.com
Hola buenas,
 
respondo en dos sentidos. Primero a José Manuel por ser el último. Yo creo que no hay que forzar nunca al equipo. Como Scrum Master has de intentar hacer ver al equipo la buena manera de trabajar, o que el equipo vea por si mismo como se trabaja mejor pero nunca forzar. Y hay prácticas en las que seguro que no tienes problemas. Quien ha hecho alguna vez algun merge de código a mano, verá que la integración continua es una gozada. Quien ha estado buceando por su código en busca de un error verá que tener test unitarios es vital. Quen ha estado bucenado por el código de otro verá que utilizar coding standard es maravilloso. Y así para todas las prácticas.
 
Y en cuanto a utilizar Scrum y XP a la vez, yo creo que se complementan tan bien que no pueden vivir uno sin el otro. Si os leeis el libro de Kniberg que comentaba Juan Antonio, el autor dice que él a lo único que no renunciaria ( y és un libro sobre scrum ) és al TDD. Si quieres entregar valor al cliente tienes que codificar bien. No puedes entregar continuamente valor al cliente si tu código es una maraña, no encuentras rápidamente el error, etc.
 
Un saludo,
 
Vicenç

 

José Manuel Beas

unread,
Mar 12, 2009, 8:38:44 PM3/12/09
to agile...@googlegroups.com


2009/3/13 Vicenç Garcia <vincen...@gmail.com>

Hola buenas,
 
respondo en dos sentidos. Primero a José Manuel por ser el último. Yo creo que no hay que forzar nunca al equipo. Como Scrum Master has de intentar hacer ver al equipo la buena manera de trabajar, o que el equipo vea por si mismo como se trabaja mejor pero nunca forzar. Y hay prácticas en las que seguro que no tienes problemas. Quien ha hecho alguna vez algun merge de código a mano, verá que la integración continua es una gozada. Quien ha estado buceando por su código en busca de un error verá que tener test unitarios es vital. Quen ha estado bucenado por el código de otro verá que utilizar coding standard es maravilloso. Y así para todas las prácticas.

Sí, pero cuando se trata de que el código no es mío sino de todos... o que en una retrospectiva (o incluso un daily stand-up) hay que ser honestos... ¡ay! Ya no estamos hablando de dónde ponemos las llaves de abrir y cerrar bloque, sino de algo que requiere exponer tus defectos en público... quizás ahí no todo el mundo se sienta tan a gusto y frente a la amenaza suele haber resistencia. Por eso hay veces que hay que, con cariño, castigar al niño para que aprenda. Cuando el niño ya sabe comer con el tenedor, a pesar de su resistencia inicial, luego ya no es capaz de comer con los dedos porque le resulta molesto estar pringado. Vamos, que cuando el equipo es forzado a exponer su código a sus compañeros y explicar qué está haciendo día a día, al principio no le hará ni pizca de gracia, pero con el paso del tiempo se dará cuenta de que ha salido ganando con el cambio y ya no podrá dejar de hacerlo. (Pero llegar hasta este punto cuesta, claro).

 
Y en cuanto a utilizar Scrum y XP a la vez, yo creo que se complementan tan bien que no pueden vivir uno sin el otro. Si os leeis el libro de Kniberg que comentaba Juan Antonio, el autor dice que él a lo único que no renunciaria ( y és un libro sobre scrum ) és al TDD. Si quieres entregar valor al cliente tienes que codificar bien. No puedes entregar continuamente valor al cliente si tu código es una maraña, no encuentras rápidamente el error, etc.
 

(Entendiendo por TDD que haces red-green-refactor y no sólo red-green o incluso green).

Juanan

unread,
Mar 13, 2009, 4:07:03 AM3/13/09
to agile-spain
Buenos días,

Por mi experiencia, dejar que el equipo adopte las prácticas por si
mismo no acaba de funcionar del todo. Un poco es lo que comenta José
Manuel, tu intentas educar, sugerir, hacer ver que la adopción de las
prácticas será una cosa positiva, pero a la larga (por lo menos en mi
caso) si no eres un poco riguroso nadie hace los tests unitarios,
nadie hace refactoring , nadie hace caso de la guía de estilo...
Seguro que depende mucho de las personas que formen tu equipo, de su
nivel y del compromiso o grado de motivación que tengan, pero por
desgracia es lo que yo me he encontrado.

On 13 mar, 01:38, José Manuel Beas <jose.m.b...@gmail.com> wrote:
> 2009/3/13 Vicenç Garcia <vincentred...@gmail.com>

Ricardo Roldán

unread,
Mar 13, 2009, 8:19:52 AM3/13/09
to agile...@googlegroups.com
Hola,

En mi opinión por encima de las prácticas Agiles,  XP  o Scrum están los principios.
Propongo una traducción colectiva  ...

"The Manifesto for Software Craftsmanship"

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

  • Not only working software, but also well-crafted software
  • Not only responding to change, but also steadily adding value
  • Not only individuals and interactions, but also a community of professionals
  • Not only customer collaboration, but also productive partnerships
That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

http://parlezuml.com/softwarecraftsmanship/links.htm


Me ha gustado mucho la frase de Gemma Hornos:

 "Por muchos libros que se lean, las personas nos creemos las cosas cuando las vivimos".

Saludos,
Ricardo


2009/3/13 Juanan <juana...@gmail.com>



--
La diversidad y la independencia son fundamentales porque las mejores decisiones colectivas son producto del desacuerdo y del enfrentamiento, y no del consenso y del compromiso (Surowiecki)

Martin Perez

unread,
Mar 13, 2009, 8:44:07 AM3/13/09
to agile...@googlegroups.com
Me ha gustado mucho esta última aportación de Ricardo, y las ideas en general que se han comentado.

Sea como sea, me imagino que las opiniones de cada uno dependen mucho de los equipos con los que han trabajado, ¿no? Hay gente que por naturaleza les encanta seguir las buenas prácticas, y otras personas que simplemente pasan mucho más de todo quizás porque no les gusta tanto su trabajo.

Tener un equipo con sólo elementos del primer grupo tiene que ser una maravilla. En mi caso particular siempre me ha tocado sin embargo trabajar con equipos donde los primeros son un 20% y los segundos un 80% por poner una proporción. Por eso yo abogo por el ser riguroso. Las revisiones de código (y no sólo de código sino de funcionalidad, diseño, arquitectura) y la programación (diseño, arquitectura) en parejas creo que ayudan muchísimo aquí. Actitudes "perras" como no permitir subir código al que no le acompañen tests unitarios, o revertir los cambios ante cualquier error en la build, en mi opinión ayudan a forzar algo más al equipo a adoptar el agilismo.

Martin


2009/3/13 Ricardo Roldán <roldan....@gmail.com>

José Manuel Beas

unread,
Mar 13, 2009, 9:06:19 AM3/13/09
to agile...@googlegroups.com


2009/3/13 Martin Perez <mpe...@gmail.com>

Me ha gustado mucho esta última aportación de Ricardo, y las ideas en general que se han comentado.

Pues ya podéis ir echando una firmita... :-)
http://manifesto.softwarecraftsmanship.org

(De todos modos, recordad también el lado derecho, no sólo el izquierdo) :-)


Sea como sea, me imagino que las opiniones de cada uno dependen mucho de los equipos con los que han trabajado, ¿no? Hay gente que por naturaleza les encanta seguir las buenas prácticas, y otras personas que simplemente pasan mucho más de todo quizás porque no les gusta tanto su trabajo.

Tener un equipo con sólo elementos del primer grupo tiene que ser una maravilla. En mi caso particular siempre me ha tocado sin embargo trabajar con equipos donde los primeros son un 20% y los segundos un 80% por poner una proporción. Por eso yo abogo por el ser riguroso. Las revisiones de código (y no sólo de código sino de funcionalidad, diseño, arquitectura) y la programación (diseño, arquitectura) en parejas creo que ayudan muchísimo aquí. Actitudes "perras" como no permitir subir código al que no le acompañen tests unitarios, o revertir los cambios ante cualquier error en la build, en mi opinión ayudan a forzar algo más al equipo a adoptar el agilismo.

O a buscarte enemigos dentro de tu propio equipo. :(

Homo homini lupus!

Vicenç Garcia

unread,
Mar 13, 2009, 9:19:53 AM3/13/09
to agile...@googlegroups.com
Yo creo que forzar las cosas puede ser contraproducente. Siguiendo la analogía del padre-hijo, si tu obligas al hijo a hacer algo, quizá te sale bien, pero se te puede rebotar y salirte el tiro por la culata.

Creo que en la gran mayoria de los casos todo esto es por que no sabemos transmitir bien las bondades de lo que queremos que el equipo implante ( yo el primero ). Si todo el mundo dice que los tests unitarios són buenos y que la integración continua es genial, deberiamos ser capaces de transmitir esta idea, y no que quede como un capricho nuestro.


2009/3/13 José Manuel Beas <jose....@gmail.com>

Juanan

unread,
Mar 13, 2009, 9:38:59 AM3/13/09
to agile-spain
Bueno tampoco se trata de forzar a nadie. Está claro que si el equipo
no quiere trabajar de una determinada manera no lo va hacer, y si
intentas forzarlo sólo vas a conseguir acabar a malas. Pero creo que
tampoco basta con buenas palabras y con predicar las bondades de tal o
cual práctica, porque la inercia de hacer el mínimo esfuerzo es
fuerte.

Volviendo al símil de la educación de los hijos: a los hijos hay que
educarlos y la mayoría de las veces este proceso implica hacer que el
niño/a haga cosas que no quiere hacer. No basta con decirle que no se
meta las cosas del suelo en la boca, si lo sigue haciendo hay que
castigarle!


On 13 mar, 14:19, Vicenç Garcia <vincentred...@gmail.com> wrote:
> Yo creo que forzar las cosas puede ser contraproducente. Siguiendo la
> analogía del padre-hijo, si tu obligas al hijo a hacer algo, quizá te sale
> bien, pero se te puede rebotar y salirte el tiro por la culata.
>
> Creo que en la gran mayoria de los casos todo esto es por que no sabemos
> transmitir bien las bondades de lo que queremos que el equipo implante ( yo
> el primero ). Si todo el mundo dice que los tests unitarios són buenos y que
> la integración continua es genial, deberiamos ser capaces de transmitir esta
> idea, y no que quede como un capricho nuestro.
>
> 2009/3/13 José Manuel Beas <jose.m.b...@gmail.com>
>
>
>
>
>
> > 2009/3/13 Martin Perez <mper...@gmail.com>

Juan Carlos Quijano Abad

unread,
Mar 13, 2009, 9:41:00 AM3/13/09
to agile...@googlegroups.com
Hola, buenas tardes.

Primero me presento, soy Juan Quijano y es un honor poder compartir y leer esta lista de correo.

En mi caso particular, he podido implantar un primer paso de SCRUM en dos proyectos, y digo un primer paso porque solo he llegado hasta cierto punto sin poder implementar toda la tecnología en el desarrollo.

Al ser un equipo pequeño lo primero que utilicé fué la técnica del "pesado". Es decir, revisaba todos los días que la gente no se saltara las reglas del check-in y asignara el trabajo a la tarea correspondiente. Mientras me encargaba yo de abrir, poner porcentajes y cerrar los workitem.

Junto con esto primero implanté las reuniones diarias (scrum daily) de forma inapelable. Y es curioso lo que me costó que simplemente contestaran a las tres preguntas y no se fueran por los cerros de Ubeda. Al final las reuniones diarias se hicierón parte integrante del devenir diario en el curro junto con el ir a desayunar, a comer o a fumarse un cigarro.

A continuación, en el segundo sprint, incluí el Sprint Planning meeting, y los desarrolladores se mostraron entusiamados con la idea de valorar y crear los sprint items desde el product baklog (que yo mantenia en conjunción con el cliente) y valorar el trabajo necesario para su conjunción. Costó más el reparto de las tareas porque no estaban acostumbrados a ser responsables de sus propias valoraciones y dudaban mucho en auto asignarselas, pero al final se convencierón que era muy fructifero.

Aprovechando el inicio de este sprint, les enseñe a gestionar sus propios workitem en el Visual Studio y me dedique el resto del sprint a verificar y ayudar a que los desarrolladores llevaran correctametne dicha gestión. Que, además, más simple imposible. Aquí la excusa que utilicé cuando necesitaba "presionar" a alguno que se le olvidaba demasiado el abrir y cerrar los workitem era que "no me van a salir las métricas y las tuyas van a salir raras... y lo voy a tener que corregir yo". También me cansé de explicar que el objetivo no era ver la productividad de cada desarrollador, si no mantener el proyecto dentro de los cauces que en cada inicio del sprint decidiamos entre todos.

Por último se me acabo el proyecto, que era muy pequeñito, y me quede con las ganas de introducir el resto de la metodología.

Sobre las pruebas unitarias, tengo el mismo problema que los demás. Todos los desarrolladores ejercen una profunda resistencia a "programar el doble", por mucho que les diga que no es así. Y, aquí entono el "mea culpa", al no tener una buena base teorica ni práctica sobre el tema, no puedo utilizar el método del ejemplo para convencerlos.

--
Un saludo
Juan Quijano

Vicenç Garcia

unread,
Mar 13, 2009, 9:52:08 AM3/13/09
to agile...@googlegroups.com
Si, pero a un niño no le puedes dejar que se ponga algo en la boca y le dé un jamacuco y después decirle: ves, esto te pasa por ponerte esto en la boca. A un grupo de desarrollo, si que le puedes hacer esto hasta cierto punto :P

Obviamente hay casos en que seguramente no queda otra, pero creo que en general hay que intentar ser mucho más dialogante y que, en general, lo somos poco ( herencia de querer ser Project Manager en lugar de Scrum Master ).

Juan, me ha encantado tu introducción a Scrum en tu grupo de desarrollo!!

Un saludo,

2009/3/13 Juan Carlos Quijano Abad <juancarl...@gmail.com>

Ricardo Roldán

unread,
Mar 13, 2009, 10:07:19 AM3/13/09
to agile...@googlegroups.com
Hola  Juan,

Muchas gracias por compartir esta aventura de implantar SCRUM.

Sobre las pruebas unitarias puedes probar TDD. Programar la prueba antes que el código.

Si puedes con SCRUM podrás con TDD.

http://c2.com/cgi/wiki?TestDrivenDevelopment

¡¡ Coraje !!

Saludos,
Ricardo



2009/3/13 Juan Carlos Quijano Abad <juancarl...@gmail.com>
Hola, buenas tardes.

Jordi Pradel

unread,
Mar 13, 2009, 2:20:47 PM3/13/09
to agile-spain
Vicenç, Juanan,

Gracias por las referencias adicionales. ¡Ya he empezado a leer Scrum
And XP From The Trenches!

No dudo que para aplicar Scrum con éxito son necesarias otras buenas
prácticas. En referencia a esto me encanta la cita de Schwaber que nos
da José Manuel Beas en otro post [1][2].

Es más, creo que la pregunta interesante no es si Scrum puede
funcionar con un equipo de idiotas (por parafresear a Schwaber o a su
traducción en navegapolis). Sino, ¿Qué metodología puede funcionar con
un equipo de idiotas? Y para mi solo hay una respuesta: Ninguna. La
ventaja real de Scrum (y no quiero pasarme de listillo corrigiendo a
Schwaber) es que, si se aplica bién, expondrá el problema mucho antes
que otras metodologías. En cuanto a los primeros días de la primera
iteración (o, a lo peor, al final de la primera iteración) solo tengas
un incremento... de mierda (Schwaber dixit), sabrás que no vas a
ninguna parte.

Pero creo sinceramente que se puede hacer buen software sin aplicar
todas las técnicas de XP. De hecho, reconozco que incluso las técnicas
que mas me gustan de XP pueden ser prescindibles (y que aún así el
equipo funcione). Es posible tener éxito sin hacer Test Driven
Development (por ejemplo, escribiendo pruebas a posteriori), es
posible tener éxito sin aplicar integración contínua (por ejemplo,
haciendo integración frecuente, aunque no contínua), etc.

Mi duda era como funcionan esas técnicas XP en proyectos Scrum. Por
ello los enlaces que me proporcionáis, muy especialmente el libro,
pueden ser muy interesantes.

Saludos,
Jordi

[1] http://groups.google.es/group/agile-spain/browse_thread/thread/157fdab89b9504fa?hl=es
[2] http://www.navegapolis.net/content/view/850/62/

Jordi Pradel

unread,
Mar 13, 2009, 2:31:12 PM3/13/09
to agile-spain
Hola,

Disculpad que vaya contestando uno por uno. Muchas gracias a todos por
las respuestas y comentarios.

> De nuevo, fundamental en cualquier metodología ágil. Iteraciones cortas
> permiten controlar el estado y el progreso, tener interacción con los
> "stakeholders" (lo siento no conozco la palabra en castellano) y tomar las
> acciones necesarias. Cuanto es la duración ya es cuestión de cómo funciona
> mejor tu proyecto y tu equipo. Personalmente , a menos que sea una primera
> iteración donde se hace más énfasis en aspectos como infraestructura, etc.,
> creo que 1 semana es demasiada corta. Nosotros normalmente hacemos
> iteraciones de 2 semanas.

Estoy de acuerdo. En cada proyecto habrá determinadas características
que nos empujarán a iteraciones más cortas (pongamos 2 semanas) o más
largas (digamos 4 semanas). ¿Alguien ha trabajado con iteraciones tan
cortas como las que propone XP de 1 semana?
Solo un detalle: Las iteraciones deberían ser de la misma duración
durante todo el proyecto.

> Hay muchas similitudes y como has visto una de las cosas que queda fuera un
> poco es el aspecto de pair programming. Yo he hecho Pair Programming en
> varias ocasiones y he de decir que creo que es muy productivo y algunos de
> los mejores códigos que he escrito ha sido de esta forma. Pero PP solo
> funciona cuando tienes a dos personas al mismo nivel o similar. De lo
> contrario se convierte en una clase de formación.

Desde mi punto de vista Pair Programming debería ser especialmente
útil cuando el nivel de las dos personas NO es el mismo. Aunque
reconozco que al más experto le dará pereza...

> Lo importante de todo esto es que se aplique lo que funciona para cada
> uno/equipo y dejar fuera lo que no funciona. Eso es uno de los aspectos
> fundamentales de cualquier práctica ágil. No tienes que tener la idea de que
> si no aplicas los X puntos de XP ya no vale. No es así.

Ok. Mi post venía un poco por aquí en cuanto a XP. El libro canónico
de XP [1] hace bastante hincapié en aplicar todas las prácticas de XP
tal cual. Los autores de XP parecen muy interesados en que no elijamos
solo algunas de sus prácticas porque, según ellos, no funcionan. Como
muchos de los que comentáis algo en este foro, esto no es algo que yo
perciba como dichos autores. También pienso que es interesante aplicar
algunas y quizás otras no tanto.

[1] Kent Beck, Extreme Programming Explained: Embrace Change, Addison-
Wesley, 2001 (http://books.google.com/books?id=G8EL4H4vf7UC)

Jordi Pradel

unread,
Mar 13, 2009, 2:37:35 PM3/13/09
to agile-spain
> Guau, Jordi, estupendo resumen (creo que algo te plagiaré para la
> presentación-resumen-brevísima que estoy preparando).

¡Muchas gracias!

> ...
> Os remito al "thread" en dicha lista:http://tech.groups.yahoo.com/group/laasd/message/1280

De nuevo, gracias. Lo añado a mi lista de lectura.

> Sólo un apunte más. Quizás podrías ampliar un poco hablando de los
> principios comunes en XP, Scrum y Lean y que, en todos los casos, llevan a
> que es vital la comunicación dentro del equipo y la inclusión del cliente
> dentro del mismo, y al desarrollo por pequeños y frecuentes incrementos para
> poder reaccionar y adaptarse cuanto antes. (Seguramente los estudiosos
> podrán explicar todo lo que tienen en común mucho mejor, pero creo que es
> innegable que existe una raiz común entre todos). En mi opinión, si
> conocemos los principios en los que se basan estos "marcos de trabajo",
> seguramente estaremos más preparados para adaptar nuestro proceso de
> desarrollo a nuestra realidad (siempre cambiante).

Ok. Tenemos una raíz común muy clara: El Manifiesto Ágil [1] ofrece 4
valores y 12 principios muy claros. Y hasta hace poco [2][3] tenía
pocas críticas / revisiones dentro de la comunidad ágil.

[1] http://agilemanifesto.org/
[2] http://manifesto.softwarecraftsmanship.org/main: Robert C. Martin
y otros quieren elevar el listón del manifiesto ágil.
[2] http://www.infoq.com/news/2009/03/software_craftsmanship: Artículo
de opinión sobre el Software Craftmanship Manifesto

Jordi Pradel

unread,
Mar 13, 2009, 2:52:02 PM3/13/09
to agile-spain
Hola Gemma (y a todos, claro)

Estamos bastante de acuerdo, pero hay una parte que sí me sorprende:
El tema de hacer opcionales los daily Scrum que das como ejemplo. No
se me hubiera pasado por la cabeza omitir ninguna de las reuniones de
Scrum en una implantación. Especialmente me sorprende que el equipo al
que ayudaste tuviera problemas con esa reunión, que, de hecho, ocupa
tan poco tiempo. En mi experiencia es uno de los cambios culturales
que, por repercutir de inmediato en resultados diarios, da más
visibilidad a "lo bueno" de Scrum. Quiero decir que encaja
especialmente con tu frase: "las personas nos creemos las cosas cuando
las vivimos", porque les hace vivir las ventajas de Scrum desde los
primeros días de la primera iteración.

En cuanto a imposiciones estoy totalmente de acuerdo. Quizás he tenido
la suerte de asesorar a equipos siempre bien predispuestos (con ganas
de aplicar cada una de las técnicas que les mencionaba) por lo menos
en cuanto a Scrum puro y duro. No impondría el cálculo de la
velocidad, de acuerdo. Tampoco el Planning Poker, por poner otro
ejemplo.

Sí me encuentro con mas reticencias con las técnicas ingenieriles
(como TDD o integración contínua). Pero cuando asesoro a un equipo a
implantar Scrum intento no ponerme en el lado de asesoramiento
arquitectónico/tecnológico, porque muchas veces ese equipo no tiene
ese problema y/o no me han llamado por esa razón.

En cuanto a XP (corazón inicial de este post), creo que ante
prescindiría de Pair Programming (porque me interesa muchas veces pero
no para escribir el 100% del código, probablemente), o de Continuous
Integration (porque hay ciertas dificultades técnicas para montar un
sistema de CI y se puede sustituir por Integración Frecuente) que de
Sustainable pace, Team code ownership o Coding standard. Claro que,
como matizas que las aplicarías todas... :)

Saludos,
Jordi

Jordi Pradel

unread,
Mar 13, 2009, 2:57:45 PM3/13/09
to agile-spain
> Sí, pero cuando se trata de que el código no es mío sino de todos... o que
> en una retrospectiva (o incluso un daily stand-up) hay que ser honestos...
> ¡ay! Ya no estamos hablando de dónde ponemos las llaves de abrir y cerrar
> bloque, sino de algo que requiere exponer tus defectos en público... quizás
> ahí no todo el mundo se sienta tan a gusto y frente a la amenaza suele haber
> resistencia.

Ok. Siguiendo con tu metáfora, lo que no vale es que el niño quiera
los premios (piruletas y paga mensual) pero sin las obligaciones. Y me
explico: Las metodologías ágiles suelen ser "simpáticas" con los
equipos de desarrollo: Te valoramos por encima que al proceso,
queremos que no trabajes 60 horas semanales, entendemos que no puedes
estimar algo y grabarlo a fuego porque las cosas cambian, etc. Ok,
pero todo esto no viene "gratis".

Si queremos todo esto tenemos que ser transparentes, por poner un
ejemplo. No se puede pedir al cliente que acepte que podemos
retrasarnos y tener que quitar algo del Product Backlog y después
esperar que no tenga feedback contínuo sobre qué estamos haciendo con
su dinero (nuestro tiempo). Creo que la clave es hacer entender a los
equipos que todas esas ventajas de aplicar metodologías ágiles tienen
un precio. Y si no ven las ventajas, explicarlas altas y claras,
claro.

Saludos,
Jordi

Jordi Pradel

unread,
Mar 13, 2009, 2:59:17 PM3/13/09
to agile-spain
Hola Ricardo,

He citado la misma fuente que tu antes de leer tu mensaje. Disculpad
pues que no haya mencionado este mensaje.

Saludos,
Jordi

Hadi Hariri

unread,
Mar 13, 2009, 4:20:29 PM3/13/09
to agile...@googlegroups.com
> no para escribir el 100% del código, probablemente), o de Continuous
> Integration (porque hay ciertas dificultades técnicas para montar un
> sistema de CI y se puede sustituir por Integración Frecuente) que de

Para mí, CI es cerca de lo que clasificaría como sagrado.

Hadi Hariri

unread,
Mar 13, 2009, 4:20:29 PM3/13/09
to agile...@googlegroups.com
> Desde mi punto de vista Pair Programming debería ser especialmente
> útil cuando el nivel de las dos personas NO es el mismo. Aunque
> reconozco que al más experto le dará pereza...
>

Sin duda puede ser útil, pero en mi opinión no con el fin que se persigue
con PP. Es decir, sirve para que una persona aprende de otra, pero ese
aprendizaje es en una sola dirección, con lo cual se acoge más a formación.



> Ok. Mi post venía un poco por aquí en cuanto a XP. El libro canónico
> de XP [1] hace bastante hincapié en aplicar todas las prácticas de XP
> tal cual. Los autores de XP parecen muy interesados en que no elijamos

Pues honestamente no estoy de acuerdo. Una de las cosas que hace que las
metodologías ágiles funcionen mejor, es el ser pragmático.


Pedro Arnal Puente

unread,
Mar 13, 2009, 5:02:14 PM3/13/09
to agile...@googlegroups.com
Hola a todos

Saludos desde Barcelona... a ver si no me pierdo el próximo encuentro... :-(

Como este post parece que empieza a aglutinar unas cuantas cosas
diferentes, seré breve.

Sobre forzar o no forzar al equipo. El simil padre educando hijos
tiene un limite. En mi experiencia me he encontrado con un 20% de
gente muy buena que no sólo acepta lo que les propongas si ve valor,
sino que a veces debe ser hasta "contenido" (aquello de la casa por el
tejado), un 60% de actitudes escepticas pero receptivas (eligiendo
bien qué se va introduciendo siempre me han respondido estupendamente)
y un 20% de mezcla entre gente sin nada (de nada) de la capacidad o
motivacion necesaria y gente que directamente roza lo pasivo-agresivo
(todos de dificil recuperación normalmente).

Creo que llega un momento que si, tras poner de tu parte (como
scrummaster, jefe de equipo, proyecto, coach o lo que sea) todo lo
posible (dialogo, consensuar procesos, formación, etc.), no pones un
límite (revertir commits en repositorio, echar para atrás código
atroz, etc.) te quedas con un proceso a medias en las manos. Pides a
unas personas disciplina (que es la parte más dura) y profesionalidad
y a otras las tratas de forma "especial" y les dejas campar a sus
anchas o los apartas a un rincón.

Propongo como tema de debate como retirar de un equipo a estos
elementos (una vez queda claro que no son rehabilitables)... :-)

Acerca de elementos de XP mas o menos vitales... cada equipo y cada
proyecto tienen sus circunstancias. Ni TDD, ni CI, ni PP, ni otras son
sacrosantas (no hay nada sagrado, solo cosas que usas 99/100 ;-) ).
Como ejemplo, no hago TDD religiosamente, pero planifico muy bien que
tests preparar para que componentes y a que niveles, hace varios
proyectos que CI no me ha ofrecido nada (pero si la integración
frecuente), y PP... pocas veces pero bien escogidas (bueno, cuesta más
valorar el cuando en este caso)...

Aparte de las coincidencias Scrum/XP en cuanto a iteraciones,
planning, etc., el resto de los puntos de XP me parece como las
herramientas, parte de lo que hay que valorar, diseñar e ir adaptando
a cada momento.

Y eso con XP, con Lean, y con otros repertorios. Cualquier propuesta
metodológica monolítica me parece sospechosa (sospechosamete parecida
a un proceso en el mal sentido del término).

Propongo también para posteriores threads posibles aportaciones desde
otras lineas a Scrum... Lean, TOC, OODA/familia (aunque no sean
nativas del desarrollo), etc...

Bueno, creo que no he sido tan breve...

--
...To the (creative) destruction of what is!
--
http://agitadonorevuelto.omercenario.org

Jordi Pradel

unread,
Mar 16, 2009, 11:13:33 AM3/16/09
to agile-spain
> > Desde mi punto de vista Pair Programming debería ser especialmente
> > útil cuando el nivel de las dos personas NO es el mismo. Aunque
> > reconozco que al más experto le dará pereza...
> Sin duda puede ser útil, pero en mi opinión no con el fin que se persigue
> con PP. Es decir, sirve para que una persona aprende de otra, pero ese
> aprendizaje es en una sola dirección, con lo cual se acoge más a formación.

Entiendo lo que comentas y, aunque no creo que haga falta profundizar,
discrepo algo. Si PP consigue dotar de experiencia (no de formación
teórica) a un junior de un equipo Scrum, está elevando la velocidad
del equipo. A mí sí me parece una buena razón para aplicar PP. Por
otro lado, incluso aunque sean perfiles distintos, PP facilita el
Collective Code Ownership, por ejemplo. Pero como decía de entrada,
estoy de acuerdo que PP puede ser inadecuada para según qué equipos y
personalmente en la mayoría de ocasiones no la aplicaría al 100% del
tiempo de desarrollo.

> > Ok. Mi post venía un poco por aquí en cuanto a XP. El libro canónico
> > de XP [1] hace bastante hincapié en aplicar todas las prácticas de XP
> > tal cual. Los autores de XP parecen muy interesados en que no elijamos
> Pues honestamente no estoy de acuerdo. Una de las cosas que hace que las
> metodologías ágiles funcionen mejor, es el ser pragmático.

Ok, a eso me refería. Yo tampoco estoy de acuerdo en que XP sea todo o
nada. Precisamente comentaba que sus autores parecen bastante
"obsesionados" en que lo apliquemos 100% sin adaptarlo, por lo menos
inicialmente. Esa es la impresión que el libro que mencionaba me
transmitió a mí, por lo menos.

Hadi Hariri

unread,
Mar 16, 2009, 3:08:30 PM3/16/09
to agile...@googlegroups.com
> Ok, a eso me refería. Yo tampoco estoy de acuerdo en que XP sea todo o
> nada. Precisamente comentaba que sus autores parecen bastante
> "obsesionados" en que lo apliquemos 100% sin adaptarlo, por lo menos

Si, la obsesión no es bueno. Y justamente cosas como esto están pasando
ahora en craftsmanship etc, donde se está diciendo ya barbaridades.


Harald Messemer

unread,
Mar 17, 2009, 4:23:42 AM3/17/09
to agile...@googlegroups.com
Hola,

He seguido el hilo desde el principio y creo que para conciliar las
deferentes posturas, ayudaria de ver las aportaciones de las
diferentes metodologias como herramientas y variantes de herramientas
y escoger en funcion de las necesidades del proyecto, del equipo y de
los otros factores releavantes las herramientas que mejor encajen. He
leido un articulo interesante de Alistair Cockburn que se llama "one
methodology per project" donde machaca de buenas maneras este tema.

Un saludo,
Harald

PD: me parece que kent beck dijo que si lo quieres llamar XP tienes
que utilizar todos los elementos. No estas obligado, pero entonves no
lo llames XP. Igualmente creo que iba de broma porque ya se conocia
las discusiones de terminologia.

2009/3/16, Hadi Hariri <hadi....@gmail.com>:
--
Von meinen Mobilgerät aus gesendet
Message has been deleted
Message has been deleted

Alejandro Pérez García

unread,
Apr 8, 2009, 4:15:00 PM4/8/09
to agile...@googlegroups.com
Hola Gemma.

Creo que no viene mucho al hilo de este post, pero viendo que has trabajado con estos temas en Telefónica, me gustaría saber si tienes experiencia combinando Agile con ISO o CMMI.

Es decir, este es un tema que me interesa mucho, el ver si son compatibles, y cómo.

Normalmente veo que chocan mucho el tema de tener que dejar registros de todo (obligación de la ISO) con la pizara de Scrum, por ejemplo.


Saludos





2009/4/8 Gemma <gemma....@gmail.com>

Hola Jordi,

Disculpa que haya tardado tanto en responder. Me ha gustado mucho tu
post. Te comento el caso concreto de las Dailys.
En Telefónica I+D en estos momentos habrá unos 300 desarrolladores
utilizando métodos ágiles y creciendo :-)  . Empezamos la transición
hace unos dos años, y ha sido bastante gradual así que hay equipos que
llevan 2 años con prácticas de Scrum y XP pero también hay equipos que
llevan 1 mes. Bueno, hemos hecho una implantación gradual, empezaron
unos proyectos piloto, luego un departamento, luego una gerencia, una
dirección... luego la otra y así, jeje  (lo cuento porque creo q si no
lo hago queda muy raro, jeje).

Bueno, a lo que iba, yo en concreto habré ayudado a unos 15-20 equipos
a empezar con prácticas de Scrum, y algunos lo han llevado muy bien
desde el principio y otros no tanto. Quizá el ejemplo del daily
meeting es un ejemplo de la transición hacia Agile. En este caso en
concreto, sí que me he encontrado con equipos que han visto la Daily
Meeting como un punto de control, de que alguien iba a fiscalizar su
trabajo diariamente. Supongo que es normal, si por los pasillos de la
empresa oyes que los del proyecto fulanito estan con una "metodología"
nueva que les obliga a hacer reuniones diarias para ver cómo van, y
controlarles qué han hecho hoy etc. Entonces inicialmente son muy
escepticos. Creo que es un tema más de gestión del cambio. Luego,
cuando llevan un Sprint haciendo dailys son adictos y no quieren
dejarlo  ;-)   También está relacionado con eso de que nos creemos las
cosas cuando las vivimos: yo ya puedo insistir mucho en que las Dailys
son para la autoorganización del equipo, la sincronización, la
detección de impedimentos etc., que los equipos no lo van a entender
bien hasta que lo vivan y vean que no se está fiscalizando a nadie.

Supongo que en todo cambio siempre habrá los motivados, los "ni fu ni
fa" y los que se oponen... A mí los terceros me tienen negra!!!
jejeje  ;-)

Saludos,
   Gemma



--
Alejandro Pérez García
Socio fundador de Autentia y ww.adictosaltrabajo.com
(Formación, Consultoría, Desarrollo de sistemas transaccionales)
mailto:aleja...@autentia.com
Tel.: 655 99 11 75

Autentia Real Business Solutions S.L.
      "Soporte a Desarrollo"
http://www.autentia.com



Este mensaje, y en su caso cualquier fichero anexo al mismo, puede contener información confidencial y/o privilegiada, siendo para uso exclusivo del destinatario. Si Vd. no es el destinatario o lo ha recibido por error, por favor, informe inmediatamente al emisor y destrúyalo. Está estrictamente prohibido por la legislación vigente realizar sin autorización cualquier copia, revelación o distribución del contenido de este mensaje sin la autorización expresa del remitente. Las opiniones expresadas en este correo son las de su autor y no son, necesariamente, compartidas por Autentia Real Business Solutions S.L.

This e-mail, and in the case of any file annexed to it, may contain confidential and/or privileged information, and it is exclusively for the use of the addresses of the message. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden by current legislation. The points of view expressed in this e-mail are solely those of the author and may not necessarily be from, or supported by, Autentia Real Business Solutions S.L.

Jorge Uriarte Aretxaga

unread,
Apr 8, 2009, 4:22:44 PM4/8/09
to agile...@googlegroups.com
Normalmente veo que chocan mucho el tema de tener que dejar registros de todo (obligación de la ISO) con la pizara de Scrum, por ejemplo.
ay-ay-ay... ¿dónde pone que la pizarra debe quedar registrada? en qué estado? (antes del meeting?, durante?, diaria?, semanal?, dos por sprint?, ... )
 
Sin ánimo de polemizar, es que a veces nos ponemos la cuerda al cuello nosotros solitos...
 
_
Jorge

Xavier Quesada Allue

unread,
Apr 8, 2009, 4:34:08 PM4/8/09
to agile...@googlegroups.com
Alejandro,

Si pasan este thread a grupo-agiles, hay varias personas de Argentina (Diego Fontdevila es uno que me viene a la cabeza) que tienen empresas certificadas ISO y me dijeron que es 100% compatible con una implementacion ágil. No recuerdo que mencionara problemas con las pizarras, y a mi supongo que me lo habría dicho, sabiendo que soy fanático de ellas.

Por otro lado, respecto a Agil + CMMi, en el SEPG Europe 2009 va a haber una sesion de Hillel Glazer si mal no recuerdo (para los que no saben, el del Agile CMMI Blog y uno de los autores del famoso paper ese que andan enarbolando los del SEI ultimamente, diciendo que se puede ser CMMi y Ágil al mismo tiempo)

Date una vuelta por Praga y conocelo a Hillel y despues contanos.

Saludos,
Xavier

Visual Management Blog
http://tinyurl.com/visualmanagement

2009/4/8 Alejandro Pérez García <alejandr...@gmail.com>

Joserra

unread,
Apr 8, 2009, 4:42:37 PM4/8/09
to agile-spain
Me alegra ver lo que cuentas de Telefónica, sin duda le dará gran
visibilidad a muchas empresas todo el tema de ágiles, no?


On 8 abr, 21:47, Gemma <gemma.hor...@gmail.com> wrote:
> Hola Jordi,
>
> Disculpa que haya tardado tanto en responder. Me ha gustado mucho tu
> post. Te comento el caso concreto de las Dailys.
> En Telefónica I+D en estos momentos habrá unos 300 desarrolladores
> utilizando métodos ágiles y creciendo :-)  . Empezamos la transición
> hace unos dos años, y ha sido bastante gradual así que hay equipos que
> llevan 2 años con prácticas de Scrum y XP pero también hay equipos que
> llevan 1 mes. Bueno, hemos hecho una implantación gradual, empezaron
> unos proyectos piloto, luego un departamento, luego una gerencia, una
> dirección... luego la otra y así, jeje  (lo cuento porque creo q si no
> lo hago queda muy raro, jeje).
>
> Bueno, a lo que iba, yo en concreto habré ayudado a unos 15-20 equipos
> a empezar con prácticas de Scrum, y algunos lo han llevado muy bien
> desde el principio y otros no tanto. Quizá el ejemplo del daily
> meeting es un ejemplo de la transición hacia Agile. En este caso en
> concreto, sí que me he encontrado con equipos que han visto la Daily
> Meeting como un punto de control, de que alguien iba a fiscalizar su
> trabajo diariamente. Supongo que es normal, si por los pasillos de la
> empresa oyes que los del proyecto fulanito estan con una "metodología"
> nueva que les obliga a hacer reuniones diarias para ver cómo van, y
> controlarles qué han hecho hoy etc. Entonces inicialmente son muy
> escepticos. Creo que es un tema más de gestión del cambio. Luego,
> cuando llevan un Sprint haciendo dailys son adictos y no quieren
> dejarlo  ;-)   También está relacionado con eso de que nos creemos las
> cosas cuando las vivimos: yo ya puedo insistir mucho en que las Dailys
> son para la autoorganización del equipo, la sincronización, la
> detección de impedimentos etc., que los equipos no lo van a entender
> bien hasta que lo vivan y vean que no se está fiscalizando a nadie.
>
> Supongo que en todo cambio siempre habrá los motivados, los "ni fu ni
> fa" y los que se oponen... A mí los terceros me tienen negra!!!
> jejeje  ;-)
>
> Saludos,
>     Gemma
>
> On 13 mar, 20:52, Jordi Pradel <jordi.pra...@agilogy.com> wrote:
>

Alejandro Pérez García

unread,
Apr 8, 2009, 5:25:11 PM4/8/09
to agile...@googlegroups.com
Muchas gracias Xavier.

Lo de la pizarra lo ponía como ejemplo de cosa poco trazable. Ya os digo que la ISO desde luego no obliga a que tenga que quedar registro de la pizarra. Cosas a las que, por ejemplo, si obliga: los requisitos del cliente, cambios en esos requisitos, los errores y no conformidades sobre esos requisitos, la revision/verificación/validadción de esos requisitos, ...

Para pasar el hilo hay que hacer algo especial, o simplemente abrimos un hilo nuevo ??

Lo de conocer a Hillel parece interesante, pero este año ya hemos ido a Las Vegas al evento de TheServerSide, así que por ahora creo que se nos acabó el presupuesto para viajes  ;)

De todas formas le hechare un ojo al blog que comentas, a ver que encuentro.


Saludos


2009/4/8 Xavier Quesada Allue <xque...@gmail.com>

Xavier Quesada Allue

unread,
Apr 8, 2009, 6:02:40 PM4/8/09
to agile...@googlegroups.com
Para terminar el día y como complemento a lo anterior, justo salio en Agile-ANN un workshop sobre Agile y CMMi

Por mas que no sea factible concurrir, puede ser interesante ver el temario para tener una idea de que temas se tocan

http://agileu.org/course_details.jsp?courseid=333&schid=656

Claramente los muchachos CMMi están volcándose en forma masiva al agilismo... estamos preparados para recibirlos?

Xavier

PS: la mejor forma de pasarse de un foro a otro es hacer un cross-post (postear en los dos foros), lamentablemente yo no puedo porque uso direcciones de mail distintas

Rodrigo Corral González

unread,
Apr 10, 2009, 5:57:42 AM4/10/09
to agile...@googlegroups.com

Hola a todos:

 

Como ya dije en otro hilo, yo utilizo principalmente Team System en la mayoría de los proyectos.

 

Creo que el contar con información registrada de todo lo ocurrido en sprints anteriores es una posibilidad muy interesante. TFS se encarga de todo, y los desarrolladores no tienen que sufrir más ‘burocracia’ por ello. Al contrario, todo está integrado en el IDE, con lo que los cambios de contexto se minimizan.

 

En el momento de hacer un checkin lo asocias con el Sprint Backlog Item o el Bug con el que se corresponde y en ese mismo momento reduces el número de horas pendientes o cambias el estado del workitem a hecho. Todo desde la misma pantalla, en el momento de hacer el checkin y sin salir del IDE, sea VS o Eclipse. El datawarehouse de TFS sen encarga de agregar esa información y darte completa visibilidad de lo que pasa en tu proceso de desarrollo, desde el burndown, hasta el changlog de cada versión pasando por completa trazabilidad de que fuentes se tocaron para corregir tal bug o que fuentes se han tocado en tal build.

 

Además tienes para cualquier punto del tiempo, gracias a las consultas sobre histórico, como estaba tu desarrollo: burdonwchart de cualquier sprint, impedimentos detectados, impedimentos que se repiten…

 

Vamos que la pizarra está muy bien y es muy visual, pero cuando llevas un proyecto con 32 sprints, es sumamente interesante poder mirar al pasado y ver cómo ha evolucionado todos los aspectos de tu proceso de desarrollo. Cualquier puede mirar, cualquiera sabe dónde mirar y cualquier puede sacar conclusiones, siempre contando con información fidedigna.

 

Vamos que tener esta trazabilidad ayuda un motón en el proceso de: visibilidad, adaptación e inspección en horizontes de medio plazo.

 

Saludos!

 

Rodrigo Corral González

Software Architect


C\ Sebastián Elcano 32 , - Madrid (Spain)

Email: rco...@plainconcepts.com Mobile: +34 (686) 754 328 Blog: http://geeks.ms/blogs/rcorral/

Note: The information contained in this message may be confidential information subject to the terms and conditions of a confidentiality agreement between Plain Concepts and you or your employer. You are not permitted to disclose or publish confidential information. In addition, if you have received this message in error (i) please notify us immediately by return message, and (ii) any use or distribution of this information is prohibited.

P Please consider the environment before printing this email.

Disclaimer added by CodeTwo Exchange Rules
www.codetwo.com
Message has been deleted

Alejandro Pérez García

unread,
Apr 11, 2009, 6:23:50 AM4/11/09
to agile...@googlegroups.com
Muchas gracias Gemma

La verdad es que estoy especialmente interesado en el tema de la ISO.

Todo el tema de los requisitos (peticiones del usuarios), cambios de requisitos, bugs y no conformidades, creo que puede quedar cubierto con el Bugzilla (es la herramienta que usamos actualmente). Lo que más me preocupa es el tema de revisión/validación/verificación. No se si es válido desde el punto de vista de la ISO decir, por ejemplo, que cuando el bug se pasa a FIXED es que ya está verificado.

Desde el punto de vista de Scrum creo que es válido ya que marcarlo como FIXED indica que ya está terminado (definimos que una historia o tarea está terminada cuando está hecho el desarrollo y probado). Pero no se si desde el punto de vista de la ISO, ese cambió de estado es válido como registro. Desde luego el cambio de estado queda guardado en el Bugzilla, pero ¿es suficiente para la ISO?

¿Me podrías ayudar en este asunto? ¿me podrías contar que registros dejais vosotros?



Saludos y gracias




2009/4/10 Gemma <gemma....@gmail.com>

Hola Alejandro,

En Telefónica I+D sí tenemos la ISO, lo que intentamos es que los
registros necesarios impacten lo mínimo en el trabajo de los
desarrolladores, que el mismo soporte que sirve para que el equipo se
organice sea el mismo que utilizamos en la auditoría, pero no es algo
trivial... Una vez leí en un post que había unos que sacaban una foto
a la pizarra de Scrum periodicamente para tener el registro, la
trazabilidad etc.  :-)

Luego, una vez nos planteamos el nivel 3 CMMI pero finalmente no nos
interesó. Lo desestimamos en parte porque al ser una empresa de I+D el
modelo no acababa de encajar con la actividad que hacemos, y tampoco
lo solicitan nuestros clientes (el resto de empresas del grupo). Así
que respecto a esto que comentas no tengo experiencia, sí que he visto
muchos PPTs de empresas que combinan Scrum + CMMI, también hay quien
dice que la aplicación estricta de Scrum equivale a CMMI nivel 3... yo
por lo que estudié del modelo seguro que es posible combinarlos, pero
lo que veo más difícil es mantener los principios ágiles en cuanto a
enfocarte al "working software". La ISO en ese sentido la puedes
interpretar más como quieras, pero CMMI es más estricto y supongo que
se tendría que hacer un trabajo de chinos para registrar todo lo que
pide y que eso no impacte en forma de burocracia en el trabajo de los
equipos. Pero bueno, como te decía no tengo experiencia en Agile-CMMI,
así de primeras también me cruje un poco.

Saludos,
  Gemma

On 8 abr, 22:15, Alejandro Pérez García <alejandropgar...@gmail.com>

wrote:
> Hola Gemma.
>
> Creo que no viene mucho al hilo de este post, pero viendo que has trabajado
> con estos temas en Telefónica, me gustaría saber si tienes experiencia
> combinando Agile con ISO o CMMI.
>
> Es decir, este es un tema que me interesa mucho, el ver si son compatibles,
> y cómo.
>
> Normalmente veo que chocan mucho el tema de tener que dejar registros de
> todo (obligación de la ISO) con la pizara de Scrum, por ejemplo.
>
> Saludos
>
> 2009/4/8 Gemma <gemma.hor...@gmail.com>

aykito

unread,
Apr 11, 2009, 6:58:16 AM4/11/09
to agile-spain
Respecto al tema de Scrum+CMMi

Bastantes clientes, sobre todo clientes en los EEUU (tambien está
empezando en Europa), exigen a las empresas un certificado de CMMi
Level x.
Empresas y organismos de defensa, por ejemplo, donde los estándares de
calidad se supone que son muy altos, están empezando a exigir CMMi
Level 5 a aquellos que quieran conseguir algún contrato.
Uno de los casos que conozco es Systematics, empresa danesa joven, que
se está convirtiendo en la referencia en software de defensa. Ya tenía
el nivel 5 pero querían agilizar y optimizar los desarrollos.
Contrataron a Jeff Sutherland (como sabreis confundador de Scrum) para
hacer la migración sin perder el level 5, y hoy son totalmente Agile
(se ve en sus oficinas), implementan Scrum y tienen CMMi Level 5, de
momento el único caso que conozco en mi sector.
Sutherland ha publicado un artículo sobre el tema, por si teneis
interes en el tema:
http://jeffsutherland.com/scrum/Sutherland-ScrumCMMI6pages.pdf

Saludos


On 11 abr, 12:23, Alejandro Pérez García <alejandropgar...@gmail.com>
wrote:
> Muchas gracias Gemma
>
> La verdad es que estoy especialmente interesado en el tema de la ISO.
>
> Todo el tema de los requisitos (peticiones del usuarios), cambios de
> requisitos, bugs y no conformidades, creo que puede quedar cubierto con el
> Bugzilla (es la herramienta que usamos actualmente). Lo que más me preocupa
> es el tema de revisión/validación/verificación. No se si es válido desde el
> punto de vista de la ISO decir, por ejemplo, que cuando el bug se pasa a
> FIXED es que ya está verificado.
>
> Desde el punto de vista de Scrum creo que es válido ya que marcarlo como
> FIXED indica que ya está terminado (definimos que una historia o tarea está
> terminada cuando está hecho el desarrollo y probado). Pero no se si desde el
> punto de vista de la ISO, ese cambió de estado es válido como registro.
> Desde luego el cambio de estado queda guardado en el Bugzilla, pero ¿es
> suficiente para la ISO?
>
> ¿Me podrías ayudar en este asunto? ¿me podrías contar que registros dejais
> vosotros?
>
> Saludos y gracias
>
> 2009/4/10 Gemma <gemma.hor...@gmail.com>
> información ...
>
> leer más »

Luis Pabón

unread,
Apr 12, 2009, 6:48:15 AM4/12/09
to agile...@googlegroups.com
Gracias a todos por las experiencias y referencias. Echaré un ojo
especialmente atento a esta última de aykito, ya que me interesa
bastante seguir de cerca las iniciativas en este sector.

Saludos.

Luis Pabón.



aykito escribió:
Reply all
Reply to author
Forward
0 new messages