Introducir PRINCE2 Agiles

Introducir PRINCE2 e ISO
21500 y conocer metodologas

giles como SCRUM
Introducir PRINCE2 e ISO 21500 y conocer metodologas giles como SCRUM
INTRODUCIR PRINCE 2 E ISO 21500 Y CONOCER METODOLOGAS

GILES COMO SCRUM
Adems de la metodologa de PMI plasmada en el PMBOK y la de IPMA basada en las

competencias que debe poseer un director de proyectos, existen en Direccin de Proyectos
otros marcos de referencia como son el estndar PRINCE 2 y la nueva norma ISO 21500.
Tambin se desarrolla en esta UD la gestin gil de proyectos a travs del conocimiento de
SCRUM o Agile.
CONTENIDO
En esta Unidad Didctica se desarrollan los siguientes contenidos:

PRINCE2 ..................................................................................................................... 3
ISO 21500 ................................................................................................................ 11
Metodologas giles .................................................................................................... 17
Competencia ............................................................................................................. 30
HABILIDAD
En esta Unidad Didctica debers realizar los siguientes ejercicios para desarrollar tus
habilidades profesionales:
Autoevaluacin
Test de la Unidad Didctica
Tarea de la Unidad Didctica (TUD): Trabajo individual del alumno a enviar al tutor.
Caso Prctico de la Asignatura (CP): Trabajo en grupo a enviar al tutor.
COMPETENCIA
En esta Unidad Didctica se desarrolla la siguiente competencia de Direccin de

Proyectos:
Competencia tcnica: Cambios
PRINCE2
Es un mtodo prescriptivo basado en procesos que proporcionan una estrategia

estructurada y flexible para la gestin de todo tipo de proyectos. PRINCE (PRojects IN
Controlled Environment o proyectos, que por defecto implican variabilidad e incertidumbre, en
un entorno controlado) es utilizado de facto en Gran Bretaa para la gestin de proyectos
puesto que naci como una iniciativa del gobierno britnico para mejorar su gestin y
aumentar as la posibilidad de xito en los proyectos.
Algunos factores claves para el xito del proyecto son:
Conocer de forma precisa los requisitos del cliente del proyecto y/o del producto del
proyecto.
Definir claramente los objetivos y entregables del proyecto
Planificar en alcance, plazo y coste la ejecucin del proyecto
Seleccionar al equipo de personas ms adecuado y que mejor trabaje en grupo para
llevar a cabo el proyecto
Controlar el proyecto durante su ejecucin
Basados en estos principios de xito, se puede establecer que PRINCE2 ofrece los
siguientes beneficios en la gestin de proyectos (gueda, 2012):
Puede utilizarse para gestionar todo tipo y tamao de proyectos

Consigue que se utilice un lenguaje comn
Establece unos roles y responsabilidades bien definidos
Centrado en los productos entregables del proyecto
Utiliza como gua para el proyecto un Business Case lo que implica que no se centre en
conseguir la terminacin del proyecto, sino obtener los beneficios establecidos en dicho
documento
Insta a la utilizacin de las lecciones aprendidas de otros proyectos desde el inicio del
proyecto lo que promueve el aprendizaje y la mejora continua de las organizaciones
Establece una estructura completa de informes bsicamente econmicos
Asegura una representacin adecuada de las partes interesadas durante la planificacin
y la toma de decisiones
VIDEO EN INTERNET
A continuacin puedes ver un video que expone las principales

caractersticas de este estndar: PRINCE2 in 90 seconds
En PRINCE2 se identifican seis variables interrelacionadas que intervienen en

cualquier proyecto como seis aspectos que deben ser gestionados al ejecutar o implantar los
proyectos:
Alcance
Coste
Plazo
Calidad
Riesgo
Beneficios, preferiblemente en trminos econmicos
Estructura de PRINCE2
La estructura de PRINCE2 se organiza en cuatro partes:
Los principios son buenas prcticas que es necesario que sean

implementadas para asegurar el xito del proyecto.
Son 7:
Continua justificacin de negocio
Aprender de la experiencia
Principios
Roles y responsabilidades definidos
Gestin por fases
Gestin por excepcin
Orientado a los productos
Adaptable
Las temticas son aspectos de la Direccin de Proyectos que

deben ser gestionados.
Son 7:
Business Case
Progreso
Temticas
Riesgo
Calidad
Cambio
Organizacin
Planes
Los procesos son conjuntos de actividades que deben llevar a

cabo los miembros del equipo de proyecto.
En cada proceso se establecen listas de actividades recomendadas
y productos y responsabilidades relacionados.
Son 7:
Direccin de un proyecto
Procesos Puesta en marcha de un proyecto
Iniciar un proyecto
Control de una fase
Gestin de los lmites de fase
Gestin de la entrega de productos
Cerrar un proyecto
PRINCE2 debe ser adaptado para que refleje necesidades

Adaptacin organizacionales y especificas segn el tipo y tamao del
proyecto.
Principios
Temticas Procesos
Adaptacin
Principios
El mtodo PRINCE2 se rige por siete principios que no solo enriquecen al proyecto que
se est gestionando sino a toda la organizacin involucrada. Son universales, es decir se
atribuyen a todos los proyectos, vlidos por que han sido largamente puestos en prctica y
motivadores de la actividad de gestin del proyecto (gueda, 2012).
Principios de PRINCE2
1 Justificacin Asegurar un motivo de negocio justificable para iniciar el

continua de proyecto, que se mantenga durante todo el ciclo de vida del
negocio proyecto y que se identifica y aprueba mediante el Business Case.
El equipo de proyecto aprende continuamente de la experiencia

adquirida. Al iniciar el trabajo del proyecto, el equipo de proyecto
2 Aprender de la
estudia las lecciones aprendidas de proyectos similares anteriores
experiencia
y durante el proyecto, recoge las lecciones aprendidas y las
compila al cierre del mismo.
3 Roles y
Establecer una estructura organizativa que asegura los intereses
responsabilidades
del negocio, del usuario del proyecto y de los proveedores
definidos
4 Gestin por
Planificar, monitorizar y controlar fase a fase.
fases
Delegar la autoridad a los niveles inferiores hasta unos lmites o
5 Gestin por
tolerancias en las variables (alcance, plazo, coste, tiempo,
excepcin
calidad, riesgo y beneficios) establecidos previamente.
Orientar el proyecto a la definicin y entrega de productos y sus

6 Orientacin a
requisitos de calidad, no a la realizacin de una serie de tareas o
productos
actividades.
Adaptar el mtodo PRINCE 2 al tipo, tamao, complejidad,

7 Adaptacin
entorno, importancia, riesgo, capacidad, etc. del proyecto.
Temticas
Son aspectos de la Direccin de Proyectos que el director de proyecto debe tener

siempre y de forma continua en cuenta al gestionar un proyecto. En PRINCE2 estos
aspectos estn desarrollados de forma integrada para que estn vinculados entre s con
efectividad. Tal y como se expresa en los principios de PRINCE2, las temticas se deben
adaptar por exceso o por defecto al proyecto en cuestin.
Temticas de PRINCE2
Por qu?
En esta temtica se trata de establecer mecanismos para controlar
que la idea que dio inicio al proyecto, en la que la organizacin debe
1 Business invertir, sigue siendo deseable, viable y alcanzable y que cumple
Case con los objetivos estratgicos de la organizacin.
Un Business Case es un documento que describe las razones para el
proyecto en base a los costes estimados, los riesgos y los beneficios
esperados. (PRINCE2)
Quin?
El proyecto necesita una organizacin temporal puesto que las
estructuras jerrquicas funcionales de las empresas no son
apropiadas para los proyectos.
PRINCE2 establece una organizacin en cuatro niveles de gestin:
Gestin corporativa o del programa
2
Organizacin Direccin Junta de proyecto: compuesta por el usuario
principal, ejecutivo (promotor del proyecto) y el proveedor
principal.
Gestin Project Manager
Entrega Team Manager
Los tres ltimos niveles (direccin, gestin y entrega) forman el
equipo de gestin del proyecto
Qu?
Esta temtica tiene dos procesos relacionados.
Planificacin de calidad: Comprender, definir y documentar las

3 Calidad
expectativas y requisitos de calidad de los productos a entregar y
los criterios de aceptacin del producto y del proyecto.
Control de calidad: Controlar que los productos entregables del
proyecto cumplen con las descripciones de producto especificadas
en el paso anterior a partir de los requisitos de calidad.
Niveles de planificacin en PRINCE2
Cmo? Cunto? Cundo?

Establece el desarrollo de planes que faciliten el control de la
ejecucin del proyecto y la comunicacin entre los stakeholders.
Un plan es un documento que describe cmo, cundo y quin
obtiene uno o un conjunto de objetivos especficos del proyecto.
Estos objetivos son los productos del proyecto, plazo, coste, calidad
y beneficios.
PRINCE2 establece una planificacin gradual. El proyecto estar
dividido como mnimo en dos fases de gestin. Se desarrollar un
Plan de proyecto a alto nivel y un plan de fase detallado para la fase
que se est desarrollando en ese momento.
Niveles de planificacin:
o Plan de proyecto: establece a alto nivel el alcance, plazo,
coste, calidad, productos entregables, actividades y recursos
requeridos por el proyecto.
o Plan de fase: muy similar al Plan de proyecto pero establece
una planificacin que permita al Project Manager controlar al
da el proyecto. Cuando se aproxima el final de la fase en
curso, se realiza el Plan de fase para la siguiente fase.
o Plan de equipo: es realizado por el Team Manager para
facilitar la ejecucin de uno o varios paquetes de trabajo de
4 Planes la fase en curso. No son obligatorios.
o Plan de excepcin: se desarrollan cuando alguna de las
variables del proyecto ha superado los lmites de tolerancia
establecidos, para recuperar esta desviacin.
PRINCE2 establece una forma de planificacin basada en los
productos entregables, que establece:
o En primer lugar definir y analizar los productos entregables
del proyecto (o de la fase)
o A continuacin identificar las actividades necesarias para
desarrollarlos.
o Por ltimo estimar tiempo, recursos y costes.
Para definir y analizar los productos entregables se establece
un proceso que incluye:
o Escribir la descripcin del producto del proyecto
o Crear la PBS (Project Product Structure)
o Escribir las descripcin de cada uno de los productos de la
PBS
o Crear el diagrama de flujo de los productos. Este diagrama
define la secuencia de actividades en la que se desarrollan
los productos del plan.
Qu pasa si?
Los proyectos se desarrollan bajo un nivel de incertidumbre y de
variabilidad mayor al de los procesos y otras actividades. Debido
5 Riesgo a esto existen mayores riesgos que afectan a la consecucin del
xito en el proyecto.
En esta temtica se trata de identificar, analizar y controlar los
riesgos que pueden afectar a los objetivos del proyecto.
Cul es el impacto?
Un proyecto siempre est sometido a cambios. Esta temtica se
ocupa de que los cambios a las lneas base sean identificados de
forma proactiva, evaluados, aprobados y controlados.
6 Cambio Los cambios pueden llegar desde el equipo de proyecto o desde el

resto de stakeholders externos al proyecto.
PRINCE2 utiliza la palabra cuestiones para referirse a cualquier
evento importante que haya ocurrido, que no estaba planificado y
requiera alguna accin de gestin. Se establecen procedimientos
para el control de las cuestiones.
Dnde estamos ahora? A dnde vamos? Deberamos

continuar?
Progreso es la medida del logro de los objetivos establecidos en
los planes.
7 Progreso En esta temtica se siguen los planes reales y se comparan los

logros con los objetivos planificados para determinar si es viable
la continuidad del proyecto.
Tambin se controlan y se establecen excepciones para las
desviaciones o eventos no aceptables. Se determina si el proyecto
debera continuar y en qu modo.
Procesos
Los procesos que utiliza PRINCE2 se pueden definir como: conjunto estructurado de
actividades diseadas para lograr un objetivo especfico.
Fase/s de entrega Fase final de

Preproyecto Fase de inicio
subsiguiente/s entrega
Direccin Puesta en
Direccin de un proyecto
marcha
Gestin de los Gestin de los Cerrar un
lmites de fase lmites de fase proyecto
Gestin
Iniciar un Control de una Control de una
proyecto fase fase
Gestin de la entrega Gestin de la entrega

Entrega de productos de productos
Procesos de PRINCE2 en el ciclo de vida del proyecto
Procesos de PRINCE2
Reunir los datos necesarios para comenzar el proyecto.

Asegurar que se cumplan los prerrequisitos necesarios para el
Puesta en inicio del proyecto.
marcha Evitar que aquellos proyectos inicialmente mal definidos sean
lanzados.
Lanzar proyectos viables.
Autorizar el proyecto y su inicio.

Dirigir el proyecto delegando la gestin diaria del mismo en el
Direccin de Project Manager.
un proyecto
Ejercer el control del proyecto autorizando cada una de las fases.
Cerrar el proyecto.
Establecer las bases del proyecto mediante la creacin de la

Inicio de un documentacin de inicio del proyecto.
proyecto Examinar la justificacin del proyecto detallando y ajustando el
Business Case.
Describir y asignar el trabajo a realizar.

Control de Seguir, controlar el trabajo realizado y reportar estos datos a la
una fase Junta de Proyecto.
Gestionar las cuestiones y cambios que se produzcan
Establecer los requisitos para ejecutar, aceptar y entregar los

productos del proyecto.
Gestin de la
entrega de Entregar los productos realizados del proyecto.
productos
Un proyecto PRINCE2 tiene como mnimo dos fases: fase de inicio
y fase de entrega.
Proporcionar de forma controlada la forma de completar la fase

actual y la planificacin de la siguiente.
Gestin de los
Confirmar con ayuda del Business Case que la justificacin
lmites de fase
comercial del proyecto continua.
Informar a la Junta de Proyecto del desarrollo de la fase actual.
Revisar que se han alcanzado los objetivos del proyecto.

Cierre de un
proyecto Verificar la aceptacin formal de los entregables del proyecto por
los usuarios o clientes.
10

ISO 21500
Para ayudar en la implantacin de la Direccin de Proyectos en las organizaciones,

nace la norma ISO 21500 Directrices para la direccin y gestin de proyectos.
Diferentes normas han servido de referencia para la ISO 21500, adems de expertos,
asociaciones y organizaciones que han aportado sus conocimientos, estndares y marcos de
referencia:
Normas: BS 6079-1 Guide to Project Management, DIN 69901-2 Project Management:

Project Management Systems, Prince 2, etc.
Asociaciones: APM, Australian Institute of Project Management, IPMA, PMAJ, PMI, etc.
AENOR (Asociacin Espaola de Normalizacin y Certificacin) adopta en abril de 2013

esta norma ISO 21500 traducida al castellano como norma UNE-ISO 21500 Directrices
para la direccin y gestin de proyectos.
Caractersticas de la ISO 21500
Cubre el vaco normativo existente en relacin con la Gestin de

Cubrir vaco Proyectos, Programas y Carteras, siendo la primera norma de una
normativo familia de estndares de Direccin de Proyectos que est
planificado que sean elaborados por la organizacin ISO.
Si se echa un rpido vistazo a esta norma puede observarse la

similitud de la misma con el PMBOK, el estndar de PMI.
Similitud con El PMBOK, est dirigido a directores de proyecto, a miembros del

el PMBOK equipo de proyecto y a directores funcionales. Sin embargo la ISO
21500 ampla su alcance incluyendo desde directores y gerentes
de la organizacin hasta a la Alta Direccin, en muchas ocasiones
los promotores de los proyectos.
La norma ISO 21500 describe conceptos y procesos de la

Direccin de Proyectos generalmente reconocidos como buenas
Describe prcticas.
buenas "Buenas prcticas" significa que los conocimientos y las prcticas
prcticas en descritos, son aplicables a la mayora de los proyectos la mayor
Direccin de parte del tiempo, que existe un amplio consenso sobre su valor y
Proyectos utilidad y un acuerdo general en que la correcta aplicacin de
estos conceptos y procesos puede aumentar las posibilidades de
xito de una amplia variedad de proyectos diferentes.
11

La norma ISO 21500 contribuye a la implantacin de la

Direccin de Proyectos en cualquier organizacin pblica o
privada que trabaje por proyectos con independencia de su
Amplia sector, tipo y tamao, favoreciendo en consecuencia el beneficio
aplicabilidad para la sociedad y har llegar a ms organizaciones el
conocimiento sobre la Direccin de Proyectos, beneficiando a
asociaciones profesionales, instituciones educativas, directores
de proyecto, organizaciones pblicas y privadas y clientes.
Con esta norma se ha conseguido un estndar que engloba las

Lenguaje diferentes metodologas y marcos de trabajo existentes en la
comn actualidad estableciendo un lenguaje universal en Direccin de
Proyectos, importante para la globalizacin de las compaas.
Gracias a estas caractersticas, los nuevos directores de proyecto, as como los directores
de proyectos experimentados pueden utilizar esta norma para lograr el xito del proyecto y
mejorar los resultados del negocio.
Todos estos aspectos de la norma, facilitarn el conocimiento de la Direccin de

Proyectos a la direccin de las empresas y a los promotores de los proyectos, necesario para el
entendimiento y apoyo a sus directores de proyecto.
Procesos de direccin de proyectos en ISO 21500
La norma ISO 21500 identifica los procesos que se recomienda (no se obliga)
utilizar en la direccin y gestin de un proyecto completo, en una fase o en ambos.
Los 39 procesos de direccin y gestin de proyectos definidos en esta norma se clasifican

en:
Cinco grupos de procesos: inicio, planificacin, implementacin, control y cierre.

Diez materias: integracin, partes interesadas, alcance, recursos, tiempo, costes,
riesgos, calidad, adquisiciones y comunicaciones.
DOCUMENTO PARA DESCARGAR (En la plataforma)
Cuadro de procesos para la direccin del proyecto en ISO 21500
12

Integracin
Es la materia que se ocupa de que el proyecto sea un todo cohesionado y que los
cambios se gestionen de forma integrada. Considera al proyecto en su globalidad, desde
el inicio hasta el final con el cierre y recopilacin de lecciones aprendidas.
Incluye los siguientes procesos de Direccin de Proyectos:
Desarrollar el acta de constitucin del proyecto

Desarrollar los planes de proyecto
Dirigir el trabajo del proyecto
Controlar el trabajo del proyecto
Controlar los cambios
Cerrar proyecto o fase
Recopilar las lecciones aprendidas
Partes interesadas
En esta materia se identifican a los interesados en el proyecto y se establecen

estrategias para gestionarlos eficazmente. Tambin incluye los procesos necesarios para
analizar sus expectativas y su impacto en el proyecto, y para desarrollar estrategias
apropiadas que faciliten la involucracin eficaz de los interesados en las decisiones y en la
ejecucin del proyecto.
Identificar las partes interesadas

Gestionar las partes interesadas
Alcance
Se trata en esta materia de delimitar cul es el trabajo del proyecto, qu est dentro
de los lmites del trabajo del proyecto y qu no. Un aspecto muy importante de la
disciplina de Direccin de Proyectos que se desarrolla en esta materia es la EDT (Estructura de
Desagregacin del Trabajo).
Definir el alcance
Crear la Estructura de Desglose de Trabajo (EDT)
Definir las actividades
Controlar el alcance
13

Recursos
Un proyecto se lleva a cabo mediante recursos, tanto humanos, como materiales, de

transportes, infraestructuras, etc. En esta materia se estiman los recursos necesarios, se
gestionan y se controlan.
Establecer el equipo de proyecto

Estimar los recursos
Definir la organizacin del proyecto
Desarrollar el equipo del proyecto
Controlar los recursos
Gestionar el equipo del proyecto
Tiempo
Una vez que el alcance y los recursos han sido establecidos se puede estimar la duracin
de las actividades y secuenciarlas obteniendo as el cronograma del proyecto.
Cronograma de un proyecto en forma de Diagrama de Gantt
Secuenciar las actividades

Estimar la duracin de las actividades
Desarrollar el cronograma
Controlar el cronograma
Costes
En esta materia se estiman los costes del proyecto y por agregacin el presupuesto
de costes. Debe controlarse el coste real durante la ejecucin del proyecto para que no se
superen estos costes estimados y por lo tanto haya beneficios en el cierre del proyecto.
14

Estimar los costes

Desarrollar el presupuesto
Controlar los costes
Riesgos
En todo proyecto podemos encontrar incertidumbre de tipo negativa que puede

amenazar a los objetivos del proyecto o positiva que puede representar una oportunidad para
el proyecto. Los riesgos pueden llegar desde el entorno del proyecto o de la organizacin.
Identificar los riesgos

Evaluar los riesgos
Tratar los riesgos
Controlar los riesgos
Calidad
En esta materia se establecern las normas, requisitos, procedimiento, mtricas

polticas, etc. de calidad que debe cumplir el proyecto y los entregables del proyecto para
satisfacer las necesidades por las que el proyecto se emprendi.
Planificar la calidad
Realizar el aseguramiento de la calidad
Realizar el control de la calidad
15

Adquisiciones
La mayora de los proyectos incluyen entre sus actividades, contratos, subcontrataciones

y compras. En esta materia se planifica qu comprar y se selecciona a los proveedores.
Se debe tener en cuenta que las adquisiciones a realizar satisfagan las necesidades del
proyecto y cumplan con las polticas de la organizacin en materia de adquisiciones.
Planificar las adquisiciones

Seleccionar los proveedores
Administrar los contratos
Comunicaciones
En Direccin de Proyectos es muy importante planificar las comunicaciones entre los

miembros del equipo de proyecto, quin comunica, qu, cundo, cmo y a quin.
Planificar las comunicaciones

Distribuir la informacin
Gestionar las comunicaciones
MEDIO
EMISOR RECEPTOR
RETROINFORMACIN
Proceso de comunicacin
16

Metodologas giles
Las metodologas giles son mtodos aplicados generalmente al desarrollo de

software sustentados en la simplicidad y adaptabilidad a los cambios.
Los mtodos tradicionales, basados en modelos predictivos muy bien documentados,
pueden resultar poco beneficiosos para planificar y gestionar proyectos altamente
complejos y con una gran incertidumbre.
Por eso surgen estos mtodos giles, basados en modelos adaptativos.
Valores de las metodologas giles recogidos en el Manifiesto gil
Individuos e Se dar ms importancia a los individuos y sus interacciones

interacciones en vez de a los procesos y herramientas.
Software Primar conseguir software funcional solamente con la

funcionando documentacin estrictamente necesaria.
En vez de negociar un contrato y olvidarse del cliente, se

Colaboracin
potenciar la colaboracin entre cliente y equipo de
con el cliente
desarrollo.
Respuesta al La capacidad de responder ante los cambios, que seguro que

cambio van a tener lugar, tendr ms valor que seguir un plan prefijado.
Existen multitud de mtodos giles:
Scrum
Extreme Programming
Kanban
Agile Unified Process
Crystal Clear
Lean Software
Cada uno tiene sus particularidades, pero todos comparten los mismos principios.
ENLACE A PGINA WEB
A continuacin puedes ver la pgina Web del Manifiesto por el

Desarrollo gil, donde puedes encontrar los principios en los que se
basan estos mtodos.
17

SCRUM
La metodologa Scrum tiene su origen en las prcticas de produccin introducidas por

Hirotaka Takeuchi e Ikujijo Nonaka en Japn durante la dcada de los ochenta del siglo
pasado, pero fue Jeff Sutherland, en los aos noventa, quin adapt este modelo al mundo del
desarrollo de software.
Scrum es una metodologa gil basada en el desarrollo iterativo e incremental: el

proyecto se desarrolla en sucesivas iteraciones, denominadas sprints.
Sprint
Cada una de las sucesivas iteraciones, de entre 2 y 6 semanas de duracin, en las que se
descompone un proyecto y que siempre tiene como resultado un entregable completamente
funcional.
La descripcin completa del entregable final no tiene porqu realizarse al inicio del
proyecto, ya que ir cambiando y evolucionando conforme el propio proyecto avance. Esto
contrasta con la gestin predictiva de los modelos tradicionales, donde se planifica por
adelantado.
Adems, en la gestin predictiva es labor del gestor resolver los imprevistos y las
desviaciones respecto a lo planificado, mientras que en Scrum se tiende a dotar a los equipos
de trabajo de gran autonoma y poder de decisin.
Para conocer el funcionamiento de Scrum, es necesario definir sus elementos

caractersticos, los roles implicados, las reuniones que tienen lugar a lo largo del proyecto y las
herramientas utilizadas.
18

Elementos
Aunque Scrum comparte la filosofa y los mecanismos de muchas otras metodologas

giles, utiliza algunos elementos propios diferenciados o al menos los usa bajo su propia
terminologa.
Elementos
Es el inventario de funcionalidades, tecnologas y mejoras que

el cliente requiere que sean incluidas al producto de manera
global a lo largo de las sucesivas iteraciones o sprints.
Aunque se elabora al principio del proyecto, antes de realizar el
primer sprint, no es fijo, sino que va evolucionando y
Product adaptndose segn transcurre el proyecto.
Backlog
Usualmente se documenta como un listado donde cada trabajo
tiene una codificacin, descripcin, duracin estimada, orden
de prioridad e incluso criterios de validacin. Estos campos no
tienen por qu estar completados desde la primera versin del
documento, sino que se van completando conforme avanzan las
sucesivas iteraciones.
Es el listado de tareas a realizar durante una iteracin o sprint

para construir un incremento cumpliendo con las funcionalidades
seleccionadas del product backlog.
Cada tarea lleva asignada una persona que la realizar y una
duracin estimada, que debe oscilar entre las 4 y 16 horas.
Sprint Backlog Este listado se puede realizar en una pizarra, mediante una hoja
de clculo o a travs de herramientas informticas especialmente
diseadas, pero en todo caso debe ser fcilmente accesible por
todos los miembros del equipo.
Se debe dejar suficiente espacio para que en las reuniones
diarias se pueda documentar el tiempo restante de cada tarea.
Es el resultado de cada sprint y se trata de un entregable

completamente funcional. Debe incluir tambin la
documentacin asociada a ese entregable en caso de ser
necesaria.
Incremento
Como excepcin, tras el primer sprint es posible no llegar a
un entregable funcional ya que suele estar centrado en definir
la arquitectura del entregable final, que permanecer ms o
menos constante a lo largo de todo el proyecto.
19

Roles
En la metodologa Scrum cada miembro de la organizacin tiene fijado su rol dentro del
proyecto, que permanecer invariante hasta que este termine.
Roles
Es la persona que conoce el negocio y las expectativas del

cliente y busca para ste que el producto final aporte el mayor
Propietario valor posible.
del producto Si el desarrollo es para un cliente externo, el propietario del
producto suele ser el propio cliente, encarnado normalmente en
la figura del responsable de la adquisicin.
Son los encargados de desarrollar el producto a lo largo de las

diferentes iteraciones.
El equipo de Se suelen formar equipos multidisciplinares que conozcan el
desarrollo funcionamiento de la metodologa Scrum y que en cierta medida
sean autosuficientes a la hora de organizarse y tomar
decisiones.
Es una persona con conocimiento sobre la metodologa

Scrum que debe garantizar que sta se est aplicando de manera
adecuada y facilitar que el equipo desarrolle su labor.
Scrum Master Dependiendo del tipo de organizacin, esta labor puede recaer
en diferentes personas dentro del organigrama de la empresa,
como por ejemplo el responsable de calidad, el responsable de
procesos, etc.
Cada persona involucrada en el proyecto, sea cual sea su rol, debe estar comprometida
con una serie de valores que sustentan la metodologa Scrum:
Respeto entre los miembros del equipo.

Responsabilidad.
Auto organizacin.
20

Reuniones
El proyecto se desarrollar mediante una sucesin de sprints. Cada uno de estos

sprints se articular mediante unas reuniones prefijadas segn la propia metodologa Scrum.
Planificacin del sprint

Tambin llamada sprint planning meeting, es una reunin previa al inicio de cada
sprint, en la cual se decide qu funcionalidades se incorporarn al entregable durante la
iteracin a partir de las necesidades del cliente recogidas en el product backlog.
Aunque tanto el product backlog como el sprint backlog se documentan oportunamente,
es recomendable que en esta reunin se haga uso de una pizarra y fichas removibles
para visualizar la informacin ms relevante durante las discusiones.
A esta actividad, que no debe durar ms de un da, asiste el propietario del producto,
el Scrum Master y el equipo de desarrollo.
Partes de la Planificacin del sprint
El propietario del producto expone las funcionalidades

requeridas de mayor prioridad. El equipo de desarrollo
interactuar entonces con el propietario del producto,
Primera proponiendo sugerencias, realizando preguntas, mostrando
Parte alternativas, etc.
Fruto de esta interaccin deben quedar claras cules son las
funcionalidades que se deben conseguir al finalizar el
sprint, que conformarn el sprint backlog.
El equipo de desarrollo desagrega esas funcionalidades en

tareas relativamente simples y estima el tiempo que precisar
Segunda su realizacin.
Parte
Estas tareas son asumidas por los distintos miembros del
equipo segn sus capacidades, experiencias preferencias, etc.
Seguimiento del Sprint

Tambin llamada daily Scrum meeting, es una reunin breve (menos de 15 minutos)
que tiene lugar con frecuencia diaria durante toda la realizacin del sprint. Asiste todo
el equipo de desarrollo y de manera opcional otros miembros de la organizacin.
Cada miembro del equipo expone de manera sencilla:
o En qu ha trabajado desde la anterior reunin.
o En que tiene previsto trabajar hasta la prxima reunin.
o Si le ha surgido algn problema o tiene algn impedimento para continuar
con sus tareas.
Se suele realizar de pie y es recomendable disponer del sprint backlog y del grfico
burn down en un formato manipulable.
21

Revisin del sprint:

Tambin llamada sprint review, es una reunin de menos de 4 horas de duracin
realizada al finalizar el sprint en la cual el equipo de desarrollo muestra al propietario
del producto el incremento fruto de ese sprint.
Suele ser una reunin informal, centrada en el producto terminado donde se busca
establecer una interaccin entre los miembros participantes que sirva de cara a la
preparacin del nuevo sprint.
Retrospectiva del sprint
Tambin llamada sprint retrospective, es una reunin de menos de 4 horas que

tambin se realiza al finalizar el sprint. En ella estn presentes los miembros del
equipo de desarrollo, que analizan su forma de trabajar durante el sprint, lo que han
aprendido, las dificultades que han atravesado y las que se les plantean por delante, etc.
El objetivo de esta reunin es mejorar la productividad de cara a futuros sprints
revisando la correcta aplicacin de la metodologa Scrum.
Herramientas
Durante el desarrollo del proyecto se har uso de algunas grficas y herramientas

propias de la metodologa Scrum que ayudarn a realizar la planificacin y el seguimiento del
trabajo realizado y por realizar.
Herramientas
Es una herramienta de planificacin y seguimiento enfocada de

cara al propietario del producto.
EsfuerzoProductBacklog
Velocidad
Optimista
Velocidad
Prevista
Grfico
Burn-Up Velocidad
Tiempo
Pesismista
1E 1F 1M 1A 1M 1J
Consiste en un diagrama de ejes cartesianos en el que se

representa el esfuerzo estimado para construir el product
backlog frente al tiempo desde el inicio al final del proyecto.
En l se puede ver la velocidad estimada, las fechas previstas
y el avance real.
22

Es una herramienta con la que el equipo puede seguir el trabajo

de un sprint.
Esfuerzorestante
Planificado
Real
Grfico
Burn- Down
Tiempo(das)
Consiste en un diagrama de ejes cartesianos en el que se

representa el esfuerzo restante previsto para acabar las tareas
asumidas en el sprint backlog frente al tiempo desde el inicio
del sprint hasta su fin.
Se actualiza en las reuniones de seguimiento del sprint y
permite visualizar cuanto trabajo resta por hacer y si se va con
adelanto (por debajo de la diagonal) o con atraso (por encima de
la lnea diagonal) respecto a lo previsto.
La cantidad de esfuerzo para construir una funcionalidad del

product backlog puede medirse en distintas unidades:
o Tiempo real.
o Tiempo terico: tiempo efectivo ideal, sin
interrupciones, trabajando en buenas condiciones, etc.
o Puntos de funcin: medida relativa establecida por el
equipo.
Se pueden establecer distintas medidas de eficiencia del
Mtricas
trabajo:
o Velocidad absoluta: Cantidad de producto construido
en un sprint. Se podr medir en puntos de funcin por
sprint, en tiempo terico dedicado por cada sprint o en
tiempo real dedicado porcada sprint.
o Velocidad relativa: cantidad de producto construido
por cada unidad de tiempo real. Se podr medir en
puntos de funcin por cada unidad de tiempo real o en
tiempo terico por cada unidad de tiempo real.
23

Extreme Programming
Extreme Programming (XP) o Programacin Extrema es una metodologa de desarrollo

de software que nace a finales de los aos 90 de la mano de Kent Beck, que en 1999 public
Extreme Programming Explained: Embrace Change.
Con Extreme Programming se busca responder a los cambios en los requerimientos

de los clientes incluso en las ltimas fases de los proyectos, que es cuando los cambios
causan un mayor impacto en los objetivos de los proyectos dirigidos con mtodos
tradicionales.
Ahondando en esta filosofa, XP no intenta resistirse a los cambios, sino que los favorece
y ve en ellos una oportunidad de mejora.
Como Scrum y la mayora de las dems metodologas giles, est basado en

iteraciones sucesivas que dan lugar a entregables funcionales.
Principios
La Programacin Extrema se sustenta en una serie de principios que deben aplicarse

a lo largo de cualquier proyecto:
Bsqueda de soluciones sencillas.

Comunicacin fluida entre los participantes en el proyecto.
Continua retroalimentacin entre las partes implicadas.
Valenta a la hora de abordar problemas y aplicar cambios.
Participacin del cliente en las iteraciones.
Al tratarse de un mtodo dirigido al desarrollo de software, se basa tambin en una serie

de principios tcnicos.
24

Principios tcnicos
Se ha de buscar la solucin ms sencilla posible a cada

Simplicidad
problema.
A la hora de programar, cuando surgen dificultades, se suelen

Soluciones de
usar pequeos programas de prueba (llamados spike) para
prueba
ensayar posibles soluciones.
Se deben reescribir partes del cdigo ya terminado en busca de

aumentar su simplicidad sin que cambie su funcin siempre que
Recodificacin sea posible.
Esta recodificacin puede suponer una prdida de tiempo
inicialmente, pero facilitar la insercin de futuros cambios.
Segn la metodologa XP, para aumentar la eficiencia a la hora

de programar se debe realizar esta labor en parejas, de modo que
el cdigo as es revisado de manera instantnea.
Aunque pueda suponer un sobrecosto inicial, la cantidad de
defectos se minimiza, los problemas se resuelven con mayor
Programacin
rapidez y los profesionales aprenden y mejoran al trabajar
en pareja
juntos.
Otra ventaja de seguir este principio es que el nmero de
personas que conocen cada parte del proyecto aumenta, lo
que puede resultar muy beneficioso para afrontar eventualidades
como posibles bajas.
Pruebas de aceptacin: Creadas segn las historias de usuario de

cada iteracin, es el cliente quien ayuda a definirlas y verifica
que se cumplen.
Pruebas unitarias: Son escritas antes de desarrollar el propio
mdulo por el equipo, lo que condiciona el propio desarrollo
Programacin del proyecto, y se ejecutan con gran asiduidad.
dirigida a
pruebas Las pruebas pensadas para una iteracin tienen que ser
pasadas por el entregable al finalizar dicha iteracin pero
tambin en las iteraciones sucesivas, de modo que se van
acumulando.
La cantidad de pruebas suele llegar a ser tan elevada que se
tiene que nombrar a un encargado de pruebas o tester.
Aunque cada desarrollador se encargue de una tarea, cualquier

Propiedad del
miembro del equipo puede cambiar el cdigo escrito por otro
cdigo
sin tener que pedir permiso explcitamente, en caso de ser
colectiva
necesario.
Las diferentes versiones de cada parte del cdigo son publicadas

Entregas
con gran frecuencia, para que todos los dems miembros del
frecuentes
equipo trabajen siempre sobre la ltima versin.
25

Elementos
La metodologa Extreme Programming comparte gran parte de mecanismos con otros

mtodos giles, pero utiliza algunos de manera diferenciada o al menos bajo su propia
terminologa.
Elementos
Simple descripcin de un requerimiento realizada por el

cliente en su propio lenguaje.
Inicialmente ha de ser concreta, en una o pocas frases.
Posteriormente equipo y cliente interactuarn para clarificar la
tarea a realizar con mayor exactitud.
Historia de
El desarrollo de cada historia de usuario no debe durar ms de
usuario
tres semanas ni menos de una.
o Si la estimacin es menor de una semana, se
fusionar con otra historia de usuario.
o Si la estimacin es mayor de tres semanas, se dividir
en dos o ms historias de usuario independientes.
Es el plan de entregas, un documento donde se planifica

cundo se obtendr cada entregable, lo que equivale a
planificar las sucesivas iteraciones.
Se realiza entre el cliente, el equipo y la gerencia en una
Release
reunin denominada Planning Game en la cual se ordenan las
Plan
historias de usuario segn su prioridad y se agrupan para
conformar cada iteracin.
Tras ejecutarse las primeras iteraciones es posible que este
Release Plan deba ser actualizado en una nueva reunin.
Al inicio de cada iteracin se toman las historias de usuario

planificadas en el Release Plan y se desagregan en tareas
Plan de especficas.
iteracin
Se definen tambin las pruebas que el entregable tendr que
pasar al terminar la iteracin.
Semejantes a las del Scrum, son de corta duracin y

Reuniones frecuencia diaria.
diarias El equipo comparte problemas, consejos y soluciones, pero no
todos los asistentes estn obligados a hablar.
26

Ciclo de vida
Puesto que en muchas ocasiones el cliente no conoce bien sus necesidades, o estas
van cambiando, Extreme Programming propone ciclos cortos o iteraciones que finalizan en
cada caso con un entregable funcional. Generalmente un proyecto se puede componer de
entre 10 a 15 iteraciones.
Aunque el proyecto se desarrolle en sucesivas iteraciones, se suelen establecer tambin

distintas fases.
Fases del proyecto
El cliente explica sus necesidades y se crean las historias

de usuario, sencillos documentos donde se enuncia cada
requerimiento.
Exploracin El equipo, basndose en esos requisitos, estima el tiempo que
supondr su desarrollo. Estas estimaciones son primarias, ya que
se dispone de pocos datos y los requisitos pueden ir cambiando.
Esta fase suele durar menos de dos semanas.
En esta fase se decide la prioridad de las historias de usuario

de comn acuerdo entre cliente, desarrolladores y gerentes.
Planificacin
En base a esa priorizacin, se planifican las entregas
obtenindose un Plan de entregas o Release Plan
Se realizan las iteraciones en las que se analizan los

requerimientos, se realiza el desarrollo necesario y los test
oportunos.
Iteraciones Al final de cada iteracin se produce un entregable funcional.
Es imprescindible que el cliente participe en esta fase.
Cada iteracin debe durar menos de 3 semanas.
Aunque tras cada iteracin se produce un entregable funcional, es

usual que el cliente no ponga ste en funcionamiento hasta
Produccin que no se complete ntegramente en esta fase.
No se hace ningn desarrollo funcional, solo se ajusta lo
anteriormente obtenido.
27

Kanban
Aunque el trmino Kanban originalmente hace referencia a una tcnica de

optimizacin de la produccin creada por la firma japonesa Toyota, dentro de las
metodologas giles, Kanban es el conjunto de prcticas utilizadas en el desarrollo de
software que se suelen utilizar en compaa de otros modelos giles.
En esta metodologa no se prescriben roles, ya que promueve que el hecho de tener un

papel preestablecido dentro del proyecto limitar a los individuos a la hora de afrontar tareas
de diferente naturaleza. La ausencia de roles disminuye de esta forma la resistencia al
cambio.
Elementos
Kanban se suele aplicar como complemento a otras metodologas giles como Scrum,
de hecho, la aplicacin conjunta de Kanban y Scrum se denomina Scrumban.
Elementos de Kanban
El trabajo se divide en partes y cada parte es incluida en una

tarjeta en la que se describe la tarea y se estima su duracin.
Las tarjetas se sitan en un tablero con tantas columnas como
posibles estados por los que pueda pasar la tarea (pendiente,
Visualizar el anlisis, desarrollo, prueba, terminado, etc.)
trabajo
De este modo se podr visualizar fcilmente el estado del
proyecto en general y de cada tarea en particular.
Las tarjetas pueden ser desde simples post-it pegados en una
pizarra o pared hasta sofisticadas aplicaciones informticas.
Lead time: Es el tiempo que transcurre desde que se solicita

una tarea hasta que esta es terminada. Por tanto ser el
tiempo que los clientes perciben que tarda en realizarse la
tarea.
Mtricas
Cylcle time: Es el tiempo que transcurre desde que una tarea
empieza hasta que se termina. Siempre ser menor que el
Lead time, ya una tarea no tiene porqu empezar
inmediatamente despus de ser requerida.
28

El trabajo en curso o Work in Progress (WIP) es el

nmero de tareas sobre las que el equipo trabaja
simultneamente.
Se pretende fijar de antemano un lmite para el WIP. Este
lmite puede desagregarse por cada fase, fijndose un mximo de
tareas que pueden estar en anlisis, en desarrollo, en revisin,
etc.
Una vez llegado al lmite, el equipo no puede iniciar una nueva
tarea hasta que no termine una de las empezadas.
Con esta limitacin se pretende que el equipo se enfoque en
terminar las tareas que empieza y fomentar el trabajo en
Limitar equipo.
trabajo en
curso Si el lmite es demasiado bajo:
o Cada tarea se completar rpidamente y se fomentar el
trabajo en equipo.
o Miembros del equipo estarn ociosos y si se presentan
dificultades podra bloquearse el progreso del trabajo.
Si el lmite es demasiado alto:
o Habr pocos miembros del equipo ociosos y ante un
bloqueo se podr cambiar de tarea.
o No se fomentar el trabajo en equipo y se pude
tender a empezar muchas tareas y no acabar
ninguna.
ENLACE A PGINA WEB
A continuacin puedes ver la pgina Web de Kanbanize, una

herramienta para gestionar el tablero Kanban de forma online
29

Competencia
A continuacin podemos encontrar la definicin en la NCB de la competencia Cambios:
Cambios
En un proyecto a menudo es necesario realizar cambios debido a circunstancias no

previstas. () Los cambios se deben comparar con los puntos originales del proyecto
segn se definieron en la evaluacin previa del proyecto. () Un proceso activo de direccin
de cambios que anticipe la necesidad de cambios es preferible a un proceso que slo
reaccione cuando la necesidad de un cambio es obvia. NCB
Gestionar un cambio debe incluir los siguientes aspectos:
Realizar mediante proceso formal cualquier cambio en el alcance o en el resto de las

especificaciones de alguno de los entregables del proyecto.
Seguir un procedimiento de cambio que incluya: identificar, describir, determinar su
impacto sobre costes, entregables, etc., clasificar, evaluar, aprobar o rechazar,
materializar y verificar los cambios segn lo acordado.
Abarca todo aquello que resulte del cambio requerido.
Tener en cuenta los efectos del cambio, directos e indirectos sobre el proyecto y
ajustar en concordancia el resto de documentacin del proyecto.
30

INTRODUCIR PRINCE2 E ISO 21500 Y CONOCER METODOLOGAS

GILES COMO SCRUM
Business Project Management Solutions and Technologies S.L.
Reservados todos los derechos. El contenido de esta obra est protegido por la Ley. Queda prohibida
toda reproduccin total o parcial de la obra por cualquier medio o procedimiento sin autorizacin previa.

Introducir PRINCE2 Agiles

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Introducir PRINCE2 Agiles

Cargado por

Copyright:

Formatos disponibles

Introducir PRINCE2 e ISO

21500 y conocer metodologas

Introducir PRINCE2 e ISO 21500 y conocer metodologas giles como SCRUM

INTRODUCIR PRINCE 2 E ISO 21500 Y CONOCER METODOLOGAS

Adems de la metodologa de PMI plasmada en el PMBOK y la de IPMA basada en las

En esta Unidad Didctica se desarrollan los siguientes contenidos:

En esta Unidad Didctica se desarrolla la siguiente competencia de Direccin de

Competencia tcnica: Cambios

Introducir PRINCE2 e ISO 21500 y conocer metodologas giles como SCRUM

Es un mtodo prescriptivo basado en procesos que proporcionan una estrategia

Algunos factores claves para el xito del proyecto son:

Puede utilizarse para gestionar todo tipo y tamao de proyectos

A continuacin puedes ver un video que expone las principales

Introducir PRINCE2 e ISO 21500 y conocer metodologas giles como SCRUM

En PRINCE2 se identifican seis variables interrelacionadas que intervienen en

La estructura de PRINCE2 se organiza en cuatro partes:

Los principios son buenas prcticas que es necesario que sean

Las temticas son aspectos de la Direccin de Proyectos que

Introducir PRINCE2 e ISO 21500 y conocer metodologas giles como SCRUM

Los procesos son conjuntos de actividades que deben llevar a

PRINCE2 debe ser adaptado para que refleje necesidades

Introducir PRINCE2 e ISO 21500 y conocer metodologas giles como SCRUM

1 Justificacin Asegurar un motivo de negocio justificable para iniciar el

El equipo de proyecto aprende continuamente de la experiencia

Orientar el proyecto a la definicin y entrega de productos y sus

Adaptar el mtodo PRINCE 2 al tipo, tamao, complejidad,

Son aspectos de la Direccin de Proyectos que el director de proyecto debe tener

Introducir PRINCE2 e ISO 21500 y conocer metodologas giles como SCRUM

Planificacin de calidad: Comprender, definir y documentar las

Niveles de planificacin en PRINCE2

Introducir PRINCE2 e ISO 21500 y conocer metodologas giles como SCRUM

Cmo? Cunto? Cundo?

Introducir PRINCE2 e ISO 21500 y conocer metodologas giles como SCRUM

6 Cambio Los cambios pueden llegar desde el equipo de proyecto o desde el

Dnde estamos ahora? A dnde vamos? Deberamos

7 Progreso En esta temtica se siguen los planes reales y se comparan los

Fase/s de entrega Fase final de

Gestin de la entrega Gestin de la entrega

Procesos de PRINCE2 en el ciclo de vida del proyecto

Introducir PRINCE2 e ISO 21500 y conocer metodologas giles como SCRUM

Reunir los datos necesarios para comenzar el proyecto.

Autorizar el proyecto y su inicio.

Establecer las bases del proyecto mediante la creacin de la

Describir y asignar el trabajo a realizar.

Establecer los requisitos para ejecutar, aceptar y entregar los

Proporcionar de forma controlada la forma de completar la fase

Revisar que se han alcanzado los objetivos del proyecto.

Introducir PRINCE2 e ISO 21500 y conocer metodologas giles como SCRUM

Para ayudar en la implantacin de la Direccin de Proyectos en las organizaciones,

Normas: BS 6079-1 Guide to Project Management, DIN 69901-2 Project Management:

AENOR (Asociacin Espaola de Normalizacin y Certificacin) adopta en abril de 2013

Caractersticas de la ISO 21500

Cubre el vaco normativo existente en relacin con la Gestin de

Si se echa un rpido vistazo a esta norma puede observarse la

Similitud con El PMBOK, est dirigido a directores de proyecto, a miembros del

La norma ISO 21500 describe conceptos y procesos de la

Introducir PRINCE2 e ISO 21500 y conocer metodologas giles como SCRUM

La norma ISO 21500 contribuye a la implantacin de la

Con esta norma se ha conseguido un estndar que engloba las

Todos estos aspectos de la norma, facilitarn el conocimiento de la Direccin de

Procesos de direccin de proyectos en ISO 21500

Los 39 procesos de direccin y gestin de proyectos definidos en esta norma se clasifican

Cinco grupos de procesos: inicio, planificacin, implementacin, control y cierre.