Advertencia: al final de este artículo podrás empezar a usar Scrum
en tus proyectos.
 |
| Marco de Trabajo Scrum |
Presentación
Cuando publiqué la lista
de chequeo de Scrum, asumí que mis lectores ya conocían este marco de trabajo (para software o productos y servicios de otro tipo) o que estarían familiarizados con el concepto de prácticas y técnicas ágiles y que conocían el suficientemente expuesto manifiesto ágil. Pensé
que no hacía falta abordar los aspectos
más básicos del asunto. Me equivoqué. Acaso para algunos de nosotros esta sea
la primera vez con Scrum, el primer contacto con un marco de trabajo ágil, la
primera incursión en esta forma de construir productos de software. Así es que
decidí volver a lo fundamental. Aquí vamos otra vez.
Scrum es un marco de
trabajo liviano e iterativo de gestión de proyectos que ayuda a los equipos a
ejecutar y a entregar exitosamente el valor de negocio más alto en el tiempo
más corto posible. Este método es particularmente bien apropiado para entornos
donde los requisitos están sujetos a cambios continuos o donde los requisitos
no se entienden correctamente. “Scrum es un marco de trabajo con el cual
podemos afrontar problemas complejos y adaptativos y con el cual podemos
emplear distintos procesos y técnicas, así como también podemos optimizar
nuestra predictibilidad y tener un mejor control de los riesgos”[i].
Métodos Ágiles
Pero Scrum no es el único
método ágil que podemos encontrar. Algunos otros marcos de trabajo ágil son:
·
Adaptive Software Development (ASD)
·
Crystal Clear
· Kanban
· Extreme Programming (XP)
· Dynamic System Development Method (DSDM)
· Extreme Programming (XP)
· Dynamic System Development Method (DSDM)
·
Feature Driven Development (FDD)
·
Lean Software Development (LSD)
·
Open Unified Process (OpenUP)
· Essential unified process (ESSUP)
La Filosofía Ágil
Todos estos métodos tienen
sus cimientos en lo que se conoce como Filosofía Ágil:
·
Usted no puede
predecir o planear con absoluta certeza lo que va a entregar, cuándo lo
entregará y cuánto será su costo.
·
Empiece con planes
iniciales alrededor de las estimaciones, fechas y alcance, pero enfóquese en la
revisión continua de estas restricciones a medida que avanza.
·
La meta es entregar
el mejor software posible, dadas estas restricciones, pero ningún método con el
enfoque de receta de cocina mejorará lo que es “mejor”.
Scrum
Scrum define
explícitamente tres roles, cuatro ceremonias y cuatro artefactos principales. El
Dueño del Producto, el Equipo de Desarrollo y el Scrum Master son quienes
tienen bajo su responsabilidad entregar software probado y funcionando cada
cuatro semanas o menos. Todos ellos forman el Equipo Scrum que, además de las
actividades regulares de desarrollo de software, realiza cuatro ritos durante
cada iteración que en Scrum se llama Sprint: Planificación del Sprint, Reunión
Diaria, Revisión del Sprint y Retrospectiva. Durante estas ceremonias, el
equipo actualiza la Lista (Backlog) del Producto, la Lista de Pendientes (Backlog) del Sprint y la Lista de Impedimentos; y al final entrega un incremento del producto potencialmente distribuible.
Actores en Scrum
El Dueño del Producto es
la persona encargada de maximizar el valor del producto elaborado por el equipo
de desarrollo. Es quien define y prioriza los ítems de la bitácora de producto
y quien proporciona al equipo todo el conocimiento del negocio necesario para
que este sea transformado en software. Entre tanto, el Equipo de Desarrollo es
el responsable de construir el producto, teniendo en cuenta las necesidades y
prioridades del dueño del producto. En Scrum no existen roles especializados,
es simplemente el equipo, comprometido todo con el éxito del proyecto.
Finalmente, el Scrum
Master es un servidor, es quien vela porque se ejecute el proceso como está
definido y que se lleven a cabo cada una de las ceremonias Scrum como está
consignado en la Guía de Scrum. También es el encargado de introducir nuevas
prácticas al proceso y al proyecto, acompañando de cerca su implantación y
monitoreando los resultados. Es importante aclarar que el Scrum Master no es un
gerente, aunque bien podríamos decir que hace parte de y reporta al área de
manejo de la organización, por ejemplo, a la oficina de proyectos. Contando el
SM, el equipo Scrum no debe superar las 9 personas.
Ceremonias y Artefactos Scrum
En un proyecto gestionado
bajo el manto de Scrum, todo ocurre en el marco de un Sprint: este es una
iteración de un tiempo máximo de 4 semanas. La industria del software está
gritando a cielo abierto que este tiempo sea de solo 2 semanas o de menor duración. Al principio
del Sprint se realiza la Planificación del Sprint. En esta reunión, el dueño del
producto asiste con la Lista del Producto actualizada y priorizada, de
acuerdo con las necesidades del negocio. Junto con el equipo de trabajo, se
seleccionan algunos de los elementos de la lista, usualmente los de mayor valor para el negocio, para ser desarrollados durante la iteración.
Con estos elementos seleccionados se conforma lo que se llama la Lista de Pendientes del Sprint, el trabajo del sprint. A
continuación, el equipo de desarrollo define cómo hará el desarrollo y estima
el esfuerzo necesario para cada uno de los elementos seleccionados, teniendo en cuenta que el
esfuerzo máximo es el definido para el sprint, ni un minuto más. Con estas
premisas, el Equipo en pleno elabora la Definición de Terminado y se asegura que todo el mundo la entienda y la comparta. Esta
“definición de Terminado” se convierte en una especie de “contrato” del sprint, define las
cláusulas sine qua non el incremento
del producto no satisface a su dueño ni a la organización.
Con la definición de Terminado en la mente de los miembros del equipo Scrum, este inicia el ciclo de vida del
software. Todos los días, a la misma hora y en el mismo lugar, de pie y durante
15 minutos máximo, el equipo se congrega en la Reunión Diaria. En esta sesión,
cada integrante del equipo responde tres preguntas: ¿qué hice ayer? ¿Qué haré
hoy? Y ¿Qué problemas tengo? Solo tres y nada más que tres. Esta reunión no es
para saludarse ni para hablar de asuntos que no estén relacionados con el
proyecto o con las personas que lo ejecutan. Tampoco es para resolver los
problemas expuestos.
De la reunión diaria sale
actualizada la Lista de Impedimentos, la cual es tratada fuera de la reunión,
por cada uno de los responsables de solucionarlos. En Scrum, el equipo es
autogestionado, multidisciplinario y debería tener la capacidad de resolver sus
propios problemas sin la ayuda de alguien externo. Hacia el final de la
iteración, se realiza la Revisión del Sprint. En esta sesión, el equipo Scrum y
los interesados realizan un escrutinio de lo que se hizo en el sprint y ajustan
la lista del producto si fuese necesario. En definitiva, el dueño del
Producto verifica que se haya cumplido la Definición de Terminado.
Justo a continuación de la
revisión, se hace una Retrospectiva del Sprint: ¿Qué hicimos mal que no
repetiremos? ¿Por qué no se alcanzó la Definición de Terminado? ¿Qué hicimos bien
que podemos mejorar? ¿Qué hicimos bien que seguiremos haciendo tal cual? Estas
son algunas de las cuestiones que, con ayuda del Scrum Master, se responden en
esta reunión. En esta sesión también deberíamos separar unos instantes para
realizar una introspectiva: ¿Cómo
está nuestro estado de ánimo? ¿Seguimos? ¿Paramos? Si seguimos, ¿qué acciones
de mejoramiento podemos introducir a partir del siguiente Sprint?
Conclusión
Estos son, grosso modo, los elementos que subyacen
el método Scrum. Todas las ceremonias tardan un tiempo fijo definido en el
libro de reglas de Scrum o Guía de Scrum. No hay que saber nada más para
comenzar a usar el marco de trabajo. Y para usarlo hay que ser ágil, porque Ágil
es algo que eres, no algo que haces. Una vez que puedes diferenciar esto,
entonces convertirse en ágil será algo fácil. Extrapolando, una organización no
puede forzar la filosofía ágil en su cultura, sino que debe permitir que su
cultura evolucione hacia un estado ágil. Ágil es un estado de la mente, es una
forma de pensar y de ver las cosas.
Se me olvidaba decirles,
la retrospectiva siempre debe hacerse al final de cada sprint, a menos que el
equipo esté bien ocupado. En cuyo caso, se deberían hacer dos.
Lecturas Adicionales
Mi artículo de Scrum
Fundamental lo encuentran en este mismo Gazafatonario, en: http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html.
El libro de reglas de Scrum, la guía de Scrum, lo
encuentran en:
La lista de verificación de Scrum que desató esta serie
de artículos la encuentran en: http://www.gazafatonarioit.com/2013/05/lista-de-chequeo-scrum.html.
Otros sitios que pueden visitar para aprender más de
Scrum y libros que pueden leer son:
[i] La
Guía de Scrum. © 1991-2011 Ken Schwaber y Jeff
Sutherland, Todos los Derechos Reservados.
