Autora: Giulia Palma

Índice:

  1. Introducción
  2. Síntesis Crítica
    – ¿Qué es Agile?
    –  Ventajas y desventajas
    – Introducción a  Scrum
    – Sprint Basics
  3. Aplicación a Wink
    – Learning Contract
    – Plan de acción de Semana 20
    – Conclusiones y aprendizajes
    – Plan de acción Semana 21
  4. Bibliografía

Introducción:

El término ‘Agile’ se refiere a las metodologías ágiles. Recoge unas técnicas para la gestión de proyectos en las que se utiliza un enfoque incremental e iterativo (=que se repite muchas veces) para gestionar los proyectos. Deriva del Manifiesto Ágile de 2001 y, aunque surgió en el ámbito del Software, ya se utiliza para muchos otros proyectos.

Los objetivos de este learning path son:

  1. Conocer las ventajas de las metodologías enfocándonos a  Scrum.
  2. Entender cómo gestionar de forma ágil un proyecto y realizar una planificación Agile aplicada a Wink.
  3. Conocer roles, reuniones y artefactos Scrum.

Como fuente he decidido utilizar un mooc de edx, guiado por John Johnson una iniciativa de formación online de la universidad MIT ya que me lo aconsejaron y me ha parecido muy completo y de calidad. 

En este learning path, vas a aprender todo lo básico que necesitas para poder usar Scrum en el lugar de trabajo para lograr una mayor productividad y mayor satisfacción a medida que ejecutes un proyecto. 

¿Qués es Agile?

Agile es una metodología para el desarrollo de proyectos que precisan de rapidez y flexibilidad, retoma la organización del trabajo de Frederick Taylor, donde cada proyecto se ‘trocea’ en pequeñas partes que tienen que completarse y entregarse en pocas semanas. 

Sirve para desarrollar productos y servicios de calidad que respondan a las necesidades de unos clientes cuyas prioridades cambian a una velocidad cada vez mayor, así que su objetivo principal es tener una mayor flexibilidad ante la presencia de cambios.

Se basa en el principio de la interacción y no en usar procesos y herramientas para suplantar ese tipo de productividad en un proyecto, ya que, ninguna herramienta o proceso puede llevar tanta información, o transmitir la intención, tanto como una conversación cara a cara.

El goal de Agile es el de crear y construir un sistema que sea útil y de valor para la empresa. La planificación es continua y fundamental para este método, aún así, no se considera como una base sólida. De hecho si la planificación no va cambiando durante el proceso quiere decir que no lo estamos haciendo bien. 

Los 12 principios de Agile:

  1. Satisfacción del cliente: con una publicación rápida y continua, conocida como entrega continua, el cliente ha de estar satisfecho en todo momento.
  2. Flexibilidad: los equipos ágiles siempre ven el cambio como algo positivo, incluso si ocurre al final del proceso de desarrollo, ya que producto va evolucionando a lo largo de todo el proyecto. 
  3. Entrega: el proyecto se entrega directamente en un plazo de unas pocas semanas o meses. 
  4. Trabajo en equipo: los desarrolladores y miembros del área de ventas tienen que trabajar mano a mano. El Manifiesto Ágil contempla reuniones diarias.
  5. Apoyo: para que los trabajadores desempeñen su tarea con motivación y los equipos trabajen de forma creativa, el ambiente debe ser el adecuado. Para ello necesitan el apoyo de los demás y la confianza de sus superiores.
  6. Cultura de diálogo: para transmitir información de la manera más eficaz posible y sin malentendidos, lo mejor es la comunicación directa. 
  7. Éxitos: el éxito de un equipo puede medirse sobre todo con la publicación del proyecto creado por parte del cliente.
  8. Sostenibilidad: conviene que el desarrollo siga un proceso uniforme. Todos los participantes deben continuar trabajando de forma constante en las entregas.
  9. Calidad: los desarrolladores siempre deben asegurarse de que sus productos cumplan con los estándares más altos.
  10. Sencillez: el trabajo debe ser lo más simple posible. 
  11. Organización: solo si se permite que los equipos se organicen por su cuenta, se pueden esperar grandes resultados.
  12. Retrospectiva: un aspecto importante del desarrollo ágil de software es cuestionar los propios métodos cuando sea necesario. Para mejorar constantemente el trabajo del equipo, es importante que los miembros intercambien sus puntos de vista sobre la forma en que trabajan y que adapten sus acciones en consecuencia.

Otros conceptos de Agile:

Historias de usuario: Una historia de usuario es una representación de un requisito escrito en una o dos frases utilizando el lenguaje común del usuario. Éstas sirven para asegurarse de que el cliente o usuario siempre estén en el centro del desarrollo. En cada historia se explica brevemente lo que una función debe poder hacer desde la perspectiva del usuario. Esta descripción se anota en una tarjeta (story card) y con todas se elabora un mapa (story map).
Las historias pueden tener varios estados (planificado, listo, en desarrollo, prueba, hecho).
En resumen se trata básicamente de un post it con una tarea específica pero adaptada al lenguaje del cliente.

Product Backlogs: la lista de trabajos a realizar para todo el proyecto. Es una lista ordenada de incrementos de trabajo.

Sprint Backlog: el trabajo que se realizará durante el sprint.

Ventajas y Desventajas de Agile:

Mirando a estos pros y contras me he dado cuenta de que realmente Agile es una metodología muy aplicable dentro de Wink ya que todos los socios somos multidisciplinares y trabajamos en el mismo sitio, además teniendo en cuenta que trabajamos todos en varios proyectos a la vez no siempre tenemos el tiempo necesario para dedicarlo a Wink, así que muchas veces debemos realizar las tareas de forma rápida para los clientes y esta es una forma de trabajar que se adapta muy bien a nuestras necesidades. 

Sprint Basics:

Con Agile se va creando y presentando el producto al cliente en intervalos cortos que se conocen bajo el nombre de ‘sprints’.

Los sprints duran entre dos y cuatro semanas, así que tienen que ser conservadores en términos de lo que se puede cumplir y en lo qué puede comprometerse a hacer el equipo (realistas).

Planning → la planificación empieza por parte del cliente, que organizará el trabajo a través de una cartera de pedidos. Este trabajo se verificará junto al resto del equipo, que seleccionará desde la parte superior de esa lista, qué trabajo creen que pueden hacer durante el sprint. El objetivo de esta fase es diseñar el sprint y  que cada miembro del equipo sepa lo que tenga que hacer y esté comprometido. 

Development → el desarrollo comienza con un stand-up, en el cual todos se juntan durante cinco/quince minutos e informan al equipo sobre lo que van a hacer durante ese día para avanzar las historias (fases) del sprint.

Normalmente, esto se hace alrededor de un tablero, utilizando post-its, para entender qué trabajo está en progreso, y quién está trabajando en eso.

El trabajo se desarrolla historia por historia, evitando tener mucho trabajo abierto a la vez.

La última fase trata de construir un “incremento potencialmente enviable”, es decir, un trabajo completo que incluye documentación, así como un producto totalmente probado y funcional que el cliente puede mostrar.

Review & Retro → después de haber completado la historia el leader mostrará el avance a través de la documentación proporcionada por el equipo (que puede consistir en analíticas, descripción del proceso o resultados) y es el momento en el cual el cliente y sus colaboradores deberán dar un feedback al equipo, que aprenderá para organizar el próximo sprint. El equipo se reunirá para hacer lo que en Leinn llamamos Post Motorola, y se destacan juntos las cosas que han ido bien, mal y que se tienen que mejorar de cara al futuro. 

Aquí he creado un documento explicativo sobre la diferencia entre método tradicional, Agile y Lean. No lo he introducido directamente en esta hoja de trabajo ya que el Learning Path se volvería demasiado largo y pesado de leer si no  es un tema que el lector quiera aprender en este momento.

Introducción a Scrum:

Scrum es un framework que sigue la estrategia de desarrollo incremental de los marcos de desarrollo ágiles, pero no es lo  mismo que decir Agile, ya que Agile es mucho más que una metodología o un framework, es un conjunto de valores y de principios a seguir para evitar que surjan típicos problemas del desarrollo de proyectos. 

Formación de un equipo Scrum:

Scrum, a diferencia de Agile, no es una metodología. Scrum es un framework porque está formado por una serie de eventos, artefactos, roles, normas… para un determinado fin. 

La documentación:

El documento clave que establece el equipo es el “Charter”. Esto incluye:

  • Objetivos del proyecto: lo que los patrocinadores y / o clientes esperan de este proyecto
  • Partes interesadas: quién participa en proyecto desde patrocinadores a clientes y por qué. Incluye partes interesadas técnicas, de seguridad, comerciales y operativas.
  • Restricciones: qué debe hacer o no hacer el proyecto para lograr el objetivo, como estándares, interfaces y dependencias.
  • Riesgos: cuáles son los principales riesgos (internos y externos), esto incluye negocios, técnicos, políticos, sociales, ambientales…
  • Definición de “Hecho”: el acuerdo entre las partes interesadas sobre cuándo el propietario del producto (cliente) considera el trabajo acabado.

Una vez que la Carta del Equipo esté en su lugar, el equipo debe reunirse según las habilidades necesarias para hacer el trabajo:

Roles:

  • Propietario del producto: persona responsable de administrar la cartera de pedidos (sólo puede ser una persona) – Cliente (En nuestro caso, nuestro cliente es la persona que nos requiere los servicios).
  • Scrum Master: persona responsable de facilitar y mantener al equipo encaminado; lidera la planificación y retrospectivas de Sprint. El Scrum Master facilita reuniones, talleres y garantiza la calidad a través de buenas historias de usuario, cierre de historias, etc.
  • Miembro del equipo de desarrollo: persona en el equipo que se responsabiliza del éxito del equipo en completar los objetivos de Sprint. 

Estos últimos dos roles los asumiré yo como leader del proyecto. 

La Historia de Usuario:

Como especifiqué anteriormente, en las historias de usuarios debemos asegurarnos de priorizar en todo momento lo que el cliente desea. Sirven para resumir brevemente que requiere cada función y que queremos obtener para el cliente. La historia de usuario se divide en tres partes:

  • Declaración de valor → El medio adecuado para crear una “Declaración de valor” es el debate, pero generalmente las declaraciones son las siguientes:
    Como … [Quién – usuario] … quiero … [Qué funcionalidad desea – deben expresarse únicamente en términos comerciales] … para … [Por qué es importante – se debe especificar solo el por qué MÁS importante, los otros son los supuestos].
  • Supuestos → Todo lo que se debe conseguir con la historia de usuario. 
  • Criterios de aceptación → Los criterios de aceptación NO son reformulaciones de la Declaración de valor. Hay que detallar todas las pruebas que se ejecutarán para cerrar la historia.

El equipo de desarrollo puede actualizar estas historias con comentarios, pero no puede cambiar la declaración de valor, la suposición o los criterios de aceptación sin el consentimiento del propietario del producto (cliente) y los miembros del equipo de desarrollo (team).

Definition of Done:

La Definición de Hecho recoge todos los requisitos estándar para completar el trabajo definido en una historia de usuario, como por ejemplo:

  • Aprobaciones estándar;
  • Revisiones de los interesados;
  • Creación de prototipos (si es necesario);
  • Documentación (para sostenibilidad, informes, etc.);
  • Restricciones de diseño (para cumplimiento, integración, etc.).

La Definición de Hecho ayuda a modularizar las evidencias dentro de una historia de usuario y proporciona un conjunto claro de expectativas en torno al control de calidad y sostenibilidad del proyecto. 

La planificación de Sprint:

La planificación del sprint que se realizará para completar cada historia tiene 3 objetivos principales:

  1. Que el propietario del producto presente la cartera de pedidos actualizada
  2. Que el equipo de desarrollo seleccione y redefina las historias de usuarios
  3. Que el equipo de desarrollo pueda comprometerse con el Backlog de Sprint (el trabajo que se realizará)

Sin embargo, para garantizar la autenticidad de esos objetivos se debe cumplir lo siguiente:

  • Todas las voces deben ser escuchadas
  • El equipo debe revisar y elaborar todas las historias de usuarios en el Sprint
  • El equipo debe poder dimensionar y seleccionar esas historias dentro del «timebox» del Sprint Planning

El «timebox» para la planificación del sprint suele ser medio día para un sprint de dos semanas o un día completo para un sprint de cuatro semanas. Lo mismo se aplica para Team Retro y Reviews. Esto permite gastar un día de dos semanas en planificación y revisión.

Para hacer esto correctamente, el equipo debe evitar:

  • Entrar en largas discusiones prolongadas sobre los requisitos
  • Conflictos que pueden desestabilizar la reunión de planificación
  • No tener la información necesaria para planificar

La clave para hacer un buen trabajo de planificación de Sprint es doble:

  • Buena historia de usuario escrita por el propietario del producto (y / o el equipo de desarrollo en variaciones de Scrum) → Scrum Master y Product Owner deben trabajar juntos para garantizar la calidad de User Story. Esto es especialmente importante cuando el equipo tiene un nuevo propietario del producto, que no ha trabajado en un equipo Scrum.
  • Juegos de planificación → ayudan a facilitar y generar la creatividad del equipo. El juego más común es el juego Planning Poker. (ver normas del juego→ https://es.wikipedia.org/wiki/Planning_poker)
    Este proceso se usa para lograr tres cosas:
    – Validar que el tamaño de la historia es correcto
    – Validar que la historia del usuario se entiende bien
    – Asegurarse de que todas las voces se escuchen por igual cuando ocurran desacuerdos

El desarrollo de Sprint:

Para comenzar, es importante revisar los principios del Desarrollo Sprint:

  • Daily Stand Ups: comunicación cara a cara diaria para que no haya «programación» de coordinación. En estas reuniones se informa sobre lo que se hizo el día siguiente y lo que se hará durante ese día.
  • Equipos completos: todos saben cuál es el trabajo (lo planeamos juntos) y trabajan juntos
  • Propiedad del equipo: varios miembros del equipo trabajan en la misma historia de usuario
  • Límite WIP: límite del trabajo en progreso (WIP) para lograr un desarrollo más rápido y predecible con tiempo focalizado. El principal medio para reducir WIP es usar un tablero Kanban o «Scrumban»

Si una historia de usuario comienza a quedarse atrás, se pueden establecer «salas de guerra» para resolver el problema. (Reuniones del equipo en las cuales todos se centran para solucionar un problema).

Retro y Review del Sprint:

Revisión de Sprint: el Cliente presenta el incremento completado, potencialmente enviable a las partes interesadas.

Sprint Retro: el equipo de Sprint inspecciona en colaboración el sprint y busca formas de mejorarlo.

Objetivos de una revisión de Sprint:

  • Validar el producto 
  • Discutir cuáles deberían ser las siguientes características
  • La Participación de los interesados

Cómo ejecutar una gran revisión de Sprint:

  • Centrarse en demostrar el producto
  • Mantener las presentaciones simples y pequeñas.
  • Evitar PowerPoint si es posible, usar otras herramientas más creativas
  • Mostrar el trabajo planificado utilizando el sistema del equipo (como un sistema Kanban electrónico)
  • Involucrar a las partes interesadas (clientes, colaboradores etc.)

Objetivos de las retrospectivas de Sprint:

  • Analizar lo que salió bien durante el sprint
  • Analizar lo que salió mal durante el sprint
  • Analizar lo que el equipo puede hacer para mejorar

Cada persona escribe en notas adhesivas lo que piensa: una idea por nota y  pone en una pizarra sus pensamientos. Luego, todo el equipo trabaja en conjunto para agrupar y etiquetar pensamientos similares.

El Scrum Master luego facilita una discusión, con los puntos de conversación del grupo.

Este proceso debería ser en esencia un ejercicio de trabajo en equipo. Este método también fomenta las actividades sociales, así que una vez acabado el trabajo se aconseja salir del edificio para hacer actividades de teambuilding. 

Leave a Reply

Wow look at this!

This is an optional, highly
customizable off canvas area.

About Salient

The Castle
Unit 345
2500 Castle Dr
Manhattan, NY

T: +216 (0)40 3629 4753
E: hello@themenectar.com