Los Fundamentos de Agile Scrum. Frank Turley
aceptar que su forma de trabajar no es perfecta, y siempre puede mejorarla en pequeños pasos. Pero no se fije en la forma en la que se han mejorado el Manifiesto y los Principios: Haga lo que dicen en el Manifiesto, no lo que hacen
■ Ya hemos acabado de revisar los Principios de Agile. No olvide que son temas muy comunes en el examen.
■ CONSIDERACIONES PRÁCTICAS DE LOS CICLOS DE VIDA ADAPTATIVOS
¿Recuerda cómo funcionan los Ciclos de vida Adaptativos? Aquí tiene de nuevo la imagen, así le damos un poco más de volumen al libro:
Tenemos que hablar de varias cosas. En primer lugar, para cada iteración, elegimos un número de características o funcionalidades y nuestro objetivo es crear un software operativo (incremento) para el final de la iteración que, esperamos, contenga todas las características. Ahora, en tu opinión, ¿debería de ser una iteración con un alcance predeterminado o de una duración predeterminada?
Por cierto, uso la palabra “característica” de forma aproximada en este caso.
Iteraciones de Alcance predeterminado vs Iteraciones de Duración predeterminada
En teoría, pueden funcionar las dos pero, en la práctica, las iteraciones de una duración predeterminada son significativamente superiores porque si fijas el alcance de la iteración, entonces:
■ Normalmente, se necesitará más tiempo para acabar todo lo incluido, lo cual reduce la cantidad de feedback y por lo tanto, las oportunidades para adaptar.
■ Puede que se pase demasiado tiempo en cada característica y se incluya demasiados adornos. Tener una duración predeterminada hace que nos centremos continuamente en lo prioritario.
Esta es la razón por la que casi todos los métodos Agile tienen iteraciones de duración predeterminada y se insiste en respetar estos timeboxes. Un timebox es un periodo de tiempo de una duración máxima (o predeterminada) y no se amplía bajo ninguna circunstancia (si se amplía una vez, se hará continuamente).
Duración de las Iteraciones
Ahora que hemos establecido que las iteraciones deben de ser limitadas en el tiempo (timeboxed) ¿cuánto deben durar? Se mencionó en los Principios Agile, ¿lo recuerda?
Si se basa en los Principios Agile, el máximo son dos meses. En Scrum, el máximo es un mes.
Este tiempo es suficiente para desarrollar algunas funcionalidades y mostrárselas al cliente y al usuario final para generar feedback. No queremos que sea demasiado tiempo porque, en ese caso, no obtendremos feedback suficiente.
¿Iteraciones de una duración fija o de distintas duraciones?
En su opinión, ¿es mejor que las iteraciones tengan la misma duración o mantenerlas flexibles?
Mantener la misma duración es más disciplinado, y normalmente, no hace falta ir decidiendo duraciones nuevas.
Scrum requiere que tengan la misma duración. Sin embargo, esto está sujeto a adaptación. Esto significa que puede empezar su proyecto con Sprints de dos semanas (sí, las iteraciones en Scrum se llaman Sprint) y, después de un tiempo, cuando se da cuenta de que no es suficiente para crear las funcionalidades, puede decidir hacerlos de tres semanas. Está bien. Lo que no está bien en Scrum es reunirse antes de cada Sprint y decir “Venga, ¿cuánto queremos que dure el Sprint esta vez?”
No todos los métodos son iguales. En DSDM, que es otra metodología Agile, se planifica la duración de los time boxes (sí, las iteraciones en DSDM se llaman timeboxes) cuando se planifica el ámbito de trabajo.
¿Qué ocurre si no se acaban algunas funcionalidades?
Por lo tanto, elegimos un número de características o funcionalidades para la iteración de una duración limitada (time box). ¿Qué ocurre si no podemos acabar todo para cuando se acaba la iteración?
No pasa absolutamente nada porque nuestro objetivo principal es crear un incremento de software que pueda generarnos feedback para luego adaptarlo y, más tarde, generar el máximo valor cuando pase a producción. Nuestro objetivo NO es desarrollar el mayor número de funcionalidades posible.
Tres de los Principios Agile apoyan esta afirmación; ¿sabría decir cuáles?
Respuesta: 1, 7, 10
¿Qué ocurre dentro de las iteraciones?
En su opinión, ¿cómo se deben llevar a cabo los procesos de desarrollo dentro de cada iteración?
Se puede hacer de dos maneras:
El de la izquierda pasa por cada proceso de desarrollo y lo realiza para cada una de las funcionalidades que pertenece a esa iteración. Quizá podríamos llamarlo mini- Cascada.
El de la derecha pasa por todas las funcionalidades, bien de una en una o bien por varias a la vez, y realiza cada proceso de desarrollo para cada una de ellas. Esta opción es mejor. ¿Sabe por qué?
Una de las razones es porque hemos decidido usar iteraciones de time box, por lo que siempre existe la posibilidad de que no podamos acabarlo todo. Con el enfoque mini- Cascada, no se podrá tener ninguna funcionalidad nueva completada del todo y, por lo tanto, no se podrá generar feedback, mientras que, con el otro enfoque, siempre tendrá algunas funcionalidades para mostrarle a sus clientes y para poder adaptar para la siguiente iteración.
Empoderamiento
Determinadas decisiones las toman los altos directivos y algunas, el equipo de proyectos. La proporción de unas y otras viene dictada en parte por el enfoque del desarrollo.
¿Cuándo es necesario tomar la mayoría de las decisiones no-técnicas?
Es principalmente durante el análisis, cuando intentamos averiguar qué funcionalidades se necesitan, y durante las pruebas finales, cuando comprobamos la aceptación de las funcionalidades. Ahora, compare cómo se distribuyen estos dos procesos en los dos enfoques, Predictivo y Adaptativo. ¿Quiere que vuelva a pegar las imágenes aquí o girará las páginas para comprobarlas al principio del capítulo?
Estos puntos de decisión se concentran al principio y al final del Ciclo de vida Predictivo, por lo que nos podemos permitir elevar la mayoría de las decisiones a dirección. Pero ¿en el caso de los sistemas Adaptativos? En ese caso, los puntos de decisión se reparten a lo largo del ciclo de vida casi a diario. Por lo tanto, si queremos seguir elevando la toma de decisiones, nunca se podrá acabar el proyecto.
Por este motivo, el Ciclo de vida Adaptativo requiere miembros del equipo empoderados para poder tomar la mayoría de las decisiones ellos mismos sin necesidad de elevarlas a dirección.
Este concepto también se conoce como auto-organización.
■ ¿ES SÓLO PARA PROYECTOS DE TI?
Como se habrá fijado, doy por hecho que todos los proyectos Agile son de desarrollos de TI. También habrá observado que el Manifiesto Agile y los Principios Agile hablan de software. Por lo tanto, la pregunta es ¿los métodos Agile se limitan a proyectos de desarrollo de TI?
Me gustaría