Teamprozess
Um komplexe Produkte, insbesondere bei Software, zu entwickeln, ausliefern und zu erhalten, bedarf es einen Rahmenwerk mit dem Menschen im Team zusammen den höchstmöglichen Wert dieses Produkts erschaffen können. „Scrum“ ist ein solches Wertschöpfungs- wie auch Teamprozess, bei dem in unserem Projekt vorgegangen wurde. Hier wird nicht näher darauf eingegangen was Scrum ist, sondern lediglich wie wir anhand des Whiteboards Scrum anwendeten. Folgende Abbildung zeigt ein Schnappschuss des Verwaltungsprozesses unserer Aufgaben:
Bei dem Initialtreffen mit Auftraggeber, Product Owner, Entwicklerteam und Scrum Master legten wir grobe Ziele fest, die bei Abschluss des Projekts mit in die Bewertung des Endprodukts fließen würden. Im Anschluss zu diesem Treffen, formulierte das Entwicklerteam zusammen mit Product Owner (Marco Reitano) und Scrum Master (Marc Schmidt) feingranulare Arbeitspakete, die für das gesamte Projekt relevant sein würden. Wichtig hier anzumerken, dass diese anfänglichen Arbeitspakete einen Initialbild der Anforderungen zu Beginn des Projekts darstellten, und während des gesamten Projekts Gegenstand von Änderungen sein würden. Ein „agiler“ Prozess bei der sich die Aufgaben iterativ zu den entwickelnden Anforderungen anpassten. Einige Beispiele dieser Arbeitspakete sind:
- API Governance klären - hier musste geklärt werden, wer zuständig für die HoPS-API zuständig ist, um möglichst Zusammenarbeit zwischen unseren Systemen zu optimieren.
- Domainmodell für „Module“ anschauen ggf. erstellen - um einen kohärentes und relevantes „Module-Service“ entwickeln zu können, war es wichtig das bestehende Domänenmodell anzuschauen und weiterzuverfeinern.
- Verschiedene Filtermöglichkeiten für Module - Module sollten nach verschiedene Kriterien wie z. B. „Professoren“, „Semester“ usw. gefiltert werden können.
- Stand Keycloak abfragen - das ADV-Labor war zum Zeitpunkt unseres Projektbeginns dabei eine Authentifizierungslösung über Campus-weite Dienste zu entwickeln. Wir mussten lediglich den Status dieser Entwicklung klären, um zu evaluieren, ob wir dieses System mit in unsere Prox-Dienste integrieren konnten.
- Einrichtung für lokale Entwicklung - um Lokal im eigenen Rechner entwickeln zu können, ohne Netzwerk-erforderlichen Zugriff haben zu müssen, musste dies dementsprechend eingerichtet werden.
- Anti-Corruption Layer anlegen/umsetzen - in einer komplexen Welt verschiedener Systeme, sind die Anforderungen eines Systems unterschiedlich zu den eines anderen. In unseren Fall, musste versucht werden so gut wie möglich mit den Entwicklern der HoPS-API zu klären, wie die Logik dessen System mit unseres zusammenarbeiten könnte. Im Extremfall mussten wir aber eine Schicht zwischen beiden Systemen bilden, um unser System vor unerwünschten Änderungen und Überlaufeffekte zu schützen.
- usw.
Nachdem die Product-Backlog-Einträge aufgestellt wurden, mussten Arbeitspakete, die mit in den ersten Sprint implementiert werden würden, im Rahmen des Sprint Plannings aufgenommen werden. Dazu wurde der Aufwand von den Aufgaben mittels „Planning Poker“ geschätzt. Es wurde solange geschätzt, bis die ganz links im Whiteboard-befindlichen „Story Points“ erreicht wurden. Diese Story Points repräsentierten den relativen erforderten Aufwand, die das Team sich für den Sprint vorgenommen hatte. Zum Abschluss der Planung legten wir uns als Entwicklerteam einen verbindlichen Ziel pro Sprint wie z. B. „Integration von Prox mit Umsystemen“.
In Scrum müssen alle Teammitglieder ein gemeinsames Verständnis (Definition of Done) haben wann ein Arbeitspaket als fertig zu betrachten ist. Dies gewährleistet Transparenz. Unser Team hat folgende Definition of Done (DoD) aufgestellt:
- Entscheidungsprotokoll pflegen
- Dokumentation ist vorhanden, vollständig und gegengelesen
- Codebasis ist (inkl. vorhandene Testausführung) in die CI-Pipeline integriert → Build ist durchgelaufen (grün)
- Governance mit Product Owner + Stakeholder abgeklärt
- Neuer Code ist soweit es geht getestet (entweder Unit Test, Integration Tests und Runtime Tests)
- Implementierung ist funktional korrekt, es sind alle Sub-Tasks erfüllt
- Einhaltung des Code Styleguides
