¿El desarrollo dirigido por el comportamiento (BDD) es apropiado para una startup?

Esta pregunta es demasiado amplia para responder simplemente sí o no.

BDD es una de las herramientas que el equipo de desarrollo profesional puede usar si es necesario. El uso de Behavior Driven Development para todos los requisitos suele ser una pérdida de tiempo.

Me encanta explicar cuándo usar Behavior Driven Development explicando el concepto de Cynefin Framework.

Tiene cinco áreas / categorías de problemas / categorías de requisitos para su producto : Obvio, Complicado, Complejo, Caos y Trastorno.

En este artículo, Liz Keogh describió 5 niveles de ignorancia para los requisitos de software. Puede asignar estos niveles en Cynefin Framework:

• 1er nivel en Obvio: todos saben cómo se debe implementar este requisito
• 2do nivel entre Obvio y Complicado: algunas personas de nuestro equipo saben cómo se debe implementar.
• 3er nivel en la esquina superior derecha de Complicado: hay algunos expertos en nuestra organización que ya saben cómo debería funcionar y qué debería hacer, pero solo unos pocos.
• Cuarto nivel de ignorancia, en algún lugar entre Complicado y Complejo: alguien, en algún lugar ya lo hizo pero no en nuestra organización, por lo que no sabemos cómo debería funcionar.
• 5to nivel en la esquina superior izquierda, en la zona compleja; ninguno lo había hecho antes.

Cuando suelo trabajar con equipos, empiezo con la clasificación de requisitos. Hacemos eso para elegir el método y las herramientas adecuadas para implementarlos. El proceso comienza con el mapeo del trabajo acumulado en Cynefin y esos 5 niveles de ignorancia.

Las cosas que están en el primer y segundo nivel de ignorancia generalmente no necesitan especificarse y aclararse, por lo que no perdemos el tiempo para escribir historias de usuarios y escenarios en pepinillo para ellas. No debería haber ningún problema para comprender esos requisitos, ya que la mayoría de los miembros del equipo saben lo que hay que hacer. (Tenga en cuenta que Obvious está cerca del Caos y si ese tipo de requisitos no se gestionan en absoluto, pronto se volverá caótico y problemático).

Nivel 3: donde tenemos acceso limitado al dominio de los expertos, el conocimiento sobre cómo deberían funcionar las cosas es un lugar perfecto para usar BDD. Aquí el valor es más alto y los costos de BDD (ningún BDD no viene gratis) están justificados por los beneficios. BDD como herramienta de comunicación funciona perfectamente cuando buscamos un intercambio rápido de conocimientos y una comprensión común de los requisitos.

Nivel quinto y, a veces, cuarto: usar BDD aquí es más como adivinar. No sabemos cómo debería funcionar y no sabemos si es posible implementar requisitos particulares de la forma en que lo describimos en nuestras Historias de usuarios y Escenarios / Ejemplos. Para este tipo de requisitos, primero estamos haciendo un trabajo de investigación y desarrollo o ingeniería inversa. Al crear algunos prototipos o picos, descubrimos cómo se pueden cumplir los requisitos. Lo que realmente sucede después de la I + D es que al crear prototipos y experimentar, obtenemos el conocimiento y pocos expertos (antiguos investigadores) aparecen en nuestra organización. Por lo tanto, los requisitos se mueven del 4to y 5to nivel al 3er nivel donde podríamos implementarlos exitosamente usando BDD.

Usar BDD en 5to y 4to nivel es a menudo confuso. Usarlo en el primer y segundo nivel es una pérdida de tiempo porque simplemente no es necesario allí.

Entonces, responda su pregunta: BDD podría usarse con éxito para nuevas empresas (así como para otros tipos de productos) pero no para todos los requisitos.

PD: Mantener su cartera de pedidos como notas adhesivas en el gráfico de Cynfin puede ser una buena idea que vale la pena probar.

PPS: Por cierto, el enfoque dogmático y apegarse al único método / enfoque de desarrollo para todo es, en mi opinión, la causa principal de la mayoría de los problemas en el desarrollo de software moderno.

“Si todo lo que tienes es un martillo, todo parece un clavo ”