So läufts bei uns @Objectbay

Zu Beginn eines Projektes erarbeiten wir gemeinsam mit unseren Kunden eine gemeinsame Sicht auf die wesentlichen Projektziele. Je nach Ausgangssituation liegen bereits einige Anforderungen vor, in der Regel sind diese jedoch nicht ausführlich spezifiziert – was nicht nur völlig in Ordnung, sondern auch gewünscht ist. Für unsere Zusammenarbeit ist vor allem wichtig, dass wir die Idee, die Ziele, die Erwartungshaltungen und das zentrale Nutzenversprechen verstehen und diese gemeinsam mit dem Kunden schärfen. Darüber hinaus ist es wichtig, dass die Rollenverteilung im Projekt von Anfang an klar vereinbart wird.

Unser Konzept sieht vor, dass bei der Erstellung und dem Management von Anforderungen (Requirements-Management) Kunde und Entwicklungsteam eng zusammenarbeiten. In Scrum ist dabei die Rolle des „Product Owners“ vorgesehen, die in der Regel vom Kunden besetzt wird. Die Zusammenarbeit wird einerseits mittels persönlicher Kommunikation (bzw. durch Videokonferenzen im Falle von größeren Entfernungen) und andererseits mittels den (in der Regel) von uns bereit gestellten Werkzeugen (Backlog-Management, Dashboard und Entwicklungsinfrastruktur) gestaltet. Die Rolle des Product Owners verantwortet die Sicht auf „was wird geliefert“.

Vision

In der Regel formen wir innerhalb von drei bis fünf Arbeitstagen gemeinsam eine Product Vision und erstellen das initiale Produkt-Backlog sowie ein grobes Design, sowohl optisch als auch architektonisch. In dieser initialen Phase werden erste wesentliche Entscheidungen über Systemarchitektur und Design getroffen.

Design Thinking

In vielen Projekten erweist es sich als sinnvoll, die Vision weiter zu verfeinern, um zu konkret definierten Zielen zu gelangen. Wir verwenden dazu „Design Thinking“ um mögliche Lösungswege zu finden und präsentieren Entwürfe mittels leichtgewichtiger Prototypen, mit dem Ziel die Ideen mit möglichst originalem Benutzerfeedback zu testen. Design Thinking wird üblicherweise bei Projekten eingesetzt, wo die möglichen Umsetzungsoptionen noch sehr unklar sind und kundenseitig echte Innovationen gewünscht werden.

Story Maps

Zur gemeinsamen Entwicklung eines Überblicks hinsichtlich der Anforderungen verwenden wir gerne eine weitere Technik, die die Abläufe und Wertströme einer Softwareanwendung sichtbar macht: „User Story Mapping“. Hierbei werden die Aktivitäten des Benutzers in einer Anwendung entlang des Wertstroms oder der Zeitachse auf der X-Achse visualisiert. Auf der Y-Achse werden mögliche „Ausprägungstiefen“ einzelner Funktionen, also von „rudimentär -“ bis „umfassend implementiert“ aufgetragen. Ziel ist hier, neben der Visualisierung zum Auffinden von Kernfunktionen, auch eine Priorisierung nach Geschäftsnutzen zu erarbeiten.

Domain Driven Design - Context Maps

Unsere Entwicklungsteams setzen darüber hinaus eine weltweit anerkannte und erfolgreiche Methode in der Umsetzung ein: „Domain Driven Design“. Hierbei wird dem Design eine wesentliche Rolle eingeräumt. Gemäß einem Leitsatz von Steve Jobs „Design is not what it looks like, it is how it works!“ betrachten wir die grobe Idee der Umsetzung als zentralen Schritt bevor es tatsächlich an die Umsetzung geht.

Im Domain Driven Design wird ausgehend vom Verständnis der Domäne sowie der „domaineigenen Sprache“ gemeinsam mit Domänenexperten des Kunden eine Landkarte gezeichnet, in der sogenannte „Bounded Contexts“, die für das Modellieren relevant sind, eingezeichnet werden. Hierbei werden oft auch neue Erkenntnisse über die Kontextgrenzen gewonnen. Dieser Schritt dient dazu, wesentliche Architektur- und Designentscheidungen zu treffen.

Definition of Done

Gemeinsam mit dem Kunden definieren wir die qualitativen Merkmale der Software, wann sie als „geliefert“ betrachtet werden kann. Darunter fallen Code-, Architektur- und Performancemerkmale ebenso wie Nicht-funktionale Anforderungen, z.B.: Sicherheit oder Benutzbarkeit. In jedem Fall wird diese Liste (genannt „Definition of Done“) zumindest die Punkte „lauffähig, getestet und frei von bekannten Fehlern“ enthalten. Diese Liste dient dann zur objektiven Beurteilung einer jeden Lieferung sowie als Grundlage für das Entwicklungsteam, eine Entwicklung überhaupt als „abgeschlossen“ zu bewerten. Nur solche Lieferungen werden als Fortschritt gemessen.

Bereit zum Start

Zusammengefasst entstehen in dieser initialen Projektphase neben der Vision auch das initiale Produkt-Backlog sowie eine erste, grobe Systemarchitektur. Es wird neben den Technologieentscheidungen auch darüber entschieden, welche nicht-funktionale Anforderungen an das System gestellt werden.

Iterativ-Inkrementelle Entwicklung

Eines der wichtigsten Wesensmerkmale der agilen Vorgehensweise ist die Iterativ-Inkrementelle Entwicklung. Dabei werden in kurzen Zeitabschnitten, in der Regel in zweiwöchigen Sprints, funktionsfähige "Inkremente" gemäß der „Definition of Done“ umgesetzt bzw. geliefert.  Während der Entwicklung werden Vision und Ziele im Blick behalten, jedoch nur die aktuellen bzw. unmittelbar nächsten Anforderungen im Detail betrachtet.

Das inkrementelle Vorgehen erlaubt es Details auch später, noch während der Laufzeit zu ändern und die Erkenntnisse aus den vorangegangenen Sprints in die Zukunft einfließen zu lassen. Darüber hinaus unterstützt dieses Vorgehen die Fähigkeit sich nur mit jenen Details zu beschäftigen, die auch Sinn ergeben bzw. Geschäftsnutzen erzeugen.

‍