GESTIÓN DE PROYECTOS & OPENERP7 – SCRUM Y KANBAN

1 INTRODUCCIÓN

En este texto, se trata de resumir y aplicar tecnologías de desarrollo ágil (sobre todo en su vertiente Scrum), y su gestión desde el propio OpenERP.

Comentar, que en la versión OpenERP7, ya no tenemos los módulos de gestión de proyectos relacionados con Scrum. Esto es debido ha que han quedado absoletos, y la versión 7 de openerp, ya incluye vistas kanban, que pueden ayudarnos en nuestros proyectos.

Estudiando las distintas metodologías que tenemos a nuestro alcance para la gestión de proyectos, se ha encontrado varios libros que hacen referencia a la gestión por parte de la empresa Toyota, un referente de empresa con éxito, que aplica este tipo de metodologías (de hecho fueron los que inventaron el Kanban, como sistema visual por tarjetas, para ver en que estado se encontraban las tareas de cada proyecto), por lo que se recomienda su lectura si se desea ampliar información.

2 PUNTOS PRINCIPALES DEL DESARROLLO DE PROYECTOS CON SCRUM

En general, Scrum, y las tecnologías ágiles, comparten una serie de puntos comunes:

• Debemos buscar la manera más sencilla de realizar las cosas. No debemos perder tiempo en cosas superfluas o que el cliente no ha pedido. Siempre tendremos tiempo de añadir o mejorar después.
• Los equipos de desarrollo tienen cierto grado de independencia, buscando su implicación y motivación para el proyecto.
• Se busca lo mejor de lo mejor como producto final, de manera que el cliente quede totalmente satisfecho con el producto y nuestro trabajo.
• Es necesario mucha comunicación, entre cliente y equipo de desarrollo, y entre los propios miembros del equipo de desarrollo. Mejor si es cara a cara.
• Tiene más valor la capacidad de adaptación a lo largo del proyecto, que el hecho de tener estrictamente especificados los requisitos del mismo, permitiendo adaptarse a las nuevas necesidades sin que eso sea un inconveniente.
• Se ejecutan los requisitos secuencialmente, intentando evitar el tener varias tareas abiertas, que impedirían el concentrarse en cada una de ellas.
• En Scrum, se producen iteraciones, llamadas Sprint, que tienen como resultado un producto entregable (puede que aún no con todas las funcionalidades)
• Son iteraciones que duran entre 1 y 4 semanas, buscando maximizar el número de tareas a realizar, con el fin de simplificarlas al máximo. Mejor cuanto menos tiempo pase entre cada Sprint.
• En el Sprint, hay reuniones antes, durante y después, que favorecen el mejorar tras cada iteración.

Antes: Para seleccionar los requisitos a desarrollar durante el Sprint, asegurándonos que es factible su terminación en fecha.

Durante:

Diariamente: Para que cada miembro del equipo de desarrollo, sepa como van los demás, y en qué punto se encuentra el proyecto, y el Sprint en concreto (reuniones de entre 10 y 15 minutos)

Después:
Estas reuniones pueden ayudar a mejorar los tiempos de desarrollo, comentando aquellos problemas que nos hemos encontrado, con el fin de optimizar y mejorar las sucesivas iteraciones o Sprints

• El cliente puede ver resultados tempranos y lineales del producto contratado.
• Es importante, que los Sprint, se ajusten lo máximo posible a un ritmo de trabajo, día a día y entre cada uno de ellos. Con esto conseguiremos mejorar la previsión del trabajo que el equipo de desarrollo es capaz de ejecutar en un determinado tiempo.
• Para cada Sprint, podemos tener varias etapas, y una característica es que cada una de las iteraciones, va a coincidir en estas etapas. Ejemplo de etapas, podrían ser:

Indefinido
Pendiente
En proceso
Análisis
Especificación
Testeo
Realizado

(Si, son las etapas de las tareas, que vienen por defecto en OpenERP7. De hecho, éstas, en la vista kanban, nos facilitan ver rápidamente como va el proyecto.)

AGENTES QUE INTERVIENEN EN LA GESTIÓN DE UN PROYECTO CON SCRUM

Podemos distinguir tres partes bien diferenciadas en las gestión de los proyectos cuando utilizamos la metodología Scrum:

• Cliente: Aporta los requisitos funcionales del proyecto.

• Equipo de desarrollo: Grupo de personas encargadas del desarrollo de los requerimientos del cliente.

• Manager del proyecto: Encargado de facilitar la tarea del equipo de desarrollo, de manera que no les falte nada que impida el desarrollo de su actividad en el proyecto.Debe verificar que se cumplen los principios del desarrollo basado en Scrum.

HERRAMIENTAS PARA EL DESARROLLO MEDIANTE SCRUM

Todavía no nos estamos refiriendo a la integración de Scrum y OpenERP.

Debemos disponer de unas herramientas mínimas a la hora de gestionar un proyecto mediante Scrum:

Repositorios o Backlog. Aquí encontramos los requisitos del proyecto, que se encuentran priorizados y estimados, y han sido añadidos por cualquiera de los tres roles anteriormente mencionados. Podemos dividirlos en:

Product Backlog
contiene los requisitos aportados por el cliente, priorizados y estimados.(Propiedad del cliente)

Sprint Backlog
selección de los requisitos del product backlog, asignados a un Sprint, y que conforman tareas, entendibles por el equipo de desarrollo.(Propiedad del equipo de desarrollo)

Burndown Chart
Gráfico que muestra el trabajo pendiente de realizar por el equipo de desarrollo.
Dentro de la planificación inicial de cada Sprint, se debe negociar qué requisitos, escogidos del product backlog, conformarán el Sprint que estamos preparando. Se seleccionarán aquellos requisitos que pueden abordarse con la seguridad de terminar en el tiempo del Sprint, y se generarán tareas para asignar a los miembros del equipo de desarrollo.

KANBAN

Un poco de Kanban, ya que es la herramienta que nos queda en OpenERP7 para el desarrollo ágil.

Es una palabra de origen japones, que significa ‘tarjetas visuales’.

Como comenté anteriormente, permiten ver rápida y visualmente el estado del proyecto.

En este panel, se debe mostrar todo el flujo de trabajo necesario, añadiendo las fases que nos sean necesarias.

La primera columna, representa el backlog (en openerp7, la primera columna de las tareas es la que se denomina Indefinido)

Debemos colocar en esta primera columna, todas las tareas del proyecto, priorizadas, y lo más simple posible (desglosadas).

Si distribuimos las tareas de manera que se tarde más o menos el mismo tiempo en realizarlas, tendremos, que de manera visual podremos estimar la duración de las mismas.

Product Backlog o repositorio

Ya comentamos, que el Product Backlog, debe estar gestionado por el cliente, y es que es aquí, donde la persona que gestiona el proyecto, del lado cliente, indica qué es lo que requiere el proyecto para darse por completado y válido.

Estos requisitos, se dan en la forma de Historias, que no es más que una manera de expresar en el lenguaje común, que es lo que necesitamos para el proyecto.

Estas historias, darán lugar a tareas, que es lo que entiende el equipo de desarrollo.

Algunas características:

Son creadas habitualmente por el Dueño de producto (representante del cliente en el proyecto, debe tener una implicación real, y tener poder de decisión sobre el mismo)

Deben estar priorizadas, al menos las más importantes, lo que permitirá alcanzar los objetivos principales ordenadamente

Mejor si son lo más simple posibles (incluidos sus creterios de validación), y en cualquier caso, intentar que su desarrollo y solución, sea asumible en un sprint.

Se expresan fácilmente, normalmente de acuerdo a unas plantillas del tipo:

Como contable de la empresa, necesito que el sistema me muestre un calendario con las facturas por fecha de vencimiento, de manera que pueda actuar en consecuencia
He diferenciado mediante colores, las tres partes fundamentales en las que se divide una historia de usuario:
Rol del usuario que solicita la funcionalidad
Qué es lo que se requiere
Porque es requerido
Es necesario crear Criterios de validación que son los que determinan cuándo una historia está correctamente resuelta.

Para el caso anterior, podríamos poner como criterios de validación:

• Las facturas se deben mostrar ordenadas
• Deben diferenciarse de cliente y de proveedor
• Deben mostrar a primera vista el cliente y proveedor y la cuantía de la factura (impuestos incluidos).