Softwareentwicklung

de.buildblog.reflect – Projektübergreifende Teamkommunikation

Stellen wir uns vor wir hätten ein recht kleines “Entwicklungsteam” von ca. 5-8 Personen. Die Anzahl der gleichzeitig bearbeiteten Projekte entspricht der Anzahl der Entwickler. Wir haben also das Problem, dass jedes Mal, wenn jemand Urlaubs- oder Krankheitsbedingt ausfällt und “sein” Projekt hinreichend priorisiert ist, ein Entwickler aus einem “unterprivilegierten” Projekt die Arbeit übernehmen muss. Dabei gibt es ein paar Dinge zu beachten. Der nun einspringende Entwickler hatte nämlich mit seinem Projekt hinreichend Arbeit, kennt die Projektstruktur nicht oder unzureichend und muss sich jetzt möglichst schnell in die Sache einarbeiten. Die beste vorhandene Doku ist ein JavaDoc und ein paar Handschriftliche Notizen. “Was tun?”, sprach Zeus.

Willkommen im dritten Teil meiner Serie über allgemeine Softwareentwicklung.

Es ist extrem riskant einem einzigen Entwickler die Macht über ein Projekt zu geben. Vom Ego eines jeden Menschen abgesehen kommen hier Risikopotentiale, wie Urlaub, Krankheit, allgemeine Formschwäche, etc. hinzu. Es gibt ein paar Ansätze dieses Problem zumindest abzuschwächen. Viele davon sind mit wenig Zeit und Kostenaufwand realisierbar.

Die Dokumentation

Ein unerlässlicher Bestandteil jeder Software. Hier kommt häufiger mal die Frage auf wer den dokumentieren soll. Ein speziell dafür vorgesehener Dokumentator, oder derjenige, der den Code “verbrochen” hat? Die Antwort darauf ist recht einfach: Jemand der nicht dazu in der Lage ist seine eigene Software lückenlos zu dokumentieren ist auch nicht dazu in der Lage lückenlose Software zu schreiben. Zur Dokumentation gehört allerdings noch ein bisschen mehr. Der Entwickler selbst schreibt den technischen Teil der Dokumentation und fertig ein möglichst exaktes Pflichtenheft an, welches bei jeder Projektänderung zwingend aktualisiert werden muss. Die technische Doku beginnt zunächst mit Prosa und dies dürfte das größte Problem der meisten Entwickler sein. “Beschreibe in einfachen Worten, was die Ziele der Software sind, mit welchen Mitteln diese erreicht werden sollen und was die besonderen charakteristischen Merkmale der gelösten Probleme sind.”

Nicht jeder Entwickler muss ein wortgewaltiger Literat sein. Ein gewisses Maß an Ausdrucksfähigkeit sollte aber unterstellt werden dürfen.

Neben der technischen Dokumenation mit Ablaufbeschreibungen und idealerweise einigen schematischen Darstellungen zum einfacheren Verständnis sollte der Code lückenlos mit Kommentaren (JavaDoc, etc.) versehen werden. Die technische Dokumentation sollte so abgefasst sein, dass sie zur Not auch von betriebsfremdem Personen verstanden werden kann. Darüber hinaus ist es in diesem Zusammenhang überaus sinnvoll, wenn die Doku keinem peinlich sein muss. Das bedeutet man sollte diese aus zwei Gesichtspunkten gegenlesen (lassen):

1. Verständlichkeit
2. Rechtschreibung und Grammatik

Über das Pflichtenheft und die technische Doku hinaus, kann es äußerst hilfreich sein weitere Dokumentationswerkzeuge zu verwenden die ich im folgenden Kurz vorstellen möchte.

Interne Projektblogs

Interne Projektblogs sind ein hervorragendes Mittel um Projektfortschritte zu Dokumentieren, allgemeine Gedankengänge zum Projekt nachvollziehbar zu machen (warum habe ich etwas so gemacht und nicht anders). Hier kann jeder Projektbeteiligte seine Fortschritte dokumentieren und Probleme darlegen. Idealerweise haben alle anderen Projektbeteiligten, oder die Notfallvertretungen die Möglichkeit diese zu Kommentieren und die entsprechenden Feeds zu abonnieren, was eine Menge Atemluft und Zeit erspart. Man muss niemanden anrufen und Fragen, wo das Projekt festhängt. Das abonnierte RSS-Feed gibt bereits auskunft darüber. Um die ganze Sache abzurunden hat man mit dieser Art der Dokumentation auch noch ein passendes Werkzeug in der Hand auf Rückfragen der Art, “Warum hat dies oder jenes so lange gedauert?”, zu antworten. Ein weiterer Vorzug dieser zusätzlichen Methode Dinge zu dokumentieren ist, dass diese eine hervorragende Gedankenstütze für den Entwickler selbst darstellt. Es ist entgegen mehr oder minder landläufiger Meinung nämlich keineswegs seine Aufgabe sich an jede Schmutzecke oder gar den Grund dafür zu erinnern. Zumal sich solche Fragen üblicherweise dann stellen, wenn der Entwickler das Projekt gerade abgibt oder abgegeben hat. Minimiert man Rückfragen zu einem existierenden Projekt so minimiert man auch die Zeit, die der Ursprüngliche Entwickler aus seinem aktuellen Projekt abzwacken muss um Fragen zu seiner schlecht dokumentierten Vergangenheit zu beantworten.

Falls Projektblogs zum Einsatz kommen ist es von Vorteil sich vorher über bestimmte Regeln zu einigen, nach denen die Feeds auch gelesen werden. Denkbar sind hier Priorisierungen in den Betreffzeilen. Ein “request for comment” muss z.B. unverzüglich zur Kenntniss genommen und von den anderen beantwortet werden. Auch ist zu klären ob unbeteiligte aus eventuell ganz anderen Projekten gegenseitig Ihre Feeds abonnieren sollen oder dürfen. Ein solches Vorgehen hat mehrere Vorteile:

• In Unterschiedlichen Projekten können ähnliche Probleme auftauchen. Ist dies der Fall partizipieren die Entwickler der anderen Projekte unmittelbar an dem Wissen der anderen.
• Es findet ein schneller Informationsaustausch statt. Da in der oben beschriebenen Entwicklerkonstellation eigentlich jeder alles wissen müsste, sollte auch jeder alle Projektfortschritte mitverfolgen, oder zumindest die Möglichkeit dazu besitzen. Dies spart Stundenlange Meetings bei denen sich die Entwickler gegenseitig über für sie häufig irrelevante Projektfortschritte informieren.

Projektblogs lassen sich auch über die Grenzen der Entwicklungsabteilung hinweg hervorragend einsetzen um sonstige beteiligte Kollegen über für sie interessante Sachverhalte zu informieren. Dazu zählen nicht nur verspätete Produktivtermine sondern gemeldete und behobene Probleme. Diese lassen sich in einem Blog hervorragend in bestimmte Kategorien einsortieren, so dass der technisch weniger versierte Leser die Möglichkeit erhält lediglich für sich interessante Informationen zu extrahieren.

Fortsetzung folgt…

© 2008 buildblog.