Gestión de la fluencia del alcance en Agile

TL;RD

El desplazamiento del alcance es un riesgo del proyecto y debe controlarse. Sin embargo, en marcos ágiles, el alcance es una restricción variable en lugar de fija. Para ser un agilista eficaz, es necesario comprender las diferencias entre el alcance y el control de cambios, y cómo aplicar correctamente un marco ágil dado para adoptar el cambio (que es un valor central) sin poner en riesgo el proyecto en general.

Esto generalmente implica acuerdos de colaboración, control de cambios basado en iteraciones, transparencia y comunicación efectiva con las partes interesadas. Las prácticas ágiles no desean cambios de alcance en el campo de maíz; en cambio, ajustan otras restricciones para hacer visible el costo del cambio para que la empresa pueda tomar decisiones estratégicas informadas.

Ámbito de gestión

[S]i evita que ocurra un aumento del alcance en el proyecto, ¿cómo puede decir que el proyecto es ágil?

En un marco ágil, el aumento del alcance es realmente un problema causado por la inyección de trabajo nuevo o no planificado en medio de una iteración, en lugar de agregar alcance al proyecto general. Todos los marcos ágiles resuelven esto a través de procesos y ceremonias formales. En Scrum, por ejemplo:

1. Por lo general, el nuevo trabajo solo debe introducirse durante la planificación del Sprint.
2. El nuevo trabajo que tiene prioridad sobre el trabajo actual requería la finalización anticipada del Sprint actual y el regreso a Sprint Planning.
3. El propietario del producto debe priorizar el nuevo trabajo para el proyecto en colaboración con las partes interesadas, por lo que el avance del alcance a nivel del proyecto se gestiona a través del consenso de que el trabajo propuesto es relevante para los objetivos del proyecto.
4. En Scrum, las iteraciones son una caja de tiempo fija con un costo relativamente fijo (excluyendo los costos de capital), pero el alcance es una restricción variable.
5. El "desplazamiento del alcance" en el sentido comercial tradicional del término extenderá el tiempo de ejecución total del proyecto. Al agregar alcance al proyecto, impacta el cronograma (generalmente lo hace más largo). Usted gestiona esto a través de la transparencia y las comunicaciones efectivas con las partes interesadas.

Kanban y Lean tienen mecanismos similares para gestionar el cambio. El punto es que no hay almuerzo gratis. Agregar alcance agrega costo o tiempo al proyecto.

Compensaciones

El triángulo de gestión de proyectos generalmente se entiende como un conjunto de controles deslizantes que consisten en alcance, cronograma y costo. (Nota: hay otros modelos, pero este es el más común).

El objetivo de esta metáfora es que administras la calidad ajustando los controles deslizantes, pero son interdependientes. No puede fijar el costo, el cronograma y el alcance al mismo tiempo, por lo que un mayor alcance generalmente también aumentará los costos y el cronograma de un proyecto, mientras que a menudo reduce la calidad general a medida que la organización intenta aumentar el alcance sin aumentar los costos o extender el cronograma.

Como gerente de proyecto, debe poder articular las ventajas y desventajas del proyecto. En su caso específico, debe tener una comprensión más profunda de cómo se realizan esas compensaciones dentro de un contexto ágil y qué herramientas proporciona su marco para administrar y comunicar sobre esas compensaciones.

Por lo general, respondo diciendo que los requisitos deben definirse claramente antes de que comience el proyecto, y si hay algún cambio durante el proyecto, entonces debe pasar por un proceso de control de cambios que involucra a la junta de control de cambios, etc. etc.

Sus entrevistadores tienen razón: esto no es ágil.

El punto de ágil es que los requisitos cambian. Su comprensión del problema cambia. Tu comprensión del mercado cambia. Lo que pensó que necesitaba construir en enero no es lo que sabe que necesita construir en junio.

Si insiste en definir sus requisitos por adelantado, sucederá una de dos cosas:

1. construirá según las especificaciones y descubrirá que ha construido algo incorrecto
2. ignorará los requisitos, lo que hará que el proceso de definición de requisitos sea un esfuerzo desperdiciado y los requisitos mismos sean un documento muerto

(Hay ciertas excepciones , que involucran problemas de ingeniería extraordinariamente bien entendidos, restricciones extraordinarias y presupuestos extraordinarios. Si le hacen estas preguntas, es casi seguro que no está en uno de esos proyectos).

Ahora: arrastre de alcance. En una primera aproximación, no existe tal cosa como el desplazamiento del alcance en un proceso ágil que se ejecuta sin problemas. Hay un nuevo alcance , nuevas prioridades y nuevos requisitos, que conducen a un nuevo trabajo, pero no se arrastra .

El primer problema con el aumento del alcance en un proceso tradicional es cuando la organización se miente a sí misma. Prometió ofrecer características F en el tiempo T con un cierto nivel de calidad Q . ( Q probablemente nunca se hizo explícito, y probablemente nunca ibas a hacer T de todos modos, pero no importa). Pero ahora has redefinido silenciosamente F para que signifique F+1 , F+2 , hasta quién sabe, 2F , 3F vale la pena el esfuerzo, sin nunca hacer explícitamente las compensaciones a T o Q . Así que T se va a deslizar, yQ va a fallar, pero nadie va a admitir que nadie fuera de la organización de desarrollo sabe lo que está pasando, así que en algún momento después del momento crucial, cuando finalmente lo admitan y les den las malas noticias a sus partes interesadas, van a (justificadamente ) voltear sus tapas.

Este es el problema que su tablero de control de cambios, etc., está diseñado para prevenir: ese ciclo de negación y cambio.

Pero, incluso con un proceso de control de cambios que mantiene la honestidad de la organización, tiene otro problema. Se propuso entregar F by T , y ahora aumentó el alcance y amplió la línea de tiempo y está en camino de entregar 3F by 3T . Desde el punto de vista del equipo de desarrollo, todo está bien.

La organización más grande, sin embargo, está en serios problemas porque no ha enviado ningún software. Estás perdiendo ventas (o participación mental, en un proyecto de código abierto) frente a tus competidores más ágiles que las han perdido, incluso si solo han enviado funciones equivalentes a F/2 . Está perdiendo la oportunidad de obtener comentarios de los usuarios, por lo que sus suposiciones sobre las funciones que desean sus usuarios no se están marcando como realidad, y si finalmente envía 3F , es probable que descubra que no es lo que ellos quieren; ha desperdiciado 1F-2F de esfuerzo y tiene otros 2F-3F por delante solo para ponerse al día.

Es por eso que el Manifiesto Ágil dice que el software de trabajo es la medida principal del progreso. Fundamentalmente, el desarrollo ágil es bastante simple:

• construyes algo pequeño
• lo envías
• tú construyes la siguiente pequeña cosa

Los detalles tienen que ver con descubrir cuál debería ser la próxima pequeña cosa y asegurarse de que esté construido con un nivel aceptable de calidad.

Cuando se rompe ágil, a menudo es en forma de desplazamiento del alcance. Esa cosa pequeña se vuelve más grande, y el tiempo que lleva enviarlo se hace más largo, y luego se hace aún más grande, y lo siguiente que sabes es que no has enviado nada durante tres meses e incluso si todavía tienes paradas diarias ( o scrums) y dividiendo el trabajo en iteraciones (o sprints) honestamente ya no puedes llamarte ágil.

Diferentes prácticas ágiles se defienden contra este problema de diferentes maneras.

El diseño de prueba primero, el desarrollo basado en pruebas, la integración continua y la entrega continua, cuando se aplican correctamente, garantizan que el software esté siempre listo para enviarse.

El póquer de planificación de alto nivel y la estimación de tareas de bajo nivel alientan a los desarrolladores a pensar en las funciones y asegurarse de que ellos y el propietario del producto tengan un entendimiento común antes de comenzar el desarrollo.

El desarrollo iterativo (que permite que nuevas tareas ingresen al flujo de trabajo solo en los límites de la iteración) limita la tasa de cambio de alcance, incentiva a los propietarios de productos a pensar en las características antes de pedirles a los desarrolladores que las entreguen y minimiza el problema del desarrollador: el latigazo cognitivo y la sobrecarga del cambio de contexto. de ser sacado de su flujo para abandonar una tarea y comenzar otra. El seguimiento de la velocidad y la programación basada en evidencia mantienen sus iteraciones realistas.

Los procesos de tipo Lean/kanban eliminan las iteraciones, pero "extraen" funciones del trabajo pendiente solo cuando los desarrolladores están listos para trabajar en ellas, es decir, después de que su función anterior haya pasado al control de calidad y/o se haya enviado.

La forma real de responder a sus entrevistadores es darles la vuelta a la pregunta. Cuando dicen "desplazamiento del alcance", ¿qué es lo que realmente les preocupa? ¿Les preocupa que el producto no se envíe a tiempo? ¿Les preocupa que la calidad sufra? ¿Están preocupados por el agotamiento del desarrollador? ¿Están preocupados por todo lo anterior y también porque no se enterarán hasta que sea demasiado tarde? Estas son preocupaciones relacionadas pero diferentes, y un buen proceso las abordará todas de manera relacionada pero separada.

En el mundo Lean, dicen que si quieres encontrar la causa raíz de un problema, siempre debes preguntar “por qué” cinco veces . Pregunte a sus entrevistadores por qué les importa el aumento del alcance y encontrará su respuesta.

tldr; Agile cambia el enfoque hacia el descubrimiento y la creación de una solución para las necesidades del cliente. Agile valora "Responder al cambio sobre seguir un plan" porque uno debe "Dar la bienvenida a los requisitos cambiantes" para "aprovechar el cambio para la ventaja competitiva del cliente"

Puede ser útil comenzar con una comprensión del modelo clásico Triángulo de hierro, también conocido como Triángulo de gestión de proyectos. La base es que hay tres atributos para controlar (alcance, costo y tiempo) que afectan la calidad.

Veamos primero la gestión de proyectos clásica. Al principio, el alcance es fijo, luego el PM espera estimar adecuadamente el costo y el tiempo. Una vez que se hayan escrito todos los requisitos, se puede comenzar a trabajar. A medida que surgen cambios y problemas, es necesario ajustar algo. Una solución común es agregar más personas, consulte The Mythical Man-Month , que agrega costo. Siendo realistas, una vez que comienza un proyecto, los otros dos aspectos (costo y tiempo) también se fijan; cualquier aumento a cualquiera se considera fracaso. El resultado principal es la falta de calidad, a menudo también por encima del presupuesto y con retraso, a veces incumpliendo los acuerdos de alcance, con mucha frecuencia no satisfaciendo la necesidad del cliente o perdiendo la oportunidad de mercado.

Ahora veamos la filosofía ágil. En lugar de crear un conjunto completo de especificaciones (alcance) al principio y luego intentar predecir el costo y el tiempo, se identifica la necesidad principal. Se crea un backlog para representar los deseos: deseos que pueden o no ser requisitos reales. Luego, esta lista se clasifica en orden de valor para el cliente. El desarrollo comienza con los elementos básicos de mayor valor. Una cosa importante a tener en cuenta aquí es que el enfoque ya se ha cambiado a una mentalidad y enfoque de solución (o producto) sobre la mentalidad clásica de proyecto. El equipo trabaja en plazos reducidos, costo y tiempo fijos, para entregar la solución en incrementos pequeños, utilizables y de calidad. El alcance es flexible porque se realizan ajustes a medida que el cliente y el equipo comprenden más acerca de lo que realmente se necesita; agregan lo que inicialmente faltaba en los deseos y eliminan lo que ahora se considera innecesario o de poco valor. El trabajo puede detenerse al final de cualquier iteración cuando se alcanza el nivel adecuado de funcionalidad (alcance).

En el manifiesto Agile esto se describe con este principio:

La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.

Gestión de productos

El Propietario del Producto debe administrar el avance del alcance en la acumulación. Esta es cualquier planificación antes de que el equipo de desarrollo comience a trabajar en ella. Cumpliendo objetivos comerciales, no solo funciones de software. Los propietarios de productos podrían practicar algo como el mapeo de impacto para encontrar cómo las nuevas funciones tienen impacto para demostrar que la función no solo es agradable de tener, por ejemplo, alcance lento.

Equipo de desarrollo

Los desarrolladores pueden evitar el avance del alcance mediante el desarrollo basado en pruebas. Las pruebas pueden ser pruebas unitarias o criterios de aceptación. Piense primero y "documente" lo que quiere construir antes de construirlo, al igual que sus requisitos, pero justo a tiempo.

Una forma en que los usuarios de XP se mantendrían honestos es insistir en que escriban una prueba unitaria fallida (demostrando la necesidad de complejidad) ANTES de agregar la complejidad adicional al sistema.

http://www.agilenutshell.com/yagni

Entonces no implemente más funcionalidad de la necesaria para pasar una de las pruebas.

En resumen YAGNI (No lo vas a necesitar). Esto debería funcionar tanto para el alcance funcional como para limitar la tendencia del desarrollador a sobrediseñar un sistema.

Creo que hay diferentes respuestas a esta pregunta, dependiendo del contexto.

CodeGnome ha cubierto bien el alcance de alto nivel "fuera del sprint": básicamente agrega elementos a la cartera de pedidos y amplía el proyecto o elimina otras características.

Dentro del sprint, esta pregunta es un poco más sutil. Creo que es importante diferenciar entre "Scope Creep" y "Gold Plating", y "Change from learning".

La fluencia del alcance y el enchapado en oro deben empujarse fuera del sprint y manejarse como se indicó anteriormente. El equipo tiene un objetivo establecido con historias con criterios de aceptación y, debido a la naturaleza de los proyectos ágiles, los requisitos suelen ser vagos cuando el trabajo se lleva a cabo en un sprint. A menudo, durante el desarrollo, a medida que avanza el trabajo, surgen muchas preguntas sobre "¿deberíamos hacer X como parte de esto?" Donde es importante entrenar al equipo para que siga los principios de maximizar el trabajo no realizado y trabajar de manera efectiva para entregar lo mínimo para cumplir con la historia y la meta del sprint.

Sin embargo, el "cambio de alcance" es la esencia del valor entregado por Agile. Aprender de un sprint puede cambiar por completo la acumulación de productos, lo que le permite ofrecer mucho más valor de lo que se planeó anteriormente, en el mismo tiempo o potencialmente en menos tiempo. Al sacar algo temprano y obtener comentarios, se ven las enormes ganancias positivas de Agile, y este es un elemento positivo en lugar de potencialmente negativo del avance del alcance tradicional.

Primero, debe determinar exactamente qué quieren decir con "desplazamiento del alcance", ya que diferentes personas pueden considerar que el significado exacto es diferente.

¿Significan que no hay cambios de alcance, en absoluto, en absoluto?

• Es difícil llamar a esto 'Ágil', de verdad. Si bien aún podría ser posible cambiar el tiempo y/o el presupuesto, el hecho de que no pueda aceptar las necesidades cambiantes de los clientes sería un gran problema en cualquier tipo de proyecto Agile.

¿Significan que no aumenta el alcance , pero sacar cosas y volver a colocarlas está bien?

• Esto es bastante sencillo; cuando se necesita un cambio de alcance, solo necesita determinar qué sacar del alcance. Normalmente, otra opción sería agregar tiempo o costo (aunque, en muchos casos, el tiempo es lo único útil, ya que muchas formas de gastar dinero en un proyecto tardío, ya sea a través de nuevos miembros del equipo o nueva tecnología, solo lo harán más tarde debido a a los costos hundidos de tiempo iniciales). En este caso, sin embargo, hacerlo sería un 'desplazamiento del alcance' y, por lo tanto, su única opción real es administrar el alcance, agregando y eliminando del alcance para un cambio neto de cero (o negativo, si resulta que realmente después de todo, no necesitaba esta gran función X, por lo que puede reemplazarla fácilmente con la función Y más pequeña).

¿Significan que cualquier tipo de cambio de alcance está bien, pero no con demasiada frecuencia o fuera de control?

• Esto también es sencillo, aunque de una manera diferente. Simplemente necesita un procedimiento riguroso de gestión de cambios, en el que todos y cada uno de los cambios de alcance se evalúen de manera adecuada/completa y se responda en consecuencia (ya sea que la respuesta aumente el tiempo, saque algo más del alcance, encuentre alguna otra solución o simplemente rechace por completo). el cambio de alcance).

Puede haber otro significado que tengan la intención de usar 'desplazamiento del alcance', pero creo que los tres anteriores son los más comunes. Si todo lo demás falla, abandone cualquier noción preconcebida y simplemente piense qué tipo de reacción, dentro de las limitaciones dadas, sería necesaria para aportar valor al proyecto, a la empresa y al cliente. Al final, aportar valor es de lo que se trata Agile.

Mi opinión (IANASM) es que no existe tal cosa como "desplazamiento del alcance". En Agile, debería estar trabajando en las características más valiosas para el negocio en este momento, durante un período de tiempo corto (el sprint actual, en términos de Scrum).

Debe existir una acumulación de trabajo que es propiedad del propietario del producto, y lo mantienen en orden de lo que será más valioso para trabajar a continuación.

Si surge alguna información nueva, el propietario del producto es libre de reordenar esa lista de trabajo y priorizar ciertas características sobre otras características en función de lo que sabe en ese momento.

Cuando finaliza el sprint/iteración actual, el equipo selecciona el siguiente conjunto de características que creen que pueden completar en la próxima iteración.

El concepto es que esas iteraciones deben ser lo suficientemente largas para obtener un conjunto de características completamente "terminado" (para la definición de "terminado" de su equipo, es decir, implementadas para producir), pero no tanto como para que los cambios en el negocio no reaccionen. lo suficientemente rápido.

Scrum, al menos, habla de poder terminar un sprint antes de que esté terminado, pero está hecho para ser una operación costosa y disruptiva, por lo que no debe hacerse por capricho.

Agile debe equilibrar el compromiso con un conjunto de trabajo y un período de tiempo para hacer ese trabajo que no ponga nerviosos a los propietarios de productos porque nunca obtendrán "lo siguiente".

Agile tiene que ver con las prácticas que funcionan con requisitos que cambian continuamente. Se supone que los requisitos y el plan tienen una alta probabilidad de ser subóptimos incluso dentro de tres meses, porque:

• El contexto cambia
• Las opiniones y puntos de vista maduran o cambian
• Intentar una solución es una experiencia de aprendizaje que arroja nuevos conocimientos sobre el problema y las posibles soluciones.

Esta es una cita de Programación extrema explicada :

XP es un camino de mejora hacia la excelencia para las personas que se unen para desarrollar software. Se distingue de otras metodologías por:

• Sus cortos ciclos de desarrollo, que dan como resultado una retroalimentación temprana, concreta y continua.
• Su enfoque de planificación incremental, que genera rápidamente un plan general que se espera evolucione a lo largo de la vida del proyecto.
• Su capacidad para programar de manera flexible la implementación de la funcionalidad, respondiendo a las necesidades comerciales cambiantes.
• Su confianza en pruebas automatizadas escritas por programadores, clientes y probadores para monitorear el progreso del desarrollo, permitir que el sistema evolucione y detectar defectos temprano.
• Su dependencia de la comunicación oral, las pruebas y el código fuente para comunicar la estructura y la intención del sistema.
• Su confianza en un proceso de diseño evolutivo que dura tanto como dura el sistema.
• Su confianza en la estrecha colaboración de personas activamente comprometidas con talento ordinario.
• Su confianza en prácticas que funcionan tanto con los instintos a corto plazo de los miembros del equipo como con los intereses a largo plazo del proyecto.

Hay muchas buenas respuestas aquí, pero pensé en intentar dar una respuesta más corta para ver si ayudaría.

No existe tal cosa como Scope Creep. Sólo hay una comprensión más profunda.

Esto supone solo algunas cosas:

1. Tú y tu cliente confían el uno en el otro lo suficiente como para colaborar con frecuencia.
2. Si tiene una entrega fija, puede flexibilizar el alcance
3. Si el alcance es fijo, puede flexibilizarse en la entrega
4. Construyes lo que sabes que es valioso para tus clientes
5. ¡Usted no envía $#^!

Se requiere uno para dos y tres. Cuatro y cinco forman el número uno. Es un ciclo armonioso que es fiel al Manifiesto Ágil y que Scrum encarna.

Amplié esto aquí , si desea profundizar más.