Prozesse
cards+ unterstützt iterative Prozesse
Das Ziel agiler Software-Entwicklung ist es, den Entwicklungsprozess flexibler und schlanker zu machen, als das bei den phasenorientierten Vorgehensmodellen der Fall ist. Man möchte sich mehr auf die zu erreichenden Ziele konzentrieren und auf technische und soziale Probleme bei der Entwicklung eingehen. Motivation, Selbstorganisation, Spaß an der Sache sind Schlagworte agiler Methoden. Eine Stärke von cards+ ist das vorrangige Ziel, keine umfassende Dokumentation zu erstellen, sondern Produktwissen angemessen im Wiki zu erfassen oder bereits existierende dokumentierte Informationen im Wiki zu veröffentlichen. Besonders im Bereich der Produktdokumentation geht es sogar um die Vermeidung von Dokumentation durch Veröffentlichung von lesbaren Teilen des Codes und von Testplänen der Testpyrmide.
Agile Software-Entwicklung hat uns umdenken lassen.
- Wir müssen nicht mehr alles zu Beginn des Projektes wissen.
- Wir sollen miteinander und voneinander lernen.
- Wir haben keine getrennten Teams für Analyse, Entwicklung und Test.
- Wir lieben selbstorganisierte cross-funktionale Teams.
- Niemand arbeitet in einer »Software-Fabrik«.
- Wir entwickeln das nach unserer Meinung beste Produkt.
Mit »Wir« ist dabei die gesamte Projektorganisation gemeint.
Trotzdem gibt es in agilen Entwicklungsprozessen auch den Bedarf für Anforderungsanalyse, Erwartungs-, Änderungs, Architektur- und Lizenzmanagement. Eine agile Projektorganisation bewegt sich immer in einem Spannungsfeld zwischen großer Freiheit bei der Lösungsfindung durch ein selbstorganisiertes Team und Einschränkungen des Lösungsraums aufgrund der Gesetzeslage, internationaler Normen und unternehmensweiter Vorgaben. Das ist immer kontrovers!
Zielgruppen einer Produktdokumentation.
Prozesse
Projektmanagement
Für das Projektmanagement gibt es unterschiedliche Vorgehensmodelle. Agile Ansätze setzen vor allem auf Flexibilität und Anpassung. Statt ausführlicher und umfangreicher Planung zu Beginn eines Projekts werden das adaptive Planen in Iterationen, schnelles Erkennen von Problemen (engl. fail fast) sowie die effiziente Kommunikation im Team unterstützt. cards+ kann sehr gut in agile Prozesse integriert werden.
Durch Fluktuation oder durch Veränderungen im Unternehmen entsteht ein regelmäßiger Wechsel in der Projektorganisation. Damit verbunden ist immer die Gefahr des Verlustes von Wissen. Der Verlust von Wissen ist gefährlich. Die Produktvision geht verloren. Qualität und Produktivität sinkt. Anpassungen und Erweiterungen der Software werden schwieriger. Interessierten Parteien ist nicht klar, was die Software bereits leistet. Entwickler sind weniger motiviert, da sie in altem Code wühlen müssen, um zu verstehen, wie die Software »tickt«. Ihre Innovationskraft sinkt. Das ist ein Risiko. Im Projektmanagement geht es darum, Maßnahmen einzuleiten, um beim Eintritt eines Risikos vorbereitet zu sein. Der konsequente Einsatz von cards+ bereits beim Projektstart ist so eine Maßnahme.
Der Auftraggeber und andere interessierte Parteien (z.B. Nutzer) bestimmen den Umfang des Produktes, den der Produktverantwortliche mit dem Baustein Topic dokumentiert. Wichtige Begriffe aus den Gesprächen mit Auftraggeber und Domänenexperten erfasst er sofort im Glossar. Damit und mit den Bausteinen Epic und Case legt er allein durch den Titel der Seite im Wiki die Grundlage für eine gemeinsame Sprache im Projekt. Für den Auftraggeber wichtige Qualitätsmerkmale dokumentiert der Produktverantwortliche inklusive Begründung mit dem Baustein Decision.
Einführung in die Bausteine der Produktdokumentation.
Prozesse
Anforderungsanalyse
Anforderungen sind Teil der Projektdokumentation. Sie entstehen aufgrund von Anpassung an eine veränderte Unternehmensstrategie oder Organisationsstruktur im Unternehmen. Anforderungen zum richtigen Zeitpunkt, in ausreichender Tiefe und verständlich dargestellt, das ist die Aufgabe der Anforderungsanalyse (engl. requirements engineering). Wichtige Begriffe aus den Gesprächen mit Auftraggeber und Domänenexperten erfasst der Produktverantwortliche sofort im Glossar.
Ein wichtiges Ergebnis bei der Analyse einer Anforderung ist die Abgrenzung zu anderen, geplanten oder bereits umgesetzten Anforderungen. Anforderungen können sich ergänzen, aber auch widersprechen. Es kommt auch vor, dass eine Anforderung bereits umgesetzt ist, also ein Duplikat ist. Diese Konflikte müssen vom Produktverantwortlichen zusammen mit den interessierten Parteien geklärt werden. Wichtig ist auch, dass der Produktverantwortliche die wertvollen Analyseergebnisse sicher und schnell im Wiki erfassen kann, zum Zeitpunkt, an dem er sie zusammen mit dem Auftraggeber und Domänenexperten erzielt.
Jede Anforderung muss sich in den Grenzen bewegen, die mit dem Baustein Topic gesetzt werden. Das ist gleichzeitig die erste Validierung einer Anforderung. Der Produktverantwortliche nutzt eine Anforderung, um mindestens eine Fähigkeit der Software zu identifizieren, die entweder geändert, neu hinzugefügt oder sogar entfernt werden soll. Mit der fachlichen Beschreibung in den Bausteinen Epic und Case folgt die weitere Validierung einer Anforderung. Erst durch die »Projektion« einer Anforderung auf Fähigkeiten des Produktes wird sie realisiert und dokumentiert.
Der Produktverantwortliche hat mit dem Baustein Layout die Möglichkeit, den Entwurf für ein Element der Bedienoberfläche als Ergebnis der Analyse zu sichern. Er kann auf Veränderungen durch Feedback der Domänenexperten reagieren und den Entwurf anpassen.
Eine Bedienoberfläche verfolgt immer ein bestimmtes Bedienkonzept. Die Größe des Bildschirmes (z.B. Watch, Smartphone, Tablet, Monitor, UHD-TV) und die Möglichkeiten der Eingabe (z.B. Maus, Tastatur, Stift, Berührung) beeinflussen die Gestaltung der Bedienoberfläche. Ein Bedienkonzept verfolgt auch das Ziel einer Standardisierung der Elemente der Bedienoberfläche durch eine Gestaltungsrichtlinie (engl. style guide). Jedes Bedienkonzept wird mit dem Baustein Spec erfasst und bekommt durch den Titel der Seite im Wiki einen eindeutigen Namen.
Bei der Analyse von Anforderungen kommt häufig der Punkt, an dem sich Auftraggeber und Domänenexperten für eine von mehreren Lösungen entscheiden müssen, eine Fähigkeit in der Software umzusetzen. So eine für die Entwicklung richtungsweisenden Entscheidung dokumentiert der Produktverantwortliche inklusive Begründung mit dem Baustein Decision.
Einführung in das strategische Design.
Prozesse
Produktentwicklung
Für eine effektive, zielgerichtete Entwicklung ist es essentiell, dass das Team alle Probleme vollständig versteht, damit es eine passende und wirtschaftlich vertretbare Lösung finden kann. Mit den Bausteinen der Systembeschreibung kann der Produktverantwortliche den Problemraum des Produktes darstellen. Die vom Team gewählte Lösung beschreibt er oder ein Vertreter des Teams in Bausteinen der Systemstruktur. Mit dem Abschluss einer Implementierung durch das Team wird die Spezifikation im Wiki aktualisiert. Die Verbindung zwischen Systembeschreibung und Systemstruktur bildet der Baustein Case.
Agilität schafft Vorteile für alle Prozesse. Hier herrscht mittlerweile große Einigkeit. Scrum ist eine Methode, die eine praktikable Lösung für agile Produktentwicklung anbietet, für andere Prozesse aber keine Aussagen trifft. Das gilt besonders für den Bereich Dokumentation. Das Manifest für agile Software-Entwicklung fordert, dass ein fertiges Produkt einen höheren Wert hat als eine umfangreiche Dokumentation. Das ist richtig. Aber es bedeutet nicht den Verzicht auf Dokumentation. Eine angemessene Dokumentation ist exakt im Sinn des Manifests. Das ist eine wichtige Erkenntnis.
Wissensmanagement ist ein Thema, dass in agilen Entwicklungsprozessen immer wieder zu wenig oder gar nicht beachtet wird. Wissen muss erarbeitet, gesammelt, geprüft und veröffentlicht werden. Niemand wünscht Kopfmonopole. Kommunikation alleine kann Wissensinseln nicht verhindern. Eine angemessene Produktdokumentation kann die Lücke schließen. Ein inkrementelles Vorgehen wie bei cards+ macht die Erstellung und Pflege einer Produktdokumentation in hoher Qualität zu einer leistbaren Aufgabe.
Besonders im Zusammenhang mit verteilter Fertigung ist eine Produktdokumentation ein ganz wichtiger Faktor für den Erfolg des Projektes. Es ist ein Vorteil, eine gemeinsame Sprache in der Projektorganisation zu etablieren, die auch im Code und in den Testplänen Verwendung findet. Dabei geht es um eindeutige Begriffe, die auch von interessierten Parteien gesprochen und verstanden wird. Ein gut gepflegtes Glossar unterstützt dieses Vorhaben.
Einführung in das taktische Design.
Zielgruppen
Dokumentation betrifft jeden
Die Betroffenheit einer Person von einer Sache lässt sich sehr schön durch die Fabel vom Huhn (engl. chicken) und vom Schwein (engl. pig) erklären. Eine Partei ist beteiligt (engl. committed), die andere interessiert (engl. involved).
The Chicken says: » Hey Pig, I was thinking we should open a restaurant! «
Wikipedia
Pig replies: » Hm, maybe, what would we call it? «
The Chicken responds: » How about ‘ham-n-eggs’? «
The Pig thinks for a moment and says: » No thanks. I’d be committed, but you’d only be involved. «
Beteiligt sein bedeutet, von einer Sache überzeugt zu sein, sich persönlich dafür einzusetzen, etwas zu tun. Interessiert sein hingegen bedeutet, sich lediglich mit einer Sache zu befassen. Agile Software-Entwicklung verstärkt die Bedeutung beteiligter Personen und schützt sie vor dem negativen Einfluß interessierter Parteien. Feedback zum Produkt will ein Produktverantwortliche aber von allen Zielgruppen, ohne Einschränkung und immer wertschätzend.
Die Zielgruppen der Produktdokumentation sind ganz allgemein interessierte Parteien sowie die Projekt- und Betriebsorganisation. Für das Gelingen einer Produktdokumentation muss der Produktverantwortliche es schaffen, das sich alle Zielgruppen (oder deren Vertreter) mindestens als Leser beteiligen. cards+ unterstützt ihn bei diesem Versuch.
Zielgruppen
Interessierte Parteien
Ein Auftraggeber ist eine interessierte Partei mit einem starken wirtschaftlichen und strategischen Interesse am Produkt. Der Auftraggeber ist erster Ansprechpartner für den Produktverantwortlichen. Er ist Leser der Produktdokumentation. Die Bausteine der Systembeschreibung verwendet der Auftraggeber für seine Gespräche mit Fachabteilungen. Sie helfen ihm, die Fachabteilungen als Vertreter der Nutzer und als Geldgeber zu motivieren, Verbesserungen oder Erweiterungen an der Software zu beauftragen. Sie diskutieren in einer gemeinsamen Sprache und profitieren dabei vom Glossar. Bei Verhandlungen ist es sehr praktisch, wenn eine Produktdokumentation existiert, die einen Überblick (engl. big picture) über das Produkt vermitteln kann. Das Wissen über bereits realisierte Fähigkeiten der Software hilft bei einer schnellen Einschätzung einer Anforderung an das IT-System.
Nutzer sind interessierte Parteien und Experten für das IT-System. Individuelle Software wird in der Regel produziert, um Geschäftsprozesse im Unternehmen zu unterstützen. Nutzer arbeiten effizienter und machen weniger Fehler, weil unternehmensspezifische Abläufe und damit verbundene besondere Fähigkeiten in der Software abgebildet werden. Nutzer sind auf jeden Fall Leser für Handbücher und Online-Hilfen. Nutzer sind aber auch Leser der Produktdokumentation, wenn sie der Produktverantwortlicher als Domänenexperten für die Anforderungsanalyse hinzuzieht.
Zielgruppen
Projektorganisation
Ein Projekt ist nach üblicher Definition ein Vorhaben mit mindestens einem Ziel, einem Anfang und einem Ende. Eine Projektorganisation umfasst alle Personen, die an diesem Vorhaben mitwirken. Im Zusammenhang mit agiler Software-Entwicklung reden wir konkret von einem Produktverantwortlichen und einem Realisierungsteam. Das Team setzt sich zusammen aus Analysten, Entwicklern, Testern und Redakteuren. Analysten unterstützen den Produktverantwortlichen im Projektmanagement und in der Anforderungsanalyse. Entwickler und Tester entwickeln die Software. Redakteure kümmern sich um professionelle Handbücher und unterstützen den Produktverantwortlichen beim Marketing für das Produkt. In einem Scrum-Prozess kommt noch der Scrum-Master dazu. Ein Projektleiter ist immer dann notwendig, wenn nur das Entwicklungsprojekt agil ist, der Auftraggeber aber eher klassisch unterwegs ist.
Der Produktverantwortliche ist Autor der Bausteine der Systembeschreibung. Er nutzt die Bausteine für sein Backlog-Management. Entwickler und Tester im Team sind damit automatisch Leser der Systembeschreibung.
Der Produktverantwortliche und Vertreter des Teams sind Autoren der Bausteine der Systemstruktur. Sie teilen sich die Arbeit. Der Produktverantwortliche arbeitet im Wiki. In Abstimmung mit dem Team legt er Bausteine für Dienste und Objekte an. Vertreter des Teams veröffentlichen Teile vom Code, code-nahe Artefakte oder Spezifikationen im Wiki, sobald sie ihrer Implementierung an den Diensten und Objekten abgeschlossen haben. Tester aus dem Team veröffentlichen Testpläne im Wiki. Außerdem untersützen das Team den Produktverantwortliche bei der Formulierung der Essenzschritte der Lösung im Baustein Case — mindestens mit ihrem Feedback als Leser.
Der Produktverantwortliche und Vertreter des Teams sind Autoren der Bausteine für den Architekturentwurf. Sie nutzen den Baustein Decision für die Erfassung und Begründung wichtiger Entscheidungen. Den Baustein Spec verwenden sie, um ein wiederkehrendes Entwurfsmuster bei der Implementierung (engl. software pattern) oder ein übergreifendes Konzept produktspezifisch zu beschreiben.
Das Konzept der DevOps, also die Kombination von Entwickler (engl. developer) und Betreiber (engl. operator) von Software, ist aus einem agilen Entwicklungsprojekt nicht mehr wegzudenken. Entwickler begleiten die Software bis zur kundenwirksame Produktionsumgebung. Als Autoren der Handlungsanweisungen haben sie die Aufgabe, bereits während der Entwicklung der Software über Installation und Betrieb nachzudenken.
Zielgruppen
Betriebsorganisation
Die Betriebsorganisation umfasst als Zielgruppe alle Personen, die Verantwortung für den kundenwirksamen Betrieb tragen. Ein Betreiber (engl. operator) ist notwendig, um ein IT-System unterbrechungslos und störungsfrei zu betreiben. Dazu muss ein Unternehmen spezielles Personal haben, das einem Schichtbetrieb einen täglich verfügbaren 24-stündigen Bereitschaftsdienst dauerhaft aufrechterhalten kann. Diese Zielgruppe hat naturgemäß sehr hohe Erwartungen an die Qualität der Software.
Betreiber sind Leser der gesamten Produktdokumentation. Sie brauchen ein grundlegendes Verständnis der Software. Die Bausteine der Systemstruktur vermitteln genau dieses Wissen. In den Spezifikationen finden sie Informationen über die eingesetzten Technologien und Qualitätsmerkmale der Kategorien Sicherheit Zuverlässigkeit. Der Baustein Service zeigt die Zusammenhänge zwischen einem abstrakten Dienst und der Infrastruktur, in der die Prozesse betrieben werden. Die Bausteine Event und Entity helfen ihnen beim Verstehen von Datenflüssen im IT-System.
Das Konzept der DevOps, also die Kombination von Entwickler (engl. developer) und Betreiber (engl. operator) von Software, ist aus einer effizienten Betriebsorganisation nicht mehr wegzudenken. Betreiber sind mindestens Co-Autoren der Handlungsanweisungen für das IT-System. Sie kümmern sich um die Veröffentlichung der Handlungsanweisungen und geben es als Betriebshandbuch frei.
Geschichten aus der Praxis
Der Reise-Butler ist eine Geschichte über ein fiktives Software-Entwicklungsprojekt mit dem Ziel, eine intelligente Smartphone-App für die Begleitung eines Reisenden zu realisieren. Der Reise-Butler ist gleichzeitig ein Fallbeispiel für den Einsatz von cards+.
Jetzt lesenDie folgenden Kurzgeschichten enthalten gedankliche Experimente und Visionen im Zusammenhang mit cards+. Wie in einer Fabel steckt in jeder Kurzgeschichte mindestens ein Körnchen Wahrheit, ein Stück persönlich erlebter Realität.