Retrospectiva de la primera parte

Lo que hemos visto

Antes de pasar a la segunda parte, hagamos una retrospectiva. ¿Qué ha ido bien en la primera parte del libro? ¿Ha comprendido las ventajas de la agilidad? Esperamos sinceramente que sí.

Resumamos estos beneficios en la siguiente tabla:

Ahora bien, ¿qué...

Algunos comentarios

Como todo el mundo tiene derecho a hablar durante la retrospectiva, no dude en expresarse, es importante para avanzar.

¿Hay algún punto que deba aclararse?

¿Quién quiere tomar la palabra? No sea tímido, el objetivo es que todos avancemos juntos, y sus comentarios son inestimables si queremos mejorar sistemáticamente.

- «Sí, Fede, ¿quieres decir algo?»

- «Lo que he notado es que Scrum presenta el riesgo de ver funcionalidades extenderse indefinidamente y de entrar en el modo "Scope Creep"; a menos que se defina formalmente una fecha de finalización. Es más, como trabajamos en modo ágil, los equipos del ámbito de negocio pueden verse tentados a añadir funcionalidades durante los sprints. Además, si una tarea no está bien definida, la estimación de los costes y el tiempo del proyecto no será exacta. En este caso, la tarea puede perderse a lo largo de varios sprints.»

- «Gracias por tus comentarios, Fede. Si quieres, los repasamos uno a uno.»

La fecha de finalización de un sprint es el final del sprint, no se vuelve atrás y no se cambia nada. Una funcionalidad que no se termine durante el sprint se terminará durante el siguiente; y si se estimó en 13 puntos, ninguno de sus puntos se contará al calcular la velocidad del sprint. Es injusto, pero así son las cosas, incluso suponiendo que esté completada al 90 %

Solo contamos lo que realmente ha llegado a la fase de ¡DONE! Hacemos esto para evitar revivir escenarios como "Ya casi estoy, dame medio día y lo termino...", donde por desgracia, tres días más tarde, el asunto aún no se ha cerrado. En Scrum todo está acotado en el tiempo para ayudarle a gestionar mejor el tiempo.

Tampoco se puede posponer una Sprint Review o una Retrospectiva solo porque alguien esté de vacaciones o tenga otra reunión urgente. Como todo esta acotado en el tiempo, las ceremonias Scrum se pueden planificar y cada uno tiene que adaptarse a su horario.

En cuanto a añadir funcionalidades en medio de un sprint, no es porque estemos en modo ágil por lo que tenemos que replanificar constantemente. Adaptarse a los cambios significa que todo el mecanismo ágil nos permite ser flexibles en la capacidad de respuesta de nuestras acciones....

Los orígenes de Scrum

En esta primera parte, no hemos dejado de hablar de Scrum, pero ¿de dónde viene el nombre Scrum? Es un término que proviene del rugby y significa "melé". De manera general, los japoneses adoran este deporte. El verdadero espíritu ágil, de hecho, nació en Japón, aunque Scrum se ha convertido en la metodología ágil más utilizada en el mundo. Fue en 1986 cuando Takeuchi y Nonaka denominaron a Scrum como un estilo de gestión de proyectos, y no fue hasta 1993 cuando Jeff Sutherland y Ken Schwaber escribieron la Guía Scrum.

En el rugby existe un verdadero espíritu de equipo y un profundo respeto por las personas. Durante un partido, todos los jugadores respetan al árbitro y nadie cuestiona sus decisiones; el respeto es un valor primordial y real en el corazón de los jugadores de rugby. En el Scrum, el equipo de desarrollo trabaja colectivamente, concentrado al máximo en el objetivo del sprint, al igual que el pack (los delanteros del equipo) cuando se lleva un balón en el rugby. Como un medio de melé, el Scrum Master espolea al equipo, reorientándolo en la dirección correcta cuando se olvidan las reglas. Es él quien marca el ritmo para que el equipo mantenga la motivación y concentración, de modo que al final de cada sprint marquen su ensayo: una demostración...