Der Kunde im Zentrum (User Experience Design)

Am Anfang steht der Kunde. Mit Überlegungen der User Experience (UX), Nachforschungen und Prototypen erarbeiten wir die Grundlagen für die strukturierte Anforderungsentwicklung. Dabei stehen die Bedürfnisse der Kunden im Zentrum der Überlegungen. Ausserdem nutzen wir die Prototypen, um unsere Überlegungen direkt mit Kunden zu validieren. In regelmässigen Deep Dives werden die Erkenntnisse vom UX dann in das Anforderungs- und Entwicklungsteam weitergegeben. Dabei diskutieren wir auch die Machbarkeit und mögliche, einfachere Lösungsansätze.

Struktur zur Übergabe an die Entwicklung (Anforderungen)

Basierend auf den Deep Dives werden in der hierarchischen Struktur von Initiatives, Epics und Stories die funktionalen und nicht-funktionalen Anforderungen strukturiert dokumentiert. In einem Refinement Meeting, welches ein paar Tage vor dem offiziellen Start des Entwicklungssprints durchgeführt wird, erhält das Entwicklungsteam Einblick in die Anforderungen und kann Unklarheiten bis zum Sprint klären lassen.

Iterative Produktevolution (Entwicklung)

Die eigentliche Entwicklung wird in Sprints durchgeführt und dauert zwei bis vier Wochen. Im Sprint Planning priorisiert der Product Owner die Anforderungen. Basierend auf den Stories schätzt das Entwicklungsteam die Aufwände ab. In einem Sprint werden dann so viele Stories wie möglich umgesetzt.
Wichtig ist das sogenannte Definition of Done (DoD), welches festlegt, wann eine Umsetzung als abgeschlossen gilt. Als sehr erfolgreich hat sich ein DoD mit der Umsetzung der Story, der Qualitätssicherung des Codes, der Funktions- und Integrationstests herausgestellt. Die Behebung der Bugs kann dann in einem nachfolgenden Sprint durchgeführt werden. Dadurch kann zu Beginn eines Sprints auch eine verlässliche Schätzung der Aufwände ohne Timeboxed Blocker erfolgen.
Per Ende des Sprints wird das sogenannte Potentially Shippable Product Increment (PSPI) vom Entwicklungsteam geliefert. Dieses ist in der Qualität so gut, dass es, wie der Name sagt, potenziell als Release verwendet werden kann. Jedoch sind die im Sprint durchgeführten Tests oft nicht vollumfänglich (Beispiele wären Last- und Performance-Tests oderdie Browserkompatibilität bei Web Applikationen), weshalb dann trotzdem noch ein strukturiertes Testing notwendig ist.

Nachvollziehbare Qualitätssicherung (Testing)

Das PSPI wird in einer definierten Konfiguration von Releaseartefakten auf eine Testumgebung installiert. Dort werden funktionale als auch nicht-funktionale Tests durchgeführt. Sollten hier Fehler, also Bugs, gefunden werden, kommen diese ins Product Backlog und werden im Sprint Planning durch den Product Owner neben den neuen Stories entsprechend priorisiert.

Kreieren eines Releases (Release)

Ein PSPI wird für das Release gewählt. Dieses wird ausführlich getestet (beispielsweise mit zusätzlichen Regression-Tests). Danach erfolgt die Stabilisierung des Releases (Bugfixing, Retesting) und das Rollout. Die behobenen Fehler werden am Ende des Release Zyklus in den ordentlichen Entwicklungsstream zurückgeführt.

Originally appeared on TomRoethlisberger.com