Categoría: Metodología

EXAMEN DE CERTIFICACIÓN PMI RISK MANAGEMENT PROFESIONAL (PMI-RMP)

Dejar un comentario

A petición de algunos colegas de profesión, comparto mi experiencia acerca del examen correspondiente a la de certificación PMI Risk Management Professional (PMI-RMP) realizado con fecha 03-09-18.

Me voy a centrar en la preparación y en el examen propiamente dicho. Los requerimientos para poder presentarse al examen se pueden encontrar en la web de PMI, dentro del manual oficial de PMI (PMI-RMP Handbook). En ese documento se pueden encontrar los pre-requisitos de eligibilidad para poder optar a la certificación:

  • Un título de 4 años (título universitario o equivalente):
    • 3.000 horas de experiencia en gestión de riesgos en proyectos en los últimos cinco años
    • 30 horas de educación en materia de gestión de riesgos
  • Un diploma de educación secundaria:
    • 4.500 horas de experiencia en gestión de riesgos en proyectos en los últimos cinco años
    • 40 horas de educación en materia de gestión de riesgos

Por otra parte, el esquema del contenido del examen se puede encontrar aquí: …ESQUEMA EXAMEN PMI-RMP

Impresiones tras salir del aula del examen:

  • Me ha parecido un examen más fácil que el examen PMP, pues está más centrado y es más específico.
  • Las preguntas está mucho mejor redactadas que en los simuladores. Esto hace que algunas preguntas puedan responderse “por descarte”.
  • En mi caso en el examen no tuve tiempo para repasar las preguntas que se pueden “marcar” para revisión. El tiempo (tres horas y media) me pareció muy justo, pues el rendimiento es decreciente. Me costó más responder a las últimas 40 preguntas que a las 130 anteriores.
  • Ya no se puede realizar el “volcado de memoria” durante los 15 minutos que dura el tutorial del examen basado en ordenador. Personalmente creo que tampoco valía para mucho.
  • Si no se ha  estado nunca en un examen por ordenador auditado por Prometrics, puede desconcertar el nivel de exigencia del mismo. No se puede llevar al aula de examen ni agua ni snacks. Todo debe guardarse en la taquilla (monedas, llaves, cartera, pañuelos). Las gafas son sometidas a revisión y  se realiza un examen de detección de metales cada vez que se entra en la sala de examen.

Preguntas:

  • Varias preguntas (5 o 6) sobre el Análisis Montecarlo
  • Sobre 3 o 4 preguntas sobre EMV
  • Muchas preguntas situacionales, del tipo ¿Qué harías tú? o del tipo ¿Qué es lo siguiente que se debe hacer?
  • Ninguna pregunta sobre teorías motivacionales (Maslow, McGregor, Vroom, Herzberg…)
  • Bastantes cuestiones sobre gestión y manejo de Stakeholders
  • Bastantes preguntas sobre escoger la herramienta más adecuada para ciertas situaciones.
  • No obsesionarse con los ITTOS (entradas, herramientas, salidas de cada uno de los procesos de gestión de riesgos). No salen tantas preguntas que justifique tener que aprendérselos todos. Solo se deben memorizar los más importantes
  • No observé demasiadas preguntas con “distractores” (datos insertados sin relación con la pregunta).
  • Hay referencias a la agilidad en algunas preguntas
  • Ninguna pregunta sobre:
    • la norma ISO 31000
    •  Heurística
    • Tuckman
    • Estilos de liderazgo
    • Aplicación directa de fórmulas de valor ganado
  • Sobre 5 o 6 preguntas directas sobre respuestas al riesgo
  • Varias cuestiones sobre cuál sería el riesgo más alto, considerando Probabilidad e Impacto

Material de estudio:

  • Libros recomendados:
    • Libro Secretos para Dominar la Gestión de Riesgos en Proyectos de Liliana Buchtik:
      • Idioma español
      • Muy completo. Trata con detalle la parte de las herramientas de cada parte del proceso
      • Muy interesante cuando se inicia el estudio, pues se avanza rápido.
    • Libro Secretos para salvar el PMI-RMP (300 preguntas de examen) de Liliana Buchtik:
      • Idioma español.
      • Son 300 preguntas con sus correspondientes respuestas
      • Muy interesante cuando se inicia el estudio, pues se avanza rápido.
      • Es un material complementario al libro de la misma autora “Secretos para dominar la gestión de proyectos”
    • Libro PMI-RMP Exam Prep Study Guide, de Belinda Freemow:
      • Idioma inglés
      • Muy práctico y sencillo de entender
      • Al final de cada tema hay una serie de preguntas para responder
      • Cuenta con 150 preguntas de examen
    • Apuntes y otro material del preparador Wolf Project:
      • Amplio resumen de los temas.
      • Ahorra mucho tiempo de estudio
    • Libro Risk Management Tricks of the Trade for Project Managers + PMI-RMP Exam Prep Guide de Rita Mulchay:
      • Idioma inglés
      • Es obligatorio leerlo, pero a este libro ya se le nota mucho el paso de los años (fue editado en 2010)
      • Cuenta con un apartado final de 75 preguntas de examen
    • PMBOK Versión 5:
      • Versión Español
      • Descarga gratuita digital siendo socio de PMI
      • Es interesante leerse los siguientes procesos:
        • Riesgos, Stakeholders, Comunicaciones y Adquisiciones
      • Se deben repasar los ITTOs (entradas, herramientas, salidas) de esos procesos
      • El examen se basó en el PMBOK 5, pero ya ha ido publicada la versión 6.
      • Ojo, que la versión 6 difiere de la versión 5 (se ha incorporado un nuevo proceso denominado “implementar la respuesta de los riesgos” y se ha creado una nueva respuesta al riesgo llamada “escalar”, tanto para amenazas como para oportunidades). Se debe averiguar qué versión estará vigente para cuando se planifique el examen.
    • Libro Practice Standard for Project Risk Management, editado por PMI:Idioma inglés
      • Lectura obligatoria
    • Libro Passing the Risk Management Professional (PMI-RMP) Certification Exam the First Time! De Daniel Yeomans:Idioma inglés
      • Sencillo de entender
      • Al final de cada tema hay una serie de preguntas para responder
      • Cuenta con un apartado final de 150 preguntas de examen
  • Simuladores de examen:
    • Es muy importante escoger bien los simuladores, pues existe una gran variedad
    • Existen varios simuladores de preguntas recomendables sobre esta materia:
      • Simulador de Simplilearn. Es gratuito
      • Yo recomiendo seleccionar y comprar dos o tres paquetes de preguntas de la web de Udemi. De pago.
      • Es muy importante responder preguntas de varios simuladores, no solo de uno, pues así se logran entender más planteamientos de las posibles preguntas.

Calendario y preparación:

  • Considero que la preparación de este examen es difícilmente compatible con el desempeño laboral a tiempo completo. Yo he aprovechado la jornada continua del verano para prepararlo.
  • Recomiendo realizar el curso de preparación de 30 o 40 horas en un proveedor de confianza. Es tiempo de estudio ganado.
  • Tiempo de preparación. En un intervalo de un mes y medio o dos meses se puede preparar.
  • Es muy importante saber que este examen actualmente sólamente se administra en inglés, por lo que:
    • Recomiendo estudiar en español al inicio de la preparación (pues se avanza muy rápido)
    • Pero me parece interesante pasar a estudiar en inglés pasada la mitad de la fase de preparación, pues es necesario familiarizarse con los términos en inglés que se encontrarán en el examen final.
  • Como rutina de estudio, es recomendable repasar cada día uno o dos temas y completar el estudio respondiendo una serie de preguntas sobre lo estudiado. Los libros de Fremow, Mulcahy y de Yeomans mencionados permiten hacer eso.
  • Es muy útil días antes del examen real realizar dos exámenes completos de 170 preguntas y hacerlos a la misma hora que el examen que se ha programado en Prometrics (si se hace el examen por ordenador). Para poder presentarte con garantías al examen, es recomendable sacar al menos un 75 /80 % de aciertos.

 

 

Repito. Se avecinan cambios en el examen, tanto por su adecuación al PMBOK versión 6 como por la actualización del Standard for Risk Management. Se debe tener este punto en cuenta a la hora de planificar el examen de certificación.

Y por último, mucho ánimo. Es una materia muy interesante y es un examen más sencillo que el  PMP.

 

 

 

 

 

 

 

 

 

 

TALLER Y CERTIFICACIÓN PMO-CP

Dejar un comentario

TALLER PMO-CP  (CERTIFIED PRACTITIONER)

El pasado día 12 de junio asistí a un taller de metodología PMO-CP que, opcionalmente, permite acceder a la certificación oficial.

En el curso nos encontramos varios profesionales habituales de los eventos relacionados con proyectos que, como me pasó a mí, se sintieron interesados por lo que podía aportarles este curso.

Todos coincidimos en que la formación en materia de Oficina de Gestión de Proyectos (PMO) se da por supuesta a los profesionales que han superado el examen PMP de PMI, pero eso no es cierto. La información que proporciona el PMBOK sobre las PMO se limita a unas pocas páginas de contenido.

La metodología ha sido creada por la empresa PMO GLOBAL ALLIANCE, que cuenta con una comunidad de mas de 5.000 miembros en varios países. Su foco es la creación, desarrollo y gestión de una comunidad global de profesionales que trabajan de forma cotidiana en la gestión de PMOS. Su enfoque está basado en un benchmarking realizado sobre las experiencias de una comunidad internacional, formada por profesionales de la PMO.

Según el folleto del curso, “Este curso tiene como objetivo principal certificar profesionales en la metodología internacional denominada PMO VALUE RING, que se puede utilizar para crear, evaluar y reestructurar una Oficina de Proyectos – PMO, centrándose en la generación de valor para la cartera de proyectos para toda organización tanto para proyectos Waterfall como Agile”. El profesional certificado PMO-CP puede demostrar la alineación con la metodología más importante en el mundo para la gestión estratégica de las PMO, basada en las mejores prácticas y la investigación internacional.

De forma adicional, existe un software opcional, basado en esta metodología, que hace más sencilla su implantación y mantenimiento. Durante el curso se va haciendo referencia a los diferentes pasos en la herramienta, pero se debe destacar que se puede hacer uso de la metodología sin necesidad de adquirir una licencia de uso de la herramienta.

Su mindset (o mentalidad) es la de proponer que la PMO sea vista como un “proveedor de servicios” y como tal, posee sus clientes, los stakeholders, cada uno con necesidades y  expectativas específicas. Atender esas expectativas es la mejor forma de generar valor percibido. La PMO cumplirá este objetivo proporcionando “servicios” (funciones) de la mejor manera posible.

Según esta metodología, existen 8 pasos que es necesario seguir para asegurarse de que una PMO aporta valor:

  1. Definir las funciones de la PMO, de acuerdo con las necesidades de los stakeholders.
  2. Equilibrar las funciones de la PMO. Las funciones que la PMO deberá desempeñar deberán ser elegidas considerando su capacidad de generar valor percibido permanente (corto, medio y largo plazo) en los stakeholders.
  3. Estabilizar los procesos de la PMO. Es esencial describir como será ejecutado cada proceso elegido, pues es la vía más efectiva de asegurarse de que la PMO entrega valor.
  4. Seleccionar indicadores de desempeño, para poder monitorizar la calidad y demostrar que la PMO está generando valor
  5. Evaluar al equipo, asegurarse de que los miembros del equipo de la PMO cuentan con las competencias adecuadas y elaboración de planes de desarrollo
  6. Evaluar la madurez de la PMO y planificar su evolución
  7. Determinar el ROI de la PMO, considerando la realidad de la empresa.
  8. Establecer un panel de control que monitorice ciertos indicadores estratégicos, que determinen si la PMO cumple con lo prometido
PMO Value Ring

De forma paralela, existen varios mitos sobre la gestión de las PMO que consideran que se deben desmontar:

  1. Mito Nº 1: “El primer paso es elegir el tipo ideal de PMO“. Adherirse a un tipo de PMO establecido no va a hacer que la PMO tenga éxito. Lo que realmente importa es que la PMO ofrezca servicios que atiendan las necesidades de sus stakeholders. Las funciones pueden ser estratégicas, de soporte, centro de excelencia o de varios tipos mezclados.
  2. Mito Nº 2: “Proveer una metodología y herramientas para gestionar proyectos es  suficiente para que una PMO sea exitosa“.  Las expectativas diferentes deben ser atendidas por un conjunto de funciones diferentes. Por lo tanto, no hay estándares para las PMOs. Cada una debe proveer una mezcla específica de funciones.
  3. Mito Nº 3: “Primero defina el equipo de la PMO, después qué va hacer la PMO“. Comúnmente, las PMOs son creadas de forma contraria a lo que se recomienda. Primero se establece el equipo de la PMO, a continuación, se define lo que hará la PMO.  Lo recomendable es hacer esto justo al revés.
  4. Mito Nº 4: “El éxito de los proyectos de la organización es la mejor prueba del  éxito de la PMO”.  No siempre el éxito de los proyectos indica el éxito de la PMO
  5. Mito Nº 5: “Las competencias  necesarias para un profesional en PMOs son  las mismas de un director de proyectos.” Todos los asistentes al taller estuvimos de acuerdo en que las competencias no son necesariamente las mismas. Esta metodología propone 10 competencias básicas: Capacidad de influenciar, Capacidad de integración, Gestión de conflictos, Comunicación efectiva, Gestión de proyectos, Gestión de procesos, Proactividad, Relación interpersonal, Enfoque al cliente,  Gestión del conocimiento.
  6. Mito Nº 6: “Una PMO entre más estratégica, más  madura será“. Ser estratégico o operativo no es una señal de madurez, sino una  consecuencia de las necesidades de las partes interesadas.
  7. Mito Nº 7: “Es imposible calcular el retorno financiero de la PMO“. Es obligatorio descubrir el retorno financiero de una PMO, considerando la realidad de la empresa
  8. Mito nº 8: “Monitorizar estratégicamente la PMO es lo mismo que monitorizar el porfolio estratégico de la organización”.  Monitorear el portafolio estratégico de proyectos es una función, no necesariamente un propósito.

 

Es interesante el enfoque práctico de esta metodología, es decir, si los stakeholders no perciben que la PMO les aporta valor, lo más probable es que la PMO acabe siendo cancelada. O peor aun, la PMO puede acabar siendo un “muerto viviente”, que no sabe que ya no está viva.

Enlaces interesantes:

 

CERTIFICACIÓN PMO-CP (CERTIFIED PRACTITIONER)

Realizado el taller formativo, lo siguiente es afrontar el examen de certificación.

El examen se compone de un total de cuarenta preguntas, de las cuales es necesario acertar un 75% de las mismas, es decir, treinta. No se permite la consulta de ningún tipo de material durante el examen. Las preguntas son de tipo test, con cuatro posibles soluciones. Las preguntas más complejas se pueden resolver por descarte.

El examen se realiza a través de la plataforma Moodle de PMOGA eso si, planificado y supervisado on line a través del sistema Proctoru.  Para lo que no conozcan este sistema, es bastante exigente en lo que se refiere a las condiciones en las cuales se desarrolla el examen, para asegurarse de que no se consulta ningún tipo de material durante el examen.

Sin sorpresas, asistiendo al taller de preparación (obligatorio) y estudiando los dieciséis Papers (en inglés), junto con el material complementario que compone el curso, es suficiente para poder aprobar la certificación.

SCRUM LEVEL

Dejar un comentario

Esto se había quedado en el tintero. Hace unos meses realicé un interesante curso de Scrum Level, que merece la pena ser comentado. 

Cuando se desea implantar la agilidad en las empresas, se pueden producir problemas  o conflictos con la “cultura” o las prácticas aceptadas dentro de la propia empresa, pues cada una es diferente del resto.

Scrum Level está orientado a evitar esos conflictos, estableciendo las mejores prácticas que se deben implantar y lo hace realizando un diagnóstico personalizado de lo que se necesita poner en práctica  para hacer que las empresa se aprovechen de los beneficios de los enfoques ágiles, sin romper con todo lo anterior.

¿Cómo se define Scrum Level? Es un modelo de evaluación y mejora de la agilidad de las empresas, tanto a nivel técnico, como de la organización en su conjunto.

Extraido de su web: “Propone un método sistemático con el que analizar y evaluar las dimensiones y aspectos que determinan el nivel de agilidad organizacional. El análisis obtenido con Scrum Level revela las fortalezas y debilidades de los diferentes ejes que define el modelo, y apunta las áreas susceptibles de mejora, así como las actividades o prácticas que pueden reforzarse”

http://scrumlevel.com

Scrum Level nace de la experiencia de un reducido número de profesionales y  busca reducir la variabilidad  típica de las implantaciones y progreso de la agilidad,  a partir de los proyectos desarrollados entre sus clientes.

Para ello Scrum Level analiza indicadores y evidencias deforma separada en dos dimensiones:

DIMENSIONES:

  • Dimensión técnica:  flexibilidad.
  • Dimensión organizativa:  fluidez.

FACTORES ANALIZADOS:

  • Ejes orgánicos.
  • Técnicas y prácticas de trabajo.
  • Capacitación técnica de las personas.

Las organizaciones que desean implantar o mejorar un entorno de trabajo ágil, necesitan una guía y criterios de referencia para identificar y analizar las áreas de mejora.

Scrum Level cubre este objetivo, definiendo una guía de referencia y apoyo para mejorar la agilidad de las organizaciones

En curso  se aprende el uso del modelo de evaluación y mejora Scrum Level, y se dispone de la guía, herramientas de protocolo y competencia necesarios para llevar a cabo procesos de evaluación con los que identificar las fortalezas y áreas de mejora en la agilidad organizativa de equipos y empresas. Es un curso eminentemente práctico.

Respecto al modelo de licenciamiento, derecho de uso del material y de la certificación, se distinguen tres niveles:

  1. Consultor independiente:
    El modelo y los materiales de Scrum Level se ofrecen con derechos de uso liberados (Creative Commons By). Pueden emplearse libremente en actividades profesionales de mejora o evaluación, con o sin ánimo de lucro.
  2. Consultor certificado:
    La certificación garantiza el conocimiento profesional del modelo Scrum Level adecuado para el desempeño en actividades de mejora o evaluación. Para conseguir la certificación es necesario aprobar el examen oficial de consultor Scrum Level que forma parte de los cursos profesionales de Scrum Manager®.
  3. Evaluador certificado:
    Profesional autorizado por ScrumLevel para realizar evaluaciones oficiales como evaluador responsable.
    Para ser evaluador certificado es necesario ser consultor certificado y acreditar los requisitos profesionales necesarios:

    1. Experiencia profesional mínima de 5 años en asesoría o gestión en organizaciones TIC.
    2. Experiencia profesional mínima de 3 años en asesoría o gestión en organizaciones TIC, y experiencia previa en evaluaciones Scrum Level independientes

Por otra parte, señalar que para los que hayáis realizado el curso de Scrum Manager, que la realización y superación del curso de certificado en  Scrum Level en un centro asociado os proporciona 65 PDUS válidos para el mantenimiento de la certificación  Scrum Manager. Recordad que Scrum Manager distingue entre Acreditación (examen aprobado con nota mínima de 8, pero no realizado ante centro asociado) y Certificación (examen aprobado con nota mínima de 8 y realizado en un centro homologado).

Usar técnicas y prácticas ágiles en un marco de producción sin una cultura ágil, no es propiamente agilidad, sino ingeniería concurrente (solapamiento de fases) con ciclo de vida incremental, o lo que se podría llamar “agilidad técnica”

 

Referencias:

CERTIFICACION PRINCE2 PRACTITIONER

2 comentarios

Después de haber realizado la certificación de Scrum Level y para cerrar el círculo de las metodologías, me propuse conocer lo que me podía aportar Prince2 a la gestión de proyectos.

Para superar los exámenes de Prince2 no es obligatorio pasar un curso en un preparador oficial (como se exige en el PMP) pero es muy recomendable realizarlo. El pasado octubre, junto con un compañero de trabajo, me matriculé en un curso de preparación de la certificación Prince2. El examen de certificación se planificó para enero de 2017.

¿Que es Prince2?. La web de QRP lo define así:  “Es un método estructurado de gestión de proyectos. Es una aproximación a las “buenas prácticas” para la gestión de todo tipo de proyectos que se ha convertido en el estándar de facto para la organización, gestión y control de proyectos El método divide los proyectos en fases manejables permitiendo el control eficiente de los recursos y el control periódico de su evolución. PRINCE2 está “basado en los productos”, es decir, los planes del proyecto se centran en obtener resultados concretos, y no sólo en la planificación de las actividades que se llevan a cabo; PRINCE2 proporciona un lenguaje común en los proyectos.”

Más que un conjunto de buenas practicas (como es el PMBOK de PMI), PRINCE2 propone una metodología de gestión de proyectos, es decir, cubre todas las temáticas y propone cómo llevarlas a la práctica.

PRINCE2 es el estándar de facto para la gestión de proyectos en varios países, empresas privadas y organizaciones.

Existen dos niveles de certificación:

  • Foundation: certifica el conocimiento de la terminología y metodología de gestión de proyectos con PRINCE2
  • Practitioner: certifica la capacidad para gestionar proyectos según la metodología PRINCE2. Se necesita aprobar el nivel Foundation para presentarse a este nivel.

Un apunte, si ya dispones de uno de estos  certificados: CAPM, PMP o IPMA no es necesario examinarse previamente del nivel  Foundation, pues se convalida automáticamente.

Adicionalmente, Prince2 también dispone de una solución enfocada al mundo Agile. Esta certificación proporciona la guía para adaptar PRINCE2 en un contexto ágil e incluye:

  • Cómo adaptar el conjunto integrado de principios, temáticas y procesos de PRINCE2
  • Cómo crear los productos de gestión de PRINCE2
  • Cómo mapear los roles ágiles a la estructura de equipo de gestión de PRINCE2
  • Cómo incorporar los comportamientos, conceptos y técnicas ágiles fundamentales dentro de PRINCE2

Eso si, un aviso a navegantes, durante el año 2017 se ha producido una gran actualización de Prince2, tanto a nivel de guía como de exámenes. Una de las consecuencias de este cambio es que los exámenes no van a  estar disponibles en español como hasta ahora.

No es mi intención hablar en detalle de la metodología, pues existen otros blogs donde detallan este punto, solo destacar que Prince2 se basa en:

  • Siete temáticas:
    1. Caso de negocio: manera en que se desarrolla una idea hasta convertirse en un proyecto viable para la organización.
    2. Organización: puestos, funciones y responsabilidades del equipo encargado de ejecutar el proyecto.
    3. Calidad: Se ocupa de desarrollar la comprensión de los interesados respecto a los atributos de calidad de los productos a entregar.
    4. Planes: Describe los pasos requeridos para desarrollar los planes establecidos y las técnicas de PRINCE2 que se deben aplicar.
    5. Riesgo: gestión de las incertidumbres en sus planes.
    6. Cambio: cómo se evalúa y actúa para incorporar los posibles cambios a la línea base del proyecto
    7. Progreso: proceso de toma de decisiones para aprobar planes, seguimiento del avance real y el manejo de excepciones cuando los planes no se cumplen.
  • Siete procesos:

    1. Puesta en Marcha de un Proyecto.
    2. Dirección del Proyecto.
    3. Inicio del Proyecto.
    4. Control de Fase.
    5. Gestión de la Entrega de Productos.
    6. Gestión de los Límites de Fase
    7. Cierre de Proyecto
  • Siete  principios (que se deben seguir obligatoriamente):
    1. Justificación comercial continua
    2. Aprender de la experiencia
    3. Roles y Responsabilidades definidos
    4. Gestión por Fases
    5. Gestión por excepción
    6. Orientación a productos
    7. Adaptación al entorno del proyecto (un proyecto de PRINCE2 se debe adaptar al tamaño, el entorno, la complejidad, la importancia, la capacidad y el riesgo del proyecto).

Ahora vamos a hablar de los exámenes de las dos certificaciones:

  • El examen Foundation:
    • Se puede hacer on line.
    • Duración: una hora
    • Nivel de dificultad: es bastante sencillo
    • Material permitido: ninguno
    • Son 75 preguntas. Se necesitan 35 aciertos para aprobar
    • Renovación: no es necesario
  • El examen Practitioner:
    • Duración: son dos horas y media. Os aseguro que no sobra ni un minuto de tiempo. Se debe gestionar bien para evitar sorpresas desagradables.
    • ¿Su nivel de dificultad? Pues depende, si se compara con el de PMP  el Practitioner es mucho más sencillo pero exige dedicación y conocer los tipos de preguntas de las que se compone el examen.
    • Se basa en un escenario. Por eso es muy interesante poder realizar el exámen en papel, en lugar de escoger hacerlo on line, pues es muy recomendable tener a la vista la información de cada pregunta
    • Tipos de pregunta:
      • Con una respuesta correcta
      • Con múltiples respuesta y se deben escoger dos.
    • Material permitido: el manual original y oficial “Éxito en la gestión de proyectos con Prince2“
    • Son 80 preguntas. Se deben conseguir 44 aciertos
    • Renovación: cada 5 años
    • En 48 horas ya se proporciona la nota del examen

En este sitio web puedes encontrar unos excelentes Consejos para aprobar

Diploma Prince2
Diploma Prince2

Lo que me ha gustado de Prince2:

  • El enfoque basado en el Business Case. Un proyecto debe tener una justificación comercial continua.  Esto significa que la razón para iniciar el proyecto debe tener sentido desde un punto de vista empresarial y debe haber un claro retorno de la inversión. El “Business Case” se debe revisar periódicamente durante toda la vida del proyecto para comprobar su continua justificación para el negocio Si la justificación desaparece,  el proyecto debe cerrarse.
  • La gestión por excepción. Las tolerancias a los cambios están perfectamente definidas. Esto proporciona cierta independencia al director de proyectos para tomar decisiones, siempre que se esté dentro de las tolerancias establecidas para el proyecto.
  • Al ser una metodología (y no un conjunto de buenas prácticas como el PMBOK) si no se dispone de experiencia en proyectos, aporta una guía  y un marco para gestionar el proyecto, que es aplicable desde el primer momento. Esto es una gran ayuda para los que se inician en la gestión de proyectos, pues Price2 les va a guiar punto por punto desde el principio hasta el fin del proyecto.

Lo que veo mejorable:

  • El responsable del proyecto  y del éxito del mismo  es la Junta del Proyecto (Directivo, Usuario Principal y Proveedor Principal) . El Project Manager es responsable de dirigir el día a día del proyecto. Puede parecer un “secretario de lujo” de la Junta de Proyecto.
  • No incluye la administración o desarrollo de los Requerimientos. Estarían incluidos  dentro de la temática de “Calidad”.
  • Da por sentado que se conocen conceptos que requieren tener conocimientos previos en materia de proyectos. Por ejemplo, el WBS (Work Breakdown Structure) o el  PBS (Product Breakdown Structure)

Recursos:

 

 

¿QUÉ METODOLOGÍA ELEGIR PARA GESTIONAR UN PROYECTO?

Dejar un comentario

En fin… ¿Qué metodología es más adecuada para gestionar un proyecto?, ¿Predictiva, iterativa, incremental o ágil?

La respuesta más adecuada es que ninguna es mejor que otra. Dependerá del tipo de proyecto.

El cuestionario del interesante libro “Software Engineering” de Ian Sommerville, para valorar cuándo ser ágil o cuando usar métodos formales decía que si respondes a estas cuestiones en su mayoría NO,  conviene que la  metodología sea iterativa o ágil y si se responde SÍ, entonces conviene que sea predictiva o formal:

  • ¿Se requiere una especificación?
  • ¿Los clientes son inaccesibles?project-managemet
  • ¿El sistema a construir es muy grande?
  • ¿El sistema es muy complejo?
  • ¿Se trata de un producto con mucho tiempo de vida previsto?
  • ¿Tienes herramientas de desarrollo limitadas?
  • ¿El equipo está distribuido?
  • ¿El equipo viene de una cultura de la documentación?
  • ¿El equipo tiene conocimientos técnicos limitados?
  • ¿El sistema a construir está sometido a regulación legal?

Antes de escoger una metodología, es importante tener en cuenta  el ciclo de vida por el cual va a transcurrir  el proyecto:

  1. Predictivo o en cascada. Aquí el proyecto discurriría por fases secuenciales (unas tareas detrás de otras). Los requerimientos son fijados al inicio. Su objetivo fundamental es controlar el coste.
  2. Iterativo. Los requerimientos son dinámicos y las tareas se repiten hasta la corrección de los prototipos. Mejorar el producto a través de sucesivos prototipos o pruebas de concepto. Su objetivo es la corrección de lo entregado.
  3. Incremental. El proyecto se basará en varios desarrollos incrementales y solo se planificaría una fase, pues las siguientes se van definiendo conforme avanzan los trabajos de la fase actual. El cliente desea frecuentes entregas de pequeños entregables del producto. Su objetivo es la velocidad de entrega.
  4. Ágiles. Son proyectos donde no se conoce el alcance y se desarrollan pequeñas porciones del proyecto marcadas por los sprints, al final de las cuales el cliente puede ver lo que se ha desarrollado. Es ideal si no se conocen los requerimientos o si se sospecha que los mismos pueden cambiar, puesto que en cada sprint se descubren requerimientos ocultos o mal interpretados. Su objetivo es entregar valor de forma frecuente a los clientes. Para estos proyectos lo ideal es usar una metodología del tipo Scrum, kanban o XP.
Características de los ciclos de vida (Fuente PMBOK 6 Ed.)

Para los proyectos que se adivinan predictivos lo mejor es usar tanto la metodología del PMBOK como Prince2.

El PMBOK no está en absoluto en contra de desarrollos incrementales, es más, el PMBOK asume que en muchas ocasiones durante la gestión del proyecto no está disponible toda la información. Es lo que se llama “Rolling Wave Planning“, es decir, es planificar en detalle lo que se va a realizar en el corto plazo. También se la conoce por  “Planificación continua con incremento de detalle”.

En el excelente Blog de Sinnaps comentan con buen criterio que las metodologías ágiles potencian conversaciones directas frente a la comunicación basada en documentación escrita, los equipos de trabajo se auto-gestionan, dando libertad a los roles, según las necesidades de un proyecto que está en continua evolución. Además, su empleo supuso la optimización de sus recursos, al clasificar las tareas que tienen un mayor impacto en el proyecto, estableciendo un sistema de prioridades.

Sin embargo, este tipo de metodologías y herramientas de gestión no son aconsejables para proyectos en los que se precisa de una constante toma de decisiones técnicas por parte del Project Manager, donde la gestión de la incertidumbre ha de ser clave para enfrentarse a contratiempos de proyectos largos. Por eso, no todas las empresas han recibido con el mismo entusiasmo la llegada de metodologías ágiles. Y es que su uso requiere una fuerte dependencia y centralización del control continuo y toma de decisiones de la persona responsable del proyecto. Además, podría existir una falta de documentación importante del propio proyecto y las soluciones para etapas largas suelen ser, en la mayoría de las ocasiones, inadecuadas.

En este enlace, recomiendan hacerse cuatro preguntas antes de seleccionar una metodología para gestionar un proyecto

Las 4 preguntas antes de seleccionar una metodología:

  • …¿Qué resultados debería obtener al finalizar el proyecto? Ejercicio de objetivos.
  • …¿Qué tipo de metodologías nos ha dado mejores resultados? Ejercicio de análisis.
  • …¿Cómo funciona mejor nuestro equipo de trabajo? Ejercicio de análisis.
  • ….¿Qué metodología combina mejor con las dos preguntas anteriores? Ejercicio de estudio e identificación.

Muy interesante es la visión de Juan Palacio, en su libro gratuito descargable aquí: Flexibilidad con Scrum. En el mismo se comenta que la gestión predictiva equivale a la persona que decide irse de viaje y planifica con exactitud que ciudades, vuelos y hoteles va a visitar o reservar. Por otra parte, la gestión ágil corresponde a project-manager-1una persona que sabe que quiere conocer un país y que empezará la visita por la capital, pero deja la decisión de que ruta seguir para cuando haya llegado.

No se trata de elegir un modelo como el mejor, simplemente habrá casos en los que convendrá una gestión predictiva (por .ejemplo la construcción de un puente) y otros en los que la opción ágil puede ser más beneficiosa (p.ej. desarrollo de software). El software es mucho más maleable, adaptable y fácil de reconstruir. Sin embargo, en la construcción de un puente no se pueden destruir parte de los cimientos para volver a rehacer con un diseño diferente a mitad de proyecto.

Otro aspecto importante es identificar donde se encuentra el valor en el sector donde va a tener lugar el proyecto. Podemos considerar 3 elementos fundamentales entre los cuales se reparte el valor:

  • Personas
  • Tecnología
  • Procesos

La gestión predictiva tiende a valorar más los procesos (p.ej. planes preestablecidos, modelos de comunicación y autorización estrictos, etc.), mientras que la gestión ágil da una mayor importancia a las personas (p.ej. dando libertad, confianza y autonomía al equipo, potenciando la motivación, participación y creatividad, etc.)

Es importante remarcar que una práctica que ha cobrado mucha fuerza por los buenos resultados que proporciona es la de utilizar un sistema mixto  gestionando el proyecto siguiendo las directrices del PMBOK pero usar otra metodología para gestionar partes específicas del proyecto. Un buen ejemplo de esto sería utilizar una metodología ágil exclusivamente para la parte correspondiente al desarrollo de software (si lo hubiere).

Además, PMBOK llega donde Agile no llega (ni quiere llegar) como es la gestión de las diez áreas de conocimiento  definidas para cada proyecto (interesados, integración , tiempo, costes, adquisiciones, calidad, etc).

De esta forma, el proyecto  tiene un Project Manager que se ocupa de la gestión de todo el proyecto y un Scrum Master y un Product Owner que trabajan exclusivamente la parte de desarrollo de software a través de ciertas iteraciones acordadas.

Las ventajas de este sistema mixto son grandes, como es el poder controlar tanto el trabajo interno como el trabajo que está siendo gestionado externamente (por ejemplo, por proveedores). Además, se trata de evitar uno de los grandes riesgos de las metodologías ágiles como es la escalabilidad.

Resumiendo, no es necesario utilizar una sola aproximación para todo el proyecto. Los proyectos frecuentemente pueden combinar elementos de diferentes ciclos de vida para obtener sus ventajas. Una combinación de las aproximaciones predictivas, iterativas, incrementales o ágiles es lo que se llama un “sistema híbrido“.

Lo que nadie debería hacer es utilizar exclusivamente una sola metodología para gestionar todos sus proyectos. Lo más adecuado es estudiar primero las características inherentes al futuro proyecto para encontrar el ciclo de vida que mejor encaje.

CERTIFICACIÓN SCRUM MANAGER

Dejar un comentario

Después de leerme un par de libros sobre Scrum decidí que era momento para tomar una certificación. logo

Después de buscar un poco por Internet, comprobé que hay tres certificaciones que sobresalen del resto:

  • Scrum Alliance
  • Scrum.org
  • Scrum Manager

El modelo de Scrum Alliance es con diferencia el más conocido (fue creado por los fundadores de Scrum) se basa en cursos de dos jornadas presenciales (que son obligatorias) y un examen muy sencillo que se puede hacer desde casa. Este es uno de los puntos más criticados de este modelo.

De Scrum.org me llamaron la atención varias cosas:

  • Que lo fundó uno de los creadores descontentos de  Scrum Alliance (Ken Schwaber).
  • Que ni siquiera está traducido al español. Este es un punto negativo a tener en cuenta.
  • No es necesario haber tomado ningún curso para poder examinarse de la certificación. Eso sí, tiene fama de tener los exámenes más duros (y en inglés) especialmente PSM II.

Y busqué información sobre Scrum Manager y lo que encontré me hizo decidirme por esta certificación:

  • Tiene una de las comunidades de apoyo más activas de España y Latinoamerica.
  • La diferencia entre Scrum técnico y Scrum avanzado es un enfoque muy interesante.certificacion_scrum_manager
  • Sus cursos oficiales presenciales no son obligatorios. Se puede tomar el examen sin  pasar por ellos.
  • El manual en el que se basa su curso es gratuito y público. Se puede descargar desde aquí en formato Epub y PDF: …Manual SCRUM MANAGER.
  • El enfoque del curso de ampliación llamado  Scrum Level es decir, del “Modelo de Evaluación y Mejora de la Agilidad Organizacional” me parece muy interesante. Es muy difícil tener éxito en un proyecto ágil sin que la empresa esté formada en estas prácticas.
  • Me gustó su declaración de intenciones: “Scrum Manager no forma “gestores técnicos”: gestores conocedores de marcos de Agilidad con la implantación de las correspondientes reglas y técnicas. Scrum Manager forma “gestores expertos” que lejos de radicalizarse en el “agilismo”, amplían su inventario de conocimiento y práctica de gestión con las aportaciones de la Agilidad, facilitando así la creación de su propia síntesis de conocimiento para mejorar la gestión de su entorno“.

Y me puse manos a la obra.

Su formación sigue el esquema de dividir los diplomas en Certificación (si se examina uno en un centro asociado) o Acreditación (si se toma  el examen de la web sin supervisión).

Lo primero es darse de alta en su web. Se debe aprobar la llamada “parte troncal” de la certificación.

Para aprobar la parte “troncal” se puede recurrir a un curso de apoyo de un centro certificado (cuyo coste oscila entre unos 500 €)  o acceder al curso on line (disponible todo el año) en el apartado E-Learning de su web y que cuesta unos módicos 40 € (IVA incl.)

El curso “on line” está formado por doce lecciones, seis prácticas y un examen. Si se aprueba  este examen se obtiene la Acreditación y 150 PDA (puntos de autoridad) similares a los PDU del PMP.

Para obtener la certificación se debe tomar el examen presencialmente en un centro examinador autorizado (que cuesta sobre 180 euros) o hacerlo desde la web pero en un centro que disponga del sistema de  supervisión web. Se debe obtener un 70 % de rescertificado_2_largepuestas válidas para aprobar el examen presencial.

El examen si se prepara bien no es complicado de aprobar. Ayuda mucho la batería de las preguntas de prueba que se pueden comprar  en la propia web de Scrum Manager.

Los 150 PDA (puntos de autoridad)  que se obtienen por haber aprobado la certificación otorgan el nivel de “Experto”. Estos PDA se van perdiendo a razón de un 20% por año. Se pueden incrementar realizando cursos adicionales ( y se puede pasar al nivel “Autoridad” que implica disponer de más de 200 PDA).

 

 

 

MÉTODOS ÁGILES Y SCRUM

2 comentarios

Título original: Métodos ágiles y Scrum mays

Autores: Alonso Álvarez, Rafael de las Heras, Carmen Lasa

Editorial: Anaya Multimedia, año 2012, 350 páginas, 

ISBN: 978-84-415-3104-8

Palabras clave: metodología, proyectos, software, scrum, métodos ágiles

En la empresa en la que trabajo hemos comenzado a gestionar varios proyectos por medio de metodologías ágiles, así que me he comprado este libro para ver de qué va la moda de los métodos ágiles y en concreto de Scrum.

Una peculiaridad de este libro es que el prólogo lo firma Mike Breedle, unos de los firmantes del llamado ” Manifiesto Agil”, del que ya hablaremos. Ademas, para ser prácticos, utilizan la realización de este libro como ejemplo de proyecto realizado en Scrum

Entrando en materia, los autores destacan que el origen de los métodos ágiles se basó en la frustración del mundo informático de poder tener éxito cuando los requerimientos son indefinidos, es decir, en proyectos donde la incertidumbre de lo que se busca es alta, pues si el cliente tiene claros los requisitos entonces es mucho más adecuado optar por una metodología de proyectos clásica (en cascada o waterfall).  El cambio de paradigma que implica es adoptar el enfoque de señalar un presupuesto y una fecha de entrega y que el trabajo sea lo que se pueda hacer aplicando el principio de que el desarrollo será iteractivo.

Srum es solo uno de los muchos métodos ágiles que existen, aunque es sin duda el más popular.

Un resumen rápido del modo en el que se trabaja en Scrum es el siguiente:

  • Ante al solicitud de un proyecto, el Product Owner crea un  equipo, solicita unos recursos y fija los primeros requisitos.
  • Desarrolla el Product Backlog con los trabajos detectados necesarios, que se compone de temas, épicas e historias.
  • Se debe dividir el trabajo en varios Sprints, que se agrupan en Releases o entregas.
  • El equipo de trabajo valora el esfuerzo implicado y traduce las historias en las que se compone el proyecto en unidades menores o tareas.
  • El trabajo se va realizando y se expone en la Daily Meeting.
  • Los impedimentos detectados va a a un Impediment Backlog y el Scruim Master vigila que se resuelvan.
  • El final del Sprint lo señala la Review Meeting
  • En la reunión de Retrospectiva el equipo revisa lo realizado y lo que se ha hecho bien y lo mejorable.
  • Y vuelta a empezar.

Y esto es todo…

Vamos a verlo con un poco más de detalle.

VALORES:

  • Mejora continua
  • Calidad
  • Time Boxing
  • Responsabilidad
  • Multidisciplinar
  • Flexibilidad
  • Ritmo (latido)
  • Compromiso
  • Simplicidad
  • Respeto
  • Coraje
  • Foco
  • Predictibilidad
  • Personas

cambio-de-paradigma2

 

 

 

 

 

 

 

 

ROLES:

  • Product Owner:
    • Es el intermediario entre el cliente y el equipo. Es la voz del cliente.
    • Fija las fechas de entrega y prioriza los distintos requisitos
    • Mantiene la “visión” actualizada del producto o proyecto. La “visión” es un resumen de las metas a medio y largo plazo donde se quiere llegar. es muy importante por ello disponer de un “caso de negocio”. La “visión” del producto implica:
      • Unas características básicas u obligatorias, que el producto debe tener
      • Unas características de rendimiento o lineales
      • Características inesperadas o emocionantes
    • Mantiene al día el Product Backlog. Describe los elementos, con las condiciones de aceptación y priorizadas)
    • Traduce los requisitos de negocio en elementos del Backlog (temas, épicas e historias)
    • Es quien acepta o rechaza las entregas de trabajo
    • Asiste  a la Review y al Planning
    • Es el responsable del éxito no fracaso del proyecto y de su ROI. Controla el presupuesto
    • Gestiona las expectativas del cliente y de los stakeholders
    • Qué no debe ser un PO: Que no tenga poder, que esté  saturado de trabajo.
    • Hay una interesante historia acerca de los roles dentro de Scrum y  de lo que es estar implicado y estar comprometido.  Pues bien , el PO tendría el rol de”cerdo”, pues está totalmente comprometido con  el proyecto
  • Scrum Manager:
    • No es un jefe de proyecto. No tiene autoridad formal ante el equipo.
    • Supervisa todo el proceso. No está subordinado al PO.
    • Es un experto en la metodología Scrum debe enseñar esta metodología a cada integrante implicado en el proyecto, preocupándose de poner la metodologia en practica de modo que se encuentre dentro de la cultura de la organización y así entregue las ventajas previstas, asegurándose de que cada uno siga las Reglas y prácticas de Scrum.
    • Pilota los Sprints.
    • Debe velar por la productividad del equipo.
    • Debe procurar que fluya la comunicación y la colaboración.
    • Analiza la velocidad del equipo y debe buscar la calidad
    • Los roles de Scrum Manager y Product Owner son muy diferentes y es incompatible con que sean la misma persona.
    • Último objetivo: no ser necesario
  • Equipo:
    • El equipo se debe auto-organizar
    • Debe estar comprometido con el proyecto
    • Su responsabilidad es entregar el producto, en base  a lo que existe en el Product Backlog
    • Los equipos auto-suficientes, auto-organizados y funcionales, tienen la responsabilidad, en cada iteración, de transformar el Product Backlog en un incremento en la funcionalidad del producto y planificar su propio trabajo para lograrlo.
    • Debería de eligir al Scrum Master, porque es su representante. debe confiar en él.
    • Debería de tener dedicación suficiente y continuada
  • Coach:
    • No es una figura obligatoria
    • Es un formador y mentor. Elabora las guías de actuación.

EL PROCESO:

  • Lo primero de todo, el Sprint Cero: 
    • Es responsabilidad del Product Owner
    • El él se define la misión, herramientas y el equipo
    • El objetivo es definir las condiciones y el contenido del trabajo
    • De esta forma se establece la primera versión del Producto Backlog
    • También se elige la duración de cada sprint y el calendario de releases o entregas
  • Sprints:
    • El Sprint Backlog contiene aquello que se llevará a cabo en cada sprint.
    • Hay tres etapas:
      • Sprint Planning, donde se realizan los criterios de aceptacion y la valoración de los trabajos
      • Daily Meetings. Reunión diaria donde se revisa de forma rápida qué se hizo, que se va a hacer y los problemas encontrados
      • Review.
    • Retrospectiva. Los resultados se valoran aquí.

scrum de un vistazo

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ENTIDADES:

  • Tareas
  • Historias de usuario.
  • Épicas. Son agrupaciones de historias

ARTEFACTOS:

  • Product Backlog:
    • Es la lista de requerimientos. Los requisitos del sistema o del producto desarrollado se enumeran en el Product Backlog. Es responsabilidad del  PO.
    • No contiene todos los requisitos. Cualquiera puede crear requisitos, es si, requieren de la aprobación del PO. El Backlog es dinámico
    • Tipos:
      • Funcionales. Son las Historias de Usuario.
      • No funcionales. Son las cualidades que debe tener el producto.
    • El nivel de detalle debe ser alto para los requisitos prioritarios y no tanto para el resto.
    • Estructuración:
      • Temas
      • Épicasscrum_2-4_week
      • Historias de Usuario
      • Tareas
    • Características de un buen Product Backlog:
      • Card. Deben caber en una tarjeta
      • Conversation. Deben ser resultado de conversaciones
      • Confirmation. Deben ser fácilmente confirmables
      • Con historias de usuario bien definidas
    • El mejor producto Backlog debe ser DEEP: Detallado, Emergente, Estimado, Priorizado
    • Es una lista ordenada por prioridad, esta tarea  de priorización es del PO, pero el equipo le debe ayudar.
    • Técnicas de priorización del Product Backlog:
      • Priority Poker
      • Moscow (Must, Shoul, Could, Won’t)
      • Kano
      • Criba de temas
      • Puntuación de elementos
      • Posibles problemas del Product Backlog:
        • Es muy grande y detallado. Encubre una especificación de requisitos encubierta. En este caso no se debería de  trabajar con Scrum
        • Historias de usuario siamesas. Encubre un problema con las dependencias. Se debería de dividir en partes más pequeñas y hacer historias de usuario conjuntas.
        • No se cierran las Historias de Usuario. Encubre un problema con las tres C’s: Card, Conversation, ConfirmationExample_Sprint_Task_Board
        • Infección Operativa. Si se dice cómo hay que hacer las cosas y no lo que hay que hacer. Se deben eliminar del PB las tareas operativas
        • Plaga de requisitos. Es síntoma de que el PB se está usando como una lista de peticiones.
        • No hay requisitos no funcionales. El PB no está completamente definido. Solución: prestar atención tanto a las Historias de Usuario como a los requisitos no funcionales
        • Inmunización tardía. Se deben priorizar todos los elementos sobre los que se tengan incertidumbres para poder trabajar sobre ellos. Si esto nop se hace pronto, luego será un problema
        • Muerte dulce por contrato. Si el PB funciona como un contrato con el cliente. El PB no es un acuerdo formal con el cliente.
        • No se debe consentir que el PO delegue la gestión del Product Backlog  en el Scrum Master o en otra persona
  • Sprint Planning:
    • Los sprints son fijados en el Sprint 0. En el Sprint Planning el equipo junto con el PO y el SM planifican los sprints.
    • Cada Sprint se divide en:
      • Planificación del contenido del sprint
      • Desarrollo del trabajo
      • Revisión de los resultados
    • Se deben establecer los límites temporales adecuados (time boxing)
    • Se debe garantizar que el objetivo, mecánica y resultados sean conocidos
  • Sprint Backlog:
    • Son los trabajos a realizar durante un determinado Sprint
    • Es propiedad del equipo, que es quien lo gestiona y actualiza.
    • Su contenido es mucho más detallado y debe de disponer de una definición de lo que se debe alcanzar para poder saber cuando se ha alcanzado el resultado
    • Dimensiones:
    • Prioridad
    • Detalle
    • Estado.  Será pendiente, en curso, terminado, impedida (se documenta y se asigna)
    • El Tablero de Tareas permite visualizar cómo va el sprint
  • Impediment backlog:
    • Es una lista de incidencias que tienen que ser resueltas por el equipo y que el Scrum Master debe gestionar y asignar al alguien para que trabaje en ellas, y que será revisada en la reunión Scrum diaria
  • Burndown Chart.
    • Mide la evolución del trabajo. Lo mantiene el Scrum Master

MECÁNICA DE TRABAJO:

  • El PO lee la primera historia de usuario junto con su criterio de aceptación. los miembros del equipo le asignan “Story points” y se suman hasta que alcancen la velocidad media del equipo (si se sabe). Estas historias deben ser divididas en tareas.
  • El compromiso del equipo es muy importante. Por eso no se aceptan presiones del PO. La calidad debe ser el criterio que debe primar
  • La cantidad de historia de usuario cerradas por el equipo según el Product Owner es el valor de la velocidad real de ese equipo
    • el valor de la complejidad, dificultad o cantidad de trabajo se mide en story points
    • También puede medirse la velocidad por días ideales que se requerirían para hacer esas historias.
    • O también se podría poner un porcentaje, un focus factor.
  • La estimación es una acción colectiva. Puede usarse el Planning Poker
  • Si la estimación coincide se acepta, si no, se discute sobre ello.
  • Sumando todos los story points se obtiene la velocidad estimada de la iteración.
  • El seguimiento del cumplimiento se realiza a través de la  Burndown Chart

PILOTANDO EL SPRINT:

El Scrum Master:

  • No tiene poder real
  • No es el jefe del proyecto
  • Es un facilitador
  • No está subordinado al Product Owner
  • No persigue a los demás
  • Cometido: velar por el seguimiento de los principios del Scrum
  • Cómo lo hace:
    • Velando por la productividad del equipo
    • Procurando que fluya la comunicación y la colaboración
    • Responasble de introducir y fomentar la prácticas ágiles
    • Supervisa el backlog
    • Analiza la velocidad
    • Es el intermediario entre el mundo exterior y el equipo de trabajo
    • Es responsable de la formación del equipo
  • Muy importante: es incompatible que una sola persona sea el PO y el SC
  • Objetivo último: no ser necesario

Planificación detallada:

  • Objetivo: pasar las historias de usuario a unidades más manejables, como son la tareas
  • En esta tarea no se necesita al PO
  • La tarea es una descripción simple de lo que se va a hacer. No es validable

Mantenimiento del backlog, el grooming:

  • Es muy recomendable hacerlo mucho antes de cada planificación del Sprint Backlog
  • El PO revisa el product Backlog para depurarlo.
  • Es un trabajko contínuo y puede asistir todo el equipo.

 DESARROLLO DEL SPRINT:

Duración de los sprints. es mejor que sean cortos al inicio o en actividades poco definidas o si el equipo es inmaduro

Frecuencia de los releases: es responsabilidad del PO

Aspectos del sprint: estabilidad, obtención de resultados, mejora continua, anticipación

Quien lo lleva a cabo: el equipo de trabajo:

  • Características: diversificado, autónomo, auto organizado, responsable, sin jerarquias o nivelss, estable y dedicado
  • Responsabilidades:
    • Realizar el trabajo del proyecto
    • Identificar formas de mejorar su productividad, junto con el SC
    • Hacer la estimación de los elementos del backlog
    • Dividir las historias en tareas
    • Comprometerse a realizar una lista de historias en cada sprint
  • Dimensión del equipo: sobre 4 a 10 miembros
  • Es muy recomendable la proximidad física

La Daily Meeting:

  • Lo realizan el equipo y el SC, que no la dirige.
  • El PO puede asistir o no.
  • Contenido:
    • Qué se ha hecho
    • Qué se hará
    • Impedimentos

Backlog de impedimentos:

  • Recoge todo lo que impide alcanzar los oobjetivos
  • Se recogen los impedimentos, se describen y se asignan a un responsable
  • Es gestionado por el SC
  • Deben priorizarse

Sprint Review:

  • También llamado Customer Sprint Review
  • Se revisa qué se ha hecho y como se ha hecho
  • Finalidad:
    • Recoger comentarios
    • Recoger la aceptación de las tareas seleccionadas
    • Analizar si se necesitan mejoras en el trabajo realizado o si se precisan nuevos items
    • Pueden acudir personas de fuera del equipo
  • Posibles problemas:
    • Cambiar la fecha de la reunión frecuentemente
    • Que sea una presentación d eresultados
    • Que se trabaje solo para la sprint review
    • Foco en los items del backlog y no en los objetivos
    • Desviación del propósito de la reunión por los asistentes
    • Convertir la review en una reunión de aprobación de requisitos
  • La mejor práctica:
    • Establecer normas y reglas.
    • Repasar los objetivos
    • Recapitulación del PO sobre lo finalizado y no finalizado
    • Revisión por el equipo de estadisticas y métricas

La retrospectiva:

  • Objetivo: mejorar la forma de trabajar de forma más efectiva
  • Debe concluir con las acciones de mejora que deben implementarse
  • Cuando: al final de un sprint, después de un release y al final del proyecto
  • Etapas: que se hizo bien, que se debe mejorar, que se vaa hacer en la nueva iteración
  • Consejo: se debe ser positivo y debe haber un moderador (el SM)

Los Scrum Buts:

  • Son malas prácticas. Se debe diferenciar entre Scrum Ands, que son modificaciones positivas, y Scrum Bad, que son modificaciones negativas
  • Los Scrum Buts exponen una disfuncionalidad que hay que solucionar. La culpa no es de Scrum.
  • Top 10 de Scrum Buts:
    1. No hacemos reuniones de fin de sprint
    2. No se eligen voluntariamente las tareas. Ojo esto es micro gestión
    3. No hacemos mejoras o corrección de problemas porque hay demasiadas funcionalidades que implementar.  A esto se le llama la Death March
    4. No hacemos retrospectivas. Esto puede ser un síntoma de que hay conflictos internos en el grupo
    5. No hacemos reuniones diarias ya que nos las necesitamos
    6. El Scrum Master y el Product Owner son la misma persona. Ojo, son roles que consumen mucho tiempo y que son incompatibles porque sus atribuciones pueden entrar en conflicto
    7. Usamos Scrum pero no hacemos el diseño, la implementación y las pruebas de cada historia de usuario en el mismo sprint, porque no os da tiempo a llevar a cabo todas estas tareas en el mismo sprint y las hacemos en sprints consecutivos. esto puede tener dos causas: el equipo no está estimando bien las historias de usuario y el product backlog no está suficientemente trabajado
    8. No se hacen iteraciones cortas porque todo está claro y las hacemos cada 3 meses. Entonces, ¿Por qué se usa Scrum?. Puede ocultar disfuncionalidades
    9. No hacemos reuniones diarias porque no está el Scrum Master. Ojo, esto no es un reporte
    10. Nosotros no lo llamamos Srum pero ya estabamos haciendo todas esas cosas.

¿Cómo detectar Scrum Buts?. Con el método de los 5 porqués (Un ejemplo. ¿Por qué no asiste el SM al Daily Meeting del proyecto?–> Porque está muy ocupado. ¿Por qué está tan ocupado? —> Porque gestiona muchos proyectos— > ¿Por qué gestiona muchos proyectos?—> Porque no hay más SC en toda la empresa….)

En fin. la teoría del método Scrum es muy sencilla. Pero hacerlo bien es muy difícil.

NORMA ISO 21500 SOBRE GESTIÓN Y DIRECCIÓN DE PROYECTOS

Dejar un comentario

Llegó a mi poder información acerca de la norna ISO 21500 sobre Gestión y Dirección de Proyectos y me pareció interesante profundizar en la misma.

Objeto y campo de aplicación de esta norma:

  • Describir conceptos y procesos que se consideran que forman parte de las buenas prácticas en dirección y gestión de proyectos.
  • Ayudar a las organizaciones de cualquier sector económico, que tengan que desarrollar proyectos de cualquier tamaño, a alcanzar sus objetivos de negocio.
  • Contribuir a un correcto desarrollo de los proyectos, mejora en su calidad y en el cumplimiento de plazos y costes

 

La norma va dirigida a:iso215001

  • Alta dirección y patrocinadores de proyectos para ayudar a dar apoyo y orientación a sus directores de proyecto, equipos de dirección de proyectos y equipos de proyecto.
  • Directores de proyecto, equipos de dirección de proyectos y equipos de proyecto ya que tendrán una base común para poder comparar sus normas y prácticas de proyectos con las de otros.
  • Redactores de normas, como base para el desarrollo de normas sobre gestión de proyectos, de modo que sean consistentes unas con otras.

Para su elaboración se tuvieron en cuenta los siguientes estandares:

  • PMBOK. Project Management Body of Knowledge
  • ICB. International Competence Baseline
  • PRINCE2. Project in Controlled Environments5affd11ab6
  • P2M. Project and Program Management for Enterprise Innovation
  • BS 6079 partes 1 a 4. Guide to Project Management
  • DIN 69901 partes 1 a 5. Project Management. Project Management Systems
  • ISO 10006. Quality Management Systems. Guideline for Quality Management in Project
  • AS 4915. Project Management. General Conditions

Y manos a la obra, me matriculé en un curso de Auditor Interno de ISO 21500 sobre Dirección y Gestión de Proyectos de una conocida empresa del sector.

Según se comenta en la web del curso “La auditoria de gestión de proyectos es una herramienta de gestión empleada por las organizaciones para evaluar la eficacia de su sistema de gestión de proyectos conforme a las directrices establecidas por la Norma ISO 21500:2013. Todo ello con el objetivo de establecer y mejorar sus políticas, objetivos y procesos, así como velar por una adecuada aplicación de los métodos, herramientas, técnicas y competencias para una eficiente dirección y gestión de los proyectos que acometen las organizaciones. Así pues, las auditorías del sistema de gestión de proyectos ofrecen a las organizaciones confianza sobre la eficacia de su sistema de gestión y su capacidad para cumplir los requisitos de las partes interesadas o stakeholders. Igualmente, las organizaciones pueden acceder a la obtención de certificados de gestión de proyectos a través de un proceso de auditoria, el cual debe ser llevado a cabo por una entidad de certificación.”

Este curso se divide en dos asignaturas bien diferenciadas:

  • Metodología para la Dirección y Gestión de Proyectos Basada en ISO 21500:
    • Esta parte busca que el alumno conozca el sistema de dirección de proyectos.
    • Si se ha aprobado alguna certificación en materia de proyectos, (PMP o Prince 2) esta parte es muy sencilla.
  • Auditoria y Certificación de Sistemas de Gestión y Dirección de Proyectos según ISO 21500. Esta asignatura se orienta a:
    • Aplicar los conocimientos sobre auditorías de proyectos en cualquier organización para verificar el cumplimiento de su Sistema de Gestión.
    • Poder asumir responsabilidades en cualquier etapa del proceso de auditoría.
    • Conocer las funciones y competencias que debe tener un auditor tanto en auditorías internas como en auditorías de certificación.
    • Conocer el proceso de certificación en una organización.
    • Reconocer las características y problemas más habituales en la consecución de la certificación de gestión de proyectos.

Este curso permite disponer del Certificado de Auditor Interno de Sistemas de Gestión de Proyectos ISO 21500 (con examen final)

Para la empresa esta norma puede tener un  gran valor añadido. pues ya es posible que empresas individuales se certifiquen en gestión de proyectos. Puede ser un potente argumento de venta. La primera empresa en certificarse  fue Sach Consultores. Más abajo disponéis de una entrevista a la General Manager de Sach Consultores.

Enlaces interesantes:

CERTIFICACIÓN PMP®

Antecedentes:

Allá por el año 2014 y después de haber pasado por un período de “Coaching” en materia de proyectos a PMPcargo de una consultora, en mi empresa estábamos pensando en la posibilidad de seguir mejorando en nuestro desempeño en materia de proyectos.

Y nos pareció una buena idea preparar la certificación PMP, es decir, la certificación Project Management Professional  que expide el Project Mangement Institute (PMI)

Dicho y hecho. A mi me tocó romper el hielo y ser el primero en preparar la certificación.

Requerimientos para poder examinarse:

Habrá que acreditar los siguientes puntos:

  • Justificar el nivel de estudios, pues la horas exigidas de experiencia profesional dependen del nivel de estudios.
  • 35 h de formación en Dirección de Proyectos.
  • 4.500 h de experiencia profesional en gestión de proyectos si tienes una diplomatura o superior / 7.500 horas en caso contrario.
  • Cumplimiento del Código de Conducta Profesional del Director de Proyectos.

Lo primero que hacía falta: tomar un curso de 35 horas de duración a cargo de un preparador homologado por el PMI para dar ese cursillo.  Buscamos  y encontramos un preparador cerca de la empresa y con buenas referencias de aprobados: Wolf Project.

diploma_certificacion_pmp

Es muy interesante darse de alta como miembro del PMI en su web, pues esto te permite obtener una buena rebaja en los derechos de examen, así como te permite descargar material interesante de su intranet. Es imprescindible bajarse un ejemplar del PMBOK edición 5. También merece la pena hojear los ejemplares de sus publicaciones PMI Today y PMI Network.

Durante las horas obligatorias de clase se busca una aproximación  al mundo de los proyectos.

Una puntualización importante: todos los ejemplos están basados en empresas americanas de tamaño medio grande, por eso choca con nuestra experiencia en empresas españolas. Es más, los test realizados durante las primeras clases suelen ser decepcionantes por no responderlos adoptando el punto de vista de una empresa americana. Son los llamados PMIsmos (ideas o planteamientos que se presuponen para el examen), en el libro de Rita existe un apartado que los estudia.

Es importante destacar que completar el proceso de inscripción dentro de la web de www.pmi.org es un trabajo laborioso y que requiere unas cuantas horas de dedicación. Es mejor reservar dedicación suficiente para hacerlo.

Además, el PMP puede auditar en cualquier momento toda la información contenida en la solicitud. Suele tocar auditoria a uno de cada cuatro alumnos.

Material empleado para la preparación de la certificación:

  • PMBOK 5. Por supuesto. Pero no es suficiente para aprobar.Project Management - Business Concept. Green Arrow with "Project Management" Slogan on a Grey Background. 3D Render.
  • PMP Exam Prep Rita Mulcahy, 8ª edición. Es la base de la preparación, complementado con la lectura del PMBOK 5. Dispone de exámenes que hay que realizar un par de veces cada uno. Es interesante sacar un 85 % de nota en ellos antes de presentarse al examen
  • Apuntes de las clases del preparador. Muy interesantes, pues con ellos se pueden hacer resúmenes muy útiles en los últimos días antes del examen
  • Head First: PMP, de Jennifer Greene. Es un libro muy básico pero es muy útil para los que desconocen alguno de los conceptos que se manejan.
  • Simuladores de examen. Existen muchos. Son de dos tipos: basados en web o instalables bajo windows. He probado los dos y prefiero los basados en web pues están mucho más actualizados. Utilicé el simulador instalable de Rita Mulcahy (RMC Project) en su versión 6 y me pareció muy desactualizado. Recomiendo el simulador on line de Pablo Ledó que es de pago pero es muy útil para hacer test un poco diferentes a los del libro de Rita Mulcahy 8ª edición.

 

Tipos de examen:

  • PBT, basado en papel:
    • Los preparadores hacen grupos para poder examinar “en papel”.
    • Se puede hacer tanto en español como en inglés.
    • La nota se entrega en un par de semanas.
  • CBT, basado en ordenador:
    • Es más caro. Puede hacerse en cualquier centro homologado de Prometric.
    • Se puede hacer tanto en español como en inglés.
    • La nota se entrega una vez finalizado el examen en el acto.

Nivel de dificultad:

  • Ato. Requiere dedicación y es difícilmente compatible con el desempeño laboral. Lo ideal es tomar unos días libres para prepararlo.
  • Requiere tener muy claro el escenario del examen, es decir, una empresa americana de tamaño medio/grande
  • Muy interesante conocer y asumir los PMismos es decir,  principios que el PMI asume como ciertos y que hay que conocer y entender para afrontar el examen de certificación, por norma general están localizados en la bibliografía relacionada (por ejemplo en el libro de Rita Mulcahy o en el PMBOK). Son importantes porque nos ayudaran a situar el marco de la pregunta del examen e incluso puede en algunas ocasiones ayudarnos a descartar alguna respuesta incorrecta.

Lo mejor de la certificación PMP:

  • Proporciona un visión muy completa de la gestión de proyectos. Incluye todas las posibilidades de gestión. Hay metodologías que se remiten al PMBOK para gestionar ciertas materias donde ellos no llegan.

Lo mejorable:

  • No es la mejor forma de acercarse a la disciplina de la gestión de proyectos. Es recomendable tener conocimientos previos.
  • Al ser el PMBOK un compendio de buenas prácticas (y no una metodología) , no proporciona una forma definida de hacer las diferentes tareas en el día a día del proyecto.

GESTIÓN DE PROYECTOS EN EL MUNDO REAL

Dejar un comentario

Título original: Your Project Management Coachbiafore

Autores: Bonnie Briafore, Teresa Stover

Editorial: Anaya Multimedia/ Viley, año 2012, 448 páginas

ISBN: 978-84-415-3225-0

Palabras clave: Proyectos, Metodología, PMP, Project Management

No hay muchos libros en el mercado que traten el tema de la gestión de proyectos, así que este libro me llamó mucho la atención cuando lo vi. Le eché un  vistazo y decidí comprármelo. Eso si, lo compré a pesar de que se trata de otro caso de cambio del titulo original por otro que no tiene nada que ver.

El libro me lo leí antes de que me examinara para obtener la certificación PMP del PMI. Ahora lo hubiera leído con otra actitud.

Se tata de un libro dirigido a personas con algunos conocimientos previos de gestión de proyectos. Al principiante le va a resultar un poco difícil entender algunos conceptos que se presuponen en ese libro. Lo escribe una persona que es PMP y que tiene

El libro se divide en las mismas partes que los grupos de procesos del PMBOK:

  • La Parte I está compuesta de una introducción de lo que es y lo que no un proyecto, así como qué es gestionar un proyecto.
  • La Parte II se refiere a la planificación y nos habla de qué es un plan de proyectos,cómo identificar los trabajos de un proyecto, cómo estima trabajos y costes, cómo planificar recursos, cómo establecer el cronograma, cómo gestionar la calidad, escribir el Plan de Comunicación, el plan de gestión de cambios, los riesgos
  • imagesLa Parte III está dirigida a los procesos de ejecución
  • La Parte IV habla de la monitorización y control
  • La Parte V  se refiere al cierre. Incluye cómo documentar el proyecto y cómo cerrarlos.

Una de cal, lo mas flojo de todo el libro es el capítulo Nº 13 (Parte II) que habla de la puesta en marcha y que describe la obtención de aprobación, seleccionar el equipo y eventualmente, seleccionar al proveedor.

Y otra de arena, en el capítulo Nº 8 (Parte II) se habla del calendario y de la ruta crítica, y menciona la idea de que el diagrama Gantt no es el proyecto. Esta es una gran verdad que ha hecho mucho daño a muchos proyectos.

Como información extra, también contiene ideas acerca de cómo crear una PMO en una empresa y los motivos por los cuales es una buena decisión.

Destaco que dentro de los capítulos hay excelentes anotaciones que son fruto de la experiencia y que hacen mas valioso el contenido, por ejemplo, el autor destaca que las “Lecciones aprendidas” es una de las partes más importantes de la gestión de los proyectos, pero que hay que ser muy cuidadoso para que los objetivos o incentivos del Project Manager y del equipo no impacten con ellas, pues de otra forma nos encontraríamos con una simple descripción de lo bien que se realizó el proyecto, eludiendo cualquier tipo de análisis o crítica.

Otro detalle a destacar, menciona  lo que son preguntas específicas del examen PMP, por ejemplo, las fases en el desarrollo de un equipo de trabajo de Bruce Tuckman. Pero hay que hacer una advertencia, con este libro no es suficiente para prepararse para el examen PMP . Hace falta bastante más material adicional para poder tener éxito en el examen.

Muy interesantes y aprovechables son las plantillas para obtener soporte a las tareas habituales de gestión del proyecto, que se ofrecen para ser descargadas directamente de la web de Anaya Multimedia.

Es de agradecer que es un libro claro, conciso y escrito con un lenguaje que todo el mundo puede entender.

Como conclusión, un libro muy recomendable para profundizar en el mundo de la gestión de proyectos.

Valoración: 8/10