Proyectos Scrum como marco de trabajo para la construcción de productos

Cada vez son más las personas del medio de tecnología que habla y trabajan con alguna herramienta para que sus procesos se vuelvan más agiles. La palabra de moda es AGILIDAD. Y no se trata de un término nuevo, ni de una metodología para desarrollo recién creada, son muchos los años que han pasado desde los primeros artículos sobre el tema de agilidad.

Tal vez, sea que luego de innumerables decepciones con desarrollos fuera de control, o con problemas de alcance, tiempo o costo en los proyectos es que se ha visto una nueva “pomada canaria” en un marco de trabajo ágil.

A pesar de que existen muchísimos desarrollos exitosos que han utilizado metodologías o procesos de desarrollo “tradicional” en cascada, algunas con diferentes implementaciones que al final siguen siendo un proceso muy secuencias y que le cuesta manejar el cambio. (Basados en procesos predictivos).

Estoy claro que prácticas como Scum, XP, TDD, entre otros, no son mágicos, ni tampoco vienen a resolver el problema de la predictibilidad o la exactitud de las estimaciones de los desarrollo tecnológicos, sin embargo creo que están enfocados en algunos de los factores críticos del existo que hace que muchos proyectos sean exitosos. – las personas -.

Modelo Cascada

En el modelo cascada el proyecto se desarrolla de una forma secuencial, entonces, en un proyecto de desarrollo de software se deben seguir pasos secuenciales, por ejemplo: definición de requisitos, el análisis y diseño del software, la implementación y pruebas de unidades, la integración y pruebas del sistema y finalmente la puesta en operación y mantenimiento. Ver figura 1:

Figura 1: Modelo Cascada Tradicional

Primero el equipo se reúne con usuarios con el fin de recopilar las necesidades del sistema, para luego crear una documentación detallada de lo que entendieron debe hacer la futura aplicación. La siguiente fase es crear un diseño de cómo debe verse y comportarse la futura aplicación. En el siguiente nivel se crea el programa y se realizan pruebas a cada requerimiento por separado. Luego se continúa con la integración de las funcionalidades y las pruebas finales. Finalmente la puesta en operación y mantenimiento.

Uno de los principales problemas del modelo antes descrito, es que no fue diseñado para mantener el ritmo que puede implicar los cambios durante el desarrollo de software. Es muy difícil mantener los requerimientos iniciales de forma invariable en el tiempo, y el modelo depende mucho de la documentación. Sobre todo por que devolverse a una etapa anterior en los modelos más conservadores no es posible.

A partir de este modelo cascada se han realizado y publicado muchas variantes y versiones con el fin de garantizar el desarrollo exitoso, hasta llegar a modelos evolutivos e incrementales. Cada uno con sus ventajas y desventajas.

Al día de hoy las practicas ágiles se han vuelto como muchas otras herramientas una luz en el camino a desarrollar software de forma eficiente. El Manifiesto Ágil (2001) dice: “Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos y a las interacciones sobre los procesos y las herramientas,
Software funcionando sobre la documentación extensiva,
Colaboración con el cliente sobre la negociación contractual,
Respuesta ante el cambio sobre el seguir un plan”

Proceso Ágil basado en SCRUM

Scrum es un marco de referencia para el desarrollo y/o mantenimiento de productos complejos, mayoritariamente aplicado en software, sin embargo se ha aplicado en áreas como: construcción de autos, dirigir una lavandería, dar clases, construir naves espaciales, planificar una boda, remodelar una casa, etc.

En palabras de su creador, Jeff Sutherland, Scrum no va dirigido a los constructores del producto, está dirigido a los clientes y todas las partes implicadas. Se basa en un cambio organizacional, un cambio de cultura.

En su visión Scrum dice que busca la entrega de productos con el máximo valor posible para el negocio, con un alto nivel de creatividad. Scrum no es una técnica o proceso para construir productos, en su lugar, dentro de este marco de trabajo se puede incluir cualquier proceso de desarrollo o construcción.

Scrum abraza los cambios, aquí son bienvenidos, en busca de construir el producto que realmente satisfaga al cliente y genere valor para el negocio.

La figura a la derecha representa de una forma gráfica como se desarrolla SCRUM, con sus reuniones o ceremonias, roles y artefactos.

Pilares de SCRUM

Scrum se basa en la teoría del control de procesos empíricos, en donde el conocimiento se crea por medio de la experiencia y tomar decisiones basados en lo que se conoce. Scrum utiliza un enfoque iterativo e incremental para mejorar la predictibilidad y control del riesgo.

Transparencia: todos los aspectos del proceso deben estar visibles para todos los que participan en el desarrollo. En donde todas las decisiones sean tomas considerando la opinión de equipo, utilizando un lenguaje común y una definición acordada de que se considera un producto terminado.

Inspección: frecuentemente se deben inspeccionar los artefactos utilizados para Scrum y revisar el avance hacia el objetivo.
Adaptación: si existen desviaciones hacia el logro del objetivo se deben ajustar los procesos y/o artefactos utilizados.

En Scrum existen tres roles, cuatro eventos formales y 3 artefactos básicos.

Roles en SCRUM

Scrum Master: es un líder servicial, es quien debe coordinar y mantener los procesos de Scrum. Es la persona que guía al equipo a conocer e interiorizar el Scrum. También es la persona llamada a colaborar en el entrenamiento del dueño del producto, cuando este último inicia en este rol.

Dueño del Producto: (product owner) es un involucrado principal o clave del proyecto, quien representa al usuario final. Este rol es el vínculo entre el equipo de desarrollo y el cliente. Su principal responsabilidad es definir y priorizar los requerimientos.

Equipo de desarrollo: (Scrum team) son las personas responsables de hacer el trabajo y entregar un incremento del producto “terminado”, que potencialmente se puede poner en el ambiente de producción al final de cada Sprint. El equipo de desarrollo deber ser empoderado y estructurado, de forma que se auto-organicen y gestionen su trabajo.

Eventos en SCRUM

SPRINT: es un bloque de tiempo (time-box) que puede ir de 1 a 4 semanas durante el cual el equipo de desarrollo se compromete a crear un incremento de producto “terminado”. Durante el Sprint el equipo selecciona y desarrolla una serie de requerimientos (casos de uso, historias de usuario) que forman el Sprint Backlog. Dentro del Sprint se llevan a cabo una serie de ceremonias o eventos que se detallan a continuación.

Reunión de planificación del Sprint: (sprint planning meeting) Al comenzar un Sprint se realiza una reunión para que el dueño del producto proponga que requerimientos desea que se desarrollen, y el equipo, en base a su conocimiento y experiencia, seleccionar que pueden completar y a que se comprometen.

Reunión diaria: (daily Scrum) todos los días se lleva a cabo una reunión, para dar seguimiento continuo al proyecto. Esta reunión no debe durar más de 15 minutos y se lleva a cabo de pie, siempre en el mismo lugar y a la misma hora. En esta reunión cada miembro debe responder a 3 preguntas: ¿qué hice ayer?, ¿qué voy a hacer hoy?, ¿si tengo algún problema?, todo orientado a completar el objetivo del Sprint.

Revisión del Sprint: (sprint review) Al final del Sprint se lleva a cabo una reunión de revisión de los requerimientos comprometido para el Sprint. El dueño del producto, quien puede invitar a otros interesados, debe aceptar o no los productos construidos.

Retrospectiva del Sprint: (Sprint retrospective) Esta reunión se utiliza para realizar mejoras en el proceso, aquí el equipo comenta como se llevó a cabo el desarrollo del Sprint, de los resultados y como se sintieron. A partir de la retrospectiva se deben aplicar pequeñas mejoras el desempeño del equipo.

Artefactos de SCRUM

Lista del producto: (product backlog) es una lista ordena de todo lo que se necesita para el producto, es la única fuente de requisitos. El dueño del producto es el responsable de crearla y mantenerla. Nunca es completa. Al comienzo contiene los requerimientos conocidos, con forme avanza el proyecto y conocemos más, se puede identificar el resto de las necesidades.

Lista de pendiente del Sprint (sprint backlog) es una lista de elementos del product backlog seleccionada para desarrollar durante el sprint. El objetivo es entregar un incremento de producto. Esta lista es seleccionada por el equipo de desarrollo según sus capacidades y velocidad de desarrollo o construcción.

Incremento: es la suma de todos los ítems del product backlog que se desarrollaran durante un sprint, con valor para el negocio de forma que el resultado tenga la capacidad de ponerse en el producción. Es importante la definición de “terminado”, cual es acordada para dar por concluido o finalizado un ítem del prouduct backlog.

¿Cómo implementamos SCRUM?

Paso 1: definimos nuestra primera versión del product backlog, con los requerimientos conocidos y acordamos quien ejecutara los roles definidos. (Este último paso considera capacitación)
Paso 2: acordamos nuestra definición de “terminado”.
Paso 3: acordamos de qué tamaño serán los Sprint.
Paso 4: acordamos el día y hora de las reuniones de planificación, diarias, revisión y retrospectiva.
Paso 5: acordamos como vamos a documentar cada proceso: product backlog y sprint backlog.

En palabras del creador de Scrum: El scrum, al igual que el aikido o, para el caso, igual que el tango, es algo que solo pueden aprender practicándolo.

Gestionando proyectos ágiles

Scrum se basa en aplicar principios prácticos y simples para desarrollar productos de una forma eficiente. Sin embargo existen muchos elementos de gestión propiamente que no se tocan o no contempla el marco de trabajo de Scrum. Lo anterior implica que todas las buenas prácticas de gestión de proyectos, mal llamadas “tradicionales”, propuestas por el PMI son útiles y totalmente funcionales para un proyecto que utilice prácticas ágiles.

Podemos aplicar los mismos principios del manifiesto ágil para el desarrollo procesos de gestión, como la gestión de las comunicación, gestión de los interesados, estimaciones de tiempo y recursos, un mayor detalle en la gestión de los riesgos del proyecto, el alcance, los costos, entre otros.

Un director de proyectos debe aplicar sus habilidades de comunicación, liderazgo y dirección con el fin de crear y formar un equipo de alto rendimiento. El fin último es entregar constantemente valor al cliente, con el menor desperdicio de tiempo.

Un factor importante al aplicar Scrum es buscar una participación constante de los involucrados durante todo el proyecto, esto implica aplicar estrategias para gestión de estos involucrados. Podría hacer una liga de todas las área de conocimiento con respecto al proceso de Scrum, sin embargo no es el propósito de esta ocasión, más quisiera dejar el interés del lector en buscar más información y crear su propio escenario.

Conclusión

A pesar de que estás práctica agiles no son algo nuevo, lo es a nivel de aplicación en la construcción de productos. Lo que implica una serie de preocupaciones a la hora de apoyar o no un cambio de paradigma en la forma de construir software. Muchas veces nuestras organizaciones sin difíciles de cambiar, o cambian muy lentamente o muy posiblemente no tenemos la autoridad o nivel para hacer el cambio. Sin embargo, como todo buen viaje, comienza con un paso a la vez, un cambio a la vez, una herramienta a la vez.

Muchas herramientas de gestión o de modelos de ciclo de vida de desarrollo de software tocan el punto de las personas y su relaciones, sin embargo, entre el día a día, muchas veces perdemos este enfoque. Con un marco de trabajo liviano y simple, enfocarse en las personas es más fácil o por lo menos se puede perder menos el foco.

Cada vez nos piden más con menos recursos y en menor tiempo, entonces, hoy en día, no el más fuerte es quien sobrevive, sino el que sea más flexible ante el cambio.