Cómo convencer a mi equipo para que comience a usar TDD

1. Conviértete en el líder y gerente del equipo. Eso generalmente requiere unirse temprano, crecer en la empresa con más empleados o quedarse cuando sus compañeros de trabajo renuncien.
2. Escribe un documento de proceso. El que escribí para mi equipo actual dice lo que hacemos, por qué lo hacemos y hace referencia a boletos específicos que demuestran la justificación. Cuando tuvimos problemas para no seguir el proceso, cito un error ilustrativo. En el mundo real hay excepciones, así que proporciono un procedimiento para eso y enlace a algunos en la base de datos de errores. Son siete viñetas fáciles de digerir que se pueden usar como una lista de verificación.
3. Dirija con el ejemplo siguiendo el documento y estableciendo alguna infraestructura.
4. Pídales a los miembros de su equipo que comiencen a hacer lo mismo, que aprovechen su infraestructura de prueba y que comiencen con algo simple y autónomo. Escriba un caso de prueba para su próximo entregable para que comiencen, demostrando que se requiere aproximadamente el mismo esfuerzo que probar una vez un candidato de lanzamiento manualmente.
5. En el caso improbable de que un miembro del equipo que objeta no sucumba a la presión de grupo, resalte los problemas que están surgiendo (las regresiones y los rechazos de control de calidad son casi inevitables). Facilítelo con unos pocos entregables o ciclos de lanzamiento que progresen de una sugerencia suave, a una sugerencia fuerte, a un requisito de trabajo.
6. En el caso menos probable de que un miembro del equipo no obtuviera el programa en el paso 5, póngalo en un Plan de mejora del rendimiento en el que el criterio de éxito esté utilizando Test Driven Development para cada entregable en la próxima versión, excepto cuando apruebe una desviación como no caso de prueba para un error que no se puede reproducir. Haga que la carga de trabajo sea liviana y alcanzable (usé un tercio de lo que pensé que el empleado podría hacer en mi último PIP) porque su objetivo es ayudar a ese empleado a tener éxito, no crear un rastro de papel que justifique una decisión que ya tomó para despedir. Arreglar problemas con un empleado existente cuesta menos tiempo y dinero que contratar a uno nuevo.
7. Despida a cualquier empleado que no haya completado con éxito su PIP y contrate a un reemplazo que sea un mejor jugador de equipo. Sea claro desde el principio sobre el proceso de su equipo para que no contrate a nadie que sea infeliz y necesite volver a intentarlo.

De lo contrario no los convencerás. Saben por experiencia que el proceso del software agrega trabajo, con una pérdida de tiempo completa. No tienen experiencia personal con TDD para mejorar sus vidas. Se han sentido cómodos con el status quo durante años. Están más motivados para hacer su trabajo en sus términos que por otras cosas como el éxito de la empresa, que está fuera de su control.

Si bien es posible que tenga influencia más adelante en la cadena de administración, no obtendrá cambios porque los gerentes deben dar autonomía a sus empleados superiores siempre y cuando cumplan con sus compromisos cuando estén lo suficientemente relajados como para adaptarse al proceso actual. Los hitos a menudo son cosas como “código completo”, dejando mucho espacio para problemas con las soluciones por separado.

Puede adquirir una parte cada vez más importante del producto porque TDD lo hace más productivo que otros ingenieros. Puede pasar de una organización en la que el vicepresidente de ingeniería abandonó las fechas de lanzamiento programadas porque no podían cumplirse con una calidad aceptable para enviar generalmente el primer candidato de lanzamiento y el mismo o al día siguiente cuando QA encuentra un error o dos. Puede seguir acumulando 170 funciones durante años con la misma predictibilidad de lanzamiento relajante. Puede hacer milagros como los comunicados dominicales de un día por problemas críticos con los clientes. Si bien sus ejecutivos apreciarán los resultados, no será suficiente que las personas que no le reportan hagan TDD o incluso escriban pruebas automatizadas.

“Creo que TDD es genial” ¿por qué? ¿Por qué crees que TDD es genial? ¿Tiene experiencia práctica donde TDD le sirvió bien? ¿Cuándo crees que TDD te fallará?

Antes de poder convencer a alguien, debe creer firmemente en TDD y debe tener una muy buena razón para TDD. Debe comprender la debilidad y la fuerza de TDD y convencer a la gente de por qué cree que la fuerza de TDD supera su debilidad.

No esperes que puedas convertir mágicamente a los no creyentes en creyentes en poco tiempo. Si crees en algo, sigue predicando. Pero, asegúrese de comprender la filosofía detrás de TDD.

Básicamente, convencer a alguien sobre TDD es como tratar de convencer a los budistas del cristianismo o viceversa. Es difícil, puede parecer imposible, pero si puedes convencer a algunos es un paso adelante. No puedes esperar convertir a todos.

La forma en que convenzo a las personas acerca de la TDD es practicar primero la TDD con firmeza y explicarles a las personas, cuando ocurre una falla, por qué la TDD habría evitado la falla.

Por cierto, eche un vistazo al blog Clean Coder y aprenda del tío Bob sobre cómo defender TDD contra los no creyentes.

La única forma de hacer que su equipo llegue a TDD es hacerlo, liderando con el ejemplo.

TDD hace que las personas se sientan poco naturales al principio. Entonces, a menos que amenaces con despedirlos, casi nadie quiere hacerlo.

Comencé a usar TDD en mis trabajos hace muchos años, y al principio, me desaceleró considerablemente. Pero después de un tiempo, me permitió escribir código mucho mejor, más rápido y más modularizado. Sin embargo, cada vez que me subo a un nuevo proyecto o un nuevo equipo, tengo que liderar con el ejemplo por un tiempo antes de que las personas reconozcan los beneficios de TDD. Entonces, aun así, pocos de ellos me siguen :))) Y no puedo despedirlos a todos, porque si lo hubiera hecho, no habría conseguido que nadie trabajara para mí.

Entonces realmente no puedes imponer nada. Puede liderar con su propio ejemplo en el mejor de los casos. Algunos te seguirán, otros no. Pero puede solicitar coberturas de prueba al final. Es obligatorio. Es posible que las personas no escriban la prueba primero, pero al final, deben tener pruebas.

Demuestre con el ejemplo. Los méritos de TDD se demuestran fácilmente en un ciclo de vida completo del proyecto. Por eso es difícil convencerlos. La única forma es hacer un proyecto usando TDD con el objetivo de distinguir sus méritos frente a un enfoque que no sea TDD.

Convenza a su equipo para que le permita trabajar en su próximo proyecto / función / módulo utilizando TDD. Eso no debería ser demasiado difícil ya que vas a hacer el trabajo, no los afecta directamente. Se bueno en eso. Luego, cuando llegue a escribir el código del producto, tome nota de todos los errores / problemas que encontró cuando ejecutó las pruebas. Además, documente los pasos del desarrollo del producto (cómo se vio obligado a planificar antes de llegar al código y cómo escribir las pruebas por adelantado le permitió encontrar escenarios que no pensó de primera mano). Luego déles una bolsa marrón de 1 hora sobre sus hallazgos. Acepte comentarios, mejore su flujo de trabajo, documente e invite a otros a comenzar a seguirlo.

En su libro de ingeniería efectiva, Edmond Lau habla de un equipo que nunca escribió una prueba unitaria. Sin embargo, cada vez que combinan el código, faltan algunos archivos / imágenes en el código de combinación. Finalmente, un miembro del equipo escribió algún tipo de prueba que descubre archivos / imágenes faltantes; y se rompe para hacer una construcción. Esta pequeña inversión de prueba ahorró mucho tiempo al equipo. El equipo comprende la importancia de las pruebas. Después de eso adoptaron TDD.

Según Roy Osherove para dominar TDD, uno tiene que aprender a escribir una buena prueba de unidad, primero escribirlas y diseñarlas bien. Estas son tres habilidades diferentes que uno necesita aprender.

Debería dedicar un tiempo por su cuenta para aprender estas habilidades (si no está familiarizado con él) y luego comenzar a hacerlo en su proyecto o su código y, una vez al mes, mostrarle a su equipo cómo ahorró tiempo o más confianza en su código .

Obtenga el permiso de su equipo / líder y gerente para usar TDD para su trabajo. Una vez que tenga un buen ejemplo, muéstreselo.

Si no hay esperanza, simplemente aprenda TDD de forma paralela y hágalo bien en su proyecto favorito. Que encontrar una empresa que hace TDD y unirse a ellos.

Creo que el problema generalmente proviene de:

• Cambios drásticos en el producto y que solo está en la versión 1.0 y no es una buena compensación escribir pruebas para cosas que pueden cambiar demasiado y demasiado rápido.
• Su equipo de negocios no lo entiende. Debe presentar un caso significativo al propietario de su producto en el que TDD paga horas extras (menos duplicación, mejor estructura de código, capturas tempranas de errores). Una vez que lo entiendan, incluirán las Pruebas en sus Criterios de aceptación (o posiblemente digan que estoy contento con la situación actual, que es básicamente el final de su viaje TDD) y luego la mayoría de los desarrolladores escriben pruebas para terminar su historia / tarea. Básicamente estoy diciendo pasar el convincente nivel superior, dejar que lo resuelvan y lo implementen. De lo contrario, incluso si el equipo está de acuerdo con eso, pero no el tiempo aprobado por el propietario de su producto, entonces estaría haciendo cosas fuera de alcance.
  Después de que todos están a bordo, se convierte en una curva de aprendizaje.

Todos hemos estado en tus zapatos

He tenido exactamente el mismo escenario hace unos 5 años. Escenarios posteriores a partir de entonces y finalmente aprendí que no puedes .

Respuesta corta: no puedes forzarlo y no prediques en exceso . La predicación excesiva dará como resultado que te desconecten de inmediato y si sigues predicando mientras tu equipo claramente no quiere escucharlo, literalmente puede hacerte despedir. La política y la gente juegan con eso, así que ten cuidado. No les envíe múltiples correos electrónicos con enlaces ni hable sobre ello. Eso es parte de “dejar de predicar al respecto”.

Tanto yo como muchos TDDists hemos cometido ese error desde el principio … no podemos evitarlo porque sabemos lo bien que funciona. Ya no lo predico, además de tener un sitio que enumera no solo quién está practicando TDD sino también detalles en profundidad sobre cómo no se puede inventar, ha servido como mi voz ahora. Deje que las personas tomen la decisión y sepan que las cosas mejorarán (lentamente), puede llevar años, pero el TDD definitivamente está creciendo.

Lo que puede hacer por ahora es plantar una semilla y decir hola, eche un vistazo a este sitio web genial : WeDoTDD.com … siga adelante. Eso es en parte por lo que creé el sitio, para ayudarme a usted y a usted a difundir la adopción de TDD. Me cansé de los estúpidos argumentos mal informados que tenía que entablar sobre TDD con personas que simplemente no querían probarlo y harían cualquier cosa en su poder para derrotarlo. Discutir al respecto fue una pérdida de tiempo total. Ahora las personas pueden hacer su propio juicio basado en datos reales y también aprender sobre ello en mi sitio.

Además, si le pasa mi sitio a alguien y quiere discutir TDD, no lo haga. Simplemente diga “Oye, es genial que tengas tu opinión, tienes derecho a ella, y vamos a dejarla allí y seguir adelante”. Deje que el sitio y otros sean la luz, para que no tenga que hacerlo. Plantar una semilla en un equipo que “odia TDD” debería hacerte sentir mejor … y seguir adelante.

Otros han mencionado ” Por ejemplo “. He oído hablar de una historia exitosa de esto, pero es algo por lo que debes tener mucha paciencia. El primer paso es encontrar un lugar que le permita probar, y mucho menos tratar de convencer. Todavía hay demasiados lugares que no se prueban y, lo que es peor, te dicen que no lo hagas. Incluso podría ser despedido si lo hace en muchos lugares. Eso es simplemente ridículo, esta es una profesión y se nos dice que no escribamos exámenes. ¿Tiene algún sentido eso? No.

Conclusión

Comparte ese enlace y déjalo así.

No sigas hablando de eso en el trabajo con un equipo que encuentre alguna forma de contrarrestarlo … es una pérdida de tiempo. Sé que es frustrante, pero debes encontrar una manera de hacer tu TDD, y entender que simplemente no lo harán y estar de acuerdo con eso … con la advertencia de que siempre y cuando estén de acuerdo contigo al menos haciendo tu TDD, entonces todo está bien . Me tomó un tiempo llegar a un punto (cambiarme) en el que me sentía así, era apasionado y terco :). Pero te servirá mejor a ti y a la profesión si tomas esa ruta … y posiblemente salves tu trabajo hasta que puedas encontrar un mejor equipo para trabajar.

Si tiene paciencia, quédese e intente influir en sus pruebas y tenga 2–3 años de paciencia para ver si el equipo puede ser influenciado lentamente para cambiar, con la esperanza de que si escribe un montón y la gente comience a notar … ¡adelante! Pero eso es como realmente ganar un boleto de lotería IMO. ¡Buena suerte con eso! Quiero decir, a menos que sea una empresa de consultoría que ingrese TDD y comiencen a ayudar a cambiar la cultura al emparejarse con los desarrolladores de su equipo, entonces tendrá una gran montaña para escalar.

Supongo que debe preguntarse “¿Por qué es bueno TDD?”.

Si no puede encontrar la respuesta usted mismo, ¿por qué podría convencer a alguien más?

Me pregunto si te estás acercando a esto desde un punto de vista de “TDD es bueno, ahora pensemos en los motivos”, en lugar de “¿Qué queremos lograr? ¿TDD encaja bien? ”.

Me parece que ya has decidido que TDD es una buena idea, y ahora necesitas probarlo. Piensa en el problema que quieres resolver, y si TDD es la solución, genial, pero también considera que puede no serlo.

La clave es resistir el impulso de probar todo el día 1.

Aquí hay una gran guía sobre el desarrollo impulsado por pruebas: qué probar (y qué no probar)