Aprenda Scrum como si estuviera en primero (II)

Estructuración de la metodología

Tres fases fundamentales: una breve fase de planificación, en la cual se realizan las labores básicas de una planificación breve: visión general del proyecto (estimación muy general, viabilidad del sistema) y construcción del Backlog. por un lado y por otro el desarrollo de la arquitectura al detalle; otra de desarrollo, en la cual tienen lugar los famosos Sprints, y otra final de entrega y balance de los éxitos y fracasos logrados.

La fase fundamental de la metodología, la que realmente tiene interés para nosotros, es la fase de Sprint. Las otras dos no difieren mucho con las fases de Planificación y Entrega de otras metodologías. El desarrollo en la fase Sprint es iterativo, en uno o más Sprints (¿cuántos? ¡los que haga falta!), hasta que el proyecto se da por finalizado por el ProductOwner. De este modo acometemos el problema de la variabilidad de los requisitos. No hay una estimación prematura fiable: los requisitos probablemente cambiarán y nuestra metodología está preparada para ello.

Reuniones, toma de decisiones

Existen cuatro tipo de reuniones durante el desarrollo de un proyecto con Scrum:

Encuentro de Planificación (4 horas): Al comienzo de un Sprint se decide qué parte del Backlog global del proyecto se implementará en este Sprint. Una vez decididas las funcionalidades a implementar, en base a estimaciones de tamaño, tiempo, esfuerzo, etc., el Sprint Backlog no se toca durante todo el Sprint, bajo ninguna circunstancia. Si algo falla, el ScrumMaster podrá cancelar el Sprint y comenzar otro.
Encuentro Diario (15 minutos): Diariamente el equipo se reúne en un rápido encuentro, de unos 15 minutos, para responder, individualmente, a 3 preguntas básicas: ¿qué hiciste ayer? ¿qué vas a hacer hoy? ¿qué te está impidiendo alcanzar tus objetivos? Si nos fijamos, de este modo se realiza el control del proyecto y el seguimiento de los posibles riesgos.
Encuentro de Revisión (4 horas): Al final del Sprint, se realizará una reunión con el ProductOwner y otros clientes (gallinas) para exponer la funcionalidad desarrollada junto con las posibles preguntas y ampliaciones del Backlog que se les pueda ocurrir a los diferentes stakeholders (clientes+ejecutivo). Con esto logramos un ‘feedback’ con el cliente, que ve cómo el producto progresa.
Encuentro Retrospectivo (4 horas): Reunión del ScrumMaster con el Team para revisar cómo fue el Sprint: qué se consiguió realizar bien y cómo se podría mejorar. Si nos fijamos detenidamente, esto no es más que una revisión de lecciones aprendidas y un intento de recabar información histórica del propio proyecto (Software Estimation, Steve McConnell), útil para futuras estimaciones y Sprints.

Desarrollo de la fase Sprint

Cada Sprint tendrá una duración aproximada de unos 30 días (en algunas fuentes se habla de entre 2 y 6 semanas); se entiende que esta cantidad de tiempo es suficiente como para desarrollar algo entregable y funcional al ProductOwner. Se comprende como jornada laboral aquella que dura 8 horas. No se contempla, bajo ningún concepto, por lo dañino y lo poco productivo, la realización de horas extra (Peopleware, deMarco y Lister).

El Sprint comienza con un Encuentro de Planificación en el cual se decide qué se va a desarrollar del Backlog general y se elabora el Sprint Backlog. A la hora de seleccionar las funcionalidades a desarrollar se tendrá en cuenta la prioridad de los requisitos, establecida por el ProductOwner. Se descomponen los requisitos en tareas simples, realizables en poco más de una jornada laboral de 8 horas como máximo. Como se ha indicado, una vez decidido el Sprint Backlog éste no se toca en absoluto y bajo ninguna circunstancia durante el Sprint. Las funcionalidades seleccionadas NO se asignan a los miembros del Team, sino que cada miembro ELIGE qué desea desarrollar (Peopleware). Una vez comenzado el Sprint, el ScrumMaster no se implicará lo más mínimo en el Team; realizará sus labores de planificación, estimación, control y gestión y solamente contactará con el Team en los Encuentros Diarios. Aparte de esto solamente tratará con algún miembro del Team cuando éste desee preguntarle algo o solicitar algún tipo de ayuda. Libertad de desarrollo para el equipo (Peopleware); que no significa ausencia de control o anarquía, ni mucho menos. El ScrumMaster tratará de favorecer el flow o máxima productividad de su Team (Peopleware) y tratará de crear un clima en el cual se pueda trabajar sin interrupciones (Peopleware).

Cada miembro se responsabilizará de entregar la parte que se ha comprometido a realizar en el plazo fijado. Si es incapaz de ello hablará con el ScrumMaster para solicitar ayuda o detener el Sprint, de forma muy excepcional. Si el Sprint Backlog se termina antes de tiempo, se puede dialogar con el ProductOwner para añadir más funcionalidad al Sprint.

El avance Sprint a Sprint se visualiza mediante un artefacto o diagrama de burn down que representa la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo ideal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el prinicipio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.

Conclusiones

Algo que no se ha dicho es: en la explicación de la fase Sprint se ha supuesto que existía un solo equipo. ¿Qué ocurre cuando tenemos varios equipos? Aquí entra en juego un añadido a la metodología Scrum, el concepto de Scrum of Scrums, que consiste en realizar un Scrum diario con un representante o portavoz de cada equipo, el cual explicará al resto los avances diarios que está realizando su grupo (responderá a las 3 preguntas antes mencionadas).

Según la opinión de los propios autores, utilizar Scrum permite entregar al cliente un producto que le satisface, que cumple mejor los requisitos que él pedía, y con la calidad adecuada. Además el equipo es productivo y trabaja más a gusto, se compromete con el proyecto y la organización haciendo lo que más le gusta. Por otro lado, el uso de Scrum permite reducir la estimación temporal hasta en un 40%, debido precisamente a este aumento en la productividad, fruto de los rápidos desarrollos en los Sprints y los compromisos adquiridos por los miembros del equipo.

Debido a su alto carácter iterativo y variable, no es en absoluto necesario realizar complejas planificaciones iniciales con Pert o diagramas de Gantt.

Existen algunas ideas más que aquí no he querido introducir, por simplicidad, como por ejemplo algún detalle más de la fase de Planificación, Entrega, u otros conceptos como el burn down chart. Sin embargo, creo que con lo aquí expuesto, libre de detalles menos importantes, uno puede hacerse una idea bastante fidedigna de qué es Scrum y qué trata de observar y tener muy presente. Para más información consulte el apartado de Fuentes. Para la elaboración de este documento se recopiló información de las distintas fuentes mencionadas, dando un resumen final bastante personal del autor sobre qué ideas merece la pena concretar un poco más y qué detalles son más superfluos.

Fuentes de información

Fuentes bibliográficas principales

  • Agile Software Development with Scrum, Ken Schwaber : el libro “oficial” de Scrum. Realmente Scrum no da como para escribir un libro de más de 20 páginas. Tan simple es. Por lo tanto, K. Schwaber rentabilizó su idea con un libro que incluye todo lo básico para conocer Scrum en el primer capítulo y los apéndices finales. Los otros 8 capítulos son experiencias del autor en la aplicación de Scrum en entornos reales. Batallitas del abuelo, vamos.
  • http://es.wikipedia.org/wiki/Scrum: la primera fuente que tuve como acercamiento a Scrum. Posteriormente tuve que modificar la parte en la que se explica el concepto de informe “burn down”, ya que era errónea.
  • www.agilealliance.org y www.controlchaos.com, donde se encuentran los siguientes documentos:
  • Agile Processes and Self-Organization, SCRUM Development Process, Controlled Chaos : Living on the Edge, Agile Processes – Emergence of Essential Systems, Controlled-Chaos Software Development, Best Practices in Scrum Project Management and XP Agile Software Development.
  • http://video.google.com/videoplay?docid=-7230144396191025011: Conferencia de Ken Schwaber sobre Scrum al personal de Google; 5 de Sept. de 2006. En inglés, por supuesto.

Fuentes bibliográficas secundarias

  • Peopleware – Productive Projects and Teams, Tom deMarco y Timothy Lister. Ya hemos hablado de este libro mucho aquí. Es fundamental para todo buen Gestor de Proyectos. Aunque no lo dice en ningún sitio, estoy completamente seguro de que Ken Schwaber se basa en muchas de las premisas aquí indicadas, sobre todo en la definición del rol ScrumMaster.
  • SW Estimation, Demystifying the Black Art, Steve McConnell. El autor es muy conocido por este y otros libros de Estimación y Gestión de Proyectos. Este libro incluye un buen número de buenas prácticas, en forma de 118 consejos, para realizar estimaciones de tamaño, de esfuerzo, de temporización y de funcionalidad en los proyectos.

8 pensamientos en “Aprenda Scrum como si estuviera en primero (II)

  1. Me ha venido a la cabeza una puntualización🙂

    Sobre la duración del sprint, puede ir de 2 a 6 semanas.

    Y hay un concepto que no comentas y que estaría bien nombrarlo, se trata del scrum of scrums, se hace cuando los equipos son muy grandes, para dividirlos.

  2. ¡Muy bien visto!

    En Wikipedia y otras fuentes dice, efectivamente, entre 2 y 6 semanas. En el libro de Ken Schawber ví en todas partes que recomendaba 30 días. Me llamó la atención. Al final lo dejé así aunque aceptamos pulpo como animal de compañía XDD. Igual el tío este ni sabe cuánto es lo mejor…

    Sobre el Scum of Scrums: también es absolutamente cierto. No he querido hablar de ello por no extenderme más (aunque visto lo visto…), como tampoco he querido hablar del gráfico “burn down”. Sobre esto que dices Ken dedica un par de capítulos y al final no me queda muy claro el éxito o fracaso de este montaje cuando existen varios equipos de desarrollo.

    De todos modos, son dos líneas, así que ya de puestos las voy a añadir. Muchas gracias y muy atento, sí señor.

  3. Supongo que la duración del sprint dependerá muchas veces del equipo y del cliente, si un equipo no es capaz de hacer algo funcional en 2 semanas tener sprints de dos semanas es totalmente inutil y con 6 semanas es más fácil perder el foco, supongo que también depende del equipo.

    Yo he formado parte de un equipo dentro de scrum of scrums y cuando los equipos están divididos pero son dependientes es bastante importante coordinarse y que los equipos sepan un poco dónde están los otros equipos o si una tarea suya bloquea otra (sobre todo a la hora de priorizar). Cuando yo lo usé el Scrum Master era el nexo de unión de los equipos, no tengo ni idea de si esa es la idea original o no.

  4. Sí, hasta donde yo conozco el ScrumMaster sigue siendo el mismo, no hay uno por cada grupo.

    “[…]cuando los equipos están divididos pero son dependientes es bastante importante coordinarse y que los equipos sepan un poco dónde están los otros equipos o si una tarea suya bloquea otra (sobre todo a la hora de priorizar).”

    Esto que dices explica perfectamente el funcionamiento del Scrum of Scrums, al menos así lo entendí yo.

  5. Lo dudo mucho, la definición la saqué de la versión del libro original de Ken Schwaber…

    Si así lo requieres, te lo busco y lo posteo aquí, indicando página y capítulo.

    ¡Un saludo!

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s