¿Cómo tener éxito en los talleres de especificaciones de BDD?

Hoy intentamos introducir BDD en nuestro proceso de desarrollo de software mediante un taller de especificaciones.

Para este taller tuvimos 2 desarrolladores, 1 probador y 1 analista de negocios. El taller duró 1h30 y al final logramos resolver algunos escenarios de BDD para nuestra nueva función. Intentamos centrarnos en encontrar los escenarios que podríamos pasar por alto y los difíciles.

Al final del taller, algunas personas no estaban contentas con el taller.

Un desarrollador sintió que perdió su tiempo ya que el analista de negocios solía entregar los escenarios directamente y revisarlos con ella. La analista de negocios no se sintió segura con nuestra cobertura de escenarios (tenía la sensación de que podríamos haber perdido otras cosas importantes), pero lo más importante fue que este taller también fue una pérdida de tiempo, ya que ella misma podría haber descubierto todos estos escenarios. y en un período de tiempo más corto .

Este taller experimental duró 1h30, y al final del mismo, no nos sentimos lo suficientemente seguros de lo que hicimos ... seguro de que podríamos haber pasado más tiempo en él, pero sinceramente, la mayoría de las personas se cansan después de 1h30 de lluvia de ideas para buscar negocios reglas del cerebro BA.

Entonces mi pregunta es cómo ese tipo de taller realmente puede funcionar. En la teoría, dado que tiene una nueva característica para desarrollar, coloca el árbol 'amigos' (dev / tester / ba) en la misma sala para que puedan colaborar juntos en la escritura de los diferentes requisitos para la nueva característica usando ejemplos. Puedo ver todos los beneficios de eso. Especialmente en términos de intercambio de conocimientos y producto común / objetivo final / visión hecha.

Nuestra conclusión de este experimento fue que en realidad es más rentable tener primero un BA para trabajar por su cuenta en los ejemplos y solo luego hacer que los escenarios sean revisados ​​/ reelaborados por los 3 'amigos'. Al hacer que el BA trabaje por su cuenta, en realidad nos sentimos más seguros de que nos vamos a perder menos cosas + todavía podemos revisar los escenarios después para verificarlo dos veces. No creemos que una simple sesión de lluvia de ideas / descubrimiento deliberado sea suficiente para cubrir seriamente todos los requisitos de una nueva función. El analista de negocios es en realidad la mejor persona para ese tipo de cosas. Lo mejor que podemos hacer es revisar lo que escribió y ver si tenemos un entendimiento común (lo que podría llevar a reescribir algunos de sus escenarios o agregar otros nuevos que podría haberse perdido).

Entonces, ¿cómo puede lograr que funcione de manera efectiva en la práctica ?

Si puede derivar los escenarios de la descripción, ya está.

Un antipatrón que a menudo veo en BDD es que las personas sienten la necesidad de hablar y escribir cada escenario en detalle.

Algunos escenarios se entienden tan bien que es suficiente derivarlos de una breve descripción. Por ejemplo, si digo: "Me gustaría la función de inicio de sesión esta semana", ya sabes cómo debería ser. Usted sabe que hay escenarios para la contraseña correcta, la contraseña incorrecta, el nombre de usuario incorrecto. Realmente no necesitamos hablar a través de ellos o capturarlos en detalle.

De manera similar, podría decir: "Aquí está el formulario para el registro de usuarios. Necesitamos poder crear nuevos usuarios, permitirles editar sus detalles y eliminarse a sí mismos, excepto que la eliminación no debería eliminar realmente, solo debería marcarlos como eliminados para que puedan recuperar sus cuentas si lo desean ".

Y puede preguntar: "¿La recuperación de la cuenta es parte de esta función?"

"Pueden ser dos características si quieres".

"Bien, entonces tenemos escenarios para crear, leer, actualizar, eliminar; eso debería ser bastante fácil. Hablemos de la recuperación de la cuenta; eso suena más interesante".

En general, si la descripción del comportamiento es suficiente para que el equipo de desarrollo deduzca los escenarios, no es necesario que los analice. Puede hacerlo si tiene alguna duda, pero es posible que solo desee capturar los escenarios que necesita recordar, si captura alguno.

Si nunca lo ha hecho antes o no está seguro, hable sobre los escenarios.

Concéntrese en las áreas que son inusuales, particularmente si hay características que nunca antes había hecho. Estos son lugares fantásticos para conversar y anotar cualquier ejemplo sorprendente que surja. Por lo general, tengo dos preguntas que hago, según la plantilla de BDD:

Dado un contexto
Cuando ocurre un evento
Entonces debe ocurrir un resultado.

• ¿Existe algún otro contexto que, para el mismo evento, produzca un resultado diferente?
• ¿Hay algún otro resultado que también sea importante?

Si todos en la mesa parecen aburridos, la característica por la que estás hablando probablemente se entienda bien. A menudo es suficiente decir: "Debería funcionar como X , pero con Y en su lugar". Esto es lo que Dan North llama el patrón Ginger Cake ; Es como la receta del pastel de chocolate, pero con jengibre en lugar de chocolate.

Incluso si la parte interesada en el negocio puede derivar los escenarios por sí mismo, es realmente importante que el equipo de desarrollo pueda hablar con él, retomar e internalizar su idioma. Ese lenguaje luego se lleva al código, lo que les permite tener mejores conversaciones en el futuro y ayuda a los recién llegados al proyecto a comprender lo que está sucediendo. Si los desarrolladores no pueden hablar el idioma, no lo usarán .

Si la parte interesada de la empresa o el analista realmente no quiere pasar el tiempo capturando cosas en la sesión, prefiero que los desarrolladores escriban los escenarios en colaboración con los evaluadores y luego le pidan que lo revise. Es más probable que esto descubra malentendidos que al revés.

A veces BDD no funciona.

Otra posibilidad es que encuentre un escenario sobre el cual las partes interesadas del negocio no estén seguros. "¡Oh, no había pensado en eso! No estoy seguro". En lugar de tratar de concretar el negocio y castigarlo con certeza, puede valer la pena abandonar BDD en este punto e intentar algo simple para obtener algunos comentarios y darle al negocio algo sobre lo que puedan iterar. Facilite el cambio y escriba los escenarios una vez que haya una mejor comprensión de lo que está sucediendo.

BDD hecho bien puede realmente ayudar a descubrir lugares de incertidumbre. Puesto que cada proyecto tiene vale la pena hacer algún aspecto de ella que es nuevo y nunca se ha hecho antes, no es cierta incertidumbre en allí, en alguna parte. Si te enfocas en usar los escenarios para ayudar a descubrir deliberadamente la ignorancia , aprenderás más rápido, y el aprendizaje suele ser una gran parte del tiempo dedicado a un proyecto.

Además, descubrí que cuanto más colaboran los equipos de desarrollo de esta manera, más preparados están los negocios para confiar en ellos con incertidumbre, y más innovación comienza a ocurrir. Las empresas innovadoras, por su propia naturaleza, tienen mucha incertidumbre en sus proyectos.

Hace un tiempo escribí una publicación en el blog sobre Cynefin , que creo que realmente me ayuda a comprender dónde serán más efectivas las conversaciones. Si lo lees y entiendes los cuatro dominios, aquí están las reglas que uso:

• Las cosas simples y complicadas (conocidas) a menudo se entienden bien y no necesita hablar sobre los escenarios en detalle.

• Las cosas altamente complejas (desconocidas) no se entienden en absoluto. Puede descubrir esto hablando de los escenarios. La falta de certeza significa que BDD no funcionará aquí, así que repita algo fácil de cambiar y obtenga comentarios rápidos en su lugar. Cualquier práctica que conserve sus opciones, como las pruebas AB, también es excelente en este espacio.

• BDD funciona de manera brillante en el espacio intermedio (conocible) como un mecanismo para transmitir el conocimiento y descubrir los otros dos espacios. No es un martillo, y no todo es un clavo. De hecho, si puede concentrar el tiempo que pasa teniendo conversaciones en algo, no se trata de los ejemplos que puede encontrar; se trata de encontrar los ejemplos que no puedes .

La duración de la reunión no es su problema. Está bien que esas reuniones se prolonguen mucho tiempo. PERO todos deberían salir sintiéndose confiados. Que no lo hicieron es tu problema.

Sugeriría una breve reunión para discutir un requisito. Programe una segunda reunión unos días después, para que todos sepan que deben estar preparados para entonces.

Luego, el BA y el probador deben presentar sus escenarios, porque ambos miran el software de maneras muy diferentes. Pídales que las escriban en tarjetas y las peguen en un pizarrón en algún lugar, al menos un día antes de la segunda reunión, deje que todos lo revisen a su propio tiempo y lo piensen. Deseche los duplicados, pegue los escenarios que no se consideraron.

No deseche nada con lo que no esté de acuerdo, pero márquelo como contencioso. Si una conversación muy breve con la persona que lo escribió le ayudará, hágalo, pero sobre todo guárdelo.

ENTONCES tenga su reunión de planificación / diseño. Tenga una agenda sólida para esa reunión (comience con la pila de tarjetas, coloque las polémicas en la parte superior) y no permita que se desvíe. Asegúrese de salir de esa reunión con todos los puntos de contención resueltos.

¡Siempre asegúrese de que todos en una reunión estén preparados para el tema de esa reunión!

Nunca use una reunión para "hacer una lluvia de ideas" juntos. Pierde el tiempo de todos.

Receta general para reuniones efectivas:

• haga que alguien prepare los artículos para ser discutidos
• requerir que todos los participantes hayan estudiado (no solo leerlos) esos elementos
• recopilar comentarios de antemano y exigir a todos los participantes que los hayan estudiado (no solo leído)
• celebrar la reunión para tomar decisiones

Sobre las quejas ...

Comencemos con estos:

Un desarrollador sintió que desperdiciaba su tiempo, ya que el analista de negocios le daba los escenarios directamente y los revisaba con ella.

Que es lo que estaba haciendo en el taller. Eso me parece una excusa malhumorada y mala. Sospecho que a este desarrollador simplemente no le gusta (o ambos) el escrutinio del taller y sus restricciones de programación.

El analista de negocios no se sintió seguro con nuestra cobertura de escenarios (tenía la sensación de que podríamos habernos perdido otras cosas importantes)

¿Cómo es esto diferente de cuando lo hace de su lado y lo revisa un desarrollador, aparte del hecho de que más personas lo miraron? Sospecho que esto es solo el resultado de que el taller sea quizás un poco caótico. Obtendrá la confianza de que tiene suficientes pruebas al implementarlas e integrarlas. Nunca puede estar seguro de haber encontrado todos los errores, y cuando se trata de cobertura, la mejor manera sería diagramarlos en sus historias de usuario.

pero lo más importante fue que este taller también fue una pérdida de tiempo, ya que podría haber descubierto todos estos escenarios por sí misma y en un período de tiempo más corto.

Sí, y completamente sola, en su jardín amurallado, y sin compartir conocimientos. Mientras que al hacer esto, los talleres futuros podrían ser más productivos ya que todos los participantes han adquirido un poco de conocimiento sobre cómo abordar estas cosas.

Tal vez la reunión fue lenta esta vez, no significa que siempre lo será. Y como personal externo, habría dado algo de capacitación para hacerlo bien, más confianza en que la cobertura fue mejor en un taller con 3 participantes con diferentes mentalidades que con un solo dictador.

Además, si ya era necesario que un desarrollador revisara estos escenarios con ella, estoy bastante seguro de que el intercambio es mucho más rápido y eficiente en el taller que usar "Hago mis cosas solo y doy cosas a usted, lo revisa solo y me responde y hagamos esto nuevamente "enfoque.

Sugerencias

• Sea positivo y haga hincapié en que si el proceso es correcto, mejorará.

• Intente racionalizar el taller y mantenerlo en el camino.

• Tal vez dé algo de espacio para el análisis del "lobo solitario", comenzando el taller con todos diseñando algunos escenarios por su cuenta (incluso mejor, antes del taller), luego clasifíquelos y combínelos.

Y si no crees que sea necesario hacer una lluvia de ideas, está bien: haz que el BA trabaje solo, pero luego haz la revisión como un taller, al menos. Los más ojos, mejor, para citar a Eric S. Raymond 's Ley de Linus :

Given enough eyeballs, all bugs are shallow.

Ya tienes algunas respuestas bastante buenas aquí, así que me voy a centrar en un pequeño aspecto que hasta ahora se ha pasado por alto. El papel de cada uno de los Tres Amigos debería poder cumplir con la sesión. Cada uno ofrece valor de diferentes maneras, cada uno comprende un conjunto diferente de restricciones.

En general, el BA debería ser capaz de llevar el camino feliz principal a la sesión, también debería ser capaz de proporcionar los principales escenarios de falla desde una perspectiva comercial. La experiencia de prueba debe ser capaz de identificar casos extremos y escenarios adicionales necesarios para demostrar que el sistema funciona en todas las circunstancias. El trabajo del desarrollador no es realmente agregar escenarios, aunque a menudo lo harán por fallas técnicas, su trabajo también asegura que tengan una comprensión completa de los requisitos para que transmitan implicaciones e implementen el requisito con el mínimo de comunicación adicional.