Erwartete Lesezeit: 3 minuten
Jeder kennt es , man wechselt sein Arbeitsgebiet oder soll in einem anderen Team aushelfen, ohne zu wissen was das Team überhaupt macht und wie deren System tickt.
Wie schön wäre es einfach irgendwo nachlesen zu können. Aber stattdessen muss man sich bei den Kollegen durchfragen und ob man dann eine erklärende Antwort bekommt ist dann auch fraglich, da nicht jeder Kollege von beginn an im Boot war und auch nur sagen kann
Ich glaube, es ist historisch gewachsen
Diese Antwort habe ich auch ab und zu genutzt , da ich auch nicht mehr wusste , warum wir damals etwas entschieden haben.
Nicht nur aus diesem Grund sollte man seine Architektur dokumentieren, es können auch regulatorische Vorgaben ausschlaggebend sein.
In den folgenden Blogeinträgen werde ich mich mit einigen Dokumentationsmitteln auseinandersetzten und an Beispielen erklären.
Hierzu gehören unter anderem
- Architekturentscheidungen
- Schnittstellenbeschreibungen
- Systemkontext
- Technische Risiken
Agilität vor Dokumentation
Funktionierende Software mehr als umfassende Dokumentation
Manifest für Agile Softwareentwicklung
Alles klar, wir können an dieser Stelle abbrechen. Wir arbeiten ja agil , also brauchen wir nix zu dokumentieren. So leicht ist es leider nicht.Es geht vielmehr um eine angemessene Menge an Dokumentation. Architekturen zu Dokumentieren ist schwieriges Thema. Vergleichen wir das agile Vorgehen mit der klassischen Entwicklung z.B. nach dem Wasserfallmodell, wurde damals vielleicht zu viel Dokumentiert. Erst wurden die Anforderungen bis ins kleinste Detail am Anfang des Projektes beschrieben (z.B. über ein Pflichtenheft) , anschließend wurde die komplette Architektur und das Vorgehen beschrieben bevor überhaupt an die Umsetzung gedacht wurde. Nun arbeiten wir Agil, d.h. in der Regel in kleinen Paketen, sodass es gar nicht möglich ist , am Anfang des Projektes eine komplette Architekturdokumentation zu machen.
Ich persönlich gehe in Bezug auf Dokumentation davon aus , das der Aufwand und der Nutzen in einen passenden Verhältnis stehen müssen. Dabei hat eine gute Dokumentation, insbesondere die Architekturdokumentation, den Vorteil, dass man sie gut zur Kommunikation mit den Stakeholdern heranziehen kann , um die Ansichten des Teams zu untermauern. Ein schönes Beispiel ist hier der Bereich Kosten.Die Frage warum ein Feature teuer ist, kommt fast immer. Nun kann man sich , sofern man eine gute Architekturbeschreibung hat, aus diese berufen und z.B. auf bislang getroffene Entscheidungen referenzieren.
Da wir beim Feature x aus kostengründen die Anbindung in der Variante 1 gemacht haben, obwohl die Variante 2 variabler , aber teurer gewesen wäre, ist das neue Feature um x Einheiten teuerer.
Eine passende Dokumentation dient aber auch zu Erklärungszwecken, da man einem Stakeholder ja nicht sagen kann “ Schau doch in den Code“ . Eine grafische Darstellung über die Einbindung des Systems in die Umsysteme ist in diesem Fall passender.