¿Cómo implementar SCRUM en mi empresa?


¿Cómo implementar SCRUM en mi empresa?

Trabajamos en desarrollo de software desde hace 4 años y desde el año pasado iniciamos nuestra transformación interna para ser una empresa más ágil. Como toda adaptación hemos tenido aciertos y mucho aprendizaje, de hecho seguimos en ese proceso. Iniciamos con la implementación del marco de trabajo para nuestro core de negocio, que es el desarrollo de productos digitales y desde hace 4 meses estamos escalando Scrum a las otras áreas de la empresa.

Scrum es una transformación de la gestión de proyectos a la cultura del product ownership.

¿Que es SCRUM?

“Scrum es un marco de trabajo para la gestión y desarrollo de productos complejos, en un proceso iterativo e incremental utilizado comúnmente en entornos donde existe gran incertidumbre”. Está compuesto por roles, ceremonias, artefactos y reglas que convergen y permiten generar entregas constantes de valor.

Dentro le los roles tenemos al Scrum Master, Product Owner y el Equipo de desarrollo.

1. Scrum Master:

Es el servant leader que guía y protege al equipo. Resuelve los impedimentos, previene las interrupciones y facilita al equipo. Es un soporte para que se pueda cumplir el marco de trabajo.

2. Product Owner:

Es el encargado de definir las características del producto en base a la visión de los stakeholders. Define las fechas de los entregables, entrega feeedback y maneja a los interesados. Prioriza las características acorde al ROI y puede aceptar o rechazar incrementos al product backlog.

3. Equipo de desarrollo:

Es un grupo que puede variar entre 3 a 9 personas, multifuncional y auto-organizado que se encarga del desarrollo y la calidad del producto.

Scrum está conformado por ceremonias: se tiene el sprint planning, el daily meeting, el review meeting y la retrospectiva.

1. Sprint:

Es un periodo “limitado” que puede durar entre 1 a 4 semanas, en el cual el equipo trabaja para entregar las tareas planificadas. El propósito de un sprint es ofrecer incrementos de funcionalidad o valor para el cliente. Esto se debe de lograr inclusive desde el primer sprint.

La mayoría de los equipos adoptan un sprint de dos semanas, en nuestro caso optamos por sprints de una semana. Les sugerimos que puedan hacer uno o dos pilotos que les permita encontrar la mejor cadencia para su equipo.

2. Sprint Planning:

Es una reunión en la que se establecen las tareas que se van a realizar durante el sprint que inicia. Está ceremonia puede durar entre dos a 8 horas de acuerdo a la duración del sprint. Se definen las tareas necesarias para poder lograr el objetivo de sprint basados en la definición de hecho (DoD). Se realiza una estimación conjunta del esfuerzo que será necesario para realizar cada tarea. Los miembros del equipo se auto-asignan y auto-ordenan para poder lograr la meta del sprint.

3. Daily meeting:

Es una reunión que debe durar 15 minutos en la que cada miembro cuenta qué es lo que hizo ayer, que hará hoy y que impedimentos lo están bloqueando. Es acá donde el Scrum Master podrá identificar los obstáculos para facilitar el trabajo del equipo. Se realiza todos los días y el Scrum Master es el encargado de revisar si hay piedras en el camino y tratar de resolverlas. En caso haya algún inconveniente que demande mayor atención o tiempo debe de coordinarse para otro momento más apropiado.

4. Review meeting:

Se realiza el ultimo día del sprint, se convoca a las partes interesadas y es el momento de la verdad. Se trae a las personas involucradas en el proyecto y se hace una comparativa entre lo que se planificó en el sprint y lo que se llegó a ejecutar. En esta ceremonia también se obtiene el feedback de los interesados.

5. Retrospective

Esta ceremonia, sucede al finalizar el sprint, el Product Owner se reúne con todo el equipo Scrum para revisar los siguientes puntos:

  • Qué se hizo mal durante el Sprint para poder mejorar en el próximo.
  • Qué se hizo bien para continuar con la buena práctica.
  • Qué inconvenientes se encontraron y no permitieron poder avanzar como se tenía planificado, para poder tomarlo en cuenta para el siguiente sprint.

Los artefactos están diseñados para proveer transparencia al trabajo. Brindan información clave sobre el producto que se está desarrollando, las actividades planificadas y las que ya han sido realizadas.

1. Product Backlog:

Lista de tareas o actividades que se deben de cumplir para hacer realidad el proyecto. En esta lista se encuentran todos los elementos que sean parte del proyecto, pueden ser requerimientos, referencias, bugs (errores), entre otros. Algo importante a tomar en consideración es que no todo el backlog se llega a considerar como un requerimiento oficial, es posible que se quede en esta lista y no llegue a pasar a desarrollarse.

2. User Story

Las historias de usuario son los elementos especiales del product backlog. Se llaman historias porque tienen información de cómo será el comportamiento del usuario y que es lo que espera obtener. Se puede usar la siguiente forma de descripción de la historia de usuario:

Como (nombre del usuario usuario)

Quiero (Actividad, acción )

Para (beneficio)

3. Sprint backlog:

Es la lista especifica de las tareas que se completaran en el sprint. Estos elementos fueron tomados del Product Backlog, estimados, priorizados y aceptados en el Sprint Planning.

4. Taskboard

En el panel de tareas se muestra la lista general y los responsables de cada una de ellas. Se puede establecer diferentes columnas, las que deberían de considerarse por defecto son:

  • Por hacer
  • Haciendo
  • Terminado

Al iniciar el sprint, todas las tareas deben de estar en la primera columna “por hacer”, cada vez que alguno del equipo va a tomar una nueva tarjeta la mueve a “haciendo” y cuando la termine a “terminado”, de esta forma el Product Owner podrá revisarla, aceptarla o rechazar.

5. DoD Definition of Done

Son los criterios que deben de darse para finalizar una iteración.

  • Todas las tareas del sprint backlog están completas.
  • Revisión de Código
  • Pruebas realizadas a cada elemento desarrollado.
  • Revisión por parte de los clientes y que cumpla sus necesidades.
  • La revisión de las condiciones de Aceptación por parte del Product Owner.

En resumen, Scrum es un marco de trabajo que puede ser aplicable a cualquier tipo de proyecto. Pero para empezar a usarlo se debe iniciar con la transformación cultural del equipo. Puede tomar un poco de tiempo y esfuerzo pero el impacto positivo se notará en los resultados de la empresa.

Si quieres estar pendiente de las publicaciones que hacemos puedes visitarnos en www.starter.pe y suscribirte a nuestro newsletter.


.