Kommunikation, Flow, Automatisierung: Unsere Projektarchitektur

Unter Projektarchitektur verstehen wir die wesentlichen Aspekte der Organisation des Projekts im Hinblick darauf, wie die Projektziele am besten zu erreichen sind.

Projektarchitektur dient der Erreichung der Projektziele

Projektziele sind dabei natürlich in erster Linie inhaltliche Ziele wie eine technische Modernisierung oder ein gestalterischer Relaunch. Ein wichtiges Projektziel ist aber regelmäßig auch ein möglichst effizienter Ressourceneinsatz und in der Folge eine möglichst kostengünstige Umsetzung, möglichst viele Funktionalitäten bei einem vorgegebenen Budget oder allgemein möglichst wenig Verschwendung.

Dafür möchten wir einerseits möglichst wenige Ressourcen in eine detaillierte Planung und allgemein umfangreiches Projektmanagement stecken, aber zugleich auch Reibungsluste durch Missverständisse oder Konflikte vermeiden. Dafür kommt es auf vor allem auf erfolgreiche Kommunikation an. Dazu später mehr.

Agile Softwareentwicklung

Wir gehen bei allen Entwicklungsprojekten nach den Prinzipien der agilen Softwareentwicklung vor. Agil bedeutet reaktionsfähig und wendig, und es geht dabei insbesondere um die menschlichen, nicht-technischen Erfolgsfaktoren eines Projekts.

Einer dieser Faktoren ist, dass man während der Projektumsetzung unweigerlich zu neuen Erkenntnissen kommt – also alle Beteiligten im Projekt lernen – und man daher das Projekt so organisieren sollte, dass diese neuen Erkenntnisse ohne aufwändige Umplanung auch in der Umsetzung berücksichtigt werden können.

Ein weiterer wichtiger Aspekt ist, dass direkte und persönliche Kommunikation der beste Weg für die Vermittlung von komplexen Sachverhalten ist und daher die Auftraggeber eines Projekts auch regelmäßig in direktem Kontakt mit den Entwicklern stehen sollten. Darauf gehe ich gleich noch ein.

Flow-Orientierung und Kanban

In unseren Projekten hat sich eine flow-orientierte Vorgehensweise in kleinen Schritten besonders bewährt. Das bedeutet, dass wir die Entwicklungsaufgaben möglichst nacheinander angehen und so strukturieren, dass wir regelmäßig Zwischenschritte abschließen können. Je weniger Aufgaben gleichzeitig in Arbeit sind, desto flüssiger läuft das Projekt. Und umgekehrt: Je mehr Aufgaben parallel angegangen werden, desto leichter entsteht Durcheinander und desto weniger Fokus haben alle Projektbeteiligten.

Um das Projekt im Alltag zu steuern nutzen wir ein sogenanntes Kanban-Board, auf dem man zugleich auch jederzeit den Projektstatus sehen kann.

Auf einem Kanban-Board (Kanban ist japanisch und bedeutet soviel wie Karte, Tafel oder Beleg) werden alle Projektaufgaben als Karten dargestellt. Die Karten sind in Spalten organisiert, wobei jede Spalte für einen Zustand der Aufgabe steht. Es gibt mindestens eine Spalte für noch nicht begonnene Aufgaben (Todo), eine Spalte für Aufgaben, die angefangen sind (Doing) und eine Spalte für abgeschlossene Aufgaben (Done). Je nach den Anforderungen des einzelnen Projekts kann es noch eine Reihe weiterer Spalten geben. Für uns haben sich in den letzten Projekten z. B. Spalten für „Wartet auf Budgetfreigabe“ und „Wartet auf Abnahme“ bewährt.

In der Spalte „Wartet auf Abnahme“ liegen alle Aufgaben, die aus unserer Sicht fertig sind. Unser CI-System richtet für jede Aufgabe automatisch einen Testserver ein, den wir unseren Kunden dann schicken und auf dem sie sich die Website mit genau dieser Änderung anschauen können. Wenn es keine Änderungswünsche gibt, nimmt unsere Ansprechperson die Aufgabe ab und wir bringen sie per Knopfdruck auf den Liveserver. Anschließend wandert die Karte in „Done“.

Das Kanban-Board hilft uns bei der Fokussierung, denn es zeigt ganz klar, welche Aufgaben gerade in Arbeit sind. Die Grundregel ist, dass Aufgaben, die bereits angefangen sind, abgeschlossen werden sollten, bevor neue Aufgaben begonnen werden.

Kommunikationsstrukturen: Mischung aus persönlich und schriftlich

Vorhin habe die die Bedeutung guter Kommunikation für den Projekterfolg erwähnt. Daher möchte ich jetzt unsere Kommunikations-Strukturen für Projekte vorstellen.

Wie schon gesagt, legen wir Wert auf möglichst direkte Kommunikation zwischen unseren Entwickler:innen und unseren Kund:innen.

Aufgabe des Projektmanagements ist bei uns die Moderation der Kommunikation und die Steuerung des Projekts, aber nicht die Weitergabe von Informationen vom Entwicklungsteam zu Kunden und von Kunden zum Entwicklungsteam. Denn das führt leicht zu "Stille Post"-Effekten und nicht zu optimalen Lösungen.

Wir setzen sowohl auf schriftliche Kommunikation als auch auf persönliche Kommunikation in Videokonferenzen.

Soviel wie möglich versuchen wir schriftlich zu klären, denn das ist in vielen Fällen sehr effizient und vor allem asynchron – mit asynchron meinen wir, dass das Senden und Empfangen einer Nachricht nicht gleichzeitig passieren muss. Wir können also eine Nachricht zu einem beliebigen Zeitpunkt senden und unsere Ansprechpersonen können uns bei passender Gelegenheit antworten, ohne dass wir uns dafür verabreden müssen. Schriftliche Kommunikation ist zudem automatisch auch Dokumentation.

Jours Fixes für effiziente persönliche Abstimmungen

Gleichzeitig ist aber auch das Potenzial für Missverständnisse in der schriftlichen Kommunikation am größten und man bekommt zudem kein direktes Feedback, ob das Gegenüber die Nachricht verstanden hat. Daher vereinbaren wir in Projekten feste Termine für Videokonferenzen, um Themen zu besprechen, die von einem persönlichen Austausch profitieren. Ein typischer Jour Fixe-Termin wäre z. B. jede Woche Dienstags um 14:30 oder auch jeden Donnerstag um 10:30. Die festen Termine haben den Vorteil, dass wir Zeitaufwand und Verzögerungen verhindern, die sich ergeben, wenn jeder Abstimmungstermin einzeln abgestimmt werden muss. Die Regelmäßigkeit führt zudem dazu, dass die meisten Themen, für die es eine persönliche Abstimmung braucht, bis zum nächsten Termin warten können und keine Ad-Hoc-Besprechungen nötig sind.

An den Jours Fixes nimmt von unserer Seite der oder die Projektverantwortliche teil sowie der oder die Entwickler:innen, die an den Themen arbeiten, die im jeweiligen Termin besprochen werden sollen. Dadurch ist eine direkte Kommunikation zwischen Entwickler:innen und Auftraggeber:innen bei komplexen Themen sichergestellt. Auch von Auftraggeberseite sind alle Personen in den Jours Fixes willkommen, die Wissen zum Thema beisteuern können oder Interesse an der Entscheidung haben.

Was uns in dem Zusammenhang wichtig ist, ist, dass wir eine feste Ansprechperson auf Seiten der Auftraggeber haben, die hauptsächlich mit uns kommuniziert und regelmäßig bei den Jours Fixes anwesend ist. Unsere Ansprechperson sollte entscheidungs- und weisungsbefugt sein. Es sollte also in der Regel möglich sein, mit dieser Person in den Jours Fixes Aufgaben und Probleme zu besprechen und gemeinsam zu einer verlässlichen Entscheidung zu kommen.

Es spricht nichts dagegen, dass es auch mehr als eine Ansprechperson gibt, aber es sollte mindestens einen "Stabilitätsanker" geben.

Übrigens: In unserem Projektprozess gibt es keine Zwischenpräsentationen vor größeren Gremien wie zum Beispiel einem Lenkungsausschuss. Alle am Projekt Interessierten können sich den Stand auf dem Kanban-Board und auf den Testservern anschauen und gerne an Jours Fixes teilnehmen.

Schriftliche Kommunikation im Projekt über GitHub

Für die schriftliche Kommunikation in Projekten nutzen wir die Plattform GitHub. In GitHub wird der Quellcode des Systems verwaltet und es ist gleichzeitig eine Projektmanagement- und Kommunikationsplattform. Wir nutzen GitHub zur Strukturierung der Aufgaben, zur Abstimmung von Details und zur Freigabe fertiger Funktionalitäten durch unsere Kundinnen und Kunden – auch unsere Kanban-Boards leben in GitHub.

In GitHub haben alle Projektbeteiligten haben Einblick in die Kommunikation. Alle Entscheidungen und Entscheidungsgründe sind dort dann dokumentiert und nachvollziehbar.

Im folgenden Screenshot aus einem fiktiven Projekt sehen Sie, wie die Freigabe eines Features über GitHub erfolgt: Wir teilen unserer Kundin mit, dass der Projektschritt „Frontend-Basiseinrichtung inkl. Basislayout und Stilen“ bereit zur Abnahme ist, und nennen ihr eine Testserver-Adresse, auf der sie den Stand anschauen kann. Sie meldet sich daraufhin mit einem Änderungswunsch zurück, den wir auf einem neuen Testserver zeigen. Sie entscheidet sich schließlich für die geänderte Version und nimmt die Umsetzung ab.

Effiziente Prozesse durch Automatisierung

Ein wichtiger Aspekt in unserer Projektarchitektur ist auch die Nutzung von Automatisierung. Wie schon ein paar Mal angeklungen ist, wird für jede Änderung und jedes neue Feature ganz automatisch ein Testserver eingerichtet, auf dem die Website voll funktionsfähig und mit genau dieser Änderung zu sehen ist. Auf dieser Basis können sowohl Kolleg:innen als auch Auftraggeber:innen dann einfach beurteilen, ob aus ihrer Sicht alles korrekt umgesetzt ist.

Die automatische Einrichtung von Testservern hat eine ganze Reihe von Vorteilen:

• Wir sparen das Budget, das früher für die manuelle Einrichtung von Testservern nötig war.
• Durch die Automatisierung bekommen wir auch für kleine Änderungen jeweils eigene Testserver und können diese vor dem Launch perfekt mit unseren Kund:innen abstimmen. Das erleichtert die Kommunikation und verhindert Missverständnisse.
• Die Abstimmung erfolgt sehr fokussiert: Auf jedem Testserver ist genau ein Feature oder eine Änderung zu sehen und genau diese Änderung kann abgenommen werden (bei größeren Relaunches arbeiten wir zusätzlich mit einem Relaunch-Testserver, auf dem alle bereits abgenommenen Änderungen gesammelt zu sehen sind)

Darüber hinaus durchläuft jede Codeänderung auch verschiedene automatisierte Tests, über die wir sicherstellen, dass auch mit dem geänderten Code alles noch so funktioniert, wie es soll.

Wenn eine Änderung abgenommen ist, wird der neue Codestand auch automatisch und ohne manuellen Aufwand in den Livebetrieb übernommen.

Risiken aktiv steuern

Last but not least betreiben wir ein bewusstes Risikomanagement. Bei allen Planungsentscheidungen und insbesondere bei der Aufgabenpriorisierung berücksichtigen wir das Risiko für das Gesamtprojekt und den Zeitplan.

Wenn wir eine Aufgabe als besonders risikobehaftet ansehen, planen wir sie früh im Projekt ein, um noch einen möglichst großen Handlungsspielraum zu haben. Ein Risiko kann beispielsweise sein, dass der Umsetzungsaufwand schwer einzuschätzen ist. Oder aber die Machbarkeit ist gar nicht sicher, dann ist es wichtig, noch Zeit für Alternativpläne zu haben.

Als weitere Maßnahme des Risikomanagements nutzen wir Code Reviews und Pair Programming. Bei einem Code Review schaut sich eine zweite Entwicklerin den Code eines Entwicklers an, um zu prüfen, ob dieser gut verständlich und korrekt ist. Dadurch findet automatisch auch ein Wissenstransfer statt und das Wissen über den Code ist in zwei Köpfen. Gleiches gilt für das Pair Programming, bei dem zwei Entwickler:innen gemeinsam an einem Feature arbeiten. Häufig kommen zwei Köpfe gemeinsam zu besseren Lösungen als einer alleine und auch hier findet automatisch Wissenstransfer statt.

So ist sichergestellt, dass wir auch in Krankheitsfällen immer weiterarbeiten können.

Kontinuierliche Weiterentwicklung

Unsere Projektarchitektur entwickeln wir behutsam, aber kontinuierlich von Projekt zu Projekt weiter. Kanban setzen wir seit 2015 für die Projektsteuerung ein. 2017 haben wir begonnen, in Projekten regelmäßige Jour Fixes anstelle von Ad-Hoc-Anrufen zu etablieren. 2021 haben wir dann begonnen, unseren Kunden Zugriff auf ihr Quellcode-Repository bei GitHub zu geben und GitHub auch zur Verwaltung und Abstimmung von Aufgaben zu nutzen. In den Jahren darauf haben wir unsere teaminternen Arbeitsabläufe so angepasst, dass wir den großen Nutzen von Pull Requests in unseren Projekten realisieren konnten. Und schließlich haben wir dann in 2022 zunächst für alle Liveserver automatische Deployments eingerichtet und die Deployment-Automatisierung bis 2024 sukzessive auch auf Testserver-Deployments für Pull Requests erweitert.

Wir haben noch viele Ideen, wie wir unsere Projektarchitektur weiterentwickeln können – ich bin gespannt, welche wir als nächstes realisieren.