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.  Die "Definition of Done" ist somit eine Checkliste, welche Qualitätskriterien enthält, die erfüllt sein müssen, um ein Feature als fertig anzusehen. Damit wird bereits sehr früh in einem Sprint die erste User Story fertig. Im Entwicklungsprozess wird für jede fertiggestellte User Story die gesamte in Entwicklung befindliche Software hinsichtlich Kriterien geprüft. 

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.

Welche Kriterien muss die Software erfüllen, damit sie fertig im Sinne der "Definition of Done" ist?

• 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 hochzuhalten. 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 Design-Sitzungen 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“.

Was ist ein Beispiel für die "Definition of Done"? 

• Alle Akzeptanzkriterien der User Story sind erfüllt und automatisch testbar. 
• Die Build Pipeline ist grün. 
• Ein Code Review nach dem 4-Augen Prinzip wurde durchgeführt. 
• Die Software ist frei von bekannten Fehlern. 
• Es wurde erfolgreich auf die Testumgebung und auf die Integrationsumgebung deployed.
  

Was passiert wenn eine User Story als "fertig" markiert ist? 

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.

UAT - User Acceptance Testing 

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.

CAT - Customer Acceptance Testing 

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.

Was am Ende des Sprints abläuft, erfahren Sie im folgenden Blog Beitrag!

Wir bei Objectbay verstehen uns als Ihr Digitalisierungs-Partner im Kontext Individualsoftware. Von der Idee zum fertigen Produkt, wir liefern end2end und unterstützen unsere Kunden

• bei der Modernisierung oder Erweiterungen bestehender digitaler Lösungen
• beim Ablösen veralteter Individual Software durch neue Frameworks
• bei der Entwicklung völlig neuer digitaler Produkte, Services und Anwendungen

‍

‍

Wissen Sie was Ihre Nutzer wirklich wollen?

Mit User Story Mapping können Sie das in 4 einfachen Schritten herausfinden!

‍