¿Cómo puedo integrar la información de un cliente en cascada en un proyecto ágil?

Actualmente estamos haciendo un proyecto ágil en el que el cliente es menos ágil de lo que realmente esperábamos (se queda con la cascada). Además, si bien existe una especificación de requisitos oficial, lamentablemente el cliente no la actualiza (problemas de tiempo, lo que sea), por lo que nuestro proceso actual para obtener la información que necesitamos se ve así:

  • para obtener los requisitos correctos, recopilamos preguntas a las "épicas" que identificamos en un Wiki (Confluencia)
  • para cada epopeya, exportamos estas preguntas a un archivo de Word y se las enviamos al cliente
  • el cliente comenta estas preguntas y las devuelve
  • copiamos los comentarios del archivo de Word en Wiki y los comentamos más o cerramos las preguntas, eventualmente enviamos exportaciones épicas actualizadas al cliente

La razón por la que tratamos de mantener esta información en el Wiki es porque nos gustaría tener un lugar central en el que se puedan realizar búsquedas donde se aclaren y describan en detalle todos los requisitos del proyecto (sin documentos de Word). Además, actualmente también escribimos la especificación de nuestro sistema en el mismo Wiki, lo que nos da la capacidad de hacer referencia a las respuestas/requisitos de los clientes a los requisitos funcionales que definimos y mucho más.

Obviamente, hay al menos un problema con este enfoque: la copia manual de respuestas y la exportación de catálogos de preguntas una y otra vez. Esto, junto con el problema de que siempre debe existir algún tipo de documento "externo" acordado para consultarlo más adelante en caso de que las cosas salgan mal, es un gran dolor de cabeza para nosotros.

Sé que la gente usó listas de elementos de acción para este tipo de cosas en el pasado, pero esto no se ajusta en absoluto a nuestras expectativas de búsqueda de información. Por otro lado, un Wiki, por su naturaleza que puede ser editado en cualquier momento, seguramente tampoco cumplirá con el requisito de "documento acordado".

Entonces, ¿cuáles son algunas técnicas válidas para hacer mejor estas cosas (incluso el soporte de herramientas adecuado?) o ya se escapó después de leer el primer párrafo de esta pregunta.

La pregunta, tal como está escrita actualmente, suena como si estuviera solicitando servicios; ¿podrías hacer la pregunta más explícita? ¿Podría adjuntar el documento de coordinación (o importarlo explícitamente) a la página wiki?
No, no estoy solicitando servicios; Estoy buscando mejores prácticas de otras personas que enfrentaron problemas similares al administrar requisitos con clientes "en cascada" y flujos de trabajo ágiles.
Relevante pero no una respuesta: no puede hacer ágil dentro de la cascada porque no tiene sentido permitir/esperar cambios dentro de un marco que no lo permite. Sospecho que los problemas que enfrenta ahora son simplemente la punta del iceberg.
@Sklivvz Sí, lo sé, se avecinan más problemas. Básicamente estamos haciendo ágil en un jardín amurallado, para satisfacer nuestras propias necesidades de planificación. Creo firmemente en la metodología ágil, pero a algunos clientes simplemente no se les puede convencer para que sigan el ejemplo.
En pocas palabras, no lo hace. No se trata de seguir el ejemplo : a veces, el cliente está acostumbrado o debe usar la cascada (como las grandes empresas que requieren toneladas de burocracia). Piense al revés: ¿sería razonable tener a alguien tratando de poner sus proyectos ágiles en un modelo Waterfall? Creo que ambos modelos tienen pros y contras... no tiene mucho valor tratar de tener un modelo único para todos.
En su plan existente, ¿cuándo es la oportunidad más temprana para que su cliente vea una maqueta, una demostración o una versión beta?

Respuestas (2)

Este es un problema común con la mayoría de las metodologías. El seguimiento y la documentación de los requisitos cambiantes es difícil. Tanto el cliente como el equipo de desarrollo deben aceptar los cambios en los requisitos. Y es probable que ambos impulsen cambios en los requisitos. Si el cliente ha realizado Big Upfront Design, en lugar de Waterfall, es menos probable que impulse cambios.

Como está encontrando, el equipo de desarrollo está generando solicitudes de aclaración de los requisitos. El cliente también puede tener requisitos cambiantes. Esto se trata comúnmente mediante un proceso de control de cambios.

Puede encontrar que mantener los documentos que fluyen entre el equipo y el cliente en un formato de texto funciona mejor. Hacer la comunicación mediante mensajes de correo electrónico puede hacer que la transferencia de información fluya más fácilmente. Dependiendo de las respuestas recibidas, puede ser apropiado cortar y pegar la respuesta en el documento de requisitos. Otros cambios pueden dar lugar a ediciones de los requisitos. En cualquier caso, debería poder rastrear los requisitos actuales hasta los requisitos originales y cualquier cambio aprobado.

Pedir aclaraciones con más frecuencia puede ayudar a reducir la fricción en el proceso de cambio. Agregar los cambios y las respuestas a un sistema de seguimiento de errores/problemas/tareas también puede ayudar de varias maneras. Con el flujo de trabajo adecuado, podrá realizar un seguimiento de los cambios a lo largo de su ciclo de vida. Puede ser más fácil hacer que el cliente se una usando la herramienta de seguimiento de problemas que actualizar la wiki.

Esa fue una de mis opciones aquí también, tenemos configurado un rastreador de problemas (Jira), que se usará durante el desarrollo más adelante. Pensé que tal vez alguien ya había intentado negociar/aclarar los requisitos con la ayuda de un rastreador de problemas y me diría si eso funciona bien (por ejemplo, la trazabilidad de WRT) o no (una pesadilla, porque los requisitos similares se reparten entre muchos tickets y nadie). ve a través de él después de algún tiempo).
@ThomasKeller El flujo de trabajo debe actualizar la documentación en función de la respuesta del problema antes de cerrar el problema. Si puede vincular el documento de requisitos con el problema, puede permitirle determinar qué documentos de requisitos tienen la mayor rotación. Hacer referencia al problema en el comentario de actualización de requisitos también sería una buena idea.

Todavía no estoy seguro de entender la pregunta o el problema, y ​​el comentario de @skilwz me lleva a creer que podría tratarse de un problema X:Y. Habrá turbulencias y fricciones si su cliente está comprometido con la cascada y usted está comprometido con la agilidad. El verdadero problema puede ser la diferencia de concepciones sobre cómo gestionar el cambio y el alcance. También sospecho que esto es una violación de la ley de CodeGnome: está enmascarando la implementación tecnológica en lugar del problema central. (Ninguno de esos comentarios es una crítica hacia usted; la situación es la que es, y usted está tratando de navegar a través de ella lo mejor que puede).

Según tengo entendido, está gestionando el cambio, pero su cliente no participa en el proceso de gestión del cambio. Algunas campanas de alarma suenan en mi mente en ese momento que no tienen nada que ver con ágil/cascada/lo que sea. El desapego del cliente de la gestión del cambio y del alcance me preocupa en un nivel fundamental. Si fuera posible resolver ese problema, estoy seguro de que lo habría hecho, así que supongamos que no tiene la opción de afectar ese problema.

Partiendo de esa suposición, ha dado el paso defensivo de solicitar formalmente la participación de su cliente en la gestión de cambios y registrar formalmente la entrada del cliente. Creo que hay dos objetivos.

  1. Ser eficaz en la incorporación de la entrada del cliente en el proceso de control de cambios a pesar de la reticencia del cliente.
  2. Asegúrese de tener una trazabilidad formal desde la entrada del cliente hasta los requisitos.

El deseo de trazabilidad formal eleva el volumen de las campanas de advertencia, pero no hay nada que podamos hacer al respecto.

Mi primera prioridad sería asegurarme de que el equipo comprenda el problema y la solución. Si el equipo no entiende el problema, no importará la cantidad de sofisticación en la implementación tecnológica.

Luego importaría o adjuntaría el documento de respuesta del cliente (lo que yo llamaría el "documento de Word épico") a la página wiki. (dependiendo de lo que admita su wiki) y cree enlaces desde sus requisitos hasta sus comentarios.

Perdón por la respuesta prolija, pero los problemas periféricos me preocupan más que la pregunta central.

Solo haría un pequeño cambio en esto: "estás enmascarando la implementación tecnológica en lugar del problema central". +1!
Hizo el cambio sugerido.
Jaja, disculpas! Quise decir que, desde mi punto de vista, sería enmascarar... pero así era yo :D
Gracias por su respuesta, no es lo que esperaba de mi pregunta (y no resuelve mi problema inmediato), pero seguramente fue útil para mí tener una segunda visión del proyecto. Tenemos nuestras propias campanas sonando y por ahora nos hemos asentado con el cliente en una forma más formal de comunicarnos entre nosotros. Esto no es lo ideal y requiere mucho tiempo, pero funciona. Estoy acostumbrado a hacer proyectos 100 % ágiles en los últimos años (con clientes satisfechos), por lo que el regreso a la cascada también fue totalmente inesperado para mí, por lo que tuve que adaptarme rápidamente.
¿Cómo puedo integrar la información de un cliente en cascada en un proyecto ágil?
RespuestasAquíPolítica de privacidad1y, 0v