He decidido publicar este post que lo habia redactado hace un tiempo. Pretende ser una pequeña introduccion a la metodología de desarrollo ágil SCRUM. Pero como todos saben para aprender una metodología hay que leer mucho y sobre todo practicarla hasta dominarla. Espero este sea un buen punto de partida para aquellos interesados en comenzar a utilizarla. El texto es un resumen de lo expuesto por Ken Schwaber en su libro “Agile Project Management with Scrum“.
Espero este sea el primero de varios posts relacionados con Scrum.
Scrum
Un control de proceso empírico, se basa en tres principios: transparencia, inspección y adaptación.
La transparencia se refiere a que aquellos aspectos del proceso que afectan al resultado, deben ser visibles y conocidos por aquellos que controlan el proceso.
La inspección requiere que los aspectos del proceso sean inspeccionados con la frecuencia necesaria, para que las desviaciones inaceptables del proceso puedan ser detectadas.
Adaptación, si uno o más aspectos del proceso están fuera de los límites aceptables, el inspector debe ajustar el proceso o el material procesado. Esto debe hacerse lo más rápido posible para minimizar una mayor desviación.
Scrum es un control de proceso empírico, implementa los tres principios mediante un conjunto de reglas y prácticas simples.
Scrum emplea como esqueleto un proceso iterativo e incremental del cual derivan todas sus prácticas.
Opera de la siguiente manera: Al comienzo de cada iteración, el equipo revisa que debe hacer. Luego selecciona lo que cree puede transformar en un incremento de funcionalidad entregable al final de una iteración. Después se deja al equipo que haga su mejor esfuerzo por el resto de la iteración. Al final de la iteración, el equipo presenta el incremento de funcionalidad que construyó, para que los Stakeholders puedan inspeccionarlo y hagan adaptaciones al proyecto.
El corazón de Scrum ocurre dentro de la iteración. El equipo mira los requerimientos y la tecnología, y evalúa las habilidades y capacidades de cada integrante. Luego idea colectivamente la mejor manera que conoce de construir la funcionalidad, modificando el enfoque diariamente, a medida que encuentra nuevas complejidades, dificultades y sorpresas. El equipo decide que necesita hacerse y la mejor manera de hacerlo.
Roles:
Existen 3 roles: Product Owner, El equipo y el ScrumMaster.
El PO es responsable de representar los intereses de cualquier involucrado en el proyecto y el producto resultante. Crea inicialmente los requerimientos generales del proyecto, objetivos de retorno de inversión, y planes de lanzamiento.
La lista de requerimientos se llama Product Backlog.
El PO es responsable de usar el Product Backlog para asegurarse de que la funcionalidad más valiosa sea producida primero, esto se logra priorizando frecuentemente el Product Backlog para encolar los requerimientos más valiosos para la siguiente iteración. Es también responsable del éxito del producto.
El equipo es responsable de desarrollar la funcionalidad. Los equipos son auto-administrados, auto-organizados e interfuncionales. Un equipo es responsable de descubrir como convertir el Product Backlog en un incremento de funcionalidad dentro de una iteración, y administrar su propio trabajo para lograrlo.
El ScrumMaster es responsable del proceso Scrum, de enseñarlo a todos los involucrados en el proyecto y asegurarse de que todos sigan sus reglas y prácticas.
Flujo
Todo el trabajo se hace en los Sprints. Cada Sprint es una iteración de un mes, y es iniciada con una Sprint Planning meeting (Reunion de Planeamiento del Sprint) donde el PO y el equipo colaboran sobre que se va a hacer en el siguiente Sprint.
El equipo selecciona del Product Backlog todo lo que cree que pueda convertir en un incremento de funcionalidad entregable para el final del Sprint. Cada incremento debe consistir de código escrito, exhaustivamente testeado y bien estructurado que ha sido compilado en un ejecutable. La operación de usuario de la funcionalidad, debe ser documentada.
Al final del Sprint, se realiza la Sprint Review Meeting, es una reunión de 4 horas reloj en la cual el equipo presenta lo que fue desarrollado durante el Sprint al PO y cualquier otro stakeholder que desee asistir.
Luego de del Sprint Review y antes de la siguiente Sprint Planning meeting, el ScrumMaster mantiene una reunión de Retrospectiva del Sprint con el equipo. En esta reunión de 3 horas reloj, el ScrumMaster, alienta al equipo a revisar, dentro del marco de trabajo y prácticas del proceso Scrum, el proceso de desarrollo para hacerlo más efectivo y disfrutable para el siguiente Sprint.
Este conjunto de reuniones implementan las prácticas de inspección y adaptación, dentro del Scrum.
Artefactos
Product BackLog
Los requerimientos para el producto siendo desarrollado están listados en el Product Backlog. El PO es responsable del Product Backlog, su contenido, disponibilidad y su priorización. El product Backlog evoluciona con el producto.
Burndown Chart
Muestra la cantidad de trabajo que falta en relación con el tiempo. Es una manera de visualizar la correlación entre la cantidad de trabajo faltante y el progreso de el/los equipo/s de proyecto en reducir este trabajo. Es la relación entre la realidad (trabajo hecho y que tan rápido está siendo hecho) con lo que está planificado.
Sprint BackLog
Define un subconjunto de trabajos o tareas, que un Equipo selecciona del Product Backlog, para realizarlas en un Sprint, y convertirlas en un incremento de funcionalidad entregable del producto.
Las tareas deberían tener el suficiente detalle para que tome aproximadamente entre 4 y 6 horas el terminarlas. Solo el equipo puede cambiar el Sprint Backlog.
August 27th, 2008 by 
dpoza 
3 Comments »
