No puedo entender un cierto punto en los Principios del Manifiesto Ágil

24

Estaba leyendo los Principios del Manifiesto Ágil . Todo parece claro y razonable, excepto por un punto:

La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.

No entiendo esto ¿Significa esto que el trabajo que no se hizo debe ser exagerado de alguna manera? Si es así, realmente no tiene sentido.

agile management superM
fuente
2
+1 para contrarrestar el voto negativo: tiene una pregunta sorprendentemente interesante aquí.
1
También vea Wu Wei e imagine cómo se puede aplicar al desarrollo de software en general. Es la progresión natural de la filosofía expresada en su pregunta.

Respuestas:

30

Eliminar el comentario entre paréntesis. Lo que queda es "La simplicidad es esencial", que por cierto es una aplicación del principio a su propia expresión.

La simplicidad es esencial, porque ha destilado lo que realmente necesita, eliminando lo que hace que la tarea sea más pesada, menos elegante: compleja.

Siempre he interpretado en el sentido de la brevedad de Pascal : " Hubiera escrito una carta más corta, pero no tenía tiempo " . Debe evitar lo que no es necesario (de la carta, del código) y esto es una tarea activa y no fácil. No es algo que sucede por sí solo.

Francesco
fuente
35

La idea es evitar hacer un trabajo que no es necesario, es decir, "maximizar la cantidad de trabajo no realizado".

Por lo tanto, si en un proyecto tradicional planearía y crearía un excelente sistema de base abstracta para satisfacer todas sus posibles necesidades más adelante, simplemente omita eso y cree lo más simple que pueda funcionar para los requisitos actuales . No construyas cosas que no necesitas.

YAGNI es un concepto relacionado.

Joachim Sauer
fuente
55
Casualmente, este es probablemente el principio ágil con el que estoy menos de acuerdo . Llevado al extremo, la previsión abstracta es lo que nos separa de otros animales ... Digo que necesitamos usarlo siempre que podamos. Por supuesto, sé a qué tipo de atrocidades debe responder el principio, pero un poco de previsión no va a doler. A veces es YAGNI, pero he visto a algunos desarrolladores tan dogmáticos que no se detendrán a pensar siquiera unas horas antes (y me doy cuenta de que la simplicidad que están implementando ahora ni siquiera será suficiente en 4-8 horas).
Max
2
@Max, creo que es necesario prever futuros cambios posibles. Aquí es donde la previsión es de gran ayuda. Y los desarrolladores que describe son más como avestruces, que se esconden en la arena.
superM
77
Los clientes de @Max no quieren pagar lo que crees que podrían necesitar en el futuro, quieren pagar lo que necesitan en este momento lo antes posible . Hay miles de millones de dólares de esfuerzo desperdiciado cada mes en buenas intenciones de "esto ahorrará mucho tiempo más tarde" y ese "más tarde" en realidad nunca llega, pero las cosas son complejas, con errores y tarde debido a toda esa "previsión"
15
@Max: YAGNI se trata de retrasar las decisiones hasta el último momento responsable . De lo que estás hablando es de retrasar la decisión hasta el último momento posible , lo que de hecho es una Bad Idea ™. La cuestión es: nunca tendrá menos información para basar una decisión de la que tiene en este momento. En el peor de los casos, tendrá la misma información mañana. Pero por lo general, habrás aprendido algo para entonces. En el caso que usted ha mencionado, usted sabe que es lo que va a necesitar, por lo YAGNI simplemente no se aplica. Intentar aplicarlo es realmente estúpido en ese caso.
Jörg W Mittag
2
@Max: Lo que está describiendo aquí es exactamente lo contrario de maximizar la cantidad de trabajo no realizado. Está haciendo el doble de trabajo.
pdr
5

Solíamos llamar a esto "chapado en oro". El requisito para un martillo es que pueda golpear un clavo en un pedazo de madera. No hace el trabajo mejor por ser un martillo chapado en oro.

Muchas veces, un desarrollador sugeriría usar un nuevo marco genial o agregar características que, aunque geniales, no eran necesarias. Anotaríamos esta idea, pero para esta versión no lo haremos. Maximizaremos el trabajo no realizado. Es bastante difícil entregar el software a tiempo, así que no entregue más código del que necesita. Si es necesario hacerlo, eventualmente entrará en el plan y se hará en el momento apropiado.

Stuart Woodward
fuente
4

Esta idea es muy similar a un concepto del Sistema de producción de Toyota (TPS) , que condujo a Lean Manufacturing más genérico y luego a la aplicación de esas técnicas al desarrollo de software Lean . El TPS es significativamente anterior al movimiento ágil, con sus raíces en la fabricación a fines de la década de 1950.

El concepto de maximizar la cantidad de trabajo no realizado es similar a eliminar el desperdicio. En el entorno de fabricación, los desechos incluyen cosas como la sobreproducción de bienes, la espera de recursos, el movimiento innecesario de personas o productos, demasiado inventario y productos defectuosos. En Lean Software Development, estos desechos se tradujeron en funcionalidades innecesarias, retrasos en el proceso de desarrollo, requisitos poco claros que ralentizan la producción de software, falta de pruebas y retrasos en la comunicación.

La idea general de ambos conceptos es la misma: las cosas que no agregan valor son un desperdicio y deben minimizarse. El objetivo final es aumentar la calidad y reducir el tiempo y el costo de producción.

Thomas Owens
fuente