Guía de desarrollo ágil para servicios digitales

Marcos recomendados de desarrollo ágil

A continuación, se describen dos entornos o metodologías recomendadas del desarrollo ágil. Cada uno tiene sus ventajas e inconvenientes y, al final, son los equipos de desarrollo los que deberán elegir lo que más se adecue a sus necesidades.

Scrum

El marco de trabajo Scrum es un conjunto estandarizado de conceptos, prácticas y criterios. Con ellos se busca la agilidad del equipo de desarrollo, mediante la adaptación iterativa e incremental, rápida, flexible y eficaz en base a la comunicación; así como a recabar los comentarios y pruebas con los usuarios finales.

Suele tener bloques de trabajo o ciclos temporales (por lo general, de 2 semanas), con tareas simples pero priorizadas según el valor que le dará al usuario. Estos ciclos, conocidos como Sprints, están planificados para ofrecer un valor significativo en cada entrega.

Es recomendable utilizar Scrum en proyectos nuevos y altamente innovadores en vez de en proyectos que estén en fase de mantenimiento o que hayan sido heredados. Para proyectos en mantenimiento, es recomendable utilizar metodologías como Kanban, orientadas a la entrega en el menor tiempo posible.

Principios

El Scrum se rige por seis principios:

Control de proceso empírico: se conoce el estado del desarrollo de manera transparente, favoreciendo la inspección y la adaptación.
Autoorganización: la forma de trabajo, el orden y las coordinaciones surgen de las interacciones del equipo.
Colaboración: el equipo trabaja en un solo lugar, lo que favorece la comunicación, resolución de problemas y el aprendizaje.
Priorización basada en el valor: entregar el máximo valor para el cliente en el menor tiempo posible.
Tiempo asignado (time boxing): el tiempo es limitado, buscando eficiencia y velocidad. Para esto, existen ceremonias obligatorias como la planificación del bloque de trabajo (Sprint Planning), las reuniones rápidas diarias (Daily Stand-up), las reflexiones o reunión de retrospectiva (Sprint Retrospective) y la revisión de avances con el cliente (Sprint Review).
Desarrollo iterativo: bloques de trabajo temporales y cíclicos con tareas simples pero valiosas.

Equipo Scrum

Suele estar formado por entre 3 a 9 desarrolladores, un facilitador o guía (Scrum Master) y el responsable o propietario del producto (Product Owner). La suma de todos los roles es lo que llamamos Equipo Scrum.

Propietario del producto (Product Owner)

Es el representante del cliente ante el equipo de desarrollo. Entiende las necesidades del cliente y las prioriza para permitir la entrega de valor y software funcionando. Suele describir las tareas en “historias de usuario” y se toma el trabajo de ordenarlas de más a menos valiosas. Participa en el planeamiento de los ciclos como “la voz del cliente”.

Facilitador (Scrum Master)

Trabaja día a día con el equipo de desarrollo para facilitar el trabajo, destrabar problemas, promover la comunicación constante y apoyar al Product Owner en el fluir del equipo.

Equipo de desarrollo (Scrum Team)

Son los que toman las historias de usuario y proceden a convertirlas en entregables, programando y probando la aplicación.

Otros integrantes
Los socios o stakeholders suelen ser personas alrededor del equipo o que tienen algún interés en el servicio digital. También están los proveedores de servicios terceros, como la infraestructura de nube o el acceso a aplicaciones.

Finalmente, cabe destacar el Cuerpo de asesoramiento Scrum (Scrum of Scrum), que son las personas con experiencia Scrum y que suelen coordinar las acciones del equipo con otros grupos Scrum de la institución, para recabar y atesorar las experiencias.

Técnicas y herramientas Scrum

Según el equipo de servicios digitales de Reino Unido (⁹) y junto con la experiencia recabada al utilizar Scrum por el equipo de servicios digitales, se recomiendan estas etapas y herramientas.

Reunión diaria (Daily stand-up)

Es la reunión del día para que el equipo discuta en qué están trabajando y si hay algún problema o dependencia que necesiten resolver (por ejemplo, si necesitan la ayuda de otra persona). Debe hacerse a la misma hora todos los días y no durar más de 15 minutos.

Reuniones de planificación (Sprint Planning)

Se ejecutan al inicio de un ciclo de trabajo o Sprint. Basándose en las tareas que el Product Owner ha priorizado, el equipo decide en qué trabajar en ese Sprint y cómo lo harán.

Revisión del equipo (Sprint Review)

Esta reunión se da al final de cada Sprint y brinda a los miembros la oportunidad de demostrar su trabajo. Se suele invitar a partes interesadas como directores o proveedores a esta reunión y usarla para contarles sobre las historias de usuario que el equipo ha completado u otro trabajo que hayan realizado.

Esto ayuda a hablar sobre lo aprendido con la tarea realizada, explicar los planes para las próximas semanas y responder preguntas. También le da a otros equipos la oportunidad de ver cómo se relaciona su trabajo con el de ellos.

Reuniones retrospectivas (Sprint Retrospective)

Las retrospectivas, a veces llamadas "retros", son reuniones regulares en las que todo el equipo habla sobre lo que funcionó y lo que no durante el Sprint que acaba de terminar. Esta permite a tu equipo aprender y fortalecer lo que salió bien, tomar nota de lo que salió mal y proponer mejoras, así como aprender de los errores. El objetivo de un retro es solucionar cualquier problema en el equipo y asegurarse de seguir haciendo las cosas que funcionan bien. Esta reunión debe tener una atmósfera abierta, donde cada miembro del equipo pueda hablar libre y honestamente, y sentirse seguro de que sus colegas lo escucharán.

Un retro básico podría seguir estos pasos:

El anfitrión explica las preguntas al principio y pega una nota adhesiva en la pared para cada interrogante.
Cada miembro escribe una o más respuestas para cada pregunta en notas adhesivas y las pega en la parte derecha del muro.
El grupo discute los problemas a medida que surgen, o al final.
El anfitrión decide las acciones para solucionar los problemas planteados y los asigna a los miembros del equipo.

Puedes elegir cubrir 3 o 4 de los siguientes temas de ejemplo:

Lo que salió bien en la última iteración (o Sprint).
Lo que salió mal en la última iteración.
Qué es lo que desconcierta o no comprende el equipo.
A quién quiere agradecer el equipo (por ejemplo, otros miembros del grupo).

Debes usar la información que obtienes del retro para mejorar el entorno de trabajo. Para esto, crea una lista de acciones de mejora con esta información, asígnalas al equipo y procura resolver esos temas para revisarlos en el siguiente retro.

Historias del usuario

Es una herramienta que permite al equipo registrar brevemente las cosas que necesita hacer para construir el servicio. Son escritas inicialmente por el Product Owner y usadas para generar debates sobre las funciones cuando estén listos para comenzar a trabajar en ellas.

Es de esperar que una historia de usuario tenga una lista de “Criterios de aceptación”; es decir, aquellos criterios que definen la historia como concluida.

Las historias de usuario se recaban sin prioridad en el Backlog o lista de tareas generales para desarrollar tu servicio. Luego, pasan de manera priorizada a la lista de tareas del Sprint durante el Sprint Planning.

Kanban

Este método de desarrollo se inspiró en los sistemas de producción centrados en reducir el desperdicio y mejorar la calidad, como los creados por Toyota.

Kanban es una forma de visualizar y mejorar las prácticas de trabajo actuales para que el trabajo fluya a través de un sistema rápidamente.

Un flujo de trabajo rápido y fluido te permite:

Entregar valor de forma rápida y previsible.
Obtener comentarios anticipados para averiguar si tu producto o servicio satisface las necesidades de los usuarios.

La herramienta principal de la metodología Kanban es el tablero de tareas, formado por columnas donde se listan las historias de usuario o las tareas pendientes, las que se están ejecutando y las ya terminadas.

Este tipo de tablero simplificado permite ejecutar tareas “justo a tiempo” o tareas de mantenimiento de servicios que ya están en fase de producción.

Lean

El desarrollo de software Lean, como Kanban, está adaptado de principios de fabricación ligero como el sistema de producción Toyota.

Los principios de Lean tienen como objetivo ayudar a tu equipo a centrarse en:

Reducir residuos.
Entregar rápidamente.
Aprender y mejorar.
Usar evidencia y datos para tomar decisiones.

Mayormente, se utilizan metodologías Lean para servicios digitales que están en etapa de descubrimiento e investigación.

⁹ Herramientas y técnicas ágiles. (18 de enero, 2019). Recuperado de https://www.gov.uk/service-manual/agile-delivery/agile-tools-techniques.