¿Puede ser ágil sin hacer TDD (desarrollo dirigido por pruebas)?

44

¿Es posible llamarse a sí mismo (oa su equipo) "Agile" correctamente si no hace TDD (desarrollo dirigido por pruebas)?

    
pregunta CraigTP 27.11.2010 - 10:31

9 respuestas

50

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

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

Si quisiera ser exigente con realmente , simplemente podría señalar que hay bastantes variaciones de xDD, que sus defensores explicarán en profundidad no TDD - pero esos aún están sustancialmente relacionados con la prueba primero, por lo que sería trampa.

Entonces digamos esto: puede ser ágil sin hacer el desarrollo de "probar primero" (mire la forma en que funciona scrum - en ninguna parte hay información específica sobre cómo escribir el código). Mira un tablero kanban, observa todo tipo de metodologías ágiles.

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

Y, finalmente, es igualmente cierto que puedes hacer la primera prueba sin ser ágil y argumentos sólidos para realizar la primera prueba, independientemente de tu filosofía de desarrollo general.

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

enlace

  

@unclebobmartin: enlace Aunque no es imposible hacerlo   Ágil sin TDD y OOD, es difícil. Sin TDD la iteración   tasa de ...

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

    
respondido por el Murph 27.11.2010 - 11:33
19

"Ser ágil" simplemente significa adherirse a los valores y principios del manifiesto ágil . Nada en ese documento menciona TDD, ni siquiera pruebas de unidad para esa materia.

Entonces, sí, puedes ser ágil sin hacer TDD o pruebas de unidad.

Aunque no lo recomendaría ...

    
respondido por el Martin Wickman 27.11.2010 - 12:05
11

Sí ,

Mira uno de los valores ágiles:

  

Personas e interacciones sobre   procesos y herramientas

Eso debería responder ya. TDD es una cierta metodología, un proceso. De hecho, un proceso que podría ser utilizado en procesos de desarrollo ágil, pero nada más. Creo que tal vez el TDD es de vanguardia ahora cuando es ágil. Pero creo que el concepto de ágil aún podrá durar, incluso si quizás el TDD haya sido reemplazado por otras prácticas.

Lo resumiría como:

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

  • Puede haber formas de ser ágil sin TDD

respondido por el FabianB 30.01.2011 - 11:29
5

Yo digo

No [tipo de]

Si regresa a la fuente original enlace TDD es fundamental para el proceso; las pruebas reemplazan las especificaciones de requisitos y los casos de uso de la cascada, sirven como documentación viviente y ejemplos de funcionamiento, etc. Son indispensables.

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

EDITAR: la interpretación de @ Murph de la pregunta parece ser la preferida. Diablos, incluso lo he votado, 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 me sirve de nada decir "oh, sí, soy ágil" sin implementar las prácticas que aportan 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 por tiempo indefinido.

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

EDIT 2: sí, técnicamente puedes escribir las pruebas después; pero sigo considerando el test-first / TDD como 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-after-pens. Las descripciones de las pruebas son los requisitos . No los dejes hasta más tarde ;-)

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

    
respondido por el Steven A. Lowe 27.11.2010 - 10:41
2

Estrictamente, usted es ágil al adherirse 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 realizar 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 más efectivo hacerlo a la manera TDD.

    
respondido por el Alb 30.01.2011 - 11:39
2

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

Uno de los principios de Agile es que debe ser capaz de responder al cambio. Esto significa que no sabes de antemano lo que tienes que construir. Si estuviera siguiendo un proceso en cascada, sabría con x meses de anticipación exactamente lo que necesita para 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 usted pensaría que era tan). Pero como Agile 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 desarrollado continúen funcionando a medida que se modifica la base del código.

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

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

Pero si estás siguiendo los principios ágiles, no deberías escribir este código, porque no tienes idea de si eso será necesario. La característica que se planeó para la próxima semana puede ser pospuesta repentinamente indefinidamente.

Si sigue correctamente el principio de 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 un código trivial sin realizar pruebas), y si comienza escribiendo la prueba de aceptación, entonces solo implementas exactamente lo que se necesita para entregar las funciones requeridas.

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

  

El software de trabajo es la medida principal del progreso

    
respondido por el Pete 30.01.2011 - 22:12
1

¿Puede ser ágil sin hacer TDD (desarrollo guiado por pruebas)?

Respuesta corta: sí.

Respuesta más larga: 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 correcto de Lean-ness para el proyecto en cuestión. ¿Qué quiero decir con Lean-ness? Y, ¿por qué lo incluyo en esta respuesta?

Lean no significa eliminar todo lo posible de tu método. Como señaló uno de nuestros colegas, no tiene que incluir TDD o Unit Test en sus comportamientos. Sin embargo, en el contexto del proyecto en el que se encuentra, puede o no ser beneficioso.

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

¿Qué sucede cuando se le dice al gerente general de envíos en la cadena de suministro anterior que recibirá una bonificación anual de $ 1 millón por cada año que tenga menos de 10 camiones en la flota? Él inmediatamente cortará la flota a 9 camiones. En este "terrible" escenario, esto aumentará la cantidad de mercancías almacenadas en el almacén (aumentando el costo en ese nodo). Y, "morirá de hambre" en 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 requerimientos. El sistema DEBE cumplir con esas restricciones. Lo suficientemente justo. TDD puede reemplazar el comportamiento de los requisitos de Use Case Drive Development o el comportamiento de los requisitos de User Story Driven Development. Tiene la ventaja de "inclinarse" de combinar las cargas de trabajo de Prueba unitaria y Requisitos. Es un beneficio si se reduce la carga de trabajo general. No lo es, si se aumenta la carga de trabajo de la cadena de suministro general (reparemos la calidad).

Y entonces, usted preguntó: ¿Puede ser ágil sin hacer TDD (desarrollo guiado por pruebas)?

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

Para citar a un autor favorito ... J.R.R. Tolkien

  

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

Entonces, al final, ... depende. Debes responder a la pregunta. El camino que lo llevará más eficientemente a sus objetivos deseados.

A TDD o no a TDD. Esa sigue siendo la cuestión. :-)

PD: También estoy reenviando esta respuesta en otro sitio. <

    
respondido por el M Kevin McHugh 16.03.2012 - 03:26
1

Comparando con la ingeniería de un castillo.

Castillo ágil

Si fueras a diseñar un castillo usando Agile. Escribiría partes que tienen funciones específicas y alentaría al usuario a usar las partes funcionales, ajustando el diseño futuro a las reacciones del usuario. Entonces, construyes la mazmorra, y te comunicas con el guardián de la mazmorra, probarás los cimientos proporcionados por la tierra y la mazmorra. Usted construiría los parapetos y preguntaría a los vigilantes de la noche si es bueno. Usted construiría las paredes y haría que los soldados probaran el valor defensivo. Usted construiría la cocina y haría que los cocineros la revisaran. Y durante este proceso, cada parte hasta la fecha funcionaría además de la estructura actual. Así que cuando terminaste la mazmorra, podrías mover a los prisioneros. Y así sucesivamente. Pero cuando finalmente has terminado el castillo, descubres que los prisioneros escaparon. Ahora debe volver a la mazmorra y descubrir que necesita barras más gruesas, pero las puertas no son lo suficientemente profundas como para sostener las barras y las bisagras no admiten puertas más grandes.

TDD Castle

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

Agile TDD Castle

Si combinas Agile y TDD. Verías si los prisioneros escaparon y luego preguntarle al carcelero qué es lo que se necesita. Él dice que necesitas más células. Irías a agarrar a algunas personas al azar para simular ser prisioneros y ver si escapan. Si no lo hacen, entonces se lo enseñas al carcelero, y él está feliz con eso. Entonces empiezas a construir los parapetos.

Conclusión

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

TDD resuelve el problema de anticipar fallas. Descubrir y corregir las fallas a medida que ocurren en un punto del proceso donde es más fácil de solucionar. Implica probar unidades de código desacopladas estables a partir del diseño general.

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

Notas

  • Tener solo pruebas unitarias no significa que use TDD. TDD significa tener 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 usar para asegurarse de que no invalide las funciones creadas 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 con el compromiso de favorecer a las personas sobre los procesos.
  • Por definición de TDD y Agile. Las 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: falla en 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.
  • Fallas el TDD fallando la prueba de la unidad. Producir código que no produce la característica correctamente.
respondido por el Lee Louviere 11.09.2013 - 20:07
0

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

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

    
respondido por el Jay Godse 19.03.2011 - 18:33

Lea otras preguntas en las etiquetas