Los objetivos que se pretenden alcanzar con el tema «Metodologías y estándares de diseño y

planificación de proyectos» son:

 Distinguir entre metodologías y estándares.

 Presentar los principales tipos de metodologías de desarrollo en vigor hoy en día, con las
ventajas e inconvenientes que presenta cada uno a la hora de aplicarlo a la gestión de
según qué tipo de proyectos.

 Informar sobre las principales herramientas de gestión disponibles en el ecosistema de la

gestión de proyectos.

  Presentar los principales modelos de metodología utilizados hoy en día.

Es necesario que el alumno comprenda la necesidad de adaptar cualquier

Metodología que se escoja a la realidad del proyecto que se va a dirigir. Para ello,
un buen comienzo es el PMBOK®, del Project Management Institute, que recoge un
 conjunto de buenas prácticas y estándares de planificación de proyectos.

Así mismo en la web grafía se proporcionan enlaces a otras metodologías también ampliamente
utilizadas en distintos ámbitos de la ingeniería.

El tema se estructura en torno al concepto de metodología como elemento organizador de las

tareas asociadas a la gestión de los procesos de dirección de un proyecto. Se expone también el
concepto de diferencia entre metodología y estándar y los distintos tipos de metodologías con que
se cuenta para planificar y gestionar un proyecto tecnológico.

El Project Management Body of Knowledge, del Project Management Institute, es el único

estándar (ANSI y IEEE) en Gestión de Proyectos, y aporta un conjunto de buenas prácticas, es
decir, cómo se hacen las cosas, aunque el equipo de dirección del proyecto es el responsable de
determinar lo que es apropiado para cada proyecto determinado.

La dirección de proyectos, según vimos en el tema anterior, no puede ser una

actividad «amateur» en la que la planificación de actividades, la gestión de los
recursos humanos y técnicos y la consecución de los objetivos del proyecto se
hagan sin ningún tipo de rigor.

Es necesario tener unos modelos que guíen las actividades de gestión y permitan
cuantificar el éxito de estas actividades. Es necesario, en definitiva, contar
con metodologías y estándares de Dirección y Planificación de Proyectos.
Metodologías

Metodología: Palabra derivada del griego que etimológicamente

significa:

 μετη metà «más allá»
 οδως odòs «camino»
 λογος logos «estudio»

…y que se puede definir como:

Conjunto de procedimientos basados en principios lógicos, utilizados

para alcanzar una gama de objetivos.

También se la puede definir como:

 Un proceso que documenta una serie de pasos y procedimientos necesarios para

completar con éxito un proyecto.

 Una serie de pasos a través de los cuales progresa un proyecto.

  Una colección de métodos, estándares y procesos que definen una aproximación ingenieril
diseñada para producir un producto, servicio o solución.

Pero una metodología completa es algo más que una notación o una colección de
procedimientos.

Proporciona además:

 Guías (para estimar costes, para tomar requisitos…).

 Medidas y métricas.

 Herramientas.

 Manejo del proyecto: tareas, hitos y entregas.

 Políticas y procedimientos para garantizar la calidad del producto.

Descripciones de los roles y responsabilidades.

Técnicas para adaptar el método a cada caso concreto.

Ejemplos como base para iniciar los trabajos.

Ejercicios de entrenamiento.

Una metodología define qué hay que hacer ante un problema determinado. El uso de una
metodología para resolver un problema es una estrategia de negocio que permite a las compañías
maximizar el valor del proyecto, asegurando la máxima eficacia y reusabilidad.

A la hora de escoger una metodología adecuada para la gestión de nuestro proyecto hay que
distinguir entre la gestión del mismo y el desarrollo del producto o servicio que con él queremos
obtener. No son iguales (ni tienen por qué serlo) los principios metodológicos c,on que se diseña
un avión y los principios metodológicos con los que se realiza la planificación del diseño del avión.

Es cierto que los organismos estandarizadores sectoriales (aquellos que generan

estándares para áreas concretas de actividad como puede ser el SW Engineering
Institute o la ESA para el desarrollo de SW) o los organismos gubernamentales
pueden definir metodologías completas que abarquen tanto los procesos de
gestión como los de desarrollo. Este es el caso de METRICA en España
(desarrollada por encargo del Ministerio de Administraciones Públicas), MERISE
en Francia (desarrollada por el Centre d'Etudes Techniques de l'Equipement) o
PRINCE2 en el Reino Unido (desarrollada por la Central Computer and
Telecommunications Agency) para el desarrollo de SW.
Sin embargo lo normal es seguir alguna guía metodológica específica para la
Dirección del Proyecto (como la propuesta por el PMI – Project Management
Institute).
Sea cual sea la aproximación metodológica que se use hay que ser consciente de
que va a ser percibida de forma distinta por el gestor del proyecto y por el resto del
equipo:

Estándares

Un estándar es:

 El conjunto de especificaciones técnicas y mejores prácticas en la

experiencia profesional con el objeto de ser utilizada como regulación, guía
o definición para las necesidades demandadas por la sociedad y
tecnología.
 Un Modelo a seguir al hacer algo. Son documentos que dan los detalles
técnicos y las reglas necesarias para que un producto o tecnología se use
correctamente.
 La definición clara de un modelo, criterio, regla de medida o de los
requisitos mínimos aceptables para la operación de procesos específicos,
con el fin asegurar la calidad en la prestación de los servicios de salud.

Un estándar define como hay que hacer y normalmente es parte de o

es utilizado por una metodología.

¿Hay una única metodología?

No hay ninguna metodología única.

 Algunas compañías tienen metodologías que cubren todo, desde la fase de ventas
hasta el soporte post-venta. En cambio, otros modelos metodológicos cubren los
aspectos del diseño y desarrollo. Las buenas prácticas que se han diseñado en
una compañía u organismo de estandarización pueden chocar con las prácticas de
otra y dificultar la implantación al 100% de un modelo metodológico.
Además, basta con examinar las metodologías de proyecto que existen hoy en día
para ver que la idea de un proyecto universal simplemente no funciona debido a
las diferencias que hay en las distintas industrias respecto a:

 Ciclo de vida
 Sector de mercado
 Producto
 Tamaño
 Tecnología
 Situación

Por ejemplo, una central nuclear o el proyecto de desarrollo de una

lanzadera espacial tienen algunas fases primordiales y específicas de
su ciclo de vida que nada tienen que ver con un proyecto de
ingeniería civil o de desarrollo de SW. Además, los ciclos de vida para
proyectos de construcción (por ejemplo, un puente), en comparación
con los proyectos TIC (por ejemplo, arquitecturas de tres niveles),
pueden ser muy diferentes unos de otros. Esto significa que se
necesitan diferentes metodologías. Por lo tanto, tenemos una
situación catch-22, diversas industrias y tecnologías hacen muy difícil
diseñar un ciclo de vida del proyecto «talla única».

Hay un problema adicional con el enfoque de metodología de proyecto universal

única. En la práctica, no se puede usar una metodología exactamente tal y como
está.

Es necesario modificar y adaptar cualquier metodología para

adecuarla a cada proyecto según un enfoque «pick-and-choose»,
usando sólo lo que realmente se necesita.

No obstante, se puede decir que aunque las fases de un proyecto varían por proyecto o
industria, un mínimo común incluiría:
Conceptualización / preparación
 Desarrollo /seguimiento y control
Cierre
En ciertos casos, se incluye la fase de iniciación si el proyecto se enmarca en una
estructura superior, plan estratégico de empresa, etc.

La selección del tipo de metodología determina a menudo el éxito o el fracaso del

proyecto. Se puede hacer una primera aproximación a la clasificación de las
distintas metodologías de gestión de proyectos agrupándolas en dos categorías:
 Metodologías pesadas o tradicionales
 Metodologías ligeras o ágiles

Metodologías pesadas (tradicionales)

Las metodologías de proyecto tradicionales (también

llamadas metodologías en cascada en referencia al modelo de ciclo
de vida que implementan) se consideran burocráticas o «predictivas»
por naturaleza y se han traducido en muchos proyectos fallidos. Estas
metodologías pesadas son cada vez menos populares.

Estas metodologías son tan laboriosas que todo el ritmo de diseño, desarrollo e

implementación se ralentiza y no se obtiene nada. Los gestores tienden a predecir
cada hito del proyecto porque quieren prever todos los detalles técnicos (por
ejemplo, el código software). Esto lleva los administradores a exigir muchos tipos
de especificaciones, planes, informes, puntos de control y calendarios. Las
metodologías pesadas intentan planificar una gran parte de un proyecto con gran
detalle para un período largo de tiempo.

Esto funciona bien hasta que las cosas empiezan a cambiar mientras
que los jefes de proyecto intentan resistirse a los cambios.

Si el gestor de proyectos no obtiene una lista completa de requisitos de usuario

por parte de los clientes, es muy probable que la metodología pesada no funcione
con eficacia debido a que el proyecto se verá afectado por continuos cambios y
revisiones de la documentación del proyecto. Estas metodologías trabajan sobre la
hipótesis de que cuantas más reglas y coordinación haya, mejor será el resultado.

Con este modelo, un proyecto complejo requiere suficiente documentación para

saturar la capacidad de trabajo de muchos de los miembros del equipo. El exceso
de metodología es, en términos de productividad, muy costoso e ineficaz. Muchas
empresas han caído en esta trampa al querer usar la metodología mejor y más
grande. Y muchos, esperando resultados milagrosos, se han decepcionado
después de varios meses de trabajo en el proyecto.

Por otra parte, hay ocasiones en las que la metodología tradicional puede ser
apropiada: cuando los proyectos son realmente complejos, en los que es
necesario tener un control más estricto y mejor coordinación entre las distintas
fases y equipos de trabajo, así como cuando hay que reforzar las líneas de
comunicación entre los miembros del equipo.

Cualquier proyecto con un equipo de más de 10 a 20 personas que

trabajan en varias ubicaciones puede ser un buen candidato para una
metodología tradicional.

Debido a que las tecnologías son cada vez más complejas y están más integradas
(lo cual provoca muchos problemas de diseño y desarrollo) las metodologías
pesadas a veces pueden ser la mejor opción, especialmente cuando varios
equipos están trabajando en distintos lugares y cuando es necesario un control
más estricto y una formalización de los elementos claves del proyecto.

Metodologías ágiles

La creciente complejidad tecnológica, los continuos retrasos en los

proyectos y los requisitos cambiantes del cliente han provocado
una pequeña revolución en el mundo de las metodologías de
desarrollo. Una clase totalmente nueva de metodología (ágil,
adaptable y que involucra al cliente en cada paso del camino) está
empezando a surgir. Muchos de los metodólogos tradicionales han
sido reacios a la introducción de estas «metodologías ágiles» o
«ligeras».
 Estas metodologías utilizan un estilo de comunicación informal. A diferencia de las
metodologías tradicionales, los proyectos ligeros tienen sólo unas pocas normas,
prácticas y documentos. Los proyectos se diseñan y construyen a través del flujo
de información con los clientes, en reuniones y debates cara a cara. Generalmente
se benefician de equipos con experiencia en trabajar juntos
La diferencia más obvia que aparece cuando se usan metodologías ligeras es que
estas son mucho menos orientadas al documento, normalmente haciendo hincapié
en una menor cantidad de documentación para el proyecto. Por ejemplo, el equipo
considera el código fuente como la documentación del proyecto.

Entre las ventajas de una metodología ágil destacan:

 Funcionan bien con el cambio.
 Están orientadas a la gente en lugar de orientadas al proceso. Trabajan con personas en
lugar de hacerlo contra ellas.
 Se complementan con el uso de listas de control dinámicas.

Si un cliente constantemente introduce cambios frecuentes en el

diseño para ver cómo será la solución, posiblemente para ver
resultados inmediatos o la funcionalidad del producto, una
metodología ligera puede ser el camino adecuado a seguir.

Aunque se pueden establecer algunos límites para evitar demasiados cambios, en

el cambiante entorno tecnológico .

Todas ellas se basan en «el manifiesto»: Manifiesto por el Desarrollo Agil de

Software.

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra

propia experiencia como ayudando a terceros. A través de este trabajo hemos
aprendiendo a valorar:
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la
izquierda.
El PMI® y el PMBOK®

El Project Management Institute (PMI) se funda en 1969 por cinco voluntarios y su

primera reunión plenaria tiene lugar en Atlanta (Estados Unidos) con ochenta
asistentes. A finales de 1970, ya casi 2.000 miembros formaban parte de la
organización. En 1987 realiza la primera evaluación para la certificación como
profesional en gestión de proyectos (PMP® por sus siglas en inglés) como un
intento por documentar y estandarizar información y prácticas generalmente
aceptadas en la gestión de proyectos y propone también un código de ética para
la profesión.

Quizás lo que ha hecho famoso al PMI es el desarrollo de la Guía de los

Fundamentos de la Dirección de Proyectos (más conocida como PMBOK® «A
Guide to the Project Management Body of Knowledge») que es el estándar para
manejar y administrar proyectos más ampliamente reconocido.
La primera edición de esta guía data de 1996, llevando al mundo un documento
que, poco a poco, fue calando en las industrias y en la administración de
proyectos, convirtiéndose en un estándar ANSI en el año 2000 con su segunda
edición (el único con esta categoría para la Gestión de Proyectos) y reconocido
internacionalmente en el IEEE Std 1490-2003. Para ese momento, contaba con
más de 40.000 personas en calidad de miembros activos, 10.000 PMP®
certificados y casi 300.000 copias vendidas del PMBOK®. En esta edición tuvo
lugar una fuerte importante evolución del estándar y cuando se empezó a cobrar,
ya que la de 1996 había sido gratuita. Actualmente va por la 6º edición.

El PMBOK® es un compendio de mejores prácticas, agrupadas de cierta manera,

heredadas de diversas industrias y disciplinas que conforman un modelo
metodológico. En sí, no es una metodología que «deba» ser seguida al pie de la
letra. Para citar uno de sus párrafos introductorios:

«Buenas prácticas» no quiere decir que los conocimientos descritos

deban aplicarse siempre de manera uniforme en todos los proyectos:
el equipo de dirección del proyecto es el responsable de determinar lo
que es apropiado para cada proyecto determinado.

El PMBOK® es sólo una guía, muy completa y elaborada, de lo que normalmente

un gerente de proyectos debe llevar a cabo, explicado en un buen nivel de detalle
y separando procesos que normalmente se llevan a cabo de forma simultánea.
Como modelo, el PMBOK® no nos indica cómo se hacen las cosas, al igual que
CMMi® pero es más explícito que este en la definición de los procesos o prácticas
a llevar a cabo, estableciendo una serie de entradas, técnicas y salidas para cada
uno.

Son normas, adoptadas por consenso voluntario, que identifican el subconjunto de

fundamentos generalmente reconocido como buenas prácticas. La clave del
alcance del PMBOK® está en tres palabras de esta frase:

 Identificar: proporcionar una descripción general.

 Generalmente reconocido: los conocimientos y las prácticas descritos son
aplicables a la mayoría de los proyectos y existe un amplio consenso sobre
su valor y utilidad.
 Buenas prácticas: existe un acuerdo general en que su correcta aplicación
aumenta las posibilidades de éxito de un proyecto, pero no son una norma.

Se centra en la descripción de los fundamentos para la dirección de

proyectos según la siguiente estructura:

 Influencia del ciclo de vida y de la organización/contexto en la gestión de un

proyecto.
 Descripción de los procesos de dirección de proyectos.
 Descripción las áreas de conocimiento específico para la gestión de un
proyecto.

El PMBOK® compite con otros modelos de gerencia de proyectos como son:

 APM, de la Association for Project Management (APM).

 PRINCE desarrollado en 1989 en el Reino Unido por la Central Computer
and Telecommunications Agency (CCTA).

Sin embargo, se ha posicionado a nivel mundial como estándar de gerencia de

proyectos y las certificaciones otorgadas sobre este, como Certificate Associate in
Project Management (CAPM®) y Project Management Professional (PMP®) son
las más reconocidas por las empresas y las más buscadas por los practicantes.
 La gestión de proyectos efectiva requiere que el equipo de dirección comprenda y
use conocimientos y habilidades correspondientes a cinco apartados:

 Fundamentos de la dirección de proyectos.

o Organización del proyecto.
o Procesos de dirección (5).
o Áreas de conocimiento (9).
 Conocimientos, normas y regulaciones del área de aplicación.
 Comprensión del entorno del proyecto.
 Conocimientos y habilidades de dirección general
 Habilidades interpersonales. Además de las capacidades técnicas y
administrativas, se requieren otro tipo de habilidades relacionadas con la
gestión de equipos humanos.

En la 5º una nueva área de conocimiento respecto a la 4º edición: «Interesados»)

que pueden ser aplicadas a la mayoría de los proyectos.

La 6º edición aparecida en 2.017 aporta las siguientes novedades:

  Nuevos procesos:
 Gestionar el conocimiento del proyecto.
 Implementar las respuestas a riesgos.
  Control de recursos.
 Cambios de nombre:
 Gestión del tiempo del proyecto pasa a llamarse: gestión del calendario del proyecto.
 Gestión de los recursos humanos del proyecto pasa a llamarse: gestión de los recursos.
 Categorías de los procesos. Se consideran casi 50 procesos divididos en 10 áreas de
conocimiento según tres categorías:

Organización del Proyecto

Relación con el ciclo de vida

Cada proyecto se descompone temporalmente en fases o etapas, para permitir,

entre otras cosas:

 Mejor control de la gestión, incluyendo el control de subcontrataciones

 Enlaces con las operaciones habituales de la organización
 El control de calidad

Al conjunto de las fases se le conoce como ciclo de vida y definen el comienzo, el

final y las fases de proyecto. Según el modelo de ciclo de vida, la sucesión de
fases puede ampliarse con bucles de realimentación (una misma fase se pueda
 ejecutar más de una vez a lo largo de un proyecto), dando lugar a los distintos
modelos de Ciclo de Vida, algunos de los cuales son:

 Ciclo de vida en cascada.

 Ciclo de vida en espiral.
 Entrega evolutiva.
 Prototipado incremental.

Independientemente de cuál sea la estructura general del ciclo de vida, cada fase

ha de comenzar y terminar con un hito que marque el comienzo y fin de las
actividades. Además, una fase:
 Lleva asociadas unas actividades de gestión.
 Se termina con la entrega de un producto tangible y verificable (ya sea un documento, un
servicio o un elemento físico o lógico).
 Su conclusión está marcada por una revisión tanto del producto como del rendimiento
para:
o Determinar si el proyecto debe continuar a su siguiente fase.
o Detectar y corregir errores de forma costo-efectiva.

La gestión de proyectos, tal y como la propone PMBOK® se lleva a cabo para

cada una de las fases del ciclo de vida. Como ya se ha mencionado
anteriormente, PMBOK® no hace ninguna suposición respecto a que ciclo de vida
debe de usar un proyecto concreto, sólo que ha de existir uno y que para cada una
de las fases se ha de llevar a cabo una serie de actividades de gestión, que son
transversales a toda la vida del proyecto. Se obtiene así una estructura matricial
entre gestión y desarrollo, como ilustra la siguiente figura. Muchos de los procesos
de gestión son iterativos debido a la naturaleza iterativa del ciclo de vida.

Intervinientes en el proyecto
 En un proyecto hay distintos roles correspondientes a los distintos intervinientes
en el mismo. Estos roles y su influencia en el proyecto son abordados por el
PMBOK® según el siguiente esquema:

 Stakeholders:

Aquellos individuos u organizaciones que están activamente involucrados en el proyecto,

o cuyos intereses pueden verse afectados, positiva o negativamente, como resultado de
la ejecución y término del proyecto. Pueden ejercer influencia en el proyecto y sus
resultados:

o Positiva.

o Negativa.

El equipo de gestión de proyectos debe:

o Identificar a los stakeholders.
o Determinar sus requerimientos.
o Gestionar e influenciar aquellos requerimientos, de modo que se asegure el éxito.

 Cliente/usuario:

La identificación de los clientes o usuarios es a menudo especialmente difícil y puede

producirse confusión entre ambos roles:

o Cliente: persona, organización o grupo que proporciona los recursos financieros.

Es el que arriesga su dinero en el desarrollo.
o Usuario: persona, organización  o grupo que usará los resultados del proyecto a
nivel operativo. A su vez puede haber varios tipos de usuario según el nivel de uso
o la parte de los resultados del proyecto que vayan a utilizar. Son los que nos
 darán pistas sobre el problema a nivel de funcionamiento. Son responsables de
que el sistema funcione de manera eficiente.
o Organización responsable: la principal organización implicada en el proyecto. Hay
que significar a los directivos de la organización que son los responsables de que
el sistema funcione de manera eficaz. Tienen una visión de conjunto, es decir, no
solo del sistema, sino además de la interrelación de éste con otros subsistemas de
la empresa.

Estos roles, en muchas situaciones los llevan las mismas personas, así en una
cooperativa de trabajo, el cliente y el usuario son la misma persona, En una sociedad
limitada, suelen coincidir director de empresa y cliente,…

 Project manager:
o Persona responsable de la administración de proyecto

o Persona responsable de administrar las expectativas de los interesados

o Negociador y facilitador
o Persona de referencia para un proyecto

 Equipo de gestión. Los miembros del equipo directamente involucrados en la gestión del
proyecto.
 Equipo del proyecto. El equipo que lleva a cabo el trabajo.

influencias organizacionales

Los proyectos son comúnmente parte de una organización más grande que el
proyecto. Por ello no pueden sustraerse a la influencia que esa organización
ejerce, desde distintos ámbitos y por diferentes motivos:

 Por la madurez de la organización.

 Por su cultura.
 Por el estilo de dirección.
 Por la estructura organizacional.

Áreas de Conocimiento

El PMBOK® 6th edición establece la administración de proyectos como un

conjunto de diez áreas de conocimiento que deben ser dominadas por el Project
Manager y que contienen una serie de procesos que corresponden a los pasos
necesarios para que sean completamente cubiertas. Son comunes a casi todos los
proyectos. En la matriz de dirección de proyectos que encontrarás más adelante
aparecen recogidos todos los procesos para cada área de conocimiento que se
describe a continuación:

 Gestión de integración del proyecto. Asegurar que los diversos procesos y

actividades que forman parte de la dirección del proyecto están coordinados
adecuadamente.
 Gestión del alcance del proyecto. Asegurar que el proyecto incluya todo los trabajos
requeridos y sólo ésos para completarlo satisfactoriamente. Básicamente, definir qué se
incluye y qué no en el proyecto.
  Gestión de la programación. Hasta la 5º edición recibía el nombre de gestión del tiempo
(duración) del proyecto. Se trata de los procesos relativos a la puntualidad en la
conclusión del proyecto para asegurar el término a tiempo del proyecto.
  Gestión de costes del proyecto. Procesos involucrados en la planificación, estimación,
presupuesto y control de costes de forma que el proyecto se complete dentro del
presupuesto aprobado.
  Gestión de calidad del proyecto. Procesos necesarios para asegurarse de que el
proyecto cumpla con los objetivos por los cuales ha sido emprendido.
  Gestión de recursos del proyecto. En la última edición esta área de conocimiento
adquiere más importancia: considerando todos los recursos necesarios para la gestión de
proyecto, no solo los recursos humanos. Aparece un nuevo proceso: controlar los
recursos.
  Gestión de comunicaciones del proyecto. Generación, recopilación, diseminación,
almacenamiento y destino final de la información en forma adecuada y a tiempo.
  Gestión de riesgos del proyecto. Identificación, análisis y respuesta a los riesgos del
proyecto. La nueva edición incorpora un nuevo proceso: implementar la respuesta a los
riesgos.
  Gestión de adquisiciones en el proyecto. Procesos para adquirir bienes, servicios o
resultados fuera de la organización ejecutante así como para contratar procesos de
dirección.
  Gestión de los interesados del proyecto. Considera los procesos relativos a la gestión de
los interesados de alguna manera en el proyecto.
Procesos de dirección

El PMBOK reconoce 5 grupos de procesos básicos comunes a casi todos los

proyectos. Los procesos se solapan entre sí en el tiempo e interactúan a través de
un proyecto o fase y son descritos en términos de:
 Grupo de procesos de iniciación.
 Grupo de procesos de planificación.
 Grupo de procesos de ejecución.
 Grupo de procesos de seguimiento y control.
 Grupo de procesos de cierre.
La distribución temporal de estos grupos de procesos no es secuencial, sino que
hay solapes e interacciones en el tiempo:

Matriz de dirección de proyectos

El PMBOK® puede verse de dos formas diferentes, cual si fuera una matriz que
puede leerse por columnas o filas. La forma estándar como está estructurado el
documento establece áreas de conocimiento. La forma útil para el gerente de
proyectos y la organización es, sin embargo, por grupos de procesos de Inicio,
planificación, ejecución, control y cierre.
 Una metodología Agile para la gestión
proyectos: SCRUM
Scrum define un proceso empírico, interactivo e incremental de desarrollo que
intenta obtener ventajas mediante la construcción de un marco de trabajo, en el
cual las personas pueden acometer problemas complejos adaptativos
maximizando el valor de los productos obtenidos de manera creativa a la vez que
se mejora el rendimiento del equipo.
Se trata de un proceso en el que se aplican un conjunto de buenas prácticas para
trabajar de manera colaborativa en equipo. El mismo surge de un artículo de 1986
de la Harvard Business Review titulado The New Product Development Game de
Takeuchi y Nonaka, que introducía las mejores prácticas más utilizadas en 10
compañías japonesas altamente innovadoras. A partir de ahí y tomando
referencias al juego de rugby, Ken Scwaber y Jeff Sutherland formalizan el
proceso conocido como Scrum en el año 1995.
Esta metodología esta especialmente indicada para proyectos en entornos
complejos, donde:

 Se necesita obtener resultados rápido.

  Los requisitos están poco definidos o son cambiantes.
  La competitividad, la flexibilidad, la productividad y la innovación son claves.

Ventajas:

 Fácil de aprender y poco esfuerzo para su implementación.

 Muy adecuada para proyectos con requisitos incompletos.
 Las reuniones diarias permiten visualizar avances y problemas.
 Se obtiene mucha retroalimentación del cliente.
 Facilita el cumplimiento de plazos.

inconvenientes:

 Las tareas mal definidas pueden originar un incremento de costes y plazos.

 Necesidad de equipos comprometidos y experimentados para que funcione.
 Al tratarse de equipos reducidos, el abandono de un miembro puede ser un problema.
  Si no se fijan fechas de fin, se corre el riesgo de que el cliente pida nuevas
funcionalidades.

Los roles principales de Scrum son:

 Product Owner: es el encargado de alimentar y revisar las actividades necesarias para
que el desarrollo del proyecto sea llevado acabo como el cliente lo quiere.

 Scrum Master: es el líder del grupo de Scrum, entre sus principales actividades está el
estar pendiente de que las tareas que se establezcan con el Product Owner y que estas
sean llevadas a cabo de manera correcta y en el orden establecido.

 Scrum Team: grupo de desarrollo con habilidades que permiten que las tareas sean
generadas lo más completas posibles

 Cliente: recibe el producto y puede influir en el proceso, entregando sus ideas o

comentarios respecto al desarrollo.

El corazón de Scrum es el sprint, es un bloque de tiempo (time-box) de 2-4

semanas durante el cual se crea un incremento de producto «terminado»,
utilizable y potencialmente desplegable.

Al principio del proyecto se define el product backlog, que contiene todos los
requisitos funcionales y no funcionales que deberá satisfacer el sistema a
construir. Los mismos estarán especificados de acuerdo a las convenciones de la
organización ya sea mediante: features, casos de uso, diagramas de flujo de
datos, incidentes, tareas, etc.

El product backlog será definido durante reuniones de planeamiento con

los stakeholders. A partir de ahí se definirán las interacciones, conocidas como
Sprint en la jerga de Scrum, en las que se irá evolucionando la aplicación
evolutivamente. Cada sprint tendrá su propio sprint backlog que será un
subconjunto del product backlog con los requisitos a ser construidos en
el sprint correspondiente. La duración recomendada del sprint es de un mes.
Como se puede observar en la figura que aparece a continuación, la metodología
resulta sencilla definiendo algunos roles y artefactos que contribuyen a tener un
proceso que maximiza el feedback para mitigar cualquier riesgo que pueda
presentarse.

Descripción de roles, artefactos, reuniones y proceso de desarrollo de Scrum.

Fuente: William C. Wake (http://www.xp123.com)
 La intención de Scrum es la de maximizar la realimentación sobre el desarrollo
pudiendo corregir problemas y mitigar riesgos de forma temprana. Su uso se está
extendiendo cada vez más dentro de la comunidad de metodologías Agiles, siendo
combinado con otras (como XP) para completar sus carencias. Cabe mencionar que
Scrum no propone el uso de ninguna práctica de desarrollo en particular; sin embargo,
es habitual emplearlo como un framework ágil de administración de proyectos que
puede ser combinado con cualquiera de las metodologías mencionadas.

Un poco más a fondo: creando el product backlog

El product backlog es una forma rápida de manejar las necesidades de los usuarios
sin tener que tratar con documentos de gran exigencia formal y tediosas tareas
relacionadas con el mantenimiento de los mismos. La intención es poder responder
más rápido y con menos sobrecarga rápidamente a las cambiantes necesidades
reales.

¿Por qué necesitamos el product backlog?

Las principales razones para tener backlog son:

 Comunicación a las partes interesadas. Al tener un product backlog, las partes

interesadas tienen una imagen de lo que está previsto y lo que no está
previsto. Y al agregar sensación de velocidad, los interesados también pueden
obtener una opinión de la fecha en la que cosas van a ser implementadas.

 Comunicación con los desarrolladores. Los desarrolladores pueden ver la hoja

de ruta por delante, pero también pueden ver las prioridades: lo que deba
aplicarse y lo que puede esperar. Esto también puede ser una buena cosa
durante el desarrollo real. Dependiendo de planes para el futuro cercano, se
pueden implementar soluciones diferentes.

 Identificar posibles recortes en el ámbito de aplicación. Al dividir la

funcionalidad vaga en partes más específicas, pueden suprimir las cosas
menos importantes por ahora. Y esto puede comunicarse a las partes
interesadas y los desarrolladores.

¿Qué debe contener el backlog?

 Una lista de trabajo.
 Requisitos funcionales: historias de usuario, funciones, productos, funcionalidades.
 Requisitos no funcionales: rendimiento, robustez, seguridad, facilidad de uso, errores, los
requisitos...
 Priorización.
 Estimación del equipo.
 Tener información más detallada sobre los temas mayor prioridad.
 Mantenimiento y publicaciones visibles.
 Re-priorización al principio de cada iteración.