Comparando PMBOK y Agile ProjectLos procesos de desarrollo de software de gestión

RESUMEN

El objetivo de este artículo es comparar un conjunto genérico de procesos de gestión de 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é desarrollado por el Instituto de 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ón de la integración, gestión del alcance, gestión del tiempo, gestión de 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 los siguientes principios: aceptar el cambio, se centran en el valor del cliente, entregar parte de la funcionalidad de forma incremental, colaborar reflexionar y aprender continuamente. El propósito de esta comparación es identificar las lagunas, las diferencias, discrepancias, etc. El resultado es que, las metodologías de gestión de proyectos ágiles no pueden considerarse 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 controlar grandes proyectos de desarrollo, y de las dificultades de estimación y gestión de estos esfuerzos para entregar 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, los profesionales de tecnologías de la información de hoy en día están bajo una tremenda presión para entregar productos de TI y servicios de calidad, con el fin de responder a los siempre dinámicos y rápidos cambios del mercado.

Como resultado, la lista de los grandes proyectos de 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 desarrollar software y gestionar proyectos. El desarrollo ágil de software intenta poner el software que está siendo desarrollado por primera vez. Además, los métodos ágiles reconocen que las

necesidades de los usuarios pueden cambiar, que tenemos que responder rápidamente a las necesidades de los usuarios, que hay una necesidad de producir frecuente y regularmente, murvas versiones del software, etc.

El Manifiesto de desarrollo de software ágil fue publicado en febrero de 2001 por un grupo de 17 expertos en procesos de software, que asistieron a una reunión en la cumbre para promover una mejor manera de desarrollar el software y luego formó el Agile Alianza. El Manifiesto de desarrollo ágil de software puede encontrarse en el sitio web de Agile Alliance (Http://www.agilemanifesto.org).

Desde entonces, una serie de métodos de desarrollo de software se ha suscrito a este enfoque. La lista varía dependiendo de diferentes puntos de 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 intento de mejorar los procesos existentes. 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 en los procesos, el desarrollo lineal ciclos y la cascada como los ciclos de vida de desarrollo de software. Junto con la previsibilidad, que proviene de un enfoque determinista y reduccionista que dependían de desglose de tareas, y estaba basada en la estabilidad - requisitos estables, análisis y 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 un total de 44 procesos de 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 brevemente en la siguiente sección. Dentro de PMBOK cada proceso se describe en términos de entradas (documentos, planos, diseño, otros datos, etc.), las salidas (documentos, productos) y las herramientas y técnicas (mecanismos que se aplican a los insumos para la producción de salidas) y sin ser demasiado específico, proporciona una guía para alguien que desea para aplicar los procesos [11].

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.

Sin embargo, incluso aunque los métodos ágiles son atractivos y su uso está logrando resultados prometedores hay críticas que cuestionan si son metodologías completas de 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 siguientes secciones, presentaremos brevemente las principales características del PMBOK y de algunos de los métodos ágiles más conocidos. Luego los compararemos teniendo como base los procesos definidos, por área de conocimiento, en el PMBOK.

II. CUERPO DE CONOCIMIENTOS EN GESTIÓN PROYECTOS

Como se mencionó antes, la gestión y administració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, ya que estas zonas 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, yg. Cierre del proyecto.

2. Gestión del 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

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, yf. Calendario de control.

4. Gestión de los costos 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 yc. Control de Costes.

5. Gestión de la Calidad del Proyecto, se describen los procesos 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, yc. 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, yd. Gestionar el Equipo del Proyecto.

7. Gestión de las Comunicaciones del 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 yd. 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:

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, yf. Supervisión y Control de Riesgos.

9. Gestión de Compras del 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, yf. 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 manifiesto no es un proceso orientado o enfocado. Como el que fue presentado en la introducción, hay muchos mé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 basa en 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

Además, XP se basa en una serie de prácticas. Algunos son:

Planificación. El alcance de la próxima versión debe 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. Todo el desarrollo es impulsado por una simple historia de cómo funciona todo el 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 propiedad colectiva. Cualquier persona puede 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 instalaciones del cliente. Un representante del cliente o de la organización debería estar

disponible a tiempo completo o para responder a las preguntas del equipo del proyecto.

B. SCRUM

Scrum es un enfoque para el desarrollo de nuevos productos fue presentado primero por Takeuchi y Nonaka [18] después de observar pequeños equipos de alto rendimiento, en varias empresas similares. Las mismas observaciones se realizaron a su vez por otros investigadores [19, 20]. Scrum es un proceso de desarrollo de software ágil, donde los proyectos 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ón del producto. Al comienzo del proyecto, los requisitos del proyecto son 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 diaria reunión de pie para discutir los problemas del proyecto, llamado el scrum diario. Los scrums diarios ayudan de manera significativa el desarrollo y la comunicación del equipo.

Además, los miembros de los scrums diarios pueden decidir rápidamente sobre cualquier cuestión que requiera mayor atención. Los asuntos no 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 Scrum se agrupan en tres fases [23], previa al juego, durante el juego y la posterior al juego.

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 producto que 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.

Desarrollo de la arquitectura. Incluye la arquitectura, 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 trabajo se divide y asigna a equipos pequeños, que constan de desarrolladores y usuarios.

Estos equipos son responsables de parte de todo el modelo y para la presentación de 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 expresadas en términos de los clientes. Por lo general, 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

áreas temáticas. La agrupación se realiza de acuerdo con la funcionalidad y las dependencias entre 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 pronto como las características se agrupen y se esté de acuerdo con cuáles son las que deben incluirse en el lanzamiento, tenemos que determinar la secuencia de desarrollo, para asignar las actividades del negocio al jefe de programadores y, al hacerlo, tenga en cuenta cuál de las clases principales se asignarán a cuales desarrolladores. Cuando esta planificación Se completa el 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 paso es el "Diseño de conjunto de características". El objetivo en este paso es producir el diseño de cada conjunto de características. Los modelos de diseño incluyen diagramas de secuencia UML, refinamiento del diagrama general de clases UML desarrollado en el primer paso, etc.

Por último, el quinto paso, "Construir por la característica", implica acondicionamiento de un lote pequeño de características del conjunto de características decidido en el paso 4 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 trabajo del 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án organizados por áreas de conocimiento. Las razones que contribuyeron a 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 es bien 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.

TABLA I

COMPARACIÓN DE PMBOK Y PROCESOS métodos ágiles

PMBOK Métodos ágilesXP Scrum FDD

Gestión de la Integración del Proyecto●Desarrollar el Acta del Proyecto●Desarrollar Proyecto Pre- liminar●Declaración del alcance●Desarrollar el Plan de Ges tión del Proyecto●Administración directa de ejecución del proyecto●Control y monitoreo del trabajo del proyecto●Control Integral de cam-bios●Cerrar proyecto

●Integración de software tan pronto y tan a menudocomo sea posible (en su mayoría relacionados con código de software).●La propiedad colectiva del código●Medición de la velocidad de proyecto

●Verificación de la gestiónaprobación y financiación durante fase de planifi-cación.●Validación del desarrolloherramientas 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 del Alcance del Proyecto●Planificación del Alcance,●Definición del Alcance,●Crear desglose del trabajoEstructura (PEP),●Verificación del Alcance y●Control del Alcance

●historias de los usuarios●Planificación del lanza-miento, Pequeños Comu-nicados

●Realizar un análisis de dominio para construir el modelo de dominio.●Desarrollo de una ampliaLista backlog de producto.●Desarrollo de una ampliasprint 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).

PMBOK Métodos ágilesXP Scrum FDD

Gestión del Tiempo del Proyecto●Definición de las Activi-dades,●Secuenciación de activi-dades,●Estimar recursos de las actividades●Estimación de 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 y la 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 clases de Desarro-lladores (paso 3).● paquetes de trabajo Jefe programador.

Gestión del Costo del 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 yajuste de los estándares con los cuales se 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ón de personal en varias posiciones●Programación en pare-jas●Buenas condiciones de trabajo (Sin horas extra-ordinarias)

●Designación de equipo de 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ón de 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)

PMBOK Métodos ágilesXP Scrum FDD

Gestión de Riesgos del Proyecto●Planificación de la ges-tión de riesgos,●Identificación de 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 antes y durante el juego.●Revisión de riesgos duran-te las reuniones de revisión

No disponible

Gestión de las Adquisiciones del Proyecto●Planificar las Compras yadquisiciones,●Plan de Contrataciones,●Solicitar respuestas de vendedores,●Selección de vendedores,●Administración de contra-tos, y●Cierre del Contrato.

No disponible No disponible No disponible

V. CONCLUSIÓN

La Tabla I demuestra que los mé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: Gestión del Alcance, ya que el énfasis se da en la gestión de requisitos. Gestión de recursos humanos, ya que se da énfasis en el trabajo en equipo. Gestión de la calidad, a pesar de que no es formalmente 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: El riesgo no se gestiona explícitamente, La gestión de costos no es parte de las metodologías ágiles Gestión de las adquisiciones no se aborda en absoluto.

Esto implica que la conexión de los métodos ágiles con PMBOK no beneficiará a la comunidad de gestión de proyectos de software. Los siguiente paso de este trabajo es el mapeo detallado entreprocesos del PMBOK y las metodologías ágiles

GLOSARIO

Sprint: correr a toda velocidad en una distancia corta.

Backlog: una acumulación de algo, sobre todo el trabajo no finalizado o asuntos que necesitan ser resueltos.Scrum: una formación ordenada de los jugadores, que se utiliza para reiniciar el juego, en el que los delanteros de un equipo forman con los brazos entrelazados y la cabeza hacia abajo, y empujan hacia adelante contra un grupo similar desde el lado opuesto. La pelota es lanzada en el scrum y los jugadores tratan de ganar la posesión de la misma por patadas hacia atrás, hacia su propio lado.Walkthrough: un recorrido o demostración de un área o tarea.

REFERENCIAS

[1] F. Brooks Jr., The mythical man-month: essays on software engineering— Anniversary ed., Addison Wesley Longman, 1995.[2] R. Charette, Why software fails, IEEE Spectrum, September 2005.[3] J.S. Reel, Critical success factors in software projects, IEEE Software,16(3), 19-23.[4] T. Chow, and D-B. Cao, A Survey Study of Critical Success Factors inAgile Software Projects, The Journal of Systems and Software, doi:10.1016/j.jss.2007.08.020, in press.[5] A. Carmichael, and D. Haywood, Better Software Faster, Prentice-HallNJ, 2002.[6] K. Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley Professional, 1999.[7] P. Coad, E. Lefebvre, and J. De Luca, Java Modeling in Color withUML: Enterprise Components and Process, Prentice Hall, 1999.[8] A. Carmichael, and D. Haywood, Better Software Faster, Prentice-HallNJ, 2002.[9] S. Augustine and S. Woodcock, Agile Project Management, CC Pace,Available at www.ccpace.com.[10] PMI Institute, A Guide to the Project Management Body of Knowledge,PMI Standard Committee, 2004.[11] U.S. Department of Defense, Extension to: A Guide to the ProjectManagement Body of Knowledge, First Edition, Version 1.0, 2003.[12] International Project Management Association, IPMA CompetenceBaseline, Version 3.0. Van Haren Publishing, 2006.[13] M. Sliger, Relating PMBOK Practices to Agile Practices, Available athttp://www.stickyminds.com[14] G. Alleman, PMBOK and agile article, Available athttp://herdingcats.typepad.com/my_weblog/2007/08/pmbok-andagile.html[15] K. Auer, and R. Miller, Extreme Programming Applied: Playing to Win(The XP Series), Addison Wesley - New York, 2002.[16] S. W. Ambler, Agile Modeling: Effective Practices for ExtremeProgramming and the Unified Process, Wiley and Son, Inc., 2002.[17] K. Beck and M. Fowler, Planning Extreme Programming, Addison-Wesley, 200.[18] H. Takeuchi and I. Nonaka, The New New Product Development Game,Harvard Business Review, January-February 1986.[19] J. Coplien, Borland Software Craftsmanship: A New Look at Process,Quality and Productivity, Proceedings of the 5th Annual BorlandInternational Conference, June 1994, Orlando, Florida.[20] K. Schwaber, Controlled Chaos: Living on the Edge, AmericanProgrammer, April 1996.[21] K. Schwaber, Agile Project Management with Scrum, Microsoft Press,2004.

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