gran cuadro con la planificación ágil

Question

he hecho un poco de lectura bastante a fondo y buscar a través de SO y no encontró nada sobre este tema, así que espero que no estoy creando una víctima. Si esto se ha preguntado antes, agradecería un enlace.

Trabajo para un taller de desarrollo de la empresa que actualmente está utilizando un proceso de cascada sobre todo para los proyectos de desarrollo de software. He leído muchos libros y artículos sobre metodologías ágiles, y puedo ver cuánto podría mejorar realmente nuestro proceso. También puedo imaginar cómo se pueden aplicar muchas prácticas en el nivel de desarrollador, es decir, codificación de pares, iteraciones más cortas, refactorización, TDD, etc. Ya estamos haciendo mucho de eso.

El gran vacío en mi mente, y en la mente de la gestión de nuestra organización, es así como la planificación a largo plazo sería trabajar en un proceso ágil. Antes de que podamos comenzar a trabajar en un proyecto, necesitamos tener un presupuesto aprobado por los clientes internos que están pagando por el software que estamos produciendo. ¿Cómo sabemos cuál debería ser ese presupuesto si no hacemos algunos requisitos y estimaciones bastante detallados por adelantado? Claro, nuestros requisitos y estimación no son perfectos (ya veces realmente no) pero son mejores que nada.

Una cuestión relacionada es cómo juzgar el estado a largo plazo de un proyecto durante la construcción. Si un producto de software en particular vale una cierta cantidad de dólares para la organización, ¿cómo saben si podremos implementar el producto antes de que terminemos gastando más de lo que vale? Puedo ver cómo funciona Agile cuando descubro qué trabajo puede hacer en la próxima iteración, pero ¿cómo calcula una estimación de cuál será la suma total de trabajo para obtener la versión 1.0 y si puede o no hacer eso? para el cuarto trimestre del próximo año?

¿Cómo ocurre esta planificación de nivel estratégico en una tienda Agile? ¿Acabas de arrojar estimados contra las historias de usuario vagas iniciales de las que comienzas? ¿No planifica a largo plazo de esta naturaleza? ¿Todavía tiene una fase de requisitos/diseño de alto nivel por adelantado y luego pasa a un proceso Ágil una vez que el proyecto no despega?

Gracias,

~ Justin

Answer 1

La planificación de imágenes grandes con Agile puro es extremadamente difícil. El primer gran problema es (como has visto) que la planificación puramente ágil y avanzada (presupuestos, escalas de tiempo a largo plazo, etc.) fundamentalmente no funcionan bien juntas.

Si está familiarizado con el project management triangle (alcance, costo, escala de tiempo), el enfoque de Agile es fijar costos y programar y permitir que el alcance sea variable. En las organizaciones grandes, el alcance y el cronograma a menudo son fijos (necesitamos el producto X con estas características para el próximo trimestre) y luego pasa la mayor parte de su tiempo discutiendo el costo (es decir, el número de desarrolladores) y a menudo termina entregando tarde porque la escala de tiempo y el costo permitido simplemente no fue suficiente.

Esto nos lleva al segundo problema: el cambio de mentalidad necesario para ejecutar Agile puro en un entorno empresarial tradicional. El consejo ideal sería lograr que su organización compre en Agile al por mayor y reconozca que pueden crear un retraso en las funciones, pero que no todas pueden entregarse. Sin embargo, lo que se entregue será de alta calidad, a tiempo y con un costo conocido. Cambiar a Agile puro puede resultar en un cambio serio del pensamiento organizacional como Mike Cohen's book se describe expertamente.

Desafortunadamente es muy difícil cambiar el pensamiento de toda una organización a partir de la parte posterior de un solo proyecto, por lo que la tercera vía es un compromiso: no se trata de Agile puro. Lo que usted hace es algo como RUP/Waterfall donde hace un análisis inicial de los requisitos y hace un poco de trabajo de diseño y arquitectura. Solo lo suficiente para resaltar las áreas de riesgo y comprender las complejidades de la gran imagen. Luego ejecuta una iteración "0".

Iteration 0 es un desarrollo de prueba de concepto para las áreas de alto riesgo y para ayudar a comprender las estimaciones clave y el rendimiento del equipo. Este puede ser un prototipo que se descarta, puede ser el fundamento del marco de trabajo de tu aplicación, pero el punto importante es obtener una sensación fundamentada de la calidad de las estimaciones y la velocidad probable del equipo, etc. Esto te proporciona una base sobre la cual construir algunos planes y establecer un presupuesto probable.

Luego puede ejecutar el trabajo de desarrollo como iteraciones Agile normales, cosechando los beneficios de la retroalimentación y visibilidad temprana del usuario, etc. El enfoque iterativo también ayuda a proporcionar hitos regulares para realizar un seguimiento del plan, permitir puntos de replanificación y advertencias previas de presupuesto over/under-runs. Use las estimaciones/datos actuales hasta la fecha para volver a trabajar los planes futuros sobre la marcha.

Answer 2

Al hacer la planificación estratégica, los clientes internos tienden a preocuparse más acerca de las características que los requisitos.

que tienden a crear una hoja de ruta de función por medio de una herramienta que apoya la trazabilidad (prefiero Enterprise Architect de Sparx Systems, pero muchas herramientas a hacer). Reviso las características deseadas y el orden en que se necesitan en el nivel del patrocinador del proyecto.

Luego, trabajo con las personas adecuadas (a veces expertos en negocios, analistas de negocios o personas de TI senior como arquitectos) para dividir cada función en un conjunto de requisitos de alto nivel. Creé la trazabilidad desde los requisitos de alto nivel hasta las características. En este punto, los requisitos a menudo están en el nivel de "Agregar una pantalla ABC", "Agregar una pantalla DEF", "Crear un proceso en segundo plano para volver a calcular XYZ", etc., sin más detalles. En este punto, trabajo con las personas adecuadas para estimar el esfuerzo para cada requisito de alto nivel en función de las métricas disponibles (desde sensaciones viscerales hasta estadísticas sobre cuánto tiempo, por ejemplo, las pantallas tardan en agregarse). Mi herramienta de modelado resume el esfuerzo total estimado para cada Característica, que luego se puede presentar a los patrocinadores del proyecto y colocar en un plan de proyecto.

Entonces comenzamos una iteración para hacer frente a la primera característica o conjunto de características. Cada requisito de alto nivel se refina en requisitos detallados ("Pantalla ABC necesita un campo de Nombre, longitud máxima 40, requerida", etc.). Dependiendo de las necesidades del proyecto, podemos volver a estimar el esfuerzo para los requisitos más detallados y completarlos con el requisito de alto nivel que rastrean.Más comúnmente, un desarrollador será asignado para desarrollar Screen ABC, ingresará su propia estimación en la herramienta de planificación de sprints, y esa estimación se retrotraerá al modelo original. Dado que los requisitos que está implementando (y estimado) se remontan a los requisitos de alto nivel, que se remontan al nivel de característica, el plan se actualiza constantemente a medida que entramos en cada iteración.

Requiere un poco de disciplina y esfuerzo para configurar esto, pero bien vale la pena.

Answer 3

No haga proyectos donde el valor es tan bajo, que no es obvio que va a obtener un ROI razonable.

No intente con para crear certeza falsa donde no la hay. La planificación general es, y debe ser vaga.

Un proceso de implementación ágil permite al cliente orientarse y adaptarse. Si tiene un equipo experimentado, un dominio conocido y estable, ninguna nueva tecnología o metodología, conoce su velocidad. Esto también limita el tamaño de un proyecto que puede estimar. Los equipos cambian regularmente, la tecnología cambia cada pocos años.

Si un cliente necesita un presupuesto detallado, debe proporcionar historias de usuario a un nivel estimable. Eso significa que hay que hacer mucho trabajo por adelantado. Todos los picos de riesgo visibles tienen que hacerse. Ese trabajo solo vale la pena cuando los requisitos son suficientemente estables.

El nivel de detalle que Eric J. describe es totalmente innecesario. Eso debería estar en el software y extraerse de él, en lugar de estar especificado en papel de antemano.

[editar] Tener una lista de historias que no sean suficientemente entendidas por el cliente o el desarrollador puede ser interesante. No debes pasar mucho tiempo con ellos, ya que su estabilidad es baja. Usando la clasificación de los carros, puede tener una idea rápida del tamaño y la prioridad. En todas partes donde hay grandes diferencias de posición, usted tiene un riesgo potencial. Pedir a todas las partes interesadas que proporcionen nuevas historias puede ayudarlo a estimar la integridad.

Answer 4

¿Cómo hacer la foto grande Agile? Piénselo de esta manera: el objetivo principal de un analista de negocios en un proyecto de Waterfall es obtener un panorama general mínimo pero de calidad de los requisitos esenciales de comportamiento, y el objetivo principal de un analista de negocios en un proyecto Ágil es presentarlo con una visión general mínima pero de calidad de los requisitos esenciales de comportamiento.

Answer 5

"seguro" solucionar este problema mediante la financiación de los "trenes de liberación ágiles" en lugar de Proyectos:

http://www.scaledagileframework.com/budgets/