Software-Entwicklungsprojekte (agil)

Agiles Projektmanagement ist ein Oberbegriff für Entwicklungsmodelle wie z.B. Scrum oder Extreme Programming Es ist gekennzeichnet durch adaptives Planen und das Team entscheidet, welche Arbeitsergebnisse wann erbracht werden können. Die Hauptaktivitäten sind dabei:
  • Anforderungskatalog (Product Backlog) erstellen und priorisieren
  • Architektur definieren
  • Iterations- (Sprint-) Inhalte definieren
  • Sprints umsetzen und die Anforderungen laufend Testen

Wichtige Schritte

Nr. Schritte Aufgaben
01 Initialisierung Bedürfnisse und Ziele der Stakeholder erheben. Probleme des bestehenden und Merkmale des neuen Systems analysieren. Mögliche Projektrisiken identifizieren, analysieren und bewerten. Erarbeiten der Entscheidungsgrundlagen für agiles PM und Entscheid treffen.
02 Initialer Projektplan Der Product Owner erstellt mit dem Projektleiter zusammen einen initialen Projektplan. Daraus gehen die Rahmengrössen Umfang, Ressourcen, Kosten und Zeit hervor, sodass jetzt, wenn das Vorhaben vom Management freigegeben wird, mit der richtigen Entwicklung im Rahmen des ersten Releases sprich Sprints begonnen werden kann.
03 Projektabwicklungskonfiguration I Gemäss dem Scope werden die Anforderungen bzw. Leistungsmerkmale beschrieben und im Anforderungskatalog (Product Backlog) festgehalten. Basierend auf der Anforderungen wird der Systemarchitektur-Rahmen entwickelt, Zusätzlich werden - sofern nicht vorhanden - Architektur-Entscheidungen, Design-Regeln und Umsetzungsrichtlinien definiert. Die notwendigen Konzepten werden in der entsprechenden Tiefe geschrieben.
04 Projektabwicklungskonfiguration II SCRUM-Vereinbarungen treffen: Sprintdauer, Definition „Done“, Besetzung der Rollen, etc. IT-Security und Betriebsaspekte klären.
05 Projektabwicklungskonfiguration III Aufwand für die Realisierung der Product Backlog-Elemente bestimmen und die Anzahl der notwendigen Iterationen (Sprints) festlegen. Einen Releaseplan erstellen mit der Anzahl Sprints die benötigt werden, um den nächsten Release zu erreichen.
06 Sprint Planning 1 Im Sprint Planning Meeting 1, stellt der Product Owner die User Stories vor. Zusammen mit dem Team werden das Ziel und der Inhalt (das WAS, die User Stories) des nächsten Sprints, bestimmt. In diesem Schritt wird auch über die qualitative Beschreibung der User Stories mittels DoR-Prinzip überprüft. Wenn alles geklärt ist, gibt das Team das Commitment für den nächsten Sprint. Das Ergebnis bzw. die entsprechenden Product Backlog-Items werden im «Sprint Backlog» festgehalten.
07 Sprint Planning 2 Im Sprint Planning Meeting 2, erarbeitet das Sprint Team die Arbeiten der nächsten 30 Kalendertage (sprich das WIE: Wie wollen wir die selektierten User Stories umsetzen?). Dabei werden die User Stories auf einzelne Tasks heruntergebrochen und im Task Board festgehalten.
08 Sprint (Inkrementelle Entwicklung) Während einem Sprint wird das System auf Grundlage der vorgegebenen Architektur und der für diesen Sprint ausgewählten Anforderungen gebaut. In jedem Sprint werden die definierten Anforderungen so umgesetzt, dass dieser End-To-End (GUI bis Datenbank) überprüft werden kann. Gleichzeitig wird das System laufend getestet, so dass am Ende jedes Sprints ein fertiges Stück der benötigten Software bereit steht.
09 Sprint Review (Product Review) Am Ende des Sprints wird mittels Sprint Review eine Produktprüfung durch den Kunden vorgenommen. Das Team präsentiert dem Product Owner und allen interessierten Stakeholdern das Ergebnis seiner Arbeit live am System und sammelt Feedbacks. Der Product Owner nimmt die umgesetzten User Stories ab, sofern sie die anfänglich formulierten Abnahmekriterien erfüllen (Definition-of-Done-Prinzip).
10 Retrospective (Lessons learned) Nach Abschluss jedes Sprints führt das Entwicklungsteam unter der Leitung des Scrum Masters eine «Retrospective» durch: Das heisst, es findet ein Lessons-learned-Meeting statt mit dem Ziel, das Gelernte sofort für die kommenden Sprints zu verwenden. Im Rahmen der Retrospektive werden diejenigen Punkte in das Impediment Backlog aufgenommen, welche das Team daran hindern, maximal effizient zu sein.
11 Backlog Grooming Das Backlog Grooming – auch Backlog Refinement genannt – ist ein Treffen des Entwicklungsteams mit dem Product Owner, in welchem sie die Product Back-log-Items diskutieren und verfeinern sowie das nächste Sprint Planning Meeting vorbereiten. Das heisst, es geht darum, zu klären, ob das Backlog Item klar genug formuliert und tief genug aufgesplittet ist, um es zu schätzen und in einem Sprints zu implementieren.
12 Integrationstest/Releasetest Es wird das gesamte System gegen die gesamten Anforderungen (funktionale und nicht funktionale Anforderungen) getestet.
13 Auslieferung & Einführung Das IT-System in seiner produktiven Umgebung installieren und zur Nutzung dem Betrieb übergeben.
14 Übergabe Nach der Inbetriebnahme des IT-Systems, erfolgt innerhalb eines gegebenen Zeitraums die Übergabe an die für den Betrieb verantwortliche Organisation.

Lieferobjekte

Nr. Bezeichnung Kurzbeschrieb
01 Anforderungskatalog Ausformulierte und vollständig definierte Anforderungen, welche zu Beginn des Projekts bekannt sind (Business Case, Product Backlog).
02 Projektentscheid Entscheid für oder gegen agiles PM nach SCRUM.
03 Sicherheitskonzept Analysiert die Sicherheitsanforderungen an das System und beschreibt die getroffenen Massnahmen im Bereich Sicherheit und Datenschutz:  Physische Sicherheiten, Software-Sicherheiten, Zugriffsberechtigungen
04 SCRUM Vereinbarung der Rahmenbedingungen, welche für die Projektführung nach SCRUM gelten: Sprintdauer, Definition des Status „Done“, Rollendefinition und personelle Zuweisung. Betriebskonzept und Einstufung gemäss geltenden IT-Security Roules
05 Projektmanagementplan Grobe Übersicht über den gesamten Projektverlauf. Der nachfolgende Releaseplan gibt Auskunft über die Realisierung der Entwicklungsschritte (Releases) basierend auf dem Product Backlog.
06 Product Backlog  Liste der Leistungsmerkmale, basierend auf dem Anforderungskatalog, den Systemanforderungen und der Systemarchitektur, priorisiert.
07 Releaseplan Ein grober Projektplan, welcher den Aufwand für die Realisierung der definierten Product Backlog Elemente aufzeigt.
08 Sprint Backlog Taskliste für den kommenden Sprint Backlog.
09 Testplan/ -konzept Legt fest, welche Tests im jeweiligen Sprint durch wen durchzuführen sind. Im Testkonzept wird die Grundlage definiert, welche die beteiligten Personen, Aktivitäten und Infrastruktur aufzeigt. Testkonzept: Definiert die Testrahmenbedingungen und die Testmethoden im jeweiligen Sprint, und dient der effizienten Planung und Durchführung der einzelnen Tests.
10 Testfall-Spezifikation Beschreibt die Grundlagen für die durchzuführenden Tests und wird für jeden Sprint mit erarbeitet.
11 Lastprofil Beschreibt die Auslastung resp. Belastung des Systems.
12 Integrationskonzept Definiert die Eingliederung des Systems (Master Release) in der bestehenden IT-Landschaft und spezifiziert die dazu notwendigen Schnittstellen detailliert.
13 Prototyp Vorabversion des Projektprodukts, welches meistens nicht funktionsfähig ist. Es dient zur Überprüfung der Einhaltung von Anforderungen mit dem Auftraggeber und fördert die Zusammenarbeit.
14 Testbericht Beschreibt den Stand des Testfortschrittes bzw. deren Ergebnisse im Systemtest sowie die getroffenen Massnahmen und offene Punkte.
15 Test- und Abnahmebericht Beschreibt den Stand des Testfortschrittes bzw. deren Ergebnisse im Abnahmetest des Master Release und gibt eine Empfehlung in Bezug auf die Einführung ab.
16 Support- und Betriebskonzept Anleitung für Installation  und Betrieb der Softwarelösung in der produktiven Umgebung.  Beschreibt die Unterstützung, die der Lieferant eines Produktes dem Anwender bietet.
17 Benutzer- und Schulungsunterlagen Beschreibt die Anwendung des IT-Systems aus Sicht der verschiedenen Benutzergruppen
18 Programm- und Wartungsdokumentation Beschreibt alle Elemente, die zur Lösung einer bestimmten Aufgabe im Rahmen des IT-Systems notwendig sind. Dokumentiert das Programm resp. die Programme des IT-Systems.
19 Einführungskonzept Legt die die Planung und Bereitstellung der erforderlichen Ressourcen für die Einführung fest.
20 Migrationskonzept und -verfahren Das Migrationskonzept definiert die technischen und organisatorischen Voraussetzungen an das Migrationsverfahren, welches für eine erfolgreiche Einführung des Systems benötigt wird. Das Verfahren stellt die Überführung des Systems in die bestehende IT-Landschaft während der Einführung sicher
21 Benutzerdokumentation Beschreibt die Anwendung des IT-Systems aus Sicht der verschiedenen Benutzergruppen.
22 Rollout-Schlussbericht Protokolliert den Ablauf der Einführung (Migrationen, Pilotinstallation, Verbreitung, Ausbildung, Einführungsschritte, offene Punkte).

Anwenden

profi.pm® erklärt (FAQ)
info@spol.ch
+41 41 747 30 60