Pregunta al grupo: ¿Qué metodología ágil utilizáis?

Me gustaría conocer si alguien de este grupo ha utilizado alguna vez alguna metodología ágil, cómo la ha implementado y qué resultados ha obtenido, tanto buenos como malos. Añadiendo, finalmente, alguna conclusión personal al respecto.

De este modo quizá podamos aprender un poco de los puntos fuertes y débiles que pueden tener estas metodologías al aplicarlas en entornos reales.

Un saludo a tod@s.

#1   

Donde estoy trabajando ahora hacemos un subconjunto bastante pequeño de Scrum. Nos reunimos a diario unos 10 - 20 minutos. En esa reunión que hacemos frente la pizarra vemos las tareas realizadas, en curso y pendientes, que están escritas en post-its. Las movemos de sitio si es necesario y hablamos de lo que estamos haciendo y los problemas que hemos tenido. Pero por ejemplo no estimamos horas. Procuramos dividir las tareas hasta tal punto que se puedan completar en menos de un día para así cada día cambiar de tarea.

Me gusta porque así todos sabemos lo que hace cada uno y hablamos todos los días.

No puedo decir mucho más porque llevo poco tiempo (un mes aproximadamente).

saludos!

#2   

Esperaba con avidez tu respuesta XD, pues ya comentaste esto mismo en otro foro y fue lo que me dio la idea.

Sí se parece bastante a la filosofía general de Scrum. Una pregunta: ¿el modelo es iterativo? de ser así: ¿os comprometéis al principio de cada iteración a desarrollar durante la misma un determinado subconjunto de funcionalidades o no?

Gracias por tu aportación

#3   

Jejejeje.

Ocurre que he entrado en un período poco representativo. Porque estamos trabajando en 3 proyectos. De los cuales 1 es propio de la empresa y 2 son externos. Los proyectos externos se están terminando y las tareas que quedan no son fundamentales. Básicamente es una pila de tareas pendientes que hay que hacer, pero que no urgen, ni tienen un plazo fijo. Y del proyecto propio se está definiendo su versión 2.0. Así que es difícil que te lo diga. Realmente no hay iteraciones con fechas concretas, pero sí que es verdad que cada semana o dos semanas el jefe de proyectos añade un grupo de post it nuevos :P. Así que más o menos sí, pero no :P

En el resto de empresas en las que he estado no he usado metodologías ágiles. Ni tampoco una metodología clásica suficientemente definida.

saludos!

#4   

No hace mucho estuve en un curso de Scrum (y he leido en otros sitios) que no es recomendable empezar por sucedáneos de Scrum. Todas las referencias que he visto sobre cómo empezar con Scrum es hacer "por el libro" y luego, cuando le hemos cogido "el tranquillo", ir haciendo variaciones para adaptarlo a nuestra organización.

Yo he vivido el usar "una especie de Scrum" y no tuvo éxito. Sólo se consiguió avanzar con éxito cuando se eligió un proyecto y el equipo hizo Scrum-by-the-book.

Por otra parte, (sea la metodología ágil que sea) hay que contar con el rechazo de unos cuantos (o unos muchos), bien sea por miedo o incluso por ignorancia (la cuál produce miedo). Cuidado con ésto porque es muy difícil manejar así un proyecto puesto que adoptar el agilismo es cambiar el paradigma en todos los roles, desde la dirección hasta el que hace fotocopias ;-)

Un saludo,
JMB

#5   

Efectivamente; en el caso de Scrum el ScrumMaster no es tanto el rol de gestor, es, utilizando la analogía de Ken Schwaber, autor de Scrum, más bien un perro pastor, y el equipo son las ovejas. El equipo tampoco tiene un rol determinado al estilo RUP: todos analizan, diseñan, implementan, prueban y documentan.

Y por otra parte los stakeholders y el ProductOwner en particular al principio suelen ser bastante reacios, como dices, a este tipo de mecanismos en los cuales "se deja libertad al equipo y está prohibido molestarlos o exigirles más".

El asunto con Scrum es que tiene una filosofía y unas reglas y el resto es libertad para implementarlo, teniendo en cuenta siempre lo anterior.

Estoy estudiando a fondo Scrum (¿se nota?) y, a pesar de sus éxitos, hay algunas cosas que no me acaban de convencer, sobre todo relativo a temas de estimación: ésta se basa en juicio de expertos (el equipo decide cuánto tarda en desarrollarse un ítem o funcionalidad del Backlog), lo cual está sujeto a muchas imprecisiones, sobre todo porque depende mucho también de quién va a implementar tal funcionalidad; pero al estimar no se sabe quién va a hacer qué, porque la asignación de ítems se hace después (cada uno elige lo que quiere desarrollar). También existe una fuerte carga, sobre todo al principio, de elegir demasiadas cosas para hacer en un Scrum y no cumplir el compromiso, o elegir demasiado pocas y sobrar tiempo. Es difícil dar en el blanco. Echo en falta mecanismos que apoyen a la estimación, por ello, desde el propio método.

#6   

Yo usé Scrum durante unos meses y la verdad que me gustó mucho.

El escenario fue un poco diferente ya que los 'product owner' eran de la misma empresa ya que era un proyecto interno.

Cosas que me gustaron:

1.- Tener siempre una visión de dónde está el proyecto. Al tener reuniones diárias no sólo sabes por dónde vas tú, sino que descubres por dónde va el proyecto en su totalidad. Esto me parece muy recomendable.

2.- Mejora de la comunicación, por la misma razón que el anterior punto, las reuniones diárias.

3.- Congelación del sprint backlog, una de las cosas más importantes, mientras se está en un sprint no se cambian las tareas de este, así el equipo puede desarrollar de forma cómoda.

4.- Desarrollo orientado a prototipos, muchas veces pecamos en exceso de querer enseñar algo que ya casi es el proyecto final (en aspecto), en cambio en Scrum es más importante que tenga las funcionalidades a que tenga coloritos.

5.- Debido al punto cuatro y a los sprints se recibe un feecback casi constante del cliente, por lo que puedes saber si vas bien o mal. Algo mucho más adecuado que estar 6 meses u 8 desarrollando para que luego resulte que entendiste mal unos requerimientos, o que el cliente ya no está convencido con lo que pidió y ahora quiere otro enfoque. El tener el feedback al final de cada sprint hace que en caso de haberse equivocado alguna de las partes se detecte antes y el cambio no sea tan grave.

Desde mi punto de vista este timo de metodologías te ayudan a tener estimaciones realistas de ti mismo, al tener que estimar cada tarea en horas o días después de unos meses de práctica vas acertando mucho más con lo que te va a costar una tarea.

Creo que el punto débil, es que no es fácil convencer a un cliente para usar una metodología ágil, pero tampoco tengo experiencia ene se punto, así que es sólo lo que me parece.

#7   

A tí te pasa como a mí: entendí el ProductOwner como un cliente. Fíjate que es el propietario del proyecto, en ningún sitio dice "cliente". El ProductOwner puede ser un directivo de la propia empresa, o un comercial, incluso aunque el proyecto sea para un cliente externo.

Totalmente de acuerdo con lo que dices, sobre todo con los primeros puntos. La visibilidad y el feedback con el cliente son los puntos más fuertes de Scrum, sin ninguna duda. Esto propicia el control del proyecto.

Sí es cierto que a medida que coges experiencia haces mejores estimaciones, sin duda.

En cuanto a lo último que dices, es esperable que el cliente al final esté agradecido con este tipo de metodologías (aunque al principio sea reticente), porque ve el progreso del proyecto, ve a la gente implicada, asistiendo como "gallina" a los diferentes tipos de reuniones en Scrum.

#8   

No no, no lo entiendo como cliente externo, pero normalmente suele ser el caso, por eso digo que era un poco diferente. Una de las bases de Scrum es que el product owner se implique también en el proceso, eso en el caso particular de mi experiencia era sencillo, ya que era parte de de la empresa, pero es posible que que en otros casos puede ser bastante más difícil.

Esto también se aplica a lo de que es esperable que el cliente esté agradecido, pues yo creo que por el momento no en exceso, pero me parece que es más por desconocimiento que porque no les guste la metodología.

#9   

Hola muchachos, pues les cuento que para desarrollar mi trabajo de grado despues de leer e investigar he decidido irme por el "Proceso ICONIX".

He encontrado este magnifico libro: "Agile Development With ICONIX Process". y es lo que estaba buscando, una metodologia muy ligera pero eficiente. La verdad es que la usé unos semestres antes para el desarrollo de un proyecto pero en ese entonces no me interesé mas por esa metodología y luego de realizar el proyecto la abandoné.

Este proceso te conduce lo mas pronto posible desde los requerimientos hasta el código en iteraciones cortas.

Bueno, les estaré contando como avanzo en la aplicación de esta metodología.

#10   

Nunca la había oído...
¿Y nos podrías contar, así, a grandes rasgos, en qué consiste?