¿Qué argumentos puedo usar para "vender" el concepto de BDD a un equipo reacio a adoptarlo?

Soy un defensor vocal de la metodología de Desarrollo Conducido por el Comportamiento (también conocido como BDD). He estado aplicando BDD durante un par de años y he adoptado StoryQ como mi marco de elección al desarrollar aplicaciones DotNet. A pesar de que he estado haciendo pruebas unitarias durante muchos años, y previamente había cambiado a un enfoque de prueba primero, descubrí que obtengo mucho más valor al usar un marco BDD, porque mis pruebas capturan la intención de los requisitos en relativamente inglés claro dentro de mi código, y debido a que mis pruebas pueden ejecutar múltiples aserciones sin terminar la prueba a la mitad, lo que significa que puedo ver qué aserciones específicas pasan / fallan de un vistazo sin depurar para probarlo.

Esto realmente ha sido la punta del iceberg para mí, ya que también he notado que puedo depurar tanto el código de prueba como el de implementación de una manera más específica, con el resultado de que mi productividad ha crecido significativamente y que puedo más determine fácilmente dónde ocurre una falla si ocurre un problema para llegar a la compilación de integración debido a la salida que llega a los registros de compilación. Además, la API StoryQ tiene una sintaxis fluida encantadora que es fácil de aprender y que se puede aplicar de muchas maneras, sin necesidad de dependencias externas para usarla.

Entonces, con todos estos beneficios, pensaría que es fácil presentar el concepto al resto del equipo. Desafortunadamente, los otros miembros del equipo son reacios incluso a mirar StoryQ para evaluarlo adecuadamente (y mucho menos considerar la idea de aplicar BDD), y se han convencido mutuamente para tratar de eliminar una serie de elementos de StoryQ de nuestro propio marco de prueba central, incluso aunque originalmente admitieron el uso de StoryQ, y aunque el código que desean eliminar no afecta a ninguna otra parte de nuestro sistema de prueba. Si lo hace, terminaría aumentando mi carga de trabajo significativamente en general y realmente va en contra de la corriente, ya que estoy convencido por experiencia práctica de que es una mejor manera de trabajar en un entorno de trabajo particular y solo puede conducir a una mayor mejoras en la calidad de nuestro software, dado que ' Me ha resultado más fácil seguir con la prueba usando BDD. Para aclarar aún más, la mayoría de las pruebas unitarias que tenemos tienden a ser bastante frágiles y difíciles de mantener, un remanente de años de pruebas mal aplicadas donde la renuencia a seguir un proceso basado en pruebas ha visto a los desarrolladores recurrir a viejos hábitos y haga todas sus pruebas al final del proyecto (¡estas mismas personas dicen ser ágiles!).

Entonces la pregunta realmente se reduce a lo siguiente:

1. ¿Qué argumentos puedo usar para realmente señalar que sería mejor para este equipo usar StoryQ, o al menos adoptar la metodología BDD?
2. ¿Puede señalarme alguna evidencia anecdótica que pueda utilizar para apoyar mi argumento de adoptar BDD como nuestro método estándar de elección?
3. ¿Qué contraargumentos puedes pensar que sugieran que mi deseo de alentar al equipo a adoptar BDD podría ser un error? Sí, estoy feliz de que se demuestre que estoy equivocado, siempre que el argumento sea sólido.

NOTA : No estoy abogando por que reescribamos nuestras pruebas en su totalidad, sino que simplemente comencemos a trabajar de una manera diferente para todo el trabajo de prueba futuro, y preferiblemente en la forma en que involucramos a nuestros clientes.

Y para aquellos de ustedes que deseen aprender más sobre BDD, los siguientes enlaces pueden ser útiles:

• http://dannorth.net/introducing-bdd/
• http://en.wikipedia.org/wiki/Behaviour_driven_development
• http://behaviour-driven.org/Introduction

_{Para aquellos interesados ​​en más detalles, somos un pequeño equipo de 4 personas que trabajan en aproximadamente 5 proyectos grandes. La "prueba piloto" para BDD se ejecutó durante aproximadamente 2 meses inicialmente, con otro período de aproximadamente 4 meses después. El equipo aceptó que debía continuar trabajando de esta manera y que debía hacer sus propias pruebas. He estado BDD durante aproximadamente 2 años desde que terminó el juicio, mientras que los otros se han vuelto muy buenos para esquivar el problema. En lugar de forzar una "confrontación" sobre el tema, estoy buscando maneras de persuadir suavemente al equipo para que se salga de sus espaldas colectivas y se tome el tiempo para hacer su parte.}

¿Qué argumentos puedo usar para realmente entender que sería mejor usar StoryQ, o al menos aplicar la metodología BDD?

"El cliente lo quiere".

En mi opinión, desea vender BDD a sus clientes / expertos de dominio al menos tanto como al equipo de desarrollo.

BDD es un proceso colaborativo de afuera hacia adentro donde participan múltiples partes interesadas. Los beneficios de BDD no son solo para que los desarrolladores infieran automáticamente su código de prueba a partir de las pruebas de aceptación, sino que también radican en la cooperación creativa que se lleva a cabo entre técnicos y empresarios para producir especificaciones valiosas y bien definidas del comportamiento previsto del sistema.

Por lo general, también se agradece a los clientes / analistas de negocios el acceso a una interfaz donde pueden ejecutar cada especificación ejecutable, controlar su estado y ver la progresión en su implementación.

Hay una presentación de Dan North sobre cómo vender BDD a la empresa: http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

1. En un equipo reacio a adoptar BDD, es probable que no haya "argumentos" que pueda usar para "convertir" a sus colegas en una adopción a gran escala.
    
   Creo que lo mejor que puedes hacer es convencerlos de que lo prueben ("prueba de humo", "prueba en seco", "proyecto piloto"), especialmente si dejas perfectamente claro que abandonarás la idea si los resultados de la prueba son negativos
2. Su enfoque para encontrar evidencia anecdótica se ajusta perfectamente a la idea de convencer al equipo para que lo intente. Para eso, simplemente buscaría en la web algo como "Historia de éxito del desarrollo impulsado por el comportamiento" y elegiría lo que me parece más fácil de usar.
3. Hay un par de argumentos contrarios que puedo pensar que podrían sugerir que su deseo de convertir los esfuerzos del equipo a BDD podría ser un error.
    
   Ninguno de estos es particularmente constructivo, especialmente desde el punto de vista de un "defensor del cambio", pero desafortunadamente es probable que tenga que lidiar exactamente con este tipo de retórica ( BTDTGTTS ):
    
   • no puede garantizar que la productividad general del equipo mejorará
   • no puede garantizar que los esfuerzos invertidos en la adopción de BDD den un ROI sustancial
   • al equipo le estaba yendo lo suficientemente bien sin BDD, el riesgo de cambiar el enfoque actual no está justificado
   • Google (o Microsoft, o IBM, simplemente complete el nombre del proveedor de software "respetable") funcionará bien sin BDD, lo que "prueba" que BDD no es necesario
   • los enfoques no BDD no tuvieron una oportunidad justa en las pruebas comparativas
   • BDD puede estar generalmente bien, pero para este y ese módulo / proyecto no es aplicable

Según mi experiencia, la forma menos dolorosa de abordar los argumentos contrarios como se enumeró anteriormente fue realizar una ejecución de prueba controlada limitada para un cambio propuesto.

El estado de "prueba limitada" esencialmente invalida tres de los cuatro argumentos anteriores, excepto uno sobre "vendedor respetable", que podría contrarrestarse proporcionando evidencia anecdótica de la historia de éxito (la evidencia anecdótica probablemente no funcionará para un "cambio de big bang" sino para pruebas limitadas es lo suficientemente bueno).

Si el cambio realmente vale la pena y la ejecución de la prueba se organiza correctamente, notará un cambio positivo en la actitud del equipo y la gerencia, haciendo que la transición a un cambio a gran escala sea fluida e indolora.

Otro beneficio de la ejecución de prueba limitada es que le permite aclarar y ajustar los detalles del proceso objetivo sin causar demasiados problemas y con un menor riesgo de "daño a la reputación" de la idea. Cada vez que participé en tales ejecuciones de prueba , me sorprendió gratamente descubrir lo fácil que fue cambiar a la adopción a gran escala con los detalles más importantes establecidos y aclarados en la ejecución de la prueba.

Puede ser hora de reclutar a la gerencia. Si lo ha intentado y ha visto resultados sólidos, pero el equipo se resiste, es posible que la administración deba involucrarse.

Esto es especialmente cierto si están perjudicando al miembro del equipo más productivo de la empresa. Prepárate para la reacción violenta. Puede comenzar por acercarse a la administración y buscar que el equipo deje de debilitarlo sacando sus casos de prueba.