Kolumne

DevOps-Stories: So wird hier gearbeitet!

Konstantin Diener

Aus funktionalen Teams sind crossfunktionale Teams geworden. Da heißt es, sich mit den neuen Kollegen zusammenzuraufen. Und weil der Chef keine Entscheidungen mehr für das Team trifft, muss das Team das selbst regeln: mit einem Teamvertrag.

In der letzten Folge der Kolumne haben Lukas und seine Kollegen festgestellt, dass sich für ihre Art der Produktentwicklung crossfunktionale Teams anbieten. In einem solchen Team sind alle Disziplinen vertreten, die es für die Herstellung eines Shippable Product Increments braucht. Als Konsequenz wurden die Mitglieder der bestehenden Teams Backend, Frontend und Mobile auf verschiedene neue Produktteams verteilt. Lukas’ neues Team besteht neben seinem Backend-Kollegen Christian noch aus Jörg (mobile Entwicklung) und Julia (Frontend-Entwicklung) (Abb. 1).

Das Team hat ein Daily-Stand-up-Meeting eingeführt, das jeden Tag um 10 Uhr stattfindet. Bis auf Jörg sind alle pünktlich versammelt. Er kommt um 10:10 Uhr durch die Tür geschlendert und hat einen Kaffeebecher in der Hand.

Abb. 1: In einem crossfunktionalen Team sind alle Disziplinen vertreten, die das Projekt oder Produkt braucht

Christian: „Hey Jörg, wie schön, dass du auch schon da bist. Wir warten schon seit zehn Minuten auf dich, um mit dem Stand-up zu beginnen.“

Jörg: „Wieso regst du dich so auf, Christian? Wir hatten uns locker für 10 Uhr verabredet. Sind diese zehn Minuten jetzt wirklich so wichtig? Meine Bahn hatte Verspätung und bei Starbucks war eine riesige Schlange …“

Julia: „Ich finde schon, dass du pünktlich sein solltest. Wir haben die Zeit nämlich mit nutzlosem Rumstehen verbracht. Du könntest wenigstens Bescheid sagen, wenn es bei dir eng wird!“

Jörg: „OK, wenn ihr darauf Wert legt, versuche ich mich danach zu richten. Soll ich direkt mit meinen Punkten fürs Daily loslegen?“

Lukas: „Gerne.“

Jörg: „Ich habe gestern versucht, die neue Titelsuche in die App zu integrieren. Ich habe aber direkt festgestellt, dass der App Build rot ist. Die Integrationstests schlagen fehl, weil ihr, Lukas und Christian, nichtkompatible Änderungen am Backend-Service gemacht habt. So kann ich den Service nicht mehr nutzen und muss mühsam nachvollziehen, was sich geändert hat.“

Lukas: „Ich wusste gar nicht, dass du in deinem Build Integrationstests für unsere Services hast. Das ist ja eigentlich eine tolle Sache. Aber wie sollen wir deiner Meinung nach vorgehen?“

Jörg: „Mir wäre es am liebsten, wenn ihr meine Tests in euren Continuous-Integration-Zyklus integriert. So könnt ihr verhindern, dass die Services nicht mehr so funktionieren, wie ich es erwarte.“

Christian: „Ja, aber …“

Julia: „Ich glaube, dass eure Diskussion wichtig ist. Sie gehört aber nicht ins Daily Stand-up. Sie geht zu tief ins Detail. Lasst uns das bitte im Nachgang besprechen.“

Christian: „OK, Julia, du hast Recht.“

DevOps Docker Camp 2017

Das neue DevOps Docker Camp – mit Erkan Yanar

Lernen Sie die Konzepte von Docker und die darauf aufbauende Infrastrukturen umfassend kennen. Bauen Sie Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf!

Vereinbarungen im Team

Eine solche Situation lässt sich oft in Teams beobachten, die erst eine relativ kurze Zeit bestehen. Lukas und Christian arbeiten schon länger zusammen. Zwischen ihnen sind die Abläufe eingespielt. Mit den neuen Kollegen müssen sie sich erst darüber verständigen, wie die Zusammenarbeit genau aussehen soll. Bruce Tuckman beschreibt die Entwicklung eines Teams in vier Phasen:

  1. Forming: In der ersten Phase nimmt das Team Kontakt untereinander auf. Diese Phase haben Lukas und seine Kollegen bereits hinter sich.
  2. Storming: In dieser Phase kommt es zu Auseinandersetzungen und Streit. Die Diskussion im Daily Stand-up ist ein gutes Beispiel dafür. Die Teammitglieder haben unterschiedliche Erwartungen an die grundsätzliche Zusammenarbeit oder die Qualität bzw. Beschaffenheit der Arbeitsergebnisse.
  3. Norming: Um sich aus der Konfliktphase heraus zu entwickeln, muss das Team gemeinsame Regeln entwickeln. Bis ein sinnvoller Satz an Regeln etabliert ist und vor allem auch eingehalten wird, dauert es eine gewisse Zeit.
  4. Performing: Auf Basis der gemeinsamen Regeln kann das Team effektiv kollaborieren.

Nicht nur neu gegründete Teams durchlaufen diese Phasen. Wird ein bestehendes Team personell stark verändert, stellen die neuen Mitglieder die Regeln in Frage und das Team beginnt wieder mit Storming, Norming und dann erst Performing. Im Sinne des Phasenmodells müssen Lukas und seine Kollegen sich als Nächstes über einen gemeinsamen Satz an Regeln verständigen. Dabei unterscheidet man in der Regel zwei verschiedene Ebenen: den Teamvertrag und eine Definition of Done.

Teamvertrag entwickeln und auch einhalten

In einem Teamvertrag – auch Working Agreements genannt – legt das Team generelle Regeln der Zusammenarbeit fest. Ein wichtiger Teil der Regeln bezieht sich oft auf die Durchführung von Meetings. Beispiele für solche Regeln sind:

  • Wir kommen pünktlich zu Meetings. Sollten wir verhindert sein, geben wir dem Team frühzeitig Bescheid.
  • Wir verlassen zum Telefonieren den Teamraum. Während eines Meetings sind die Handys aus oder lautlos.
  • Wir lassen einander ausreden.
  • Wir halten den Zeitplan für die Meetings ein.
  • Wir verbringen mindestens einen Tag pro Sprint mit Pair Programming.
  • Wir teilen alle Informationen mit unseren Teammitgliedern.
  • Wir hinterlassen unseren Arbeitsplatz so, dass am nächsten Tag auch jemand anderes aus unserem Team dort arbeiten könnte.

Welche Regeln ein Team in seinen Teamvertrag aufnimmt, hängt stark vom Team selbst, seinen Konflikten und der aktuellen Situation ab. Es gibt keine Elemente, die unbedingt in jeden Teamvertrag gehören. Folgende Eigenschaften sind für einen Teamvertrag aber empfehlenswert (angelehnt an Jane Haskell: „Working Agreements“ ):

  • Vom Team ausgehend: Das Team sollte ihn selbst erstellen und über den Inhalt verhandeln. Die enthaltenen Regeln werden nicht durch einen Manager vorgegeben. In Scrum-Teams begleitet und berät der Scrum Master das Team in der Regel bei der Anfertigung des Vertrags.
  • Positiv: Damit die Teammitglieder gerne mit einem Teamvertrag arbeiten, sollten die Regeln in Form positiver Verhaltensweisen beschrieben sein. „Wir lassen einander ausreden“ ist besser als „Wir wollen einander nicht mehr ständig ins Wort fallen“.
  • Kurz: Der Vertrag ist möglichst kurz, damit sich die Teammitglieder alle Regeln merken können. Außerdem erlaubt es neuen Mitgliedern, die Regeln schnell zu erfassen und zu verinnerlichen. Als Faustregel gilt, dass der Vertrag ungefähr auf eine Flipchartseite passen sollte.
  • Sichtbar: Damit die Regeln in Fleisch und Blut übergehen, sollte der Teamvertrag als Information Radiator gut sichtbar im Teamraum präsent sein, mit großen Buchstaben und gut lesbar geschrieben. Ausgedruckte DIN-A4- oder Wiki-Seiten sind weniger gut geeignet, weil sie gerne übersehen werden. Wechselt das Team für Meetings in einen anderen Raum, sollte es seinen Teamvertrag dorthin mitnehmen.
  • Umsetzbar: Die Regeln sollten durch das Team innerhalb seines Einflussbereichs umsetzbar sein und keine Wunschträume beschreiben.

Abb. 2: Das Team diskutiert seinen Teamvertrag

Wie für alle anderen Elemente in agilen Teams gilt auch für den Teamvertrag das Prinzip von Inspect and Adapt. Das Team sollte in Retrospektiven regelmäßig überprüfen, welche der Regeln noch Teil des Vertrags sein sollten und ob neue aufgenommen werden müssen. Bei der regelmäßigen Überprüfung des Teamvertrags kann sich das Team an den folgenden Fragen orientieren [1]:

  • Befolgen wir diese Regel noch?
  • Wenn ja, brauchen wir noch eine explizite Regel im Teamvertrag?
  • Wenn nein, ist dieser Punkt noch wichtig für uns?
  • Gibt es irgendeinen Punkt, den wir aufgrund aktueller Probleme gerne in den Teamvertrag aufnehmen würden?

Wenn der Teamvertrag erfolgreich zum Einsatz kommt, gehen die Regeln nach und nach in Fleisch und Blut über und müssen nicht mehr prominent präsentiert werden.

Einheitliche Definition of Done finden

Der Teamvertrag enthält allgemeine Regeln der Zusammenarbeit. Darüber hinaus ist es normalerweise sinnvoll, auch Regeln für die Qualität oder Beschaffenheit von Arbeitsergebnissen zu vereinbaren, beispielsweise die folgenden:

  • Ins zentrale Repository wird nur Code gepusht, der frei von Compilerfehlern sowie Checkstyle- und FindBugs-Warnungen ist.
  • Für alle Servicemethoden existieren automatisierte Integrationstests und eine Schnittstellenbeschreibung im Wiki.
  • Jede public-Methode ist mit einem JavaDoc-Kommentar dokumentiert und wird durch mindestens einen Unit-Test abgesichert, der grün ist.
  • Änderungen am Datenbankschema sind in der Liquibase-Konfiguration hinterlegt.
  • Aller Code erfüllt die Architekturregeln (z. B. jQAssistant).
  • Für die Codeänderungen wurde ein Peer Review durchgeführt.
  • Für das User Interface wurde zu zweit das manuelle Testdrehbuch abgearbeitet. Sind neue Anwendungsfälle hinzugekommen, wurde das Drehbuch entsprechend erweitert.

Die Definition of Done soll allen Mitgliedern des Teams Sicherheit geben, selbst entscheiden zu können, ob ein Feature, eine User Story oder Ähnliches wirklich fertig ist. Im Idealfall wird ein Großteil der Definition of Done im Kontext der Continuous Integration automatisiert geprüft.

Am Nachmittag nach dem Stand-up haben sich Lukas, Christian, Julia und Jörg zusammengesetzt und einen Teamvertrag sowie eine Definition of Done erstellt. Beide Dokumente möchten sie zukünftig in regelmäßigen Abständen überprüfen. Ihnen ist auch bewusst geworden, dass das Einhalten eine gewisse Disziplin erfordert und ihnen ein externer Moderator dabei helfen kann. Deswegen ist Ruben eine Woche später als Scrum Master zum Team gestoßen.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.