¿Es posible adoptar un enfoque ágil y flexible para proyectos que requieren estimaciones tanto del tiempo empleado como del tiempo ahorrado?

Como alguien que ha trabajado efectivamente con Agile antes, estoy tratando de convencer a mis empleadores actuales de sus beneficios. Sin embargo, la gerencia insiste en que conservemos la capacidad de hacer estimaciones iniciales para evaluar el valor comercial de los proyectos.

La mayoría de mis clientes son internos, y recientemente me encargaron reunir equipos y pedirles ideas sobre procesos comerciales para automatizar. Entonces debía averiguar cuánto tiempo les llevaba esto, calcular cuánto tiempo ahorraría la solución y calcular el tiempo total de desarrollo. De esa forma, los gerentes podrían intentar medir cuán efectiva es probable que sea una solución en términos de tiempo ahorrado.

Sin embargo, me parece que no hay forma de abordar este requisito de una manera "ágil". Los requisitos flexibles significan que no solo las estimaciones del tiempo tomado serán incorrectas, también lo harán las estimaciones del tiempo potencial ahorrado. Lo expliqué, expliqué por qué era probable que fuera problemático, pero me dijeron que no era negociable.

La pregunta Cómo vender desarrollo ágil a clientes (en cascada) tiene algunos consejos útiles sobre cómo "vender" ágil a clientes externos. No estoy tratando de venderlo a clientes externos: estoy tratando de encontrar la mejor manera de conciliar las demandas de la administración interna y al mismo tiempo mantener una metodología que creo que funciona bien.

¿Hay alguna forma de abordar esta tarea de manera flexible que me permita retener al menos algunos beneficios ágiles?

Como han dicho otras respuestas, la Administración tiene todo el derecho de obtener una estimación de alto nivel por adelantado de un proyecto. No son irrazonables para tratar de determinar el ROI.

Sin embargo, uno de los enfoques que me gusta de Agile es que el alcance de un proyecto no es fijo. Puede dimensionarse inicialmente en el nivel de Función y Épico, luego las empresas pueden determinar el ROI en función de cuáles son las características más importantes. Tal vez la elegante interfaz de usuario con campanas y silbatos tiene un bajo valor comercial, pero el motor de flujo de trabajo para manejar reclamos tiene un alto ROI.

Cuando agrupa todo el proyecto, es más difícil alcanzar el ROI que si se enfoca en la funcionalidad comercial crítica que se desea.

Aquí hay una manera en que he hecho esto:

Tome sus hitos de WBS y convierta cada uno de estos en una función entregable

Esto le permite clasificar su proyecto en mini subproyectos que tienen un valor comercial variable. Cada uno de estos debe ser independiente en términos de valor comercial.

Tamaño de camiseta el esfuerzo en las características

Esta es una manera muy fácil de tener una idea aproximada de cuán grande o involucrada podría ser una característica en particular. Quizás las características de bajo valor aún tengan un gran ROI si parecen ganancias fáciles.

Descomponer una característica en historias

Realice el ejercicio para encontrar una pequeña característica que se entienda bien y desglosarla en historias inicialmente. Estima estas historias por puntos. Ahora tienes una base donde

Pequeño -> 40 puntos

Esto será una base de comparación con otras características

Asociar el esfuerzo de puntos de historia a todas las características

Compare su pequeña característica con otras características. Por ejemplo,

Medium Feature Y parece que es el doble del tamaño y el esfuerzo de Small Feature X de 40 puntos de historia.

La característica media Y es probablemente 80 puntos de historia. Continúe esto hasta que tenga puntos de historia estimados en un nivel alto para todas las características.

Estima la velocidad de tu equipo

Mirando a su equipo de desarrollo, intente determinar cuántos puntos de historia podría entregar este equipo de manera efectiva en un sprint determinado. Si tiene proyectos Agile anteriores como ejemplo con este equipo, es un excelente lugar para comenzar. Si no tiene ese historial detrás del equipo, realice un simulacro de planificación de Sprint con su equipo en el que comenzará a ver su característica Pequeña que ha detallado. ¿Qué tipo de estimaciones por hora están dando las personas por sus tareas en estas historias?

Según la cantidad de trabajo que el equipo cree que puede entregar en 2 semanas, ¡use ese número total de puntos de la historia como la velocidad potencial promedio de su equipo!

Encuentra tu fecha de finalización proyectada

Si su equipo en la planificación simulada del sprint se siente cómodo al entregar 25 puntos de historia en un sprint, y su cartera total parece 300 puntos de historia para la versión dorada de Cadillac de su proyecto, entonces parece que su equipo idealmente tomaría 12 sprints o 24 semanas para Completa todo.

Ahora es trivial convertir el costo de los recursos de su equipo en dólares por semana para llegar a un costo por ROI versus valor comercial. La negociación puede continuar sobre cuáles son las características más importantes y luego la gestión de su proyecto se convierte básicamente en un problema de mochila.

Esto no es un problema con la "gestión". Es un requisito absoluto poder estimar el costo y el beneficio de cualquier proyecto potencial antes de comenzar. De lo contrario, ¿cómo podría alguien saber lo que vale la pena hacer (o intentar)?

Entonces, ¿por qué ágil?

Yo diría que usar métodos ágiles no es elegir incertidumbre. Más bien, Agile es un argumento de que la incertidumbre es inevitable, y las especificaciones detalladas y las estimaciones de los métodos tradicionales introducen una certeza falsa, lo que puede ser bastante costoso.

Algunos puntos clave en términos de estimación de tiempo:

• Los cambios a los requisitos a lo largo de un proyecto son inevitables; Agile toma esto en cuenta en lugar de pretender que no habrá cambios.
• Las especificaciones detalladas a menudo contienen fallas de diseño que no se descubren hasta bien entrado el proyecto. Esto puede significar cambios mayores en un proyecto tradicional que uno ágil.
• Una estimación de tiempo basada en "¿qué tan importante creo que es todo este proyecto?" es probable que sea tan preciso como sumar el tiempo estimado para muchos requisitos detallados.
• Lo principal que conduce a buenas estimaciones es un ciclo de estimación, medición y revisión, que se puede aplicar a cualquier proceso consistente.
• La estimación del "trabajo ahorrado" dependerá de los requisitos primarios del proyecto en lugar de los detalles, por lo que dudo que Agile perjudique mucho la capacidad de estimar esto.

Actualizar:

Solo para aclarar, su respuesta a sus jefes parece ser "No podemos estimar muy bien el tiempo ahorrado o el esfuerzo de desarrollo total usando Agile, porque es flexible". Creo que esto está equivocado. Creo que estas estimaciones se pueden hacer igual de bien cuando se utiliza un proceso ágil, ya que la incertidumbre existe de todos modos. Y, por supuesto, Agile permite un proceso más flexible y receptivo a medida que se desarrolla el proyecto.

Esta es sin duda una de las partes más difíciles de presentar Agile.

"La gerencia aún necesita estimaciones de tiempo"

Mi enfoque es:

• Almohadilla 300%. El viejo dicho del 300% es útil cuando te encuentras en una situación en la que no serás muy ágil a nivel gerencial. Quizás este no sea un "enfoque ágil", pero es un compromiso para esta situación. Podrás adelantarte varias veces, ¡pero no cuentes con ello!

• Solicite una revisión basada en el trabajo realizado en lo que sería el punto "intermedio" del proyecto. Proyecta cuándo estarías completo según el trabajo realizado Luego, hable con la gerencia y analice cuáles sacrificar (funcionalidad o calidad) dado que el tiempo se fija en función de las suposiciones al comienzo del proyecto.

• Asegúrese de colaborar en las funciones realizadas y la calidad con la administración para que realmente tomen esas decisiones

• Siga la corriente de este proyecto y permita que sucedan las cosas habituales: plazos vencidos, calidad comprometida, empleados agotados y estresados ​​(y posiblemente despedidos) que se van. Cuando surja el próximo proyecto de fase, discuta estos 'efectos secundarios'.

• Enfocar y demostrar las ventajas de un enfoque ágil "verdadero". Hable acerca de la mejora en la calidad. Hable acerca de la capacidad de hacer cambios al final del día hasta que entren en producción. Hablamos de menos necesidad de volver a trabajar. Hable acerca de una deuda menos técnica que eventualmente llevará el desarrollo a un rastreo. Haga analogías con el mundo real, por ejemplo, podemos posponer un cambio de aceite cualquier día, pero posponerlo el tiempo suficiente y el motor sufre, funciona mal y eventualmente sopla una varilla.

• Mantenga actualizado su currículum y el perfil de LinkedIn. Si no puede obtener asistencia administrativa después de presentar su caso varias veces, continúe. Algunas organizaciones no se incluirán en sus argumentos, así que pase a las que sí lo hacen. Lo llamó empleo darwinista;)

Creo que está haciendo suposiciones falsas sobre el desarrollo ágil. La flexibilidad y los requisitos cambiantes están literalmente incluidos en el Manifiesto Ágil .

Bienvenido a los requisitos cambiantes, incluso tarde en el desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente.

Los requisitos flexibles (léase: cambiantes) son bienvenidos en Agile. Si le preguntas a la mayoría de los desarrolladores, agregarán una advertencia de que el cambio debe ser razonable. Pedirle a un equipo que construya un juego en 3D y luego cambiar los requisitos para ser "sistema de control para un reactor nuclear" es un poco demasiado. Pero agregar, eliminar o modificar requisitos en el alcance del proyecto está perfectamente bien.

La pregunta es ¿cómo hacer frente a los requisitos cambiantes? La respuesta típica es usar iteraciones cortas para que pueda hacer ajustes en el curso desde el principio antes de perder demasiado tiempo. También obliga al equipo a descomponer los requisitos en partes más pequeñas para que todos puedan comprenderlos mejor e implementarlos en una cantidad razonable de tiempo y esfuerzo.

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

También me gusta este principio ágil. Normalmente se da a entender que un equipo debe esforzarse por entregar solo aquellas cosas que son necesarias a través de una eficiencia despiadada. Por ejemplo: si el cliente cree que necesita algo pero parece sospechoso, busque. Tal vez los usuarios finales realmente no lo usen, por lo que el trabajo no debe hacerse.

Sin embargo, creo que su pregunta golpeó otro aspecto de este principio. El software generalmente sirve para automatizar un proceso manual. El software en sí existe para maximizar la cantidad de trabajo no realizado por los usuarios finales.

La medición de la cantidad de trabajo que el software ahorrará a los usuarios finales es definitivamente una medida valiosa. Lo he medido yo mismo en mi carrera. En realidad, es un componente crítico de un análisis de costo / beneficio: cuánto esfuerzo tomará el proyecto de software para implementar, en comparación con cuánto esfuerzo ahorrará el producto final a los usuarios finales.

Esto es absolutamente compatible con la filosofía de desarrollo ágil (o cualquier otra) y su gerencia debería aceptar esto.

Sí, la agilidad tiene algunas ventajas.

• Permite a las personas de negocios cambiar de opinión en pleno vuelo.
• De alguna manera protege al negocio contra las estimaciones perpetuamente malas del ingeniero.
• Ofrece valor temprano y, a menudo, antes de lograr la visión final.
• Le ahorra parte del costo de planificación inicial, que a menudo puede producir un mal plan de todos modos .
• Es super guay. ¿Correcto?

Pero, aún necesita dar estimaciones iniciales razonablemente precisas.

Si no lo hace, efectivamente le está pidiendo a la empresa que invierta en su producto sin ninguna evidencia de que su producto valga la inversión inicial, y en algunos casos, cualquier cosa.

Y puedo escucharlo ahora.

Lo he escuchado antes. Estoy bastante seguro de que tengo dicho antes:

Oh - Pero ¿¡Haow !? ¡HAOW un simple hombre mortal como yo mira mis ojos al destino de tales cosas! Cosas que solo los dioses mismos pueden adivinar y dirigir. ¡Cosas que los hombres mortales solo pueden soñar en el sueño más profundo y olvidar al despertar del día! Oh, tipos de gestión tiránicos, ¡HAOW, pueden satisfacerse tales demandas !?

Use su desempeño anterior como guía y sea ​​honesto .

• Tenga suficiente conversación con la parte interesada y / o el usuario final para determinar qué tan complejo es el producto y / o sus componentes principales en relación con otros componentes principales en los que ha trabajado. Haga una estimación inicial de punto relativo.
• Infle ese número por la cantidad histórica de cambios en el alcance y las consecuencias de errores que ha visto históricamente.
• Aplique su velocidad histórica a la estimación puntual para llegar a una línea de tiempo aproximada. Y aplique un cono razonable de incertidumbre .
• Vuelva a revisar su estimación y comprensión del proyecto. Puede estar seguro de que usted estaría dispuesto a tomar una decisión sobre la lucha contra un proyecto basado en su evaluación.

Finalmente, presente su cono de incertidumbre a las partes interesadas, exponga sus suposiciones y preocupaciones y déjelo así.

Como comentario adicional, también sugeriría proponer una heurística objetiva de estimación puntual para verificar su cordura y / o las estimaciones normales de su equipo.

Puedes usar esta estimación como un enésimo voto durante la planificación del póker, o al validar tu estimación privada si vas solo. Por ejemplo, mi equipo tiende a estimar aproximadamente 1 punto por minuto de discusión de descubrimiento poco técnica sobre una historia. Esto es especialmente útil si tu instinto te dice que una historia tiene 5 puntos, pero te tomó 20 minutos entender lo que hay que hacer; por lo general, es un buen indicador de que todavía hay complejidades y malentendidos al acecho.

Nunca he trabajado en ninguna compañía que haya podido tener estimaciones de tiempo consistentemente buenas, ni he trabajado con alguien que afirme haberlo hecho tampoco. La búsqueda le mostrará que la estimación es un problema no resuelto en toda la industria.

Trataría de obtener una aceptación sobre la medición de la velocidad basada en puntos abstractos de la historia, y si no puede hacer eso, rellenaría sus estimaciones más.

Ágil es una gran solución para una amplia gama de problemas, pero a pesar de lo que algunos evangélicos sugerirían, no es la única solución y no siempre es la solución correcta.

Su caso declarado simplemente no es un problema ágil:

Recientemente tuve la tarea de dar la vuelta a los equipos y pedirles ideas sobre procesos comerciales para automatizar. Entonces debía averiguar cuánto tiempo les llevaba esto, calcular cuánto tiempo ahorraría la solución y calcular el tiempo total de desarrollo. De esa forma, los gerentes podrían intentar medir cuán efectiva es probable que sea una solución en términos de tiempo ahorrado.

Tiene la tarea de determinar el costo y el beneficio de automatizar algunos procesos comerciales, que no es una tarea ágil sujeta a cambios, es un problema específico con una solución específica. Producirá una lista con un número arbitrario de procesos de negocio y para cada uno, habrá un costo estimado de automatización, un costo estimado de no automatización y un beneficio estimado de la automatización. La gerencia comparará esto con sus presupuestos, recursos, requisitos y objetivos estratégicos y determinará cuál (si alguno) de estos procesos se automatizará. Si eres concienzudo, entonces habrás resaltado tareas seleccionadas que tienen un ROI potencialmente más bajo en sí mismas, pero que reducirán el costo de otras fases, mejorando así el ROI total. También puede haber identificado diferentes formas de lograr la automatización, incluido el desarrollo a medida interno y externo (utilizando técnicas ágiles y / o en cascada), comprando soluciones estándar, utilizando proveedores de servicios de terceros, etc. Todo este proceso estuvo muy de moda en los años 90, cuando se conocía como reingeniería de procesos comerciales.