Artefakte in der Softwareentwicklung

In der Vorbereitungsphase kann ein anfängliches Produkt Backlog als einfache Tabelle dargestellt werden.

Abbildung 6: Beispiel eines GitLab Issue Boards

Auf ILIAS gibt es ein Selbststudiums-Kurs zur Verwendung von GitLab. 

Projektmanagementplan

Der Projektmanagementplan enthält alle Informationen und Entscheidungen zum Entwicklungsprozess. Die folgenden Unterkapitel beschreiben den Inhalt eines Good-Practice Managementplans.
 
Vision und Ziele
Die Projektvision dient als Inspiration und gibt dem Projekt einen Fokus. Sie begründet kurz und bündig und leicht verständlich das Projekt und es ist wichtig, dass das ganze Team die Vision versteht, sie mitträgt und während des ganzen Prozesses darauf hinarbeitet.

Ein Ziel ist ein erwünschter zukünftiger Zustand, der kurz und klar definiert ist hinsichtlich Inhalt, Zeit und Ausmass. 
Gemeinsam mit der Auftraggeberin oder dem Auftraggeber sollen drei bis maximal sechs Ziele erarbeitet und formuliert werden.

Ziele sollen so «SMART» sein wie möglich. «SMART» bedeutet:

• Spezifisch Das Ziel muss sich auf konkret benannte Organisationen, Rahmenbedingungen, etc., beziehen; der Zielbereich ist genau abgegrenzt.
• Messbar Die Qualität und, wo nötig, Quantität der Zielerfüllung ist festlegbar; es lassen sich Indikatoren lassen davon ableiten.
• Angemessen Ist es überhaupt das richtige Ziel? Braucht es die geplanten Massnahmen? 
• Realistisch Die Aussicht auf Zielerfüllung ist gut unter den vorliegenden Rahmenbedingungen (Ressourcen, Zeit, Kompetenzen); externe, unkontrollierbare Faktoren stehen der Zielerfüllung nicht im Weg. 
• Zeitlich festgelegt (Time-bound) Es besteht ein zeitlicher Rahmen. 

Ergebnisse 
Eine Liste aller Artefakte wird erstellt, welche die Auftraggeberin oder der Auftraggeber als Leistung des Teams erwartet.

In einem Softwareentwicklungsprojekt ist die Leistung hauptsächlich die Software selbst. Es kann jedoch sein, dass die Auftraggeberin oder der Auftraggeber eine schriftliche Dokumentation möchte, in der das Produkt und dessen Testverlauf beschrieben ist, oder in der Hilfestellung geboten wird bei der Benutzung der Software, etc.

Ergebnisse können sein:

• Applikationssoftware
• Dokumentation der Softwarearchitektur
• Dokumentation von Teststrategie und -skript
• Benutzerhandbuch
• Handbücher zu Bereitstellung, Installation und des Unterhalts
• Projektmanagementplan

Auftraggeberinnen und Auftraggeber wünschen sich oft vorgezogene Ergebnisse, damit sie gewisse Teile des neuen Produkts möglichst schnell benutzen können (siehe Kapitel «Roadmap»). 

Die folgende Tabelle ist ein Hilfsmittel, um die Arbeitsergebnisse eines Projekts festzuhalten:

Definition of Done
Nebst den Ergebnissen sind Qualitätsaspekte zu definieren, welche das Team bei der Implementierung eines Elements im Backlog erfüllen muss. Zu diesem Zweck wird eine «Definition of Done» verwendet. 
Für Software kann eine Definition of Done z.B. so aussehen: «Done bedeutet gemäss den Standards programmiert, überprüft, implementiert mit Unit Test-Driven Development (TDD), getestet mit 100% Testautomatisierung (oder gemäss Teststrategie), integriert und dokumentiert.»

Projektorganisation
Es wird eine Liste mit allen involvierten oder betroffenen Personen (die Anspruchsgruppe) erstellt, einschliesslich einer Beschreibung ihrer Rollen.
Das Projektteam wird gebildet und die Aufgaben, Kompetenzen und Verantwortlichkeiten eines jeden Mitglieds festgelegt. Je ein Teammitglied wird ernannt als Projektleiter, Scrum Owner und Scrum Master.

Roadmap
Die Roadmap ist die langfristige Planung des Projekts und dient dazu, die Wirtschaftlichkeit im Auge zu behalten.
Sie wird basierend auf dem anfänglichen Produkt Backlogs erstellt. Es ist ratsam, für die Projektdauer und den Projektaufwand zusätzliche etwas Zeit und Ressourcen einzuplanen: denn es ist ein bekanntes Phänomen, dass das ursprüngliche Produkt Backlog oft nur 80% aller Projektanforderungen enthält.
Die zentralen Elemente der Roadmap sind die  Meilensteine.
Ein Meilenstein ist ein Fixpunkt im Projektablauf, bei dem vordefinierte, messbare (Zwischen-) Arbeitsergebnisse vorliegen müssen und der es erlaubt, den Projektfortschritt und die Projektkosten zu verfolgen.
Es ist für jeden Meilenstein festzulegen, welche Artefakte (siehe «Ergebnisse») verfügbar sein müssen.
Ein Meilenstein ist erreicht, sobald die benötigten Artefakte verfügbar sind und deren Prüfung erfolgreich verlaufen ist.

Die Roadmap für eine Bachelorarbeit mit drei Meilensteinen könnte z.B. so aussehen:

Abbildung 7: Beispiel einer Roadmap für eine Bachelorarbeit

Release Plan
In der agilen Entwicklung ist der Release Plan ein kurzfristiges Planungsinstrument, das aufzeigt, was in den nächsten paar Sprints verfügbar sein wird. Es basiert auf den priorisierten Einträgen des Produkt Backlogs und zeigt, welche Backlog Items in welchem der anstehenden Sprints implementiert wird.

Abbildung 8: Beispiel eines Release Plans als einfache Tabelle

Der Release Plan ist ein «lebendiger» Plan. Konkret heisst das, dass dieser nach jedem Sprint aktualisiert und um den Inhalt zukünftiger Sprints ergänzt wird.
Bei kleinen Projekten - beispielsweise Bachelorarbeiten - können Roadmap und Release Plan in einem einzelnen Plan kombiniert werden.

Risikomanagement
Risikomanagement dient dem Zweck, mögliche Probleme vorwegzunehmen bevor sie auftraten und über den Lebenszyklus des Projekts hinweg Aktionen auszuführen und Massnahmen zur Verhinderung dieser Probleme (und damit zum Schutz der Projektziele) umzusetzen.

Die Verwendung von Checklisten, Brainstorming mit den Anspruchsgruppen und die Berücksichtigung von Erfahrungen aus früheren Projekten sind mögliche Strategien zur Identifikation möglicher Risiken.
Jedes Risiko wird beschreiben, einschliesslich einer Einschätzung seiner Eintrittswahrscheinlichkeit und des zu erwartenden Schadenmasses. Für die grössten Risiken (siehe Risikomatrix) sollen Indikatoren für des Eintreten definiert werden sowie Strategien zur Verringerung der Eintrittswahrscheinlichkeit und/oder mögliche Korrekturmassnahmen zur Verringerung des möglichen Schadens. Als nächstes wird der Effekt dieser Aktionen beurteilt.

Die folgende Tabelle kann dabei helfen, all diese Informationen zu sammeln.

Abbildung 9: Tabelle für das Risikomanagement

Zur Abschätzung der tatsächlichen Risikosituation und der Effekte des Risikomanagements kann eine Risk Matrix benutzt werden.

Abbildung 10: Beispiel einer Risikomatrix

Es ist wichtig abzugleichen und sicherzustellen, dass die im Risikomanagement aufgeführten und beschriebenen Risiken sich mit jenen in der Teststrategie decken. Damit wird sichergestellt, dass das «risiokobasierte Testen» zu den Projektrisiken passt.

Überwachung (Controlling)
Projektüberwachung schliesst alle Aktivitäten ein, die der Entdeckung von Projektabweichungen zwischen dem geplanten und dem tatsächlichen Zustand dienen.
Mögliche Gründe für solche Abweichungen sind:

• Veränderte oder neue Projektanforderungen vergrössern den Projektaufwand
• Unzureichende Aufwandschätzung in der Sprintplanung
• Falsch verstandene Anforderungen
• Eintreten eines Risikos
• Ineffizientes Teamwork

Jede der oben beschriebenen Abweichungen kann mit einem entsprechenden Tool entdeckt werden.

Veränderte oder neue Anforderungen
Die Project Burndown Chart zeigt den über die Zeit hinweg noch ausstehenden Arbeitsaufwand gemäss Produkt Backlog. Die Sprints werden auf der X-Achse als Zeitmarker gesetzt.
Die Trendlinie in der Project Burndown Chart zeigt in der Regel nach unten. Wenn allerdings neue Items zum Backlog hinzugefügt werden, wird sich die Anzahl der verbleibenden Storypoints nach oben bewegen.

Abbildung 11: Projekt-Burndown Chart

In der Literatur wird statt «Projekt-Burndown Chart» auch oft der Begriff «Release Burnout Chart» verwendet. «Release» bedeutet in diesem Fall die erwarteten Ergebnisse für einen Meilenstein.

Unzureichende Schätzung des Aufwands bei der Sprintplanung
Um die Fähigkeit des Teams zu verbessern, seinen Aufwand in der Sprint-Planung abzuschätzen, sollten für jeden Sprint die Schätzungen mit dem effektiven Aufwand verglichen werden. Natürlich muss entsprechend jedes Teammitglied den geleisteten Aufwand pro Task oder User Story notieren, um effektive Daten zu erhalten.

Das Softwarearchitektur-Dokument beschreibt alle Aspekte eines Produkts. 
Eine empfehlenswerte Struktur ist beschrieben in der «arc42 initiative» von Gernot Starke, Peter Hruschka und Ralf D. Müller.
Eine Übersicht der arc42 Softwarearchitekturdokument-Kapitelstruktur zeigt die nächste Abbildung (Quelle: arc42 Template Overview, https://arc42.org/overview, aufgerufen am 11. Aug. 2022).

Abbildung 13: Übersicht der Kapitelstruktur nach arc42 für ein Softwarearchitektur-Dokument 

Die arc24 Website https://arc42.org/ erklärt im Detail die Struktur, die benutzt werden kann, um eine Softwarearchitektur zu bauen, zu kommunizieren und zu dokumentieren.
Zusätzlich zur detaillierten Erklärung der vorgesehenen Kapitelinhalte enthält die Website Tipps und Beispiele aus der Praxis.