CARDS+

Month: June 2015

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

Durch offensichtliche Fehler in der Dokumentation verlieren wir schnell das Vertrauen der Entwickler. Wir verlieren dadurch auch wichtiges Feedback.
Die Qualität sinkt – ein Teufelskreis!

Was ist die Lösung?

Für die Darstellung der Lösung verwende ich gedanklich ein ausreichend komplexes Projektumfeld. Das Projekt hat die Aufgabe, ein Software-Produkt agil zu entwickeln. Der Auftraggeber und die Stakeholder sind in dieser agilen Methode integriert. Sie haben Ziele festgelegt, die nicht nur die Realisierung eines Software-Produktes, sondern auch die Bereitstellung einer Produktdokumentation umfasst, bestehend aus einer Systembeschreibung, einer Architekturdefinition und Benutzer– und Betriebshandbuch.

10 Was ist die Lösung

In diesem Artikel beschränke ich mich auf die Rolle der agilen Methode CARDS+ für Wissensmanagement in einem Software-Projekt. Die Methode

  • gibt ein Wissensmodell mit klar definierten Strukturen vor,
  • legt Regeln fest, die es dem Team ermöglichen, die geforderte Qualität sicherzustellen,
  • formuliert Praktiken, durch die wir wichtige Informationen von weniger wichtigen unterscheiden können und
  • fordert Werkzeuge, die es uns erlauben, schnell und effektiv einmal erarbeitetes Wissen zu sichern.

Continue reading

Eine gute Dokumentation hat eine klare und nachvollziehbare Struktur und einen “Gärtner“, der sie pflegt und verteidigt!

Continue reading

Wir unterscheiden nicht mehr wesentlich zwischen der Tätigkeit des Programmierens und der des Dokumentierens.

Copyright © 2018 Impressum Datenschutz

Zum Anfang ↑