3.
FASES DE SCRUM
SCRUM comprende las siguientes fases:
3.1 Pre-juego
La fase previa al juego incluye la planificación y las implementaciones
arquitectónicas; La fase de desarrollo incluye el desarrollo iterativo utilizando
enfoques típicos de SDLC. (Pavan Kumar, 2009)
3.2 Juego
Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versión con
respeto continuo a las variables de tiempo, requisitos, costo y competencia. La
interacción con estas variables define el final de esta fase. El sistema va
evolucionando a través de múltiples iteraciones de desarrollo o sprints. (Ken
Schwaber, 1997)
3.3 Post-juego
Contiene el cierre del release. Para ingresar a esta fase se debe llegar a un
acuerdo respecto a las variables del entorno por ejemplo que los requerimientos
fueron completados. El sistema está listo para ser liberado y es en esta etapa
en la que se realiza integración, pruebas del sistema y documentación. (Adriana
Peralta, 2003)
Ilustración 1. SCRUM Phases. Scrum Development Process. Recuperado de
http://www.scrummanager.net/bok/images/7/7c/Scrum_Development_Process.pdf
Pasos de la planificación
Desarrollo de un backlog completo.
Determinación de la fecha de entrega y la funcionalidad de una o más
versiones.
Selección de la versión más adecuada para desarrollo inmediato.
Trazado de los “paquetes del producto” (objetos) sobre los elementos del
backlog de la versión elegida.
Selección del equipo o equipos para desarrollar la nueva versión.
Evaluación y control adecuado de los riesgos.
Estimación del coste de la versión, incluyendo desarrollo, material,
marketing, formación y despliegue.
Conformidad de la dirección y financiación del proyecto.
Pasos de diseño y arquitectura
Revisión de los elementos del backlog incluidos en la versión.
Identificación de los cambios necesarios para implementar el backlog.
Análisis del dominio para incluir los requisitos que incluye el desarrollo
mejora o actualización.
Acotar la arquitectura del sistema para apoyar el nuevo contexto y
necesidades.
Identificar problemas del desarrollo o modificaciones.
Reunión de revisión de diseño. Cada equipo presenta los cambios para
implementar los elementos del backlog, e identificar posibles
reasignaciones.
Pasos del desarrollo (Sprint)
La fase de desarrollo es un ciclo de trabajo repetitivo. La gestión determina el
cumplimiento de los tiempos, funcionalidad y calidad. Este enfoque es conocido
también como ingeniería concurrente. (Ken Schwaber, 1997)
En esta fase se espera que ocurran cosas impredecibles. (Adriana Peralta,
2003)
El desarrollo consiste en los siguientes macro-procesos:
Reunión con los equipos para revisar los planes de lanzamiento de versión.
Distribución, revisión y ajuste de los estándares de conformidad para el
producto.
Sprints iterativos hasta que el producto se considera listo para su
distribución.
Un Sprint es el procedimiento de adaptación de las cambiantes variables del
entorno (requerimientos, tiempo, recursos, conocimiento, tecnología). Son ciclos
iterativos en los cuales se desarrolla o mejora una funcionalidad para producir
nuevos incrementos. Durante un Sprint el producto es diseñado, codificado y
probado. Y su arquitectura y diseño evolucionan durante el desarrollo. (Adriana
Peralta, 2003)
Cada sprint consiste en uno o varios equipos realizando:
Desarrollo: Definición de los cambios necesarios para la implementación
de los requisitos del backlog en módulos, la apertura de los módulos,
análisis del dominio, diseño, desarrollo, implementación, pruebas y
documentación de los cambios. El Desarrollo consiste en el micro proceso
de descubrimiento, invención e implementación.
Envoltura: Cierre de los módulos, creación de una versión ejecutable con
los cambios que implementas los requisitos del backlog.
Revisión: Reunión de todos los equipos para presentar el trabajo y revisar
el progreso, identificando y resolviendo posibles cuestiones y añadiendo
nuevos elementos al backlog. Se revisan los riesgos y las respuestas
apropiadas.
Ajuste: Consolidación de la información de la revisión de los módulos
afectados.
Cada sprint es seguido de una revisión cuyas características son:
Está presente y participa el equipo al completo.
La revisión puede incluir a clientes, personal de ventas y otros.
La revisión cubre los sistemas funcionales y ejecutables abarcados por el
equipo e incluye los cambios que se han realizado para implementar los
elementos del backlog.
En la revisión se pueden evidenciar cambios en la forma en la que se han
implementado los elementos del backlog.
La revisión también puede introducir elementos nuevos en el backlog,
cambiando de esta forma los contenidos y dirección de las versiones
previstas.
Se determina la fecha de la siguiente revisión en base al progreso y
complejidad. La duración normal de los sprints es de 1 a 4 semanas.
Ilustración 1. Scrum Methodology. Scrum Development Process. Recuperado de
http://www.scrummanager.net/bok/images/7/7c/Scrum_Development_Process.pdf
Cierre
Cuando el equipo de gestión siente que las variables de tiempo, parte
completada, requisitos, coste y calidad están alineadas para producir una nueva
versión, declaran cerrada la versión, dando paso a esta fase. En esta fase se
prepara el producto generado para producir una nueva versión. Entre las tareas
de cierre se encuentran: integración, pruebas del sistema, documentación de
usuario, preparación del material de formación y marketing.
Controles de SCRUM
Al trabajar bordeando el caos (complejidad e imprevisibilidad) se requiere la
gestión de controles que eviten la caída en el caos.
La metodología SCRUM incorpora estos controles generales para evitar la
pérdida de control, utilizando las técnicas de Orientación a Objetos para la
construcción de las entregas.
El principal control es el del riesgo. La gestión de riesgos da lugar a cambios en
los controles y respuestas del equipo.
Los controles de la metodología SCRUM Son:
Backlog: Requisitos que el producto en su versión actual no gestiona de
forma adecuada. Errores, defectos, peticiones del cliente, incorporación de
mejoras competitivas o tecnológicas son elementos del backlog.
Los elementos del backlog que comprenden una nueva versión
comprenden variables de fechas, calidad y funcionalidad viables.
Paquetes: componentes del producto que deben cambiarse para
implementar la nueva versión.
Cambios: cambios que deben producirse en un paquete para implementar
una nueva versión.
Problemas: problemas técnicos presentes que deben resolverse para
implementar un cambio.
Riesgos: Para lograr el éxito del proyecto se revisan de forma continua los
riesgos y las respuestas previstas. La gestión de riesgos afecta a otros
controles.
Soluciones: respuestas a problemas y riesgos, que suelen ser cambios.
Temas: Cuestiones generales del proyecto que no se definen en términos
de paquetes.
Estos controles se emplean en diversas fases de SCRUM. La dirección los
emplea para gestionar el backlog. Los equipos los usan para gestionar cambios
y problemas. Ambos, dirección y equipos, gestionan los temas, riesgos y
soluciones. Estos controles son revisados, modificados y consolidados en la
revisión de cada Sprint.
2. CONCLUSIONES
El uso de Scrum como metodología de desarrollo probó ser una gran manera de
tratar de traer orden a todo el caos que conlleva un proyecto de esta índole. Por otro
lado, es imperativo mencionar que uno de los puntos clave que se requieren para el
correcto funcionamiento de la metodología es el compromiso de todos los miembros
del equipo, ya que Scrum como metodología ágil está enfocado en dirigir los
esfuerzos de las personas en lugar de los procesos del equipo, por lo tanto, todo el
éxito del proyecto recae en el compromiso y esfuerzo de los miembros tanto por
incorporarse de manera correcta a Scrum como de poner todo el esfuerzo de su
parte para poder lograr alcanzar las metas del proyecto.
Uno de los puntos más importantes que podemos reportar es la complejidad de
acostumbrarse como equipo a ver a Scrum como una serie de pasos que deben
beneficiar al proceso de desarrollo y no solo como un conjunto de prácticas. Esto se
logra sencillamente mediante el compromiso y el interés de los miembros del equipo
por verdaderamente comprender los beneficios que conlleva el uso de los diferentes
artefactos de Scrum y principalmente la ideología de las metodologías ágiles.
De esta experiencia poder comentar de igual manera una serie de recomendaciones
al momento de utilizar Scrum. Primero que nada, sugerimos realizar una exhaustiva
investigación acerca de los puntos clave de la metodología y posteriormente buscar
literatura que hable sobre casos aplicados de Scrum ya que si tan solo se lee la
teoría será complicado poder aplicarla en un proyecto real. Segundo, sugerimos
que se exhorte a los miembros del equipo a de igual manera leer por su parte acerca
de la metodología y sus bondades, no tan solo quedarse con la explicación de los
miembros del equipo que están informados sobre la metodología. Tercero y
posiblemente la mayor sugerencia es comprender que Scrum es una metodología
que debe estar al servicio de que el proyecto se gestione de mejor manera y sea el
proyecto mismo el que se beneficie de las prácticas de Scrum, es decir, no se debe
ver Scrum solamente como una serie de pasos a cumplir y un conjunto de artefactos
a utilizar, sino como una metodología que ayudará a todos los miembros del equipo
a hacer el desarrollo algo más sencillo.
Finalmente, una de las lecciones mejor aprendidas y que es un punto muy
mencionado dentro de las metodologías ágiles, es que en realidad no existen las
metodologías ágiles, lo único que existen son equipos ágiles, lo cual fue algo que
vivimos en carne propia al ver como un equipo auto organizado puede proveer
buenos resultados sin tener un seguimiento tan autoritario como lo tendría alguna
otra metodología tradicional.
BIBLIOGRAFIAS
Kumar, Pavan. (2009) Build Your Project Using Scrum Methodology [Versión
electrónica]. Recuperado de http://www.ipma-usa.org/articles/A3_AboutScrum
Peralta, Adriana. (2003) Metodología SCRUM [Versión electrónica]. Recuperado de
https://fi.ort.edu.uy/innovaportal/file/2021/1/scrum.pdf
Schwaber, Ken. (1996) Controlled Chaos : Living on the Edge [Versión electrónica].
Recuperado de
http://www.scrummanager.net/bok/images/e/e0/Living_on_the_Edge.pdf
Schwaber, Ken. (1996) SCRUM Development Process [Versión electrónica].
Recuperado de
http://www.scrummanager.net/bok/images/7/7c/Scrum_Development_Process.pdf
