Ablauf: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
Zeile 16: | Zeile 16: | ||
=== Sprint Planning ('''max. 60min''') === | === Sprint Planning ('''max. 60min''') === | ||
In diesem Teil des Treffens werden die Ziele für den nächsten Sprint geplant. | |||
Zuerst sollte geklärt werden, wie viel Zeit jedes Teammitglied und damit das gesamte Team für den nächsten [[Sprint]] bereitstellen kann. Danach wählt man gemeinsam ein [[Item]] (unter Berücksichtigung der Priorität) aus dem [[Product Backlog]] aus, das im nächsten [[Sprint]] umgesetzt werden soll. Das [[Item]] sollte nun so lange in kleinere [[Item]]s, zerlegt werden (z.B. zuerst in User Stories und dann in Tasks, oder auch direkt in Tasks), bis diese direkt als Aufgaben an einzelne Teammitglieder verteilt werden können. Für jedes der so entstandenen [[Item]]s sollte nun der Arbeitsaufwand ([[ETC]]) abgeschätzt werden. Danach werden die [[Item]]s in das neue [[Sprint Backlog]] verschoben. | |||
Diesen Vorgang wiederholt man nun so lange bis man die Zeit, die das Team für den nächsten Sprint zur Verfügung hat, aufgebraucht hat. Erst danach werden die einzelnen Aufgaben im [[Sprint Backlog]] unter den Teammitgliedern aufgeteilt. | |||
Am Ende diesen Teils kommt man somit zu einem neuen [[Sprint Backlog]] mit einer Liste von Aufgaben und jeweils einer Zuteilung an einen Verantwortlichen. | |||
Die Aufgaben sollten mit Bedacht herausgearbeitet und verteilt werden, da sie in der Regel für den Rest des [[Sprint|Sprints]] festgehalten und nicht mehr geändert werden. | |||
Natürlich kann es vorkommen, dass man sich im Scrum-Meeting überschätzt und sich während der Bearbeitung der Aufgaben abzeichnet, dass man einen Teil der Aufgaben innerhalb des aktuellen Sprints nicht erledigen kann. In diesem Fall '''muss''' dies den anderen Gruppenmitgliedern und dem Tutor über die Gruppenliste rechtzeitig (sobald man merkt, dass die Zeit für eine Aufgabe nicht reicht) vor Ende des Sprints mitgeteilt werden. Versäumt man diese Mitteilung, zählt die jeweilige Aufgabe als nicht abgeschlossen und führt zu Punkteverlust bei den wöchentlich erreichbaren Punkten der Eigenleistung (siehe [[Formalien#Benotung|Benotung]]). | Natürlich kann es vorkommen, dass man sich im Scrum-Meeting überschätzt und sich während der Bearbeitung der Aufgaben abzeichnet, dass man einen Teil der Aufgaben innerhalb des aktuellen Sprints nicht erledigen kann. In diesem Fall '''muss''' dies den anderen Gruppenmitgliedern und dem Tutor über die Gruppenliste rechtzeitig (sobald man merkt, dass die Zeit für eine Aufgabe nicht reicht) vor Ende des Sprints mitgeteilt werden. Versäumt man diese Mitteilung, zählt die jeweilige Aufgabe als nicht abgeschlossen und führt zu Punkteverlust bei den wöchentlich erreichbaren Punkten der Eigenleistung (siehe [[Formalien#Benotung|Benotung]]). | ||
Zeile 66: | Zeile 69: | ||
{{BA|Dietsch|Alleine arbeiten: Auf Code-Qualität achten [[Clean Code]], Abschätzungen korrigieren und kommunizieren (auch wegen Punkten), ... }} | {{BA|Dietsch|Alleine arbeiten: Auf Code-Qualität achten [[Clean Code]], Abschätzungen korrigieren und kommunizieren (auch wegen Punkten), ... }} | ||
[[Kategorie:Organisation]] | [[Kategorie:Organisation]] | ||
[[Kategorie:Scrum]] | [[Kategorie:Scrum]] |
Version vom 29. April 2014, 15:35 Uhr
Das Softwarepraktikum verwendet Scrum als Vorgehensmodell für die Softwareentwicklung und ist daher in insgesamt 13 Sprints (1 Sprint pro Woche) unterteilt.
Wöchentliches Gruppentreffen mit Tutor
Jeder Sprint beginnt und endet am wöchentlichen Gruppentreffen, das wie ein Scrum-Meeting organisiert ist. In diesem Treffen wird der letzte Sprint besprochen und der nächste Sprint geplant. Dazu ist das Treffen in 3 Teile unterteilt.
Sprint Review (max. 30min)
- Product Owner gibt basierend auf DoD Einschätzung ab, was fertig und was nicht fertig ist.
- Team zeigt, was alles fertig geworden ist und beantwortet Fragen zum Fortschritt.
- Team erklärt dabei, was es für Probleme gab und wie diese gelöst worden sind.
- Product Owner erklärt den aktuellen Stand des Product Backlogs und speziell Änderungen an der Aufwandsabschätzung.
Sprint Planning (max. 60min)
In diesem Teil des Treffens werden die Ziele für den nächsten Sprint geplant.
Zuerst sollte geklärt werden, wie viel Zeit jedes Teammitglied und damit das gesamte Team für den nächsten Sprint bereitstellen kann. Danach wählt man gemeinsam ein Item (unter Berücksichtigung der Priorität) aus dem Product Backlog aus, das im nächsten Sprint umgesetzt werden soll. Das Item sollte nun so lange in kleinere Items, zerlegt werden (z.B. zuerst in User Stories und dann in Tasks, oder auch direkt in Tasks), bis diese direkt als Aufgaben an einzelne Teammitglieder verteilt werden können. Für jedes der so entstandenen Items sollte nun der Arbeitsaufwand (ETC) abgeschätzt werden. Danach werden die Items in das neue Sprint Backlog verschoben. Diesen Vorgang wiederholt man nun so lange bis man die Zeit, die das Team für den nächsten Sprint zur Verfügung hat, aufgebraucht hat. Erst danach werden die einzelnen Aufgaben im Sprint Backlog unter den Teammitgliedern aufgeteilt. Am Ende diesen Teils kommt man somit zu einem neuen Sprint Backlog mit einer Liste von Aufgaben und jeweils einer Zuteilung an einen Verantwortlichen.
Die Aufgaben sollten mit Bedacht herausgearbeitet und verteilt werden, da sie in der Regel für den Rest des Sprints festgehalten und nicht mehr geändert werden.
Natürlich kann es vorkommen, dass man sich im Scrum-Meeting überschätzt und sich während der Bearbeitung der Aufgaben abzeichnet, dass man einen Teil der Aufgaben innerhalb des aktuellen Sprints nicht erledigen kann. In diesem Fall muss dies den anderen Gruppenmitgliedern und dem Tutor über die Gruppenliste rechtzeitig (sobald man merkt, dass die Zeit für eine Aufgabe nicht reicht) vor Ende des Sprints mitgeteilt werden. Versäumt man diese Mitteilung, zählt die jeweilige Aufgabe als nicht abgeschlossen und führt zu Punkteverlust bei den wöchentlich erreichbaren Punkten der Eigenleistung (siehe Benotung).
Wiederkehrende Aufgaben
Während des Semesters kann es sinnvoll sein, folgende Aufgaben in jedem Sprint immer wieder neu zu verteilen:
- Product Owner (ab Woche 2)
- Pflegen und Anpassen von Requirements und User Stories im Product Backlog.
- Verfeinern von Requirements zu User Stories.
- Requirements nach Entwicklungsreife ordnen.
- Gruppentreffen vorbereiten (was ist fertig, wie war die Aufwandsabschätzung).
- Architektur (ab Woche 3)
- Schnittstellen definieren
- Architekturbeschreibungen pflegen
- Einhaltung der Architektur sicherstellen
- Qualitätssicherung (ab Woche 6)
- Code auf Clean-Code Richtlinien prüfen.
- Code Reviews vorbereiten
- ReSharper Konformität herstellen
Sprint Retrospective (max. 15min)
- Diskutieren, was im letzten Sprint im Hinblick auf Menschen, Beziehungen, Prozesse, Tools gut bzw. schlecht gelaufen ist.
- Wo muss etwas verändert oder verbessert werden, damit besser gearbeitet werden kann?
- Plan erstellen, wie diese Änderungen im nächsten Sprint umgesetzt werden können.
Hinweise zur Arbeitsorganisation
Gemeinsam arbeiten
Außerhalb des offiziellen Gruppentreffens ist es sinnvoll zu versuchen, weitere feste Treffen zu vereinbaren, an denen gemeinsam an der Umsetzung des Spiels gearbeitet werden kann. Oftmals reicht es auch schon, gemeinsame Zeiten zu vereinbaren in denen man von Zuhause aus arbeitet, sich aber gegenseitig über synchrone Kommunikationsmedien (Skype, IRC, Instant Messaging,...) erreichen kann.
Bei diesen Treffen ist es sinnvoll, zuerst ein Daily-Scrum zu machen. Ein Daily-Scrum ist ein Scrum-Meeting, das max. 15min dauert und bei dem jeder Teilnehmer folgende Fragen beantwortet, ohne das andere Teilnehmer Rückfragen stellen oder Kommentare abgeben:
- Was wurde seit dem letzten Meeting gemacht?
- Was wird bis zum nächsten Meeting gemacht?
- Was für Probleme gibt es, die die aktuellen Aufgaben behindern?
Probleme werden hierbei nur kommuniziert, jedoch noch nicht gelöst. Dies dient dem Zweck, dass jedes Gruppenmitglied innerhalb von 15 min über die Arbeit und Probleme aller anderen Mitglieder informiert ist. Im Anschluss an das Daily-Scrum können dann die vorhandenen Probleme angegangen und gelöst werden.
Kommunizieren
- Auch für sich selbst den Sprint planen
- Abhängigkeiten berücksichtigen
- Trac richtig benutzen
- Abschätzungen korrigieren
- Code Review