Menú

MÉTODOS ÁGILES Y SCRUM

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

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

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

 

LEGAL PROJECT MANAGEMENT

lpmTítulo original: Legal Project Management

Autores: Anna Marra

Editorial: Rasche, año 2012, 140 páginas

ISBN: 978-84-15560-06-7

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

Este libro aborda una tendencia que nace en USA, Canadá, Reino Unido y Australia y que se está extendiendo por el mundo, el Legal project Management (LPM), que, según la Wikipedia,  se define como la “aplicación de los conceptos de gestión de proyectos para el control y gestión de casos legales o asuntos“.

Su autora es Anna Marra, una abogada italiana, que también es Directora académica del Programa de Desarrollo “Legal Project Management”, organizado por IE Law School.

Vayamos pues a lo que nos cuenta el libro. Un primer detalle muy mejorable  es que no existe un índice del libro. Está dividido en dos partes: 1.- Hablamos de LPM y 2.- Aplicamos  el LPM.

Y hace una importante reflexión en la página 63, este libro solo pretende ser una introducción al LPM. Para profundizar en este tema se deben buscar otras fuentes.

Entrando en la parte 1.- “Hablamos de LPM”,  Anna Marra comenta que la situación de partida en el mundo de los bufetes es la de ser un sector caracterizado por cierto inmovilismo. Se trata de un sector que solo ha considerado superficialmente la necesidad de adaptarse al nuevo contexto social y económico. En resumidas cuentas, el sector legal se resiste al cambio. En este punto, el LPM puede ser una ventaja competitiva para los despachos que lo adopten.

La autora detalla las ventajas que pueden obtener los despachos de abogados del uso del LPM. Los bufetes de abogados que se benefician especialmente de la gestión de proyectos  son los que trabajan bajo acuerdos de honorarios alternativos tales como honorarios fijos o planos o con límites de coste.

Por otra parte, los clientes de bufetes que han adoptado el LPM se benefician de que la información es mas transparente (en especial los costes están más detallados) y que se reducen las incertidumbres propias de los servicios jurídicos  en cuanto a alcance, coste y ejecución.

Ventajas del LPM (fuente: programa de LPM de IE):

  • Alinea la práctica organizativa a la estrategia y cultura del despacho.
  • Permite prever costes y beneficios, aumentando la rentabilidad.mazo
  • Permite asignar los recursos necesarios atribuyendo responsabilidades y tareas.
  • Permite saber cuántos recursos estarán ocupados, cuándo y por cuánto tiempo.
  • Reduce o elimina el nivel de incertidumbre, a través de una correcta identificación de los riesgos.
  • Permite gestionar el cambio.
  • Mejora el proceso de control y seguimiento desde el inicio hasta el cierre del encargo.
  • Mejora la comunicación con el cliente generando más confianza y satisfacción.
  • Permite centrarse en las verdaderas necesidades del cliente y ofrecer la solución más
    apropiada.
  • Evita desperdicio de recursos.
  • Mejora el ambiente de trabajo

Dicho esto, la autora introduce en el libro las ideas básicas de la gestión de proyectos como es la triple restricción (tiempo, coste, calidad), las estructuras empresariales con las que debe contar la gestión  de proyectos, las áreas de conocimiento (alcance, tiempo, coste, riesgo, calidad, rrhh, comunicación, adquisiciones, integración).

Un detalle importante que remarca la autora es que por la misma naturaleza del trabajo que desempeña, el abogado no puede comprometerse a obtener un resultado determinado, (a diferencia de otros sectores como la construcción o la informática). Puede parecer que esto iría  en contra de abrir un acta de constitución del proyecto, pero no sería  un problema, le bastaría con actual con la “diligencia debida” en el desarrollo de su labor.

El segunda parte del libro “2.- Aplicamos el LPM”, se aplica la gestión de proyectos a un caso jurídico ficticio basado en dos sentencias del Tribunal Supremo: una empresa compra a otra un terreno afectado por residuos tóxicos y le reclama que abone los gastos de limpieza de los mismos. Desde que el cliente entra por la puerta del despacho, se busca enfocar los trabajos tal y como se realizarían gestionando el caso como un proyecto. Esta es quizás la parte más interesante del libro.

Como conclusión, el libro deja con ganas de conocer más sobre el LPM. Con la información que proporciona el libro un abogado puede hacerse una pequeña idea de lo que es la gestión de proyectos, pero es absolutamente insuficiente para aplicar el LPM a un despacho. Eso si, la autora ya avisó de que esto es una introducción al LPM.

Sospecho que el LPM va a ser una tendencia imparable en el mundo legal. Los clientes van a desear trabajar con bufetes que les proporcionen información sobre su caso, en un formato que ellos puedan entender.

Un ejemplo: el Departamento de Servicios Jurídicos de Telefónica España ya apuesta por el LPM.

Enlaces interesantes sobre LPM:

GESTIÓN DE PROYECTOS (ANAYA MULTIMEDIA)

Título original: Absolute Beginners Guide to Project Management

Autor: Gregory M. Horine

Editorial: Anaya Multimedia, año 2010

ISBN: 84-415-1917-x

Palabras clave: proyectos, gestión, management, metodología

Este libro trata de la materia de  gestión de proyectos y está orientado a personas que desean conocer este campo, ¡¡Que fácil o qué difícil puede llegar a ser!! Aunque es un libro editado en l año 2010 tiene partes muy aprovechables.

Pero primero, consultemos a nuestra buena amiga la Wikipedia sobre lo que significa gestión de proyectos: “es la disciplina de organizar y administrar recursos de tal manera que se pueda culminar todo el trabajo requerido en el proyecto dentro del alcance, el tiempo y los costes definidos. Un proyecto es un esfuerzo temporal, único y progresivo, emprendido par crear un producto o un servicio también único”.

El libro se divide en cuatro partes.

La primera parte trata de lo que es iniciarse en la gestión de los proyectos. Se pregunta qué es exactamente gestionar proyectos y lo que no es, habla de las funciones del jefe de proyectos y de los elementos esenciales de un buen proyecto.

La parte segunda se refiere a la planificación del proyecto. Trata de la definición correcta de los proyectos y de los principios básicos de la planificación. Una buena observación que hace el autor es que un archivo de Microsoft Project 2007 no es un plan de proyecto (es algo más amplio, y debe hacer referencia a otro documentos y planes complementarios
Esta parte también trata del desarrollo de la estructura del desglose del trabajo. Recomienda crear hitos de trabajo pequeños para que sea más fácil de controlar. El desglose es diferente al calendario, el calendario recoge las dependencias entre tareas, las tareas programadas y las asignaciones de tareas, el desglose no las contempla.esquema

Se habla de cómo hacer buenas estimaciones de trabajo (crear un calendario realista), de cómo desarrollar adecuadamente el calendario del proyecto, y de la determinación del presupuesto del proyecto.

La parte tercera se refiere al control del proyecto. Explica las técnicas efectivas del control, la gestión de los cambios (que pongamos como nos pongamos son inevitables y hay que tener un plan previo para afrontarlos) y la gestión de los entregables, (es tentador no prestar atención a los entregables porque parece demasiado trabajo, pero que resulta ser una parte esencial para la satisfacción de los clientes).

Afronta la gestión de los problemas del proyecto, que como en el caso de los cambios, también son inevitables, por lo tanto es mejor tener un procedimiento que permita documentarlos, comunicarlos, alinearlos con los costes y solucionarlos.

Otros apartados son la gestión de los riesgos del proyecto, (identificar y prepararse contra cualquier amenaza hacia los factores críticos de éxito antes de que sucedan) y la gestión de la calidad de proyecto (la satisfacción de las necesidades reales de los clientes).

La parte cuarta, y última, se refiere a la ejecución del proyecto. Trata de la dirección (la diferencia entre gestionar y dirigir y como novedad habla de la “dirección servil”), la gestión de las comunicaciones (que se refiere a todos los medios de interacción, ej. Informes, presentaciones, registros, etc.), la gestión de las expectativas (diferente a la alcance), las claves para incrementar el rendimiento del equipo, la gestión de las diferencias (cuando existan diferencias culturales o étnicas o de otros tipo), la gestión de los vendedores del proyecto y la finalización del proyecto (qué difícil parece pero que es sencillo utilizando una lista de control).

En fin, como valoración, se trata de un buen manual de inicio, válido para todo tipo de proyectos y por eso se le perdonan algunas pequeñas ausencias como no hablar de la ruta crítica, (es excusable porque se trata de una introducción a la gestión). Le falta un poco de profundidad pero eso queda para libros más concretos de gestión. Está orientado para ser un libro de entrada al mundo de la gestión de los proyectos.

Tiene de positivo que enfoca este tema de la gestión de proyectos con mucho sentido común y eso es realmente bueno, pues no se complica mucho, (gracias a Dios), porque parece que está de moda lo absurdamente complicado. No habla de fórmulas milagrosas (que no existen).

Como el autor es americano, no habla de lo complejo que es para las  empresas españolas  cuando deben gestionar proyectos contando con estructuras funcionales o matriciales.

Valoración: 6/10.

THE PRINCIPLES OF BEAUTIFUL WEB DESIGN

Título original: The Principles of Beautiful Web Design

Principles of a beautiful web design

 

Autor: Jason Beaird


Editorial SitePoint, febrero 2007 Formato: Paperback


168 Páginas


ISBN: 0975841963


Palabras clave: diseño web, Internet, maquetación, tipografía, color, texturas, composición.

OK, de acuerdo, las webs tienen que ser usables, accesibles y poseer una buena arquitectura de la información. Pero, ¿No nos olvidamos de algo?¡También tienen que ser bonitas!

Jason Beaird nos habla en este libro de realizar webs atractivas visualmente, que entren por los ojos. Y lo hace desde la perspectiva de alguien que se dedica a ello desde hace tiempo y con verdadera pasión. Para ilustrar lo que explica, el autor va elaborando una web paso a paso.

Claramente nos advierte, una web no es bonita porque sí,  sino que lo es por la combinación de muchos pequeños factores que logran un resultado excelente.

En el Capitulo 1 habla de Maquetación y composición. Nos comenta las bases de un diseño bonito a través de la teoría del número áureo y del equilibrio de los elementos de la página.

En el Capitulo 2 habla  de la teoría del Color, cómo crear una paleta de color y del uso adecuado de los  colores, para que el resultado sea armónico. Aburrido  estoy de ver webs llenas de colorejos que no combinan entre sí y que hacen daño a los ojos.

El Capitulo 3 lo dedica a las Texturas, un tema pasado por alto muchas veces y que puede hacer mucho más bonita una web. Usar puntos, líneas y formas es un verdadero arte.
El Capítulo 4 es uno de mis favoritos porque habla de la tipografía (el estudio de las letras). Esto daría para muchos libros pero condensa el tema realmente bien.

El último capítulo habla de las imágenes y su tratamiento (recorte, bordes, etc). No es fácil elegir las imágenes que nuestro proyecto web necesita. Algunas fotos de pago valen su peso en oro para transmitir una imagen de profesionalidad. A veces se abusa de las imágenes y el sitio resulta recargado. En otras ocasiones las imágenes elegidas no proceden y transmiten la idea  de ser poco profesional (me estoy acordando de la manía de hace unos años de poner fotos de niños pequeños en las webs).

Por cierto, que este libro tiene una web propia:www.principlesofabeautifulwebdesign.com, muy interesante de visitar.

En resumidas cuentas, resulta agradable centrarse en hacer que los sitios web sean más atractivos, además de usables y accesibles.

Valoración 7/10

USABILIDAD, PRIORIDAD EN EL DISEÑO WEB

Título original: Priorizing Web Usability

¡NO ME HAGAS PENSAR!

Título Original: Don’t make me think!no me hagas pensar

Autor: Steve Krug

Editorial: Prentice Hall

ISBN: 9788483222867

Palabras clave: usabilidad, diseño web, Web 2.0

Lo primero que hay que decir de este libro son dos cosas: que es un libro de culto dentro de la usabilidad y que es bastante corto, unas 200 páginas. Si a eso le sumamos el hecho de  que está escrito con un gran sentido del humor, pues ¡no sé que estais esperando para ir la la librería a comprarlo! No os decepcionará.

Pero primero definamos lo que es la usabilidad según la Wikipedia, pues es el tema principal del libro:

“La usabilidad (del inglés usability) es la facilidad con que las personas pueden utilizar una herramienta particular o cualquier otro objeto fabricado por humanos con el fin de alcanzar un objetivo concreto. La usabilidad también puede referirse al estudio de los principios que hay tras la eficacia percibida de un objeto. En interacción persona-ordenador, la usabilidad se refiere a la claridad y la elegancia con que se diseña la interacción con un programa de ordenador o un sitio web.”

Vamos a ir al grano, en su primer capítulo, “No me hagas pensar” el autor se pregunta ¿Cual es la relación entre la usabilidad y las webs?, muy sencillo: que si algo es muy complicado de usar, ¡Pues no se usa! En el caso de la web, se consultan otras webs mas sencillas de usar y la web deja de tener visistas.  Así se resume todo el libro, Cuando uso algo, no me hagas pensar demasiado o utilizaré para lograr lo que necesito otra web o herramientas más fácil de usar. Se requiere mucha empatía para crear un sitio web, hay que ponerse en la piel del usuario que visita la web. Eso si, la empatía no es una cualidad que brille en le curriculum vitae de los desarrolladores.

El autor, Steve Krug, advierte que no es un libro para lo que gustan de criticar los defectos de todas las webs, pues crear y mantener un sitio web es una labor que requiere respeto.

El segundo capítulo del libro “Cómo usamos realmente la web” se refiere a que los diseñadores de los sitios diseñan como si los contenidos fueran a leerse de forma minuciosa, cuando lo que realmente pasa es que los lectores pasan por los menos a 200 km/hora. Porque en Internet las webs se hojean, no se leen, pues todos tenemos prisa. Además, no siempre tomamos el camino correcto, sino el que a nosotros nos parece que podemos obtener lo que estamos buscando (cosa muy diferente),  y a todo esto hay que sumar el hecho de que a la gente le gusta adivinar y que equivocarse aquí no tiene consecuencias importantes, salvo tener que clicar en el botón “Atras”. Asumamoslo, la gente no se lee las instrucciones de uso de ninguna máquina y menos del uso de la webs.

Y con esas llegamos al capítulo tres que se titula “Diseño de rótulos 101“, que es la consecuencia lógica de todo lo dicho, si los usuarios no leen sino que hojean a toda velocidad las webs, pues diseñemos los contenidos de una forma visual muy clara, dejando clara la jerarquía visual de los contenidos y aprovechándonos del uso de las convenciones.

He de decir que me ha parecido este es el capítulo más influenciado por la obra de Jakob Nielsen “Usabilidad, prioridad en el diseño web”.

El capítulo cuatro “Animal, vegetal o mineral” y el cinco “Omisión de palabras innecesarias”, se refiere a que a los usuarios les gustan las opciones cerradas que les lleven a donde ellos quieren  y que suprimir el contenido innecersario hace que se reduzca el “nivel  de ruido visual”   en una página y la información sea más clara. El lector perspicaz ya se habrá dado cuenta de que entre  los consejos está el de no añadir instrucciones de uso de nada, (si es que nadie las va a leer).

Los capítulos seis y siete “Señales en la calle y migas” y“El primer paso para la recuperación…” se refieren a cómo evitar que los usuarios se pierdan dentro de la web. En este sentido toda ayuda para informar a usuario de donde esta en la web es poca (es decir, el tipico cartel de “Usted está aquí” que se usa en ciudades o centros comerciales o las conocidas “migas de pan” o “breadcrumbs”  utilizadas afortunadamente en bastantes webs.lot 1

“Granjeros y ganaderos deben ser amigos”, el capítulo ocho, tiene que ver con el problema de que los equipos  de desarrollo de webs (diseñadores y desarrolladores) tienen unas perpectivas y unas convicciones muy diferentes de los que es un  buen sitio web. Vamos, el eterno dilema entre arte y negocio.

¿Como solucionamos el anterior dilema?, pues como se propone en el capítulo nueve “Prueba de usabilidad 101″ y diez  “La  usabilidad como cortesía común” de forma muy sencilla,  haciendo que hable el usuario final del sitio por medio de testeos y pruebas con usuarios ficticios antes de publicar el sitio web. Creo que esta es la mejor recomendación de todo el libro, hacer testeos con usuarios para probar que el sitio es usable y eliminar los fllos más evidentes.

Por otra parte, vamos a dar otro paso, vamos a unir usabilidad y accesibilidad (capitulo diez “Accesibilidad..”), que se ha convertido en un requisito básito de todas las webs.

La accesibilidad es “El grado en el que todas las personas pueden utilizar un objeto, visitar un lugar o acceder a un servicio, independientemente de sus capacidades técnicas, cognitivas o físicas.La accesibilidad aplicada al contenido de Internet se denomina accesibilidad web. En la Web, el W3C ha desarrollado directrices o pautas específicas para permitir y asegurar este tipo de accesiblidad”. El típico ejemplo de accesibilidad es el poder aumentar el tamaños de las letras para que sea más cómodo leer los textos.

Usabilidad y accesibilidad deberían de ir de la mano y más ahora que todos los gobiernos exigen que las webs de las administraciones públicas sean accesibles para comodidad de sus ciudadanos con problemas visuales.

El último capítulo es el más irónico del libro (Ayuda, mi jefe quiere…), pues el autor se ofrece a ayudar a todo desarrollador cuyo jefe el exige que  su web haga cosas incoherentes, ej. que tenga muchas visitas y que el sitio tenga un diseño sobrecargado. Amablemente,  Steve Krug ofrece a los sufridos subalternos una batería de modelos de respuestas que él mismo ha enviado cuando le piden cosas incompatibles.  Muy bueno.

Valoración: 9/10

Actualización de la información. En septiembre de 2015 se ha sacado a la venta una edición actualizada del libro.

Esta actualización aporta una nueva perspectiva para reexaminar los principios Web actualizados y un nuevo capítulo acerca de la usabilidad móvil.

Sigue siendo divertido de leer.