6 praktische Tipps für verteiltes Arbeiten im Systems Engineering

Es braucht wohl nicht diskutiert zu werden, dass komplexe Produkte nur im Team entwickelt werden können, was häufig auf verteiltes Arbeiten hinausläuft. Ebenfalls nicht diskutiert werden muss, dass ein „Word-Dokument auf einer Dropbox“ ebenfalls nicht adäquat ist.

Inzwischen unterstützt fast jedes moderne Werkzeug der Systementwicklung die Möglichkeit, im Team zu arbeiten. Doch damit allein ist es nicht getan, sonst werden schnell veraltete Anforderungen getestet, um nur ein Beispiel zu nennen. Wenn dann noch verschiedene Werkzeuge eingesetzt werden, wird es schnell unübersichtlich.

In diesem Artikel werden die größten Probleme beim verteilten Arbeiten vorgestellt, sowie mögliche Lösungen.

1. Akzeptanz für Prozess-Werkzeug-Kombination sicherstellen!

Bei der Systementwicklung im Team müssen Prozesse und Werkzeuge sauber zusammenpassen, und das Team muss diese auch annehmen (Akzeptanz). Ohne diese drei Aspekte geht es nicht. Wenn die Prozesse nicht stimmen, kann es schnell zu inkonsistenten Datenständen kommen. Wenn das Werkzeug nicht passt, wird Arbeiten extrem ineffizient. Und die Menschen müssen beides natürlich nutzen, insbesondere, wenn verteiltes Arbeiten praktiziert wird.

Es wird oft gesagt, dass zuerst die Prozesse stehen sollten, und dann erst Werkzeuge für diese konfiguriert werden. Dem stimme ich nicht so ohne weiteres zu: Jedes vernünftige Werkzeug lässt sich – in Maßen – konfigurieren. Dabei ist es egal ob es um Anforderungsmanagement geht, Modellieren, Testen oder einen anderen Bereich im Systems Engineering. Aber trotzdem sind fast alle Werkzeuge auf „Best Practices“ ausgelegt, die sich mit dem Werkzeug besonders gut umsetzen lassen. Wenn die Prozesse grob stehen, dann sollte die Konkretisierung im Kontext des ausgewählten Werkzeuges stattfinden. Dies stellt sicher, dass das Arbeiten intuitiv ist, wodurch die Akzeptanz erhöht wird.

2. Feingranulare Versionierung

Wenn im Team gearbeitet wird, so kann es Konflikte geben, wenn zeitgleich gearbeitet wird. Die Alternative ist das Sperren von Elementen, die in Bearbeitung sind. Gerade im Team ist eine feingranulare Versionierung aus mehreren Gründen wichtig: Zum einen können einzelne Elemente gesperrt werden, was die Wahrscheinlichkeit verringert, das ein Teammitglied auf eine Freigabe warten muss. Zum anderen erlaubt dies auch einen besseren Umgang mit Änderungen (siehe Punkt 5).

3. Daten so nah wie möglich zusammenhalten

Idealerweise sind alle für die Entwicklung relevanten Daten in einer einzigen Datenbank („Single Source of Truth“). Doch in der Praxis ist dies selten realisierbar, und wenn doch, dann ist das Ergebnis selten optimal, was wiederum zu Akzeptanzproblemen führen kann. Dennoch, es ist wünschenswert, die Daten über so wenige Datenbanken wie möglich zu verteilen.

Monolithische Lösungen für die Systementwicklung halten selten, was sie versprechen. Daher lieber die passendsten Werkzeuge suchen und Daten in Echtzeit synchronisieren. Twittern

Wenn eine einzige Datenbank nicht machbar ist, dann sollten die wenigen Daten möglichst in Echtzeit synchronisiert werden. Dazu gibt es kommerzielle Integration-Hubs wie OpsHub oder Tasktop, die auch mit Synchronisationskonflikten umgehen können. Ein Integrations-Hub gibt auch gleichzeitig die Architektur einer Werkzeuglandschaft vor.

Aber auch Synchronisierung ist nicht immer möglich. Das trifft unter andrem auch auf die Zusammenarbeit mit externen Parteien (Kunden, Zulieferer) zu. Dort ist es dann wichtig, mit sauber definierten Aktualisierungsprozessen zu arbeiten (siehe Punkt 5). Hier sollte möglichst auf Standards zurückgegriffen werden, wie das ReqIF-Format für den verlustfreien Austausch von Anforderungen.

4. Branching und Merging für zeitversetzte Arbeit

Das Konzept von „Branching und Merging“ stammt aus der Softwareentwicklung. Es besagt, dass Daten kopiert, bearbeitet, und dann wieder in die Quelle zurückgeführt werden. Dabei kann es natürlich Konflikte und andere Probleme geben. Daher sollte Branching und Merging möglichst vermieden werden (siehe Punkt 3).

Es gibt aber viele Situationen, wo dies Sinn macht: Zum Beispiel beim Testen, wo die Tester arbeiten können, während die Anforderungen weiterentwickelt werden. Oder bei einem System, bei dem Hardware- und Softwareteams mit unterschiedlich langen Sprint-Zyklen arbeiten.

Als Faustregel sollte Branching & Merging vermieden werden. Wenn es aber notwendig ist, müssen die Prozesse das entsprechend unterstützen.

5. Klarer Umgang mit Änderungen

Datenmodelle sehen auf dem Papier immer so schön aus, weil sie statisch sind. Aber eine Entwicklung ist ein dynamischer Vorgang. Und damit die Teamarbeit funktioniert, muss dies auch geklärt sein. Wichtig dabei ist, die Nutzer nicht zu sehr einzuschränken, aber gleichzeitig alles in gerichtete Bahnen zu lenken.

Hier sollte unbedingt darauf geachtet werden, dass insbesondere bei Reviews auf Konsistenz geachtet wird, das muss aber nicht unbedingt bei der täglichen Arbeit eingefordert werden. (Zum Beispiel ist nichts schlimmer, als zu viele Pflichtfelder. Das führt dann nämlich nicht zu vollständigen Informationen, sondern zu nutzlosen Fülltexten!).

6. Kommunikation!

Ganz wichtig ist natürlich die Kommunikation. Wenn möglich sollte immer im Kontext von konkreten Informationen zusammengearbeitet werden. Auch dies wird von moderen Werkzeugen wie Jama, Jira oder Plattformen wie gitHub ermöglicht. Informationen in E-Mails gehen verloren und können schwer einem bestimmten Element zugeordnet werden, geschweige denn einer bestimmten Version.

Es reicht nicht, die Werkzeuge zur Verfügung zu stellen, es muss auch eine Kultur für Kommunikation gepflegt werden. Dabei ist der direkte Kontakt unerlässlich. Während kontextbasierte Kommunikation es ermöglicht, Gedankengänge und Entscheidungen im Kontext festzuhalten, sorgt der direkte Kontakt für den sozialen Zusammenhang. Beide Ansätze ergänzen sich. Verteiltes Arbeiten impliziert jedoch, dass der direkte Kontakt nicht immer möglich ist, manchmal sogar nie.

Reviews beschleunigen die Entwicklung und reduzieren Risiken, wenn sie früh und häufig durchgeführt werden Twittern

Ein weiterer Aspekt der Kommunikation sind Reviews. Reviews können die Qualität drastisch erhöhen und Entwicklungsrisiken minimieren, wenn sie häufig und frühzeitig durchgeführt werden. Das geht aber nur, wenn eine entsprechende Infrastruktur bereitsteht, siehe Punkt 3. Idealerweise stellen die Werkzeuge diese Funktion zur Verfügung, zum Beispiel Gerrit für Code-Reviews oder Jama für Anforderungs-Reviews.

Fazit

Die Liste hier ist natürlich nicht vollständig und geht auch nicht ins Detail. Doch wenn diese sechs Punkte berücksichtigt werden, dann steigen die Chancen drastisch, dass das Teamwork funktioniert.