Sie setzen auf ein agiles Vorgehen zur Organisation ihrer agilen Entwicklung. Ihr Ansatz 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 Team zu bekommen.
Der Bedarf an Wissen und die Art der Dokumentation am Beginn und am Ende einer Iteration unterscheiden sich. Am Beginn ist umfangreiches Wissen über die angestrebte Veränderung des Produktes notwendig, damit das Team die «richtige» Lösung für jedes Problem findet. Dieses Wissen wird zu großen Teilen in Code verwandelt, z.B:
- Ein Algorithmus wird angepasst.
- Neue Geschäftsregeln werden implementiert.
- Eine Konfiguration wird verändert.
- Ein Konzept wird umgesetzt.
Am Ende der Iteration 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 Anforderung. 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.
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. Es entsteht ein Wiki, in dem alle Informationen zum Produkt stehen, z.B.:
- Das Glossar der gemeinsamen Sprache der Anwendungsdomäne.
- Fundamentale Entscheidungen und daraus abgeleitete Konzepte mit ihren Qualitätsmerkmalen.
- Die Fähigkeiten der Software mit den veröffentlichten Systemtestfällen.
- Datenflüsse in den Diensten in einem Komponentenüberblick.
- Spezifikationen der Datenobjekte in den Diensten.
Leser sind natürlich alle Mitglieder des 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 cards+ entsteht das Wiki als Teil des Produktes. Es zeigt immer einen freigegebenen, gültigen Stand der Dokumentation – in der Regel passend zum kundenwirksamen Stand des Produkts. Spezifikationen werden zusammen mit dem Code und wie Code entwickelt, geprüft, freigegeben und im Wiki veröffentlicht.