CARDS+

Tag: FAQ (page 1 of 2)

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

Olderposts

Copyright © 2018 Impressum Datenschutz

Zum Anfang ↑