traducción del inglés de un trabajo de comparación de métodos de gestión del desarrollo de sftware

1. Comparando PMBOK y Agile Project
Los procesos de desarrollo de software de gestión
RESUMEN
El objetivode este artículoescompararun conjunto genéricode procesosde gestiónde proyectos
definidos en el Cuerpo de Conocimientos en Gestión Proyectos (Project Management Body of
Knowledge - PMBOK) con los procesos de Gestión de Proyectos Ágiles (Agile Project
Management.)
PMBOK fué desarrolladoporel Institutode Gestión de Proyectos y se estructura en torno a cinco
grupos de procesos: (iniciación, planificación, ejecución, control y cierre) y nueve áreas del
conocimiento(gestiónde laintegración, gestióndel alcance,gestióndel tiempo,gestiónde costes,
gestión de la calidad, gestión de los recursos humanos, gestión de la comunicación, gestión de
riesgos,gestión de compras). Por otra parte, la gestión de proyectos de software ágil se basa en
lossiguientesprincipios:aceptarel cambio,se centranenel valordel cliente, entregar parte de la
funcionalidadde formaincremental, colaborarreflexionaryaprendercontinuamente.El propósito
de esta comparación es identificar las lagunas, las diferencias, discrepancias, etc. El resultado es
que, lasmetodologíasde gestiónde proyectoságiles no puedenconsiderarse completas,desde el
punto de vista de la gestión de proyectos tradicional, ya que un número de procesos o bien no
existen o no se ha descrito explícitamente
I. INTRODUCCIÓN
Las metodologías de desarrollo de software tradicionales crecieron a raíz de la necesidad de
controlargrandes proyectos de desarrollo, y de las dificultades de estimación y gestión de estos
esfuerzos paraentregar resultados fiables. Estas dificultades que provienen de la naturaleza del
software y que fueron identificados a partir de los primeros años de desarrollo por desgracia la
mayoría de ellos todavía persiste. La mayor parte del escepticismo expresado en el legendario
libro de Frederic Brooks, "The Mythical Man-Month" Hace treinta años sigue siendo válida [1].
Además,losprofesionalesde tecnologíasde lainformaciónde hoyendía estánbajo una tremenda
presiónparaentregarproductos de TI y servicios de calidad,conel fin de responder a los siempre
dinámicos y rápidos cambios del mercado.
Comoresultado,lalistade losgrandesproyectosde software que han fracasado sigue creciendo.
Robert Charette [2] compiló una lista de los fiascos más notables en la industria de TI. Además,
afirma que "la mayor parte expertos en TI están de acuerdo en que estos fallos se producen con
mucha más frecuencia de lo que deberían y que las fallas son de carácter universalmente.
La literatura sugiere que la organización del proyecto, las partes interesadas " gestión de las
expectativas, la definición del alcance etc., son siempre factores importantes que conducen al
éxito del proyecto, cuando se administran adecuadamente [3, 4, 5].
Las metodologías ágiles intentan superar estos obstáculos cambiando el enfoque utilizado para
desarrollarsoftware ygestionar proyectos.El desarrolloágil de software intentaponerel software
que está siendo desarrollado por primera vez. Además, los métodos ágiles reconocen que las

2. necesidades de los usuarios pueden cambiar, que tenemos que responder rápidamente a las
necesidadesde losusuarios,que hayunanecesidadde producirfrecuente yregularmente,murvas
versiones del software, etc.
El Manifiestode desarrollode software ágil fue publicado en febrero de 2001 por un grupo de 17
expertosen procesosde software,que asistieron a una reunión en la cumbre para promover una
mejormanerade desarrollarel software yluegoformóel Agile Alianza.El Manifiestode desarrollo
ágil de software puede encontrarse en el sitio web de Agile Alliance
(Http://www.agilemanifesto.org).
Desde entonces,unaserie de métodosde desarrollode software se hasuscritoa este enfoque. La
listavaría dependiendode diferentespuntosde vista e interpretaciones, pero, en general, la lista
incluye:Extreme Programación (XP), Scrum, el desarrollo de funciones-Driven (FDD), adaptativa
desarrollo de software (ASD), Metodología Crystal Clear, etc. La mayoría de los métodos de
desarrolloágil se crean dentro de corporaciones por los expertos en procesos de software como
un intentode mejorarlosprocesosexistentes.Por ejemplo, XP fue creado por Kent Beck durante
su trabajo en el proyecto Sistema de Compensación Integral de Chrysler. Kent Beck refinó el
método de desarrollo utilizado y el resultado fue publicado en su libro "Extreme Programming
Explained" [6].
Del mismo modo, FDD se introdujo inicialmente por Jeff De Luca, con el fin de satisfacer las
necesidades específicas durante los 15 meses de desarrollo de software 50 personas fueron
involucradas en el proyecto de un gran banco de Singapur en 1997. FDD por las ideas de Peter
Coad en el modelado de objetos. La descripción de FDD se introdujo por primera vez en el libro
"Java Modeling in Color con UML "de Peter Coad, Eric Lefebvre y Jeff De Luca en 1999 [7]. Una
descripción más genérica de FDD desacoplada de Java se puede encontrar en el libro "Una guía
práctica para Feature- Driven Development "[8].
En el otro extremo las metodologías gestión de proyectos más tradicionales se basan
fundamentalmente enlosprocesos,el desarrollo lineal ciclos y la cascada como los ciclos de vida
de desarrollode software. Juntoconlaprevisibilidad,que provienede un enfoque determinista y
reduccionistaque dependíande desglose de tareas,y estaba basada en la estabilidad - requisitos
estables,análisisy diseño estable. Esta rigidez se caracterizó también por una tendencia hacia el
servil proceso de "cumplimiento" como medio de control del proyecto [9].
La guía de los fundamentos de gestión de proyectos (PMBOK) desarrollado por el Instituto de
Gestión de Proyectos es la mejor representante de este enfoque [10].
PMBOK define formalmente untotal de 44 procesosde proyectos que describen las actividades a
lo largo del ciclo de vida de un proyecto. Estos procesos del proyecto son 44 organizados en dos
ejes: en cinco grupos de procesos y en nueve áreas de conocimiento que se describirán
brevementeen la siguiente sección. Dentro de PMBOK cada proceso se describe en términos de
entradas(documentos,planos,diseño,otrosdatos,etc.),lassalidas (documentos,productos) y las
herramientasytécnicas (mecanismos que se aplicanalosinsumosparala producciónde salidas) y
sin ser demasiado específico, proporciona una guía para alguien que desea para aplicar los
procesos [11].

3. Enfoques similares, orientados a los procesos, se han introducido por otras entidades o
asociaciones internacionales. Entre ellos, pueden citarse: Gestión de Proyectos Internacionales
Asociación, Competencia de línea de base (ICB), que describe el competencias necesarias
(técnicas, del comportamiento, contextuales) para gestión y dirección de proyectos [12] y
conocimiento como se define por la Asociación para la Gestión de Proyectos en el Reino Unido
(APM) (http://www.apm.org.uk), que describe de nuevo 40 competencias necesarias para la
gestión de proyectos.
Estos enfoques de gestión de proyectos de estudio en una faceta de múltiples formas y por lo
tanto alguien puede discutir acerca de la definición de un proceso o si se necesita una
competencia pero no sobre el método completo. Además, la mayoría de ellos son ampliamente
conocidos y aceptado por los profesionales y las organizaciones.
Sinembargo,incluso aunque los métodos ágiles son atractivos y su uso está logrando resultados
prometedoreshaycríticas que cuestionan si son metodologías completasde gestión de proyectos
o deben ser ampliadas, con otros elementos de gestión. Estudios similares y discusiones al
respecto pueden encontrarse en [13, 14]
En las siguientessecciones, presentaremos brevementelasprincipalescaracterísticas del PMBOK y
de algunosde losmétodoságilesmásconocidos.Luego loscompararemosteniendocomobase los
procesos definidos, por área de conocimiento, en el PMBOK.
II. CUERPO DE CONOCIMIENTOS EN GESTIÓN PROYECTOS
Comose mencionóantes, lagestiónyadministración de proyectos de (PMBOK) [10] se define en
términos de proceso grupos y áreas de conocimiento. En este estudio, nos centraremos en las
áreas de conocimiento,yaque estaszonas están ofreciendo una mayor precisión sobre lo que es
la gestión de proyectos y al mismo tiempo dan la visión de conjunto. Las áreas de conocimiento
son las siguientes:
1. Gestión de la Integración del Proyecto: describe la procesos y actividades que integran
diferentes aspectos de la gestión de proyectos. Se compone de los siguientes procesos:
a. Desarrollar el Acta (Charter) del proyecto,
b. Desarrollar la declaración preliminar del alcance del proyecto,
c. Desarrollar del Plan de Gestión del Proyecto,
d. Dirigir y Gestionar la Ejecución del Proyecto,
e. Supervisar y Controlar el Trabajo del Proyecto,
f. Control Integrado de Cambios, y
g. Cierre del proyecto.
2. Gestióndel Alcance del Proyecto. Se encapsula procesos que son responsables de controlar el
alcance del proyecto. Eso consiste en:
a. Planificación del Alcance,
b. Definición del alcance,
c. Crear la estructura del proyecto (PEP),
d. Verificación del Alcance y

4. e. Control del Alcance.
3. Gestión del tiempo del Proyecto, que describe la los procesos relativos a la terminación
oportuna del proyecto. Consiste en
a. Definición de las Actividades,
b. Secuencia de las Actividades,
c. Estimación de Recursos de las Actividades,
d. Estimación de la Duración de las Actividades,
e. El desarrollo del Cronograma, y
f. Calendario de control.
4. Gestiónde loscostos del Proyecto,que incluye procesos en relación con el coste. Los procesos
que son parte de esta área de conocimiento son:
a. La estimación de costos,
b. Presupuesto y
c. Control de Costes.
5. Gestiónde la Calidaddel Proyecto, se describenlosprocesos que existen para garantizar que el
proyecto va a satisfacer la objetivos para los cuales fue emprendido. Consiste en:
a. Planificación de la calidad,
b. Realizar Aseguramiento de Calidad, y
c. Realizar el Control de Calidad.
6. Gestión de los Recursos Humanos del Proyecto, incluye todo procesos necesarios para la
organización y gestión del equipo de proyecto. Consiste en:
a. Planeamiento de Recursos Humanos,
b. Adquirir el Equipo del Proyecto,
c. Desarrollar el Equipo del Proyecto, y
d. Gestionar el Equipo del Proyecto.
7. Gestiónde las Comunicacionesdel Proyecto, describe los procesos relativos a las modalidades
de comunicación de un proyecto, y se refieren a la oportuna y apropiada generación, difusión,
almacenamiento y disposición final de la información del proyecto. Consiste en los siguientes
procesos:
a. Planificación de las Comunicaciones,
b. Distribución de la Información,
c. Informes de rendimiento y
d. Gestionar a los Interesados
8. Gestión de Riesgos del Proyecto, se describen los procesos ocupa de la gestión de riesgos
relacionados con el proyecto. Eso consiste en:

5. a. Planificación de la gestión de riesgos,
b. Identificación de riesgo,
c. Análisis Cualitativo de Riesgos,
d. Análisis Cuantitativo de Riesgos,
e. Planificación de la respuesta a los riesgos, y
f. Supervisión y Control de Riesgos.
9. Gestiónde Comprasdel Proyecto,incluye todo procesos que tienen que ver con la adquisición
de productos y los servicios necesarios para completar un proyecto. Consiste en:
a. Planificar las Compras y Adquisiciones,
b. Plan de Contrataciónes,
c. Solicitar Respuestas de Vendedores,
d. Selección de Vendedores,
e. Administración de contratos, y
f. Cierre de contratos.
III. GESTIÓN DE PROYECTOS AGILES
El objetivo del Manifiesto de desarrollo de software ágil era "Descubrir mejores formas de
desarrollar software y haciéndolo ayudar a los demás que lo hacen”
((http://www.agilemanifesto.org). La principios que se basa son los siguientes:
 Interacciones entre individuos sobre procesos y herramientas.
 Trabajar sobre el software con documentación completa.
 Colaboración con el cliente a través de la negociación del contrato.
 Responder a cambios en el desarrollo del plan.
Obviamente,el manifiestonoesunprocesoorientado oenfocado.Comoel que fue presentadoen
la introducción,hay muchosmétodos de desarrollo de software que se pueden llamar "ágil". Sin
embargo, en este trabajo se han seleccionado sólo unos pocos de ellos como los más
representativos. Los métodos de desarrollo de software que se incluyeron son: Extreme
Programming (XP),Scrum y el desarrollo de funciones-Driven (FDD).
A. eXtreme Programming (XP)
Extreme Programming o XP, es un método ágil que surgido de un proyecto en Chrysler
Corporation en los finales 1990. Fue ideado por Ward Cunningham, Kent Beck, y Ron Jeffries. El
método está bien documentado en una serie de libros, artículos y sitios web
(Http://www.extremeprogramming.org/) [6, 15, 16, 17].
El método XP se basa en cuatro valores:
 Comunicación,que se basaen prácticas tales como la unidad de pruebas, la programación en
parejas, la estimación de tareas.
 La sencillez, buscando siempre la solución más simple.
 Evaluación, al tener conocimiento concreto acerca de la Estado actual del sistema
 El valor, para admitir fallas en el sistema y tomar acciones correctivas inmediatas

6. Además, XP se basa en una serie de prácticas. Algunos son:
 Planificación.El alcance de lapróximaversióndebe ser definido tan pronto como sea posible,
mediante la combinación de negocios las prioridades y las estimaciones técnicas.
 Las pequeñas emisiones. El sistema tiene que estar en funcionamiento por tener ciclos muy
cortos y cierres rápidos.
 La metáfora.Todoel desarrolloesimpulsadoporunasimple historiade cómofuncionatodoel
sistema.
 El diseño simple. Las soluciones simples son los preferidos. La complejidad se debe quitar
cuando sea posible.
 Pruebas. La prueba es una actividad continua.
 La programación en parejas. Todos los programadores están trabajando en pares.
 La propiedadcolectiva.Cualquierpersonapuede cambiar cualquier código en cualquier lugar
en el sistema en cualquier momento.
 La integración continua. El sistema es construido muchas veces al día, tan pronto como ha
terminado una tarea.
 En las instalacionesdel cliente.Unrepresentante del cliente ode laorganizacióndebería estar
disponible a tiempo completo o para responder a las preguntas del equipo del proyecto.
B. SCRUM
Scrum esun enfoque parael desarrollode nuevosproductosfue presentado primeroporTakeuchi
y Nonaka [18] después de observar pequeños equipos de alto rendimiento, en varias empresas
similares. Lasmismas observacionesse realizaronasuvezpor otrosinvestigadores[19, 20]. Scrum
esun procesode desarrollode software ágil,donde losproyectos progresan a través de una serie
de iteraciones de un mes de duración llamadas sprints [21, 22, 23].
Por otra parte, en una serie de sprints y de scrum, en promedio de 6 a 9, se puede producir una
versióndel producto. Al comienzodel proyecto,losrequisitosdelproyectoson capturados en una
lista conocida como el backlog de producto.
En el inicio de cada sprint una reunión de planificación de sprint es celebrada durante el cual el
propietario del producto define prioridades sobre el Backlog de Producto y los miembros del
equipo de scrum definen las tareas que puedan completar durante el próximo Sprint.
Para cada día de sprint,hay diariareuniónde pie para discutirlosproblemasdel proyecto,llamado
el scrumdiario. Los scrums diariosayudande manera significativa el desarrollo y la comunicación
del equipo.
Además,losmiembrosde losscrumsdiariospuedendecidirrápidamente sobre cualquiercuestión
que requieramayoratención.Losasuntosno se debaten en la reunión en sí, ya que esta no debe
durar más de 15 minutos. Al final del sprint el equipo presenta la funcionalidad desarrollada en
una reunión de revisión de Sprint.
Los procesos Scrumse agrupan entresfases[23], previaal juego, durante el juegoy la posterior al
juego.

7. La fase previa al juego incluye los siguientes procesos:
 Planificación, que incluye la definición de un nuevo lanzamiento basado en el backlog de
productoque actualmente se conoce, junto con una estimación de su duración y costos. Si el
sistema en desarrollo es nuevo, incluye la planificación, la conceptualización y el análisis.
 Desarrollode laarquitectura.Incluye laarquitectura,el desarrollo y el diseño de alto nivel. El
juego consiste en carreras cortas (sprint) de desarrollo que producen una nueva versión del
producto.
La fase posterior al juego es el cierre del proyecto, que incluye preparación de las versiones, la
producción de la documentación final, la ejecución de las pruebas de aceptación en el sitio y el
lanzamiento del producto final.
C. Driven Development (FDD)
Feature Driven Development (FDD) es un proceso iterativo e incremental de desarrollo de
software [7, 8].
La metodología FDD consta de cinco pasos que son los siguientes:
 Desarrollar el modelo general,
 Construir la lista de características,
 Planificar por área temática,
 Diseño del conjunto de características, y
 Construir por característica.
En la primera etapa, de desarrollar el modelo general, un alto nivel walkthrough del alcance del
sistema y de su entorno está hecho. El propósito principal es el de los requisitos de captura (de
datos) y desarrollar el diagrama inicial en clase UML que describe las entidades del dominio del
problema.Todo el trabajose divide y asignaa equipospequeños, que constan de desarrolladores
y usuarios.
Estos equipossonresponsablesde parte de todoel modeloy para lapresentaciónde sus modelos
para su revisión y aprobación. Finalmente, los modelos propuestos se fusionan para formar el
dominio del modelo.
El segundo paso del FDD es la construcción de la lista de las características. Los equipos de
desarrollo identificarán el conjunto de características necesarias, por la descomposición de la
funcionalidad del sistema en áreas temáticas. Cada materia se compone de actividades
comerciales que comprenden la actividad de negocios en los pasos (características).
Las características son funciones granulares expresadasentérminosde losclientes.Porlogeneral,
cada característica requiere hasta dos semanas de desarrollo. En el caso que la función requiera
más tiempo, entonces este paso se descompone en pasos más pequeños.
El tercer paso es producir el plan de desarrollo del proyecto. Planificación por áreas temáticas
implica la planificación del proyecto por agrupar funciones para conjuntos de características y

8. áreas temáticas.Laagrupación se realizade acuerdocon la funcionalidady lasdependenciasentre
las características. Otros factores a tener en consideración son: la carga a través del equipo de
desarrollo y la complejidad de las características para ser implementadas.
Tan prontocomo las característicasse agrupeny se esté de acuerdo con cuáles son las que deben
incluirse enel lanzamiento, tenemos que determinar la secuencia de desarrollo, para asignar las
actividadesdel negocioal jefe de programadores y, al hacerlo, tenga en cuenta cuál de las clases
principales se asignaránacualesdesarrolladores.Cuandoestaplanificación Se completael equipo
se pondrá entonces de acuerdo en una fecha para la entrega. El área temática y la función se
establecen en forma conjunta con el promotor del proyecto.
El cuarto pasoes el "Diseñode conjuntode características".El objetivo eneste paso es producir el
diseño de cada conjunto de características. Los modelos de diseño incluyen diagramas de
secuenciaUML, refinamientodel diagrama general de clasesUML desarrollado en el primer paso,
etc.
Por último,el quintopaso,"Construirporlacaracterística", implica acondicionamiento de un lote
pequeñode característicasdel conjuntode características decididoenel paso4 y el desarrollo del
código para esas características y la unidad de ponerlos a prueba. El lote de características se
conoce como un paquete de trabajodel Jefe Programador (CPWP) y debe ser seleccionada de tal
manera que puede ser completado por un solo grupo de trabajo de en menos de 2 semanas.
IV. COMPARACIÓN DE LOS MÉTODOS PMBOK y ágil
Con el fin de comparar los métodos de gestión de proyecto Se tomaron como base los procesos
del PMBOK,ya que estánorganizadosporáreas de conocimiento.Lasrazonesque contribuyerona
esta decisión fueron dos:
 PMBOK es una lista exhaustiva de buenas prácticas, en forma de procesos que puede ser
adaptado y modificado para requisitos particulares y necesidades específicas.
 PMBOK esbien conocido y documentado formalmente en comparación con los métodos ágil
presentados en este trabajo.
El resultado de esta comparación se presenta la Tabla I.

9. TABLA I
COMPARACIÓN DE PMBOK Y PROCESOS métodos ágiles
PMBOK
Métodos ágiles
XP Scrum FDD
Gestión de la Integracióndel Proyecto
●Desarrollar el Acta del
Proyecto
●Desarrollar Proyecto Pre-
liminar
●Declaración del alcance
●Desarrollar el Plande Ges
tión del Proyecto
●Administracióndirecta de
ejecución del proyecto
●Control y monitoreo del
trabajo del proyecto
●Control Integral de cam-
bios
●Cerrar proyecto
●Integración de software
tan prontoytan a menudo
como sea posible (en su
mayoría relacionados con
código de software).
●La propiedadcolectiva del
código
●Mediciónde la velocidad
de proyecto
●Verificación de la gestión
aprobaciónyfinanciación
durante fase de planifi-
cación.
●Validacióndel desarrollo
herramientas e infraes-
tructura durante la fase de
planificación.
●la gestión del cambio
Fuerte procedimiento con
el producto y sprint
backlog.
●Perfeccionamiento de los
sistemas la arquitectura de
la ayuda cambios.
●fase Postgame.
●Desarrollo del modelo
general de sistema.
Gestión delAlcance del Proyecto
●Planificación delAlcance,
●Definición del Alcance,
●Crear desglose del trabajo
Estructura (PEP),
●Verificación delAlcance y
●Control del Alcance
●historias de los usuarios
●Planificación del lanza-
miento, Pequeños Comu-
nicados
●Realizar un análisis de
dominiopara construir el
modelo de dominio.
●Desarrollo de una amplia
Lista backlogde producto.
●Desarrollo de una amplia
sprint backlog del pro-
ducto.
●Definición de la funcio-
nalidad que se incluirán en
cada lanzamiento.
●Selección de la versión
más apropiada para inme-
diato desarrollo.
●Examen de los progresos
para asignar elementos del
backlog.
●Realizar un análisis de do-
minio para construir un
modelo de dominio
(paso1).
●Construir lista de fun-
ciones sin prejuicios por
área (paso 2).

10. PMBOK
Métodos ágiles
XP Scrum FDD
Gestión delTiempodel Proyecto
●Definición de las Activi-
dades,
●Secuenciación de activi-
dades,
●Estimar recursos de las
actividades
●Estimaciónde la duración
de las actividades
●Desarrollo del cronogra-
ma y
●Control de plazos
●Planificación de lanza-
miento,
●planificación de itera-
ciones
●Definición de la fecha de
entrega yla funcionalidad
para cada versión.
●Iteraciones mensuales
●Determinar la secuencia
de desarrollo ( paso 3).
●Asignar actividades co-
merciales a los progra-
madores principales (paso
3).
●Asignar clasesde Desarro-
lladores (paso 3).
● paquetesde trabajoJefe
programador
.
Gestión delCostodel Proyecto
●Estimación de Costos,
●Presupuesto de Costes y
●proyecto de Control de
Costos
No disponible ●Estimación de costos de
lanzamiento, durante fase
de planificación.
No disponible
Gestión de la Calidad del Proyecto
●Planificación de la cali-
dad,
●Realizar Aseguramiento
de la calidad, y
●Realizar el control de
calidad.
●Énfasis en las pruebas
(Unidad, aceptación)
●Sobre la base de la
simplicidad
●El uso de estándares del
proyecto
●Distribucion, revisión y
ajuste de los estándares
con los cualesse ajustará el
producto
●Reunión de revisión del
diseño
●Reunión de planificación
de sprint
●Reunión de revisión de
sprint
●Scrum diario
●Reuniones de revisión
(todos los pasos)
●prueba de inspección
Código y la unidad
(Paso 5)
Gestión de los Recursos Humanos del Proyecto
●Planificación de Recursos
Humanos,
●Adquirir el Equipo del
Proyecto,
●Desarrollar el Equipo del
Proyecto, y
●Gestionar el Equipo del
Proyecto.
●Rotaciónde personal en
varias posiciones
●Programaciónenpare-jas
●Buenas condiciones de
trabajo (Sin horas extra-
ordinarias)
●Designaciónde equipode
proyecto para el lanza-
miento.
●Participación del equipo
en las reuniones de sprint
●Participación del equipo
en los scrums diarios
●Designar equipo de mo-
delado (paso1)
●Designar funciónde equi-
po (paso 2)
●Designar Equipo de Pla-
nificación (paso 3)
●Designar equipo de las
características (paso3)
Gestión de las Comunicaciones del Proyecto
●Planificación de las comu-
nicaciones,
●Distribución de la infor-
mación,
●Informes de rendimiento,
y
●Gestionar a los interesa-
dos
●El uso de la metáfora del
sistema
●Cliente siempre disponi-
ble
●Las reuniones diarias
●El uso de estándares del
proyecto
●Reunión de revisión del
diseño
●Reunión Scrum
●Reunión de planificación
de Sprint
●Reunión de revisión de
Sprint
●Comunicación de los
estándares al equipo del
proyecto
●Reuniones de revisión
(todos los pasos)

11. PMBOK
Métodos ágiles
XP Scrum FDD
Gestión de Riesgos del Proyecto
●Planificación de la ges-
tión de riesgos,
●Identificaciónde riesgos
●Análisis cualitativo de
riesgos,
●Análisis cuantitativo de
riesgos,
●Planificación de respues-
tas a los Riesgos, y
●Supervisión y Control de
Riesgos.
●Crear prototipo para li-
mitar riesgos
●La evaluación inicial de
los riesgos antesydurante
el juego.
●Revisiónde riesgos duran-
te las reunionesde revisión
No disponible
Gestión de las Adquisiciones del Proyecto
●Planificar las Compras y
adquisiciones,
●Plan de Contrataciones,
●Solicitar respuestas de
vendedores,
●Selecciónde vendedores,
●Administraciónde contra-
tos, y
●Cierre del Contrato.
No disponible No disponible No disponible
V. CONCLUSIÓN
La TablaI demuestraque losmétodoságiles no definen todas las facetas sea necesario con el fin
de cubrir todos los aspectos de la gestión del proyecto, en el sentido tradicional. Esto era de
esperar ya parcialmente los procesos de gestión de proyectos tradicional están completamente
definidos en comparación con los métodos ágiles que son considerados "empírica".
Sin embargo, a partir de este estudio podemos concluir lo siguiente. Los métodos ágiles están
dando énfasis en las siguientesáreas de conocimiento:
que el énfasis se da en la gestión de requisitos.
en el trabajo en equipo.
uso definido, de normas, pruebas y
revisiones frecuentes son promovidos.
Por otro lado, los métodos ágiles no tratan plenamente el las siguientes áreas de conocimiento:
mente,
os no es parte de las metodologías ágiles
absoluto.
Esto implicaque laconexiónde los métodos ágiles con PMBOK no beneficiará a la comunidad de
gestiónde proyectosde software. Lossiguientepasode este trabajo es el mapeo detallado entre
procesos del PMBOK y las metodologías ágiles
GLOSARIO
Sprint: correr a toda velocidad en una distancia corta.

12. Backlog: una acumulación de algo, sobre todo el trabajonofinalizadoo asuntos que necesitanser resueltos.
Scrum: una formaciónordenada de los jugadores, que se utiliza para reiniciar el juego, enel que los delanteros de un
equipoforman conlos brazos entrelazados yla cabeza hacia abajo, yempujanhacia adelante contra ungrupo similar
desde el lado opuesto. La pelota es lanzada enel scrumylos jugadores tratande ganar la posesiónde la misma por
patadas hacia atrás, haciasupropiolado.
Walkthrough: un recorridoo demostraciónde un área o tarea.
REFERENCIAS
[1] F. Brooks Jr., The mythical man-month:essays on software engineering
— Anniversary ed., AddisonWesleyLongman, 1995.
[2] R. Charette, Whysoftware fails, IEEE Spectrum, September 2005.
[3] J.S. Reel,Critical success factors insoftware projects, IEEE Software,
16(3), 19-23.
[4] T. Chow, andD-B. Cao, A SurveyStudyof Critical Success Factors in
Agile Software Projects, The Journal of Systems and Software, doi:
10.1016/j.jss.2007.08.020, in press.
[5] A. Carmichael, andD. Haywood, Better Software Faster, Prentice-Hall
NJ, 2002.
[6] K. Beck, Extreme Programming Explained:Embrace Change, Addison-
WesleyProfessional, 1999.
[7] P. Coad, E. Lefebvre, andJ. De Luca, Java Modeling in Color with
UML: Enterprise Components and Process, Prentice Hall, 1999.
[8] A. Carmichael, andD. Haywood, Better Software Faster, Prentice-Hall
NJ, 2002.
[9] S. Augustine andS. Woodcock, Agile Project Management, CCPace,
Available at www.ccpace.com.
[10] PMI Institute, A Guide to the Project Management Body of Knowledge,
PMI StandardCommittee, 2004.
[11] U.S. Department ofDefense, Extension to:A Guide to the Project
Management Body of Knowledge, First Edition, Version 1.0, 2003.
[12] International Project Management Association, IPMA Competence
Baseline, Version3.0. Van HarenPublishing, 2006.
[13] M. Sliger, Relating PMBOKPractices to Agile Practices, Available at
http://www.stickyminds.com
[14] G. Alleman, PMBOKand agile article, Available at
http://herdingcats.typepad.com/my_weblog/2007/08/pmbok-andagile.
html
[15] K. Auer, and R. Miller, Extreme Programming Applied:Playing to Win
(The XPSeries), Addison Wesley - NewYork, 2002.
[16] S. W. Ambler, AgileModeling:Effective Practicesfor Extreme
Programmingandthe UnifiedProcess, Wileyand Son, Inc., 2002.
[17] K. Beck andM. Fowler, Planning Extreme Programming, Addison-
Wesley, 200.
[18] H. Takeuchi andI. Nonaka, The New New Product Development Game,
Harvard Business Review, January-February1986.
[19] J. Coplien, Borland Software Craftsmanship:A New Lookat Process,
QualityandProductivity, Proceedings of the 5th Annual Borland
InternationalConference, June 1994, Orlando, Florida.
[20] K. Schwaber, ControlledChaos:Living onthe Edge, American
Programmer, April 1996.
[21] K. Schwaber, Agile Project Management with Scrum, Microsoft Press,
2004.

13. [22] L. Rising, and N.S. Janoff, The ScrumSoftware Development Process
for Small Teams, IEEE Software, July-August 2000.
[23] K. Schwaber, Advanced Development Methods. SCRUMDevelopment.
Available at http://jeffsutherland.com/oopsla/schwapub.pdf