Introducción

Aquí empezamos la primera etapa de nuestro aprendizaje del uso del método Scrum.

Y para llegar al método propiamente dicho, nada mejor que hacer memoria sobre la manera en la que se han gestionado los proyectos informáticos a lo largo de los últimos 30 años, así como sobre los hallazgos que han llevado a la aparición de Scrum.

Algunos hechos y cifras

En efecto, ya hace decenas de años que se desarrolla software y lo menos que podemos decir es que los resultados de los estudios sobre los proyectos informáticos muestran que todavía hay mucho por hacer en lo que respecta a los métodos de gestión:

Alrededor del 20% de los proyectos de software fracasan.
En los 4 años siguientes, el 80% de los proyectos van a desaparecer.
El 50% del código generado nunca se utiliza.
En un software solo se utiliza alrededor del 20% de las funciones.

A la vista de este informe que detalla la evolución de las tasas de éxitos/fracasos de los proyectos (creado por el famoso Chaos Report 2015 del Standish Group, estudio realizado sobre 50.000 proyectos), lo menos que podemos decir es que la situación evoluciona lentamente:

Pero antes de ir más lejos, volvamos sobre esto que se llama métodos tradicionales de gestión de proyectos informáticos, que todavía forma parte del día a día de muchos equipos (incluso puede que del suyo, si está leyendo este libro…).

El modelo de gestión de proyecto "en cascada"

En este modelo, las diferentes fases del proyecto se realizan simplemente unas detrás de otras. Por tanto, en su descripción más sencilla:

Etapa 1: expresión de las necesidades, elaborado siguiendo un formalismo definido por la empresa, que identifica los requisitos funcionales de los usuarios.
Etapa 2: redacción de las especificaciones funcionales que describen de manera precisa el funcionamiento de la aplicación desde el punto de vista del usuario.
Etapa 3: fase de diseño detallado a lo largo de la que se elaboran las especificaciones técnicas, por parte de los diseñadores informáticos (diagrama UML, esquemas de bases de datos...).
Etapa 4: fase de codificación a lo largo de la que se realizan los desarrollos informáticos, basándose en las especificaciones funcionales y técnicas.
Etapa 5: aceptación global de la aplicación (pruebas unitarias, pruebas funcionales y pruebas de integración).
Etapa 6: entrega de la aplicación; se pasa a la fase de mantenimiento.

Lo que acabamos de describir es lo que llamamos modelo nominal (o modelo lineal) de gestión de proyectos. Cada etapa sigue a la anterior. Una etapa solo puede existir si la etapa anterior ha terminado. Por tanto, no es posible paralelizar etapas. Por este motivo a este modelo se le llama (muy...

El modelo (o ciclo) en V

El modelo en V nace al inicio de los años 1980, y sigue siendo el modelo de gestión de proyecto informático más utilizado en la empresa.

1. La teoría

El modelo en V tiene etapas muy comparables a las que se han visto en el ámbito del modelo en cascada:

Etapa 1: formalización de la expresión de necesidad. En esta etapa, el cliente explicita su necesidad a través de una descripción general de las funciones del software que imagina.
Etapa 2: escritura de las especificaciones funcionales detalladas. Se trata de una descripción muy detallada, que debe cubrir totalmente los casos de uso del sistema con todo lo que esto implica (reglas de gestión, pantallas...). En general, se trata de documentos que tienen varios centenares de páginas.
Etapa 3: escritura de las especificaciones técnicas. El trabajo realizado en esta etapa consiste en trasladar al plano técnico todo lo que se ha descrito en las especificaciones funcionales: arquitectura técnica, componentes de software, modelo de bases de datos, etc.
Etapa 4: desarrollo. Este es el momento en el que intervienen los desarrolladores para materializar el software en forma de código.
Etapa 5: ejecución de las "pruebas unitarias": estas pruebas permiten garantizar que cada pieza funcional (en ocasiones llamada módulo) sea correcta y no tenga errores importantes. Hablaremos...

La agilidad en el corazón de los proyectos

Si consultamos el diccionario, ser ágil significa ser una persona "que se mueve con soltura y rápidez", pero también que "se desarrolla con rápidez y prontitud y que es hábil y rápido".

A priori, esto no tiene ninguna relación con el asunto que nos afecta, a saber un método de gestión de proyectos. Sin embargo, si nos centramos en el asunto del que trata este libro, se puede definir como un método cuyo objetivo es ser más flexible y reactivo. Pero más flexible ¿respeto a qué?

En 2001 aparece el Manifiesto Ágil, cuyo objetivo es definir los valores y principios que permiten definir esta noción y todos los conceptos que confluyen en ella.

1. Un poco de historia

Del 11 al 13 de febrero del 2001, se reunieron 17 personas en Estados Unidos para establecer lo que se convertiría en el Manifiesto Ágil. En esta ocasión, se presentan grandes figuras del mundo del desarrollo de software, en particular Kent Beck (inventor de eXtreme Programming), Jeff Sutherland (co-fundador de Scrum) y Ken Schwaber. El objetivo de esta reunión es que cada uno de los participantes explique sus métodos, con el objetivo de extraer los principios y valores de lo que se convertiría en el repositorio de cualquier método ágil.

Como consecuencia de esta reunión, se promulgaron...

Scrum, un marco de trabajo ágil

A finales del 2001, tiene lugar la publicación por Ken Schwaber y Mike Beedle de "Agile Software Development With Scrum", que contiene la descripción del método Scrum.

En 2019, hace ya casi veinte años que existe Scrum, se practica en las empresas y se usa ampliamente: de esta manera, entre las empresas consultadas para hacer el informe anual "Estado de la agilidad" de collabNet/VersionOne (mayo de 2019), el 97% han adoptado los métodos de desarrollo ágiles y, entre ellos, el 54% usan Scrum (sabiendo que el 18% utilizan híbridos de Scrum).

El nombre Scrum, que significa "melé" y en inglés expresa un aspecto principal del método: en gran medida se basa en la cohesión del equipo. Es el equipo en su conjunto el que va trabajar para alcanzar el mismo objetivo. El equipo debe estar unido como los jugadores de rugby durante una melé para poder sacar el balón. El objetivo final se alcanza por medio de varias iteraciones que permitan al equipo visualizar su avance y, fundamentalmente, tener en cuenta los eventuales cambios de necesidad y su mejor comprensión, sin olvidar superar los obstáculos que se vayan encontrando.

Scrum, como cualquier enfoque ágil, se ilustra por el respeto a los valores del Manifiesto. Se basa en principios muy concretos:

La existencia de un equipo auto-organizado.
Roles definidos:...

Información, formación y certificaciones

Por supuesto, hay multitud de organismos diversos que ofrecen en la actualidad formación y certificación alrededor de Scrum. Vamos a citar dos que tienen una posición de referencia gracias a su nivel de calidad.

Scrum Alliance (http://www.scrumalliance.org/) es una organización sin ánimo de lucro, cuya vocación es acompañar a los usuarios del método Scrum a través de la formación, evaluaciones y retornos de experiencia, para certificar a los profesionales Scrum.

Scrum.org (http://scrum.org) fue creada por Ken Schwaber, uno de los padres de Scrum, y de la misma manera ofrece formación y certificaciones (en particular en línea). Observe que en este sitio Web puede descargar de manera gratuita la "Guide Scrum" oficial, escrita por Ken Schwaber y Jeff Sutherland.

No queremos entrar en el debate alrededor de lo conveniente de las certificaciones (algunos consideran que se trata más de un negocio que otra cosa), pero algunas veces es un requisito obligatorio para ocupar roles como Scrum Master o Product Owner en algunos proyectos.

De manera más general, aunque algunos puedan tener éxito en la implementación de Scrum por ellos mismos, es muy útil seguir una formación (certificada o no) cuando se empieza o se desea perfeccionar sobre Scrum. En la medida de lo posible, se debe seguir de una puesta...

Para concluir

En este primer capítulo, hemos abordado las nociones principales que es necesario entender sobre Agilidad, como el enfoque de la gestión de proyecto. En vista de estas pocas líneas, algunos de ustedes han quedado sin duda seducidos y convencidos por el concepto y la puesta en práctica del método Scrum (es precisamente para esto por lo que han adquirido este libro). Pero verá que la implementación no es tan sencilla como parece. En particular si se trata de introducir la agilidad en un contexto arraigado en las metodologías clásicas de tipo ciclo en V.

Por este motivo, a lo largo de este libro vamos a intentar explicarle el método de manera progresiva, lo que le permitirá entender los fundamentos y difundir a continuación este saber a su entorno.

Continuaremos el proceso de aprendizaje sin entrar inmediatamente en los detalles del método Scrum, sino presentando otros tres métodos ágiles: Lean Management, Kanban y eXtreme Programming que, como veremos, introducen conceptos que más adelante serán adquiridos por el método Scrum.

De la gestión de proyectos tradicional a la agilidad