¿Es posible llamarse a sí mismo (o su equipo) correctamente "Agile" si no hace TDD (Test-Driven Development)?

Sí, sí, sí, un millón de veces sí.

Agile es una filosofía, TDD es una metodología específica.

Si quisiera ser muy exigente, simplemente podría señalar que hay bastantes variaciones de xDD, que sus defensores explicarán en profundidad no son TDD, pero que todavía están sustancialmente vinculadas con la prueba primero, por lo que sería una trampa.

Entonces, digamos esto: puede ser ágil sin realizar el desarrollo de "probar primero" (mire la forma en que funciona scrum; en ningún lugar hay detalles sobre cómo escribir código). Mire un tablero kanban, mire todo tipo de metodologías ágiles.

¿Quieres pruebas unitarias? Por supuesto que sí, por todo tipo de razones, y bien podría argumentar que no puede ser ágil sin pruebas unitarias (aunque sospecho que puede serlo), pero no tiene que escribirlas primero para ser ágil.

Y, por último, es igualmente cierto que podría hacer Test First sin ser ágil y argumentos sólidos para hacer test primero, independientemente de su filosofía general de desarrollo.

Parece que otros (con un representante más SÓLIDO) tienen una opinión similar ...

http://www.twitter.com/unclebobmartin/status/208621409663070208

@unclebobmartin: http://t.co/huxAP5cS Aunque no es imposible hacer Agile sin TDD y OOD, es difícil. Sin TDD, la tasa de iteración de ...

(El enlace en el tweet es la respuesta completa en LinkedIn)

"Ser ágil" simplemente significa adherirse a los valores y principios del manifiesto ágil . Nada en ese documento menciona TDD, o incluso pruebas unitarias para el caso.

Entonces sí, puede ser ágil sin hacer TDD o pruebas unitarias.

Aunque no lo recomendaría ...

Sí ,

Mira uno de los valores ágiles:

Individuos e interacciones sobre procesos y herramientas

Eso ya debería responderlo. TDD es una determinada metodología, un proceso. De hecho, un proceso que posiblemente podría usarse en procesos de desarrollo ágiles, pero nada más. Creo que quizás TDD es lo último en tecnología ahora cuando es ágil. Pero creo que el concepto de ágil aún podrá durar, incluso si tal vez TDD ha sido reemplazado por otras prácticas.

Lo resumiría como:

• Hoy TDD es un estándar de facto para ser ágil

• Puede haber formas de ser ágil sin TDD

yo digo

No [tipo de]

Si vuelve a la fuente original, http://en.wikipedia.org/wiki/Extreme_Programming TDD es fundamental para el proceso; Las pruebas reemplazan las especificaciones de requisitos y los casos de uso de cascada, sirven como documentación viva y ejemplos de funcionamiento, etc. Son indispensables.

Sin embargo, hay tantos sabores diferentes de 'ágil' flotando ahora que es completamente posible que uno de ellos evite TDD

EDITAR: la interpretación de @ Murph de la pregunta parece ser la preferida. Diablos, incluso lo voté, es una buena respuesta. Sin embargo , mantengo mi posición de que el Manifiesto Ágil es un conjunto de principios, no una metodología de desarrollo. No creo que sea útil decir "oh sí, soy ágil" sin implementar realmente las prácticas que traen los beneficios. En particular:

El software de trabajo es la medida principal del progreso.

y

Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deberían poder mantener un ritmo constante indefinidamente.

Para mí, estos dos principios implican, si no requieren TDD, ¡al menos no conozco otra forma de lograrlos sin él!

EDIT 2: sí, técnicamente puedes escribir las pruebas después; pero todavía considero que test-first / TDD es fundamental. No porque no puedas "ser ágil" sin él, sino porque serás más ágil con él. Test-first / test-driven es un enfoque mucho más eficiente que test-later / test-afterthought. Las descripciones de las pruebas son los requisitos . No los pospongas hasta más tarde ;-)

EDITAR 3: Finalmente descubrí lo que me molesta tanto de la respuesta muy bien escrita de Murph. Es esa noción de que uno podría "ser ágil" sin hacerlo realmente . Y "hacerlo" (como se muestra arriba) prácticamente requiere TDD.

Estrictamente, eres ágil al adherirte al manifiesto ágil . En la práctica, una base de código no es ágil a menos que tenga una buena cobertura de prueba. Puede hacer TDD y escribir las pruebas antes / durante el desarrollo de la funcionalidad o escribir pruebas para la funcionalidad después de que se haya desarrollado. Sin embargo, generalmente es más fácil y efectivo hacerlo de la manera TDD.

Puede ser ágil, pero probablemente haya margen de mejora.

Uno de los principios en ágil es que debe ser capaz de responder al cambio. Esto significa que no sabe de antemano lo que tiene que construir. Si estuviera siguiendo un proceso en cascada, sabría con x meses de anticipación exactamente lo que necesita construir, y podría diseñar componentes de software individuales para que cada uno participe en un esquema más amplio, llegando al producto final (al menos pensaría que era tan). Pero como ágil dicta que no sabes cuál es el producto final, nunca sabes para qué se usará el código y, lo que es más importante, cuándo se cambiará.

Por lo tanto, necesita un conjunto de pruebas exhaustivo para asegurarse de que las características que ya ha creado continúan funcionando a medida que se modifica la base del código.

Pero eso en sí mismo no es TDD. Si escribe las pruebas después de escribir el código, no es TDD. Pero TDD ayuda con otro aspecto, evita la sobreproducción.

En mi propio equipo ágil, he estado luchando con los desarrolladores que escriben código que creen que sería útil más adelante en el proyecto. Si hubiera sido un desarrollo en cascada, probablemente estaría bien, porque estaban agregando soporte para algo en el plan del proyecto para los próximos x meses.

Pero si sigue los principios ágiles, no debe escribir este código, porque no tiene idea de si eso será necesario. La característica que fue planeada para la próxima semana puede ser pospuesta de manera indefinida.

Si sigue correctamente el principio TDD, entonces no puede existir una sola línea de código antes de que una prueba dicte esta línea de código (personalmente puedo escribir algún código trivial sin probar), y si comienza escribiendo la prueba de aceptación, entonces solo implementa exactamente lo que se necesita para ofrecer las funciones requeridas.

Por lo tanto, TDD ayuda a evitar la sobreproducción, permitiendo que el equipo sea lo más efectivo posible, que también es un principio ágil fundamental.

El software de trabajo es la medida principal del progreso.

¿Puedes ser ágil sin hacer TDD (desarrollo impulsado por pruebas)?

Respuesta corta: sí.

Respuesta más larga: ya hay muchas respuestas realmente buenas a esta pregunta y muy buenas referencias. No intentaré debatir esos puntos.

En mi experiencia, Agile se trata de elegir el nivel adecuado de Leanness para el proyecto en cuestión. ¿Qué quiero decir con Lean-ness? Y, ¿por qué lo traigo a esta respuesta?

Lean no significa cortar todo lo posible de su método. Como señaló uno de nuestros colegas, no tiene que incluir TDD o Prueba de unidad en sus comportamientos. Sin embargo, en el contexto del proyecto en el que se encuentre, puede o no ser beneficioso.

Pensemos en la cadena de suministro de un gran minorista sin nombre ubicado en AK. Ahí está el consumidor. Entran en la tienda. La tienda recibe varios productos en camión. Los camiones, presumiblemente, obtienen esos productos de un almacén. El almacén se llena con envíos de varios fabricantes. Los fabricantes a su vez tienen cadenas enteras de suministro.

¿Qué sucede cuando se le dice al gerente general de envíos en la cadena de suministro anterior que recibirá un bono anual de $ 1 millón por cada año que tenga menos de 10 camiones en la flota? Inmediatamente cortará la flota a 9 camiones. En este escenario "horrible", esto aumentará la cantidad de bienes almacenados en el almacén (aumentando el costo en ese nodo). Y "matará de hambre" los frentes de las tiendas.

Por lo tanto, la cadena de suministro general sufre si se permite la optimización local sin tener en cuenta el conjunto.

Volver a TDD y UT. TDD es un mecanismo de expresión de requisitos. El sistema DEBE cumplir con esas restricciones. Lo suficientemente justo. TDD puede reemplazar el comportamiento de requisitos de Desarrollo de casos de uso o el comportamiento de requisitos de Desarrollo guiado por la historia del usuario. Tiene el beneficio "inclinado" de combinar las cargas de trabajo de Prueba unitaria y Requisitos. Es un beneficio si la carga de trabajo general se reduce. No lo es, si aumenta la carga de trabajo de la cadena de suministro general (arreglemos la calidad).

Y entonces, preguntaste: ¿Puedes ser ágil sin hacer TDD (desarrollo impulsado por pruebas)?

Seguro que puede. Una pregunta diferente, y quizás mejor, es: - Si aplico TDD a este proyecto, ¿resultará en una entrega general de software más eficiente o menos eficiente?

Para citar a un autor favorito ... JRR Tolkien

Señor de los Anillos. Comunidad de los Anillos. Pg 94 'Y también se dice', respondió Frodo: 'No vayas a los elfos a pedir consejo, porque ambos no y sí'.

Entonces, al final, ... depende. Debes responder la pregunta. Qué camino lo llevará de manera más eficiente a su (s) objetivo (s) deseado (s).

A TDD o no a TDD. Esa sigue siendo la pregunta. :-)

PD: también estoy volviendo a publicar esta respuesta en otro sitio. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

En comparación con la ingeniería de un castillo.

Castillo ágil

Si fueras a diseñar un castillo usando Agile. Escribiría porciones que tengan funciones específicas y aliente al usuario a usar las partes funcionales, ajustando el diseño futuro a las reacciones del usuario. Entonces, si construyes la mazmorra y te comunicas con el guardián de la mazmorra, probarías los cimientos proporcionados por la tierra y la mazmorra. Construirías los parapetos y preguntarías a los vigilantes nocturnos si es bueno. Construirías las paredes y harías que los soldados probaran el valor defensivo. Construirías la cocina y harías que los cocineros la revisen. Y durante este proceso, cada parte hasta la fecha funcionaría además de la estructura actual. Entonces, cuando termines la mazmorra, podrías mover a los prisioneros. Y así sucesivamente. Pero cuando finalmente has terminado el castillo, descubres que los prisioneros escaparon.

Castillo TDD

Con TDD, apareces con los prisioneros y ves si escapan. Luego escribes las celdas de la cárcel hasta que no puedan escapar. Luego refactorizaría el código limpiamente eliminando celdas innecesarias y eliminando barras que están en la ubicación incorrecta, y volvería a probar. Los prisioneros no escaparon. No tienes que comunicarte con el carcelero. Y podrías entregar todo el castillo una vez que hayas terminado todo. En ese momento, el carcelero dice que la mazmorra necesita más celdas, y ahora tienes que desenterrar más cimientos.

Castillo ágil TDD

Si combina Agile y TDD. Verías si los prisioneros escaparon y luego preguntarías al carcelero qué se necesita. Dice que necesitas más células. Irías a buscar gente al azar para fingir ser prisioneros y ver si escapan. Si no lo hacen, entonces se lo muestras al carcelero, y él está contento con eso. Entonces comienzas a construir los parapetos.

Conclusión

Entonces ambos resuelven diferentes problemas. Agile ayuda a cambiar los requisitos en función de descubrir las necesidades de los usuarios a medida que ven que el producto se desarrolla en el punto del proceso donde es más fácil adaptarse. Implica liberar adiciones estables desglosadas del diseño general.

TDD resuelve el problema de anticipar el fracaso. Descubrir y corregir la falla tal como ocurre en un punto del proceso donde es más fácil de solucionar. Implica probar unidades de código desacopladas estables desglosadas del diseño general.

Es fácil ver TDD como una extensión de Agile, porque ambos siguen el mismo patrón, progreso y revisión impulsados ​​por la unidad. La diferencia es que las unidades en Agile funcionan externamente en su conjunto, mientras que las unidades en TDD funcionan como una parte y pueden no producir un producto funcional para revisión externa. Y ambos procesos gobiernan diferentes necesidades (usabilidad versus corrección). Dado que ambos funcionan sobre un proceso de desarrollo en unidades, ambos procesos de revisión pueden ocurrir en puntos similares, con TDD dividido más finamente.

Notas

• Tener pruebas unitarias solas no significa que use TDD. TDD significa hacerse la prueba antes de la unidad producida y usar la prueba a medida que se desarrolla para confirmar la unidad. Las pruebas unitarias sin TDD se pueden utilizar para asegurarse de que no invalide la funcionalidad creada anteriormente.
• Tener sprints y otras reuniones no te hace ágil. Los objetivos del manifiesto te hacen ágil. Puede dividir los objetivos de cascada en sprints con unidades de trabajo, sin cumplir el compromiso de favorecer a las personas sobre los procesos.
• Por definición de TDD y Agile. Sus pruebas unitarias regirán las unidades no entregables, por lo que TDD realizará un ciclo más rápido que Agile. Y si emplea ambos, sus ciclos Agile contendrán uno o más ciclos TDD (si se prueba cada unidad).
• Por lo que entiendo: usted falla Agile al no desarrollar una unidad entregable / significativa para el usuario. La unidad puede ser significativa incluso si acelera el producto. Pero, ¿cómo explica Agile la refactorización para facilitar el mantenimiento? No lo he cubierto lo suficiente como para responder eso.
• Usted falla TDD al fallar la prueba de la unidad. Producir código que no produce la función correctamente.

Agile lo obliga a abordar y mitigar los riesgos de programación y calidad en cada iteración. es decir, no se necesita TDD para ser considerado Ágil .

Sin embargo, TDD es una técnica tremenda para mitigar riesgos de calidad, especialmente para un proyecto con un gran número de iteraciones o personas. En dicho proyecto, TDD agregará cierto riesgo de programación en las primeras iteraciones, porque también debe escribir casos de prueba. Sin embargo, TDD produce grandes ahorros de costos en iteraciones posteriores porque mitiga continuamente los riesgos de calidad. es decir, se recomienda TDD.