Ablauf: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
LeonH (Diskussion | Beiträge) |
|||
| (23 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
{{review}} | {{review}} | ||
__TOC__ | __TOC__ | ||
| Zeile 9: | Zeile 8: | ||
Dazu ist das Treffen normalerweise in die drei Teile Sprint Review, Sprint Planning und Sprint Retrospective unterteilt. Bei den ersten zwei Treffen kann es aber sinnvoll sein, sich erst einmal langsam an diese Vorgehensweise heranzutasten und die Aufteilung nicht so streng zu verfolgen. Erst wenn die eigentliche Implementierungsphase beginnt sollte man sich möglichst eng an diese Aufteilung halten. | Dazu ist das Treffen normalerweise in die drei Teile Sprint Review, Sprint Planning und Sprint Retrospective unterteilt. Bei den ersten zwei Treffen kann es aber sinnvoll sein, sich erst einmal langsam an diese Vorgehensweise heranzutasten und die Aufteilung nicht so streng zu verfolgen. Erst wenn die eigentliche Implementierungsphase beginnt sollte man sich möglichst eng an diese Aufteilung halten. | ||
=== Sprint Review ( | === Sprint Review (max. 30min) === | ||
Im Sprint Review werden die Ergebnisse des vergangenen [[Sprint]]s besprochen und bestimmt, ob alle Ziele erreicht worden sind. | Im Sprint Review werden die Ergebnisse des vergangenen [[Sprint]]s demonstriert und besprochen und bestimmt, ob alle Ziele erreicht worden sind. | ||
Zu Beginn dieses Teils des Treffens führt das Team zuerst vor, was für neue Features im letzten [[Sprint]] fertiggestellt worden sind. Danach erklärt entweder der [[Product Owner]] (siehe [[Ablauf#Wiederkehrende Aufgaben|Wiederkehrende Aufgabe "Product Owner"]]) oder jedes Teammitglied einzeln, welche Aufgaben aus dem letzten [[Sprint]] im Sinne der [[DoD]] abgeschlossen wurden, bzw. welche übrig geblieben sind. Dann wird die Aufwandsabschätzung überprüft. Dabei sollten zwei Punkte geklärt werden: | Zu Beginn dieses Teils des Treffens führt das Team zuerst vor, was für neue Features im letzten [[Sprint]] fertiggestellt worden sind. Danach erklärt entweder der [[Product Owner]] (siehe [[Ablauf#Wiederkehrende Aufgaben|Wiederkehrende Aufgabe "Product Owner"]]) oder jedes Teammitglied einzeln, welche Aufgaben aus dem letzten [[Sprint]] im Sinne der [[DoD|Definition of Done]] abgeschlossen wurden, bzw. welche übrig geblieben sind. Dann wird die Aufwandsabschätzung überprüft. Dabei sollten zwei Punkte geklärt werden: | ||
* War die Abschätzung für die einzelnen [[Item]]s im letzten [[Sprint]] richtig oder hat man sich nach oben oder unten verschätzt? | * War die Abschätzung für die einzelnen [[Item]]s im letzten [[Sprint]] richtig oder hat man sich nach oben oder unten verschätzt? | ||
* Wurde die dem Team zur Verfügung stehende Zeit richtig eingeschätzt? | * Wurde die dem Team zur Verfügung stehende Zeit richtig eingeschätzt? | ||
| Zeile 19: | Zeile 18: | ||
Die Ergebnisse aus dem Sprint Review können dann direkt im nächsten Teil des Gruppentreffens verwendet werden. | Die Ergebnisse aus dem Sprint Review können dann direkt im nächsten Teil des Gruppentreffens verwendet werden. | ||
=== Sprint | === Sprint Retrospective (max. 15min) === | ||
In diesem Teil des Treffens sollten alle Dinge geklärt werden, die den bisherigen Prozess betreffen. Dazu wird diskutiert, was im letzten Sprint im Hinblick auf Menschen, Beziehungen, Prozesse, Tools gut bzw. schlecht gelaufen ist. Bei Bedarf sollte man feststellen, wo etwas verändert werden muss, damit die gemeinsamen Ziele besser erreicht werden können. Dabei sollte man einen schriftlichen Plan erstellen, wie man diese Änderungen im nächsten [[Sprint]] umsetzen kann. | |||
Im Speziellen sollte während der Sprint Retrospektive auch die [[DoD]] diskutiert und im Bedarfsfall angepasst werden. | |||
Dieser Schritt finde '''vor''' dem nächsten Sprintplanning statt, da Änderungsvorschläge direkt im anschließenden Sprint umgesetzt werden sollen. | |||
=== Sprint Planning (max. 60min) === | |||
In diesem Teil des Treffens werden die Ziele für den nächsten Sprint geplant. | In diesem Teil des Treffens werden die Ziele für den nächsten Sprint geplant. | ||
| Zeile 28: | Zeile 35: | ||
==== Wiederkehrende Aufgaben ==== | ==== Wiederkehrende Aufgaben ==== | ||
Während des Softwarepraktikums | Während des Softwarepraktikums müssen bestimmte organisatorische Aufgaben in jedem [[Sprint]] ab Woche 2 erledigt werden. Diese Aufgaben können immer vom gleichen Teammitglied, oder abwechselnd ausgeführt werden. Aufgaben können auch von mehr als einer Person erledigt werden, sofern der Umfang der Aufgaben dies zulässt und Bedarf besteht. | ||
Die folgenden wiederkehrenden Aufgaben gibt es: | |||
* Product Owner ( | * [[Product_Owner|Product Owner]] (ab Woche 2) | ||
** Pflegen und Anpassen von | ** Pflegen und Anpassen von User Stories und Tasks im [[Product Backlog]]. | ||
** Verfeinern von | ** Verfeinern von User Stories zu Tasks. | ||
** | ** User Stories mit Prioritäten versehen und Prioritäten aktualisieren. | ||
** Gruppentreffen vorbereiten (was ist fertig, wie war die Aufwandsabschätzung). | ** Gruppentreffen vorbereiten (was ist fertig, wie war die Aufwandsabschätzung). | ||
* | ** Gemeinsam mit der Gruppe bestimmen, was aufgrund der Entwicklungsreife die als nächstes zu bearbeitenden User Stories werden soll. | ||
** Vor dem Gruppentreffen das Increment nach <code>release</code> pushen (siehe [[GitWorkflow#Sprint Abschließen| Sprint Abschließen]]). | |||
* Qualitätssicherung (ab Woche 3) | |||
** Code auf [[CleanCode|Clean-Code]] Richtlinien prüfen. | |||
** Code Reviews vorbereiten und durchführen. | |||
** ReSharper-Konformität im ganzen Projekt überprüfen und ggf. herstellen. | |||
* Architektur (ab Woche 3) | |||
** Schnittstellen definieren. | ** Schnittstellen definieren. | ||
** Architekturbeschreibungen pflegen. | ** Architekturbeschreibungen pflegen. | ||
** Einhaltung der Architektur sicherstellen | ** Einhaltung der Architektur im Projekt sicherstellen und beides ggf. anpassen. | ||
** Einen Überblick über die Gesamtarchitektur behalten und bei der Umsetzung verschiedener Tasks stets die Abhängigkeiten innerhalb der Architektur berücksichtigen. | |||
** | |||
==== Aufgabe schwieriger als gedacht ==== | ==== Aufgabe schwieriger als gedacht ==== | ||
Natürlich kann es vorkommen, dass man eine Aufgabe als zu leicht einschätzt und sich während der Bearbeitung abzeichnet, dass man die Aufgabe innerhalb des aktuellen [[Sprint]]s nicht erledigen kann. Daher ist es zum einen wichtig, bei den eigenen Aufgaben auf die Abhängigkeiten zu den Aufgaben anderer Teammitglieder zu achten und sich entsprechend abzusprechen (speziell sollte man vermeiden, erst kurz vorm Ende des [[Sprint]]s mit Aufgaben zu beginnen, die andere für die Erledigung ihrer Aufgaben brauchen). Zum anderen '''muss''' man seine Teammitglieder und den Tutor über | Natürlich kann es vorkommen, dass man eine Aufgabe als zu leicht einschätzt und sich während der Bearbeitung abzeichnet, dass man die Aufgabe innerhalb des aktuellen [[Sprint]]s nicht erledigen kann. Daher ist es zum einen wichtig, bei den eigenen Aufgaben auf die Abhängigkeiten zu den Aufgaben anderer Teammitglieder zu achten und sich entsprechend abzusprechen (speziell sollte man vermeiden, erst kurz vorm Ende des [[Sprint]]s mit Aufgaben zu beginnen, die andere für die Erledigung ihrer Aufgaben brauchen). | ||
Zum anderen '''muss''' man seine Teammitglieder und den Tutor über ein Kommentar im entsprechenden Ticket '''rechtzeitig''' informieren, dass eine Aufgabe nicht mehr innerhalb des aktuellen [[Sprint]]s erledigt werden kann. | |||
Ohne eine rechtzeitige Mitteilung im Ticket zählt die jeweilige Aufgabe als nicht abgeschlossen und führt zu Punkteverlust bei den wöchentlich erreichbaren Punkten der Einzelleistung (siehe [[Formalien#Benotung|Benotung]]). | |||
== Hinweise zur Arbeitsorganisation == | == Hinweise zur Arbeitsorganisation == | ||
| Zeile 73: | Zeile 78: | ||
* Auch für sich selbst den Sprint planen | * Auch für sich selbst den Sprint planen | ||
* Abhängigkeiten berücksichtigen | * Abhängigkeiten berücksichtigen | ||
* | * Gitea richtig benutzen | ||
* Richtig abschätzen (vlt. auch Abschätzungsmethoden?) Abschätzungen korrigieren | * Richtig abschätzen (vlt. auch Abschätzungsmethoden?) Abschätzungen korrigieren | ||
* Wie geht Code Review? Vlt. Code Review Artikel. | * Wie geht Code Review? Vlt. Code Review Artikel. | ||
