Entwicklung

Die Entwicklungsphase, manchmal auch Implementierung genannt, klärt, wie die Lösung robust umgesetzt wird. Das entworfene System wird dabei in lauffähigen Code überführt, im Idealfall iterativ, mit kurzen Feedbackschleifen zwischen Entwicklung, Design und Fachbereich, statt in einem langen, stillen Tunnel.

Diese Phase wird häufig mit Softwareentwicklung insgesamt gleichgesetzt, dabei ist sie nur eine von sieben Phasen. Sie ist die sichtbarste, aber selten die, die über Erfolg oder Misserfolg eines Projekts entscheidet.

Was in der Entwicklungsphase geklärt wird

Vier Bereiche bestimmen, wie robust eine Umsetzung wird:

• Umsetzung: Wie wird der Entwurf konkret in Code übersetzt, mit welchen Bausteinen und Mustern?
• Codequalität: Welche Standards gelten für Lesbarkeit, Tests und Reviews und wie werden sie durchgesetzt?
• Technische Schulden: Welche bewussten Kompromisse werden eingegangen und wie werden sie sichtbar gemacht?
• Zusammenarbeit: Wie arbeiten mehrere Entwicklerinnen und Entwickler am selben Code, ohne sich gegenseitig zu blockieren?

Wie diese vier Bereiche gelebt werden, entscheidet sich selten in offiziellen Meetings. Meist zeigt es sich in alltäglichen Kleinigkeiten: in dem, was ein Code-Review durchwinkt, und in dem, was ein Entwickler klaglos noch schnell selbst repariert, statt es anzusprechen.

Wer typischerweise beteiligt ist

Entwicklerinnen und Entwickler setzen den Entwurf um und treffen dabei fortlaufend kleinere technische Entscheidungen, die im Design nie im Detail vorgegeben waren. Die technische Leitung oder erfahrene Kolleginnen und Kollegen sichern über Code-Reviews die Qualität ab und sorgen dafür, dass Standards nicht nur auf dem Papier existieren. Product Owner und Fachbereich bleiben ansprechbar für Rückfragen, die während der Umsetzung entstehen, denn nicht jede Detailfrage lässt sich in der Analyse vorwegnehmen. QA wird häufig schon hier einbezogen, damit Code von Anfang an testbar entsteht, statt erst nachträglich testbar gemacht zu werden.

Typische Risiken

Technische Schulden entstehen in dieser Phase zwangsläufig. Entscheidend ist, ob sie bewusst gesteuert oder verdrängt werden. Wenn Entwicklung allein auf Geschwindigkeit optimiert wird, wachsen Schulden und Wissensinseln unbemerkt mit. Spätere Änderungen werden dann überproportional teuer und riskant, weil niemand mehr genau weiß, warum eine Stelle im Code so aussieht, wie sie aussieht.

Was am Ende vorliegen sollte: Übergabe an den Test

Übergabeartefakt	Warum es zählt
Lauffähiger, reviewter Code	Grundlage für jede weitere Testaktivität
Automatisierte Tests auf Unit- und Integrationsebene	Reduziert die Last rein manueller Prüfung im Test
Dokumentierte bewusste Kompromisse	Erklärt, warum der Code so aussieht, wie er aussieht
Bekannte offene Punkte und technische Schulden	Verhindert, dass der Test sie fälschlich als neuen Fehler einstuft
Nutzbare Test- oder Staging-Umgebung	Ermöglicht Prüfung unter realistischen Bedingungen

Was hier unausgesprochen bleibt, taucht im Test meist als Überraschung wieder auf, nur mit höheren Kosten für die Klärung.

Fragen, die sich alle Beteiligten stellen sollten

• Wie wird Qualität abgesichert, durch wiederholbare Praktiken wie Code-Reviews und automatisierte Tests, oder durch den guten Willen Einzelner?
• Ist für Nicht-Techniker nachvollziehbar, wann und warum technische Schulden bewusst in Kauf genommen werden?

Auch Management und Product Owner profitieren davon, technische Schulden als bewusste, terminierbare Entscheidung zu verstehen, statt als unsichtbares Risiko, das irgendwann unangekündigt fällig wird.

Im Beispiel: Ablösung des Ticketsystems

In der Entwicklungsphase unseres Beispiels zur Systemablösung entsteht der Code, der die in Design und Analyse erarbeiteten Konzepte technisch umsetzt. Hier zeigt sich, ob die vorherigen Phasen genug Klarheit geschaffen haben, um zügig und robust zu bauen, oder ob offene Fragen die Entwicklung immer wieder ausbremsen.