Wie bekomme ich gutes Design mit agilen Methoden?

Ich verwende seit ungefähr drei Jahren eine agile Methodik (SCRUM) und sehe bestimmte Vorteile darin, insbesondere in dem kurzfristigen Feedback auf vielen Ebenen (von Kunden, die frühzeitig auf implementierte Funktionen zugreifen, von Testern, die Funktionen wie testen können) Sobald sie implementiert sind, von anderen Entwicklern, die sehr früh Feedback zu neuem Code durch Überprüfung usw. geben können.

Andererseits habe ich zwei offene Probleme, von denen ich das erste in dieser Frage zu erklären versuchen werde.

Problem: Schwierigkeit, ein gutes Design zu bekommen

Ich versuche, das Refactoring durchzuführen, sobald der Code unordentlich wird. Ich schreibe so viele Unit-Tests wie möglich (was hilft , Fehler im Allgemeinen und beim Refactoring im Besonderen zu vermeiden). Andererseits ist es mir nicht möglich, ein komplexes Feature in kleinen Schritten mit täglichen Commits zu entwickeln und den Code kontinuierlich zu überdenken, wenn er unstrukturiert wird.

Das einzige gut gestaltete Modul, das ich in letzter Zeit herstellen konnte, wurde auf eine andere Weise entwickelt: Ich analysierte das Problem einige Tage lang (ich hatte das Problem tatsächlich einige Monate lang durch den Kopf gegangen, bevor ich ernsthaft daran arbeitete) ), skizzierte noch ein paar Tage lang einen ziemlich detaillierten Entwurf aller beteiligten Klassen und ihrer Beziehungen, schloss mich dann in mein Büro ein und schrieb den gesamten Code auf, indem ich etwa drei Wochen lang ohne Unterbrechung arbeitete. Das Ergebnis war das Beste, was ich seit einiger Zeit produziert habe, mit sehr wenigen Fehlern, die relativ einfach zu lokalisieren und zu beheben waren, und mit einem sehr klaren Design, das seitdem keine relevanten Änderungen mehr erforderlich gemacht hat.

Bis jetzt fand ich es viel effektiver, mir ein Gesamtbild von dem zu machen, was ich vorab machen wollte, als in kleinen Schritten mit dem Schreiben von Code zu beginnen, in der Hoffnung, dass das große Bild dabei magisch auftaucht. Mit meiner besten Mühe hat mich der Ansatz der Entwicklung mit kleinen Schritten immer zu einem schlechteren Design geführt.

Frage : Hat jemand eine ähnliche Erfahrung gemacht? Wende ich SCRUM falsch an oder was muss ich beachten, wenn ich in kleinen Schritten entwickeln und trotzdem eine gut gestaltete Software erhalten möchte? Oder sollte ich eine Design User Story planen, bevor ich mit dem eigentlichen Coding beginne? Wird dies als eine gute Vorgehensweise angesehen, zumindest für Funktionen, die komplexer als der Durchschnitt sind?

NOTIZ BEARBEITEN

Mir ist bewusst, dass gutes Design nichts Absolutes ist und keinen eigenen Wert hat, sondern vom Kontext abhängt und dass man ein Design anstreben sollte, das für das jeweilige Problem gut genug ist .

Zum Beispiel ist mir gutes Design (zu sehr) egal, wenn ich eine einfache Komponente implementieren muss, die (1) so schnell wie möglich bereit sein muss, (2) nur einmal verwendet wird, (3) nicht von anderen Teilen des Systems (YAGNI) verwendet.

Gutes Design ist mir wichtig, wenn eine Komponente (1) mehrmals und in mehreren verschiedenen Releases eines Produkts verwendet wird, (2) über die Zeit gewartet und erweitert werden muss, (3) viele andere Komponenten davon abhängen .

Andererseits ist es mir nicht möglich, ein komplexes Feature in kleinen Schritten mit täglichen Commits zu entwickeln und den Code kontinuierlich zu überdenken, wenn er unstrukturiert wird.

Dann mach das nicht.

Nicht alles passt in die schöne agile Box. Oft hat ein Produkt ein paar komplexe Dinge, die nicht an Einzelpersonen vererbt werden können und in einem Sprint nicht auf eine vernünftige Weise vervollständigt werden können. Sie in diese Box zu zwingen , wird nur Ärger verursachen. Aber das sollten nur wenige sein. Wenn Sie feststellen, dass viele Ihrer Komponenten so sind, muss Ihr Product Owner (mit Ihrem Team) daran arbeiten, die Dinge besser aufzulösen. Mir geht es gut, wie Sie es getan haben: Nehmen Sie die Geschichte, entwerfen Sie sie und hämmern Sie sie so schnell wie möglich aus, mit der Erwartung, dass es einige Wochen dauern wird.

Im Allgemeinen gibt es drei Dinge, die ich gesehen habe, um in Agile gutes Design zu erzielen:

• Eigentlich mache ich Design - Viele Orte, die ich gesehen habe, starten ihren Sprint und beginnen einfach damit, Code herauszuspielen. Auf diese Weise erhalten Sie schlechtes Design. Agile verändert den Entwicklungsprozess von Plan - Code - Test - Release nicht, sondern verkürzt ihn nur auf granularere Teile. Setzen Sie sich zu Beginn des Sprints nach Bedarf hin und entwerfen Sie Ihre Lösung.

• Haben Sie einen Architekten / Lead - Sobald Ihr Projekt groß genug ist, arbeiten mehrere Scrum-Teams an verschiedenen Teilen der Anwendung. Es ist sehr nützlich, jemanden (oder mehrere Personen, abhängig von der Größe der Anwendung) zu haben, dessen Hauptaufgabe es ist, zu wissen, was alle Teams vom Standpunkt des Designs aus tun. Sie können Fragen beantworten und die Teams zu einem harmonischeren übergreifenden Design führen. Jedes Scrum-Team hat einen Vorsprung, der weiß, was die meisten anderen Teams tun. Das habe ich auch gesehen und war sehr effektiv.

• Sei ein Pragmatiker - ich habe das oben behandelt. Agile ist ein Werkzeug und wie jedes Werkzeug auch. es gilt nicht für alle probleme. Wenn es keinen Sinn macht, auf eine Komponente anzuwenden, wenden Sie sie dort nicht an. Ihr Ziel ist es, gute Software zu liefern. vergiss es nicht

Es ist sehr gut möglich, in kleinen Schritten zu implementieren und gut strukturierten wartbaren Code zu erhalten. In der Theorie ist es sehr einfach: Wenn Sie sicherstellen, dass der Code nach jeder Änderung gut strukturiert ist, wird er immer gut strukturiert sein. Ihr Code wird schlecht strukturiert, da Sie weiterhin Code hinzufügen, wenn Sie umgestalten sollten.

Unabhängig davon, wie viel Zeit Sie für das Design aufwenden, ändern sich die Anforderungen möglicherweise auf unerwartete Weise, und Sie müssen Code schreiben, der nicht zum ursprünglichen Design passt. Dann müssen Sie eine inkrementelle Änderung vornehmen. Wenn Sie über eine Reihe guter Komponententests verfügen und sich mit Refactoring auskennen, können Sie den Code gut strukturieren, wenn Sie neue Anforderungen erfüllen.

"Gut designt" ist subjektiv

Was bedeutet "gut gestaltet" für Sie? an den Product Owner? zum Kunden?

Ist "gut designt " ein Ziel des Produktbesitzers? ein Ziel des Kunden? oder nur du?

Entspricht das, was Sie für "nicht gut designt" halten, immer noch den Erwartungen des Produktbesitzers und macht den Kunden glücklich? Dann ist das ziemlich "gut designt" .

Gut genug und YAGNI

In den meisten agilen Methoden spricht nichts von "gut gestaltet", da jedes System, bei dem der Product Owner die Storys als vollständig akzeptiert und die Kunden glauben, dass es ihren Anforderungen entspricht, "gut gestaltet" ist .

Es wird erwartet, dass die Entwickler Profis sind und pragmatisch Best Practices, geeignete Designs und Redewendungen verwenden, um die Features und Storys zu implementieren.

Wenn Sie die Zeit nicht einkalkulieren, um die Dinge richtig zu machen, was ein Entwicklerproblem ist, und wenn der Product Owner verlangt, dass die Dinge in kürzerer Zeit erledigt werden können, ist es sein Vorrecht, dies zu tun, und Ihre Verantwortung, sie über das Problem aufzuklären Konsequenzen in Form von technischen Schuldengeschichten .

GEDRÄNGE

_{Die Agile Methodik, die aufgeschrieben werden kann, ist nicht die Agile Methodik. "- Jarrod Roberson}

SCRUM soll ein Framework von Tools sein, um den gesamten Lebenszyklus eines Softwareprodukts zu verwalten. Es soll kein starres Bündel von Dingen sein, nur ein guter Ort, um anzufangen und sich hoffentlich zu verbessern.

Die meisten Läden, in denen ich gearbeitet habe, haben sogenannte Sprint ZERO, Sprints für die leitenden Mitglieder des Teams, um eine Gesamtarchitektur oder ein Gesamtthema des Produkts zu skizzieren.

Geschichten, die größer als etwa 20 sind, werden in der Regel zerlegt, bis sie tatsächlich einige 3 - 5-Punkte-Geschichten ergeben. Eine dieser Geschichten lautet: "Als Team müssen wir uns treffen, um zu besprechen, wie wir diese Funktion entwickeln werden, damit wir in der vorgegebenen Zeit so wenig technische Schulden wie möglich haben."

Allgemein

Im Allgemeinen ist ein "gut gestaltetes" System gut genug und folgt YAGNI.

Bei Agile und insbesondere bei SCRUM als Implementierung von Agile geht es mehr darum, wie ein Produkt für den Product Owner / Sponsor so transparent wie möglich hergestellt werden kann.

Es geht nicht um technisches Design / Architektur. Es ist eher eine Philosophie, wie man sich der Bereitstellung von Software nähert, die die Bedürfnisse und Erwartungen der Kunden erfüllt. Wenn es nicht das gibt, was Sie als "gut gestaltete" Teile bezeichnen, ist dies an sich kein Versagen, da es kein grundlegender Teil der Philosophie ist.

Wir arbeiten seit mehreren Monaten mit scrum und ich möchte meine Erfahrungen mit Ihrem Problem teilen.

Vor ein paar Monaten wurde mir ein großes Stück zur Umsetzung gegeben. Ich hatte alle Spezifikationen parat und musste neue Funktionen entsprechend implementieren. Die Aufgabe bestand darin, ungefähr 5-6 Wochen (wie ich schätzte) zu dauern. Ich habe die erste Woche nur mit Design verbracht. Die Aufgabe war etwas kompliziert: Es gab ein Hauptobjekt, das, wie ich aus der Spezifikation schloss, 15 verschiedene Zustände hatte, und die Benutzeroberfläche sollte für jeden Zustand ein unterschiedliches Verhalten aufweisen.

Ich habe den gesamten Workflow und anschließend die DB-Struktur und -Klassen entworfen.

Ich sehe keinen anderen Ansatz in meinem Fall. Wenn ich sofort in das Programmieren eintauchen würde, hätte ich am Ende ein großes Durcheinander - fast unmöglich zu warten und extrem schwierig, weitere Änderungen vorzunehmen. Aber die Änderungen kamen in den nächsten 2 Wochen, so dass ich den Code überarbeiten musste. Mit dem anfänglich durchdachten Design war das jetzt ganz einfach. Das hat uns Zeit, Geld und Nerven gespart.

Nach dieser Erfahrung bin ich mir absolut sicher, dass es sich am Anfang lohnt, ein akzeptables Design zu erstellen, und hoffe, dass Sie es mit einem Wunder am Ende haben werden.

Das Nachsehen ist 20-20. Wenn Sie zu Beginn des Projekts die Informationen zur Verfügung hatten, um das Ganze herauszufinden, und dann den Code in ein paar Wochen schreiben, empfehle ich Ihnen, dies zu tun.

Sie geben nicht genug Anerkennung für alle Erkenntnisse, die Sie gewonnen haben, die Ansätze, die ausprobiert wurden und fehlgeschlagen sind / geändert werden mussten, und die gesteigerte Fähigkeit des Kunden / der Benutzer, Anforderungen genügend Anerkennung zu gewähren.

Warum sollte jemand mit einer Geschichte von erfolgreichen Wasserfallprojekten zu einer agilen Methodik wechseln?

Sie brauchen immer einen Überblick darüber, was das Endziel sein soll und welche Funktionen implementiert werden sollen und wann, bevor Sie ein Projekt starten. Die Arbeit an Geschichten als atomare Aufgaben fordert Ärger. Sie müssen die zukünftigen Anforderungen so weit wie möglich berücksichtigen.