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, im Sprint Planning, 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. Der Sprint ist Teil des Scrum Frameworks. Agile Softwareentwicklung nach Scrum vs. Wasserfallmodell bringt viele Vorteile, wie beispielsweise eine bessere Qualität der Software, Flexibilität bei Anpassungen oder schnellere Time-to-Market des entwickelten Produktes.

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, technische Schulden werden vermieden. 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. Hier geht es zu unserer Code Review Checkliste.
• 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.

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.
  

Wie formuliert man User Stories?

8 Punkte, die Sie bei der Erstellung beachten sollten!

‍

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.

Erfahren Sie mehr darüber wie das Sprint Review am Ende des Sprints abläuft.

Wir bei Objectbay verstehen uns als Ihr Digitalisierungs-Partner im Kontext Individualsoftware. Von der Idee zum fertigen Produkt, wir liefern end-to-end 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

‍

Kriterium: Code Review. Wie Sie schnell Ihren Code auf Qualität checken!

Hier finden Sie die konkrete Objectbay Code Review Checkliste, die Sie Schritt für Schritt durch den Review Prozess führt.

‍