Prozesse
Scrum
Sie setzen auf Scrum zur Organisation ihrer agilen Entwicklung. Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Schritt für Schritt wird ihr Team besser und schneller. Selbstorganisiert. Maximal Motiviert. Ihr Fokus liegt auf Qualität und Exzellenz. In kurzen Zyklen entwickeln Sie kundenwirksame Inkremente.
Wo volle Flexibilität verlangt ist, braucht es möglichst vollständige und zuverlässige dokumentierte Informationen. Besonders wichtig in einem agilen Umfeld ist es, die Tätigkeit des Dokumentierens als Aufgabe in das Dev-Team zu bekommen. Der Bedarf an Wissen und die Art der Dokumentation am Beginn und am Ende eines Sprints unterscheiden sich. Am Beginn des Sprints ist umfangreiches Wissen über die angestrebte Veränderung des Produktes notwendig, damit das Scrum-Team die “richtige” Lösung für jede Story im Sprint findet. Während des Sprints wird dieses Wissen vom Dev-Team zu großen Teilen in Code verwandelt: Ein Algorithmus wird angepasst oder neue Geschäftsregeln werden implementiert, eine Konfiguration wird verändert, ein Konzept wird umgesetzt. Am Ende des Sprints muss nur mehr das Ergebnis der Veränderungen dokumentiert werden. Die Spezifikation enthält jetzt eine Beschreibung des angepassten Algorithmus und die neuen Geschäftsregeln. Systemtestfälle entstehen als Ergebnis der Akzeptanzkriterien einer Story. Sie überprüfen die neue Fähigkeit der Software und werden automatisch ausgeführt. Gleichzeitig beschreiben Systemtestfälle die neue Fähigkeiten. Sie sind ausführbare Dokumentation.
Ein wichtiges Element von Scrum ist das Sprint-Review am Ende eines Sprints. Dort zeigt das Dev-Team, was es erreicht hat, in der Regel als Demonstration am aktuellen Inkrement. Sie berichten über erledigte und nicht-erledigte Aufgaben, aber nur erledigte Aufgaben werden gezeigt und anhand der Akzeptanzkriterien geprüft. Eine angemessene Dokumentation ist bei jedem einigermaßen komplexen Produkt gefordert und in den allgemeinen Fertigstellungskriterien (engl. definition of done) geregelt. Da ist der Umfang nicht immer klar.
Mit dem Einsatz von cards+ werden große Teile der Dokumentation im Wiki durch automatisierbare Veröffentlichung aus der Code-Basis aktualisiert. Ohne spürbaren zusätzlichen Aufwand. Übrig bleibt ganz wenig Dokumentation, die direkt im Wiki angelegt oder dort geändert werden muss: Ein neuer Begriff im Glossar, ein neuer Dienst oder ein neuer Datenfluß im IT-System. Je reifer eine Software, desto stabiler ist die Struktur im Wiki. Der Fortschritt wird sichtbar durch die kleinen Veränderungen in den Spezifikationen. Dort ein Attribut mehr im Nachrichtenobjekt, da eine neue Operation im REST-API eines Dienstes.
Mit dem Einsatz von cards+ entsteht ein Wiki, in dem alle Informationen zum Inkrement stehen, z.B.:
- Das Glossar der gemeinsamen Sprache der Anwendungsdomäne.
- Fundamentale Entscheidungen im Baustein Decision und daraus abgeleitete Konzepte mit ihren Qualitätsmerkmalen im Baustein Spec.
- Die Fähigkeiten im Baustein Case mit den veröffentlichten Systemtestfällen.
- Dienste und ihre Datenflüsse in einem Komponentenüberblick.
- Aktuelle, aus der Code-Basis stammende Spezifikationen der Dienste im Baustein Service und Objekte in den Bausteinen Entity und Event.
Leser sind natürlich alle Mitglieder des Scrum-Teams, aber auch alle interessierten Parteien. Sie alle können ihr spezielles Produktwissen nutzen, um Feedback zu geben, kontinuierlich, zielgerichtet und moderiert vom Produktverantwortlichen oder einem Gärtner in seinem Auftrag.
Mit dem Einsatz von cards+ wird klar zwischen der Präsentation des Inkrementes im Wiki und der Bearbeitung von Spezifikationen als Teil der Code-Basis unterschieden. Das Wiki zeigt immer einen freigegebenen, gültigen Stand der Dokumentation – in der Regel passend zum kundenwirksamen Produkt. Eine Spezifikation wird zusammen mit dem Code und wie Code entwickelt, geprüft, freigegeben und “installiert”.