Metodologas de proyectos.

Scrum: gestin gil de proyectos (agile Project management) . Actualmente, la

metodologa gil ms popular para la gestin de proyectos es Scrum

Scrum es una metodologa de desarrollo gil basado en procesos iterativos e

incrementales. El desarrollo parte de una idea general de lo que se requiere construir,
elaborando un listado de caractersticas ordenadas por prioridad (product backlog)
que el propietario del producto desea obtener. El product backlog ser un documento
en constante actualizacin y al cual podrn acceder todos los interesados. A partir de
aqu se efectuar una reunin para la planificacin del primer sprint (la primera
iteracin), en la cual se generar una lista de tareas (sprint backlog) con
asignaciones de personas y una estimacin de tiempo y recursos. Adicionalmente se
establecer el objetivo del sprint (necesidad del negocio a cubrir). El sprint (iteraccin)
dar como resultado una primera versin parcial del producto (resultado incremental).
Cabe destacar que, en cada proyecto se debe definir una duracin fija de los sprints,
siendo recomendable que se encuentre entre los 15 y 60 das. Durante el sprint, se
realizar una reunin diaria (15 minutos mximo) donde cada componente del equipo
da respuesta a los siguientes aspectos:

Trabajo realizado desde la reunin de seguimiento anterior.

Trabajo a realizar hasta la prxima reunin.

Limitaciones reales o potenciales que puedan impedir la ejecucin del trabajo.

Al finalizar el sprint se realiza una revisin, donde se evala el mismo y se presentan
los resultados obtenidos. De esta forma habr concluido el primer sprint y se podr dar
lugar a una nueva iteracin, volviendo a efectuar una reunin de planificacin del
nuevo
sprint.

Responsabilidades: Tal y como hemos visto, aparte del equipo de trabajo, hay dos
figuras bien diferenciadas:
Propietario del producto: representante del rea de negocio (product manager o
responsable de marketing para desarrollos internos) que tiene entre sus
responsabilidades los siguientes objetivos:

Obtener el mximo valor para usuarios y clientes.

Financiacin

Decisin para efectuar el lanzamiento

Scrum Master:
metodologa.

responsable

Componentes bsicos

de

garantizar

que

se

aplica

correctamente

la

Durante el desarrollo del proyecto se trabaja con tres elementos bsicos:

Product backlog proporciona los requisitos desde el punto de vista del negocio y
cada uno de estos debe estar compuesto por:

Identificador nico de la funcionalidad

Descripcin

Prioridad

Estimacin en tiempo

Criterio de validacin
Sprint backlog determinas las tareas a realizar desde la perspectiva del desarrollo
de software. En su elaboracin debe participar todo el equipo y cubre todas las tareas
necesarias (se recomienda actividades de tamao entre 4 y 16 horas) para conseguir el
objetivo del sprint. Todo el equipo debe tener acceso permanente a esta informacin
va digital (p.ej. hoja de clculo, herramienta de gestin) o fsicamente en el espacio de
trabajo (p.ej. pizarra). El sprint backlog contiene por cada tarea:

Identificador

Descripcin

Responsable

Estado

Estimacin del tiempo pendiente para su finalizacin

El incremento parte del producto desarrollado en un sprint, el cual ya se encuentra
preparado para ser entregado al cliente y por tanto, terminado y probado (no se trata
de mdulos no funcionales o similares). Cabe destacar que la primera iteracin puede
resultar difcil cumplir con la produccin de un incremento entregable y por regla
general, se suele ser considerar la nica excepcin.
Reuniones
Planificacin del sprint
Asiste el propietario del producto, el scrum master y todo el equipo de trabajo. En una
primera parte (mximo 4 horas), el propietario del producto informa de los posibles
cambios del product backlog y los motivos con el objetivo de que todo el mundo
conozca los detalles. Adems, presentar una propuesta de elementos a desarrollar
para el siguiente sprint con su respectiva prioridad y estimacin en tiempo (el cual ser
contrastado y acordado entre todo el equipo). El equipo participa planteando dudas y
replanteando funcionalidades. El objetivo es conseguir el mximo grado de implicacin

y la generacin de valor multidisciplinar para acabar escogiendo los elementos del

product backlog que finalmente se desarrollaran en el sprint. En una segunda parte
(mximo 1 da contando la primera parte), se desglosan las tareas necesarias para el
desarrollo de los elementos seleccionados. Teniendo en cuenta los conocimientos e
intereses, cada miembro del equipo se auto-asigna las tareas de las que se
compromete a ser responsable (garantizando paralelamente la distribucin homognea
y equilibrada). Como resultado de la reunin se obtendr el sprint backlog y la fecha de
la reunin de revisin. El scrum master tiene como finalidad la conduccin y
moderacin de la reunin, garantizando que los objetivos de la reunin son alcanzados.
Durante la reunin, aparte de los soportes digitales, se recomienda el uso de
elementos fsicos sobre los que poder distribuir las diferentes tareas. Por ejemplo, es
habitual el uso de post-its sobre una pizarra la cual se encuentra dividida en:
Objetivo general del sprint y fecha de la reunin de revisin

Fila de elementos del product backlog a cubrir ordenados por prioridad (1 por

post-it)

Debajo de cada elemento, conjunto de tareas a realizar (1 por post-it)

Monitorizacin del sprint: Reunin diaria donde actualizar el sprint backlog con las
tareas ya realizadas o los tiempos pendientes. Adicionalmente, se actualizan tambin
los grficos burn-down. A la reunin acude la totalidad del equipo y estos son los nicos
que pueden intervenir en caso de que se incorporen otras personas (p.ej. el propietario
del producto). La duracin mxima debe ser de 15 minutos y se recomienda realizarla
de pie enfrente de alguna pizarra con los elementos del sprint backlog en forma de
post-it.
Revisin del sprint: Reunin informativa que se efecta una vez finalizado el sprint y
a la que asiste el equipo de trabajo, el propietario del producto, el scrum master y
todos aquellos interesados en el proyecto (p.ej. cliente).
Prince2: complemento a pmbok
PRINCE2 (PRojects IN Controlled Environments) es una metodologa de gestin de
proyecto desarrollada inicialmente por el Central Computer and Telecommunications
Agency (CCTA) del gobierno de Reino Unido y que actualmente tambin es usado en
organizaciones privadas.
PRINCE2 se basa en los mismos principios que PMBOK y amplia los conceptos que este
presenta, proporcionando tcnicas complementarias para reducir el riesgo e
incrementar la calidad en los proyectos de la forma ms efectiva. No obstante,
PRINCE2 deja fuera de su alcance aspectos que si cubre PMBOK, como por ejemplo:

Gestin de personas: motivacin, lideraje y delegacin

Tcnicas de planificacin genricas como Critical path y Gantt Charts

Tcnicas de gestin del riesgo

Tcnicas de anlisis financiero o presupuestario

Componentes bsicos: Como hemos

interactan con 8 componentes bsicos:

apuntando,

los

procesos

de

PRINCE2

Business Case: Documentacin corresponde a la fase previa al inicio del

proyecto, la cual definir el rumbo del proyecto.

Organizacin: El proyecto requerir recursos de la organizacin, debern

tomarse decisiones de inversin y efectuar un control presupuestario.

Planes: Espina dorsal del proyecto, donde se detalla la planificacin de las

diferentes partes del mismo.

Controles: Es necesario es garantizar el cumplimiento de los requisitos, el

control de las desviaciones en tiempo/costes y la verificacin de que la viabilidad del
proyecto no se ve afectada segn los criterios establecidos en el Business Case.

Gestin del riesgo: Anlisis del riesgo y definicin de estrategias para afrontarlo.

Gestin de la calidad: Los requerimientos de calidad son descritos mediante

Product Descriptions, preparados por el Project Manager y aprobados por el Project
Board.

Gestin de configuraciones: Proporciona mecanismos para realizar seguimiento

y control de los entregables y los aspectos pendientes (issues).

Gestin del cambio: Verifica el impacto de cambios potenciales sobre el

Business Case, siendo un apoyo fundamental para la toma de decisiones.

Puesta en marcha del Proyecto (Starting up a Project): Diseo y eleccin del

equipo de trabajo (incluido el Project Board), definicin de la necesidad a cubrir y el
approach para afrontarla.

Direccin del Proyecto (Directing a Project): Tiene lugar durante todo el proyecto
y permite al Project Manager consultar y solicitar apoyo/autorizacin al Project
Board.

Iniciacin del Proyecto (Initiating a Project): Anlisis y definicin de los

requerimientos y elementos crticos mediante la creacin del documento PID
(Project Initiation Document).

Gestin de los limites de las etapas (Managing Stage Boundaries): Gestin de la

transicin de una etapa a la siguiente, proporcionando informacin al Project
Board para validar la aceptacin del paso de etapa.

Control sobre una etapa (Controlling a Stage): Trabajo diario del Project
Manager, el cual se encarga de la gestin de cambios, recoleccin de
informacin sobre el grado de avance, toma de decisiones para la aplicacin de
medidas correctivas y, en caso de ser necesario, escalado de problemas o
peticiones al Project Board.

Gestin de la entrega del producto (Managing Product Delivery): Sistema de

autorizacin de trabajo, el cual ofrece mecanismos para establecer que trabajo
debe ser realizado mediante Work Packages.

Cierre del proyecto (Closing a Project): Se valida que las necesidades han sido
cubiertas, se realizan sugerencias de cara a futuro y se liberan los recursos
ocupados.

Planificacin (Planning): La planificacin tiene lugar de forma repetida en

diversos procesos (p.ej. Planificacin del proyecto, Inicio de una etapa, etc.). El
objetivo es la creacin de planes y calendarios en base a los requerimientos,
actividades y recursos disponibles.

Aportaciones principales de PRINCE2 sobre PMBOK

Project Board : PRINCE2 introduce la idea de disponer de una junta o Project Board,
cuyo principal objetivo radica en facilitar la correcta ejecucin del proyecto. En
repetidas ocasiones, sobretodo en organizaciones que no trabajan orientadas a
proyectos y estos son puntuales, el Project Manager controla y dirige el proyecto pero
no dispone de suficiente autoridad. Sin embargo, si se constituye un Project Board con
miembros pertenecientes a la cpula directiva media o alta, el Project Manager puede
superar las limitaciones en su autoridad mediante esta junta.
Product Breakdown Structure, Product Descriptions y Product Flow Diagram:
PRINCE2 se orienta a la generacin de productos, entendiendo producto como un
elemento tangible (p.ej. maquinaria, documentos, etc.) o intangible (p.ej. software).
Con dicha finalidad, PRINCE2 presenta la tcnica de la generacin del Product
Breakdown Structure (PBS). El PBS es utilizado para la identificacin tanto de los
entregables (productos especficos) como de los productos (p.ej. documentos)
necesarios para la gestin (productos de gestin).No obstante, segn el proyecto, este
esquema puede reducirse o ampliarse en funcin de las necesidades. Por otra parte,
los productos especficos dependen en su totalidad del proyecto y cada uno de ellos
sera documentado mediante un Product Description que contendr:

Objetivo

Requerimientos

Tareas necesarias

Recursos necesarios

Criterios para su aceptacin

Mecanismos para medir los criterios de aceptacin

4. Gerencia de Proyectos de Desarrollo de Software segn CMMI-Dev

Propsito e implementacin Una vez ms, la diferencia respecto de las dos
metodologas de proyectos ya revisadas, salta a la vista. En primer lugar, los

servicios de tecnologa y de desarrollo de software especialmente, destacan un

inusitado auge de crecimiento, al punto de que en pases emergentes, por
mencionar un ejemplo, este sector econmico se ha multiplicado en relacin
con otros sectores de la economa [33], [34] y [35]. De este modo, contar con
un modelo de procesos para la gestin de proyectos de desarrollo de software,
es de vital importancia para la economa del Pas [36] [37]. La Integracin de
Modelos de Madurez de Capacidades (Capability Maturity Model Integration for
Development, CMMI-Dev3 Figura 5. Prcticas genricas segn CMMI Fuente:
Adaptado de CMMI for Development. Carnegie Mellon. Software Engineeering
Institute. V 1.2. USA (2006). La implementacin de CMMI-Dev se puede resumir
en las etapas descritas en la figura 6. Dentro de ellas, se debe tener claro el
alcance del proyecto para determinar el propsito que va a desempear el
software, y analizar las necesidades del cliente, ms all de sus
requerimientos. En otras palabras, este modelo utiliza un proceso que
convierte el metalenguaje de los clientes o usuarios, expresado en sus
necesidades y requerimientos tcnicos, pues en cuestiones de software,
muchas veces los requerimientos tcnicos descritos por el cliente no
corresponden al cumplimiento de sus expectativas [41] y [42]. Una vez
establecidos los requerimientos tcnicos y verificados mediante claros
indicadores de gestin, se contina con el diseo y desarrollo del producto,
para luego seguir con las pruebas de aceptacin con el cliente, de manera que
se determine e implemente cambios o mejoramientos necesarios para llevar
finalmente, el software a produccin. ), entra a llenar ese vaco y se considera
un estndar que cubre las actividades de desarrollo y mantenimiento aplicadas
a los productos y servicios, adems de proporcionar herramientas para el
mejoramiento y la evaluacin de los procesos enfocados al desarrollo,
mantenimiento y operacin de sistemas de software [38], [39] y [40]. En la
figura 5, se muestra la estructura de las prcticas genricas planteadas por
este modelo de gerencia de proyectos. La implementacin de CMMI-Dev se
puede resumir en las etapas descritas en la figura 6. Dentro de ellas, se debe
tener claro el alcance del proyecto para determinar el propsito que va a
desempear el software, y analizar las necesidades del cliente, ms all de sus
requerimientos. En otras palabras, este modelo utiliza un proceso que
convierte el metalenguaje de los clientes o usuarios, expresado en sus
necesidades y requerimientos tcnicos, pues en cuestiones de software,
muchas veces los requerimientos tcnicos descritos por el cliente no
corresponden al cumplimiento de sus expectativas [41] y [42]. Una vez
establecidos los requerimientos tcnicos y verificados mediante claros
indicadores de gestin, se contina con el diseo y desarrollo del producto,
para luego seguir con las pruebas de aceptacin con el cliente, de manera que
se determine e implemente cambios o mejoramientos necesarios para llevar
finalmente, el software a produccin. Independiente del modelo seleccionado,
las prcticas de CMMI-Dev son adaptables a casi cualquier organizacin que
involucre el desarrollo de software en funcin de sus objetivos de negocio, bien
para evaluar los avances en la implementacin de los modelos y las buenas
prcticas o para identificar los cambios o mejoras requeridas. Atendiendo la
necesidad de identificar la adherencia de los procesos, CMMI-Dev cuenta con
dos modelos de evaluacin, el escalonado o por etapas y el de representacin
continua. Los dos modelos no son equivalentes, son adaptables a cualquier
empresa y no requieren utilizarse en forma simultnea; en consecuencia, cada

empresa es autnoma para implementar uno de los dos modelos como gua
para evaluar la adopcin de los procesos en su da a da [43]. En este sentido,
el primer modelo establece cinco niveles de madurez para clasificar las
organizaciones, los cuales se describen en la figura 7, y sintetizan la evaluacin
del nivel de madurez organizacional por medio de la identificacin de los
procesos que obtienen los objetivos planteados. Este modelo se recomienda
para una organizacin que busque mejorar sus procesos [44]; por otra parte, el
segundo modelo establece seis niveles de capacidad que clasifican los
procesos de una organizacin, de acuerdo con lo descrito en la figura 8, y
puede ser til para una organizacin con conocimiento maduro de sus propios
objetivos estratgicos.
1. politica organizacional
2. planear procesos
3. proveer recursos
4. asignar responsabilidades
5. entrenar equipo de trabajo
6. administrar la configuracin
7. involucrar personal
8. monitorear y controlar
9. evaluar adherencias
10. revisin de la alta gerencia.