Título original: Métodos ágiles y Scrum 

Autores: Alonso Álvarez, Rafael de las Heras, Carmen Lasa

Editorial: Anaya Multimedia, año 2012, 350 páginas, 

ISBN: 978-84-415-3104-8

Palabras clave: metodología, proyectos, software, scrum, métodos ágiles

QUÉ ES:

En la empresa hemos comenzado a gestionar varios proyectos por medio de metodologías ágiles, así que me he comprado este libro para ver de qué va la moda de los métodos ágiles y en concreto de Scrum.

Una peculiaridad de este libro es que el prólogo lo firma Mike Breedle, unos de los firmantes del llamado ” Manifiesto Ágil”, del que ya hablaremos. además, para ser prácticos, utilizan la realización de este libro como ejemplo de proyecto realizado en Scrum

Entrando en materia, los autores destacan que el origen de los métodos ágiles se basó en la frustración del mundo informático de poder tener éxito cuando los requerimientos son indefinidos, es decir, en proyectos donde la incertidumbre de lo que se busca es alta, pues si el cliente tiene claros los requisitos entonces es mucho más adecuado optar por una metodología de proyectos clásica (en cascada o waterfall).  El cambio de paradigma que implica es adoptar el enfoque de señalar un presupuesto y una fecha de entrega y que el trabajo sea lo que se pueda hacer aplicando el principio de que el desarrollo será interactivo.

Scrum es solo uno de los muchos métodos ágiles que existen, aunque es sin duda el más popular.

Un resumen rápido del modo en el que se trabaja en Scrum es el siguiente:

• Ante al solicitud de un proyecto, el Product Owner crea un equipo, solicita unos recursos y fija los primeros requisitos.
• Desarrolla el Product Backlog con los trabajos detectados necesarios, que se compone de temas, épicas e historias.
• Se debe dividir el trabajo en varios Sprints, que se agrupan en Releases o entregas.
• El equipo de trabajo valora el esfuerzo implicado y traduce las historias en las que se compone el proyecto en unidades menores o tareas.
• El trabajo se va realizando y se expone en la Daily Meeting.
• Los impedimentos detectados van a a un Impediment Backlog y el Scrum Máster vigila que se resuelvan.
• El final del Sprint lo señala la Review Meeting
• En la reunión de Retrospectiva el equipo revisa lo realizado y lo que se ha hecho bien y lo mejorable.
• Y vuelta a empezar.

Y esto es todo…

Vamos a verlo con un poco más de detalle.

VALORES:

• Mejora continua
• Calidad
• Time Boxing
• Responsabilidad
• Multidisciplinar
• Flexibilidad
• Ritmo (latido)
• Compromiso
• Simplicidad
• Respeto
• Coraje
• Foco
• Predictibilidad
• Personas

 

 

 

 

 

 

 

 

ROLES:

• Product Owner:
  • Es el intermediario entre el cliente y el equipo. Es la voz del cliente.
  • Fija las fechas de entrega y prioriza los distintos requisitos
  • Mantiene la “visión” actualizada del producto o proyecto. La “visión” es un resumen de las metas a medio y largo plazo donde se quiere llegar. es muy importante por ello disponer de un “caso de negocio”. La “visión” del producto implica:
    • Unas características básicas u obligatorias, que el producto debe tener
    • Unas características de rendimiento o lineales
    • Características inesperadas o emocionantes
  • Mantiene al día el Product Backlog. Describe los elementos, con las condiciones de aceptación y priorizadas)
  • Traduce los requisitos de negocio en elementos del Backlog (temas, épicas e historias)
  • Es quien acepta o rechaza las entregas de trabajo
  • Asiste  a la Review y al Planning
  • Es el responsable del éxito o fracaso del proyecto y de su ROI. Controla el presupuesto
  • Gestiona las expectativas del cliente y de los stakeholders
  • Qué no debe ser un PO: Que no tenga poder, que esté saturado de trabajo.
  • Hay una interesante historia acerca de los roles dentro de Scrum y de lo que es estar implicado y estar comprometido.  Pues bien, el PO tendría el rol de “cerdo”, pues está totalmente comprometido con el proyecto
• Scrum Manager:
  • No es un jefe de proyecto. No tiene autoridad formal ante el equipo.
  • Supervisa todo el proceso. No está subordinado al PO.
  • Es un experto en la metodología Scrum debe enseñar esta metodología a cada integrante implicado en el proyecto, preocupándose de poner la metodología en práctica de modo que se encuentre dentro de la cultura de la organización y así entregue las ventajas previstas, asegurándose de que cada uno siga las Reglas y prácticas de Scrum.
  • Pilota los Sprints.
  • Debe velar por la productividad del equipo.
  • Debe procurar que fluya la comunicación y la colaboración.
  • Analiza la velocidad del equipo y debe buscar la calidad
  • Los roles de Scrum Manager y Product Owner son muy diferentes y es incompatible con que sean la misma persona.
  • Último objetivo: no ser necesario
• Equipo:
  • El equipo se debe auto organizar
  • Debe estar comprometido con el proyecto
  • Su responsabilidad es entregar el producto, en base a lo que existe en el Product Backlog
  • Los equipos autosuficientes, auto organizados y funcionales, tienen la responsabilidad, en cada iteración, de transformar el Product Backlog en un incremento en la funcionalidad del producto y planificar su propio trabajo para lograrlo.
  • Debería de elegir al Scrum Máster, porque es su representante. debe confiar en él.
  • Debería de tener dedicación suficiente y continuada
• Coach:
  • No es una figura obligatoria
  • Es un formador y mentor. Elabora las guías de actuación.

EL PROCESO:

• Lo primero de todo, el Sprint Cero: 
  • Es responsabilidad del Product Owner
  • El él se define la misión, herramientas y el equipo
  • El objetivo es definir las condiciones y el contenido del trabajo
  • De esta forma se establece la primera versión del Producto Backlog
  • También se elige la duración de cada sprint y el calendario de releases o entregas
• Sprints:
  • El Sprint Backlog contiene aquello que se llevará a cabo en cada sprint.
  • Hay tres etapas:
    • Sprint Planning, donde se realizan los criterios de aceptación y la valoración de los trabajos
    • Daily Meetings. Reunión diaria donde se revisa de forma rápida qué se hizo, que se va a hacer y los problemas encontrados
    • Review.
  • Sesión de Retrospectiva. Los resultados obtenidos en el sprint o fase se valoran aquí. Es una mirada al pasado para mejorar el futuro.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ENTIDADES:

• Tareas
• Historias de usuario.
• Épicas. Son agrupaciones de historias

ARTEFACTOS:

• Product Backlog:
  • Es la lista de requerimientos. Los requisitos del sistema o del producto desarrollado se enumeran en el Product Backlog. Es responsabilidad del PO.
  • No contiene todos los requisitos. Cualquiera puede crear requisitos, es si, requieren de la aprobación del PO. El Backlog es dinámico
  • Tipos:
    • Funcionales. Son las Historias de Usuario.
    • No funcionales. Son las cualidades que debe tener el producto.
  • El nivel de detalle debe ser alto para los requisitos prioritarios y no tanto para el resto.
  • Estructuración:
    • Temas
    • Épicas
    • Historias de Usuario
    • Tareas
  • Características de un buen Product Backlog:
    • Card. Deben caber en una tarjeta
    • Conversation. Deben ser resultado de conversaciones
    • Confirmation. Deben ser fácilmente confirmables
    • Con historias de usuario bien definidas
  • El mejor producto Backlog debe ser DEEP: Detallado, Emergente, Estimado, Priorizado
  • Es una lista ordenada por prioridad, esta tarea de priorización es del PO, pero el equipo le debe ayudar.
  • Técnicas de priorización del Product Backlog:
    • Priority Poker
    • Moscow (Must, Should, Could, Won’t)
    • Kano
    • Criba de temas
    • Puntuación de elementos
    • Posibles problemas del Product Backlog:
      • Es muy grande y detallado. Encubre una especificación de requisitos encubierta. En este caso no se debería de trabajar con Scrum
      • Historias de usuario siamesas. Encubre un problema con las dependencias. Se debería de dividir en partes más pequeñas y hacer historias de usuario conjuntas.
      • No se cierran las Historias de Usuario. Encubre un problema con las tres C’s: Card, Conversation, Confirmation
      • Infección Operativa. Si se dice cómo hay que hacer las cosas y no lo que hay que hacer. Se deben eliminar del PB las tareas operativas
      • Plaga de requisitos. Es síntoma de que el PB se está usando como una lista de peticiones.
      • No hay requisitos no funcionales. El PB no está completamente definido. Solución: prestar atención tanto a las Historias de Usuario como a los requisitos no funcionales
      • Inmunización tardía. Se deben priorizar todos los elementos sobre los que se tengan incertidumbres para poder trabajar sobre ellos. Si esto nop se hace pronto, luego será un problema
      • Muerte dulce por contrato. Si el PB funciona como un contrato con el cliente. El PB no es un acuerdo formal con el cliente.
      • No se debe consentir que el PO delegue la gestión del Product Backlog en el Scrum Master o en otra persona
• Sprint Planning:
  • Los sprints son fijados en el Sprint 0. En el Sprint Planning el equipo junto con el PO y el SM planifican los sprints.
  • Cada Sprint se divide en:
    • Planificación del contenido del sprint
    • Desarrollo del trabajo
    • Revisión de los resultados
  • Se deben establecer los límites temporales adecuados (time boxing)
  • Se debe garantizar que el objetivo, mecánica y resultados sean conocidos
• Sprint Backlog:
  • Son los trabajos a realizar durante un determinado Sprint
  • Es propiedad del equipo, que es quien lo gestiona y actualiza.
  • Su contenido es mucho más detallado y debe de disponer de una definición de lo que se debe alcanzar para poder saber cuándo se ha alcanzado el resultado
  • Dimensiones:
  • Prioridad
  • Detalle
  • Estado.  Será pendiente, en curso, terminado, impedida (se documenta y se asigna)
  • El Tablero de Tareas permite visualizar cómo va el sprint
• Impediment backlog:
  • Es una lista de incidencias que tienen que ser resueltas por el equipo y que el Scrum Máster debe gestionar y asignar al alguien para que trabaje en ellas, y que será revisada en la reunión Scrum diaria
• Burndown Chart.
  • Mide la evolución del trabajo. Lo mantiene el Scrum Master

MECÁNICA DE TRABAJO:

• El PO lee la primera historia de usuario junto con su criterio de aceptación. los miembros del equipo le asignan “Story points” y se suman hasta que alcancen la velocidad media del equipo (si se sabe). Estas historias deben ser divididas en tareas.
• El compromiso del equipo es muy importante. Por eso no se aceptan presiones del PO. La calidad debe ser el criterio que debe primar
• La cantidad de historia de usuario cerradas por el equipo según el Product Owner es el valor de la velocidad real de ese equipo
  • el valor de la complejidad, dificultad o cantidad de trabajo se mide en story points
  • También puede medirse la velocidad por días ideales que se requerirían para hacer esas historias.
  • O también se podría poner un porcentaje, un focus factor.
• La estimación es una acción colectiva. Puede usarse el Planning Poker
• Si la estimación coincide se acepta, si no, se discute sobre ello.
• Sumando todos los story points se obtiene la velocidad estimada de la iteración.
• El seguimiento del cumplimiento se realiza a través de la  Burndown Chart

PILOTANDO EL SPRINT:

El Scrum Master:

• No tiene poder real
• No es el jefe del proyecto
• Es un facilitador
• No está subordinado al Product Owner
• No persigue a los demás
• Cometido: velar por el seguimiento de los principios del Scrum
• Cómo lo hace:
  • Velando por la productividad del equipo
  • Procurando que fluya la comunicación y la colaboración
  • Responsable de introducir y fomentar las prácticas ágiles
  • Supervisa el backlog
  • Analiza la velocidad
  • Es el intermediario entre el mundo exterior y el equipo de trabajo
  • Es responsable de la formación del equipo
• Muy importante: es incompatible que una sola persona sea el PO y el SC
• Objetivo último: no ser necesario

Planificación detallada:

• Objetivo: pasar las historias de usuario a unidades más manejables, como son las tareas
• En esta tarea no se necesita al PO
• La tarea es una descripción simple de lo que se va a hacer. No es validable

Mantenimiento del backlog, el grooming:

• Es muy recomendable hacerlo mucho antes de cada planificación del Sprint Backlog
• El PO revisa el product Backlog para depurarlo.
• Es un trabajo continuo y puede asistir todo el equipo.

 DESARROLLO DEL SPRINT:

• Duración de los sprints. es mejor que sean cortos al inicio o en actividades poco definidas o si el equipo es inmaduro
• Frecuencia de los releases: es responsabilidad del PO
• Aspectos del sprint: estabilidad, obtención de resultados, mejora continua, anticipación

Quien lo lleva a cabo: el equipo de trabajo:

• Características: diversificado, autónomo, auto organizado, responsable, sin jerarquías o niveles, estable y dedicado
• Responsabilidades:
  • Realizar el trabajo del proyecto
  • Identificar formas de mejorar su productividad, junto con el SC
  • Hacer la estimación de los elementos del backlog
  • Dividir las historias en tareas
  • Comprometerse a realizar una lista de historias en cada sprint
• Dimensión del equipo: sobre 4 a 10 miembros
• Es muy recomendable la proximidad física

La Daily Meeting:

• Lo realizan el equipo y el SC, que no la dirige.
• El PO puede asistir o no.
• Contenido:
  • Qué se ha hecho
  • Qué se hará
  • Impedimentos

Backlog de impedimentos:

• Recoge todo lo que impide alcanzar los objetivos
• Se recogen los impedimentos, se describen y se asignan a un responsable
• Es gestionado por el SC
• Deben priorizarse

Sprint Review:

• También llamado Customer Sprint Review
• Se revisa qué se ha hecho y como se ha hecho
• Finalidad:
  • Recoger comentarios
  • Recoger la aceptación de las tareas seleccionadas
  • Analizar si se necesitan mejoras en el trabajo realizado o si se precisan nuevos items
  • Pueden acudir personas de fuera del equipo
• Posibles problemas:
  • Cambiar la fecha de la reunión frecuentemente
  • Que sea una presentación de resultados
  • Que se trabaje solo para el sprint review
  • Foco en los items del backlog y no en los objetivos
  • Desviación del propósito de la reunión por los asistentes
  • Convertir la review en una reunión de aprobación de requisitos
• La mejor práctica:
  • Establecer normas y reglas.
  • Repasar los objetivos
  • Recapitulación del PO sobre lo finalizado y no finalizado
  • Revisión por el equipo de estadísticas y métricas

La retrospectiva:

• Objetivo: mejorar la forma de trabajar de forma más efectiva
• Debe concluir con las acciones de mejora que deben implementarse
• Cuando: al final de un sprint, después de un release y al final del proyecto
• Etapas: que se hizo bien, que se debe mejorar, que se va a hacer en la nueva iteración
• Consejo: se debe ser positivo y debe haber un moderador (el SM)

LOS SCRUM BUTS:

• Son malas prácticas. Se debe diferenciar entre Scrum Ands, que son modificaciones positivas, y Scrum Bad, que son modificaciones negativas
• Los Scrum Buts exponen una disfuncionalidad que hay que solucionar. La culpa no es de Scrum.
• Top 10 de Scrum Buts:
  1. No hacemos reuniones de fin de sprint
  2. No se eligen voluntariamente las tareas. Ojo esto es micro gestión
  3. No hacemos mejoras o corrección de problemas porque hay demasiadas funcionalidades que implementar.  A esto se le llama la Death March
  4. No hacemos retrospectivas. Esto puede ser un síntoma de que hay conflictos internos en el grupo
  5. No hacemos reuniones diarias ya que nos las necesitamos
  6. El Scrum Master y el Product Owner son la misma persona. Ojo, son roles que consumen mucho tiempo y que son incompatibles porque sus atribuciones pueden entrar en conflicto
  7. Usamos Scrum pero no hacemos el diseño, la implementación y las pruebas de cada historia de usuario en el mismo sprint, porque no os da tiempo a llevar a cabo todas estas tareas en el mismo sprint y las hacemos en sprints consecutivos. esto puede tener dos causas: el equipo no está estimando bien las historias de usuario y el product backlog no está suficientemente trabajado
  8. No se hacen iteraciones cortas porque todo está claro y las hacemos cada 3 meses. Entonces, ¿Por qué se usa Scrum? Puede ocultar disfuncionalidades
  9. No hacemos reuniones diarias porque no está el Scrum Master. Ojo, esto no es un reporte
  10. Nosotros no lo llamamos Srum pero ya estábamos haciendo todas esas cosas.

¿Cómo detectar Scrum Buts?. Con el método de los 5 porqués (Un ejemplo. ¿Por qué no asiste el SM al Daily Meeting del proyecto? –> Porque está muy ocupado. ¿Por qué está tan ocupado? —> Porque gestiona muchos proyectos— > ¿Por qué gestiona muchos proyectos? —> Porque no hay más SC en toda la empresa…)

En fin. la teoría del método Scrum es muy sencilla. Pero hacerlo bien es muy difícil.