/ InnerSource

InnerSource - Unsere Erfahrungen

Michael Geiss hat vor einiger Zeit im Europace Tech Blog über den Einsatz von Pull Requests innerhalb eines Teams berichtet. Diesmal soll der Fokus auf der Zusammenarbeit über Teamgrenzen hinweg mit Unterstützung von Pull Requests liegen.

Bei Europace arbeiten Entwickler gemeinsam mit Kollegen mit Fokus auf Support, Produktmanangement und fachlicher Begleitung der Plattform innerhalb von vier Units (andernorts oft auch Abteilung genannt). Teams wurden bisher üblicherweise jeweils aus Mitgliedern einer Unit zusammengestellt.

Trotz weitgehender Autonomie in den Units wird letztlich mit Europace 2 eine gemeinsame Plattform entwickelt was im Alltag immer wieder zu Abstimmungsbedarf über Unit-Grenzen hinweg führt.

Inspiriert durch das Konzept InnerSource sind wir dieses Problem mit Methodiken aus dem Open-Source-Bereich angegangen: Da in vielen Bereichen bei uns bereits Github zum Einsatz kommt, war ein naheliegendes Tool die Arbeit mit Pull Requests - auch über Team- und Unit-Grenzen hinweg.

Was haben wir dabei gelernt?

Lieber einmal mehr fragen, als Annahmen machen.

Was im eigenen Team üblich ist, muss im Nachbarteam noch lange nicht genauso gelten - selbst wenn man die gleiche Programmiersprache mit den gleichen Coding Guidelines einsetzt.

Verantwortungen und Basis-Spielregeln von Anfang an klären.

Insbesondere, wenn Entwickler sich an einem bereits bestehenden Projekt beteiligen wollen, hilft es von Anfang an Spielregeln zu vereinbaren. Dabei hilft das InnerSource-Konzept des Trusted Committers: Nicht eine Absichtsbekundung führt zu Entscheidungskompetenz, sondern tatsächliche Unterstützung. Über gemeinsame Zusammenarbeit wird schrittweise Vertrauen aufgebaut und Verantwortung geteilt.

Persönliche Treffen sind wertvoller als zuvor.

Über Teamgrenzen hinweg zu arbeiten, bedeutet oft, mit Kollegen zusammenzuarbeiten deren Schreibtisch nicht direkt neben dem eigenen steht und die man nicht jeden Tag zum Mittagessen begleitet. Fehlt der stete persönliche Kontakt kommt es schnell zu Missverständnissen - insbesondere wenn wie bei Pull Requests üblich nur Text übermittelt wird, nicht aber Mimik, Gestik, Tonfall des Gegenübers. Es hilft, sich auch außerhalb des Projektes persönlich zu treffen - am besten außerhalb eines offiziellen Meetings zum Beispiel zu einem Stück Kuchen im Rahmen von "Cake Driven Development".

Work-in-progress möglichst früh teilen - und als solchen markieren.

Fehlen Absprachen über die Schreibtischgrenzen hinweg lohnt es sich, Entwürfe möglichst früh als Pull Request zu teilen und Feedback einzusammeln. Wichtig dabei: Nicht vergessen, klarzumachen, dass es sich um Work-In-Progess handelt - nicht dass im schlimmsten Falle Code in der Deployment Pipeline landet, der dafür noch gar nicht gedacht war.

Deployment und Businesslogik sind oft fester verdrahtet als gedacht.

In einem unserer InnerSource-Projekte war die Aufgabe, einen Microservice um einige zusätzliche Aufgaben zu erweitern und in einem völlig anderen Kontext einzusetzen als bisher - betrieben von einem anderen Team in einer anderen Deployment-Umgebung. Was auffiel? Den Service in einem team-übergreifenden Setting einzusetzen bedeutete auch, Deployment-Spezifika von Bibliothekslogik sauberer als bisher zu trennen.

Was haben wir beobachtet?

Feedback in Code Reviews ist oft kritischer als das, was im Pair Programming angesprochen wird. Entsprechend steigt die Code-Qualität nochmal erheblich.

Code Reviews ermöglichen auch dann eine Zusammenarbeit, wenn unterschiedliche Abläufe es schwer machen, gemeinsame Zeiten für Pair Programming zu finden.

Pull Requests mit asynchronem Review machen eine Zusammenarbeit einfacher, da nicht erst für ein gemeinsamer Raum mit Platz für das gesamte Team gefunden werden muss - spätestens bei Brainstorming, Design, Retrospektiven lohnt es dann aber doch wieder, die höhere Bandbreite zu nutzen, die in einem Face-To-Face Meeting vorhanden ist. Erfahrene Entwickler, die bisher Probleme hatten, alle an sie gerichteten Fragen zu beantworten, bekommen die Möglichkeit, eine Mentorenrolle zu übernehmen und an sie gerichtete Fragen ohne viel zusätzlichen Aufwand im ursprünglichen Kontext zu sehen und zu beantworten - ähnlich wie es vor zehn Jahren bereits im Open-Source-Umfeld formuliert wurde: "So you can either try to drink from the firehose and inevitably be bitched about because you're holding something up or not giving something the attention it deserves, or you can try to make sure that you can let others help you."

Last but not least: Auch positives Feedback geben will gelernt sein

Ein Blick in die Zukunft

Unsere Entwickler haben innerhalb der eigenen Units und über Unit-Grenzen hinweg Erfahrungen mit InnerSource sammeln können. Inzwischen beteiligen sich auch Kollegen, deren tägliche Arbeit nicht "Softwareentwicklung" heißt. Michael Geiß hat in seinem Artikel zum Thema Pull Requests bereits die Vorteile der Arbeit mit Pull Requests auf Unit-Ebene beschrieben. InnerSource Prinzipien haben es uns ermöglicht, diese positiven Effekte über Unit-Grenzen hinaus zu skalieren, die Teams in einen engeren Austausch zu bringen und so vorhandene Expertise im Unternehmen noch besser zu nutzen.

Einige spannende Neben-Effekte machen die Aussage von Kollegen deutlich:

"InnerSource war für mich der erste Schritt in Richtung Open-Source - mit Prozessen und Tooling vertraut zu sein, hat bei mir dazu geführt, auch bei Open-Source-Projekten einen Schritt weiter zu gehen und mich selbst aktiv am Projekt zu beteiligen."

"Ich habe vor der Einführung von Inner Source bei EP schon viel in Open Source Projekten mitgemacht, viel beobachtet und pflege auch eigene Projekte. Die dabei gesammelten Erfahrungen habe ich als positiv und wertvoll für uns bei EP (nicht nur PKU) gesehen und fühle mich auch sehr wohl dabei, wie ich jetzt die bei Open Source gelernten Mechanismen einfach per Inner Source anwenden kann, ohne "umschalten" zu müssen zwischen normaler Arbeit und Aktivitäten außerhalb.

Der teamübergreifende Aspekt wird dabei geschenkt: in der Open Source Welt ist fast jedes Projekt teamübergreifend, verschiedene Communities treffen sich und tauschen sich aus. Diese Art von Austausch findet nun auch vermehrt bei uns statt und scheint auch bei allen als bereichernd wahrgenommen zu werden. Das ist der für mich wichtigste Wert von Inner Source: effektivere, entspanntere und angenehmere Zusammenarbeit."

Wie sind Eure Erfahrungen mit teamübergreifender Zusammenarbeit?

Dieser Artikel entstand mit Unterstützung und Input von Tobias Gesellchen,
Enrico Hartung.