En primer lugar empecemos definiendo a Scrum, pues bien, se trata de un Framework o marco de trabajo ágil que permite el trabajo colaborativo y ágil en un equipo, es oportuno aclarar de entrada que no se trata de una metodología, pero que al reemplazar la función de una metodología en proyectos de software se acrecentó la confusión, por ejemplo en una consultora lo que antes se hacía con RUP o cualquier Cascade hoy se hace con Scrum, he allí el origen del desbarajuste 🤓. Este framework en cambio se trata de algo más simple, ligero y menos estructurado, como bien lo definen sus creadores, cito textualmente:
Scrum es un marco ligero que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptables para problemas complejos.
Scrum guide, Ken Schwaber & Jeff Sutherland
En esta entrada pongo Scrum y no SCRUM porque no es un acrónimo sino más bien una palabra tomada del rugby.
Hablar de Scrum es hablar de Sprints, así que comencemos por enterarnos que es un sprint ya que a lo largo del flujo de trabajo con Scrum trabajaremos en un sprint.
SPRINTS
Es un intervalo de tiempo que el equipo establece como base para a partir de él trabajar, es entonces en ese lapso de tiempo que se presentan avances del proyecto al cliente. Este periodo de tiempo puede ser de dos o hasta tres semanas y se recomienda que en un proyecto se use un intervalo constante, es decir si se decidió que los sprints sean de dos semanas, respetar eso. Al finalizar el proyecto se puede analizar los resultados y hacer ajustes para los siguientes.
El proceso de un proyecto bajo el enfoque ágil con Scrum también se ve reflejado en este gráfico que observé en una charla, el gráfico me pareció muy bueno y completo, por eso aquí lo comparto con ustedes:
Si las imágenes de arriba te confundieron, no te preocupes genio, luego de leer este artículo vuelve a verla y la comprenderás. Ahora si vamos a mayor detalle, como marco de trabajo que es, Scrum nos plantea una serie de "cosas" que nos ayudarán a manejar un proyecto dado, no sólo proyecto de desarrollo de software sino cualquier otro tipo de trabajo colaborativo, los principios de Scrum proponen estas tres piezas fundamentales, posteriormente hablaremos de cada una de ellas en un lenguaje claro, sencillo y con seguridad ya que todo lo mencionado aquí fue aplicado en proyectos reales:
- Roles
- Artefactos
- Eventos
Roles
Los roles son responsabilidades asignadas a uno o más miembros del equipo, tenemos los siguientes:
Los roles no son intercambiables durante el proyecto ni tampoco una persona puede desempeñar más de uno.
- Scrum master(SM) : Se encarga de velar por el cumplimiento adecuado de las reglas de Scrum en el equipo y de facilitar todo lo que esté a su alcance para asegurarse que así sea. Gerencia la interrelación entre los demás roles siempre pensando en el logro de objetivos del proyecto, no sólo en hacer cumplir la "letra o reglas del framework". Como hemos visto, sus funciones son de guía, líder, moderador y facilitador, no debe malinterpretarse como "el jefe del equipo", sin duda un rol importante ya que es líder.
- Product Owner (PO) o dueño de producto: Es el encargado de decidir que trabajo debe hacerse, cuando y cómo, para ello elabora las historias de usuario (por ejemplo en Azure Devops). Trata siempre de maximizar el valor del producto, tratando que sea lo más eficiente posible con los recursos que posee tanto materiales como de capacidades técnicas profesionales. Es la cara visible de la empresa para con el cliente y debe conocer el producto al revés y al derecho.
- Technical Product Owner (TPO): Este es un rol al cual guardo especial cariño ya que lo desempeñé tiempo atrás. Debido a la alta demanda y responsabilidad de los PO especialmente para proyectos grandes y complejos, algunos equipos han integrado al famoso TPO el cual viene a ser el brazo derecho técnico del product owner ayudándolo en tareas más técnicas como la definición de arquitecturas, las viabilidades técnicas, la estimación de tiempos de trabajo, testing y validación de cumplimiento de tareas, code reviews y cumplimiento de estándares de programación y seguridad, entre otras tareas que de preferencia las realiza con el líder técnico o el desarrollador más experimentado. En síntesis es la cara visible del equipo de desarrollo para con el PO y es quien usualmente dirige los daily meetings, una reunión de la cual hablaremos más abajo.
- Development Team o equipo de desarrollo: Para un proyecto de software vienen a ser los desarrolladores, programadores, ingenieros de software, arquitectos, líderes técnicos, QA, testers, cloud engineers, infraestructura, TI y devOps, es decir aquí está el 💪, las abejas obreras 🐝 que empujan el coche. Cada uno de estos cracks tiene asignado PBIs los cuales van trabajando y se espera que los terminen antes de la finalización del sprint. Diariamente se reunen con el TPO y PO.
- Stakeholders: Son agentes externos al equipo scrum o a la empresa desarrolladora, pero que intervienen indirectamente en el proyecto ya que algunos de ellos son los que pagan la cuenta jaja 😂, así que cómo no iban a estar? Tenemos por ejemplo a los clientes, proveedores, vendedores, finanzas, etc. todos ellos dan soporte al equipo. Con quien más interacción tienen ellos es con el Product owner, dejando al equipo hacer lo que más saben hacer y estableciendo una línea de comunicación directa que no perturbe al equipo ni a su eficiencia, esto es una de las cosas que más me gustan de Scrum, sino imagínense que a los programadores se les diga que la fórmula de cálculo del salario de aquel sistema de planillas debe ser X, luego venga finanzas y directamente hable con ellos y les diga que no, que es Y y finalmente el gerente viene y les dice que el manda acá y que debe ser Z 🙄, eso sería un caos cierto?
Artefactos
- Product backlog (PB): Es un inventario de todas las cosas que hay que hacer y está conformada por Product Backlog Items (PBI) los cuales pueden estar en diversos formatos como tareas, features, casos de uso, requerimientos, historias de usuario, anotaciones simples, etc. Cada una de estas partes integrantes reciben un código así como una descripción y demás detalles que se le quiera agregar como criterios de Aceptación y observaciones. Sólo el PO o TPO gestionan el PB.
- Sprint backlog: Es la lista de los PBI asignados a determinado sprint, el cual el development team se encargará de desarrollar en el sprint actual. Cada PBI tiene un estado que puede ser pendiente, en curso y terminado, esto permite saber la evolución y avance del trabajo en el sprint actual para ajustar tiempos oportunamente y llegar a las fechas límite.
- Product Increment o incremento del producto: Es el resultado obtenido al finalizar un sprint, se trata de un avance funcional del proyecto, no puede ser texto, imágenes o diapositivas ni maquetas, sino algo funcional.
Puedes hallar más información en este excelente artículo del buen Julio Roche, director en Deloitte, asimismo, este otro artículo también es notable.
Eventos (también conocido como reuniones o ceremonias)
Si bien es cierto se le puede llamar ceremonias, no quiere decir que son eventos parametrizados y mecánicos, para nada.
Son acontecimientos definidos en el framework los cuales, salvo uno, se van desarrollando en cada sprint, es decir se repiten cada cierto tiempo hasta la culminación del proyecto, tenemos 5:
- PBI Definition: Aquí de definen todos los items del Product backlog, es el único evento que no se repite en cada Sprint, aunque a lo largo del tiempo sus items pueden aumentar, disminuir o actualizarse, la definición sólo se da al inicio del proyecto.
- Sprint planning: Se da cada inicio de sprint y se identifica según tiempo y prioridad cuantos y cuales PBI se van a desarrollar en el sprint actual.
- Daily scrum o daily meeting: Es una reunión diaria que dura máximo 15 minutos en los cuales todo el equipo (al decir equipo siempre me refiero al SM, PO y Team) se reunen ya sea presencialmente o de forma remota para que cada miembro del development team comente estas 3 cosas: ¿Que trabajaste ayer? ¿Qué haras hoy? ¿Que bloqueos o impedimentos tienes? La finalidad es que todo el equipo esté enterado de lo que están haciendo los demás y de identificar problemas de forma temprana. En esta reunión se va al grano, se evitan divagaciones.
Las tres preguntas mencionadas del daily son una recomendación, no son obligatorias y puedes cambiarlas, la idea es que esta importante reunión no se haga mecánica, eso sería fatal.
- Sprint review: La revisión se da al finalizar cada sprint y es aquí donde se presentan todos los avances realizados, no debe exceder de preferencia las 2 horas.
- Sprint retrospective: Al finalizar cada sprint se da la retrospectiva, y todos los integrantes del equipo dejan sus opiniones y propuestas de mejora, esto se hace para lograr la mejora continua del equipo.
En retrospectiva...
En este artículo hemos podido comprobar el porqué se dice que Scrum es flexible y ágil además de fomentar el trabajo colaborativo, nota que todo en este framework es en equipo, además el tener sprints permite una iteración con tendencia a mejorar cada vez, además de permitir cambios de último momento que nunca faltan en los proyectos, sobre todo de software.
Antes de culminar, es bueno saber que al ser un marco de trabajo, podemos hacerle pequeñas variantes que se acomoden mejor al trabajo con nuestro equipo, nada está escrito en piedra en Scrum y eso lo hace muy versátil, claro que también hay que seguir sus lineamientos y principios, las variantes no deben cambiar esto ya que sería contraproducente, en cuanto a variaciones podemos permitirnos por ejemplo: dejar de hacer un evento, o agregar uno como por ejemplo algunos equipos lo hacen al agregar el Sprint refinement, también podemos combinar este framework con tableros kanban. Lo importante es que una vez hayamos encontrado nuestro Framework efectivo para el equipo no lo cambiemos a cada momento.
Finalmente, es por eso estimado lector de la buena fama y el hype ganado por Scrum, aunque claro como todo en la vida, no es perfecto, sin embargo su eficacia es comprobada, y bien aplicado puede generar resultados increíbles y equipos con un sentido de realización en vez de frustración. Anímate a probarlo y deja de postergarlo, con este artículo ya puedes defenderte en cualquier equipo de trabajo en la industria del software, lo que resta es que practiques 😉.
Ya sabes crack si este contenido te ha aportado algo de valor compártelo, y que tengas una excelente semana máquina 🤓
Información adicional y fuentes empleadas:
https://www.scrum.org/resources/blog/que-es-scrum
https://www.sprintagil.com/blog/combinar-roles-scrum
https://www.atlassian.com/es/agile/scrum
https://integrait.com.mx/blog/roles-de-scrum/
https://www2.deloitte.com/es/es/
Y por último: la experiencia propia y de amigos en la cancha, unos cracks en proyectos ágiles 🚀.
Good day! I know this is kinda off topic however , I’d figured I’d ask. Would you be interested in trading links or maybe guest writing a blog article or vice-versa? My site goes over a lot of the same subjects as yours and I think we could greatly benefit from each other. If you might be interested feel free to shoot me an e-mail. I look forward to hearing from you! Great blog by the way!