OBJ_WaehrendeinesSprints

02 | Während des Sprints

So läufts bei uns @Objectbay

Während eines Sprints gilt als vereinbart, dass sich die für diesen Sprint eingeplanten oder begonnenen Elemente nicht mehr ändern dürfen (außer minimalen Anpassungen). Der Product Owner und das Entwicklungsteam arbeiten auch während der Umsetzung im Sprint eng zusammen, um Feedback und Details zeitnah abstimmen zu können.

Das Entwicklungsteam setzt eine User Story nach der anderen vollständig und fertig im Sinne der „Definition of Done“ um und versucht weitestgehend, parallele Arbeiten zu vermeiden. Damit wird bereits sehr früh in einem Sprint die erste User Story fertig. In unserem Entwicklungsprozess wird für jede fertiggestellte User Story die gesamte in Entwicklung befindliche Software hinsichtlich folgender Kriterien geprüft:

  • Getesteter und fehlerfreier Code: Wir entwickeln weitestgehend, wo möglich und sinnvoll mittels „testgetriebener Entwicklung“, d.h. wir automatisieren das funktionale Testen des entwickelten Codes. Entwicklungsfehler („Bugs“) werden so sehr zeitnah gefunden und gelöst. In unserer „Definition of Done" ist selbstverständlich enthalten, dass der Code frei von bekannten Fehlern ist. Wir betrachten aber auch die laufend ermittelten Metriken, wie z.B.: die „Testabdeckung“ der automatisierten Tests, um die Testqualität maximal hoch zu halten. Diese Kennzahlen werden auch am Kunden- bzw. Projekt-Dashboard angezeigt.
  • Code-Reviews: Im Zuge von laufend stattfindenden Code-Reviews wird die Quellcodebasis hinsichtlich der Einhaltung der Prinzipien von Clean Code untersucht. Wir ermitteln mit jedem Build mehrmals täglich eine ganze Reihe von Kennzahlen, darunter z.B. die Komplexität der Software, Laufzeitverhalten, Speicherverbrauch etc., um stets Transparenz über die Code-Qualität zu haben. Diese Kennzahlen werden ebenfalls am Kunden- bzw. Projekt-Dashboard angezeigt.
  • Architektur: Neben den gemeinsamen Designsitzungen des Teams finden auch regelmäßige Architektur-Reviews statt, in der die Software auf saubere Architekturmuster und -typen hin untersucht wird. Diese dienen letztendlich auch der Wartbarkeit und Änderbarkeit der Software. Architektonische Änderungen werden rasch entdeckt und in Form von kleinen „Refactorings“ dem Entwicklungsprozess zugeführt.
  • Performance: Auch wenn keine expliziten Nicht-funktionalen Anforderungen dazu definiert wurden, überprüfen wir die Software regelmäßig im Sinne von Last, Skalierbarkeit und Speicherverhalten, um eventuelle Schwachstellen diesbezüglich rasch feststellen und beheben zu können.
  • Security: Analog dazu überprüfen wir unsere Entwicklung laufend hinsichtlich der aktuellen Security-Richtlinien, darunter z.B. die „OWASP Top 10 Most Critical Web Application Security Risks“.

Wird eine User Story dann nach erfolgreicher, teaminterner Überprüfung als „Fertig“ („Done“) markiert, wird die Funktionalität sofort und automatisiert in einer produktionsähnlichen Systemumgebung zur Verfügung gestellt. Wir verwenden dazu zwei Systemumgebungen, UAT und CAT in unserem Staging, welche unser Continuous Integration & Delivery-System für jeden Entwicklungsstand automatisiert bereitstellt, wodurch der Fortschritt der Entwicklung quasi live mitverfolgt werden kann.

- Auf der “UAT” („User Acceptance Testing“) bezeichneten Systemumgebung werden finale Tests ausgeführt. Sie dient dem Team und dem Product Owner während des Sprints als Referenzplattform zur Überprüfung des Sprint-Ziels. Eine fertig gestellte User Story landet zunächst hier zur Begutachtung. Diese Systemumgebung ist „produktionsnah“ im Sinne von Aufbau und Daten.

- Auf der „CAT“ („Customer Acceptance Testing“) genannten Umgebung wird am Ende eines Sprints ein jeweils von allen Seiten akzeptierter Stand der Entwicklung auf Basis der UAT verfügbar gemacht. Diese Umgebung dient auch als Basis für die gemeinsame Begutachtung des Projektfortschritts und steht dem Kunden während der Projektlaufzeit für eigene Testzwecke zur Verfügung. Diese Umgebung ist gleich aufgebaut wie die Produktivumgebung und enthält (wenn zulässig) Produktivdaten, um das System in einem möglichst realistischen Kontext verfügbar zu machen.

Mehr dazu erfahren Sie gerne auf Anfrage via office@objectbay.com