Adaptación de Scrum al Servicio de Gestión Informática

De EduWiki
Saltar a: navegación, buscar

Introducción

Definiciones

Pila de producto / Product BackLog

Pila de producto, conjunto de historias de usuario, casos de uso, o requisitos indicados por el cliente y pendientes de realizar.

Burndown Chart

Es una representación gráfica del esfuerzo pendiente (trabajo por hacerse) en el tiempo del Sprint o User Story individual. En el eje vertical se muestra el esfuerzo pendiente para terminar la tarea y el tiempo en el eje horizontal. Es decir, el diagrama representa una serie temporal del esfuerzo pendiente. Este diagrama es útil para predecir cuándo se completará todo el trabajo y para evaluar el rendimiento del equipo de desarrollo de manera a poder realizar ajustes en la velocidad mínima, promedio y máxima del equipo. De esta forma se podrán ajustar los parámetros del equipo para realizar estimaciones más certeras para la planificación de futuros Sprints. Más abajo se ilustra un Burndown chart a modo ejemplo para reflejar el concepto:

Equipo Scrum

  • El director de Scrum. Debe asegurarse que el equipo de desarrollo se ajusta a la metodología de Scrum y sus normas. Ayudará al equipo a entenderse y autogestionarse, así como a eliminar todos los obstáculos que puedan surgirles. Su rol debe ser a la vez el de líder y sirviente.
  • El propietario del producto. es el responsable y único comprometido en el desarrollo y gestión del “Product Backlog” o documento de requerimientos del proyecto. Debe asegurarse del valor que este trabajo aporta al cliente. Además debe realizar la priorización de las tareas del “Product Backlog”, que derivarán en ser las primeras tareas en realizarse por el equipo de desarrollo en el siguiente Sprint
  • El equipo de desarrollo son los encargados de transformar las tareas más prioritarias del “Product Backlog” en productos acabados y potencialmente entregables una vez finalizado el Sprint.

Reuniones SCRUM

La metodología Scrum plantea una serie de reuniones a las que deben asistir todos los agentes pero solo una serie de ellos deben tomar las decisiones. También hay unas duraciones estimadas para hacer que sean útiles.

A continuación se puede ver un cuadro resumen.

  • Release planning, van todos, dura lo que haga falta. Realizan la pila de producto.
  • Sprint planning meeting, van todos, dura 4 horas, Se planifica el próximo SPRINT a partir de la pila de producto.
  • Daily scrum, van todos, dura 15 minutos, se hace diariamente. Se indica el trabajo hecho, por hacer ese día y los problemas encontrados.
  • Sprint review, van todos, dura 2 horas y se realiza al final del sprint. Se presenta el producto desarrollado en el último “Sprint”, centrado en funcionalidades.
  • Sprint retrospective, van todos, Director Scrum y equipo. Dura dos horas. Se hace un Análisis del funcionamiento del equipo y de la metodología Scrum durante el último sprint.


Sprint backlog: Pila del sprint

Inicio. Preparar la pila de producto

Un proceso Scrum inicia con la concepción del Product Backlog, el cual consiste en la especificación de todas las historias de usuario (también lo denominaremos tickets) definidas hasta el momento y que se requiere sean incorporadas al software. Claramente el Product Backlog, en la medida en que el desarrollo del software avanza, puede ser actualizado de manera a incorporar, redefinir o eliminar tickets.

No es necesario en esta etapa dar una definición detallada de cada ticket (lo que en un desarrollo convencional correspondería a diseñar un Caso de Uso), sino más bien enumerar los tickets. En la práctica el Product Backlog en la medida en que avanza el desarrollo será actualizado, tanto para agregar, modificar o eliminar tickets. Por ejemplo es muy común, como cada Sprint ya va produciendo un producto entregable y usable por parte del usuario, ir agregando al Backlog tickets de mantenimiento de funcionalidades ya existentes.

También es común, al inicio contar con tickets vagamente detallados que luego, con el transcurrir del desarrollo, cuando ya se cuenta con mayores conocimientos de las reglas del negocio, es factible dar una nueva definición de tickets con mayor precisión que reemplacen o modifiquen a algunos anteriores. Un ejemplo del punto anterior puede ser el siguiente: Consideremos un sistema de inventarios, donde primero se prioriza el desarrollo de la actualización del stock de productos en el depósito (carga masiva de productos, reposiciones, etc), de seguro se incluirá un ticket para "trazabilidad de un producto", el cual a inicios del proyecto es una funcionalidad deseada, que sabemos cuando sea priorizada para incluirse en un Sprint se podrá detallar más. Mínimamente podría ser reemplazado por estos 2 tickets "registrar los movimientos de entrada/salida de productos por el código de barra en depósitos, almacenes intermedios, y puestos de venta", y "crear una interfaz que reciba el código de un producto y muestre todos los lugares por donde tuvo movimiento y su última ubicación", con los cuales se implementa realmente la trazabilidad mencionada en el ticket original.

Una vez definido el Product Backlog se recomienda proceder a la carga de los tickets en el Redmine, cada uno como "User Story /Historia de usuario" con estado Nuevo y aún sin información precisa de fecha de inicio, responsable ni tamaño del ticket (size).

Preparar la pila de sprint / sprint backlog

Sprints Un Sprint de Scrum corresponde a una iteración en el proceso de desarrollo. La entrada a cada iteración es el Sprint Backlog que contiene los tickets planificados a ser incluidos en la iteración con el acuerdo del Product Owner y según sus priorizaciones. La salida del Sprint es deseable corresponda a un release del software, incluyendo las funcionalidades desarrolladas en la iteración, y el cual se disponibiliza al usuario final para su uso. En la práctica, podría suceder que cada 2 Sprints se genere el release del software, no obstante esta situación no es la recomendada en la metodología Scrum, y de todas formas deberá realizarse una demo al Prduct Owner de las funcionalidades desarrolladas en el Sprint por más que aún no se disponibilice un release.

En términos del proceso, un Sprint se organiza con las siguientes fases:

  • Planning Meeting: Se priorizan los tickets del Product Backlog a ser incluidos en el Sprint, y se realiza la estimación del tamaño de cada User Story (sizing). Finalmente se crea el Sprint Backlog, que representa el input para iniciar la iteración.
  • Daily Scrum: Corresponde a la etapa de implementación de los User Stories, típicamente involucra el relevamiento detallado de cada User Story, el diseño y codificación propiamente y los procedimientos de aseguramiento de calidad.
  • Relevamiento: Se organizan reuniones entre el equipo de desarrollo, el Product Owner y usuarios del software, de manera a detallar cada User Story incluido en el Sprint Backlog.

Diseño y Codificación: Se diseñan técnicamente los tickets del Spring Backlog, para aquellos que requieran interfaz gráfica se esbozan los wireframes (mockups) que luego son evaluados con el Product Owner. Se programan los *User Stories diseñados. El proceso establece que se deben realizar Daily Meetings entre todos los miembros del equipo de trabajo de manera a compartir los trabajos hechos, por realizar y las dificultades. Aseguramiento de calidad: Cada componente desarrollado sigue el modelo de integración contínua propuesta más abajo de manera a gestionar el testing, tanto de manera manual como automatizada.

  • Review Meeting: Se realiza la demo de las funcionalidades desarrolladas al Product Owner para su revisión. Se genera el Release de la iteración y se realiza el deploy de la misma para disponibilizar a los usuarios finales.
  • Sprint Retrospective: Se realiza el análisis final del Sprint, a partir de los Burndown charts. En base al avance logrado y potenciales cambios en los requerimientos que hayan surgido durante el Sprint, se realiza la actualización del Product Backlog, y un registro de los impedimentos o bloqueos encontrados en la iteración. El cierre del Sprint deberá generar un informe de entrega que formalice la entrega del Release producido.

A continuación se explican con más detalles cada una de las fases mencionadas.

Sprint Backlog

En base a la velocidad del equipo de trabajo, el tamaño estimado de los User Stories y las prioridades del Product Owner se designan los tickets que serán incluidos en el Sprint. En caso de utilizar el Redmine con el plugin redmine_yarsp, se podrá utilizar la funcionalidad "Backlog" del proyecto, en donde estarán todos los User Stories con estado "In Planning". El plugin requiere especificar una velocidad mínima, promedio, y máxima, y en base a esto a estos parámetros nos sugerirá los User Stories que entran para el siguiente Sprint. El plugin ordena el Backlog acorde a la prioridad de cada User Story, la cual recordemos se calcula en función a 4 criterios: Market value, Urgency, Techinical Value y el Size del User Story.

Daily Scrum

Esta fase corresponde a la implementación de los tickets priorizados para el Sprint actual. Típicamente implica reuniones de relevamiento detallado por cada ticket a incluir, el proceso de diseño y codificación propiamente, y finalmente los procedimientos de aseguramiento de calidad e integración contínua.

El proceso Scrum recomienda reuniones diarias del equipo de trabajo (daily meetings), de duración muy breve y en donde cada team member comparte su trabajo realizado el día anterior, lo que realizará en el día actual y bloqueos que le impidan avanzar con la codificación.

Relevamiento

A través de la gestión del Product Owner se organizan reuniones de relevamiento detallado para cada User Story incluido en el Sprint. Se generan las especificaciones de requerimientos del software, que son la base para iniciar los trabajo de codificación.

En la sección de la Documentación "Gestión de requerimientos" se incluyen plantillas de documentos para formalizar el relevamiento realizado.

Diseño y Codificación

Se realizan las actividades de diseño y codificación de los User Stories en base a las asignaciones del Scrum Master a los miembros del equipo. Se sugiere el uso de técnicas de prototipado rápido y aplicar un diseño orientado a los usuarios (Ux-Desing). Se recomienda la elaboración de wireframes (mockups de pantallas) para aquellos User Stories que requieran de una interfaz gráfica y validar los mismos con el Product Owner lo antes posible.

Daily Meeting

El proceso propone reuniones diarias entre todos los miembros del equipo de desarrollo, conocidas como Daily Meetings. La reunión no debe durar más de 15 minutos en total y al inicio de la jornada de trabajo. Cada miembro del equipo debe responder 3 consultas:

  • ¿Qué realizó ayer?
  • ¿Qué realizará hoy?
  • ¿Qué situaciones le bloquean? Es decir que problemas causan que no pueda progresar con la implementación.

Estas reuniones deben realizarse en un lugar poco cómodo y de ser posible los participantes deberían permanecer de pié. El objetivo es no extender la reunión más de lo previsto y realizarla de la forma más breve posible.

Review Meeting

Al finalizar la codificación en un Sprint, el Scrum Master organiza a través del Product Owner una reunión de revisión del Release desarrollado en el Sprint. El enfoque de la reunión debe tener un caracter de Demo, y puede invitarse a muchas personas, el equipo de desarrollo, el Product Owner, los usuarios finales y cualquier otra persona involucrada en el proyecto.

Se deben destinar 1 o 2 días previos a la finalización del Sprint para la gestión del Review Meeting y preparar la Demo que será realizada. El objetivo de la misma es causar un impacto positivo en el Product Owner, los usuarios, y a través de ellos en el cliente del proyecto.

Release Deploy

Cada Sprint debe generar un producto que se pueda distribuir y disponibilzar para su uso a los usuarios finales. En otras palabras, el proceso plantea que cada Sprint genere un Release del producto y este se accesible a los usuarios. Esta estrategia proporciona mayor visibilidad al Product Owner y usuarios sobre el proceso de desarrollo del software y la posibilidad de obtener un feedback cuanto antes.

En muchos casos, podría suceder que las funcionalidades incluidas en el Sprint aún no justifiquen la generación de un Release, en ese caso se pueden juntar las salidas de 2 Sprints a modo de generar el Release, no obstante se recomienda no exceder de 1 o 2 Sprints para disponibilizar el producto.

Sprint Retrospective

Esta fase se realiza al terminar el Sprint y consiste en la revisión y análisis del proyecto luego del Sprint. Se plantea la utilización de Burndown charts que ilustren la relación entre el esfuerzo esperado, el esfuerzo real realizado, el tiempo estimado y el que demoró la finalización de cada User Story planificado.

Además en esta etapa se puede actualizar el Product Backlog en caso de ser requerido, es decir si surgieron nuevos User Stories, se modificaron algunos ya existentes o dejaron de ser válidos. También en este punto, se recomienda actualizar y preparar la lista de bloqueos que impidan el avance planificado del proyecto de manera a permitir gestionarlos.

Informe de entrega

Elaborar el informe de entrega del Sprint, el cual deberá brevemente incluir listar las funcionalidades que fueron disponibilizadas a través del release generado en el Sprint. Para el efecto se sugiere el uso del siguiente template (LINK a informe sprint).

El objetivo de este informe radica en formalizar y documentar el trabajo realizado durante el Sprint y el release generado entre las partes, equipo de desarrollo y Product Owner.

Informe Final y de Aceptación del Software

Elaborar el informe Final y de Aceptación del Software, para el efecto se sugiere el uso del siguiente template (LINK a informe final).

El objetivo de este informe radica en formalizar el cierre del proyecto, y a su vez obtener la aprobación del producto por parte del cliente, representado típicamente por el Product Owner. Se utilizará como herramienta formal para el cese de los trabajos y la entrega final del producto.







Bibliografía