Agile Methodik: schnell und schmutzig oder zuerst planen?

Agile Frage: Glaubt Agile daran, die Dinge „schnell und schmutzig“ zum Laufen zu bringen - oder zieht es Agile vor, von Grund auf solide zu bauen? Oder ist dies keine methodische Frage, sondern eher eine Frage, die Sie von Fall zu Fall bewerten?

Ich mache das Fundament des Systems technisch „neu“, nachdem ich bereits einen Großteil der Struktur selbst gebaut habe ... es ist keine enorme Menge an Arbeit ... hätte Agile gewollt, dass ich zuerst den gesamten Fluss spezifiziere, ihn analysiere, optimieren und dann bauen? Ich habe das Gefühl, dass es auf diese Weise besser ist ... Sobald ich ein chaotisches System aufgebaut habe, sehe ich besser, wie es gemacht werden muss ... andererseits ist es nicht so organisiert ... nur neugierig, welche Entwicklung am besten ist Praxis ist in dieser Hinsicht.

Ich glaube, diese Frage ist etwas anders als Agile und Protyping, da ich nicht nach Prototyping und Wegwerfcode frage . Ich interessiere mich für Agile für Code in Produktionsqualität.

Die agile Methodik ist zuerst geplant. Es ist einfach nicht alles zuerst zu planen. Tatsächlich erfassen Sie Anforderungen, entwerfen, codieren, testen, implementieren und präsentieren sie. Sie erledigen das alles in weniger als vierzehn Tagen (Geben oder Nehmen) mit der kleinsten kleinen Funktion, die Sie bereitstellen und über die Sie Feedback erhalten können. Dann machen Sie alles noch einmal und fügen eine weitere Funktion hinzu oder optimieren eine alte.

Der Schlüssel besteht darin, Code zu schreiben, der Änderungen akzeptiert, damit Sie den Code ändern können, wenn Sie endlich sehen, wie der gesamte Ablauf ablaufen soll. Auf diese Weise ist es nicht traumatisch, wenn sich "der Weg, in dem der Fluss verlaufen soll" (oder was auch immer) erneut ändert.

Sie können nicht schnell und schmutzig schreiben. Schnell und schmutzig gibt Ihnen Ridgid-Code. Sei schnell, indem du klein arbeitest. Bleiben Sie flexibel, indem Sie kein Wissen verbreiten . Im Idealfall sollte sich jede einzelne Funktionsänderung nur auf eine Stelle im Code auswirken.

Sie können nicht viel Zeit damit verbringen, nichts anderes zu tun als zu planen. Sie können planen, aber Sie müssen in der Lage sein, den Plan zu ändern. Sie müssen schnell Gründe finden, um den Plan zu ändern. Wenn die Planung reibungslos verläuft und keine Überraschungen zu erwarten sind, wurde die Planung zu lange fortgesetzt. Die Planung und die Kodierung müssen nahe beieinander erfolgen. Wenn Sie lernen, ist der Plan umso dümmer, je älter er ist.

Langfristig sollten Sie planen, klüger zu werden. Schreiben Sie flexiblen Code. Dann führt es nicht zu Bedauern, schlauer zu werden.

Ich mag es nicht, dass es für die meisten Leute entweder "schnell und schmutzig" oder "großes Design vorne" ist. Sie denken nicht einmal daran, dass es andere Möglichkeiten gibt.

Bei Agile geht es darum, ein System aufzubauen, bei dem Veränderungen auch spät in der Entwicklung trivial sind. Dies erfolgt durch Erstellen der Software in kleinen, inkrementellen Blöcken und Sperren des Verhaltens dieser Blöcke mit robusten automatisierten Tests. Verwenden Sie die häufige, automatisierte Bereitstellung in der Produktion, um den Wert dieser Änderungen zu überprüfen.

Durch robuste automatisierte Tests wird es trivial, selbst die schwierigsten Teile der Architektur durch inkrementelles Refactoring über längere Zeiträume zu ändern. Selbst wenn Sie erkennen, dass Ihre Architektur in der Mitte des Projekts besser umgesetzt werden kann, ist es realistisch möglich, die Änderung relativ schnell vorzunehmen.

Einige Leute sagen, dass "einige Design vorne" gut mit Agilität ist. Wenn Sie dieses Design jedoch später wiederholen möchten, müssen Sie dennoch sicherstellen, dass Ihre Entwicklungskultur ein System hervorbringt, das leicht zu ändern ist. "SDUF" macht also keine robusten Tests, aggressives Refactoring und kontinuierliche Bereitstellung ungültig.

Wenn Sie "Easy of Change" in das System einbauen, müssen Sie nicht lange über das ursprüngliche Design Ihres Projekts nachdenken, da dies später geändert werden kann. Der "Quick and Dirty" -Ansatz, den die meisten Leute als "Spike" bezeichnen, kann nur verwendet werden, wenn Sie die Funktionen stabilisieren, die Sie für wertvoll halten. Sie sollten jedoch nicht zu lange Teile des gehackten Codes in Ihrer Codebasis belassen, da diese den Wandel verlangsamen.

Weder.

Es ist "Einfach anfangen und verbessern, während Sie sich fortbewegen".

Schnell und schmutzig ist spröde, aber schnell (wenn das Projekt ausreichend klein und kurzlebig ist).

Der erste Plan ist starr, aber stabil (wenn das Projekt abgeschlossen ist, bevor es finanzielle oder zeitliche Einschränkungen aufweist).

Agile ist eine Alternative zu den beiden oben genannten. Es basiert auf einem iterativen Ansatz, bei dem Features einzeln nacheinander abgeschlossen werden und das Wissen, das beim Ausfüllen dieser voll funktionsfähigen Teile des Programms gewonnen wurde, verwendet wird, um den Plan im Verlauf der Entwicklung zu konkretisieren und anzupassen. Um dies zu erreichen, ist eine gewisse Vorausplanung erforderlich - Sie benötigen mindestens genügend Planung, um abschätzen zu können, wie viel Arbeit die einzelnen Funktionen erfordern. Da Agile jedoch Änderungen erwartet, führt eine übermäßige Planung zu Verschwendung.

Eines der Hauptmerkmale von Agile besteht darin, kurze Iterationen durchzuführen und anschließend neu zu bewerten. Sie rennen voraus, um Neuland zu erkunden, daraus zu lernen und dann einen Plan zu erstellen. Auf diese Weise wird Ihr Plan besser. Und wenn Sie scheitern (finden Sie, dass Ihre Kursidee nicht funktioniert), haben Sie "schnell gescheitert", was gut ist.

Ihr Ansatz ist also in Ordnung. Die Gefahr besteht dann jedoch darin zu sagen: "Schön, es funktioniert, ich bin fertig. Was kommt als nächstes?". Sie sind noch nicht fertig, es gibt viele abgeschnittene Ecken, die Sie begradigen müssen, und Sie sollten sich die Zeit nehmen, um es richtig zu machen, sobald klar ist, dass Ihr Ansatz ein funktionierendes und funktionsfähiges System ergibt. Das kann sein, Tests zu schreiben, zu dokumentieren, StyleCop zu erstellen, zu optimieren, Kollegen darüber aufzuklären, was Sie getan haben und wie Sie es getan haben, es überprüfen zu lassen usw.

Um die obigen Antworten zu ergänzen, ist YAGNI ein Schlüsselprinzip . Wenn Ihr Design und Ihre Planung im Voraus den nächsten Schritt ermöglichen, ist das in Ordnung. Wenn es jedoch einen hypothetischen zukünftigen Schritt ermöglicht, den Sie nicht nachweisen können, nehmen Sie YAGNI an.

Bei vielen Designs, sowohl von oben nach unten als auch von unten nach oben, wird davon ausgegangen, dass der Code erheblich wiederverwendet wird. Die Erfahrung zeigt jedoch, dass die Wiederverwendung von Code einfach nicht so häufig ist, da Sie selten genau das gleiche Problem lösen. Wenn Sie in Zukunft eine Variante dieses Problems lösen müssen, überarbeiten Sie Ihr Design in Zukunft, um diese Variante hinzuzufügen. Berücksichtigen Sie dies jedoch derzeit nicht .

Mit anderen Worten, planen Sie die unmittelbare Aufgabe, aber planen Sie nichts weiter voraus.