Las historias de los usuarios son de alto nivel y conceptuales, la gerencia espera que los desarrolladores llenen los espacios en blanco

Estoy empleado en una empresa muy brillante con la verdadera intención de hacer XP. La comunicación es buena y la administración está abierta a una discusión constructiva, pero debido a las apremiantes limitaciones de tiempo, algunas cosas se consideran demasiado RUP para ser discutidas.

En este momento estoy un poco preocupado con el volumen de cambio que se hace necesario al implementar las historias. Creo que muchos de estos descubrimientos (que requieren tiempo y esfuerzo, por supuesto) son responsabilidad de los escritores de historias (clientes, usuarios finales y propietarios de productos) y no de los desarrolladores. En pocas palabras, las historias de usuario son demasiado conceptuales y solo transmiten la intención subyacente, pero carecen de suficientes detalles (especialmente condiciones previas y posteriores, relevancia para otras historias, dependencias y similares). Se espera que el desarrollador complete los espacios en blanco a su propia discreción debido a que los desarrolladores de XP son diseñadores y analistas al mismo tiempo. El problema es que muchos de estos espacios en blanco se descubren después de que algunas suposiciones erróneas se hayan introducido en el tiempo de evaluación y en el código, ya que se observan complejidades adicionales que surgen de lo inicialmente previsto. Incluso entonces, encontrar lo correcto para completar lleva tiempo que, en varios grados, se considera una desviación de las estimaciones iniciales.

Estoy buscando una forma constructiva de transmitir estas implicaciones a la gerencia de una manera que no me haga pasar por alguien que está tratando de complicar las cosas innecesariamente. Soy nuevo y todavía no he establecido mucha credibilidad.

Sus ideas son bienvenidas.

Estrechamente relacionado y de alguna manera da una respuesta: ¿Cuántos detalles sobre una historia de usuario puede esperar un desarrollador?

El truco es no evitar que haya espacios en blanco. El truco es completar esos espacios en blanco lo antes posible en el proceso de desarrollo.

Tiene razón en que, si los desarrolladores hacen suposiciones, invariablemente se equivocarán y eso les costará tiempo volver a desarrollar el software más adelante. Pero, igualmente, si se espera que los empresarios hagan un diseño inicial completo cuando realmente no saben lo que quieren, sucederá lo mismo.

Es una gran parte del trabajo de un desarrollador averiguar qué quiere el cliente, cuando a menudo no lo sabe realmente.

Primero, haz preguntas. Cuando las respuestas que obtenga parezcan insatisfactorias, cree un prototipo. Muestre al cliente lo que está pidiendo y permítale decirle que no es lo que realmente quiere. Comience con un prototipo en papel, luego pase a uno basado en HTML, sin código detrás. Luego, realice la menor cantidad de desarrollo que necesite para producir un producto que casi funcione y muéstreles eso. Deje las partes difíciles lo más tarde posible en el proceso.

Esto puede parecer lento en sí mismo, pero, en comparación con la reurbanización de un producto supuestamente terminado, no lo es.

Además, mantenga las historias lo más pequeñas posible. Invariablemente, lo que el negocio quiere es una epopeya, algo que se puede dividir en muchos entregables. Esto es mejor porque no habrás desarrollado demasiado cuando miran al candidato de lanzamiento final y gritan "Oh no, eso no es realmente lo que estábamos buscando".

Incluso entonces, encontrar lo correcto para completar lleva tiempo que, en varios grados, se considera una desviación de las estimaciones iniciales.

Eso no me suena muy "XP".

No soy de ninguna manera un experto en XP, pero AFAIK la idea de XP es adaptar sus especificaciones y su estimación continuamente cada vez que recibe comentarios del proceso. Y el proceso es "analizar un poco - diseñar un poco - codificar un poco - probar un poco - y luego obtener comentarios de los usuarios para corregir sus suposiciones erróneas lo antes posible. También puede intentar obtener comentarios de los usuarios aún más pronto , por ejemplo , después de diseñar algunas partes de su software (como la interfaz de usuario), en una hoja de papel o una pizarra y discutirlo con un usuario o cliente . No creo que la "forma XP" prohíba este enfoque solo por tener " historias de usuarios".

Aquí hay un buen artículo sobre cómo obtener comentarios más temprano mediante el uso de especificaciones. Creo que este tipo de pensamiento es independiente de la "metodología", y los argumentos presentados allí lo ayudarán con su debate con la gerencia.

Para resumir, se encuentra en la siguiente situación:

1. Tu eres nuevo.
2. El proyecto (supongo que estás hablando de un proyecto en ejecución) tiene limitaciones de tiempo apremiantes.
3. Se espera que el desarrollador complete los espacios en blanco a su propia discreción.
4. La empresa en la que está trabajando tiene la intención de practicar XP. Sin embargo, las historias de usuarios parecen no aplicarse de una manera que se ajuste a la metodología XP. Por otro lado " Se espera que el desarrollador complete los espacios en blanco a su propia discreción ".

Piense en el punto 4: mi opinión es que las prácticas ágiles deben adaptarse a las necesidades y la cultura de una empresa / equipo (no al revés). Identifique dónde se adhiere la empresa a la metodología XP y dónde se desvía. Esta es la base para un enfoque constructivo de sus inquietudes.

Debido a 1 y 2, actualmente no está en una buena posición para cuestionar si la empresa aplica XP de manera razonable. Comenzar una discusión con la gerencia probablemente lo hará pasar por alguien que " complica las cosas ". Sin embargo, puede comenzar a discutir sus inquietudes con sus colegas desarrolladores. Quizás encuentres algunos desarrolladores que piensen como tú. Tal vez haya un desarrollador senior que luego transmitirá sus inquietudes a la gerencia. Pero no espere que las cosas cambien rápidamente, especialmente en el proyecto actual. Sin embargo, el proyecto le dará una buena oportunidad para recopilar más datos que agreguen más sustancia a un enfoque constructivo.

Ahora al punto 3: creo que las buenas historias de usuario son escritas en colaboración por clientes / usuarios finales / propietarios de productos y desarrolladores. Muestra alguna iniciativa: busca alguna oportunidad para preguntar directamente a los autores de las historias de los usuarios. Si esto no es posible, pregunte a algún desarrollador sénior o a la gerencia cómo abordar las preguntas abiertas que deben responder los autores de las historias de los usuarios. Tal vez al menos pueda tener alguna correspondencia escrita. Dado que debe completar los espacios en blanco a su propia discreción, entonces su elección debe ser involucrar activamente a los clientes / usuarios finales / propietarios del producto.

En algún momento ha pensado y observado lo suficiente sobre cómo su empresa aplica XP (o prácticas ágiles en general). Tal vez ya haya pasado algún tiempo y ya no se te perciba como un cuerno verde. Quizás su participación activa con el cliente ha mostrado algunos efectos positivos. Quizás el próximo proyecto ya esté comenzando. Quizás también tengas alguna copia de seguridad de otros desarrolladores. Tal vez descubras que la forma en que funciona no está nada mal. El punto es que entonces tendrá suficientes ideas para transmitir sus inquietudes a la administración, basándose en la experiencia real y los datos dentro de su empresa.

Francamente, las historias de usuarios no deberían tener muchos detalles. "Quiero que el software haga X, para satisfacer las necesidades comerciales de Y" debería ser suficiente. Después de todo, no desea que las personas de negocios dicten cómo hacer eso: usted es el experto en el software y las mejores prácticas allí.

Dicho esto, los desarrolladores también deben preguntarse : "¿cómo espera que funcione?", "¿Qué sucede cuando interactúa con la función Z?". Los desarrolladores no hacen requisitos, hacen la implementación.

También parece que hay demasiada brecha entre la implementación y la evaluación. Las partes interesadas deberían estar buscando prototipos, en código a medio hacer cada pocos días. Eso le permite obtener comentarios antes de adentrarse demasiado en las malezas.

Si se le pide que calcule una historia que le parece incompleta, dígale que tiene preguntas sobre la historia y que no puede hacer una estimación adecuada antes de que esas preguntas sean respondidas.

Luego, haga sus preguntas y asegúrese de que las respuestas se vuelvan parte de la historia.

Si se ve obligado a dar una estimación incluso cuando sus preguntas no están (todas) respondidas, puede optar por negarse a dar una estimación o indicar claramente que está asumiendo los peores resultados posibles para los espacios en blanco restantes en su estimación (que probablemente hará que su estimación sea muy atípica).

Lo que haces no es una forma ágil de desarrollo. En cambio, está trabajando con requisitos de baja calidad. Es falso que una forma ágil de desarrollo no sea especificar requisitos.

En cambio, necesitan especificar inicialmente tanto como sea posible y, si es necesario, cambiar más adelante. Luego divide su trabajo en partes e implementa en iteraciones. Después de cada iteración, tienes algo terminado.

La diferencia con el desarrollo en cascada está en el desarrollo en cascada, todo se implementa con los requisitos iniciales y se cambia al final.

Parece que los desarrolladores están completamente eliminados de la creación de las historias de los usuarios. ¿Espera poder leerlos como una especificación detallada y construirla correctamente la primera vez? Si pudieras hacer eso, no necesitarías XP ni ninguna otra metodología ágil.

Alguien debería hacer preguntas si la historia es demasiado vaga. ¿Dónde ocurren las pruebas de aceptación ?

Las historias de los usuarios están destinadas a cambiar. Tienes que lidiar con eso.

Aunque un desarrollador podría escribir una historia / requisitos detallados, no he visto a muchos que sean buenos en eso. Somos buenos para señalar problemas, sugiriendo mejores flujos, pero como una entrada a un caso ya bien escrito.

Trabajé en productos nuevos y existentes y en ambos tuvimos casos donde los requisitos eran solo de 5 líneas y se esperaba que llenáramos los espacios en blanco y hiciéramos un 'entendimiento' o un documento más elaborado.

Los proyectos se movieron mucho mejor, entonces tuvimos nuestra propia persona de servicios profesionales que ayudó con esto (o en un caso, un vicepresidente que intervino porque no había nadie más disponible). De cualquier manera, es una pérdida de tiempo desarrollar (a menos que no haya retroalimentación y la fecha límite no haya cambiado). así que mi sugerencia: solicite más detalles, brinde más, solicite retroalimentación con tiempo limitado a sus suposiciones y documentación y declare que es un riesgo de que haya retrabajo y demoras si no obtiene esta información para la fecha x.

Independientemente de la metodología de desarrollo, si lo que esté utilizando para definir los requisitos hace que el desarrollador haga suposiciones, es necesario devolverlo al lado comercial. A menudo tengo una buena idea de qué respuesta preferiría, así que rechazo las cosas así:

XYZ no está claro para mí. ¿Significa ABC? ¿O me estoy perdiendo algo? (Suponga que XYZ es el requisito, suponga que ABC es la suposición que me gustaría hacer como desarrollador)

Toma mucho menos tiempo aclarar las cosas antes de hacer suposiciones erróneas que rehacerlas. Los desarrolladores que hacen conjeturas sobre los requisitos sin obtener la confirmación de que su suposición es correcta tienden a ser malos desarrolladores y le cuestan mucho dinero a su empresa. Si un mal gerente no le permite rechazar las cosas, explíquele cuánto más caro es en términos de tiempo y dinero hacerlo mal. Si él todavía insiste, entonces haga lo que dice y cuando falle UAT, la próxima vez que quiera devolver algo, recuérdele lo costoso que fue el momento en que no lo dejó. Si todavía no escucha, encuentra un mejor jefe.

El otro valor de devolver las cosas es que, gradualmente, la empresa aprenderá lo que necesita y le dará mejores requisitos.

Como desarrollador,

Necesito comprender completamente los detalles de una historia de usuario,

para que pueda estimarlo e implementarlo con confianza.

En otras palabras, debe hacer preguntas hasta que comprenda los detalles de la historia. Esto se realiza en la planificación de iteración y actúa como punto de decisión: si no puede estimarlo, no puede construirlo.