Ist das analoge Scrum Board agiler als die digitale Projektdokumentation?

Darüber scheiden sich die Geister. Agile Romantiker schwören auf ein physisches Sprintboard, an dem man sichtbar für das Team Tag für Tag die Tasks auf „Done“ schiebt. Andere sehen die Vorteile einer digitalen Lösung und pflegen ihre Tasks in JIRA. Was ist besser, was agiler? „Ist das analoge Scrum Board agiler als die digitale Projektdokumentation?“ weiterlesen

Wer dokumentiert eigentlich im Scrum-Team?

Scrum kennt eigentlich nur drei Rollen: den Product Owner, den Scrum Master und das Entwicklungsteam. Das Entwicklungsteam setzt sich interdisziplinär aus Mitgliedern wie Programmierern, Testern, Architekten, Business Analysten oder technischen Redakteuren zusammen. Aber wer davon ist jetzt für die Dokumentation verantwortlich? „Wer dokumentiert eigentlich im Scrum-Team?“ weiterlesen

Ein Konzeptionär im Scrum-Team. Und jetzt?!

Neuen politischen Amtsträgern wird eine 100 tägige Schonfrist zugestanden. Sie sollen sich erstmal mit den Abläufen und Personen im Umfeld vertraut machen, bevor die Medien das erste Resümee ziehen. Nach einem halben Jahr und etwas mehr als 100 aktiven Sprinttagen möchte ich auch Bilanz ziehen. Was hat sich an meiner Arbeit als Konzeptionär verändert und war es die richtige Entscheidung in ein Scrum-Team zu gehen? „Ein Konzeptionär im Scrum-Team. Und jetzt?!“ weiterlesen

Definition of Ready – Weder agil noch Dokumentation?

Nachdem die letzten Beiträge sich hauptsächlich mit der Produktdokumentation beschäftigt haben, möchte ich nun eine Methodik zur Projektdokumentation vorstellen. Die „Defintion of Ready“ findet immer mehr Zuspruch in Scrum, obwohl sie in der Kritik steht, dass sie gegen agile Prinzipien verstößt.  „Definition of Ready – Weder agil noch Dokumentation?“ weiterlesen

Wann ist der richtige Zeitpunkt für Dokumentation?

Produktdokumentation ist wichtig. Das habe ich jetzt verstanden, aber während des Sprints ist oftmals nicht viel Zeit. Das Team ist ausgelastet mit der Spezifizierung und Implementierung der Anforderung. Dann muss auch noch getestet werden und das Review bereitet sich auch nicht von alleine vor. Wann bleibt also noch Zeit für Dokumentation? Mache ich sie vor dem Sprint, danach oder doch währenddessen?

„Wann ist der richtige Zeitpunkt für Dokumentation?“ weiterlesen

User Stories sind als Produktdokumentation ungeeignet

In Scrum oder anderen agilen Methoden werden User Stories eingesetzt, um ein gemeinsames Verständnis von Anforderungen zu bekommen. Mit einer alltäglichen Sprache werden Ziel und Nutzen transparent. Sie sind damit ein bewährtes Mittel um strukturiert und fokussiert zu arbeiten. Als Produktdokumentation sind sie aber eher ungeeignet. Warum ist das so? „User Stories sind als Produktdokumentation ungeeignet“ weiterlesen

Warum dokumentieren wir überhaupt?

In diesem Beitrag möchte ich mich damit beschäftigen, warum wir überhaupt dokumentieren. Dokumentation sollte kein Selbstzweck sein. Wir könnten sonst unsere wertvolle Zeit voll und ganz in die Entwicklung funktionierender Software investieren. Glaubt man dem IEEE-Standard 1471-2000 ist es die Kernaufgabe von Dokumentation, Fragen der Stakeholder zu beantworten. Kennt ihr die Fragen eurer Stakeholder? Kennt ihr eure Stakeholder?

„Warum dokumentieren wir überhaupt?“ weiterlesen

Softwaredokumentation – Ein vielschichtiger Begriff

Bevor ich in weiteren Blog-Artikeln über Dokumentation im agilen Umfeld schreibe, möchte ich mir zunächst einmal die Grundlagen zur Softwaredokumentation ansehen. Liest man den entsprechenden Wikipedia-Artikel soll eine Dokumentation zeigen, wie die Software funktioniert. Wie geht sie mit Daten um, was ist im Betrieb zu beachten und auf welcher technischen Grundlage wurde entwickelt? Das bedeutet, es kann gar nicht die eine richtige Dokumentation geben.

„Softwaredokumentation – Ein vielschichtiger Begriff“ weiterlesen

Funktionierende Software ist wichtiger als umfassende Dokumentation, aber…

Wie wichtig ist eigentlichen Dokumentation in der IT? Diese Fragestellung wird wohl schon solange diskutiert wie programmiert wird. Während fachliche Mitarbeiter am liebsten die gesamte Anwendung dokumentiert wissen wollen, reicht Entwicklern oftmals der Code selbst als Informationsquelle. Das agile Manifest entfacht diese Meinungsverschiedenheit erneut, indem es festhält: „funktionierende Software ist wichtiger als umfassende Dokumentation“. Was das für die agile Dokumentation und meine tägliche Arbeit als Business Analyst in einem Scrum-Team bedeutet, möchte ich in diesem Blog festhalten.

„Funktionierende Software ist wichtiger als umfassende Dokumentation, aber…“ weiterlesen