Qué es Scrum
Scrumes un marco de trabajo ágil para el desarrollo y mantenimiento de productos. Se usa habitualmente en proyectos de software, aunque se puede aplicar en otras actividades.
Como casi cualquier otra técnica o metodología, Scrum tiene grandes detractores y defensores. Las discusiones por las ventajas y desventajas de este framework son legendarias.
Veamos en qué consiste la metodología Scrum, de qué forma puede usarse en los proyectos y ya decides si es lo que te va bien.
Una revisión rápida de Scrum
Muy breve, el Scrum es la aplicación metodológica de algunos principios básicos para lograr productos de la mayor calidad posible.
- Hay que enfocarse en productos mínimos viables. Si se puede hacer en una tarde mejor que en un año. En Scrum este periodo oscila entre una semana y un mes, normalmente.
- Los productos en desarrollo casi siempre son imperfectos, sobre todo en las primeras etapas. En lo que ha imaginado el cliente, o nosotros mismos, no se están considerando todas las posibilidades y probablemente se deja fuera algo significativo. Por eso se trata de lanzar rápido y se va iterando sobre el producto, a partir de la interacción con el cliente y los usuarios. No confundir iterar, con interaccionar, lo primero es repetir varias veces un proceso con el objetivo de alcanzar un resultado, mientras que lo segundo es la acción recíproca entre dos o más personas.
- Los buenos productos los construye gente experimentada, dado que se trata de hacer algo rápido, pero tan funcional como sea posible, la experiencia del equipo para completar los espacios y unir puntos es esencial.
Resumiendo, en Scrum hacen falta equipos pequeños, autónomos, que pueden resolver problemas. Por tanto la experiencia y la inteligencia son vitales, no es un trabajo de autómatas rellenadores y/o seguidores de formularios.
El ciclo de Scrum resumido
- El Product Owner crea un Product Backlog, de acuerdo con el cliente. Básicamente una lista de requerimientos a completar.
- El Equipo realiza un Sprint Planning Meeting. El proyecto se divide en tareas y se reparten.
- Se crea un Sprint Backlog, donde se definen los Springs con objetivos detallados.
- Se define un tiempo asignado a cada Spring, normalmente entre una y cuatro semanas.
- El equipo se reune a diario en un Daily Standup, para que cada miembro detalle su progreso y que el Scrum Master y al resto del equipo estén informados.
- Al final de cada Spring se llevan a cabo una Revisión y una retrospectiva del Spring.
Una breve historia de Scrum
Scrum fue definido originalmente por Hirotaka Takeuchi e Ikujiro Nonaka, en 1986, en un artículo para Hardvard Business Review.
Los autores planteaban un nuevo enfoque para el desarrollo de productos comerciales, que permitiera lanzarlos rápidamente, aplicando una metodología flexible.
La metodología se basaba en la inteligencia y no en la replica de fórmulas que se entendían insuficientes en aquella época. Parecerá una perogrullada, pero menudos visionarios.
En los primeros 90 Ken Schwaber y Jeff Sutherland, primero por separado, y luego en equipo, evolucionan el modelo. En 2001 aparece el que será el documento fundacional del movimiento: The Agile Manifesto. Sigue el enlace para la versión en español.
La filosofía de Scrum
En la metodología Scrum se aplica una estrategia de desarrollo incremental basada en buenas prácticas. El producto se va creando por fases, lo más breves posible, para obtener un feedback continuo del cliente y/o los usuarios, y así aplicarlo como mejoras en la etapa en curso o en fases sucesivas.
La metodología Scrum sienta un principio que cualquier desarrollador experimentado descubre muy pronto: los proyectos reales y la teoría aprendida tienen poco que ver. Y la enseñanza más importante es que en una mayoría de casos, las necesidades y los deseos de los clientes están cambiando continuamente.
Scrum parte de la base de que el problema no puede ser entendido en su totalidad con la información que se tiene en cada momento. Por eso se aprovechará la inteligencia y experiencia del equipo para resolver el problema con los datos disponibles. Enfocándose en la entrega ágil de versiones que vayan resolviendo los nuevos requerimientos que vayan apareciendo, inevitablemente.
Roles en Scrum
En Scrum hay tres roles principales: el Product Owner, el Scrum Master y el Development Team.Un proyecto Scrum no puede funcionar sin alguno de ellos.
Aunque en un proyecto pequeño, una misma persona puede llevar a cabo más de un rol, la realización de cada uno es imprescindible para el éxito del proyecto.
Por ejemplo, sería perfectamente posible que en un proyecto el Product Owner y el Scrum Master sean la misma persona y que, además, forme parte del Development Team. Es bastante trabajo y requerirá una experiencia más amplia, pero dependiendo del tipo de proyecto y la dinámica del equipo o la organización, posible es.
Product Owner
En español, dueño del producto, es el representante del proyecto dentro del equipo de trabajo, aunque no es obligatorio que sea parte del staff del cliente. Su principal tarea es la de concretar con claridad las necesidades del cliente en el Product Backlog. Es el máximo responsable en un proceso Scrum.
El Product Owner frecuentemente se equipara a un analista o consultor, que se encarga de recopilar toda la información y conocer las necesidades del cliente. Por tanto es un magnífico interlocutor, un perfil experimentado, con la capacidad de concretar los requerimientos y funcionalidades, para trasladarlos con tanto detalle como sea preciso.
El Product Owner transmite estas necesidades a los miembros del equipo y especialmente al Scrum Master.
Scrum Master
Es un facilitador, un moderador, se podría definir como el líder del equipo de trabajo. Es el responsable de asegurar que el Scrum es entendido por el Development Team. Su labor principal es la deeliminar cualquier escollo que pueda impedir el cumplimiento de los objetivos de plazos y entregables.
El Scrum Master se preocupa de que el equipo trabaje de acuerdo con las reglas y la práctica del Scrum.
Development Team
Es el equipo de desarrollo. Se compone de las personas responsables de dar cumplimiento a los Sprint. Son un equipo experimentado, autogestionado y organizado. Son los desarrolladores, tester, analistas, diseñadores…
El equipo mínimo está compuesto por tres miembros y no se recomienda sobrepasar los nueve. Los equipos de no más de cinco personas suelen ser los más eficientes. Yo he tenido magníficos resultados con equipos de tres miembros.
Ciclo de vida del proyecto Scrum
Los procesos del marco de trabajo Scrum se plasman en documentos denominados artefactos. Los tres principales artefactos son: el Product Backlog, el Sprint Backlog y el Incremento.
El product Owner definirá enun primer artefacto, la lista completa de funcionalidades, ideas, requisitos y necesidades obtenidas del cliente. Ese artefacto es el Product Backlog.
Sprint Planning Meeting
En una reunión denominada Sprint Planning Meeting, el Product Owner transmitirá estas necesidades al Development Team y al Scrum Master. En esta reunión se planea cómo se dará solución a una primera fase del producto que deben construir.
Del Sprint Planning Meeting surgirá una lista de funcionalidades y requisitos, que se escogen entre las definidas en el Product Backlog. Este nuevo artefacto es el Sprint Backlog.
El Sprint
Los requisitos que surgen de cada meeting deben llevarse a cabo, idealmente, en un plazo de entre una y cuatro semanas. Dependerá de la cantidad y complejidad de las funcionalidades definidas en el Sprint Backlog.
Estos periodos deben adaptarse a la experiencia y las dinámicas del equipo de trabajo, además de a las prácticas de la organización. Así en algunos casos podrán ser más cortos, pero no es recomendable que se alarguen más.
Este periodo se llama Sprint y es el corazón del marco Scrum.El Sprint es una iteración, que se corresponde con una etapa del proceso de construcción incremental del producto.
En el Sprint trabaja el Scrum Master junto al Team Development, son los encargados de desarrollar las funcionalidades definidas en el Sprint Backlog.
En este punto el papel del Scrum Master como conseguidor es determinante. Se encargará de ayudar y engrasar todo lo necesario para que el Team Development pueda cumplir los objetivos. También puede ser miembro del Team Development, aunque sin perder de vista cuál es su misión principal: que el TD entienda muy bien que es lo que debe hacerse, ayudándoles a lograrlo.
Si el Scrum Master falla en su labor, el proyecto no saldrá adelante.
Scrum diario o Daily Standup
En los meetings diarios, el Development Team y el Scrum Master se reunen para hacerun seguimiento de las tareas en marcha.Se hacen siempre a la misma hora, en un mismo lugar, independientemente de que falte algún miembro.
Se trata de realizar reuniones cortas, idealmente no más de 15 minutos, en las que se pregunta a cada miembro, que informarán de los trabajos realizados el día anterior y comentan las tareas para el día en curso.
El propósito en esta reunión es que todos los miembros del equipo estén informados de lo que está sucediendo. Para hacerlo de forma ágil deben hacerse de pie y seguir el procedimiento.
Si hay que ampliar algún tema, concretar cualquier punto o solucionar un problema, se hará al final de la reunión. Nunca se interrumpe la dinánima establecida.
Cualquier desviación sobre lo planeado se reflejará en el tablero de progreso del Sprint, que es accesible para todos los miembros del equipo, tanto si son post-tit, como si se utilizan herramientas de gestión de proyectos como Asana, Jira, Monday, Trelloo cualquier otra.
Revisión y retrospectiva del Sprint
Al finalizar cada Sprint se realizan dos reuniones, la revisión del Sprint,propiamente dicha y la retrospectiva del Sprint.
En la revisión se presentan los trabajos completados en el Sprint en curso. Se recomienda que la duración no supere las cuatro horas.
La función de la retrospectiva del Sprint es que cada miembro analice lo que ha sucedido, comentando técnicas o cualquier aspecto que ayude a entender qué ha ocurrido y cómo se han resuelto los posibles problemas. Tampoco debería superar las cuatro horas.
Scrum es un proceso de mejora continua, por tanto las impresiones del equipo son vitales para mantener el progreso.
Desventajas de Scrum
No hay ninguna solución que pueda satisfacer a todo el mundo. Por eso existen numerosos marcos de trabajo y metodologías de desarrollo de productos, generalistas o específicas. En el caso de Scrum, las desventajas más notables podrían ser:
- Puede dar la impresión de que los proyectos basados en Scrum tienden a durar más tiempo, al no tener una fecha de finalización definida. Esto es discutible, porque a menudo no se está comparando el resultado final obtenido con cada metodología.
- Se dice que las posibilidades de fracasar son mayores que en otras metodologías. Principalmente porque se apoya en el trabajo de pocos miembros, muy cualificados, la salida del proyecto de uno de ellos supone un serio contratiempo. Si la cooperación y motivación son esenciales en cualquier proyecto, en Scrum más.
- Por la misma razón Scrum solo funciona si contamos con profesionales muy experimentados, los junior necesitan referencias, veteranos que les ayuden a desarrollarse.
- No es posible aplicar Scrum con grandes equipos, digan lo que digan no funciona. Hace falta una adaptación del framework o usarlo en combinación con otras metodologías.
- Las reuniones diarias pueden crear estrés y frustración entre los miembros menos experimentados. Hay que ayudarles a aprovecharlas para su crecimiento personal y profesional. Esta es una de las tareas fundamentales del Scrum Master.
- Lograr estándares altos de calidad solo es posible con una gran disciplina. El seguimiento de las tareas realizadas y la implementación de métodos de prueba estrictos son obligatorios. Algo que, por otra parte, debería ser aplicable a cualquier otra metodología.
Las ventajas de Scrum
Scrum es una metología que ayuda a los equipos a mejorar su forma de trabajo, al lograr entregas en plazos más cortos y de manera más eficaz.
- Es más eficiente, también desde el punto de vista económico. Aunque los proyectos puedan alargase, se logra mas en menos tiempo.
- Todos los implicados en el proyecto, desde el cliente, hasta los miembros del equipo de desarrollo tienen una mejor visión. Tanto del conjunto, como en detalle.
- Promueve una participación activa. La interacción continua permite obtener un producto más cercano a las necesidades reales, que a menudo no coinciden con los requerimientos iniciales.
- La aportación de cada miembro del equipo se muestra a diario en cada reunión.
Conclusión
Como indicaba al principio los debates sobre ventajas y desventajas duran ya unos cuantos lustros. No me considero un especialista en Scrum, pero si en crear productos de software y dirigir equipos desde hace 30 años. Después de seguir casi todas las prácticas indicadas en Scrum, puedo asegurar que es adaptable en buena medida en la mayor parte de equipos y proyectos actuales.
Se llame Scrum al marco, Scrum Master al responsable del proyecto, o de cualquier otra manera, lo cierto es que nos sitúa ante una problemática referente al desarrollo del software que ninguna metodología puede resolver fácilmente: personas, profesionales, que hacen uso de tecnologías en constante evolución, con una enorme presión, bajo demandas que generan mucho estrés.
He visto como los profesionales repiten la misma curva de comportamiento una y otra vez: ilusión, absorber conocimiento, aumentar la experiencia, eficiencia, cansancio, estrés, desilusión, desactualización… Y aquí los finales son muy diferentes. Pero dejar rotos a profesionales con 30 ó 35 años no puede ser rentable para ninguna organización, ni por supuesto para la sociedad. Creo que Scrum puede ayudar a gestionar este escenario.
Un buen Scrum Master deberá resolver problemas muy importantes. Pero los directivos de las organizaciones que viven del desarrollo de software o de su uso, deberán encontrar el equilibrio entre los objetivos empresariales y de negocio. Contar con profesionales tan competentes como productivos, es tan importante como conseguir retener el talento. Scrum puede ayudarles a que trabajen de una forma más dinámica, pero también más participativa, que les puede motivar para crecer profesionalmente.
Imagen: Raimond Spekking
