Wenn ihr in Softwareprojekten unterwegs seid, wird bei Euch wahrscheinlich auch die Umsetzung in irgendeiner Weise geplant. Bei der Projektplanung, auf der übergeordneten Ebene gibt es vielleicht so etwas wie einen Meilensteinplan, wo mit einem Horizont von einigen Wochen oder Monaten aufgetragen ist, was in welcher Reihenfolge erreicht werden soll. Auf der feingranulareren Ebene, bei der Planung der Umsetzung, arbeiten die Entwicklungsteams vielleicht mit Backlogs und schreiben zur Umsetzung von Features oder Anforderungen User Stories, um diese als Entwicklungsaufgaben einzuplanen.

Konzeptarbeit in Softwareprojekten

Nur in seltenen Fällen ist es empfehlenswert, basierend auf Anforderungen direkt Umsetzungsaufgaben zu definieren, denn: Zwischen Anforderungen und Implementierung gehört Engineering und dieses Engineering heißt Softwarearchitektur. Das heißt, es müssen Architekturkonzepte (oder auch Lösungskonzepte) entwickelt werden, mit denen wir definieren, wie zentrale Aspekte im System grundsätzlich funktionieren. Und das, möglichst bevor wir Code schreiben. Die Konzepte können fachlicher Natur sein, um Sachverhalte aus der Domäne und deren Abbildung in die Technik zu beschreiben; sie sind damit sehr nah an der Umsetzung von einzelnen Features dran (Beispiel: Was ist ein Journal in der Finanzbuchhaltung, wie muss die technische Umsetzung im System funktionieren?). Oder es können Qualitätskonzepte sein, die beschreiben, wie bestimmte Qualitätsanforderungen im System erfüllt werden sollen (Beispiel: Skalierungskonzept). Oder aber es können technische Konzepte sein, die technische Funktionsweisen in einer grundsätzlichen und einheitlichen Weise für das System beschreiben (Beispiel: Logging-Konzept).

Ein gutes Architekturkonzept zu entwickeln, das einen passenden Lösungsansatz definiert, der gut zu verstehen ist und zu Konsistenz und Einheitlichkeit im System beiträgt, ist keine einfache Aufgabe. Sie erfordert durchaus einiges an Zeit und Aufwand; der ist hier aber äußerst gut investiert. Die darin enthaltenen Entscheidungen, müssen nämlich in jedem Fall getroffen werden, spätestens wenn Code geschrieben wird. Dies aber explizit, im Rahmen von Konzeptarbeit zu tun, hat den Vorteil, dass man für eine gegebene Problemstellung einen Lösungsansatz mit Blick auf das Gesamtsystem entwickeln kann und nicht nur implizit, im Rahmen einer Entwicklungsaufgabe, quasi so nebenbei mit Scheuklappen auf. Einheitliche Ansätze, die gleiche Probleme immer wieder auf die gleiche Weise lösen, tragen ganz substanziell zu Verständlichkeit und damit zur Wartbarkeit des Systems bei. Das beschleunigt die Umsetzung und macht das System langlebig.

Konzeptarbeit muss geplant werden

Wenn also die Entwicklung von Konzepten eine eigenständige Aufgabe im Entwicklungsprojekt ist, dann muss sie bei der Planung der Umsetzung auch als solche behandelt werden, denn sie erfordert Ressourcen (Leute müssen daran arbeiten) und sie hat Abhängigkeiten zu anderen Aufgaben (das Konzept bildet die Grundlage für die Umsetzung). Trotzdem sehen wir in unseren Projekten immer wieder eine starke Zentrierung auf rein funktionale Aspekte bei der Projekt- und Umsetzungsplanung. Das ist ungeschickt, denn wenn so wichtige und umfangreiche Tätigkeiten außen vorgelassen werden, wird der Plan unnötig ungenau und büßt ein gutes Stück seines eigentlichen Mehrwerts ein. Deswegen ist es äußerst empfehlenswert, Konzeptarbeit in der Projekt- und Umsetzungsplanung explizit zu machen.

Wie geht das?

Wie plant man nun aber die Arbeit an Architekturkonzepten ein?

In der (grobgranularen) Projektplanung ist das ziemlich simpel: Man integriert die Arbeit an Konzepten und die zu erarbeitenden Ergebnisse explizit in den Projektplan und beachtet dabei Abhängigkeiten zu anderen Aufgaben im Projekt. Dazu braucht man natürlich eine Übersicht, welche Konzepte insgesamt entwickelt werden müssen. Um die zu erstellen, hilft die oben genannte Einteilung: fachliche, technische und Qualitätskonzepte. In jedem dieser Bereiche kann man sich fragen, was für das System, an dem man gerade arbeitet, die zentralen Aspekte sind, die geklärt, definiert und verstanden werden müssen. Eine solche Sammlung muss man natürlich nicht auf einmal und vollständig am Anfang machen, sondern kontinuierlich und sukzessive im Projektverlauf, getrieben durch die jeweils aktuellen Prioritäten und Aufgaben.

Für die (feingranulare) Umsetzungsplanung bedeutet das, eigenständige Aufgaben zur Entwicklung von Architekturkonzepten (beispielsweise) in das Backlog aufzunehmen und entsprechend bei der Umsetzung zu berücksichtigen. Diese Aufgaben stehen dann neben den typischen User Stories (oder ähnlichen Work Items), mit denen die Backlogs normalerweise gefüllt sind. Während des Plannings können diese dann eingeplant und (beispielsweise während des Sprints) bearbeitet werden, wie die sonstigen Aufgaben auch.

Gibt es eine vom Entwicklungsteam separierte Gruppe von Fachexpert:innen oder Architekt:innen, die beispielsweise für die Entwicklung von fachlichen Konzepten verantwortlich ist, würden sie analog die Arbeit an Konzepten in ihre eigene Aufgabenplanung einbeziehen. Unter Umständen könnte es in so einem Fall auch sinnvoll sein, ein dediziertes Konzeptarbeit-Backlog aufzubauen.

Bei der Beschreibung der Aufgabe zur Entwicklung sollten die folgenden Aspekte berücksichtigt werden:

• Hintergrund und Zielstellung: Es sollte eine kurze, dabei aber präzise Beschreibung enthalten sein, warum das Konzept benötigt wird und wofür eine Lösung entwickelt werden soll.
• Anforderungen: Je nach Konzept sind die Anforderungen, die das Konzept erfüllen soll, schon irgendwo aufgeschrieben, dann können sie verlinkt werden, oder sie müssen als Teil der Konzeptentwicklung noch weiter herausgearbeitet werden, dann ist deren Erarbeitung Teil der Akzeptanzkriterien.
• Zu berücksichtigende Aspekte und zu beantwortende Fragestellungen: Es sollte eine Auflistung der Fragestellungen enthalten sein, die das Lösungskonzept beantworten soll.
• Akzeptanzkriterien / Definition of Done: Für Umsetzungsaufgaben werden spezifische Akzeptanzkriterien definiert, oder, als Definition of Done, eine Liste von Tätigkeiten, die grundsätzlich immer erfüllt sein müssen. Dies sollte analog auch für Aufgaben zur Erarbeitung von Konzepten getan werden. Typische Punkte, die hier verwendet werden können sind beispielsweise:
  • Das Konzept beschreibt klar die Zielstellung und die zu erfüllenden Anforderungen
  • Das Konzept erfüllt die zugrundeliegenden Anforderungen
  • Das Konzept beantwortet die in der Aufgabenstellung beschriebenen Fragestellungen
  • Die Konzeptidee wurde dem Team / relevanten Stakeholder:innen vorgestellt und Feedback eingearbeitet
  • Das Konzept wurde im Wiki dokumentiert und gereviewt
  • Das Konzept zeigt und beschreibt explizit die getroffenen Entwurfsentscheidungen
• Abhängigkeiten: Abhängigkeiten zu anderen Aufgaben sollten angegeben werden. Dies ist beispielsweise der Fall, wenn Umsetzungsaufgaben erst begonnen werden können, wenn ein zugrundeliegendes Konzept fertiggestellt wurde.

Zur Veranschaulichung, hier ein (zur besseren Verständlichkeit eher kleines und für das System eher unspezifisches) Beispiel:

Konzept-Task: Logging-Konzept

Wir wollen einen einheitlichen Logging-Ansatz für das System etablieren, so dass Logs in einer einheitlichen Weise erzeugt werden und über einen zentralen Mechanismus zugreifbar werden. Dafür soll ein Konzept entwickelt werden, das die hier dokumentierten Anforderungen [LINK] erfüllt.

Das Konzept soll mindestens die folgenden Fragestellungen beantworten:

• Wie werden technische und fachliche Logging-Informationen differenziert?
• Welche Logging-Technologie wird verwendet und welche Konfiguration muss vorgenommen werden?
• Wie werden Log-Nachrichten generiert?
• Welche Logging-Level werden für was verwendet?
• Wie ist das Format und die Struktur von Log-Nachrichten?
• Welche Informationen sind standardmäßig in jeder Lognachricht enthalten?
• Wie ist der Datenfluss der Log-Nachrichten im System?
• Wo werden Logs in welcher Weise gespeichert?
• Wer hat in welcher Weise Zugriff auf die generierten Logs?
• Welche Arten von Log-Analysen werden unterstützt?

Akzeptanzkriterien

• Das Konzept beschreibt Hintergründe und Zielstellung
• Das Konzept erfüllt die hier [LINK] dokumentierten Anforderungen
• Das Konzept beantwortet die genannten Fragestellungen
• Die Konzeptidee wurde im Entwicklungsteam vorgestellt und als geeignet akzeptiert
• Das Konzept wurde im Confluence dokumentiert und gereviewt

Wie Ihr seht, steckt auch bei einem rein technischen und recht übersichtlichen Thema wie Logging durchaus einige Tiefe, und man kann und sollte für die Ausarbeitung eines passenden Lösungsansatzes auch unbedingt einige Zeit einplanen. Und die dazugehörige Aufgabe muss das reflektieren.

Fazit

Konzeptarbeit ist eine zentrale Aufgabe in Softwareprojekten. Um zu realistischen Plänen auf Ebene des Gesamtprojektes und der Umsetzung zu kommen, müssen Aufgaben zur Entwicklung von Lösungskonzepten in den Plänen explizit berücksichtigt werden. Plant diese Arbeit ein und investiert in gute Konzepte. Wie meine Oma gerne sagte: „Bub, streng Dich an, es lohnt sich.“