Gestión Ágil de Proyectos con Scrum

Módulo 2. Gestión Ágil de Proyectos con Scrum


Módulo 2. Gestión Ágil de Proyectos con Scrum

Los postulados del Manifiesto Ágil son demasiado abstractos, en el Master en Dirección de Proyectos vamos a convertirlos en instrucciones más prácticas y aplicables a nuestros Proyectos, este conjunto de instrucciones, más concretas, definen el método SCRUM


Conceptos Básicos de Scrum


Las historias de usuario describen la funcionalidad, desde del punto de vista de lo que el cliente necesita realmente del royecto, están escritas en lenguaje natural  y son responsabilidad del ProductOwner


El Sprint es el bloque de tiempo fundamental en SCRUM: tiene una duración fija y corta, generalmente menos de un mes + tiene un objetivo muy bien definido y alcanzable denominado Sprint Goal + se debe definir exactamente porque al final de cada sprint se debe tener un incremento del producto terminado y sin errores + no se deben cambiar los requisitos durante el sprint + sólo lo puede cancelar el Product Owner.

Qué son las historias de usuario: describe la funcionalidad desde del punto de vista del cliente + están escritas en lenguaje natural + son responsabilidad del ProductOwner.

Qué es la tarjeta de historia: cada equipo, proyecto o empresa, pueden generar su propia forma de plasmar las historias de usuario + durante un proyecto todas las historias se plasman igual + el cliente conoce la forma de trabajo + es el  ProductOwner es el que gestiona las tarjetas.

Qué es el ProductBacklog: es la lista ordenada + priorizada + estimada de las historias de usuario.

Qué es el SprintGoal: es el alcance conseguido de un Sprint.

Qué es el BurnDown Chart: es el trabajo/esfuerzo pendiente, muestra la evolución del sprint

Qué es el SprintMonitoring: método para seleccionar las tareas que hay que realizar para lograr un elemento del ProductBacklog, todo el equipo de desarrollo debe interaccionar con el Sprint Monitoring.

Qué es el Sprint board: representa, en el  eje vertical,  las historias del sprint que asocian a las tareas para completar las historias, en el eje horizontal, se indican las fases por las que pueden pasar las tareas.

Qué es Done (Terminado, acabado, finalizado): en SCRUM es muy importante saber qué quiere decir que una tarea del sprint está finalizada, todo el equipo de desarrollo debe conocer qué condiciones hacen a una tarea ”done”, todo el equipo debe conocer qué condiciones hacen a un elemento “done”.

Qué es el SprintReview: es el instante en que se revisa que todos los elementos del ProductBacklog se han finalizado, en el participa todo el equipo SCRUM y se permite la asistencia de Stakeholders. El ProductOwner valida los elementos del Sprint que se han terminado.

Qué es el Scrum Board: unifica toda la información, en ocasiones mantiene las historias de usuario “ocultas” para no generar “ruido”, incluye todos los artefactos de backlogs y la monitorización.

Qué son los Artefactos: representan trabajo o valor.

conceptos-scrum-hitoteam

El Equipo Scrum


Vamos a ver el Product Owner, el Scrum Master y el Equipo de Desarrollo


Quién es el Product Owner: es el responsable del producto + es el único que gestiona el Product Backlog + se encarga de definir todos los elementos para que quede perfectamente especificado lo que se debe implementar en el ProductBacklog  para alcanzar los objetivos del cliente + se asegura que el ProductBacklog sea conocido por todos los implicados + se encarga de optimizar el valor del trabajo desempeñado por el equipo de desarrollo

Quién es el Scrum Master: es el responsable de que Scrum se cumpla (el funcionamiento de todo el equipo, no sólo el de desarrollo) + está al servicio del equipo, no es un líder, ni ordena, ni protege + su labor es la de un intermediador entre todos los elementos, no sólo entre personas, también entre el producto, el entorno el cliente del proyecto.

Quién es el Equipo de Desarrollo: es un equipo auto-organizado + tiene poder para tomar todas las decisiones necesarias sobre el desarrollo del producto (no sobre los elementos del producto) + es un equipo igualitario, no hay jerarquía dentro del equipo, ni por titulación, ni por experiencia, ni por cualquier otro motivo + es un equipo empoderado, es decir, tiene capacidad para decidir todo lo relativo al desarrollo, estás decisiónes debe ser transparente a todo el equipo.

Las Reuniones Scrum


Vamos a ver el Sprint Planning Meeting, el Daily Sprint y el el SprintRetrospective


Qué es el Sprint Planning Meeting: la estimación de cada historia de usuario es la clave que permitirá poder crear un Product Backlog alcanzable. El Product Backlog es la clave de la reunión, en esta reunión se reúne todo el equipo y pueden asistir los stakeholders, el responsable de la reunión es el ScrumMáster.

 Cuestiones de la reunión: ¿qué puede entregarse en el incremento resultante del Sprint que comienza?, ¿cómo se conseguirá hacer el trabajo necesario para entregar el incremento?. El equipo de desarrollo es quien define si es alcanzable o no. Los elementos seleccionados conforman el SprintGoal, los elementos y el plan para desarrollarlos, crean el SprintBacklog.

Qué es el Daily Sprint: reunión diaria, de duración corta en la que debe participar todo el equipo de desarrollo, el ScrumMaster coordina la reunión.

Cuestiones de la reunión: ¿qué hice ayer que ayudó al equipo de desarrollo a lograr el SprintGoal? + ¿qué haré hoy para ayudar al equipo de Desarrollo a lograr el SprintGoal? + ¿veo algún impedimento que evite que el equipo de desarrollo, o yo, logremos el SprintGoal?.

Qué es el SprintRetrospective: reunión reflexiva de todo el equipo, es el mecanismo de mejora del equipo.

Cuestiones de la reunión: Temas de funcionamiento interno + inspeccionar cómo fue el último Sprint en cuanto a personas + relaciones, procesos y herramientas + identificar y ordenar los elementos más importantes que salieron bien y las posibles mejoras + crear un plan paracimplementar las mejoras a la forma en la que el Equipo Scrum desempeña su trabajo. Como vemos, todo es revisable en esta reunión.

reuniones-scrum-hitoteam

Consideraciones sobre Scrum


Vamos a analizar algunos aspectos muy relevantes sobre Scrum y las metodologías ágiles en general


Nunca extender un Sprint: no se debe confundir “ágil” y flexibilidad con un “todo vale”, si los objetivos marcados para una iteración no pueden ser alcanzados no debe ampliarse la duración de la iteración para “maquillar” el resultado, deberá asumirse que el objetivo no era realista y analizar el por qué (aprendizaje continuo).

Afloraremos los riesgos lo antes posible: aquellas tareas que no sabemos si pueden hacerse o que su realización (el proceso durante el que se hacen) puedan derivar en tomas de decisiones o, incluso, en cambios en el proyecto, deben hacerse tan pronto sea posible, de esta manera, en caso de tener que rehacer trabajo o incluso desecharlo el impacto será el mínimo, ya que la cantidad de trabajo realizado y relacionado con él será el justo y necesario para detectar esa necesidad de cambiar.

Priorizar las tareas que impliquen valor para el negocio: priorizar aquellas tareas o funcionalidades que impliquen valor de negocio, es decir, priorizar aquellas tareas que sean más importante para el cliente a nivel de negocio, realizar tareas completas en cuanto a funcionalidad, mostrárselas al cliente y, una vez obtenido un feedback, mejorarlas todo lo que sea necesario.

El cliente tendrá un producto funcional lo antes posible: y podrá obtener provecho de él, mientras que todos los flecos o posibles mejoras que desee podrán ser llevadas a cabo posteriormente

Igualar la duración de Sprints: genera por un lado una costumbre que facilita la planificación por parte del equipo, también facilita la obtención de medidas de velocidad del trabajo realizado y estimaciones del trabajo pendiente, en caso de desfases los miembros del equipo y el PO cambiarán la duración de las iteraciones para ajustarlas a lo que el proyecto requiera, pero siempre al termino de una iteración y antes de comenzar la siguiente, nunca durante una iteración.

En cada Sprint, tiempo, coste y calidad, son fijos: es el alcance (las funcionalidades o hitos a llevar a cabo) el que debe adaptarse, nunca este número debe aumentar a costa, por ejemplo, de reducir la calidad de lo realizado o de aumentar la presión de trabajo sobre el equipo para que produzca más rápido, todos los miembros del proceso deben ser capaces de mantener un ritmo de trabajo constante de manera indefinida.

Entregas parciales al cliente: con lo que el cliente nos dará  feedback, esto permite replantearse la priorización de todos aquellos hitos que queden realmente pendientes, tenemos que estar siempre abiertos al cambio.

Reforzar la importancia del equipo: Scrum se basa en equipos auto-organizados a los que se expone el trabajo a realizar y se confía en su capacidad para llevar a cabo dicho trabajo, es importante que la gente implicada en el proyecto sea consciente de la confianza depositada en ellos y les sirva como motivación para realizar bien su trabajo.

Facilitar un entorno de comunicación apropiado: el método más eficiente y efectivo de comunicación entre miembros del equipo es la conversación cara a cara, Scrum delimita qué roles deben existir en el proyecto y establece una comunicación directa entre ellos, de modo que el equipo siempre debe poder comunicarse, rápida y directamente, con el responsable de tratar con el cliente, para tratar cualquier tema que requiera de su intervención. Toda la información debe ser lo más accesible posible para todo el mundo y la comunicación para tratar cualquier tema, debe ser fluida y frecuente.

Los equipos deben estar adaptados al Proyecto: no todos los proyectos requieren de las mismas disciplinas y, por tanto, el equipo no debe ser el mismo, dependiendo cada equipo de la naturaleza del proyecto en el que trabaje, los beneficios que obtendremos serán reducir los recursos externos, ser capaces de hacer más cosas con nuestro equipo e incrementar la calidad del producto final entregado.

Criterio de Finalización. Retorno de Inversión (ROI): podemos llegar a un punto en que no valga la pena desarrollar los requerimientos restantes dado el poco retorno de inversión (ROI) que tienen. El contrato ágil permite detener el proyecto desde cualquiera de las dos partes, se detendrá el proyecto cuando el cliente ha cubierto la inversión que ha hecho hasta el momento con los beneficios que le aporta el producto o servicio (típicamente, el software) o en el momento en que el retorno de inversión que le producirá determinada funcionalidad restante es menor que el esfuerzo que implica realizar el resto de sprints.

El proceso parte de la lista de objetivos/requisitos priorizada del producto del Proyecto: que actúa como plan del proyecto, en esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas, de esta manera, el cliente puede maximizar la utilidad de lo que se desarrollará y el retorno de inversión mediante la replanificación de objetivos del producto del proyecto que se realiza durante la iteración con vista a las siguientes iteraciones.

equipo-scrum-hitoteam