Ablauf

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 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 (max. 30min)

Im Sprint Review werden die Ergebnisse des vergangenen Sprints 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 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:

• War die Abschätzung für die einzelnen Items 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?

Zum Schluss sollte noch geklärt werden, ob mit der aktuellen Arbeitsweise der nächste Milestone erreicht werden kann.

Die Ergebnisse aus dem Sprint Review können dann direkt im nächsten Teil des Gruppentreffens verwendet werden.

Sprint Planning (max. 60min)

In diesem Teil des Treffens werden die Ziele für den nächsten Sprint geplant.

Ablauf

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 an einzelne Teammitglieder verteilt werden können. Für jedes der so entstandenen atomaren Items sollte nun der Arbeitsaufwand (ETC) abgeschätzt werden. Danach werden die atomaren 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 Items im Sprint Backlog unter den Teammitgliedern aufgeteilt. Am Ende diesen Teils kommt man somit zu einem neuen Sprint Backlog mit einer Liste von Items die jeweils einem Verantwortlichen zugeteilt sind.

Wiederkehrende Aufgaben

Während des Softwarepraktikums kann es sinnvoll sein, bestimmte organisatorische Aufgaben in jedem Sprint immer wieder neu zu verteilen. Dadurch kann sichergestellt werden, dass der Aufwand für diese Aufgaben auch honoriert wird und der Prozess reibungsloser abläuft.

Folgende Aufgaben bieten sich an:

• Product Owner (z.B. 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 (z.B. ab Woche 3)
  • Schnittstellen definieren.
  • Architekturbeschreibungen pflegen.
  • Einhaltung der Architektur sicherstellen.
• Coaching (z.B. ab Woche 3)
  • Code Reviews vorbereiten und durchführen.
• Qualitätssicherung (z.B. ab Woche 6)
  • Code auf Clean-Code Richtlinien prüfen.
  • ReSharper-Konformität im ganzen Projekt überprüfen und ggf. herstellen.

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 Sprints 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 Sprints mit Aufgaben zu beginnen, die andere für die Erledigung ihrer Aufgaben brauchen). Zum anderen muss man seine Teammitglieder und den Tutor über die Gruppenliste rechtzeitig informieren, dass eine Aufgabe nicht mehr innerhalb des aktuellen Sprints erledigt werden kann.

Ohne eine rechtzeitige Mitteilung zählt die jeweilige Aufgabe als nicht abgeschlossen und führt zu Punkteverlust bei den wöchentlich erreichbaren Punkten der Eigenleistung (siehe Benotung).

Sprint Retrospective (max. 15min)

Im letzten 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.

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.