| Nr. |
Aufgabe |
Kurzbeschreibung |
| 1 |
Idee formulieren |
In der Sichtweise der Projektdurchführung beinhaltet die erste Frage die Ausformulierung und Konkretisierung der Projektidee sowie das Verfassen des Steckbriefs als Projektanmeldung (MS10). |
| 2 |
Scope festlegen |
Bei der Definition des Projekt-Scopes, insbesondere des System-Scopes, geht es um eine inhaltliche Abgrenzung des Vorhabens (was ist "In Scope", was "Out of Scope"?). Dies geschieht unter Anleitung des designierten Projektleiters in folgenden Schritten:
Der IST-Zustand wird analysiert und klar abgegrenzt. Was für Umsysteme gibt es? Systembezogene Einflussgrössen und Schnittstellen werden bestimmt
Unter- und Teilsysteme werden definiert
Schnittstellen zu Unter-/Teilsysteme und zu Umsysteme werden geklärt |
| 3 |
Projektumfeld analysieren |
Die Rahmenbedingungen und Restriktionen, welche als Einflussgrösse auf das Projekt eine entsprechende Wirkung verursachen ermitteln und festhalten.
Systembezogene Einflussgrössen analysieren und festhalten. |
| 4 |
Anforderungen / Ziele / Bedürfnisse aufnehmen |
Die Anforderungen sowie deren Stakeholder werden erhoben und im Anforderungs- und Stakeholderkatalog (Stakeholder-Map) festgehalten.
Ziele und Anforderungen, die umgesetzt werden müssen, ausformulieren.
Probleme und Risiken, die mithilfe des Projekts beseitigt werden sollen, definieren.
Produktbezogene Anforderungen im Form von User Stories im Product Backlog festhalten |
| 5 |
Lösung grob konzipieren |
Die Projektidee wird konkretisiert und entsprechende Lösungsansätze werden gesucht. Gibt es schon einen konkreten Lösungsansatz oder mögliche Lösungsvarianten?
Den quantifizierbaren und den nicht quantifizierbaren Nutzen bewerten.
Allfällig vorhandene Ausführungsvarianten festhalten.
Das Projektprodukt wird hinsichtlich Etappierung und Modularisierung analysiert |
| 6 |
Business Value definieren |
Basierend der grob definierten Lösung den Projektnutzens resp. Wirtschaftlichkeit errechnen und die Strategiekonformität der angestrebten Lösung überprüfen. Aufführen der Chancen und Risiken, die Wirtschaftlichkeit und weitere positive Wirkung des zu erstellenden Produkts was man nach dem Projekt effektiv erreichen erhofft. |
| 11 |
Produkt Workshop / Konfiguration |
In einem oder sogar mehreren Projektkonfigurationsworkshops wird festgelegt, welche
Vorbedingungen (z.B. Architektur, Konfiguration etc.) vorhanden sein müssen, damit die Sprints möglichst effizient durchgeführt werden können. Es wird hier entschieden, wie viel kann agil und was kann/muss konventionell entwickelt werden.
Proof of Concept
Bei erhöhten Sicherheitsbedarf gilt es Informationssicherheits- und Datenschutzkonzept
(ISDS-Konzept) erstellen
Test- und Integrationsstrategie festlegen
Projektinfrastruktur respektive Entwicklungsumgebung aufbauen |
| 12 |
Sprint Planen (Planning Meeting 1 und 2) |
Basierend auf dem Product Backlog und aufgrund der Priorisierung werden die für die nächste anstehende Iteration (Sprint) umzusetzenden User Stories bzw. Ergebnisse definiert. Dazu gehören die saubere Sprint-Planung.
Im Sprint Planning Meeting (Teil 1) stellt der Product Owner die User Stories vor. Zusammen mit dem Team wird das Ziel und der Inhalt «WASdes nächsten Sprints bestimmt. In diesem Schritt wird auch über die qualitative Beschreibung der User Stories mittels dem DoR-Prinzip entschieden.
Im Sprint Planning Meeting (Teil 2) erarbeitet das Team gemeinsam die für die Erreichung der Sprintziele notwendigen Tätigkeiten und koordinieren die notwendige Architektur und/oder das Design (WIE). Dabei werden die User Stories in einzelne Tasks heruntergebrochen und als Backlog Tasks festgehalten.
In der Folge läuft jede User Stories, welche in Tasks unterteilt wurden, die Arbeitsschritte 13 – 16 in einem iterativen Prozess ab. Bis das gesamte geplante Inkrement erstellt wurde. |
| 13 |
Analysieren & Spezifizieren |
User Stories müssen bezüglich deren Anforderungen in diesem Arbeitsschritt so spezifiziert werden, dass anschliessend ein lückenloses Verständnis beim Entwickler oder Entwicklungsteams vorliegt. Wie wird im Detail nun die Anforderung respektive Stories umgesetzt, so dass die definierten Akzeptanzkriterien erfüllt werden können. |
| 14 |
Architektur & Design |
Basierend auf den Anforderungen der neuen User Stories wird die Systemarchitektur
geprüft und allenfalls angepasst, Zusätzlich werden - sofern nicht vorhanden - Architektur- Entscheidungen, Design-Regeln und Umsetzungsrichtlinien definiert oder angepasst.
Wenn keine Architektur existiert, wird zuerst diese erstellt/festgelegt. |
| 15 |
Inkrement / Produkt erstellen |
Während einem Sprint wird das System auf Grundlage der vorgegebenen Architektur und der für diesen Sprint ausgewählten User Stories gebaut. In jedem Sprint werden die definierten Anforderungen so umgesetzt, dass dieser End-To-End (GUI bis Datenbank) überprüft werden kann. |
| 16 |
Inkrement testen |
Gleichzeitig zur Entwicklung wird das Inkrement laufend getestet, so dass am Ende jedes Sprints ein fertiges Stück der benötigten Software bereit steht. |
| 17 |
Sprint Review & Retrospektive |
Nach dem Realisieren und allfälligen Anpassen wird das erstellte Projektprodukt anhand der User Stories verifiziert und auf seine zielbezogene und fehlerfreie Anwendbarkeit geprüft (Validation).
Die Ergebnisse des Sprints werden dem Product Owinder und allen interessierten Stakeholdern live am System präsentieren. Dieser nimmt die umgesetzten User Stories in Form des DoD-Prinzips ab.
Verbesserungsvorschläge, Lob und Kritik werden entgegen genommen und allenfalls werden neue Task und User Stories für das Product Backlog definiert.
Im Rahmen der Retrospektive werden diejenigen Punkte im Impediment Backlog aufgenommen, welche das Team daran hindern maximal effizient zu sein. |
| 18 |
Backlog Grooming |
Das Backlog Grooming oder auch Backlog Refinement genannt ist ein Tref-fen des
Entwicklungsteams mit dem Product Owner, in welchem sie die Product Backlog Items diskutieren und das nächste Sprint Planning vorberei-ten. Das heisst, es geht darum zu klären ob das Backlog Item klar genug formuliert und tief genug aufgesplittet (lässt es ihr Umfang zu) sind, um sie zu schätzen und innerhalb eines Sprints zu implementieren?
Aufnahme von neuen User Storys, Features und Epics in das Backlog
Verfeinerung von vorhandenen Epics, Features und User Storys und gegebenenfalls
Aufteilung in mehrere kleine Backlog Items Zusammenfassen von User Storys |
| 21 |
Integrations- & Systemtests durchführen |
Beim Integrations- & Systemtest wird das erstellte Inkremente mit dem gesamten System gegen die gesamten Anforderungen (funktionale und nicht funktionale Anforderungen) getestet.
Last- & Performancetest Mobile Tests |
| 22 |
Produkt einführen |
Die realisierte Lösung wird in das reale Umfeld integriert und ihre optimale Handhabung sichergestellt. Evtl. muss eine Schulung durchgeführt werden. Die Verantwortlichkeiten werden endgültig geregelt bzw. übergeben.
Einführungsplan erstellen
Bereitschaft für Inbetriebnahme/Ausbreitung erstellen Produkt/Inkrement in Betrieb setzen
Definitive Freigabe |
| 23 |
Produkt übergeben |
Alle Ausführungsarbeiten inkl. allfälliger Nachbesserungen werden abgeschlossen und die Verantwortlichkeiten bezüglich des neu erstellten Projektprodukts geregelt (Decharge- Erteilung an den Projektleiter). Ebenfalls geregelt werden Wartung/Unterhalt oder eine allfällige Produktion. Die Dokumentationen werden zwecks späterer Bearbeitung sichergestellt. |
