Archivo de la categoría: Gestión de Proyectos

Gestión de Proyectos

Desafío en la dirección de proyectos informáticos, presente y futuro

La charla “Desafío en la dirección de proyectos informáticos, presente y futuro” tuvo lugar en Infosoft 2012, a cargo de Luis Flores.

» Leer más

[INFOGRAFÍA] ¿Por qué los Reportes de Performance Laboral van a volverse Sociales?

[INFOGRAFÍA] ¿Por qué los Reportes de Performance Laboral van a volverse Sociales?

Pasando del reporte de performance a una interacción humana entre los equipos, motivación continua, feedback y reconocimiento constante y público de los logros y progreso en los proyectos

Las compañías intentaron apuntar a los desafíos del reporte de performance a través de la automatización y software, pero no sin consecuencias negativas.

– “Tu reporte dice EXACTAMENTE lo mismo que el mío”
– “Síp! Creo que él hico todos los reportes en el último minuto… le tomó 25 minutos para todo el equipo.”

Los reportes de performance DESTRUYEN la moral, MATAN el trabajo en equipo, y HIEREN a la última línea. – [2008] Deshazte del Reporte de Performance publicado por Prof. Samuel Culbert

– “WTF?! Esto no cubre siquiera LA MITAD todo el trabajo que he realizado!”

El futuro

V.5 website launch COMPLETED
– Thanks for all your help
– Killer design Jane! ✔

ROCKSTAR Award to the marketing team!
– Thanks Mark

Closed Coffee Bottle account
– You ROCK, GEORGE
– ★★★★

» Leer más

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]

» Leer más

Scrum

Scrum es una metodología de gestión de proyectos de software y es por eso que se percibe más cercana al desarrollo de la solución que la metología sugerida en el PMBOK, que es más genérica.

Roles

Roles en Scrum

Dueño del Producto mantiene la orientación del equipo hacia los requerimientos del cliente. El Product Backlog está a su cargo.
Scrum Master es quién mantiene la correcta aplicación de las prácticas Scrum al interior del equipo.
Equipo Scrum, dentro del cual están los desarrolladores.
– Los Usuarios y Clientes también son roles considerados en la metodología Scrum.

Artefactos

Artefactos en Scrum

Los artefactos principales son:
Product Backlog: Es una lista con las funcionalidades del sistema con sus correspondientes niveles de prioridad. Nuevas funcionalidades pueden ser adicionadas a esta lista.
Sprint Backlog: Es un documento detallado que indica la forma en la que se van a cubrir los requerimientos. Las tareas no deben ser demasiado extensas por lo que sí se admite que sean numerosas.

También te puede interesar leer:

PMBOK – Una reseña breve sobre las prácticas expuestas en el PMBOK.

PMBOK vs Scrum – Un Versus (comparativa) para el caso práctico de Proyecto de Tesis entre las prácticas sugeridas por el PMBOK y Scrum.

PeruBlogs Tag: Scrum Gestión de Proyectos de Software Metodología Ágil Gestión Ágil

BlogsPeru Tag: [Scrum] [Gestión de Proyectos de Software] [Metodología Ágil] [Gestión Ágil]

» Leer más

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.

Triple Restricción: 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 <br />
metodología PDCA” title=”Grupos de Procesos de la Gestión de Proyectos en la <br />
metodología PDCA” /><br />
Figura 1.2: Grupos de Procesos de la Gestión de Proyectos en la metodología PDCA <b>[PMB2004]</b></p>
<p>Las áreas de conocimiento en la gestión de proyectos son:<br />
• Gestión del Alcance<br />
• Gestión de Tiempos<br />
• Gestión de Costos<br />
• Gestión de la Calidad<br />
• Gestión de los Recursos Humanos<br />
• Gestión de las Comunicaciones<br />
• Gestión de los Riesgos<br />
• Gestión de las Adquisiciones<br />
• Gestión de la Integración</p>
<p>Las áreas de dominio requerido por el equipo de proyecto son:<br />
• Habilidades Interpersonales<br />
• Conocimiento y Habilidades de Gestión<br />
• Entendimiento del Entorno del Proyecto<br />
• Conocimiento aplicado en el Área, Estándares y Regulaciones</p>
<p>De acuerdo a <b>[<a href=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

También te puede interesar leer:

Scrum – Una reseña breve sobre Scrum

PMBOK vs Scrum – Un Versus (comparativa) para el caso práctico de Proyecto de Tesis entre las prácticas sugeridas por el PMBOK y Scrum.

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] » Leer más