Vorbereitung auf die agile Wartung - Wissensmanagement

Wenn Sie über Dokumentation in der agilen Softwareentwicklung nachdenken, ist meist von "gerade genug" die Rede, was angesichts des Umfangs der Designdokumente in der traditionellen Softwareentwicklung durchaus Sinn macht. Der agile Geist denkt speziell darüber nach, was in Bezug auf die Dokumentation tatsächlich erforderlich ist.Agile Softwareentwicklung bedeutet auch effiziente Kommunikation, Zusammenarbeit und das Zusammensitzen in einem Raum oder am selben Tisch und Gespräche, wenn es Probleme gibt. Einige der XP-Praktiken wie Pair-Programming helfen neuen Mitarbeitern, sich in das Projekt einzufinden. Wenn Sie von effektiver Kommunikation und der Lösung von Problemen in einem Team sprechen, sobald diese auftreten, führen Sie zu einer Situation, in der das Wissen in den Köpfen sitzt. Die Mitarbeiter halten es vielleicht nicht für nötig, detailliert zu dokumentieren, da sie scheinbar alles über das Projekt wissen. Das kann dazu führen, dass ein neues Team in der Wartungsphase zunächst nicht über "genug" Dokumentation verfügt. Wenn man also von "gerade genug Dokumentation" spricht, muss das Wort "genug" quantifiziert werden.

In der agilen Softwareentwicklung konzentrieren wir uns sehr auf die testgetriebene Entwicklung und manchmal sagen wir, dass der Code die Dokumentation ist. Irgendwie scheine ich mit diesem Argument nicht einverstanden zu sein. Ich bestreite nicht, dass der Quellcode so geschrieben werden sollte, dass er gut lesbar und gleichzeitig wartbar ist. Ich stimme diesem Argument also wörtlich gesehen zu. Aber wenn Sie einem Entwickler die Anwendung erklären wollen, sind Testfälle als Konzepte zu feinkörnig. Am einfachsten ist es, die Anwendung auf einem Whiteboard zu erklären. Wenn Sie die Anwendungen aus der Quellcode-Perspektive betrachten, führt dies zu einer Situation, in der die Leute zwar verschiedene Teile der Projekte einzeln sehen können, aber möglicherweise nicht in der Lage sind, das gesamte Thema der Anwendung zu erkennen. Sie können sich eine sehr interessante Diskussion zu diesem Thema zwischen Jim Coplien und Bob Martin ansehen. Nehmen wir ein Szenario an. Die Softwareentwicklung ist abgeschlossen und die Anwendung läuft in der Produktionsumgebung. Die Anwendung muss nach einer gewissen Zeit in die Wartungsphase übergehen. Was passiert, wenn Sie in der Wartungsphase keinen Entwickler haben, der in der Entwicklungsphase an diesem Projekt gearbeitet hat? Dann bekommen Sie eine Menge Probleme. Viele Dinge, wie z.B. bestimmte Designentscheidungen und funktionale Aspekte, werden unklar.

Was macht das Leben eines neuen Entwicklers einfacher?

Wenn ein neuer Entwickler in ein Wartungsprojekt einsteigt, wird er, anstatt direkt in den Quellcode zu schauen, das Projekt in seiner Gesamtheit aus 20.000 Fuß sehen wollen. Das kann bedeuten, dass er sich ein Bild davon machen möchte, worum es bei der Anwendung in einer ganzheitlichen Perspektive geht, ihre Funktionalität, die Beteiligten, die Schnittstellen und den Wert der Anwendung in geschäftlicher Hinsicht usw. Darauf kann eine Diskussion über die architektonischen Grundlagen des Projekts folgen, um dann auf die technischen Einzelheiten und die Funktionalität der einzelnen Komponenten einzugehen. Je nachdem, auf welche Teile sich die neue Entwicklerin konzentrieren muss, kann sie Details zu diesen Komponenten einzeln erhalten. Danach kann sie natürlich tiefer in den Quellcode eintauchen. Das macht das Leben eines Neulings viel einfacher, da die Einführung in etwas Neues in einem schrittweisen Prozess erfolgt und nicht aus der Perspektive eines "blinden Mannes, der auf einen Elefanten schaut".

Wie machen wir das eigentlich?

Bevor wir darüber sprechen, wie wir es wirklich tun, sollten wir uns klar machen, dass wir die Zahl der Projekt-Veteranen schrittweise reduzieren wollen. Das scheint unvermeidlich zu sein, denn die meisten Menschen wollen sich nach einem langen Projekt ein neues Leben suchen. Am Ende sollte es zu einer Situation kommen, in der alte Entwickler in der Wartungsphase nur noch wenig oder gar nichts mehr zu tun haben. Es ist also sinnvoll, proaktiv und phasenweise neue Mitarbeiter in das Projekt einzubinden und die altgedienten Entwickler aus dem Projekt zu entlassen. Im Grunde genommen sollte das Endziel ein völlig neues Team sein, das in die Wartungsphase eintritt. Im Idealfall ist es sinnvoll, so zu denken, dass im Wartungszyklus keine Unterstützung durch alte Entwickler zur Verfügung steht. Sie werden vielleicht sagen, dass die Geschwindigkeit eines Scrum-Sprints abnimmt, wenn Sie neue Mitarbeiter in Phasen einstellen. Das hat zwei Aspekte. Erstens: Der Kunde sollte sich darüber im Klaren sein, dass eine Verringerung der Teamgeschwindigkeit unvermeidlich ist, aber letztendlich wird dadurch ein Team und eine Wissensbasis geschaffen, die ihm in der Wartungsphase zugute kommen. Eine andere Möglichkeit besteht darin, mehrere Mitarbeiter einzustellen, wenn ein alter Entwickler aus dem Projekt ausscheidet. Dieses Szenario ist aus finanzieller Sicht sinnvoll, wenn Sie versuchen, die Wartungsphase an ein verteiltes Team auszulagern.Wir haben soeben darüber gesprochen, was alles erforderlich ist, um in der Wartungsphase effektiv zu sein. Lassen Sie uns nun darüber sprechen, wie Sie diese Aufgabe bewältigen und im Entwicklungszyklus selbst darauf vorbereitet sein können.Zunächst einmal müssen wir auf der Grundlage unserer Analyse feststellen, welche Dokumentation für die Wartungsphase erforderlich ist, und eine Lückenanalyse durchführen. Auf der Grundlage der ermittelten Lücken kann die Dokumentation auf innovative Weise erfolgen. Wie in einem der Xebia-Blogs (in dem die Bedeutung des Einsatzes von Multimedia für die Dokumentation hervorgehoben wird) erörtert wurde, ist es gut, einen Projektüberblick auf einem Whiteboard zu geben, gefolgt von einer Fragerunde mit den neuen Mitarbeitern, die dann als Video aufgezeichnet wird. Das Gleiche gilt für den Wissenstransfer bei der Präsentation der Architektur und der Anwendungsfunktionalität. Anstatt den Wissenstransfer für jeden neuen Mitarbeiter durchzuführen, sollten Sie den Inhalt aufzeichnen lassen. Wenn Sie tiefer in die Anwendungsfunktionalität eintauchen möchten, steht Ihnen möglicherweise eine Dokumentation zur Verfügung, die die Funktionalität und die technischen Aspekte der verschiedenen Teile der Anwendung abdeckt. Bei Bedarf können Sie auch Screencasts für Installationsanleitungen verwenden. Neben der High-Level-Dokumentation, die in Form von Videocasts verfügbar ist, bietet die schriftliche Dokumentation für einzelne Komponenten einen sehr guten Start für einen neuen Entwickler. Wenn neue Entwickler in der letzten Phase des Entwicklungszyklus zum Projekt stoßen, ziehen sie zunächst die bereits verfügbare Dokumentation (Videocasts und schriftliche Dokumentation) zu Rate. Wenn sie eine Lücke finden, verfeinern sie diese weiter. Die Dokumentation, über die wir jetzt sprechen, ist per Definition "gerade genug". Keine dicken Bände von Dokumenten. Sie sollte jedoch für einen neuen Java-Entwickler ausreichen, um mit dem Projekt Schritt zu halten. Während das Projekt voranschreitet, verlassen alte Entwickler das Projekt, neue Entwickler kommen hinzu und erweitern die Wissensbasis auf der Grundlage ihrer eigenen Erfahrungen und der Probleme, die sie mit der vorhandenen Wissensbasis haben.

Fazit

Mit dieser Dokumentation und Wissensbasis in der Hand wird es für das neue Team relativ viel einfacher, ohne große Probleme in die Wartungsphase zu gehen. Auch wenn wir bisher davon gesprochen haben, dass im Idealfall keine erfahrenen Entwickler zur Verfügung stehen, ist es in der Realität immer gut, wenn ein erfahrener Entwickler für 1 Tag in der Woche zur Verfügung steht, um eventuelle Probleme in der Anfangsphase zu klären.