Debate. ¿SCRUM vale para todas las fases del proyecto?

Yo:
En mi humilde opinión, SCRUM es una buena metodología para el seguimiento y el desarrollo de software pero no es una metodología para empezar el proyecto. Se ha de implantar una vez ya se está en una etapa del desarrollado en el que se puede decir que se tiene una primera versión de la o las aplicaciones del proyecto.

Contertulio:
No entiendo porqué dices que no es una buena metodología para empezar el proyecto. Que sea una metodología ágil, que no se fomente el upfront design, etc, no quiere decir que empieces a codificar a lo loco sin pensar un poco. En muchos proyectos se hace la famosa iteración 0, en la que precisamente se piensa en todo esto. Lo que si que no se puede hacer es pasarte tres meses diseñando la aplicación.

Yo:
No quería decir hay que empezar a codificar sin más. SCRUM tiene una dinámica en la que cada sprint tiene valor por lo que ya es una ?release? de la aplicación o casi; por ese principio, si no tienes nada (acabas de empezar) ¿el primer y único spirnt debería ser el producto entero?.
Bueno, he sido un poco filósofo en el párrafo anterior. Perdón. Pero lo que quiero decir es que al empezar hay muchas tareas que en realidad no añaden valor directo como indica SCRUM por lo que la tendencia, en mi opinión claro, es amoldar SCRUM para poder hacer sprints que no tienen valor para el cliente, pero entonces ya no es SCRUM seria SCRUM versión beta 1.0.
Cuando digo amoldar me refiero a que si el sprint no genera una ?release? entonces genera una parte que habrá que integrar con otra parte que saldrá de otro sprint. No he visto nada en SCRUM que hable sobre cómo integrar partes. En este enlace esta mi opinión sobre subestimar los costes de integración
http://rumberomelo.blogspot.com/2010/12/la-excesiva-simplicidad.html

Contertulio:
Al finalizar cada sprint lo que entregas es producto potencialmente entregable, es decir, una o varias historias de usuario acabadas. Esto, obviamente, no quiere decir que esté todo lo que pide el cliente. En Scrum tienes una pila de producto y en cada sprint implementas lo que puedas por orden de prioridad. Por lo tanto, por ejemplo, en tu primer sprint podrias tener implementado el sistema de loguin de tu aplicación. Y esa história estará totalmente acabada, con sus tests de aceptación pasados, etc. El cliente la podrá evaluar y darla por buena o no. A partir de esto, se implementa otra(s) história(s) de usuario(s) que se integran con esta y que implementan otras cosas que requiere el usuario. No se implementan n historias en paralelo y después se integra, sinó justo al contrario, estás integrando continuamente.

Por otra part, es normal que Scrum no te hable de como integrar partes explicitamente. Scrum es un marco metodológico para la gestión del proyecto y se debe apoyar en buenas prácticas técnicas como la que se describen en XP. Si te fijas un poco en XP junto con Scrum, verás que la integración se hace continuamente, sprint a sprint, dia a dia, commit a commit.

Yo:
Siguiendo tú ejemplo. Supongamos que tenemos el modulo de login que estará totalmente acabado, se le presentará al cliente, le gusta y todo correcto. Otro sprint me va a dar el modulo de menú principal pero al empezar el desarrollarlo nos damos cuenta que tenemos que cambiar el modulo de login porque no se integran bien (modulo de login con modulo de menú principal) y el cambio es mejor hacerlo en el modulo de login. Por lo que tengo que parar el modulo de menú principal (sprint parado) y empezar un nuevo sprint que es modificación de modulo de login.
Me surgen varios problemas según he podido leer de SCRUM:
- No he visto como se tratan los sprint parados. ¿Cómo va eso? ¿Se para y se retoma desde donde se dejo?¿Se empieza de nuevo?
- Los sprint se generan siempre un día concreto de la semana o del mes, al tener que generarlos de urgencia se está rompiendo el ciclo normal de trabajo por lo que se asume un riesgo: ?como lo asimilará un cambio drástico en el ritmo de trabajo el equipo de desarrollo?.

SCRUM, como tú dices, intenta que si el cliente no puede ver la aplicación hecha que al menos vea algo que le guste; pero es que eso es imposible en una aplicación medio grande, hay demasiados factores y, además, en la mayoría de proyectos el cliente necesita una interfaz para ver el valor de la aplicación y esa interfaz puede que no exista porque no es parte de los requisitos.

SCRUM me parece buena metodologia pero cuando ya te has quitado de encima "los pequeños factores".

Contertulio:
Lo normal es que en la reunión de inicio de sprint, el equipo se dé cuenta que la nueva história que le pide el cliente requiere de la modificación de un elemento ya existente. No hay problema, se pone como tarea, se hace y listos. Que una história un dia determinado se dé por acabada no quiere decir que nunca más se toque lo que se ha implementado. Scrum abraza el cambio y lo vé como algo positivo, ya que acerca la aplicación a lo deseado por el cliente.

Por ejemplo, para empezar el cliente podría haber pedido una versión básica de login, y más adelante quiere añadir más funcionalidad. Cap problema, se hace y ya está.

Para para un sprint, se tiene que dar una cosa realmente excepcional, como por ejemplo una repriorización brutal a mitad de sprint. En general, no se rompen los sprints.

Yo:
El cambio al que me refiero no es una petición de cliente. Me refiero a que hay un problema de integración. Si, como creo que quieres decir, abrazo ese cambio en el login como una tarea del modulo de menú principal ¿no estoy perdiendo ese valor que se consigue al decir que con el primer sprint tengo algo con valor del que siempre podría partir?. Ten en cuenta que al desarrollar el modulo de menú principal te has dado cuenta que en verdad el modulo de login no es correcto pero para el cliente ya tiene valor porque lo ha visto.

¿No crees que SCRUM subestima el coste de codificación (cosa que no hace XP) e integración?

Y en otro orden de cosas, dar la posibilidad de asimilar en cualquier momento un requisito o modificación del cliente no sé si es buena idea. Teóricamente es perfecto, pero en la práctica puede que tu proyecto fuera para construir un coche y terminar con un avión.

Contertulio:
Empezemos por la primera. En un proyecto gestionado con Scrum, en cada sprint tenemos que tener implementado aquello que dá más valor al cliente. El cliente decidió que el loguin tal como lo definió aquel dia era lo más importante para él. Si n sprints después resulta que hay que modificarlo un poco para adaptarlo a otra historia, no pasa nada. Una história acabada es una história acabada para ese sprint. Si después se tiene que crear otra história que modifique la codificación de la primera, es que tiene mucho valor por el cliente y él estará encantado que la modifiques. Recuerda que el cliente en Scrum ve la aplicación al final de cada sprint, y la tiene que ver toda, no sólo lo nuevo. Por tanto, para él la nueva história tiene valor, y mucho.

Lo segundo. Scrum no subestima el coste de codificación. Recuerda que quien estima en Scrum es el equipo, és decir, quien lo va a codificar todo y a quien se va a exigir tener el producto funcionando a final de sprint, con lo que ya se cuidará de estimar todos los detalles que comporte la programación de la tarea.

Tercero, si acabas hacieno un avión, es que en el fondo el cliente queria hacer un avión y a principio de proyecto no lo sabía. Por eso es muy bueno no hacer un gran upfront design suponiendo que el tio queria hacer un coche pq vamos a sufrir mucho. Si vamos implementando história a história, poco a poco y nos vamos adaptando poco a poco a los cambios del cliente, esta transición será mucho más llevadera.

Yo:
Si teóricamente no te quito razón. Pero en la práctica, desde el punto de vista de estar allí en el proyecto, veo tantas cosas que no van a ser así. Las estimaciones hechas por el equipo teóricamente deben ser exactas (es la gente que lo va a implementar) pero en la práctica... ¿me vas a decir que TODOS los programadores asimilan y aceptan las pautas marcadas para el desarrollo y van a seguir el diseño?.

Lo del símil del avión no lo he concretado bien, quería decir ?puede que tu proyecto fuera para construir un coche y terminar con un avión. Y te han pagado por un coche?.

Respecto a modificar el login, dices: ?Si después se tiene que crear otra história que modifique la codificación de la primera, es que tiene mucho valor por el cliente y él estará encantado que la modifiques?. Él estará encantado si te ha pedido una modificación. Pero la modificación no te la ha pedido él, en el ejemplo quería decir que, al desarrollar, el equipo se ha dado cuenta que hay que modificarlo por lo que el cliente seguramente te dirá:?¿Pero eso no estaba ya??

Contertulio:
Las estimaciones son, por definición, inexactas. Eso si, serán mucho más exactas las que haga el equipo después de una buena reflexión en la reunión de inicio de sprint que no la de un analista o jefe de proyecto que haga al vuelo.

Que todos los programadores asimilen y acepten las pautas marcadas para el desarrollo y sigan el diseño, es tan ""fácil"" como hacer unas buenas revisiones de código a final del sprint.

El tema de la presupuestación es otro tema aparte. Si haces Scrum con proyectos de presupuesto cerrado, tendrás que empezar a negociar con él cliente. Si él pidió un coche y ahora te pide un avión, pués o lo quitas features a implementar del avión, o le cobras más. Pero este problema lo tendrás con Scrum y con todas las metodologías. Aunque bien gestionado, con Scrum lo harás mucho mejor :D

Y lo tercero, todo es comunicación. Esto se habla en la reunión de inicio de sprint. El cliente te cuenta lo que quiere hacer, tu le cuentas las implicaciones y él decide si tirar para adelante o no. La comunicación entre el equipo y el cliente ( o el Prodcut Owner ) es vital.