Implementación de Scrum en Project Online/Server 2013: caso de éxito

En el anterior artículo se comentó como implementar Kanban en Project Server/Online 2013. Siguiendo con esta temática, vamos a abordar cómo implementar Scrum detallando, además, un caso de éxito de implantación de esta metodología ágil en uno de nuestros clientes.

Simplificando mucho, la metodología Scrum está basada en una serie de Sprints en los que el equipo va ampliando la funcionalidad del producto a construir. Cada Sprint se constituye de una serie de tareas a afrontar para poder incrementar esta funcionalidad. Al final de cada Sprint se contempla una tarea conocida como “Retrospectiva” en la cual el equipo trata de aprender sobre la velocidad a la que puede trabajar y sobre los errores y aciertos producidos durante el Sprint finalizado. El Sprint puede ser aprobado o no por el Scrum Master.

La implementación de Scrum en Project Server se puede dividir en dos partes: la planificación del proyecto y la gestión de los diferentes sprints mediante un flujo de trabajo.

Planificación del Proyecto (Project Shedule)

Por un lado, se tiene la planificación (schedule) de los diferentes Sprints. Esta planificación se lleva de la forma habitual desde la PDP “Schedule” del proyecto. En ella, se reflejan las tareas de arranque del proyecto y los diferentes sprints. Cada Sprint consta de las siguientes tareas:

  • Definición del “BackLog”
  • Tareas a ejecutar
  • Retrospectiva

Scrum_Schedule

Se podrían incluir otras fases de la metodología Scrum como el “Sprint Review”, pero en el caso de la implementación para nuestro cliente no se consideró necesario. Como puede observarse en la imagen, se generan en la planificación tantos Sprints como se requieran.

Flujo de trabajo

Por otro lado, es necesario generar un flujo de trabajo para poder gestionar cada uno de los sprints y decidir si se pasa al siguiente sprint o se realiza una nueva iteración del actual. Hay que recordar que no existe una relación entre las tareas de planificación de Project y los flujos de trabajo, es decir, no se puede acceder directamente desde el flujo de trabajo a una tarea planificada en concreto. Lo comento porque nos hemos encontrado clientes que “daban por hecho” que Project Server funciona de esta manera, pero no es así. En el caso de Scrum habría ayudado a poder identificar más fácilmente el sprint en el que nos encontramos, pero esto se soluciona de una forma muy simple, como veremos más adelante.

Antes de empezar a diseñar el flujo en Sharepoint Designer, se deben crear las etapas necesarias para el mismo. Vamos a mostrar sólo las etapas que afectan a cada uno de los Sprints que, como se puede observar en la imagen, se corresponden con las que se han visto en la planificación del proyecto:

Scrum_WF_Stages

La idea es que, para cada Sprint, se ejecuten estas mismas fases y etapas del flujo de trabajo. Para el Sprint N, se indicarán qué elementos del Backlog se completarán en el mismo y se modificará la planificación del proyecto según corresponda. A continuación, se pasará el proyecto a la siguiente fase: “Agile – 3 – Sprint”. En esta etapa se desarrollarán todas las tareas que correspondan al sprint por parte del equipo y planificadas en la etapa anterior. Una vez finalizado el sprint, el “Scrum Master” pasará el mismo a la siguiente fase del flujo “Agile – 4 – Retrospective”. En la misma se debe indicar si se pasa al siguiente sprint o ya se ha finalizado el proyecto. Para ello, se ha creado un campo empresarial basado en una tabla de búsqueda en el que se pueden indicar dos valores:

  • Back to backlog definition: Se continúa con el siguiente sprint, es decir, se define un nuevo “Sprint Backlog” y se pasa a la etapa “Agile – 2- Backlog Definition”.
  • Close Project: este estado se utiliza en el último sprint del proyecto para indicar que se ha finalizado el mismo.

Este campo se completa en una PDP de la etapa “Agile – 4 – Retrospective” y se continúa con el flujo. En el caso de la implementación para nuestro cliente, se añadió una etapa adicional en la que el “Product Owner” (la PMO) podía rechazar el sprint, lo que lleva de nuevo a la etapa “Agile – 3 – Sprint” para realizar una nueva iteración sobre el mismo.

¿Y cómo sabemos en qué etapa/Sprint nos encontramos si no se puede acceder a las tareas de Project desde el flujo? Muy sencillo, simplemente utilizando una variable de flujo de trabajo que se va aumentado cada vez que se inicia la etapa “Agile – 2- Backlog definition”:

Scrum_Calcular_Sprint

La información de lo que sucede en cada etapa se puede ir guardando en el propio log del flujo de trabajo, aunque es preferible utilizar una lista de Sharepoint que almacene la información relevante del flujo y pueda visualizarse desde una PDP, tal y como se comentó en el apartado “Gestión de la demanda en un flujo independiente al de la cartera” del artículo “Cómo realizar la Gestión de la Demanda en Project Server 2013”. De esta forma, es posible saber fácilmente en qué Sprint nos encontramos y qué ha sucedido en los anteriores.

Conclusiones

Como se ha podido observar, aunque Project Server es un producto nacido para gestionar proyectos mediante un desarrollo en cascada (“Waterfall”), implementar Scrum en Project Online/Server no es algo excesivamente complicado. La adaptación de esta metodología se basa prácticamente en el flujo de trabajo y en adecuar la planificación del proyecto a los diferentes sprints que se realicen.

Anuncios