cards+ unterstützt eine Projektorganisation bei dem Vorhaben, Wissen dauerhaft zu sichern. Mit cards+ wird Produktwissen angemessen im Wiki erfasst oder bereits existierende dokumentierte Informationen aus anderen Quellen im Wiki zu veröffentlicht. cards+ steht nicht in Konkurrenz zu agilen Methoden wie «XP», «Scrum» oder «Kanban», sondern ergänzt sie optimal.
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.
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.
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 Concept 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.
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. 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 einem Wiki in hoher Qualität zu einer leistbaren Aufgabe für eine Projektorganisation.
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.
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!«
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.«
Wikipedia
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 (engl. stakeholder) sowie die Projekt- und Betriebsorganisation. Für das Gelingen einer Produktdokumentation muss der Produktverantwortliche es schaffen, dass sich viele Personen aus allen Zielgruppen mindestens als Leser beteiligen. cards+ unterstützt ihn bei diesem Versuch.
Ein Auftraggeber ist eine interessierte Partei mit einem starken wirtschaftlichen und strategischen Interesse am Produkt. 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. Bei seinen Gesprächen mit Fachabteilungen diskutieren sie in einer gemeinsamen Sprache und profitieren dabei vom Glossar.
Eine Fachabteilungen umfasst alle Personen, die das IT-System als Nutzer verwenden. 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 werden vom Produktverantwortlichen als Domänenexperten für die Anforderungsanalyse und für den Test hinzugezogen.
Eine Projektorganisation umfasst alle Personen, die an einem Projekt mitwirken. Im Zusammenhang mit agiler Software-Entwicklung reden wir konkret von einem Produktverantwortlichen und einem Realisierungsteam. Das Realisierungsteam setzt sich zusammen aus Analysten, Entwicklern, Testern und Redakteuren. Analysten unterstützen den Produktverantwortlichen im Projektmanagement und in der Anforderungsanalyse. Entwickler und Tester programmieren und testen die Software. Redakteure kümmern sich um professionelle Handbücher und unterstützen den Produktverantwortlichen beim Marketing für das Produkt.
Eine Betriebsorganisation umfasst 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. 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. Diese Zielgruppe braucht ein grundlegendes Verständnis für die Software und hat naturgemäß sehr hohe Erwartungen an die Qualität der Software.