¿Por qué nuestro proceso hizo que perdiéramos nuestra fecha de lanzamiento? [cerrado]

Creo que el quid de su pregunta en realidad puede estar en las preguntas que planteó en un comentario, en lugar de en la pregunta en sí:

¿Le parece aceptable que no se cumplan las fechas de lanzamiento?

La respuesta es, depende. Realmente depende de la situación; en el proyecto mismo. ¿Si es un proyecto puramente interno que es 'bueno tener' o algo así? Sí, no es realmente un gran problema retrasar la fecha de lanzamiento. Sin duda, es mejor tomarse más tiempo para hacerlo bien que apresurarse a hacer algo.

Si se trata de una aplicación sensible al tiempo en la que su cliente ha declarado que si no la recibe antes de (fecha), ¿renunciará a su contrato y optará por otra solución? Absolutamente inaceptable.

¿Si (como suele ser el caso) es un área gris donde cumplir con la fecha de lanzamiento es bueno pero no es absolutamente necesario ? Entonces realmente depende. Lo que me lleva al segundo punto...

Estoy preguntando cómo se podría modificar nuestra metodología aquí para evitar retrasar las fechas de lanzamiento.

Al final de cada iteración, examine el proyecto. Si ve un problema como este, examine sus prioridades y actualice el plan. Exactamente lo que eso significa dependerá de la situación. Empujar la liberación hacia atrás es una opción. Otra es eliminar el alcance, extrayendo ciertas características a una versión futura (o eliminándolas por completo). Otra (más arriesgada) es tirarle más dinero. ¿Esa herramienta costosa que sus desarrolladores han estado pidiendo y que dicen que acelerará su trabajo en un 30%? Puede que valga la pena mirar más a fondo. Decidir sobre estas prioridades es el trabajo del Project Manager (o Product Owner en Scrum, etc.)

Todo lo que Agile está haciendo es intentar que estas decisiones se tomen temprano y con frecuencia, en lugar de posponerlas hasta el final. Si bien eso generalmente es algo bueno, si las decisiones que se toman son incorrectas (o se ignoran por completo, etc.), entonces Agile ciertamente no lo salvará. Pero entonces, Waterfall tampoco. Con Waterfall, te llevará más tiempo darte cuenta de que no vas a salvarte.

Vale la pena señalar:

Estaba previsto que se publicara mañana pero, como resultado de una revisión por parte de la gerencia, necesita volver a trabajar.

Si tenía un montón de iteraciones que la gerencia básicamente ignoró, y luego solo se interesaron cerca de la fecha de lanzamiento... eso ni siquiera es Agile en primer lugar. Ese es un enfoque de cascada más tradicional que pretende ser ágil.

Tanto los desarrolladores como los ejecutivos rompieron el contrato ágil

Estaba previsto que se publicara mañana pero, como resultado de una revisión por parte de la gerencia, necesita volver a trabajar. Sin duda, esto agregará mucho tiempo a la estimación para el lanzamiento.

Tiene una falla de proceso básica si la primera vez que su equipo de administración revisó el producto fue poco antes del lanzamiento. En particular, su organización no cumplió con dos de los principios fundamentales del Manifiesto Ágil . Específicamente:

• Entregue software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.
• Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.

Ustedes (colectivamente) no hicieron esas cosas. Aparentemente, ahora está sorprendido de que el equipo del proyecto haya entregado algo incorrecto y de que la fecha de lanzamiento deba moverse para adaptarse a grandes cambios posteriores.

Estos son problemas sistémicos. Toda la organización (incluido el equipo de gestión del proyecto, los desarrolladores y la alta dirección) debe trabajar en conjunto para arreglar un proceso claramente roto. En esta etapa, también es probable que la empresa necesite un entrenador ágil externo para ayudar a identificar todos los problemas del proceso y ayudar a su empresa a formular nuevas soluciones.

Si su empresa soluciona o no los problemas subyacentes es, en última instancia, responsabilidad de la alta dirección. Los gerentes de proyecto y los desarrolladores solo pueden recomendar; los ejecutivos deben apropiarse de las decisiones estratégicas de la empresa.

Te animo a que te sientes con tu equipo (quizás en la retrospectiva) y eches un vistazo a los valores del manifiesto ágil: http://agilemanifesto.org/

La colaboración con el cliente sobre la negociación de contratos es algo en lo que se debe considerar pasar un tiempo como equipo o vender a las partes interesadas. Puede beneficiarse de realizar demostraciones con las partes interesadas con más frecuencia. El objetivo es obtener comentarios iterativos de las partes interesadas de manera temprana y frecuente, y responder a los requisitos cambiantes a medida que su producto se acerca a una visión final. Creo firmemente, y mi experiencia lo ha demostrado, que al final del proyecto no es la primera vez que las partes interesadas deben ver su entregable. Con mucha frecuencia será decepcionante y requerirá reelaboración.

Compare los valores del manifiesto con los valores mostrados tanto por las partes interesadas externas como por su propio equipo. Tal vez pueda iniciar un diálogo con aquellos cuyas expectativas no se han cumplido. ¡La mejor de las suertes para ti y tu equipo!

Tu pensamiento asume varias falacias que han sido evidenciadas una y otra vez.

• La idea de que la ingeniería de software es estimable con precisión (no lo es, las estimaciones simplemente se vuelven más precisas a medida que avanzamos hacia la finalización). Una acumulación saludable de trabajo con algunas estimaciones básicas y un gráfico de quemado mantenido habría demostrado eso desde el principio.
• La idea de que las empresas no pueden cambiar de opinión. Son. ellos están pagando Teóricamente, si quieren que refactorices las mismas 10 líneas de código todos los días durante un año, pueden pedirte que lo hagas. Sus opciones si no le gusta que el negocio cambie de opinión es renunciar y encontrar un nuevo negocio que crea que no cambiará de opinión.
• La idea de que los requisitos siempre son verdaderamente fijos. (No lo son excepto en casos de cumplimiento legislativo y posiblemente construcción/arquitectura)
• La idea de que la reelaboración es mala (no lo es si aprendemos de ella y hacemos un producto superior al final)
• La idea de que el código es lo que importa (no lo es. El código es lo que te lleva a lo que estás tratando de lograr. El código no es una mascota sagrada, es ganado que sacrificamos cuando decidimos que es el momento adecuado para hacerlo). hazlo)
• La idea de que las fechas impulsan la entrega. ellos no Necesita una persona fuerte para comunicarle eso al Patrocinador y también necesita entender eso. Las fechas no determinan la entrega. La entrega impulsa la fecha realista al demostrar cuándo es probable que se complete el alcance actual con los recursos actuales trabajando al ritmo promedio al que están completando las tareas de ingeniería.

Agile no es el problema; ¿cómo puede ser si es simplemente un conjunto de valores y principios sobre trabajar en colaboración y priorizar el software que funciona?

Lo que realmente le frustra es la entrega incremental sin requisitos fijos. Sin embargo, considere el siguiente escenario...

Los requisitos y el diseño se fijan por adelantado y pasó 6 meses en una entrega en cascada solo para realizar un lanzamiento de Big Bang y luego el negocio cambia de opinión o cambian las condiciones del mercado.

¿No sería más beneficioso tener un diseño fluido y comprometerse con una pequeña porción de software funcional que luego se revisa para asegurarse de que está en el camino correcto?

Estás viendo esto al revés; está viendo un esfuerzo desperdiciado en lugar de ver que el proceso de revisión está funcionando para usted. Ha ahorrado potencialmente muchos más meses de desarrollar algo incorrecto.

Cualquier desarrollador que alguna vez me haya dicho que no tengo derecho a cambiar de opinión sobre el producto que estoy patrocinando como ejecutivo, es mejor que comience a buscar un nuevo trabajo.