CARDS+

Tag: Epic (page 1 of 4)

Entwicklungsergebnisse messen

Die Organisation muss sicherstellen, dass die Entwicklungsergebnisse Anforderungen an die Überwachung und Messung, soweit zutreffend, sowie Annahmekriterien enthalten oder auf sie verweisen.
ISO 9001, Kapitel 8.3

Continue reading

Der Baustein Case

Der Reise-Butler ist die Smartphone-App für den wissbegierigen Reisenden und Fallbeispiel für die Methode CARDS+.

Continue reading

Architekturentwurf

Der Reise-Butler ist die Smartphone-App für den wissbegierigen Reisenden und Fallbeispiel für die Methode CARDS+.

Continue reading

Anforderungsanalyse (3)

Der Reise-Butler ist die Smartphone-App für den wissbegierigen Reisenden und Fallbeispiel für die Methode CARDS+.

Continue reading

Anforderungsanalyse (2)

Der Reise-Butler ist die Smartphone-App für den wissbegierigen Reisenden und Fallbeispiel für die Methode CARDS+.

Continue reading

Anforderungsanalyse (1)

Der Reise-Butler ist die Smartphone-App für den wissbegierigen Reisenden und Fallbeispiel für die Methode CARDS+.

Continue reading

Der Baustein Epic

Der Reise-Butler ist die Smartphone-App für den wissbegierigen Reisenden und Fallbeispiel für die Methode CARDS+.

Continue reading

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

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

Olderposts

Copyright © 2018 Impressum Datenschutz

Zum Anfang ↑