Diskussionsmöglichkeiten

Dieser Abschnitt vergleicht die unterschiedlichen Möglichkeiten für Diskussionen während der Entwicklung. Hierzu zählen die geplanten und spontanen Diskussionen im Team, wie auch der teamübergreifende Austausch.

Die Tabelle5.2gibt an, welche Diskussionen im Prozess vorhanden sind. Wenn ein Punkt nicht markiert oder nicht vorhanden ist, heißt dies nicht zwingend, dass dieser nicht durchgeführt wird. Es ist ebenfalls möglich, dass zu diesem Zeitpunkt nicht über Architekturthemen geredet wird.

Viele der regelmäßigen Meetings aus dem Scrum Manifesto werden bereits für eine Diskussion eingesetzt. Die Kanban Teams (C, F, G) verwenden diese ebenfalls zum großen Teil. Die Meetings und deren regelmäßigen Zyklus haben sie übernommen.

Der erste Zeitpunkt, an dem über die Architektur geredet wird, ist meist das Sprint Planning. In

Unternehmen Sprint Planning

Daily Me

eting

sp ontanes

Me eting

Teamintern

Teamüb ergr

eifend

A X X X - Tec-Grooming - Community Meeting

B X X X - individuelle Absprachen

zwischen den Teams - Pizza-Mittwoch

C X - Vorstellung der Stories

- Code-Camp

- Jour Fixe

D X X X - individuelle Absprachen

E X X X - allgemeines Treffen

F X X - Vorstellung der Stories - Table-Talk - Slack

G X X - allgemeine

Teambespre-chung

- Story-Kickoff - Understanding

- Besprechung der Makro-Architektur

- Entwickler Convention - interne Konferenzen H X X X - Vorträge und Workshops - ausführliche

Architektur-analyse

Ø 5/8 8/8 7/8

Tabelle 5.2: Diskussionsmöglichkeiten

diesem Meeting„werden schon viele Aspekte diskutiert, die in Richtung der Architektur gehen“

[D, 11:57min]. Die Diskussion findet hauptsächlich im zweiten Teil, beim Aufteilen in Tasks statt:„dort muss man schon technisch diskutieren, was müssen wir jetzt eigentlich alles ändern“

[E, 06:25min]. Früher wird nicht darüber geredet, weil die Teams dann erst entschieden haben, an diesem Ticket zu arbeiten und dadurch„nicht zu sehr im Vorhinein über Architektur reden und dann eventuell über etwas reden, was [sie] doch nie machen“ [A,14:58min]. Dort wird auch diskutiert:„Wie machen wir es den jetzt?“ [G, 18:03min]. Bei diesem Treffen „überlegen die Entwickler, [...] welche technischen Schritte müssen wir umsetzten“ [F, 09:04min]. Die Schritte stellen einzelne Tasks dar (Task-Breakdown). Die Kanban Teams führen kein Planning-Meeting durch. Sie stellen die neuen Stories in regelmäßigen Kickoff-Meetings vor. Die Aufteilung in konkrete Arbeitsschritte wird in Unternehmen C und F in einem spontanen Meeting, direkt vor Beginn der Entwicklung vorgenommen.

Unternehmen A hat zur Lösung von technischen Unklarheiten ein zusätzlichesTec-Grooming eingeführt:„Da müssen wir uns nochmal überlegen, wie wir das eigentlich machen wollen bevor wir das schätzen können und setzten uns dann aber relativ spontan zusammen.“ [A, 16,42min].

Das zu diesem Zeitpunkt gehörende Schätzen (Estimation) der Stories wurde in Unternehmen G in Understanding umbenannt. Dies wurde getan, weil es ihnen beim Schätzen nicht um die Dauer der Entwicklung geht. Der Vergleich der geschätztenStory-Pointssoll stattdessen in Erfahrung bringen, ob alle Entwickler ein ähnliches Verständnis davon haben was zur Realisierung getan werden muss.

In kürzeren Zeitabständen wird das Daily Meeting (bzw. Standup) um über Architekturthemen zu reden verwendet. In manchen Projekten wird dies zum teamübergreifenden Austausch eingesetzt (A, E). In Unternehmen A wird das Daily Meeting z.B. zwei mal in der Woche mit allen Teams der Abteilung durchgeführt. Es dient häufig als Einstiegspunkt, um Probleme anzusprechen:„Meist wird sowas im Standup angesprochen.“ [F, 25:45min].„Da dies nicht ein-mal am Anfang des Sprints, sondern jeden Tag“ [H, 07:25min] stattfindet, eignet es sich gut um kurzfristig Dinge anzusprechen bei denen Feedback gewünscht ist. Häufig löst dies ein zusätzliches, mehr oder weniger spontanes, Meeting aus. Das Daily Meeting soll dadurch nicht unnötig in die Länge gezogen werden. Die Lösungen der Probleme werden häufig erneut im Daily Meeting kurz erklärt.

Ein paar der Unternehmen haben einen zusätzlichen Zeitraum eingeführt, um über den Zustand der aktuellen Architektur zu reden. Das Vorgehen dabei ist bei den Unternehmen sehr unter-schiedlich. Dies ist eine Art von„Retrospektive für die Architektur“ [C, 08:22min]. Ein extra Zeitraum macht Sinn, weil sich gezeigt hat, dass„wenn man so ein dediziertes Meeting hat, dann kommen doch mehr Sachen raus“ [C, 09:39min], als bei Meetings bei denen andere Themen im Fokus stehen. Bei Unternehmen C ist dies dasCode-Camp. Unternehmen D führt etwas ähnliches durch. Bei ihnen ist es allerdings konkreter auf einzelne Stories bezogen. Hierbei geht es vor einem Review darum, dass„Besonderheiten der Entwicklung nochmal vorgestellt werden bevor ein Product Owner dazu kommt“ [D, 11:00min]. Unternehmen C ( Jour Fixe) und G führen regelmäßige Debatten über die oberhalb liegende Gesamtarchitektur durch. An diesen nehmen nur die Architekten der Teams teil. Hier sollen Fragen wie:„Wie würden wir das einheitlich lösen?“ [C, 11:21min] beantwortet werden. Die Ideen tragen die Architekten ihren Teams vor.

Für den Zustand der einzelnen Komponenten sind die Teams vollständig selbstverantwortlich.

Das Team von G hat zu diesem Zweck zweimal in der Woche eine allgemeine Teambesprechung.

Unternehmen H führt eine sehr intensive Analyse der entstandenen Architektur durch. Dies wird im Abschnitt zum Management der Architekturerosion (Kapitel5.4.3) genauer vorgestellt.

Absprachen zwischen einzelnen Teams, z.B. zu Schnittstellen, werden meist individuell ge-handhabt. Unternehmen B dokumentiert umgesetzte Schnittstellen„formal über ein Wiki“ [B, 23:25min]. Die Einträge stellen die„Verträge zwischen den Teams“ [B, 23:28min] dar. Unter-nehmen D führt dies ebenfalls sehr individuell durch. In Zukunft soll ein„Provider-Consumer Regelgespräch eingeführt [werden], wo solche Austauschmöglichkeiten stattfinden“[D, 09:45min]

können. Die Absprachen können meist nur sehr individuell durchgeführt werden, weil mit

„manchen Teams arbeitet man sehr eng und kurz getaktet“ [G, 31:56min] und„in anderen Fällen ist das etwas mühseliger, da hängt es dann wirklich von den einzelnen Personen ab“[G, 32:53min].

Für den allgemeinen teamübergreifenden Austausch stellen viele Unternehmen einen Zeitraum zur Verfügung. Dieser Austausch kann über Architekturthemen, wie auch allgemeine weitere Themen stattfinden. Unternehmen A hat zu diesem Zweck ein wöchentliches Community-Meeting. Inhalt dieses Meetings„kann im Prinzip alles sein“[A, 20:50min]. Dies umfasst das Besprechen von Problemen, wie auch das Halten von Vorträgen. In Unternehmen B wurde zu diesem Zweck früher regelmäßig der Pizza-Mittwoch durchgeführt. D möchte dies in Zukunft wieder einplanen. Derzeit bestehe das Problem, dass die„die was vorzustellen haben, keine Zeit haben etwas vorzustellen“ [D, 17:28min]. Bei Unternehmen F wird dies alsTable-Talk bezeichnet. Hier kann außerdem ein Mitarbeiter vorstellen,„woran er gerade arbeitet, wo er sagt, hier brauche ich nochmal Input“ [F, 24:14min]. Dies kann er machen, um Feedback zu erhalten. Unternehmen G hat mehrere Möglichkeiten zum teamübergreifenden Austausch.

Zum Einen ist dies eine Entwickler Convention, mit einer„klassische[n] Vortragssituation“ [G, 16:27min]. Zum Andern werden unregelmäßig interne Konferenzen zu speziellen Themen mit externen Referenten durchgeführt.

Neben den festen und spontanen Meetings findet meist zusätzlich ein sehr individueller aber wichtiger Austausch statt. Dies kann z.B. über Chatsysteme (z.B. Slack in Unternehmen F), wie auch bei Flurgesprächen an der Kaffeemaschine geschehen. Außerdem kann zu allen Diskussionen gesagt werden, dass diese nur mit den dafür relevanten Personen durchgeführt werden sollten. Mit zu vielen Personen„schweift [die Diskussion] schnell ab oder man hängt sich an Detailfragen auf“ [E, 7:54min].

Die Art, wie eine Diskussion stattfindet, ist abhängig von den Personen im Team. Eine Diskus-sion kann z.B. mithilfe von Entwurfsmustern geschehen. Hierdurch sprechen die Entwickler eine gemeinsame Sprache. Laut H ist die Einstiegshürde allerdings hoch, weil gute Kenntnisse über die Muster vorhanden sein müssen. Sobald diese überwunden sei, ist die Diskussion im Team einfacher. Wie unter anderem auch D berichten konnte hängt die Art der Diskussion stark vom Team ab und entwickle sich meist ohne konkrete Absprachen.

Zusammenfassung

Zusammenfassend kann gesagt werden, dass verschiedene Diskussionsräume hilfreich sein können. Vor Beginn einer Story sollte mit mindestens einer weiteren Person ein möglicher Lösungsweg erarbeitet werden. Das Daily Meeting kann frühzeitig genutzt werden um Proble-men anzusprechen. Das Problem selbst sollte nicht bei diesem Treffen diskutiert werden. Dieses würde dadurch unnötig in die Länge gezogen werden. Außerdem sind viele Personen anwesend, die nicht zur Lösung beitragen können und stattdessen nur von der Arbeit abgehalten werden.

Um über den aktuellen Zustand der Architektur zu reden ist ein dediziertes Meeting sehr wertvoll. Hier können geplante Änderungen, die nicht in Zusammenhang mit einer Story stehen, besprochen werden. Außerdem kann dieses Meeting für eine Art von Retrospektive, bzw. Review für die Architektur eingesetzt werden.

Der teamübergreifende Austausch zu Schnittstellen sollte nicht genauer geregelt werden.

Hierzu sind die Teams und Projekte meist zu individuell. Individuell angesetzte Absprachen könnten hier die passendere Lösung sein. Ein weiterer teamübergreifender Austausch, im Rahmen einer festen Vortragssituation, ist wichtig für eine Wissensverbreitung. Die Themen sind meist allgemein und helfen dadurch nicht zwingend bei einem konkreten Problem. Sie können aber den Einstieg in eine neue Technologie vereinfachen und neue Ideen schaffen.