Si se utiliza Scrum para la parte de desarrollo de software de un proyecto, ¿todavía se usa PMBOK o alguna otra metodología de gestión de proyectos para las "otras" tareas en un proyecto, p. las tareas de negocios, marketing, capacitación. ¿A qué se refiere la gestión de proyectos de tareas de desarrollo no de software, es decir, la gestión de proyectos tradicionales?Agile Project Management
Hemos expandido el scrum a otros departamentos de la compañía, modelado, textura y artista de animación. Tuvimos que adaptar el método un poco, pero funciona bien. Tuvimos problemas que fueron resueltos mediante el uso de metodología ágil. Algunos departamentos más pequeños (audio, efectos especiales) ya funcionaban bien, así que no intentamos arreglar lo que no estaba roto. Agile habría agregado una sobrecarga innecesaria para ellos.
No es necesario que todos los departamentos de una empresa utilicen la misma metodología, lo mejor es adaptarse a las necesidades de todos. Pero el scrum puede ser la solución para personas que no sean programadores, pero puede necesitar un poco de adaptación. Soporte diario, sprints, backlog, pueden ser una buena opción para muchos tipos de trabajos.
¿Cómo implementó SCRUM en otros departamentos? ¿Tiene una lista de tareas para las cuales las personas se ofrecen voluntariamente o asignan tareas? – Joanne
Scrum NO es un método de desarrollo de software, sino un método de gestión de proyectos.
Además Scrum a menudo se presenta con Lego u otros artefactos (busque "59 minutos Scrum"). Por lo tanto, se puede usar para manejar todas las tareas de un proyecto, cualquiera sea su naturaleza.
Si bien aprender sobre estas técnicas es genial, ¿puedo sugerir que su enfoque principal se centra en la ejecución del proyecto y en hacer las cosas?
EDITAR: ese es un punto serio por cierto, no es una broma descartable.
Un proyecto se define en el PMBOK como algo fijo, de duración y presupuesto. El fracaso del proyecto se define como la ruptura fuera de uno de los tres lados de este "triángulo de hierro". Scrum es un conjunto de principios y algunas prácticas concretas para tratar todo tipo de trabajo de conocimiento, basado en valores ágiles, y está diseñado específicamente para esfuerzos de desarrollo que pueden no ser proyectos, o pueden tener un alcance flexible, duración o presupuesto.
Tiene razón en que Scrum solo se ocupa de algunos aspectos del proceso de desarrollo de software, como la planificación. Solo define algunos roles, reuniones y artefactos, esto es para mantenerlo lo más flexible posible. Scrum puede y debe abordar partes del flujo de valores fuera del desarrollo del software mismo. Sin embargo, como mencionó, no se ocupa de muchas cosas, como las prácticas de ingeniería de software y el análisis del caso comercial.
A menudo, la solución estándar de Scrum es "dejar que el equipo decida" en asuntos que no están especificados directamente por Scrum. A menudo, las pautas para tratar estos asuntos provienen de otras culturas y valores o sistemas principales dentro del mundo Ágil, como XP, o desarrollo de software lean. Otras culturas que proporcionan cosas útiles para los equipos de Scrum incluyen Real Options, el Método de financiación incremental, Evo.
Algunas de las cosas de PMBOK pueden ser útiles para un "gerente de proyecto" o PO en un equipo de Scrum, pero hay que tener cuidado ya que las cosas de PMBOK implican un sistema de valores bastante diferente al basado en Scrum. Por lo general, es mejor buscar soluciones dentro de la cultura ágil. Algunas de las cosas del PMBOK todavía se aplican en un contexto ágil.
Si busca listas de correo relacionadas con "administración de proyectos ágiles", encontrará muchas comunidades prósperas discutiendo sobre estos temas.
Si su esfuerzo de desarrollo de software es solo una faceta de un proyecto más grande, por ejemplo, implementando un nuevo producto financiero, entonces seguro que tendrá que emplear algún tipo de metodología de gestión de proyectos para organizar todo el trabajo involucrado. Sin embargo, ajustar un esfuerzo de desarrollo de software basado en Scrum en un proyecto administrado según los principios del PMBOK puede ser un desafío, ya que PMBOK prescribe un enfoque lineal y por fases para la ejecución del proyecto mientras que Scrum, al igual que otras metodologías Agile, promueve la mejora incremental mediante iteración. Eso no quiere decir que los dos no puedan coexistir. Como todo lo demás, todo se reduce a la implementación. Solo recuerda ser pragmático y adaptar las metodologías a tus necesidades, no al revés.
El desarrollo ágil y PMBOK no deben mezclarse. Si lo haces, es probable que termines con Scrummerfall.He visto esto suceder con los gerentes de proyectos tradicionales que se convierten en ágiles. Simplemente no lo entienden y parecen volver a los viejos patrones.
Sin embargo, en mi opinión SCRUM no cubre todo lo que necesita para la gestión de proyectos. En cierto modo, le falta una estrategia general para gobernar. Una posibilidad es combinar SCRUM con EVO project/value management u otros métodos de gestión de valores. Sin embargo, requerirá un tipo diferente de contrato legal con el cliente. Los proyectos se asemejan más a un proceso continuo marcado por el tiempo, restringido por un presupuesto o que termina cuando el cliente siente que gana menos que su inversión (utilizando casos comerciales y medidas de objetivos). Un beneficio adicional es que el cliente lo verá más como un socio a largo plazo que como un proveedor a corto plazo.
He intentado leer sobre EVO project/value management pero encuentro el material muy complicado y prolijo. ¿Has usado esto con éxito? – Joanne
Creo que esta pregunta sería buena para [Programmers.SE], si no es demasiado viejo para migrarla. –