Wie gehen Sie in Scrum mit Design um?

Wie gehen Sie in Scrum mit Design um? Haben Sie noch gut geschriebene Designdokumente für jede Scrum-Iteration? Entwerfen Sie nur Notizen mit UML-Diagrammen? Oder haben Sie nur gut kommentierten Code?

Bei jeder Iteration muss möglicherweise das Design geändert werden. Daher wollte ich nur wissen, wie die Leute dies erfassen, damit neue Entwickler die Domäne mühelos verstehen und so schnell wie möglich einsteigen können.

Nur weil es Scrum ist, bedeutet das nicht, dass sich bei jedem Sprint alles ändert!

Bei Scrum geht es darum , das Notwendige zu tun (aber nicht mehr) . Sie müssen das Design noch ausführen und dokumentieren. Es ist nur der Betrag nicht festgelegt, noch wie es geht.

Teil der Planung jedes Sprints ist die Entscheidung, was getan werden muss. Wenn etwas im Backlog entworfen werden muss, weil es sich auf andere Dinge auswirkt, müssen Sie eine bestimmte Aufgabe für die Entwurfsprozesse hinzufügen und dies vor der Implementierungsaufgabe tun.

Zu diesem Thema habe ich viel zu sagen. Ich habe viele Fälle erlebt, in denen Unternehmen / Teams / Mitarbeiter sagen, dass sie einen agilen Ansatz für Software verwenden, aber in Wirklichkeit wollen sie die Belohnungen, die agile Methoden versprechen, ernten, ohne sich an die Prinzipien zu halten.

Damit eine schnelle Iteration funktioniert, sollten Sie eine testgetriebene Entwicklung durchführen (ich habe aufgehört zu sagen, dass Sie nur widerwillig TDD durchführen müssen). In TDD drücken Ihre Tests das Design und die Absicht des Codes aus (wenn sie sagen, dass "der Code die Dokumentation ist", sollten sie sagen, dass "die Tests die Dokumentation sind"). Indem Sie Komponententests schreiben, die Ihr Verständnis der vorliegenden Funktion zum Ausdruck bringen, geben Sie ausdrücklich an, was Ihrer Meinung nach der Code tun muss. Dann schreiben Sie den Code, der das macht. Dann überarbeiten Sie diesen Code so, dass er den guten Architekturprinzipien "Rot-Grün-Refaktor" entspricht.

Durch Ausführen Ihrer Komponententests bei jedem Einchecken (oder sogar vor jedem Einchecken) wird sichergestellt, dass der neue Code, den Sie geschrieben haben, die erwarteten Funktionen in einem anderen Bereich der Anwendung nicht beeinträchtigt. Dies bietet ein Sicherheitsnetz, mit dem Sie den Code in aller Ruhe ändern können. Mit zunehmendem Verständnis der vorliegenden Anforderungen können Sie den Test ändern, um das neue Wissen widerzuspiegeln. Das eigentliche Design liegt in den Unit-Tests. Alles andere (einschließlich Code, der nicht behandelt wird) ist eine Lüge.

Hier sind einige empfohlene Lektüre

• Code bereinigen
• Prinzipien, Muster und Praktiken der agilen Softwareentwicklung
• Der Pragmatische Programmierer

Dies sind gute Orte, um zu lernen, wie man wirklich agile Entwicklung angeht.

Scrum ist eine Projektmanagementmethode, keine Softwareentwicklungsmethode. Scrum wird normalerweise in Verbindung mit einer agilen Methodik verwendet. Darin liegt Ihre Antwort.

Es gibt im Vorfeld nicht so viel Design, wie sich die Anforderungen häufig ändern. Es ist also in der Regel Zeitverschwendung, bis auf Klassenebene zu entwerfen. Es kann sich jedoch lohnen, übergeordnete Architekturentscheidungen zu skizzieren.

Das Problem bei anspruchsvollen Designdokumenten besteht darin, dass sie fast veraltet sind, sobald sie erstellt wurden. Was am besten funktioniert, ist in der Regel eine Dokumentation auf hohem Niveau, die sich in kurzer Zeit wahrscheinlich nicht vollständig ändern wird.

Scrum ist ein iteratives und inkrementelles Modell, das auf agilen Werten basiert . Das heißt, Sie haben keine separate Designphase. Die Idee ist, dass Sie ständig sollten mit Design beschäftigen sollten, genauso wie Sie sich ständig mit Analyse, Implementierung, Testen und Integration während des gesamten Projekts beschäftigen.

Sie müssen etwas planen, damit dies funktioniert. Nehmen Sie an der Sprint-Planungsbesprechung teil , in der das Team Aufgaben für den bevorstehenden Sprint abschätzt. Den meisten Menschen ist nicht klar, dass dies nicht nur ein Schätzungsgespräch ist, sondern auch ein Entwurfsaufwand. Eine Aufgabe könnte beispielsweise "Code für neues Automodell hinzufügen" sein. Sie können dies noch nicht abschätzen, Sie müssen ein bisschen mehr wissen. Das Team erörtert das Design und entwickelt eine umfassende Lösung ("Unterklasse Auto?"), Die der Aufgabe als Erinnerung hinzugefügt wird. Mehr Formalität braucht man selten. Sie haben jetzt eine Idee, wie Sie das Problem lösen können. Sie haben noch nicht alle Details und das ist in Ordnung, Sie wissen genug über das Design, um eine bequeme Schätzung vornehmen zu können. Ohne dass Sie (zu diesem Zeitpunkt) irgendwelche Diagramme erstellen müssen.

Für die tatsächliche physische Dokumentation empfehle ich , ein Systemübersichtsdiagramm an einer Wand zu erstellen damit alle es sehen können. Die Übersicht muss nur die wichtigsten Klassen und Module enthalten und sollte selten aktualisiert werden müssen. Auch das Erstellen einiger Zustandsdiagramme für die wichtigsten Klassen im System ist sehr hilfreich. Streuen Sie ein paar ausgewählte Sequenzdiagramme mit typischen Anwendungsfällen an, damit die Menschen schnell erkennen können, wie die Dinge miteinander verbunden sind. Ich gehe davon aus, dass Sie Klassenhierarchiediagramme aus Ihrem Code generieren können, sodass dieses Problem leicht gelöst werden kann.

Beachten Sie, dass alle Diagramme nach der tatsächlichen Implementierung erstellt werden. Dies steht im Einklang mit der "Arbeitssoftware über umfassende Dokumentation" und Just-in-Time-Design.

Und ja, lesbarer Code ist definitiv Dokumentation.

Die Gesamtarchitektur des Projekts und das High-Level-Design würden außerhalb der Scrum-Teams erstellt, wenn die Projektbesitzer die Geschichten erstellen.

Es muss genug eines Gesamtentwurfs in welcher Form auch immer vorhanden sein, um die Beziehung zwischen den Geschichten und den Erwartungen des Kunden zu erkennen.

Einige der für jede Geschichte erforderlichen Entwürfe würden während der Planung in Planung und Verhandlung mit dem Produktbesitzer vorgenommen.

Der größte Teil des Entwicklungsaufwands für eine Geschichte entfiel auf den Sprint.

Wenn die Story nicht ausreichend definiert ist, um eine Schätzung vorzunehmen, kann im aktuellen Sprint eine Zeitbox abgelegt werden, um genügend Entwurfsarbeit zu leisten, damit eine entsprechende Story für einen späteren Sprint erstellt werden kann.

Mein Verständnis ist, dass Sie ein übergeordnetes Design mit den Anfangsanforderungen erstellen, die Sie zu Beginn des Projekts zusammengetragen haben. Sie dokumentieren diesen Entwurf gut.

Wenn Sie dann die Anforderung tatsächlich implementieren, ändern Sie das Design der niedrigeren Ebene nach Bedarf, aber Sie vermeiden, das Design der höheren Ebene zu ändern.

Nun, so wurde es mir sowieso vor fünf Minuten erklärt ...

In der Eclipse-Community gibt es heute eine Spaltung zwischen traditionellen UML-Tools für MDD, in denen das Modell den Code / die Entwicklung steuert, und Omondo, der der Ansicht ist, dass Iterationen den Entwicklungsprozess und sicherlich nicht nur das Modell steuern sollten.

Ich stimme ihnen zu, weil MDD Mist ist, während UML wirklich ein ausgezeichneter Weg ist, um zu standardisieren, um mit anderen Teammitgliedern zu kommunizieren.