Vender TDD al equipo

Question

He estado haciendo TDD durante los últimos 3 años. Éramos una empresa pequeña, y contamos con un soporte muy sólido para la mayoría de los aspectos del proceso ágil de la administración. Todos en el equipo de desarrollo se vendieron en el proceso. Y por lo tanto, la inversión inicial que normalmente se requiere para construir instalaciones fue aceptada sabiendo que pagaría en el camino. (Código que inicia un servidor http, código que rellena las bases de datos sql antes de las pruebas, etc.). La documentación ocurría principalmente en las pruebas y las solicitudes de ayuda generalmente se presentaban en forma de prueba fallida.

Ahora me mudé a una empresa más grande, y aunque la administración apoya el proceso Ágil, los compañeros de equipo son una mezcla, algunos lo ven útil, algunos lo hacen debido a la gestión y otros no ven el valor. Ha sido un desafío convencer a la gente de dedicar algún tiempo a la construcción de instalaciones o convencer a un miembro del equipo de la mejor manera de ayudarlo si se toma el tiempo de escribir una prueba fallida.

Entonces, ¿cuál crees que es la mejor manera de vender TDD a un compañero de equipo vacilante? Las objeciones son usualmente: 'Es un costo innecesario', 'siempre podemos escribir pruebas después del hecho para las partes que son importantes', 'es una palabra de moda, los equipos la recogen y luego cae a un lado cuando comienza la rutina pesada 'etc.

Answer 1

"la mejor manera de vender TDD a un compañero de equipo indeciso"

No se puede. No pierdas el tiempo "vendiendo".

En su lugar, invierta tiempo en "probar".

Solo hazlo. Tener éxito. Cuando las personas pregunten cuál es el secreto de su éxito, revele el TDD. No antes.

Answer 2

simple - mantenibilidad. TDD le brinda la posibilidad de realizar cambios y ver dónde esos cambios afectan el resto del código. Cuanto mayor sea la base del código, más imperativo es que haya pruebas para validar cualquier cambio nuevo.

corrección. Aunque las pruebas se pueden romper, eventualmente llegan a un punto en el que se aseguran de que los componentes están haciendo lo que se supone que deben hacer. Cuanto mejor sea el desarrollador, más rápido será.

Otra ventaja es que TDD informa el diseño de los componentes en el sistema. Si está intentando probar algo, y la prueba es demasiado complicada, probablemente signifique que necesita dividir el problema en partes más pequeñas ...

para venderlo a las personas, usted dice que a la larga lo hace agregar nuevas funciones más baratas y reducir el riesgo de romper la funcionalidad existente. Por lo tanto, reduce el costo.

Answer 3

Creo que Joel's post explica muy bien por qué las pruebas son A Good Thing ™.

No creo que alguna vez use la frase "TDD", pero tiene mucha información.

Answer 4

Para el compañero de equipo vacilante, sea paciente, espere la oportunidad, luego bote. En el desarrollo de software, sin duda, habrá un problema donde TDD hubiera evitado o mitigado el problema. Esté atento a esa oportunidad. Trabaja con él/ella para crear una prueba (s) que debería haber sido desarrollada desde el principio. Sin embargo, asegúrese de elaborar su mensaje de tal manera que no avergüence a su compañero de equipo.

Answer 5

Estoy de acuerdo con S. Lott, no puede "venderlos" para mostrar el valor.

Una de las formas más efectivas de hacerlo es con la programación de pares. De acuerdo, tiene otro problema de "venta" que convence a la gente de que el emparejamiento es un enfoque efectivo, pero después de un tiempo puede convencer/convertir a un desarrollador o también.

TDD era un concepto difícil para mí inicialmente, pero ahora no puedo imaginar la programación de otra manera.

Answer 6

Muéstrales este sitio: WeDoTDD.com - casos reales de uso del equipo de la empresa. Aquellos que están practicando con éxito TDD en compañías reales.