So kann das Schreiben von Release Notes die Qualität in der Software-Entwicklung – insbesondere dem Software Delivery Process – unterstützen.

Perfekt durchgeplante Releases, keine Live-Bugs, keine geänderten Anforderungen gehören leider zu den Wunschträumen in der Web-Entwicklung. Leider ist es insbesondere in Projekten mit sehr kleinem Budget schwierig Ticket-Systeme o.ä. zu implementieren und gleichzeitig schnell Iterationen auszuliefern.

Auch wenn wir uns das alle gern wünschen, aber gerade in der Web-Entwicklung bestehen Anforderungen und Abnahmen doch in der Regeln auf seitenlangen E-Mail-Konversationen. Schnell wird dabei eine Zeile überlesen oder die vorherige Bedingen für dieses oder jenes Feature überlesen. Man glaubt mit bestem Wissen und Gewissen alle Anforderungen umgesetzt zu haben. Aus eigener Erfahrung kann ich nur sagen, dass man trotz gründlicher Arbeit einmal was übersehen kann, insbesondere wenn sich Anforderungen nochmal in letzter Minute ändern.

Um dem entgegen zu wirken setzen wir seit einiger Zeit eine Technik in einigen Projekten ein, die ich bereits im Studium für das Lernen für Klausuren genutzt haben. Früher habe ich mir den Stoff nocheinmal schriftlich (sogar handschriftlich) zusammengefasst. Ich habe also den kompletten Stoff mehrfach aufgeschrieben. Durch dieses immer und immer wieder nachdenken und aufschreiben konnte ich mir sehr gut den Stoff merken und war in der Regel gut auf Klausuren vorbereitet.

Beim Schreiben von Release Notes für Software-Iterationen wenden wir einen ganz ähnlichen Prozess an. Jeder Entwickler schreibt natürlich etwas in die Commit-Messages der Versionsverwaltung, aber eben nur für die eben genannte Aufgabe. Das entspricht dem gefühlten Abhaken der momentanen Aufgabe. Wenn man allerdings den Release vorbereitet, kann man mit dem Schreiben der Release Notes nochmal über alle umgesetzten Features nachdenken und mit eigenen Worten die Features aufschreiben.

Das Aufschreiben mit eigenen Worten ist dabei ein wirklich wichtiger Punkt. Wenn man lediglich alle Commit-Messages in ein Dokument hineinkopiert, hilft das weder fehlende Features zu finden noch dem Kunden die Features nachzuvollziehen. Die Release Notes sollen nämlich für den Kunden und nicht für den Entwickler sein, d.h. man muss auch aktiv darüber nachdenken was man eigentlich getan hat und welchen Vorteil es für den Kunden bringt. Eine Zeile wie “refactor CartView” hilft einem Kunden wahrscheinlich wenig einzuschätzen was passiert ist – jedoch die Aussage “Warenkorb Seiten überarbeitet um die Speicherverwaltung zu optimieren” kann der Kunde durchaus nachvollziehen.

Vorteile

• Entwickler denken noch einmal aktiv darüber nach, welche Features und Optimierungen in einer Iteration umgesetzt wurden.
• Die Entwickler schärfen den Blick für den Nutzen ihrer Änderungen aus Kundensicht.
• Es besteht die Möglichkeit, dass vergessene Anforderungen vor dem Release gefunden und noch behoben werden.

Nachteile

• Das Erstellen von Release Notes kostet zusätzlichen Aufwand.

Diese Vor- und Nachteile spiegeln natürlich nur meine persönlich Sicht wieder und können von Projekt zu Projekt variieren. Für mich jedenfalls überwiegen die Vorteile deutlich die möglichen Nachteile.

Vielleicht haben Sie in Projekten ähnliche Erfahrungen gemacht und könne diese beisteuern? Dann würde ich mich über eine Kommentar. Der Artikel darf auch gerne zahlreich in sozialen Medien geteilt werden.