CARDS+

Category: Artikel (page 1 of 5)

Die Methode CARDS+ in der Theorie.

Umgebungsübersicht

In einem IT-System ist jede Komponente ein Knoten in einem mehr oder weniger komplexen Netzwerk. Eine Umgebungsübersicht ist ein zentraler Anlaufpunkt für die Betriebsorganisation, aber auch für Entwickler und Tester. Sie beinhaltet Informationen über die Version jeder Komponente, welche Komponente wie oft als Instanz existiert, wie viel Speicher sie verwendet oder wie ihr aktueller Zustand ist. Abhängig von der gewählten Architektur zeigt so eine Übersicht noch viele weitere Merkmale.

Continue reading

Betriebsanweisungen

Es ist offensichtlich, dass ein Restaurant wesentlich effektiver (also gewinnbringender) funktioniert, wenn Köche und Kellner ihre Aufgaben beherrschen und gut zusammenarbeiten. Sowohl Koch als auch Kellner haben Aufgaben, die sie wiederholt ausführen. Der Koch muss die Erwartungen der Gäste des Restaurants erfüllen und die Speisen so zubereiten, wie sie in der Speisekarte stehen. Der Kellner muss wissen, wie er einen Tisch eindeckt und wie er Getränke und Speisen serviert. Das Konzept der DevOps überträgt diese Gedanken auf die agile Software-Entwicklung. Product-Owner (Chefkoch) und das cross-funktionale Scrum-Team (Entremetier, Gardemanger, Pâtissier und Saucier) liefern ein Produkt (Speisen). Die Betriebsorganisation (u.a. Kellner) definiert Qualitätsanforderungen, achtet auf die Einhaltung der Qualität des Produktes und macht es für die Nutzer (Gäste) verfügbar.

Continue reading

Qualität sichtbar machen

In einem Vortrag über Herausforderungen und Ergebnisqualität der Pflege im Gesundheitswesen des 21. Jahrhundert war das Motto «Gutes tun und es gut tun». Die Autorin hat gleich zu Beginn ein paar sehr gute Fragen gestellt, die ich für die Methode CARDS+ und für die Frage der Autoren nach der Qualität einer Produktdokumentation adaptieren konnte:

  1. Wie wissen wir, dass wir es «gut tun»?
  2. Wissen alle Entwickler und Tester im Projekt, dass wir es «gut tun»?
  3. Weiß die Betriebsorganisation, dass wir es «gut tun»?
  4. Wissen die Stakeholder und Nutzer, dass wir es «gut tun»?

Die Antwort bei Punkt 1 ist noch leicht zu beantworten. Im agilen Umfeld, speziell bei Scrum, gibt es die sogenannte «prime directive»:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
Norman L. Kerth

Punkt 1 ist unser Ziel und wir glauben fest daran, dass jeder sein bestes dazu tut. Schaffen wir es, alle Personengruppen als Leser unserer Produktdokumentation zu gewinnen, dann können wir jede Frage mit einem klaren Ja beantworten.

Continue reading

Qualität durch Beschränkung

Agile Entwicklung mit Scrum hat aus gutem Grund Regeln, die alle einzuhalten sind. Scrum ist es nur, wenn die drei Rollen Product-Owner, Scrum-Master und Team besetzt sind, das Team in regelmäßigen Sprints ein Product-Backlog abarbeitet und kontinuierlich Produktinkremente liefert. Jeder Sprint wird gemeinsam geplant (Refinement, Planning). Am Ende jedes Sprints gibt es eine Präsentation der Sprint-Ergebnisse (Review). Nur so funktioniert Scrum. Eine Vereinfachung (z.B. Weekly statt Daily) birgt das Risiko, dass das Vorgehen nicht mehr die gewünschten Ergebnisse liefert. Jede grundsätzliche Veränderung führt dazu, dass die Methode nicht mehr funktioniert. Die Änderung der Sprint-Ziele während des Sprints wird gerne als besonders agil bezeichnet. Mit Scrum hat diese Art der Agilität aber nichts zu tun.

Gleiches gilt auch für CARDS+. Die Struktur des Wiki, die Bausteine und Prinzipien und Praktiken sind aufeinander abgestimmt. Nur im Wiki kann inkrementell dokumentiert werden. Die Bausteine sind so gestaltet, dass Wissen schrittweise erfasst wird, vom Groben ins Feine. Code und Test werden berücksichtigt und definieren die Grenzen der Produktdokumentation.

Continue reading

Qualität ist Kopfsache

Ein ganz wesentliches Ziel der Methode CARDS+ ist die Qualität der Inhalte. Prinzipien und Praktiken der Methode sollen unter anderem Autoren die Pflege einer Produktdokumentation im Wiki so einfach wie möglich machen. Die wohl wichtigsten Leitsätze sind:

  • Erfasse jede Information nur an einer Stelle im Wiki.
  • Erfasse nur jene Information, für die es Leser gibt.
  • Erfasse keine Information im Wiki, die an einer anderen Stelle bereits ausreichend beschrieben wurde.
  • Lass jede Änderung mindestens einmal prüfen.
  • Ignoriere keinen Fehler.

Beachten wir sie nicht, ist es sehr wahrscheinlich, dass Inhalte im Wiki sprichwörtlich verderben. Das Schlimme an den verdorbenen Dokumenten ist, dass wir sie niemals sofort erkennen.

Continue reading

Qualität braucht Kompetenz und Verantwortung

“Code smells”, sagte Kent Beck. Bei übel riechendem Code handelt es sich allgemein um Code, der einer gemeinsamen Vorstellungen von guter und lesbarer Programmierung nicht entspricht. Gleiches gilt auch für Texte einer Produktdokumentation im Wiki. Sie brauchen eine Struktur. Kein Scrum-Team braucht literarisch wertvolle Werke. Texte werden von ihnen genutzt, um ein technisches System zu entwerfen und bauen. Wortwiederholungen sind auf jeden Fall gewünscht, Begriffe werden immer gleich benutzt, Doppeldeutigkeiten vermieden.

Ein Wiki ist ein Werkzeug, mit dem die Dokumentation für ein Software-Produkt schnell und sicher erstellt werden kann. Die Methode CARDS+ stellt sicher, dass diese Dokumentation in hoher Qualität dauerhaft erhalten bleibt. Sowohl Werkzeug als auch Dokumentation müssen gepflegt werden. Ein Gärtner ist eine Person, die dafür Verantwortung übernimmt.

Continue reading

Inkrementell schätzen

Scrum ist eine agile Methode. Sie beinhaltet auch Planung. Statt ausführlicher und umfangreicher Planung zu Beginn eines Projekts werden das schrittweise Planen sowie die schnelle Abstimmung im Team gesucht. Mit einer Product-Roadmap legt der Product-Owner seine Ziele für das Produkt fest. Im Unterschied zu phasenorientierten Vorgehensweisen ist aber der Planungshorizont für eine detaillierte Planung kleiner. Der Product-Owner plant mit Hilfe seines Product-Backlog mindestens zwei bis drei Sprints im voraus. Das Entwicklungsteam plant seinen nächsten Sprint.

Jede Art der Planung erfordert immer eine Abschätzung der Aufgaben hinsichtlich Komplexität und Machbarkeit im Rahmen des Projektes.

02d-inkrementell-schatzen

Continue reading

Wissen wird transformiert

Der Begriff Transformation geistert schon lange durch die Welt der IT. Digitale Transformation ist ein Schlagwort für die ganze Branche. Ich möchte mich aber mit einer Form der Transformation beschäftigen, die ganz sicher nicht neu ist: Die Transformation von Wissen in Software. Dabei geht es mir diesmal nicht um die Frage, wie solches Wissen strukturiert erfasst wird oder wie der Prozess der Transformation – die agile Software-Entwicklung – abläuft. Ich beschäftige mich mit dem Problem, dass diese Transformation von Wissen in Software ganz offensichtlich Redundanzen schafft.

01b-wissen-wird-transformiert

Continue reading

Inkrementell dokumentieren

Jedes inkrementelle Vorgehensmodell basiert auf der Idee der kleinen Schritte zur Reduktion der Komplexität. Mit dem Cynefin-Framework können wir die evolutionäre Natur komplexer Systeme veranschaulichen. In den Inkrementen reduzieren wir jedes vorliegende komplexe Problem in ein kompliziertes, manchmal sogar offensichtliches Problem. Damit machen wir ein komplexes Problem beherrschbar. Wir wollen maximal flexibel gegenüber Veränderungen sein, ohne in Chaos abzudriften.

17-inkrementell-dokumentieren

Die agile Software-Entwicklung basiert auf einem inkrementellen Vorgehen. In einem Wiki arbeiten wir auch nach diesem Prinzip, denn Wissen kann inkrementell erfasst werden.

Continue reading

Die große Chance!

Agile Methoden im Projekt- und Produktmanagement, in der Anforderungsanalyse und bei Realisierung, Test, Einführung und Betrieb sind große Herausforderungen für jede Projektorganisation. Häufig sind die Entscheider in diesen Projekten Personen, die nicht überzeugt sind von Agilität, ein eigenes Verständnis davon haben (z.B. agil mit chaotisch verwechseln) oder ganz einfach nichts oder zu wenig darüber wissen. Dadurch entstehen ganz spezielle Prozesse, ein projektspezifischer Mix aus Vorgehensmodellen. Akzeptieren wir die Tatsache, dass für etablierte Management-Prozesse Lastenheft, Pflichtenheft und vor allem Expertenschätzungen notwendig sind, dann ergibt sich mit der Verwendung von CARDS+ die Chance, diese Inhalte gewinnbringend und qualitätsfördernd für die Realisierung zu erhalten.

15 Die große Chance

Continue reading

Olderposts

Copyright © 2018 Impressum Datenschutz

Zum Anfang ↑