Archivo de la etiqueta: PMBOK

PMBOK vs Scrum

Expondré el porqué de Scrum como metodología adecuada para un proyecto de fin de carrera como es una tesis universitaria. Específicamente para uno que incluye un desarrollo en el área de Tecnologías de la Información.

En principio la metodología sugerida por el PMBOK supone:
Especialización: Miembros de equipo y roles bien delimitados y casi independientes lo que no considera una interacción cercana entre roles.
Fases: Delimitadas y rígidamente definidas, por lo que las tareas se concluyen en una fase y la acción de los roles se encuentra encasillada en una o más fases.
Requisitos detallados: Los requerimientos llegan al equipo de desarrollo a través de un artefacto. El cliente no interactúa estrechamente con el producto durante su desarrollo.
Seguimiento del plan: No se experimenta con opciones atractivas que se puedan presentar durante el transcurso del proyecto sino que se controla rígidamente el plan establecido.

En contraposición Scrum conssidera:

Solapamiento de actividades

Scrum establece ciclos en los que las fases se solapan de forma muy amplia lo que permite actualizar los requerimientos del proyecto, ajustar la planificación e incluso poder reformular el alcance. De esta forma, más que fases que se realizan de forma secuencial, se tienen actividades que se ejecutan en el momento en que se requieren. Educción de requisitos, análisis, codificación, pruebas e integración se
van realizando en cada momento según las necesidades en la evolución del proyecto. Todo esto está guiado por la gestión del alcance que otorga principalmente la exploración medida de actividades. Si se presenta la oportunidad de avanzar algún aspecto del proyecto sin correr riesgos pues este avance se realiza hasta que se vea la dimensión real del aspecto referido y plantear la planificación más adecuada en el contexto correspondiente y tratando de aprovechar los avances completados.

Visión del producto

Queda claro que se busca obtener un producto. La afirmación del concepto del producto tiene mucho más peso que los requisitos específicos del sistema. Se hace necesaria la dirección estratégica ante la ausencia de un plan detallado.

Roles

Para Scrum se considera su compatibilidad con un equipo multidisciplinar. Para el caso de una tesis, el tesista es el único encargado de los roles al interior del proyecto.
Otros roles pertenecen al asesor, asesores que realizarán correcciones al borrador del documento de tesis y el jurado.
– El asesor es cliente del documento de tesis y del producto del proyecto.
– El jurado es cliente del proyecto en su conjunto.
– Los otros asesores que realizarán una corrección al borrador del documento es un cliente no del proyecto sino de su propia apreciación del documento de tesis. Se debe atender sus apreciaciones en la medida que su posición es tan externa como lo es la de los miembros del jurado del proyecto de tesis.
El equipo de desarrollo es auto-organizado y en el caso particular de este proyecto es la unidad auto-organizada representada por el tesista.

Adaptación a los cambios

Pueden ser modificados, dejados de lado o cambiados:
– La elaboración del documento por su correspondencia con el producto a desarrollar.
– La selección de herramientas de desarrollo del producto y de gestión del proyecto.
– El software de terceros.
– El alcance hasta una etapa temprana y fijada del proyecto.

La modificación de un requisito no existe como tal ya que no ha existido la fase de requisitos tradicional sino que se ve enriquecida para concretar la visión del producto.
La incertidumbre es observada constantemente y por eso se permite el descubrimiento paulatino durante el desarrollo y se tiene cuidado con las circunstancias que se van produciendo.
El principal motivo para la elección de Scrum es que el margen de libertad amplio es propicio para que los encargados del proyecto aporten con su ingenio y compromiso.

Por ser un proyecto unipersonal son importantes las disciplinas de
Autocontrol: Se genera un ambiente de responsabilidad y de gusto por el trabajo que se realiza.
Autosuperación: Se desarrollan soluciones que son evaluadas, analizadas y mejoradas.

Por ser un proyecto único se considera:
– Muchos proyectos, como una tesis, no son parte de procesos industriales y no es el plan producir muchos sino un único producto, es un proyecto particular.

De acuerdo al Manifiesto Ágil se reconoce valor en los procesos formales que sugiere el PMBOK pero que considera preferibles otros aspectos:
Individuos y su interacción frente a Procesos y herramientas
Software que funciona frente a Documentación exhaustiva
Colaboración con el cliente frente a Negociación contractual
Respuesta al cambio frente a Seguimiento de un plan

PeruBlogs Tag: Scrum PMBOK Tesis Proyecto de Fin de Carrera Ventajas Comparación

BlogsPeru Tag: [Scrum] [PMBOK] [Tesis] [Proyecto de Fin de Carrera] [Ventajas] [Comparación]

Anuncios

PMBOK

Aquí comparto con ustedes una breve reseña sobre las prácticas expuestas en el PMBOK.

El PMBOK, cuya referencia en español es Guía de Fundamentos de la Dirección de Proyectos, es una publicación del Instituto de Dirección de Proyectos (PMI) que es una organización sin fines de lucro de origen estadounidense y de presencia actual mundial.

PMBOK [PMB2004] define proyecto como un esfuerzo temporal tomado para crear un producto, servicio o resultado único.

Para enfocar el análisis de la gestión plantea la idea de la restricción desde tres perspectivas:
• Alcance: Describe claramente el objetivo del proyecto.
• Tiempo: Enfoca el tiempo asignado al proyecto.
• Costo: Observa el costo involucrado.

Alcance, Costo y Tiempo
Figura 1.1: Triple Restricción [MYM]

De acuerdo al PMBOK la gestión de proyectos agrupa los procesos en cinco grupos que son:
• Procesos de iniciación
• Procesos de seguimiento y control
• Procesos de planificación
• Procesos de ejecución
• Procesos de cierre

Grupos de Procesos de la Gestión de Proyectos en la 
metodologia PDCA
Figura 1.2: Grupos de Procesos de la Gestión de Proyectos en la metodología PDCA [PMB2004]

Las áreas de conocimiento en la gestión de proyectos son:
• Gestión del Alcance
• Gestión de Tiempos
• Gestión de Costos
• Gestión de la Calidad
• Gestión de los Recursos Humanos
• Gestión de las Comunicaciones
• Gestión de los Riesgos
• Gestión de las Adquisiciones
• Gestión de la Integración

Las áreas de dominio requerido por el equipo de proyecto son:
• Habilidades Interpersonales
• Conocimiento y Habilidades de Gestión
• Entendimiento del Entorno del Proyecto
• Conocimiento aplicado en el Área, Estándares y Regulaciones

De acuerdo a [PMTIC] se debe pensar en un modelo simplificado para pequeños proyectos de Tecnologías de Información.

Relación entre Grupos de procesos y Áreas del Conocimiento
Figura 1.3: Relación entre Grupos de procesos y Áreas del Conocimiento

La figura 1.3 muestra la forma en la que intervienen los Grupos de Procesos en cada Área de Conocimiento.

De acuerdo a [WPM] se debe enfatizar en:
• Entendimiento de lo que se hace
• Gestión del Riesgo
• Gestión del Cliente
• Control de Versiones

Fuentes:

[PMB2004]
Título: A Guide to the Project Management Body of Knowledge
Edición/Versión: Third Edition
Editorial/Grupo: Project Management Institute
Fecha: 2004

[PMTIC]
Título: Modelo Simplificado para la gestión de pequeños proyectos de Tecnologías de Información
Contexto: Congreso Nacional de Gerencia de Proyectos PMI 2007
Enlace: http://www.scribd.com/doc/3365954/ModSimp-TICs-PMI-Peru-Congreso-2007
Día de acceso: 16/07/2008

[WPM]
Título: Web Project Management
Contexto: TODcon en Orlando
Enlace: http://www.slideshare.net/jrrodgers/web-project-management-todcon2008
Día de acceso: 16/07/2008

PeruBlogs Tag: Proyectos PMBOK Dirección de Proyectos Gestión de Proyectos PMI Proyectos Web Proyectos TI Proyectos de Tecnologías de Información

BlogsPeru Tag: [Proyectos] [PMBOK] [Dirección de Proyectos] [Gestión de Proyectos] [PMI] [Proyectos Web] [Proyectos TI] [Proyectos de Tecnologías de Información]