Kann einen bestimmten Punkt in Agile Manifesto Principles nicht verstehen

24

Ich habe Agile Manifesto Principles gelesen . Alles scheint klar und vernünftig, bis auf einen Punkt:

Einfachheit - die Kunst, den Umfang der nicht geleisteten Arbeit zu maximieren - ist von entscheidender Bedeutung.

Ich verstehe das nicht. Bedeutet das, dass die Arbeit, die nicht geleistet wurde, irgendwie übertrieben sein sollte? Wenn ja, macht es nicht wirklich Sinn.

agile management

— superM
quelle

2

+1 gegen die Abwärtsabstimmung - Sie haben hier eine überraschend interessante Frage.

1

Sehen Sie sich auch Wu Wei an und stellen Sie sich vor, wie es für die Softwareentwicklung im Allgemeinen angewendet werden kann. Es ist das natürliche Fortschreiten der Philosophie, die in Ihrer Frage zum Ausdruck kommt.

30

Entfernen Sie den Kommentar in Klammern. Was bleibt, ist "Einfachheit ist wesentlich", was übrigens eine Anwendung des Prinzips auf seinen Ausdruck selbst ist.

Einfachheit ist entscheidend, denn Sie haben das destilliert, was Sie wirklich brauchen, und das entfernt, was die anstehende Aufgabe schwerer und weniger elegant macht: komplex.

Ich habe immer im Sinne von Pascals Kürze gedeutet : " Ich hätte einen kürzeren Brief geschrieben, aber ich hatte keine Zeit. " Man muss vermeiden, was überflüssig ist (aus dem Brief, aus dem Code) und das ist Eine aktive und keine leichte Aufgabe . Es ist nicht etwas, was von selbst passiert.

— Francesco
quelle

35

Die Idee ist es, zu vermeiden, dass Arbeiten ausgeführt werden, die nicht erforderlich sind, dh "die Menge der nicht ausgeführten Arbeiten zu maximieren ".

Wenn Sie also in einem traditionellen Projekt ein hervorragendes abstraktes Basissystem planen und erstellen würden, um später alle Ihre möglichen Anforderungen zu erfüllen, überspringen Sie dies und erstellen Sie das einfachste, was für die aktuellen Anforderungen möglich ist. Bauen Sie keine Sachen, die Sie nicht brauchen.

YAGNI ist ein verwandtes Konzept.

— Joachim Sauer
quelle

5

Zufälligerweise ist dies wahrscheinlich das agile Prinzip, dem ich am wenigsten zustimme . Eine extreme, abstrakte Voraussicht unterscheidet uns von anderen Tieren ... Ich sage, wir müssen sie verwenden, wann immer wir können. Natürlich weiß ich , was für Grausamkeiten des Prinzip eine Reaktion auf sein muss - aber ein wenig wenig Voraussicht wird nicht weh tun. Manchmal ist es YAGNI, aber ich habe einige Entwickler gesehen, die so dogmatisch sind, dass sie nicht aufhören werden, ein paar Stunden vorauszudenken (und erkennen, dass die Einfachheit, die sie jetzt implementieren, nicht einmal in 4-8 Stunden ausreichen wird).

— Max

2

@Max, ich denke, es ist notwendig, zukünftige mögliche Änderungen vorherzusehen. Hier ist Voraussicht eine große Hilfe. Und die Entwickler, die Sie beschreiben, sind eher Strauße, die sich im Sand verstecken.

— SuperM

7

@Max Kunden wollen nicht Lohn für das, was Sie denken , sie könnten in der Zukunft brauchen, wollen sie Lohn für das, was sie jetzt brauchen , wie so bald wie möglich . Es gibt jeden Monat Milliarden von Dollar an verschwendeter Mühe in guten Absichten, "das spart so viel Zeit später" und "später" kommt eigentlich nie, aber die Dinge sind komplex, fehlerhaft und spät wegen all dieser "Voraussicht"

15

@Max: Bei YAGNI geht es darum, Entscheidungen auf den letzten verantwortlichen Moment zu verschieben. Sie sprechen von einer Verzögerung der Entscheidung bis zum letzten möglichen Moment, was in der Tat eine schlechte Idee ist. Die Sache ist: Sie werden nie weniger Informationen haben, auf die Sie eine Entscheidung stützen können, als jetzt. Im schlimmsten Fall haben Sie morgen die gleichen Informationen. Aber in der Regel haben Sie dann schon etwas gelernt. In dem Fall, in dem Sie es erwähnt haben, wissen Sie, dass Sie es brauchen werden, also trifft YAGNI einfach nicht zu. Zu versuchen, es anzuwenden, ist in diesem Fall in der Tat dumm.

— Jörg W Mittag

2

@Max: Was Sie hier beschreiben, ist das genaue Gegenteil von der Maximierung des nicht geleisteten Arbeitsaufwands. Es macht doppelt so viel Arbeit.

— pdr

5

Früher haben wir das "Vergolden" genannt. Voraussetzung für einen Hammer ist, dass er einen Nagel in ein Stück Holz schlagen kann. Es macht den Job nicht besser, ein vergoldeter Hammer zu sein.

Oft schlug ein Entwickler vor, ein neues cooles Framework zu verwenden oder Features hinzuzufügen, die zwar cool waren, aber nicht notwendig waren. Wir würden diese Idee notieren, aber für diese Version werden wir es nicht tun. Wir werden die nicht geleistete Arbeit maximieren. Es ist schwierig genug, Software rechtzeitig bereitzustellen. Geben Sie also nicht mehr Code aus, als Sie benötigen. Wenn es erledigt werden muss, wird es irgendwann in den Plan aufgenommen und zum richtigen Zeitpunkt erledigt.

— Stuart Woodward
quelle

4

Diese Idee ist einem Konzept aus dem Toyota Production System (TPS) sehr ähnlich, das zu einer allgemeineren Lean-Fertigung und dann zur Anwendung dieser Techniken auf die Lean-Software-Entwicklung führte . Die TPS ist deutlich älter als die agile Bewegung, deren Wurzeln in der Fertigung Ende der 1950er Jahre liegen.

Das Konzept der Maximierung des nicht geleisteten Arbeitsaufwands ähnelt der Abfallbeseitigung. In der Fertigungsumgebung gehören zu Abfällen Dinge wie Überproduktion von Waren, Warten auf Ressourcen, unnötige Bewegung von Personen oder Produkten, zu viel Inventar und fehlerhafte Produkte. In der Lean-Software-Entwicklung wurden diese Abfälle in unnötige Funktionen, Verzögerungen im Entwicklungsprozess, unklare Anforderungen, die die Produktion von Software verlangsamen, fehlende Tests und Kommunikationsverzögerungen umgesetzt.

Die Gesamtidee beider Konzepte ist die gleiche - Dinge, die keinen Mehrwert bringen, sind verschwenderisch und sollten minimiert werden. Das ultimative Ziel ist es, die Qualität zu steigern und gleichzeitig Zeit und Kosten für die Produktion zu reduzieren.

— Thomas Owens
quelle