El contexto es una PMO que se ejecuta en dos grupos de desarrollo, uno que realiza el desarrollo ágil y el otro que utiliza el modelo en cascada . Para llegar a un enfoque común y un modelo de compromiso, nos gustaría estandarizar roles, responsabilidades y definiciones.
La definición de "proyecto" es algo confusa en el mundo Agile, porque el trabajo es una colección de características/épicas que están alineadas con un flujo de valor. Un proyecto es un concepto más heredado de una actividad que tiene una fecha de inicio/finalización, con la esperanza de que se entregue algún valor al cliente.
¿Cómo definimos "proyecto" en el mundo Agile?
La definición de un proyecto en términos ágiles no es diferente a la de un proyecto en términos tradicionales. La diferencia es cómo se ejecuta y ejecuta el proyecto y los valores detrás del proyecto.
Común
Tanto proyectos ágiles como proyectos tradicionales:
diferencias
Agile reconoce que tratamos con tecnologías y requisitos complejos en un mundo lleno de incertidumbres y ambigüedades. Al hacer esto, el enfoque es más un control de proceso empírico en lugar de seguir un control de proceso definido. Permite que el equipo se adapte a los desafíos.
El trabajo se realiza en iteraciones muy cortas, que no superan los 30 días para mitigar el riesgo frente a estas complejidades e incertidumbres. Los proyectos tradicionales pueden durar años sin fases, o las fases pueden durar varios meses. Los practicantes ágiles sienten que esto es demasiado largo y que hay demasiados riesgos involucrados.
La mayoría de las prácticas Agile siguen principios lean para eliminar el desperdicio y construir solo lo que se necesita. Los profesionales ágiles reconocen que los requisitos iniciales normalmente conducen a grandes volúmenes de desperdicio; Por ejemplo, el 64 % de las funciones rara vez o nunca se usan: Standish Group Research.
La mayoría de las personas no se vuelven ágiles porque es difícil. La razón por la que es difícil es que todos hemos sido educados para trabajar con procesos definidos y controlar estos procesos. Romper esta mentalidad para lidiar y aprender a gestionar proyectos complejos utilizando el control de procesos empírico requiere mucha energía y compromiso. Se ha demostrado que es una forma muy confiable de lidiar con proyectos de software, pero necesita un cambio.
He hecho algunos podcasts sobre gestión de proyectos y Scrum que resaltan estas diferencias en detalle, es posible que desee utilizar Google para intentar encontrarlas.
Independientemente del mecanismo para entregar (según la respuesta de @Brett), sugiero que la definición de un proyecto sea tan simple como "un proyecto es una actividad que brinda un valor medible a la organización al aumentar los ingresos, reducir los costos o mejorar la eficiencia".
Cada proyecto que entregue debe ser fácilmente cuantificable en cuanto a por qué lo está haciendo.
Para profundizar en lo que dijo @Brett Maytom PST en el lado de las diferencias:
Minimice el riesgo del proyecto : si tiene características que son de alto riesgo (cualquier propuesta de valor única que no se haya creado antes), puede programarlas con anticipación para validar si es factible. Si determina que no es posible o que es demasiado costoso construirlo, puede reconsiderar la viabilidad del proyecto.
Comentarios rápidos : los proyectos ágiles producen "incrementos de características entregables" al final de cada sprint. Por lo tanto, puede implementar esto y hacer que los usuarios comerciales jueguen con él, realicen pruebas de usabilidad e inscriban a los clientes beta para obtener comentarios tempranos. Esto le brinda la oportunidad de cambiar de dirección o incluso abandonar el proyecto antes de invertir la cantidad total presupuestada en el proyecto. En los proyectos en cascada, obtiene un producto que se puede enviar solo al final de la finalización real del proyecto, que a su vez puede estar por encima del presupuesto y atrasado.
Negociación de valor : Cuando hacemos una sesión de estimación, con demasiada frecuencia nuestro Product Owner se sorprende. Algunas cosas que el PO pensó que serían difíciles, resultan ser una configuración simple en la biblioteca que los desarrolladores optaron por usar. Mientras que otros que parecen lo suficientemente simples requieren una extensa codificación personalizada. En cuanto a la estimación, nuestra orden de compra puede descartar algunas funciones y reducir la prioridad de otras. En los proyectos en cascada, una vez que se escriben los requisitos, se tallan en piedra (sujeto al control de cambios, que es doloroso).
En Project Management entregas un Proyecto mientras que en Agile entregas un Epic. Los proyectos tienen una fecha de inicio y finalización definida, mientras que los épicos tienen productos con una aceptación definida o criterios de finalización en lugar de una fecha.
En mi opinión, el término Proyecto no debe usarse en Agile. Debe alinear a los equipos para que utilicen términos y roles similares, de modo que todos puedan entender y acordar procedimientos y prácticas generales. Sin embargo, si está buscando el término equivalente a Project en Agile, sería Portfolio Epic o Epic.
Recomendaría investigar Safe for Lean Enterprises para obtener una buena comprensión general de cómo alinear varios equipos y productos bajo un Portfolio Epic común que se alinea con el negocio.
Otro punto a considerar es la perspectiva de un Proyecto o Epic en Agile. Debe saberse que los Equipos no trabajan en Épicas o Proyectos, trabajan en Productos que podrían ser una función o elemento(s). Los directores (jefes de producto) y la alta dirección trabajan a nivel épico o de proyecto. Cuando buscan el estado de un Epic, les interesa saber cuántas funciones se han completado para un producto determinado. Es posible que el equipo de entrega de productos real no tenga una vista general de Epic, sino solo los productos y las características que están entregando.
Esteban
PMO ágil
Todd A. Jacobs