El equipo de desarrollo participa en la planeación

SCRUM resulta útil en proyectos de software (mediano), pero no lo veo aplicable a todo tipo de proyectos. En SCRUM falta definir tareas/actividades dentro de las

funciones del equipo de desarrollo. El impacto de los cambios en el proyecto es la misma pero la dinámica de SCRUM hace mas flexible su aceptación.

Con PMI estimaciones, definición de cronograma, proyecciones

Participación activa y permanente de todo el equipo

Actividades/ funciones pre-establecidas de comienzo a fin.

Control de costos y gastos

No son claras las directrices de control

El product owner conoce y aprueba entregas

Se obtiene mayor productividad del equipo de trabajo, cuando se exigen resultados mas cortos

Problemas de documentación

Un proyecto que exige un riguroso control presupuestal o estimación de riesgos se gestiona mejor a través de un framework que brinde herramientas para ello.

Con PM se obtiene mayor visibilidad y mejor estimación de riesgos

Detección temprana de errores

Requiere monitorear la productividad del equipo de trabajo

Los errores en el proyectos suelen detectarse muy tarde

PMI vs. SCRUMMi experiencia básicamente ha sido en proyectos gestionados utilizando la metodología del PMI:

• En proyectos de consultoría utilizábamos la carta de proyecto, WBS, gantt en MS Project, matriz de riesgos, lecciones aprendidas; estas herramientas nos permitían cierto orden y formalidad ante proyectos grandes y complejos. Adaptábamos los artefactos dependiendo de la magnitud del proyecto.

• En mi experiencia actual, he participado en proyectos gestionados con la metodología del PMI, usualmente la empresa tiene cierta flexibilidad de adaptar los artefactos, sin embargo, hay una PMO que dicta las pautas para los proyectos y utilizamos el software PPM para la gestión de los proyectos, control y visibilidad de la información de los mismos a toda la organización.

• No tengo experiencia de gestión de proyectos con la metodología SCRUM, sin embargo, en la empresa se gestionan de esta forma proyectos de alcance acotado, en el que se busca una solución expedita y que no hay inversión de dinero, ni gran cantidad de recursos.

• Luego de estudiar un poco sobre estas metodologías, ahora me parece que en algunos casos trabajamos de esa forma para la entrega de requerimientos, ya que involucramos al equipo desarrollador, el analista de negocio y el funcional, de forma tal que trabajan muy cercanos para solucionar conflictos, revisar alcance, validar, reuniones con cierta frecuencia para revisar avance y próximos pasos, siempre con un líder identificado.

Luego de lo revisado, puedo intuir que se puede tomar lo mejor de cada uno, me parece que independientemente de la metodología a utilizar debemos evaluar algún alcance inicial, un caso de negocio que justifique la inversión, identificar a los stakeholders, liderazgo, equipos de trabajo identificados, gestionar los riesgos latentes. Luego como se desarrolla si me parece que podemos ir a células de trabajo mas pequeñas, en los tracks, involucrando a los funcionales.

PMI vs. SCRUM (Continuación)

• En mi trabajo conviví con el cambio de metodologías más tradicionales (PMI), a Scrum. En un principio hubo que cambiar y adaptarse a realizar reuniones diarias, que se volvían más largas de lo necesario y que se tornaban un poco tediosas. Luego nos fuimos acostumbrando a hablar solo de los temas pertinentes y comenzamos a cumplir con los tiempos esperados (entre 15 y 20 min). Estas reuniones nos fueron sirviendo para integrarnos más como equipo dado que nos permitía saber que estaba haciendo el otro y poder ofrecer ayuda cuando había algún tema bloqueante o dar sugerencias de como resolver algún problema. Por otro lado, los clientes internos (el área de operaciones) quedaron más conformes con los resultados porque podían ir viendo prototipos de las aplicaciones, y pedir cambios o dar su conformidad más rápidamente. También nos sirvió para poder ir midiendo mejor nuestra velocidad como equipo y ver los desvíos que íbamos teniendo. Como conclusión puedo decir que el cambio fue acertado por la forma de trabajar en la empresa y por la composición de nuestro equipo, 7 personas todas alocadas en el mismo lugar de trabajo.