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

25

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?

Bob Tway
fuente
1
Si es posible, intente descomponer los proyectos en partes más pequeñas y ver si alguno de ellos será útil por sí solo, con las partes restantes construyéndose sobre ellos. El beneficio de la precisión de la estimación al reducir su cono de incertidumbre ( whatis.techtarget.com/definition/cone-of-uncertainty ) superará el costo de la flexibilidad.
Ben Aaronson
1
¿Actualmente puede hacer estimaciones precisas de cuánto tiempo llevará el desarrollo de un proyecto determinado?
Daenyth
2
@MattThrower ProTip: si la administración confía funciones de TI importantes a un único desarrollador, nunca tuvieron mucha fe o confianza en TI para empezar. Ciertamente, no parecen estar convencidos de que TI tenga un buen ROI o de lo contrario no estarían tan apretados en las cadenas de cartera.
maple_shaft
2
Si no puede convencer a la gerencia de que lo que está a punto de hacer ahorrará más dinero del que cuesta implementar, ¿por qué le pagarían por hacerlo? Agile es una metodología de desarrollo, no una metodología de proyecto. Su problema es convencer a otros de que sus estimaciones coincidirán con los reales. Cuando haces eso, no les importa cuál es tu metodología. Cada vez que cambian los requisitos, debe poder decir cuál es el efecto del cambio en el tiempo o el esfuerzo (y, por lo tanto, en el costo), de lo contrario, ¿cómo sabrán si el cambio vale la pena o no?
RobG
1
posible duplicado de Cómo vender desarrollo ágil a clientes (cascada)
mosquito

Respuestas:

25

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.

maple_shaft
fuente
2
+1 por ser la única persona (hasta ahora) que realmente responde la pregunta.
RubberDuck
2
Creo que esta respuesta pasa por alto el hecho de que, si bien la administración no es irrazonable para tratar de determinar el ROI, no son razonables (o al menos, extremadamente poco realistas) si esperan que tales estimaciones iniciales sean remotamente precisas en la práctica. Esta respuesta proporciona una buena explicación de cómo pronosticar las fechas de lanzamiento en Ágil. Pero supongo que el OP ya conoce esa parte, y estaba preguntando más sobre cómo puede proporcionar una estimación precisa garantizada por adelantado en un contexto ágil (o cualquier otro). La respuesta corta es que no puedes; por eso la gente usa Agile en primer lugar.
Aroth
@aroth Shhhh! ¡No les des el secreto a los Normies! Sin embargo, con toda seriedad tiene razón sobre las estimaciones, pero al menos Agile hace bien en comparar la complejidad relativa y puede permitir que se tomen decisiones difíciles con más información disponible. El software es un negocio desordenado y riesgoso y me parece que nada más parece dar una mejor idea sobre qué esperar en un proyecto a largo plazo.
maple_shaft
10

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.


fuente
Gracias por esto. Aprecio que todo el punto de Agile es generar incertidumbre en el proceso. Lo que me preocupa es que pensé que había ayudado a otros a entender esto, pero mi último lote de requisitos sugiere lo contrario.
Bob Tway
@MattThrower, agregué algunas ideas adicionales a la respuesta, porque no estoy seguro de que estuviera claro lo que estaba tratando de decir.
8

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;)

Michael Durrant
fuente
Su primera viñeta se conoce como el Principio de Scotty, y es 400% :-)
corsiKa
Si bien estoy de acuerdo en cierta medida con la regla del 300%, ¿deberíamos hacer eso para siempre ? Con un ciclo continuo de estimación, medida, revisión, ¿no deberíamos finalmente mejorar?
2
@ dan1111 En mi experiencia, ágil o no, no, no lo hace. La sobreestimación no se debe a que usted realmente sobreestime el proyecto, sino que siempre sobreestimamos cuán productivos somos y subestimamos los desafíos involucrados.
corsiKa
1
@ dan111: Una vez que tenga una velocidad medida razonablemente consistente , las estimaciones de su proyecto pueden basarse en puntos / sprint. Pero el instinto "tomará aproximadamente una hora de trabajo real" siempre necesitará ser rellenado porque, como dice corsiKa, lleva más de una hora hacer una hora de trabajo real. Lo único que queda por decidir es si el programador debe dar una estimación de "tiempo probable transcurrido" en lugar de una estimación de "esfuerzo real requerido" en primer lugar o si eso debe dejarse al proceso formal, que incluirá un factor de relleno de 300% o lo que se midió.
Steve Jessop
3

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.


fuente
1
Yo entiendo esto. No estoy seguro de que todos los demás en el negocio lo hagan.
Bob Tway
2
@MattThrower: Por lo que entiendo de su pregunta, su gerencia le está pidiendo que proporcione un análisis de costo / beneficio, como se describe en la segunda parte de esta respuesta. Probablemente necesiten eso para poder asignar fondos / personas al proyecto en primer lugar.
Bart van Ingen Schenau
@MattThrower Agile no es un argumento en contra de las estimaciones de tiempo. Si fuera entonces, el seguimiento de métricas como Velocity no tendría sentido ya que no tendrían un factor predictivo sobre el éxito futuro. Lo que Agile ofrece es más información y negociación sobre cuáles son las prioridades comerciales de un proyecto. Sin embargo, todavía necesitan las estimaciones para cada hito para tener esa discusión
maple_shaft
2

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.

svidgen
fuente
1

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.

Daenyth
fuente
Nunca he trabajado para una compañía que acordó comenzar un proyecto sin tener una idea de cuánto costaría y cuánto ganaría.
Paul Smith
1
Trabajé en empresas que tenían muy buenas estimaciones de tiempo. Pero eran empresas de servicios profesionales que repetidamente entregaron proyectos comparables e invirtieron mucho en metodologías. Fuera de ese sector, rara vez es el caso.
Alfred Armstrong
1

Á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.

Paul Smith
fuente