Predicciones de gestión de proyectos frente a flexibilidad Agile/Scrum

[...] cómo se equilibra el deseo de la empresa de algún tipo de estimación del esfuerzo general y el deseo de permanecer iterativamente ágil.

Infórmeles sobre por qué una gran estimación inicial puede ser completamente inútil.

El problema con la gente de negocios es que a menudo carecen de habilidades de gestión de proyectos y no entienden cómo ocurre el desarrollo de software. En consecuencia, desconocen la existencia del Cono de Incertidumbre y sus implicaciones :

• Las estimaciones (por ejemplo, sobre la duración, los costos o la calidad) son inherentemente muy vagas al comienzo de un proyecto
• Las estimaciones y los planes de proyecto basados ​​en estimaciones deben rehacerse periódicamente
• Las incertidumbres se pueden incorporar en las estimaciones y deben ser visibles en los planes del proyecto.
• Las suposiciones que luego resultan ser errores son factores importantes en la incertidumbre.

Cuando usted da estimaciones a la gente de negocios, porque no entienden lo que está involucrado, lo toman como su promesa de entregarles un producto, en un período de tiempo específico y a un costo específico.

Si su proyecto es pequeño (por ejemplo, un par de semanas o meses), tiene buenos requisitos, tiene buenas especificaciones, sabe cómo lo va a construir, conoce a las personas que lo construirán y las condiciones del mercado son estables, entonces cualquier cosa que se te ocurra como una estimación inicial podría incluso suceder, y todos están contentos. ¡Hurra!

Pero la mayoría de los proyectos no son pequeños. Los requisitos, incluso si son buenos, no pueden cubrir todo al 100%, los miembros del equipo pueden cambiar, las condiciones del mercado pueden cambiar, porque trabajas durante un período de tiempo más largo, no solo un par de semanas o meses, tienes más riesgos y te ves obligado a ganar más. suposiciones, etc., por lo que una estimación proporcionada hoy no vale mucho dentro de seis meses.

Desafortunadamente, la gente de negocios toma la estimación como un hecho y planifica todo tipo de cosas en torno al producto (eventos de lanzamiento, usarlo como una dependencia para otras actividades comerciales, asignar presupuestos para otras cosas, etc.). Cuando, eventualmente, no entregas a tiempo, muchos de sus planes se van por la ventana. Y es tu culpa, por supuesto.

Obviamente, puede proporcionar un presupuesto por adelantado y darles a las empresas lo que pidieron, pero los mantendrá ignorantes y terminarán haciendo planes basados ​​en algo que podría no suceder.

Entonces, edúcalos:

• sobre lo que es una estimación. Proporcione un rango, no un número;
• sobre qué riesgos existen, qué posibilidades hay de que ocurran y cómo eso afectará la estimación;
• sobre qué suposiciones hizo y qué sucederá si resultan incorrectas;
• sobre por qué las estimaciones casi siempre son incorrectas (se ha escrito mucho sobre el tema);
• y por qué, debido a los elementos anteriores, un enfoque iterativo e incremental funciona mejor . Mencione también otras ventajas (también se ha escrito mucho sobre este tema).

Si los educa sobre por qué prefiere un enfoque Agile, y si lo entienden, entonces sabrán qué esperar y colaborarán con usted cuando las cosas se desvíen, y luego podrán adaptar sus planes y objetivos en consecuencia. Si solo les das el presupuesto tal como te lo pidieron, te culparán cuando las cosas se desvíen e insistirán en que les des lo que prometiste, cuando lo prometiste, porque se hicieron otros planes que dependen de ello.

Este es un tema masivo, pero lo más destacado sería esto:

1) Es cascada, no Scrum. Está haciendo un diseño, creando requisitos y planificando la implementación. El hecho de que esté usando términos ágiles solo agrega confusión. Ahora, eso no es una condena. Tal vez sea perfectamente bueno usando cascada, pero los términos Scrum y XP solo agregan confusión.

2) Parte del objetivo de Scrum es que puede enviar el producto después de cada sprint, por lo que la conversación sobre cuándo se realizará es muy diferente. Se realizará en cada sprint y tendrá más funciones en cada sprint. La empresa puede decidir dejar de financiar el trabajo tan pronto como tenga suficiente o cuando descubra que el progreso no se está moviendo en una dirección que pueda respaldar.

3) Puede ordenar el pronóstico en Scrum usando gráficos de quemado. Digo "más o menos" porque parte del objetivo de Scrum es adaptarse. El gráfico de quemado se basa en lo que sabe hoy y cambiará. En los casos más saludables, se suele utilizar un gráfico de quemado para responder preguntas como: ¿qué probabilidad hay de que el producto tenga estas características para esta fecha? Eso es sutilmente diferente a preguntar "cuándo se hará", pero esa pequeña diferencia es muy importante.

Es común que las empresas tengan cierto nivel de desconfianza hacia TI, especialmente si anteriormente se sintieron decepcionadas por TI. Si te ganas su confianza, lo más probable es que la situación cambie y te quitarán la espalda. Para eso necesitas:

1. Entiéndalos a ellos y sus puntos débiles, hable su idioma, sienta por ellos. Si reconocen que eres uno de ellos, confiarán más en ti. Para eso necesitas estudiar el dominio, aprender sus flujos de trabajo.
2. Cumplir y superar sus expectativas. Para esto, se necesitan buenas habilidades de UX junto con un equipo de desarrollo sólido.

Al principio, tendrá que seguir sus reglas y proporcionar estimaciones. Pero una vez que comiences a entregar y ganar su respeto, las cosas cambiarán.

Y cuando proporcione estimaciones, no olvide mencionar que después de la implementación inicial, estará listo para escuchar sus comentarios. Y si cambian de opinión sobre algo o tienen sugerencias, estarás feliz de atenderlos. Obtendrán su estimación y obtendrá su agilidad.

Todo depende de la organización, por supuesto. Algunas empresas (especialmente las grandes) pueden tener políticas estrictas e incluso si el negocio quiere ser ágil, no necesariamente tiene los medios y la autoridad para cambiar las reglas.

No hay nada en Scrum que le impida hacer una estimación a largo plazo. El enfoque de Scrum facilita esos pronósticos de varias maneras. Los elementos del backlog normalmente están diseñados para ser independientes y estimables, y el hecho de que en Scrum la fecha de entrega sea siempre el final de un sprint significa que sus estimaciones solo necesitan ser precisas para el sprint más cercano.

Los pronósticos pueden estar equivocados, por supuesto. Siempre existe la posibilidad de trabajo imprevisto, retrasos o cambios en el alcance, pero eso es cierto independientemente del enfoque que utilice y no tiene nada que ver con Scrum.