Evaluar el desempeño del Project Manager con PMBOK7
Todo el mundo sabe cocinar, pero no todo el mundo es cocinero. Nuestra profesión no es diferente: Todo el mundo puede coordinar tareas, pero no todos son project managers. La gente debería poder opinar, sin tener que ser PMP®, si un project manager es buen o mal profesional. PMI® tiene un estándar de práctica denominado Project Manager Competency Development Framework (PMCDF), basado en los procesos de PMBOK5. Es previsible que la siguiente edición de PMCDF esté alineada con PMBOK7, que persigue que los interesados puedan comprobar el buen o mal desempeño del proyecto en 8 dominios.
Practicando la Guía del PMBOK® 7ª edición con PMPeople
PMPeople puede verse como un marco tecnológico para aquellos profesionales que quieren seguir la nueva versión del PMBOK: Como project manager profesional, puedo seguir los 12 principios más fácilmente porque tengo el hábito de actualizar la información de gestión en PMPeople. Como interesado, puedo comprobar el buen o mal desempeño del proyecto en los 8 dominios porque encuentro las evidencias directamente en PMPeople.
Controlar Proyectos Ágiles
En los proyectos software hay una complacencia alarmante sobre los incumplimientos. Es habitual escuchar la frase «Yo no he visto ningún proyecto software que cumpla fechas o que no cueste más del doble». ¿De verdad te parece que esto es un problema sin solución? Si dejas que los técnicos realicen sus tareas, pero nadie rinde cuentas sobre el proyecto, ¿por qué te sorprende que no se cumplan las fechas, o que el coste final sea muy superior? Los proyectos ágiles también se deben controlar.
El Project Manager Ágil
Un Project Manager Agile debería tener como referencia en su día a día el rol de agile practitioner delineado por PMI®. En el texto que usa PMI® para especificar el examen PMI-ACP® se describen 7 dominios que resumen las principales áreas de responsabilidad del Director de Proyectos Ágil….
Caso de Estudio Ágil (5/5): Fin de la Primera Release
Quinta y última entrega de la traducción capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, dejábamos al equipo a punto de comenzar la primera iteración de 2 semanas, que habían planificado en 4 historias de 18 puntos. También habían previsto que…
Caso de Estudio Ágil (4/5): Release Planning
Cuarta entrega de la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, el equipo del proyecto Havannah estaba manteniendo una reunión con una agenda de tres puntos: Planificar la primera iteración. Revisar los resultados de la investigación de mercado. Hacer una…
Caso de Estudio Ágil (3/5): Planificar el primer Sprint
Tercera entrega de la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, el equipo del proyecto Havannah había escrito 32 historias de usuario, que tenían un tamaño de 146 puntos en total. En este post, los miembros del equipo dedican dos semanas…
Caso de Estudio Ágil (2/5): Historias de Usuario
Continúa la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En este segundo artículo veremos la conveniencia de escribir tarjetas físicas y cómo puede organizarse una reunión de brainstorming para hacer que los miembros del equipo vayan deduciendo los requisitos (en forma de historias de usuario)….
Caso de Estudio Ágil (1/5): Lanzamiento del Proyecto
El siguiente caso de estudio es una traducción del capítulo 23 del libro de Mike Cohn titulado Agile Estimating and Planning. En este capítulo, el autor, con la intención de resumir y ejemplificar la mayoría de los puntos clave del libro, desarrolla el caso práctico de…
El “Ciudadano Programador” en la Economía de Proyectos
Un citizen developer es un usuario sin formación técnica que crea software de negocio para otros mediante plataformas de desarrollo LCNC supervisadas por el departamento de informática. En 2024, más del 65% de los proyectos software de la economía de proyectos tendrán en sus equipos algún citizen developer. Esto no significa que los proyectos software trabajen al margen del departamento de informática, sino más bien lo contrario.