sensores - Renunciar a Agile, cambiar a cascada-¿Es esto correcto?
sensor de temperatura chevrolet agile (16)
Estoy trabajando en un entorno Agile y las cosas han ido al estado donde el cliente siente que preferiría Waterfall debido a las fallas (eso es lo que piensan) del escenario Agile actual. La razón que los 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 en el tiempo especificado.
Como de costumbre, ambos nos estábamos culpando el uno al otro. Desde nuestra perspectiva, los cambios indicados al final fueron demasiados y las modificaciones de diseño / código fueron demasiado. Mientras que, desde la perspectiva del cliente, se quejan de que nosotros (los desarrolladores) no estamos entendiendo los requisitos por completo y estamos encontrando soluciones que no eran "lo que querían" en el requisito. (como nos han pedido que dibujemos un tigre, y nosotros dibujamos un gato).
Por lo tanto, el cliente sintió (no nosotros) que el proceso Agile no es correcto y desea cambiar al modo Cascada, lo que en mi humilde opinión sería desastroso. La simple razón de ser sus niveles de satisfacción en un modo Agile en sí no era suficiente, entonces, ¿cómo van a tolerar la producción después de pasar tanto tiempo durante la fase de diseño de un desarrollo de cascada?
Por favor dé sus sugerencias.
La razón que los 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 en el tiempo especificado.
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 debe atenerse a los requisitos de congelación durante la duración del sprint. Tal vez sus iteraciones son demasiado largas? (Supongo que sigues a 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. A estas alturas, debe tener la arquitectura y el diseño básicos en su lugar. Tal vez debería revisar el diseño real e intentar imponer algunas pautas de diseño e implementar algunos patrones. Por ejemplo, en una aplicación web de empresa típica, probablemente terminará usando algo como DAO. Cuando agrega nuevas funciones, crea un nuevo DAO, pero la arquitectura y el diseño básicos no cambiarán.
Sin embargo, parece que no estás entregando lo que el cliente quiere. En ese caso, es de suma importancia entregar el producto de trabajo al cliente, por lo que podría proporcionar comentarios sensatos para la próxima iteración.
Respecto a
"Nosotros (los desarrolladores) no pudimos completar en el 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 planifica para la iteración se debe basar en la estimación que realiza el equipo y la cantidad de "puntos" que puede entregar durante la iteración. .
Ágil o cascada son solo palabras. Solo 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 las 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: el modelado de datos, el diccionario de datos, los diagramas de flujo de datos ... el objetivo es conocer todos los requisitos en detalle. Cortar su producto en muchos bloques independientes lo ayuda a comenzar a codificar mientras continúa diseñando o especificando otras partes de su producto final.
Consulte el libro de Steve McConnell: "Desarrollo rápido de software: controle la programación de software salvaje" para conocer todas las prácticas que funcionan.
Creo que su cliente se equivoca al pasar a la cascada. Es curar el síntoma, no la enfermedad. El problema que describe es uno de comunicación: el cliente quiere un tigre, usted le está dando un gato.
El modelo de cascada incluye muchos pasos para verificar que se cumplan los requisitos escritos, pero no garantiza que los requisitos escritos sean lo que significó el negocio.
Me gustaría ver técnicas como mapeo de impacto , desarrollo impulsado por el comportamiento ( BDD ) y mapeo de historias para mejorar la comunicación.
Despedir al cliente Incluso si es tu culpa por no entender lo que significan, la cascada 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 por ellos. Dispáralos o diles que estás usando Waterfall sin cambiar realmente.
El desarrollo ágil no le ahorra la carga de crear un diseño que tanto usted como el cliente entiendan de manera similar. Agile solo permite 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, crear un diseño adecuado lleva tiempo.
Por lo tanto, me esforzaría más en sentarme con el cliente, con una pizarra blanca, repasar qué es lo que realmente quieren. No creo que realmente importe en este caso si el proceso de desarrollo es ágil o en cascada.
El problema obvio aquí es la comunicación con el cliente. Si realmente desea hacer Agile, tiene que comunicarse con el cliente en los conceptos básicos diarios. Sólo el cliente debe poder tomar una decisión. Si se comunica con el cliente solo a mediados de la primavera y al final del sprint, es natural que más adelante encuentre problemas en su aplicación. También las características implementadas en el sprint deben ser aceptadas y probadas por el cliente. Hasta que las características no se completen.
Estoy escribiendo esto porque tengo un problema similar en mi proyecto actual pero sé dónde fallamos.
En primer lugar, pregúntate, ¿ realmente estás haciendo Agile? Si es así, ya debería haber entregado una gran parte de la funcionalidad utilizable al cliente que cumplió con sus requisitos en los sprints anteriores. En teoría, el "daño" debe limitarse al sprint final donde descubrió que necesitaba grandes cambios de diseño. Siendo ese el caso, debería haber demostrado su capacidad de entrega y ahora necesita un diálogo con el cliente para planificar los cambios que ahora se requieren.
Sin embargo, dada su descripción, sospecho que ha caído en la trampa de simplemente desarrollarse en un ciclo de dos semanas sin entregar realmente en producción cada vez y tener una fecha de finalización fija en mente para la primera versión correcta. Si este es el caso, entonces realmente está haciendo una cascada iterativa sin el análisis / diseño de requisitos por adelantado, un mal lugar en el que estar normalmente.
La cascada completa no es necesariamente la respuesta (hay pruebas suficientes para demostrar cuáles son los problemas con ella), pero en la práctica es generalmente preferible una cierta cantidad de planificación y diseño por adelantado al espíritu ágil "puro" de la arquitectura emergente (que encaja con un Enfoque magro en realidad). Los grandes proyectos simplemente no pueden aspirar a lograr una base arquitectónica estable y razonable si simplemente comienzan a piratear el código y esperan que todo salga bien en una cierta cantidad de sprints en el futuro.
Además de lo anterior, otro problema común con Agile "puro" es la gestión de expectativas del cliente. Agile se vende como esta cosa maravillosa que significa que el cliente puede aplazar decisiones, cambiar de opinión y agregar nuevos requisitos a su conveniencia. SIN EMBARGO, eso no significa que la fecha de finalización / presupuesto / esfuerzo requerido permanezca fijo, pero las personas siempre parecen perder esa parte.
La depuración remota de un proceso de desarrollo es lo suficientemente difícil como para dudar en ofrecer una opinión sobre lo que debe 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 sobre qué salió mal. Según su descripción, parece que los resultados iniciales, que usted creía que eran progresos en el banco, terminaron siendo revisados en gran medida.
Una causa común de esto es el descubrimiento / creación tardía de los requisitos ''todos'', 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.
Una descripción clásica de este tipo de falla (aunque en un proyecto no ágil) se puede encontrar here
"Una vez que vieron el producto del código que escribimos, decían: ''Oh, tenemos que cambiar esto. Eso no es lo que quise decir''", dijo Reynolds de SAIC. "Y fue entonces cuando comenzamos a registrar la solicitud de cambio después de la solicitud de cambio después de la solicitud de cambio".
Por ejemplo, según los ingenieros de SAIC, después de que los ocho equipos completaron aproximadamente el 25 por ciento del VCF, el FBI quería que se agregara una capacidad de "migaja de página" a todas las pantallas. También conocido como "migas de pan", un nombre inspirado en el cuento de hadas Hansel y Gretel, este dispositivo de navegación proporciona a los usuarios una lista de URL que identifican la ruta tomada 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 subprocesos completados tuvieron que ser actualizados con la nueva característica.
La frase clave allí es ''todas las pantallas''. Ante los cambios de esa naturaleza, entonces, a menos que tenga alguna herramienta de soporte preexistente que solo pueda activar (cambiar todos los colores de fondo realmente debería ser trivial), está en problemas. El progreso que crees haber hecho hasta ese momento se habrá vuelto retroactivamente ilusorio.
El único enfoque conocido de estos problemas es solucionarlos por primera vez. Si eso falla, convive con tenerlos mal.
Las metodologías de desarrollo ágil son particularmente apropiadas cuando tiene requisitos poco claros y cuando necesita realizar cambios de diseño en etapas posteriores de su proyecto. La 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 útil del proyecto. No parece que ese sea el caso aquí.
¿Cuánto duran tus sprints? Un enfoque alternativo podría ser disminuir la longitud del sprint, al menos al inicio del proyecto. Entregue nuevas versiones al cliente con más frecuencia y discuta los cambios con el cliente. Si no está haciendo lo que ellos quieren, esto se hará evidente más rápidamente, por lo que se perderá menos tiempo implementando soluciones que no cumplan con los requisitos del cliente.
Muchas tiendas agregan adornos Agile para que se vean "ágiles" para los clientes que lo esperan. Tal vez solo necesite agregar algunos recortes de cascada y mostrarles el producto una vez cada 2 sprints.
No está claro a qué tipo de cambios de diseño se refiere. Diseño grafico? Diseño de experiencia de usuario? Código de diseño?
En cualquier caso, la mejor solución es más, y antes, discusiones con el cliente. Desarrollar conjuntamente ejemplos concretos y explícitos que satisfagan los requisitos del cliente. Puede convertir estos ejemplos en pruebas de regresión para asegurarse de que continúa satisfaciéndolos.
Además, continúe las discusiones a medida que avanza. Muestre su salida cuando esté disponible, no espere hasta cerca del final del sprint. Y trabajar en la parte con mayor probabilidad de generar problemas primero. También busque formas de facilitar el cambio de las cosas que está encontrando a menudo.
El punto es involucrar más al cliente, incluso en la iteración de un diseño. Quizás quieras tener algunas discusiones centradas solo en el diseño.
No estoy seguro de qué tipo de tienda manejas, por lo que es difícil para mí dar buenas recomendaciones. Aunque puedo ofrecer dos principios rectores:
- Si tiene una mala comunicación con el cliente, ninguna metodología de desarrollo lo salvará.
- No es asunto del comensal cómo un chef organiza la cocina, siempre que la comida sea sabrosa.
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, se trata más de lidiar con la creciente incertidumbre en el futuro. Por ejemplo, debería haber un plan de lanzamiento con las funciones planificadas para todos los lanzamientos en los próximos 2 meses (y un plan menos detallado con funciones para los lanzamientos posteriores), de modo que el cliente tenga claro cuándo esperar una característica y cuándo. Hay una posibilidad de requisitos de cambio.
También para mí, 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á usted.
También trate de no asignar la culpa, ya que esto impide que las personas bloqueen. Intente utilizar el enfoque de inspección y adopción para obtener un mejor proceso en su lugar.
Parece que tiene serios problemas de gestión de proyectos y arquitectura / diseño, y parece que sus comunicaciones también se han roto. Fundamentalmente, no creo que cambiar su metodología de desarrollo vaya a solucionar nada de eso y, por lo tanto, es algo incorrecto que se debe hacer (aunque puede restaurar la confianza del cliente).
Estaría especialmente preocupado por avanzar hacia la cascada, ya que ahora está eligiendo capturar esencialmente los requisitos solo una vez (con lo cual sabemos que tiene un problema) sin capacidad de entrada. Esa rigidez es buena para objetivos de entrega inflexibles, pero es completamente inapropiado aquí, donde tiene cambios todo el tiempo, ¡eso es ágil!
A corto plazo, daría un paso atrás y volvería a comprobar sus requisitos en esta etapa con ellos. Renegociar y confirmar su estado actual en relación con esos.
A medio plazo, abriría más comunicaciones con el cliente; intente involucrarlos en un scrum diario durante un tiempo (hasta que recupere la confianza, entonces puede ser más flexible).
A largo plazo, debes preocuparte por la forma en que tus PM y los desarrolladores senior han logrado ponerte en esta posición. Si el cliente está siendo irrazonable, eso es una cosa (pero aún depende del PM para gestionarlo, por lo que no está absuelto). No es razonable quejarse de tener demasiados cambios, eso solo significa que cometiste un error al determinar 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 veo que el movimiento hacia la cascada sea posiblemente correcto. No soluciona nada directamente y solo puedo verlo exacerbando los problemas que ya ha resaltado.
Advertencia: no soy realmente capaz de tener una visión equilibrada de la cascada, ya que nunca la he visto funcionar de manera efectiva y, por lo tanto, está completamente desactualizada para los proyectos empresariales.
Si el problema de comunicación entre el Equipo y el Cliente no es fijo, la situación podría empeorar con la cascada, si el cliente solo ve el producto una vez que está completo (efecto túnel).
Comentó que los cambios de los sprints 6-7 comenzaron a volver a trabajar en las tareas realizadas en los 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 función, y el Equipo no implementa lo que el cliente espera, esto debe detectarse a más tardar en el Sprint donde se implementa la función, e idealmente corregirse en el Sprint actual.
Si el cliente cambió de idea, las nuevas ideas se agregarán al Product Backlog, se priorizarán y se seleccionarán para un Sprint, como cualquier otro elemento de backlog. Esto no debe ser considerado como retrabajo.
¿Entrega el software al cliente después de cada carrera, o simplemente lo está demostrando?
El origen de la falta de comunicación podría estar en la Planificación de Sprint: el Equipo solo debe confirmar en el Artículo de Backlog que está claramente definido. La definición de los elementos debe comprender los criterios de aceptación. ¿Es el cliente el propietario del producto, y es el propietario del producto?
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 qué 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 se preocupará realmente por estos detalles, siempre que los requisitos se cumplan dentro del presupuesto y el calendario acordados. No espere que a ellos les importe, y no los confunda con muchas versiones inadecuadas e información irrelevante en su proceso interno.
Esto es lo que le importa al cliente e intenta hablarle (en parte, utilizando su propia jerga técnica): sus requisitos, sus expectativas decepcionadas y la forma en que se comunica con ellos. En estos asuntos, el cliente es la autoridad absoluta. Interprete lo que dicen sobre su relación y el producto, no como comentarios útiles sobre el proceso interno. No niegue el agua con sus plazos y procesos internos, discuta el progreso y las expectativas y la relación. (Si insisten en hablar sobre aspectos internos, puede volver a asignar los términos: por ejemplo, lo que entienden como "la próxima versión" puede conocerse internamente como "la próxima versión importante", 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 jueguen con una mala compilación. Vale la pena verificar si esto es cierto. Si es así, debe respetarlo y seguir utilizando métodos ágiles internamente si eso es lo que su equipo considera que es lo mejor. Si dicen "cascada", es posible que pueda interpretar eso internamente en el sentido de que "establecemos una fecha límite para los requisitos, y luego no permitimos que se agreguen más funciones por un tiempo". Discuta con el cliente si le conviene tener una fecha límite de requisitos seguida de este tipo de congelación.
Alguien en su equipo debe ser el defensor del cliente, sentarse sobre los problemas del cliente y luchar por ellos. Este defensor no debe ser marginado, ni puede tomar partido por el equipo contra el cliente; deberían ser el jefe de los poderes. Luego puede separar la comunicación del proceso interno (equipo para abogar) de la comunicación externa (abogar ante el cliente). El defensor puede, en cierta medida, aislar al cliente de la conversación 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 que debas ser reservado o distante con el cliente, pero debes (A) escuchar lo que el cliente está diciendo sobre la relación y cómo te estás 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.