Scrum

SCRUM

Fue desarrolla por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los 80, al analizar el desarrollo de proyectos de las principales empresas tecnológicas: Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M y Hewlett-Packard

Scrum es una estructura de procesos, y se lleva usando desde los inicios de los años 90. Se usa Scrum para la dirección del desarrollo de productos complejos, y varios procesos y técnicas garantizan que esto ocurre. Cuando pretendes mejorar tus prácticas de dirección y desarrollo, Scrum puede ayudarte a aclarar la relativa eficacia de tu gestión de productos.

La estructura está compuesta de Equipos Scrum que llevan a cabo una serie de funciones, tienen diferentes utensilios y eventos y siguen una serie de reglas. Cada parte de la estructura tiene un propósito, que trabaja hacia el éxito de Scrum.

¿QUÉ ES SCRUM?

SCRUM es un marco de trabajo (metodología, procesos, framework) para gestionar proyectos complejos, basado en un proceso iterativo (sprint) e incremental.
Organiza el desarrollo del proyecto en ciclos breves (sprint) para producir un producto por partes y obtener resultados que incrementan las capacidades o características al producto.
Se desarrolla en el marco de un framework. Conjunto estandarizado de conceptos, practicas y criterios para enfocar un tipo problemática particular.

SCRUM en principio surgió en la industria del software, pero por su sencillez y flexibilidad se puede aplicar en contextos (industrias) muy diversos.

Scrum se ha fundado sobre una teoría empírica de control de procesos, que también se conoce como empirismo. Lo que afirma esta teoría es que el conocimiento se basa en la toma de decisiones y en la experiencia de los factores conocidos.

Por tanto, Scrum busca cómo optimizar la predictibilidad y controlar el riesgo utilizando un método Iterativo e Incremental.

Iterativo: Organiza ciclos breves de desarrollo del producto (que SCRUM denomina Sprint) en cada uno de ellos se elabora una parte terminada y funcional del producto (se genera una nueva versión del producto).

Incremental: En cada sprint, se va incrementando una parte, una nueva capacidad o característica al producto conforme avanza el proyecto.

TEORÍA DEL SCRUM

CRUM se basa en tres pilares

Para que esto suceda, hay tres pilares que se deben implementar. Estos son la Transparencia, la Inspección y la Adaptación.

TRANSPARENCIA

Hay partes de este proceso que necesitan ser visibles para aquellos responsables de los resultados. Esto requiere definiciones estándar de todos los aspectos para asegurarse de que hay un entendimiento común de todas las observaciones. Considera estos ejemplos:

Todos los participantes en el proceso deben usar un lenguaje común
Tanto aquellos que llevan a cabo el trabajo, como los que aceptan el resultado, deben tener una definición estándar de “Finalizado”.

INSPECCIÓN

Aquellos que usan Scrum necesitan inspeccionar periódicamente los instrumentos Scrum y el progreso del Objetivo en el Sprint. Esto asegura que puedan detectar variaciones no deseadas a tiempo. Las inspecciones deben llevarse a cabo de vez en cuando, de manera que no se interrumpa el trabajo en progreso. Los inspectores cualificados se aseguran de que todas las inspecciones se hacen de manera correcta y son beneficiosas.

ADAPTACIÓN

Después de una inspección, puede revelarse que uno o más aspectos del proceso se ha desviado de los límites aceptables. Esto significa que el producto final podría no ser aceptable y que es necesario hacer algún ajuste en el proceso o el material que se está usando. Cuanto antes ocurra, mejor, de manera que se eviten más desviaciones.

PRINCIPIOS DEL SCRUM

Colaboración estrecha con el cliente.
Predisposición y respuesta al cambio.
Prefiere el conocimiento tácito de las personas al explícito de los procesos.
Desarrollo incremental con entregas funcionales frecuentes.
Comunicación verbal directa entre los implicados en el proyecto.
Motivación y responsabilidad de los equipos por la auto-gestión, autoorganización y compromiso.
Simplicidad. Eliminación de artefactos innecesarios en la gestión del proyecto.

COMPONENTES DEL SCRUM

ROLES:

Product Owner (propietario del producto)
Scrum Master (facilitador)
Scrum Team (equipo de trabajo)
Stakeholders (clientes – usuarios)

REUNIONES:

Sprint planning meeting (Planificación del Sprint)
Daily Scrum (reunión diaria Scrum)
Sprint review meeting (Revisión del Sprint)
Sprint retrospective (Retrospectiva del Sprint)

REUNIONES:

Product backlog (Pila del producto)
Sprint backlog (Pila de sprint)
Burn – Down (grafica de avance)

VALORES DE SCRUM

Hay muchos valores que el Equipo Scrum debe encarnar. Estos son el coraje, el compromiso, la sinceridad, el respeto Estos valores son básicos para erigir los pilares del método Scrum y conseguir confianza con todas las personas envueltas en él.

Los miembros del Equipo Scrum aprenden y exploran estos valores al trabajar en eventos y roles de Scrum. Para que el método Scrum tenga éxito, es necesario que los miembros del equipo sean competentes en estas cinco características.

Así lo hacen:

Tienen el coraje para hacer lo que es correcto y abordar los problemas graves.
Se comprometen a alcanzar los objetivos del equipo.
Los inversores y el equipo acuerdan hablar abiertamente sobre el trabajo y las dificultades que tiene el mismo.
Se respetan los unos a los otros y confían en que son independientes y capaces.
Se centran en el trabajo del Sprint y los objetivos del equipo.

ROLES DEL SCRUM - EQUIPO SCRUM

Tres miembros componen el Equipo Scrum básico, y son el Product Owner, el Equipo de Desarrollo y el Scrum Master. Se espera que estos equipos se auto-organicen y sean multifuncionales. Cuando se auto-organizan, pueden elegir la mejor manera de finalizar el trabajo y no tener en cuenta la orientación que puedan dar personas que no sean del equipo.

Como equipos multifuncionales, tienen todas las competencias para para realizar el trabajo, sin depender de otras personas fuera del equipo. El objetivo del equipo es optimizar la flexibilidad, la creatividad y la productividad.

Los Equipos Scrum entregan productos de manera iterativa e incremental, aprovechando el feedeback que les llega. Las entregas incrementales de productos “Finalizados” asegura que siempre está disponible una versión funcional del producto.

Product Owner (propietario del producto) ROLES

1.Es el responsable de maximizar el valor del producto resultante del trabajo del Equipo de Desarrollo.

2.Habla constantemente con el cliente.

3.Es el responsable de gestionar la Lista del Producto (Product Backlog), implica:

Expresar claramente los elementos de la Lista del Producto;
Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera posible;
Optimizar el valor del trabajo que el Equipo de Desarrollo realiza;
Asegurar que la Lista del Producto sea visible, transparente y clara para todos y que muestra aquello en lo que el equipo trabajará a continuación; y,
Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al nivel necesario.

4.El propietario de Producto es una persona, no un comité. Trabaja a tiempo completo y puede ser parte del equipo de desarrollo

Para garantizar que el Product Owner tiene éxito, todas las personas de la organización deben respetar sus decisiones, que son visibles en el contenido y orden del Backlog de Producto. No hay nadie capaz de ordenar al Equipo de Desarrollo trabajar con requisitos distintos, y el Equipo de Desarrollo también tiene sus acciones limitadas bajo las instrucciones de otra persona.

Scrum Master (facilitador) ROLES

Es el responsable de que Scrum sea comprendido y aplicado en la empresa.

Forma parte del equipo de desarrollo

El Servicio del Scrum Master al Dueño de Producto

Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos el equipo.
Encontrar técnicas para gestionar la Lista de Producto de manera efectiva;
Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Lista de Producto claros y concisos;
Entender la planificación del producto en un entorno empírico;
Facilitar los eventos (reuniones) de Scrum según se requiera o necesite.

El Servicio del Scrum Master al Equipo de Desarrollo

Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional;
Ayudar al Equipo de Desarrollo a crear productos de alto valor;
Eliminar impedimentos para el progreso del Equipo de Desarrollo;
Facilitar los eventos de Scrum según se requiera o necesite; y,
Guiar al Equipo de Desarrollo en entornos organizacionales en los que Scrum aún no haya sido adoptado y entendido por completo.

El Servicio del Scrum Master a la Organización

Liderar y guiar a la organización en la adopción de Scrum;
Planificar las implementaciones de Scrum en la organización;
Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo empírico de producto.

Scrum Team (Equipo de trabajo o desarrollo) ROLES

1.El Equipo de trabajo o de desarrollo esta constituido por profesionales que realizan el trabajo de cada Sprint (3 a 9 integrantes)

2.Participan en la creación del incremento en cada sprint.

3.La organización es la encargada de estructurar y empoderar a los Equipos de Desarrollo para que estos organicen y gestionen su propio trabajo.

4.Los Equipos de Desarrollo tienen las siguientes características:

Son autoorganizados. Deciden cómo convertir elementos de la Lista del Producto en Incrementos de funcionalidad potencialmente desplegables;
Los Equipos de Desarrollo son multifuncionales, esto es, como equipo cuentan con todas las habilidades necesarias para crear un Incremento de producto;
Scrum no reconoce títulos para los miembros de un Equipo de Desarrollo independientemente del trabajo que realice cada persona;
Scrum no reconoce subequipos en los equipos de desarrollo, no importan los dominios que requieran tenerse en cuenta, como pruebas, arquitectura, operaciones o análisis de negocio;
Los Miembros individuales del Equipo de Desarrollo pueden tener habilidades especializadas y áreas en las que estén más enfocados, pero la responsabilidad recae en el Equipo de Desarrollo como un todo.

EL SPRINT

El corazón del método Scrum es el Sprint. Se puede definir como un periodo de tiempo de un mes o menos en el que se crea un producto liberable, utilizable y “Finalizado”. Normalmente tienen una duración consistente durante un periodo de desarrollo. Los sprints deberían tener duraciones constantes durante todo el desarrollo. Un nuevo Sprint comienza solo cuando el anterior ha finalizado.

Los Sprints contienen y consisten de la Planificación del Sprint, los Scrums Diarios, la Revisión del Sprint, la Retrospectiva del Sprint y el Trabajo de Desarrollo.

Cuando el Sprint está en curso, no debería haber ninguna alteración que pudiera afectar al objetivo del mismo, los objetivos cualitativos no descienden, y el enfoque podría ser aclarado y renegociado entre el Product Owner y el Equipo de Desarrollo.

Es seguro considerar cada Sprint como un proyecto de un mes en el que se ha de conseguir algo. Por esta razón, en el Sprint se define claramente qué se va a construir, diseñar, un plan para la producción, el trabajo y el producto final. Si el Sprint durara más de un mes, la definición de lo que se va a crear cambiaría, y el riesgo podría subir junto a la complejidad general. Los Sprints son importantes ya que aseguran que el trabajo es predecible y puede ser inspeccionado y adaptado mientras se trabaja por el objetivo del Sprint. Limitan el riesgo, particularmente si nos fijamos en el coste.

Es posible cancelar un Sprint antes de que finalice. Sin embargo, la única persona que puede hacer esto es el Product Owner. La decisión puede estar influenciada por otros, incluyendo las partes interesadas, el Equipo de Desarrollo o el Scrum Master. Una cancelación puede hacerse efectiva cuando el Objetivo del Sprint se vuelve obsoleto.

La obsolescencia puede estar causada por el azar en la dirección, las condiciones del mercado o las condiciones de la tecnología. Si el Sprint deja de tener sentido, debería ser cancelado. Sin embargo, verás que raramente se cancela un Sprint, ya que tienen una duración bastante corta.

Hay una serie de pasos que hay que cumplir al cancelar un Sprint. Se revisan primero los elementos completados y “Finalizados” del Backlog de Producto. Si algo del trabajo del Sprint puede liberarse, será aceptado por el Product Owner. Esos elementos que son incompetentes en el backlog de Producto se reestiman y devuelven al Backlog de Producto. Ya que este tipo de trabajo se puede depreciar rápidamente, se debe revalorar frecuentemente.

Las cancelaciones desaniman, ya que consumen recursos. Esto se debe a que todas las personas envueltas en el Sprint tienen que reagruparse y realizar otro proceso de planificación del Sprint, para comenzar uno nuevo. Causan malestar en el equipo y se trata de evitarlas.

EVENTOS DEL SPRINT

Planificación del Sprint

Cualquier trabajo que va a hacerse en el Sprint se planea en la Planificación del Sprint. La planificación une al Equipo Scrum y se crea mediante un trabajo colaborativo. La planificación del Sprint tiene una duración concreta de ocho horas como máximo para un Sprint de un mes; aquí puedes encontrar sugerencias sobre cómo llevar a cabo una efectiva planificación del sprint.

Cuando el Sprint dura menos, también el evento tiene a ser más corto. Depende del Scrum Master asegurar que el evento tiene lugar y que los asistentes entienden la razón del mismo. El Scrum Master enseñará al equipo a mantenerse en la duración establecida.

En la Planificación se responden las preguntas sobre qué se puede liberar en el Incremento del siguiente Sprint, y cómo se conseguirá realizar el trabajo que se va a liberar.

¿Qué se puede liberar en el siguiente Sprint?

Durante el periodo de Planificación del Sprint, el Equipo de Desarrollo trabajará en pronosticar la funcionalidad que será desarrollada durante el Sprint. El Product Owner analizará el objetivo que se busca en el Sprint. Más allá, los elementos del Backlog de Producto que ayudarán a conseguir dicho objetivo. El Equipo Scrum al completo trabajará conjuntamente para comprender el trabajo del Sprint.

Esta reunión tiene unos aportes principales, que son el Backlog de Producto, el último Incremento de producto, la capacidad esperada del Equipo de Desarrollo durante el Sprint y el rendimiento previo del mismo. El Equipo de Desarrollo seleccionará cuántos elementos del Sprint provendrán del backlog de Producto. Es el Equipo de Desarrollo quien proporcionará información sobre qué pueden conseguir, basándose en las expectativas del Sprint.

Después del pronóstico de los elementos del Backlog de Producto, el Equipo de Desarrollo llevará a cabo el Sprint, mientras que el Equipo Scrum podría establecer el Objetivo del Sprint. El Objetivo del Sprint es el propósito que se alcanzará en el Sprint cuando el Backlog de Producto haya sido implementado. Sirve como guía para el Equipo de Desarrollo sobre por qué se crea el Incremento.

¿Cómo se logrará el trabajo?

Una vez que se ha establecido el Objetivo del Sprint y que los elementos de Backlog de Producto se han seleccionado, entonces el Equipo de Desarrollo decidido cómo se construirá la funcionalidad para conseguir un Incremento del producto “Finalizado” durante el Srpint. Los elementos del Backlog de Producto elegidos para este Sprint, junto al plan para liberarlos, se conoce como Backlog del Sprint.

El Equipo de Desarrollo diseñará un sistema para convertir el Backlog de Producto en un Incremento de producto funcional. La carga de trabajo puede variar según el esfuerzo necesario y el tamaño del trabajo. Durante la Planificación del Sprint, el Equipo de Desarrollo pronosticará qué piensan que se puede conseguir en el siguiente Sprint.

Al final de la reunión, el trabajo planeado para los primeros días del Sprint, que debe realizar el Equipo de Desarrollo, se descompone en unidades diarias (o menos). La auto-organización tiene lugar a la hora de realizar el trabajo del Backlog del Sprint, tanto durante la Planificación del Sprint como cuando sea requerido en el Sprint.

El Product Owner tiene la tarea de ayudar a aclarar los elementos del Backlog de Producto elegidos e intercambiarlos cuando sea necesario. Si el Equipo de Desarrollo decidiera que es mucho o poco trabajo, entonces debería ser renegociado basándose en los elementos del Backlog de Producto.

Esto se hace junto al Product Owner. El Equipo de Desarrollo tiene también la libertad de invitar a otros a asistir en beneficio del dominio o para dar consejos técnicos. Al final de la Planificación del Sprint, el Equipo de Desarrollo debería tener la capacidad de explicar al Product Owner y al Scrum Master cómo se realizará el trabajo trabajando como un equipo auto-organizado para alcanzar el Objetivo del Sprint.

Objetivo del Sprint

Es un objetivo que se pone en el Sprint, que se consigue con facilidad una vez que se ha implementado el Backlog de Producto. Actúa, de alguna manera, como una guía al Equipo de Desarrollo sobre la razón por la que se crea el Incremento. El Objetivo del Sprint se establece en la reunión de Planificación del Sprint.

Se asegura que el Equipo de Desarrollo tiene un nivel de flexibilidad, en relación a la funcionalidad implementada en el Sprint. El Objetivo del Sprint se entrega a través de los Elementos del Backlog del Producto y asegura que el Equipo de Desarrollo puede trabajar conjuntamente, en lugar de dividirse en diferentes iniciativas.

El Equipo de Desarrollo trabaja con el Objetivo del Sprint siempre en la mente, y esto afecta su funcionalidad y uso de la tecnología. Cuando haya un cambio en las expectativas, el Equipo de Desarrollo y el Product Owner facilitarán la colaboración para negociar el enfoque que se da al Backlog de Producto en el Sprint.

Scrum Diario

Cada día, el Equipo de Desarrollo deja 15 minutos para sincronizar sus actividades y desarrollar un plan para las siguientes 24 horas. Esto se conoce como el Scrum Diario. Incluye una inspección del trabajo que se ha hecho desde el anterior Scrum Diario y posteriormente se enfatiza sobre el trabajo que ha de realizarse antes del siguiente.

Es esencial que la hora y el lugar del Scrum Diario sean siempre iguales, ya que esto evitará cualquier complejidad. En la reunión, el Equipo de Desarrollo se centrará en:

Qué se hizo el día anterior que ayudó a alcanzar el Objetivo del Sprint
Qué se ha hecho hoy para ayudar a alcanzar el Objetivo del Sprint
Qué impedimentos pueden poner trabas a la consecución del Objetivo del Sprint

Esto significa que el Scrum Diario es como una manera de chequear el grado de consecución del Objetivo del Sprint. Asegura que el trabajo se basa en el Backlog del Sprint y facilita la tarea de alcanzar el objetivo. Se desafía al Equipo de Desarrollo durante el Scrum Diario a trabajar conjuntamente como un equipo auto-organizado a través de discusiones detalladas, en las cuales puede que tengan que adaptar o repetir el trabajo del resto del Sprint.

Es el Scrum Master quien asegura que esta reunión se realiza a diario, aunque está dirigida por el Equipo de Desarrollo. Los Scrum Masters aseguran que el equipo no se sobresale de los 15 minutos, y hacen cumplir las reglas de participación.

Los beneficios del Scrum Diario son numerosos, incluyendo la mejora en la comunicación, la no necesidad de otras reuniones, la identificación de trabas al desarrollo, la rápida toma de decisiones y el aumento del conocimiento general del Equipo de Desarrollo.

Revisión del Sprint

La Revisión del Sprint se lleva a cabo una vez que el Sprint ha finalizado. En ella, se inspecciona el Incremento y se adapta el Backlog de Producto si fuera necesario. Cuando la Revisión del Sprint tiene lugar, el Equipo Scrum y las partes interesadas evalúan qué se ha hecho durante el Sprint.

El resultado de la discusión podría llevar a adoptar cambios en el backlog de Producto, así como a la revisión de lo que podría ser optimizado con el objetivo de añadir valor. La revisión sirve para compartir información y no es una reunión sobre el estado del proyecto. Solo se mantiene para conseguir algo de feedback y para asegurar que existe colaboración. Duraría unas cuatro horas si el Sprint fuera de un mes. Si el Sprint fuera más corto, también lo sería la reunión.

Incluye los siguientes elementos:

Asistencia del Equipo Scrum y de las partes interesadas, invitados por el Product Owner
El Product Owner explica qué elementos del Backlog de Producto están “Finalizados” y cuáles no.
El Equipo de Desarrollo explica qué funcionó durante el Sprint y qué no funcionó, y cómo se solventaron los problemas
El Equipo de Desarrollo revela qué se ha “Finalizado” y propone preguntas sobre el Incremento
El Product Owner habla sobre el estado del Backlog de Producto y posibles fechas de finalización de los proyectos
El grupo al completo colabora en los siguientes pasos, de manera que la Revisión del Sprint proporciona información valiosa para la Planificación de próximos Sprints
Revisar el mercado o el posible uso del producto, cualquier cambio, y lo mejor para hacer a continuación
Revisar el cronograma, el presupuesto, las capacidades y el mercado para el lanzamiento del producto

Después de la Revisión del Sprint, el Backlog de Producto se suele revisar, y se definen los elementos del Backlog de Producto que se utilizarán probablemente en el siguiente Sprint. Puede que se hagan ajustes generales para encontrar nuevas oportunidades.

Retrospectiva del Sprint

Es una oportunidad para el Equipo Scrum de realizar una inspección sobre lo que se ha realizado y desarrollar un plan para conseguir mejoras en el siguiente Sprint. Ocurre una vez que la Revisión del Sprint se ha finalizado, antes de que la Planificación del Sprint vuelva a comenzar.

Es una reunión con una duración concreta de unas tres horas para Sprints de un mes. Sprints más cortos darán lugar a reuniones más cortas. El Scrum Master se asegurará de que la reunión tiene lugar y los asistentes entienden claramente su propósito.

El Scrum Master participará como un miembro del equipo para proporcionar información sobre las responsabilidades en el proceso Scrum. El objetivo de esta reunión es:

Inspeccionar el último Sprint
Identificar y ordenar lo que funcionó y lo que necesita ser mejorado
Desarrollar un plan para implementar mejoras al Equipo Scrum y la manera en que trabajan

El Scrum Master usará esta reunión para animar al Equipo Scrum a mejorar en las prácticas y procesos del desarrollo. Esto asegurará que el siguiente Sprint sea más efectivo y disfrutable. Se implementan los planes para elevar la calidad del producto, estableciendo una definición apropiada de producto “Finalizado”.

Una vez que se ha completado la Retrospectiva del Sprint, el Equipo Scrum habrá identificado qué se puede mejorar en el siguiente Sprint. Se adoptarán estas mejoras y serán inspeccionadas por el propio Equipo Scrum. La Retrospectiva del Sprint es una oportunidad formal de centrarse en la inspección y la adaptación.