it-swarm-eu.dev

Wie gehen Sie mit Design in Scrum um?

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

Jede Iteration kann eine Änderung des Designs beinhalten, daher wollte ich nur wissen, wie die Leute dies erfassen, damit neue Entwickler die Domäne leicht verstehen und so schnell wie möglich an Bord kommen können.

26
Seth

nur weil es Scrum ist, heißt das nicht, dass sich bei jedem Sprint alles ändert!

Bei Scrum geht es um tun, was nötig ist (aber nicht mehr). Sie müssen das Design noch ausführen und Sie müssen noch dokumentieren. Es ist nur der Betrag ist nicht festgelegt, noch wie es geht.

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

11
Martin York

Ich habe viel zu diesem Thema zu sagen. Ich habe viele Fälle gesehen, in denen Unternehmen/Teams/Personen sagen, dass sie einen agilen Ansatz für Software verwenden, aber in Wirklichkeit möchten sie die Belohnungen ernten, die agile Methoden versprechen, 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 TDD nur ungern ausführen müssen). In TDD drücken Ihre Tests das Design und die Absicht des Codes aus (wenn sie sagen "der Code ist die Dokumentation", sollten sie sagen "die Tests sind die Dokumentation"). Indem Sie Komponententests schreiben, die Ihr Verständnis der vorliegenden Funktion zum Ausdruck bringen, geben Sie explizit an, was der Code Ihrer Meinung nach tun muss. Dann schreiben Sie den Code, der es tut. Dann überarbeiten Sie diesen Code so, dass er den guten Architekturprinzipien "Red-Green-Refactor" entspricht.

Wenn Sie Ihre Komponententests bei jedem Einchecken (oder sogar vor jedem Einchecken) ausführen, wird überprüft, ob der neue Code, den Sie geschrieben haben, die erwartete Funktionalität in einem anderen Bereich der Anwendung nicht beeinträchtigt. Dies bietet ein Sicherheitsnetz, mit dem Sie den Code ohne Wrack ändern können. Wenn Sie die vorliegenden Anforderungen besser verstehen, können Sie den Test ändern, um dieses 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 ist eine empfohlene Lektüre

Dies sind gute Orte, um zu lernen, wie man sich einer agilen Entwicklung wirklich nähert.

10
Michael Brown

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

2
Steven A. Lowe

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

Es muss genug von einem Gesamtdesign vorhanden sein, das in welcher Form auch immer niedergeschrieben ist, um die Beziehung zwischen den Geschichten und den Erwartungen des Kunden zu erkennen.

Ein Teil des Designs, das für jede Story benötigt wird, wird während der Planung in Planung und Verhandlung mit dem Product Owner durchgeführt.

Der Großteil des Designaufwands für eine Geschichte würde im Sprint erledigt.

Wenn die Story nicht ausreichend definiert ist, um geschätzt zu werden, kann im aktuellen Sprint eine Zeitbox reserviert werden, um genügend Designarbeit zu leisten, damit eine geeignete Story für einen späteren Sprint erstellt werden kann.

1
Blake

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

Sie müssen ein wenig planen, damit dies funktioniert. Geben Sie das Sprint-Planungsmeeting ein, bei dem das Team die Aufgaben für den bevorstehenden Sprint schä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 etwas mehr wissen. Das Team diskutiert also das Design und entwickelt eine umfassende Lösung ("Unterklasse Auto?") Und fügt diese als Erinnerung an die Aufgabe hinzu. 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 überhaupt Diagramme erstellen zu müssen (zu diesem Zeitpunkt).

Für tatsächliche physische Dokumentation empfehle ich empfehle 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. Außerdem ist es sehr hilfreich, einige Zustandsdiagramme für die wichtigsten Klassen im System zu erstellen. Mit einigen ausgewählten Sequenzdiagrammen typischer Anwendungsfälle können Sie schnell erkennen, wie die Dinge miteinander verbunden sind. Ich gehe davon aus, dass Sie aus Ihrem Code Klassenhierarchiediagramme erstellen können, damit das Problem leicht gelöst werden kann.

Beachten Sie, dass alle Diagramme nach der eigentlichen Implementierung erstellt werden. Dies steht im Einklang mit der "funktionierenden Software über umfassende Dokumentation" und dem Just-in-Time-Design.

Und ja, lesbarer Code ist definitiv Dokumentation.

1
Martin Wickman

Es gibt nicht so viel Design im Voraus, wie sich die Anforderungen häufig ändern. Daher ist das Entwerfen bis auf Klassenebene normalerweise Zeitverschwendung. Es kann sich jedoch lohnen, Architekturentscheidungen auf höherer Ebene zu skizzieren.

Das Problem bei der Erstellung von Hochleistungsentwurfsdokumenten besteht darin, dass sie fast sofort nach ihrer Erstellung veraltet sind. Was also am besten funktioniert, ist normalerweise eine Dokumentation auf hoher Ebene, die sich in kurzer Zeit wahrscheinlich nicht vollständig ändern wird.

1
Vadim

Innerhalb der Eclipse-Community gibt es heute eine Spaltung zwischen traditionellen UML-Tools, die sich auf MDD konzentrieren und bei 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, weil standardisiert, um mit anderen Teammitgliedern zu kommunizieren. alt text

0
UML_GURU

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

Wenn Sie dann die Anforderung tatsächlich implementieren, ändern Sie das Design der unteren 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 ...

0
indyK1ng