¿Qué hacer con respecto al "Desarrollo impulsado por fallas"?

En nuestra tienda, nos esforzamos por ser ágiles. Y yo diría que estamos haciendo grandes avances. Dicho esto, algunos de nosotros hemos detectado un patrón que hemos comenzado a llamar "Desarrollo impulsado por fallas".

El desarrollo impulsado por fallas se puede describir básicamente como un ciclo ágil de lanzamiento / iteración donde los errores / características se guían no por tareas e historias con criterios de aceptación, sino con defectos ingresados ​​en el software de seguimiento de defectos.

Nuestro equipo tiene un excelente gerente de proyecto que se esfuerza por obtener los criterios de aceptación del cliente (s), pero no siempre es posible. Desde mi silla de desarrollo, esto se debe a que el cliente no sabe exactamente lo que quiere o (y esto es lo mejor) dos "campamentos" diferentes en el conflicto de la oficina principal del cliente con la forma en que se debe implementar una historia. Un campamento será ligeramente dictan que funciona la característica X como este , entonces el campamento B fallará debido no funciona como esa . Por lo tanto, el término "FDD". El proceso es impulsado por "fallas".

Esto lleva a mi pregunta: ¿Alguien más se ha encontrado con esto y, de ser así, algún consejo / sugerencia para solucionarlo?

Por supuesto, hemos tratado de lograr que el campamento A y B estén de acuerdo antes, pero todos saben que este no es siempre el caso.

Gracias

Los requisitos extremadamente conflictivos no son inusuales en el mundo corporativo. Y esta es con frecuencia la razón por la que los proyectos de automatización de procesos empresariales "fallan". Puede ser tan simple como "el manual de políticas y procedimientos dice hacer X" mientras que las personas que realmente hacen el trabajo hacen Y. Hacer que el software haga Y significa que las personas que pagan por el software insistirán en que el software es defectuoso perspectiva. Hacer que el software haga X significa que las personas que realmente hacen el trabajo no pueden hacer el trabajo.

Normalmente, la mayoría de las empresas de desarrollo elegirán lo que dicen los gerentes sobre lo que dicen los trabajadores porque así es como se pagan las facturas. En el mundo ideal, no hay desajuste de impedancia entre las políticas escritas y reales; En el mundo real, gran parte del trabajo de oficina se divide y no se documenta de manera informal.

El Campamento A dictaminará que la Característica X funciona así, luego el Campamento B fallará debido a que no funciona así.

La falta de coincidencia entre CampA y CampB es un problema político y no un problema de software. Resolver el problema implicará hablar con la gente y obtener un ganador claro.

Una de las principales razones para utilizar el desarrollo iterativo es porque tiene un grupo de clientes que no tiene una buena idea de lo que quiere.

Esto no es un fracaso. Muchos clientes simplemente no tienen una idea de lo que necesitan exactamente hasta que tienen algo en sus manos. Esta es la razón por la cual la primera vez que el cliente ve que el sistema no debe funcionar después de que se haya realizado todo el ajuste y acabado. Déjelos verlo temprano y con frecuencia.

En otras palabras, si ese fuera el único problema, no hay necesidad de entrar en pánico a menos que termine en una situación en la que simplemente tenga reintentos interminables.

El problema de desacuerdo entre el cuerpo del cliente es un problema de Gerente de Producto que no debe filtrarse a usted. Lo máximo que debería ver es la acumulación / tareas / lo que sea. Por supuesto, el PM a menudo se desahogará en el rango de desarrollo porque ese es el único lugar donde pueden, pero no debería afectarlo.

La forma en que se gestione dependerá en gran medida de quiénes son los campamentos A y B.

Si el Campamento A y el Campamento B representan dos superiores, entonces traiga a alguien que realmente use el sistema para decirle lo que necesita. A veces, obtienes aire enrarecido en la tierra de gestión que causa una desconexión con la realidad. Alguien que es práctico a menudo puede cortar el idealismo y señalar lo que realmente se necesita.

Por otro lado, si A y B son grupos de usuarios, usted usa la táctica opuesta de conseguir que alguien de la gerencia establezca la ley.

En todos los casos, la perfección es enemiga de lo suficientemente bueno.

Lo que describe es una implementación incorrecta típica de Agile. No abrazas el cambio, eres su esclavo .

¿Tienes un dueño de producto? ¿Puedes hablar con ellos según sea necesario? ¿Estás haciendo una revisión de sprint con los usuarios? ¿Están los usuarios involucrados en el proceso (a través del propietario del producto) en la planificación del sprint? ¿Tienes probadores en el equipo principal?

Le recomiendo que contrate a un entrenador ágil y / o envíe a su equipo a un entrenamiento.

Otra solución es dejar de hacer Agile.

Si están haciendo ping-pong (A dice do x, B rechaza, dice y, luego A rechaza y vuelve a x), entonces tus leads (PO o lo que sea que tengas) necesitan golpearlos para decidirse .

Está bien si el primer intento termina no satisfaciendo sus necesidades (el objetivo de esto es darles algo para mirar) pero si se sientan allí y se balancean hacia adelante y hacia atrás en las iteraciones posteriores, nunca terminarán.

El problema aquí no parece ser "Lo sabré cuando lo vea". Wireframes puede ayudar (hasta cierto punto) con ese problema en particular.

El problema aquí es, me parece, las dos facciones en competencia dentro de su cliente. Idealmente, los campamentos A y B tendrían una visión compartida negociada que podrían presentarle.

Tal vez se vean obligados a ir a la mesa explicando cuánto les cuesta la lucha interna mientras vuelven a repetir lo que A pidió por B (o viceversa).

Mantener notas detalladas de su gasto de tiempo ayudaría aquí. (Mi trabajo escribió una aplicación de seguimiento de tiempo liviana: fácil de usar y fácil para informar, e informa el tiempo en fragmentos de 15 minutos. Hace que sea fácil decir "Pasé n horas en la función X").

Significa que está un poco en riesgo de molestar al cliente o de verse mal sin importar lo que haga, ya que lo que hace por B puede molestar a A (o, viceversa).

Esperemos que pueda encontrar un campeón en el cliente que se encargue de las luchas internas por usted.

A mi entender, el problema solo se puede resolver de manera efectiva en un lugar, en el cliente, lo que va a ser difícil.

Estás mencionando que estás luchando por lo ágil, así que lo tomaré desde la perspectiva de scrum, que es el proceso ágil que mejor conozco.

Según scrum, usted tiene un rol específico, el propietario del producto, que es responsable de priorizar las historias / errores / lanzamientos de usuarios, etc. Idealmente, esta debería ser solo una persona. Si hay muchas partes interesadas con diferentes puntos de vista sobre el mismo software, es responsabilidad del propietario del producto que el producto satisfaga a todas las partes interesadas.

Me parece que su gerente de proyecto tiene este papel. Pero como se le llama gerente de proyecto y no propietario de un producto, me hacen creer que él también está agobiado con otras tareas (¿tareas de gestión tradicionales, no ágiles?), Y no tiene el tiempo suficiente para realizar la tarea. Rol del propietario del producto.

Por lo tanto, creo que necesita una persona con la responsabilidad de coordinar las necesidades entre los diferentes equipos del cliente, asegurando que los requisitos / historias de usuarios que se entregan a los desarrolladores hayan sido verificados por ambos equipos en el cliente. Perseguir este rol puede ser fácilmente un trabajo de tiempo completo, especialmente con el cliente que tiene.

Lo que realmente sería ideal es trasladar esta responsabilidad al cliente, que uno de los empleados de su cliente tenga el rol de propietario del producto. Mientras el cliente no tenga esta función, el cliente no se compromete a resolver sus propios desacuerdos internos, y le deja a usted resolver eso, lo que probablemente no podrá. Y es por eso que creo que la única solución efectiva es darle al cliente esta responsabilidad.

Pero dado que ya ha comenzado una colaboración, creo que tendrá dificultades para implementar ese cambio.

Para que su cliente acepte su software, debe cumplir los requisitos establecidos por el cliente de acuerdo con los criterios de aceptación.

Usted tiene un conjunto de requisitos de usuario en forma de historias y criterios de aceptación, pero partes de la organización del cliente tienen diferentes interpretaciones de las historias de los usuarios, lo que lleva a la ambigüedad.

Puede salir de esta situación describiendo el diseño funcional y las reglas de negocio implementadas y haciendo que el cliente las firme. Estos serán lo que se prueba durante la aceptación. Esto debe ser acordado previamente por el cliente para evitar discusiones sobre el significado de toda la documentación posterior.

Mientras su grupo no pueda describir el software que está creando de tal manera que ambos grupos estén de acuerdo, todavía está en la fase de análisis de requisitos del proyecto.

Su gerente de proyecto podría / debería ofrecer consultoría pagada como parte del proyecto para resolver la ambigüedad en los requisitos funcionales.

Creo que todos hemos visto el caso en el que obtenemos requisitos detallados del usuario, los implementamos y luego escuchamos al usuario "Espera, eso no va a funcionar para mí" una vez que se haya implementado.

Una cosa que ayudaría es hacer una forma de control de calidad de los requisitos al dar al usuario ejemplos detallados con el comportamiento esperado del sistema. Por ejemplo, podría decir: "Aquí hay un caso de ejemplo. Si implementamos X, entonces Y será el resultado, y Z una de las consecuencias". De esa manera, puede llegar a "Esperar, eso no va a funcionar" antes de escribir el código en lugar de después.