1
Cuál es la mejor forma de combinar los dos mundos respecto de las necesidades de documentación y el manejo de los proyectos?
Alguna experiencia?
Hola Cristian,
Antes que nada, entiendo que PMO es “Project Management Office” (Oficina de administración de proyectos), la cual en general tiene control sobre ciertos proyectos (sino todos) de una organización. Dicho esto, si tu pregunta apunta a ese significado de las siglas, tengo algunas reflexiones / experiencias para compartir:
Se puede combinar una PMO con metodologías y prácticas ágiles de muchas formas y -dependiendo del contexto- deberá analizarse puntualmente su aplicación. Sin embargo, tratando de responder de alguna forma que te brinde herramientas para analizar tu situación, creo que algunos puntos importantes que habría que tener en cuenta son:
qué relación tiene la PMO en relación a los roles sugeridos por la metodología que estén queriendo utilizar? son compatibles de alguna forma?
la documentación que mencionás, aporta valor de negocio?
se puede pensar en mejorar la legibilidad y estructura del código para minimizar la cantidad de documentación?
en el caso de ser estrictamente necesaria: la documentación que mencionás, se puede colocar dentro del “criterio de terminado” o como criterio de aceptación de las user stories (o items del backlog, o requerimientos) que está construyendo el/los equipo/s de desarrollo?
de hecho:
existe ese “criterio de terminado”? quién lo establece: la PMO o el/los equipos? es distinto para cada proyecto/producto/cliente?
los procesos (si estuvieran definidos) de desarrollo (y los demás procesos que rodean dicho proceso) pueden ser modificados/mejorados desde el/los equipos? esto quién y cómo lo regularía?
en este contexto: las retrospectivas de los equipos, tendrán posibilidad de mejorar el entorno (además de las prácticas internas del equipo?)
el ciclo de vida planteado por la PMO (si es que está planteado por la PMO), es compatible con las ideas de desarrollo evolutivo (o iterativo + incremental) que sugieren las metodologías ágiles?
tiene sentido ver a los PMs como Product Owners y que ellos sean los que se encarguen de priorizar el backlog, teniendo en cuenta a todos los stakeholders (tanto internos como externos, si es que hay externos e internos)?
tiene algún PM un perfil parecido al de Scrum Master (líder servil, facilitador) o más bien al Product Owner?
los “dos mundos” a los cuales hacés referencia, son compatibles en la organización en la cual estarías queriendo implementar la coexistencia?
se podrá implementar alguna práctica ágil EN la PMO, como para favorecer la transición? ej: retrospectivas de la PMO, planificación a través de un Backlog y/o un tablero Kanban, planificación con foco en el negocio, etc.
qué tipo de PMO estarías necesitando combinar con Agile? tal vez una PMO muy controladora no sea compatible con la necesidad de auto-organización dentro de los equipos que promueven las metodologías ágiles (recordemos que no existe UN líder para los equipos, sino que ellos son los que construyen -autogestionándose- el software).
Bueno, podría seguir escribiendo, pero espero tus comentarios para volver a enfocar la conversación (si se necesitara continuar) para donde más te sea útil.
Saludos!
Pablo
Ok, nuestra respuesta anterior no gustó :o( Veamos si esta respuesta les gusta :o)
Cuál es la mejor forma de combinar los dos mundos?
Para combinar más de una dimensión, requieres de un artefacto documental que lo denominamos como “perspectivas”, por concepto las perspectivas representan la forma de “observar” un escenario desde el punto de vista (perspectiva) del observador.
Para poder capturar las perspectivas de tantos observadores que existen detrás de un proyecto (stakeholders, usuarios, developers, testers, etc.) recurrimos a fabricar otro artefacto documental que lo denominamos “portafolio” :o)
Por concepto un portafolio contiene folios, esto es, que puedes modelar contenidos de acuerdo a una audiencia específica, porque no es posible capturar en un único modelo todas las perspectivas por más multimedia que sea su contenido, esto se debe a que el “arte de modelar” se basa en la capacidad de abstracción y por concepto abstraer implica el ocultar información y enfocarse en un patrón específico de características para determinar un concepto y expresarlo mediante un lenguaje de modelado :o)
las necesidades de documentación y el manejo de los proyectos
Se entiende como manejo de proyectos al uso de un marco de trabajo para gestionar proyectos (de cualquier tipo), el marco de trabajo ofrece un método para ejecutar proyectos (seguimiento y control) y un modelo que soporta al método indicando cómo tiene que utilizarse el método (gestión)
Suponiendo que la pregunta es específicamente sobre proyectos tecnológicos, recurrimos a utilizar los artefactos propuestos por el lenguaje de modelado (que usualmente es UML) para capturar y modelar los requerimientos que sean soportados por la sintaxis del lenguaje, por otro lado, si lo que deseas modelar es la actividad de gestionar el proyecto, pues la respuesta la presenta el marco de trabajo (MSF, RUP, SCRUM,etc.) ya que indican al menos el modelo básico denominado como CICLO DE VIDA DEL PROYECTO)
La documentación ágil de proyectos
Hasta ahora, nuestro artefacto denominado “portafolio documental” nos ha permitido desde hace ya más de 10 años documentar adecuadamente los proyectos tecnológicos en los que hemos participado, cada vez se requiere desarrollar nuevos modelos dentro del portafolio porque nunca los proyectos son iguales entre sí, cada proyecto posee su propia naturaleza y entorno (condiciones de uso) de ejecución.
Un ejemplo del portafolio es el que publicamos en la respuesta anterior :o)
Esperemos que esta respuesta les haya gustado :o)
DSN_XP
La respuesta creemos tenerla nosotros porque somos un método de documentación del software, ahora bien, como el software se utiliza en los negocios, por ende, nos extendemos hacia el negocio también.
DSN_XP está basada en modelos, por lo tanto, nuestra respuesta a tu inquietud depende de crear modelos apropiados que permitan capturar todas las perspectivas posibles de la audiencia detrás del proyecto.
)
Utilizamos la noción de paquetes UML para contener en su interior escenarios de interéses y los stakeholdes asociados :o)
Por otro lado necesitamos documentar la arquitectura software del producto, por ello recurrimos al modelo 4+1 UML mediante advanced use cases.
DSN_XP reconoce 2 perspectivas importantes para documentar proyectos tecnológicos, la primera la hemos denominado BUSINESS VIEW y envuelve todas las perspectivas del negocio, por otro lado utiliza la perspectiva que hemos denominado SOFTWARE VIEW que envuelve a conceptos de la parte técnica.
All Shapado.com content and data are available under the
pke mi cerebro interpreta el tag “pmo” como “porno”? Soy yo? Soy el único?
@darsenovski Jajaja es tu cerebro corrompido por el porno… después se pasa tranquilo.