CARDS+

Tag: FAQ

Was beschreibt der Baustein Task?

Komplexe IT-Systeme bestehen aus Software, Middleware und Hardware. Der Betrieb eines IT-Systems stellt nicht erst seit der Idee der DevOps eine große Herausforderung an eine Betriebsorganisation. Moderne Systeme sind heterogen in vielerlei Hinsicht. Software wird von den Entwicklern in verschiedenen Programmiersprachen entwickelt. Eine Architektur mit Microservices oder die Verwendung der Cloud führt zu einer Vielzahl von Komponenten, die mit unterschiedlichen Technologien realisiert werden. Datenbanken haben relationale Modelle oder sind dokumenten- oder graphenbasiert. Verteilte Datenverarbeitung mit Events oder Microbatches spielt durch den Bedarf an Big-Data-Lösungen eine immer größere Rolle. Die Liste ließe sich noch fortsetzen.

Continue reading

Was beschreibt der Baustein Case?

Mit einer Anforderung drückt ein Stakeholder einen aus seiner Sicht wichtigen Bedarf an einer Erweiterung oder Änderung des Software-Produktes aus. In der Analyse der Anforderung wollen Product-Owner, Business-Analysten und das cross-funktionale Team einen Einblick in das fachliche Problem bekommen und ein gemeinsames Verständnis über Ziele und Lösungen entwickeln. Wir machen uns auch Gedanken über die Auswirkungen der Umsetzung. Das Sammeln von relevanten Informationen (das Produktwissen) und das Einholen von Feedback aus den Fachabteilungen ist ein ganz wichtiger Teil der Analyse.

Ein Case ist das Ergebnis von Entscheidungen aus dem Backlog-Management agiler Software-Entwicklung.

In der Methode CARDS+ untersuchen wir jede Anforderung vom Groben (als Epic) ins Feine (als Case). Über den beiden schwebt noch die Zuordnung zum Aufgabenbereich (als Topic).

Continue reading

Was beschreibt der Baustein Manual?

Das Benutzerhandbuch ist das “Buch”, in dem die Bedienung der Software für die Nutzer beschrieben ist. Es ist Teil der Produktdokumentation. Projekte planen die Aktualisierung des Benutzerhandbuches gerne so spät wie möglich. In Projekten mit klassischen Vorgehensmodell  (“Wasserfall”) ist sowas noch einigermaßen gut planbar. Mit den agilen Methoden in den Projekten ergibt sich das Problem, dass am Ende des Sprints auch das Benutzerhandbuch fertig sein muss. Das ist meiner Ansicht nach nur schwer leistbar, weil der Großteil der Arbeit in der Gestaltung des Inhaltes liegt – fehlerfreie Inhalte vorausgesetzt. Oft ist die Gestaltung des Benutzerhandbuches und die Art der Veröffentlichung an Vorgaben des Unternehmens gebunden. Es ist auch schwer vorstellbar, dass jedes cross-funktionale Team die Rolle des technischen Redakteurs besetzen kann, wie es für ein professionelles Handbuch notwendig ist.

Im Zusammenhang mit der Spezifikation von Benutzeroberflächen der Anwendung unterscheiden wir Layouts und Manuals. Beide Artefakte haben das Ziel, die Benutzeroberfläche zu beschreiben.

In einem Manual beschreiben wir die Verwendung der Benutzeroberfläche, also das gewünschte fachliche Verhalten aus Sicht der Nutzer. Manuals sind als ideal geeignet, um daraus Testfälle abzuleiten. Aus diesem Grund werden während der Realisierung einer Benutzeroberfläche – hier verwenden wir die Layouts – für den Test bereits die Manuals erstellt. Wir legen für jeden Anwendungsfall, der durch die Akzeptanzkriterien einer User-Story gefordert wird, ein Manual an und beschreiben dort aus Sicht des Nutzers die besonderen Randbedingungen für die Verwendung der Benutzeroberfläche.

Continue reading

Was beschreibt der Baustein Layout?

Benutzeroberflächen sind das für die Nutzer sichtbare Ergebnis unseres Projektes. Zum einen unterstützt die Benutzeroberfläche Abläufe innerhalb von Geschäftsprozessen des Unternehmens. Auf der anderen Seite stellen die Daten, die mithilfe der Benutzeroberfläche erfasst werden, einen hohen Wert für die Nutzer und das Unternehmen dar. In der Benutzeroberfläche einer Anwendung steckt daher ein enormes Wissen. Dieses Wissen gilt es zu sichern.

In einem Layout beschreiben wir die Gestaltung und die Struktur der Benutzeroberfläche. Layouts benötigen wir bereits vor dem Start des Sprint in der geforderten Qualität. Mit bestimmten Typen von Layouts wird bereits in der Analyse der Versuch unternommen, wiederverwendbare Elemente der Benutzeroberfläche zu identifizieren. Teilbereiche der Benutzeroberfläche erfassen wir als Layouts vom Typ Panel. Der Designer der Benutzeroberfläche gibt dem Entwickler damit frühzeitig den Hinweis, dass es Potential für eine wiederverwendbare Software-Komponente gibt. Weitere Bausteine für eine geplante Wiederverwendung sind Layouts vom Typ Prompt und Widget.

Continue reading

Was beschreibt der Baustein Epic?

Ein Software-Produkt entsteht durch einen konkreten Bedarf (englisch: need) einer Fachabteilung in einem bestimmten Geschäftsfeld. Oft steckt hinter dem Bedarf eine Vision oder Idee, wie ein Problem gelöst oder ein Prozess optimiert werden kann. Die Reduktion von Kosten oder eine Gewinnmaximierung ist in unserer wirtschaftlich geprägten Welt ebenfalls eine große Motivation der Auftraggeber. Der Product-Owner oder ein Business-Analyst hat die Aufgabe, eine Anforderung des Auftraggebers (englisch: requirement) für alle im Projekt “begreifbar” zu machen. Wir kennen unser System und bewerten und beschreiben den konkreten Wunsch eines Stakeholders, “sein” Produkt zu verändern.

Ein Epic ist das Ergebnis der Anforderungsanalyse.

In der Methode CARDS+ untersuchen wir jede Anforderung vom Groben (als Epic) ins Feine (als Case). Über den beiden schwebt noch die Zuordnung zum Aufgabenbereich (als Topic).

Continue reading

Was beschreibt der Baustein Topic?

Anforderungen an ein System entstehen in den Fachabteilungen aus einem Bedarf, den die Nutzer des Systems haben oder aufgrund von Anpassung an eine veränderte Unternehmensstrategie oder Organisationsstruktur im Unternehmen. Fachabteilung arbeiten innerhalb der Grenzen von Geschäftsbereichen. Anforderungen können daher eindeutig Geschäftsprozessen zugeordnet werden. Konkrete Aufgabenbereiche können wir in den meisten Fällen bereits beim Start des Projektes identifizieren.

Ein Topic ist das Ergebnis von Entscheidungen im Projekt-Management.

Wissen wird nicht vollständig auf einmal vermittelt, sondern wird in einem Prozess erarbeitet. Darum ist es wichtig, einen groben Rahmen zu kennen, an dem wir entscheiden können, dass eine Anforderung überhaupt zum System passt.

In der Methode CARDS+ untersuchen wir jede Anforderung vom Groben (als Epic) ins Feine (als Case). Über den beiden schwebt noch die Zuordnung zum Aufgabenbereich (als Topic).

Continue reading

Prinzipien und Praktiken

Die Initiative der «clean code developer» für mehr Professionalität in der Softwareentwicklung ist ein von mir persönlich geschätzter Katalog von Prinzipien und Praktiken, die uns zu professionelleren, besseren Entwicklern machen (sollen). Ich behaupte, dass sich diese und viele andere Prinzipien der Entwickler ganz leicht auch auf das Dokumentieren in einem Wiki anwenden lassen. Diese Prinzipien und ihre praktische Umsetzung sind ein wichtiger Teil der Methode CARDS+. Nur auf die bunten Bändern kann ich persönlich verzichten.

Continue reading

Warum brauchen wir eine Icon-Sammlung?

Jedes Software-Produkt mit einer grafischen Benutzeroberfläche verwendet Icons. Ein Icon ist ein Piktogramm, die auf einen Blick und so eindeutig wie möglich eine Funktionen des Systems darstellt. Gerade im Hinblick auf die Akzeptanz durch einen großen Nutzerkreis haben Icons ein einheitliches Erscheinungsbild (englisch: look and feel). Viele Icons fassen wir zu einer Icon-Sammlung zusammen. Es ist die konkrete Umsetzung einer Medienbibliothek für Icon-Dateien.

Continue reading

Warum brauchen wir eine Link-Sammlung?

Ein Wiki egal welchen Herstellers ist immer nur für einen gewissen Teil der Dokumentation geeignet. Selbst unsere Produktdokumentation befindet zur Vermeidung von Redundanzen nicht nur im Wiki.

  • Vertragsrelevante Unterlagen müssen in einem revisionssicheren Dokumentenverwaltungssystem gespeichert werden.
  • Schnittstellenspezifikationen werden von Partnersystemen zur Verfügung gestellt.
  • Unternehmensweite Richtlinien und Vorgaben befindet sich im Intranet.
  • Tutorials und API-Dokumentation befinden sich im Internet.
  • Unterlagen zur Code-Generierung (z.B. ein Meldungskatalog) befinden sich in einem Repositiory.

Eine Link-Sammlung ist immer dann notwendig, wenn eine Produktdokumentation in verschiedenen Versionen inkrementell gepflegt wird (also mindestens die Systembeschreibung der Version in Produktion und die aktuelle Version) und wenn es Dokumente außerhalb des Wiki gibt (z.B. API-Dokumentationen als Teil der Architekturdefinition). Beide Annahmen treffen in der Regel zu.

ktip Für Confluence gibt die Erweiterung (Add-onScroll-Version, mit dem ein ganzer Bereich (Space) versioniert wird.

Continue reading

Praxiswerte

Mein Blog hat das Ziel, die Methode CARDS+ ausführlich mit sachlichen und emotionalen Argumenten zu erklären. Im Verlauf der Arbeit an der Artikelserie habe ich festgestellt, dass es immer schwieriger wird, kompakte Artikel zu schreiben, die sowohl theoretische Grundlagen als auch alle praktischen Anwendungen zu einem Thema für die verschiedenen Zielgruppen enthalten. In der Artikelserie “Praxiswerte” verfolge ich daher das Ziel, die praktische Anwendung der Methode CARDS+ zu illustrieren und die Bausteine der Dokumentation im Detail zu beschreiben.

Warum diese Trennung in verschiedene Artikelserien? Ich habe in meiner Rolle als Software-Experte oft genug mit theoretischen Konzepten zu tun, die auf den ersten Blick ideal passen. Erst in der Anwendung der Methode erkennen wir den Wert.  Für mich persönlich sind “Praxiswerte” daher Ausarbeitungen konkreter Lösungen im Rahmen der Methode.

Außerdem nutze ich den Begriff “Praxiswerte”,  um Beiträge dann einzustreuen, wenn wir ganz aktuell ein Lösung im Projekt umgesetzt haben, egal ob erfolgreich oder nicht. Ganz frei nach dem Motto: “Schreiben befreit”.

Copyright © 2018 Impressum Datenschutz

Zum Anfang ↑