Renunciar a Agile, Cambiar a waterfall - ¿Es esto correcto? [cerrado]

Las metodologías de desarrollo ágil son particularmente apropiadas cuando tiene requisitos poco claros y cuando puede necesitar realizar cambios de diseño en etapas posteriores de su proyecto. Cascada es un enfoque menos apropiado en este caso. El enfoque de cascada es apropiado para proyectos que se entienden bien y cuando es poco probable que los requisitos cambien durante la vida del proyecto. No parece que ese sea el caso aquí.

¿Cuánto duran tus sprints? Alternativa el enfoque podría ser disminuir la longitud del sprint, al menos al comienzo del proyecto. Entregue nuevas versiones al cliente con más frecuencia y discuta los cambios con el cliente. Si no está haciendo lo que quieren, esto se hará evidente más rápidamente, por lo que se perderá menos tiempo en la implementación de soluciones que no cumplen con los requisitos del cliente.

No estoy seguro de qué tipo de tienda tienes, así que es difícil para mí encontrar buenas recomendaciones. Sin embargo, puedo ofrecer dos principios rectores:

1. Si tiene una mala comunicación con el cliente, ninguna metodología de desarrollo lo salvará.
2. No es asunto del comensal cómo un chef organiza la cocina, siempre y cuando la comida sea sabrosa.

Parece que tienes problemas serios de gestión de proyectos y arquitectura/diseño, y parece que tus comunicaciones también se han roto. Fundamentalmente, no creo que cambiar tu metodología de desarrollo vaya a solucionar nada de eso, y por lo tanto es lo incorrecto (aunque puede restaurar algo de confianza del cliente).

Estaría especialmente preocupado por mover hacia cascada ya que ahora está eligiendo capturar esencialmente los requisitos solo una vez (que sabemos que tiene un problema con) sin capacidad de entrada. Esa rigidez es buena para objetivos de entrega inflexibles, pero es completamente inapropiado aquí donde tienes cambios todo el tiempo, ¡eso es ágil!

• A corto plazo me gustaría dar un paso atrás y volver a comprobar sus requisitos en esta etapa con ellos. Renegociar y confirmar su estado actual en relación con ellos.

• A medio plazo, me gustaría abrir más comunicaciones con el cliente-tratar de conseguirlos participa en un scrum diario por un tiempo (hasta que recuperes la confianza, entonces puedes ser más flexible).

• A largo plazo, usted tiene que estar preocupado acerca de cómo sus PM y desarrolladores de alto nivel han logrado conseguir que en esta posición. Si el cliente está siendo irrazonable, eso es una cosa (pero aún depende del Primer ministro administrar eso, por lo que no está absuelto). No es razonable quejarse de tener demasiados cambios, eso solo significa que la cagó en la determinación de los requisitos (que es un diálogo, no un monólogo) o que tienes que tener sprints más numerosos, pero probablemente más cortos.

Por encima de todo, no puedo ver que moverse hacia la cascada sea posiblemente correcto. No arregla nada directamente y solo puedo verlo exacerbando los problemas que ya has resaltado.

Advertencia: No soy realmente capaz de una visión equilibrada de waterfall ya que nunca he visto que funcione de manera efectiva y en mi humilde opinión es completamente anticuado para proyectos empresariales.

Ágil o cascada son solo palabras. Sólo hay cosas que funcionan y cosas que no. El desarrollo de software parece virtual para muchas personas y no entienden por qué es difícil cambiar una pequeña cosa que solicitan.

Sus clientes deben entender que construir un software es como construir una casa : cuando ha construido todos los cimientos y paredes, es difícil cambiar todo el plan final de la casa y el diseño de la habitación.

Algunas prácticas ayudan a evitar este tipo de problema: modelado de datos, diccionario de datos, diagramas de flujo de datos... el objetivo es conocer cada requisito con todo detalle. Cortar su producto en muchos bloques independientes ayuda a comenzar a codificar mientras continúa diseñando o especificando otras partes de su producto final.

Ver el libro de Steve McConnell : "Rapid Software Development : taming wild software schedule" para todas las prácticas que funcionan.

El desarrollo ágil no lo salva de la carga de llegar a un diseño que tanto usted como el cliente entienden de manera similar. Agile solo hace posible crear el diseño en incrementos más pequeños y no todos a la vez. Y, en el caso de un cliente difícil, llegar a un diseño adecuado lleva tiempo.

Por lo tanto, me gustaría gastar más esfuerzo en sentarse con el cliente, con una pizarra, repasando qué es lo que realmente quieren. No lo creo realmente importa en este caso si el proceso de desarrollo es ágil o cascada.

La razón que les hizo pensar así sería la inmensa cantidad de cambios de nivel de diseño que ocurrieron durante las etapas finales de los sprints que nosotros (los desarrolladores) no pudimos completar dentro del tiempo que especificaron.

Scrum es en cierto modo una "cascada corta", y debe estar aislado de los requisitos cambiantes para la duración del sprint. Parece que esto no está sucediendo! Por lo tanto, no vea que ganará nada al cambiar a la cascada tradicional, pero usted debe atenerse a los requisitos de congelación para la duración del sprint. Tal vez sus iteraciones son demasiado largas? (Supongo que sigues Scrum, ya que mencionas sprints).

Hable con sus clientes y acuerde lo siguiente:

- Shorter iterations, up to 3 weeks max.
- No changes in requirements during the iteration. 
- Features are planned at the beginning of the iteration 
- Every iteration ends with deliverable: fully functional software with all features that are fully operational
- Iteration length does not change. Unfinished features are left for the next iteration (or maybe discarded if client changes his mind).
- Number of "feature points" you can deliver in a single iteration should be based on the team metric, not client insistence. This is your "capacity".
- Client decides what features (but not how many of them) are planned for the iteration 

Otra cosa que debe preguntarse es por qué hay tantos "cambios de nivel de diseño" en su aplicación. Por ahora, usted debe tener la arquitectura básica y el diseño en su lugar. Tal vez usted debe revisar el diseño real y tratar de imponer algunas directrices de diseño e implementar algunos patrones. Por ejemplo, en una aplicación web empresarial típica, probablemente terminarás usando algo como DAO. Cuando agrega nuevas características, crea un nuevo DAO, pero la arquitectura y el diseño básicos no cambiarán.

Parece, sin embargo, que usted no está entregando lo que el cliente quiere. En ese caso, es de suma importancia entregar el producto de trabajo al cliente, para que pueda proporcionar comentarios sensatos para la siguiente iteración.

Respecto a

" nosotros (desarrolladores) no se pudo completar dentro del tiempo especificado."

El cliente no debe ser el que especifique el marco de tiempo de iteración. La longitud de la iteración debe ser siempre la misma. Los requisitos que entran en la iteración deben obtenerse como resultado de la priorización del cliente, pero la cantidad de requisitos que se planea para la iteración debe basarse en la estimación que realiza el equipo y el número de "puntos" que puede entregar durante la iteración.

Para mí suena como si no hubiera un "Gran Plan[TM]" en el proyecto ágil. El uso de un proceso ágil no significa que no haya un plan a largo plazo, sino que se trata más bien de lidiar con la creciente incertidumbre en un futuro más lejano. Por ejemplo, debe haber un plan de lanzamiento con las características planificadas para todas las versiones en los próximos 2 meses (y un plan menos detallado con las características para las versiones posteriores), para que el cliente tenga claro cuándo esperar una característica y cuándo hay una posibilidad cambiar los requisitos.

También me parece que no hubo (suficiente) participación del cliente en el proceso. Sé que este es un punto muy problemático, pero ayuda mucho si el progreso actual se puede discutir con el cliente al final de cada iteración. Como @Mark Byers ya escribió, cuantos más comentarios pueda obtener de su cliente, mejor será.

También trate de no asignar la culpa, ya que esto mantiene a la gente a bloquear. Trate de utilizar el enfoque de inspeccionar y adoptar para obtener una mejor proceso en su lugar.

No está claro qué tipo de cambios de diseño quieres decir. Diseño gráfico? Diseño de experiencia de usuario? Código de diseño?

En cualquier caso, la mejor solución es más, y antes, conversaciones con el cliente. Desarrollar conjuntamente ejemplos explícitos y concretos que satisfagan los requisitos del cliente. Puede convertir estos ejemplos en pruebas de regresión para asegurarse de que continúa satisfaciéndolos.

También, continúe las discusiones a medida que avanza. Muestra tu salida como está disponible't no esperes hasta cerca del final del sprint. Y trabajar en la parte más propensa a generar problemas primero. También busque maneras de hacer que sea más fácil cambiar las cosas que está encontrando que a menudo cambian.

El punto es conseguir que el cliente se involucre más, incluso en la iteración de un diseño. Tal vez desee tener algunas discusiones centradas solo en el diseño.

Dispara al cliente. Incluso si es tu culpa por no entender lo que significan, waterfall les daría 1 oportunidad de darte retroalimentación en lugar de una oportunidad al final de cada sprint. Algunas personas / clientes son literalmente tan estúpidos que no vale la pena trabajar para ellos. Despídelos, o dígales que está usando Cascada sin cambiar realmente.

Su cliente no sabe cómo desarrollar software, o cómo administrar el proceso de desarrollo de software. No espere que el cliente proporcione instrucciones significativas sobre estos asuntos. Como caso especial, el cliente no sabe realmente lo que significan términos como' cascada 'y' ágil'; no espere que proporcionen información significativa sobre su metodología de desarrollo. Además, el cliente no realmente se preocupará por estos detalles, siempre y cuando los requisitos se cumplan dentro del acuerdo presupuesto y calendario. No esperes que les importe, y no los confundas con muchas construcciones inadecuadas e información irrelevante sobre tu proceso interno.

Esto es lo que al cliente le importa, y está tratando de hablar contigo (en parte usando tu propia jerga técnica): sus requisitos, sus expectativas decepcionadas y la forma en que te comunicas con ellos. En estos asuntos, el cliente es la autoridad absoluta. Interpreta lo que están diciendo como acerca de tu relación y el producto, no como comentario utilizable en el proceso interno. No enturbie el agua con sus plazos y procesos internos, discuta el progreso y las expectativas y la relación. (Si insisten en hablar acerca de los aspectos internos, puede volver a asignar los términos: por ejemplo, lo que entienden como "la próxima versión" puede ser conocido internamente como "la próxima versión principal", o lo que sea).

Me parece que el cliente puede querer un umbral más alto antes de que se les pida retroalimentación o jugar con un mal construir. Vale la pena verificar si esto es cierto. Si es así, deberías honrarlo y seguir usando métodos ágiles internamente si eso es lo que tu equipo considera que es lo mejor. Si dicen "cascada", es posible que pueda interpretar internamente que significa " establecemos una fecha límite para los requisitos, y luego no permitimos que se agreguen más características por un tiempo."Discuta con el cliente si le conviene tener un plazo de requisitos seguido de este tipo de congelación.

Alguien en tu equipo debe ser el defensor del cliente, y sentarse en la parte superior de los problemas del cliente y luchar por ellos. Este defensor no debe ser marginado, ni puede ponerse del lado del equipo contra el cliente; debe ser el jefe de proxy. A continuación, puede separar la comunicación del proceso interno (equipo a defensor) de la comunicación externa (defensor al cliente). El defensor puede en cierta medida aislar al cliente de la charla y las construcciones que no aprecian, sin imponer artificialmente un cierto tipo de gestión o programación en su proceso interno.

Para aclarar, no creo en absoluto que deba ser reservado o distante con el cliente, pero debe (A) escuchar lo que el cliente está diciendo sobre la relación y cómo se está comunicando y honrar eso, (B) mantener eso separado del proceso de desarrollo interno, que debe gestionarse de cualquier manera que finalmente satisfaga las expectativas del cliente.

El problema obvio aquí es la comunicación con el cliente. Si realmente quieres hacer ágil tienes que comunicarte con el cliente en lo básico diario. Solo el cliente debe ser capaz de tomar una decisión. Si se comunica con el cliente solo durante la mitad de la primavera y al final del sprint, es natural que más tarde encuentre problemas en su aplicación. También las características implementadas en sprint deben ser aceptadas y probadas por el cliente. Hasta que no se completen las características.

Estoy escribiendo esto porque tengo un problema similar en mi proyecto actual, pero sé dónde fallamos.

Si el problema de comunicación entre el Equipo y el Cliente no se soluciona, la situación podría ser peor con waterfall, si el cliente solo ve el producto una vez que está completo (efecto túnel).

Usted comentó que los cambios de sprints 6-7 comenzaron a causar la reelaboración de tareas logradas en sprints anteriores. Esos cambios deberían haberse detectado antes, durante la revisión de Sprint.

Si hay un malentendido en la descripción de una característica, y el Equipo no implementa lo que el cliente está esperando, esto debe detectarse a más tardar en el Sprint donde se implementa la función, e idealmente fijado en el Sprint actual.

Si el cliente cambió de opinión, las nuevas ideas se agregarán al Backlog del Producto, se priorizarán y se seleccionarán para un Sprint, como cualquier otro elemento de backlog. Esto no debe considerarse como una reelaboración.

¿Entrega el software al cliente después de cada sprint, o simplemente lo está haciendo una demostración ?

El origen de la la falta de comunicación podría ser en la Planificación de Sprint: el Equipo solo debe comprometerse en el Elemento de Retraso que están claramente definidos. La definición de los artículos debe incluir los criterios de aceptación. ¿Es el cliente el Propietario del Producto, y es el Propietario del Producto ?

La depuración remota de un proceso de desarrollo es lo suficientemente difícil que dudaría en ofrecer cualquier opinión sobre lo que debería hacer. Me parece que nadie fuera de su equipo puede tener suficiente información para hacer un juicio muy útil al respecto.

Un salto menor a una conclusión sería hacer una conjetura en cuanto a lo que salió mal. Por su descripción, parece que los primeros entregables, que pensó que eran progresos en el banco, terminaron siendo principalmente reelaborado.

Una causa común de esto es el descubrimiento tardío/creación de 'todos' requisitos, cosas que se supone que son ciertas sobre todo en el alcance del proyecto. Estos pueden ser bastante fatales si se toman en serio: algo tan simple como 'todos los cuadros de diálogo deben ser redimensionables' es, por ejemplo, aparentemente más allá de la capacidad de Microsoft para adaptar a Windows.

Se puede encontrar un relato clásico de este tipo de fracaso (aunque en un proyecto no ágil) aquí

"Una vez que vieron el producto del código que escribimos, entonces dirían, 'Oh, tenemos que cambiar esto. Eso no es lo que quise decir", dijo Reynolds de SAIC. "Y fue entonces cuando empezamos a registrar solicitud de cambio tras solicitud de cambio tras solicitud de cambio."

Por ejemplo, según los ingenieros de SAIC, después de que los ocho equipos completaran aproximadamente el 25 por ciento del VCF, el FBI quería que se agregara una capacidad de "miga de página" a todas las pantallas. También conocido como "pan migajas", un nombre inspirado en el cuento de hadas de Hansel y Gretel, este dispositivo de navegación ofrece a los usuarios una lista de URL que identifican el camino tomado a través del VCF para llegar a la pantalla actual. Esta nueva capacidad no solo agregó más complejidad, dijeron los ingenieros de SAIC, sino que retrasó el desarrollo porque los hilos completados tuvieron que ser reacondicionados con la nueva característica.

, La frase clave es 'todas las pantallas". Frente a los cambios de esa naturaleza, entonces, a menos que tenga algún pre-existente ayuda de la herramienta usted puede apenas encender (cambiar todos los colores de fondo realmente debe ser trivial), usted está en apuro. El progreso que usted piensa que había hecho hasta ese punto habrá resultado retroactivamente ser ilusorio.

El único enfoque conocido para tales problemas es hacerlos bien la primera vez. Si eso falla, vive con ellos equivocados.

Muchas tiendas agregan adornos ágiles para hacerse "parecer ágiles" a los clientes que lo esperan. Tal vez solo necesite agregar algunos adornos de cascada y mostrarles el producto una vez cada 2 sprints.

Creo que su cliente se equivoca al mudarse a Waterfall. Está curando el síntoma, no la enfermedad. El problema que describes es uno de comunicación-el cliente quiere un tigre, le estás dando un gato.

El modelo de cascada incluye muchos pasos para verificar que los requisitos tal como están escritos se están entregando, pero no garantiza que los requisitos escritos sean lo que el negocio quería decir.

Me gustaría ver técnicas como mapeo de impacto , impulsado por el comportamiento desarrollo ( BDD ) y story mapping para mejorar la comunicación.