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 Ágil 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…
Una Caja de Herramientas para la Economía de Proyectos
Las organizaciones de la economía de proyectos pueden comenzar a utilizar buenas herramientas freemium para gestionar proyectos hoy mismo, sin realizar ninguna inversión. Si las funcionalidades gratuitas son suficientes, podrán continuar así indefinidamente, centrándose en el valor y no en la tecnología. Hoy día es posible configurar una caja de herramientas gratuitas para cubrir la mayoría de las necesidades de cualquier proyecto.
Activar la PMO en 1 semana
Las organizaciones de la economía de proyectos no pueden esperar 6 meses para que la PMO funcione a pleno rendimiento. Gracias a nuestra herramienta PMPeople, activar un servicio de PMO dentro de la organización ya no tiene por qué ser un proyecto largo y costoso. Toda la tecnología necesaria puede quedar resuelta en 1 semana, para comenzar a poner el foco inmediatamente en la función de la PMO. En el plazo de 1 semana, ahora es técnicamente posible llevar a un porcentaje alto de personas de la organización a colaborar de forma productiva en gestión de proyectos, adoptando diferentes roles.
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.