Leitfaden Agiles HERMES · Matthias Roth leitet die Java-Abteilung der Born Informatik. ......

Leitfaden

Agiles HERMES

Matthias Roth Daniel Kobi

Frank H. Ritz Hans-Jürg Kleine

Peter Lang

© 2011 eco-HERMES Themengruppe Agiles HERMES

Autoren: Matthias Roth Daniel Kobi Frank H. Ritz Hans-Jürg Kleine Peter Lang Mitwirkende: Die Grundlagen wurden in Themengruppe «Agiles HERMES» erarbeitet. Leiter: Matthias Roth Mitglieder: Daniel Kobi Frank H. Ritz Hans-Jürg Kleine Peter Lang Marco Gianini Andreas Hamberger Patrik Riesen Beno Amacker Qualitätssicherung: Boris Bäsler Bogdan Lent Auflage: Dezember 2011 ISBN 978-3-9523984-0-1 © 2011 eco-HERMES Ihr Kontakt zu eco-HERMES, zur Themengruppe und zu den Autoren: eco-HERMES c/o Matthias Roth Talmoosstrasse 5 3063 Ittigen http://www.eco-hermes.ch Rechte: Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktion jeglicher Art (Fotokopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder andere Verfahren) nur mit schriftlicher Genehmigung des Vereins eco-HERMES. Jegliche Haftung für die Richtigkeit des gesamten Werks wird, trotz sorgfältiger Prüfung durch die Autoren, abgelehnt. Die im Buch genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren Inhaber geschützt.

Über die AutorenÜber die AutorenÜber die AutorenÜber die Autoren Matthias Roth leitet die Java-Abteilung der Born Informatik. Er ist Mitgründer der User Group eco-HERMES und Gründer der Themen-Gruppe Agiles HERMES. Seit 1994 hat er die unterschiedlichsten Rollen, vom Entwickler, Architekten über den Projektleiter bis hin zum Coach und Berater von Projektleitern, in kleinen bis sehr grossen Projekten besetzt. Er leitet die iSchule.ch, in welcher er sein Know-how im Bereich Java-Entwicklung und Projektmanagement weitergibt. Daniel Kobi arbeitet als Projektmanager und IT-Consultant für die Wistar Informatik AG. In den 80er Jahren als Softwareentwickler in der Informatik Fuss gefasst, ist er nach Rollen in Analyse/Design seit 1991 als Projektleiter und Linienmanager tätig. Dabei hat er viele Grossprojekte im Bundesumfeld und bei den SBB nach der HERMES Methode geführt und ist heute auch Mitglied von eco-HERMES. Er ist Eidg. Dipl. Wirtschaftsinformatiker, Scrum Master und zertifizierter HERMES Assessor. Frank H. Ritz ist Geschäftsführer der Ritz Engineering GmbH und der objtec GmbH. Seit 1983 Applikationsentwicklungen mittels C++, Java EE und SQL-Datenbanken. Schwerpunkt heute sind stark methodisch unterstützte agile Projektleitung, Business Analyse und Requirements Engineering & Management. Wichtige Zertifizierungen in diesem Bereich. Methodisch zu Hause in PMI, Hermes, IIBA, CPRE, RUP, Scrum, Prince2, Enterprise Architecture. HERMES Initiativen im Verein eCH, eco-HERMES und auf HERMES Veranstaltungen. Hans-Jürg Kleine startete seine Karriere im Projektmanagement 1990 bei der Direktion Personenverkehr der SBB. Als Projektleiter für Verkaufssysteme entwickelte er unter anderem die erste Generation der mobilen Zugpersonalgeräte. Nach einem Abstecher in den Journalismus und das Verlagswesen arbeitet er seit 2002 bei der Identitas AG, wo er als Leiter Projekte und Entwicklung die Organisationseinheiten für Projektmanagement und Softwareentwicklung aufgebaut hat. Peter Lang ist als selbstständiger Projektmanager für IT-Projekte sowie als Managementberater, QM-Auditor, Projekt-Coach und Trainer in der Schweiz und in Deutschland tätig. Als Mitautor von HERMES und V-Modell’97 unterstützt er Unternehmen und Behörden bei der praxisgerechten Anpassung, Einführung und Anwendung von HERMES und V-Modell®XT. Mit seiner 20-jährigen Praxiserfahrung fokussiert er u.a. das Aufsetzen von Grossprojekten, Anforderungsanalysen, Ausschreibungen und Abnahmen.

Inhaltsverzeichnis

Kapitel 1: Zweck ................................. ................................................................... 7

Ausgangslage ......................................................................................................... 7

Ziel .......................................................................................................................... 8

Kapitel 2: Grundlagen ............................ ............................................................... 9

Grundsätze und Prinzipien .................................................................................... 10

Rahmenbedingungen und Herausforderungen ..................................................... 12

Kapitel 3: Agiles HERMES .......................... ......................................................... 13

Phasen .................................................................................................................. 16

Phase Initialisierung .......................................................................................... 16

Phase Voranalyse ............................................................................................. 16

Phase Umsetzung KRE ..................................................................................... 17

Phase Abschluss ............................................................................................... 17

Rollen .................................................................................................................... 18

Product Owner, PO (PL, AnwV) ........................................................................ 18

Scrum Master, SM (PL-AN, Arch, Entw) ............................................................ 19

Scrum Team, ST (Entw, Arch, Tst, BetrV) ......................................................... 20

Ergebnisse ............................................................................................................ 20

Product Backlog ................................................................................................ 21

Initial Product Backlog ....................................................................................... 21

Sprint Backlog ................................................................................................... 21

Burndown Chart ................................................................................................ 22

Impediment Backlog .......................................................................................... 22

Definition of Done (DoD) ................................................................................... 22

Meetings ............................................................................................................... 23

Sprint Planning 1 ............................................................................................... 23

Sprint Planning 2 ............................................................................................... 23

Daily Scrum ....................................................................................................... 23

Review ............................................................................................................... 24

Retrospektive .................................................................................................... 24

Estimation Meeting ............................................................................................ 24

Planung ................................................................................................................. 25

Planung starten ................................................................................................. 25

Planen ............................................................................................................... 25

Neue Product Backlog Items ............................................................................. 25

Kapitel 4: Qualitäts- und Risikomanagement......... ............................................ 26

Qualitätsmanagement ........................................................................................... 26

Risikomanagement ............................................................................................... 26

Kapitel 5: Szenarien ............................. ............................................................... 27

Projekt 0-8-15 ....................................................................................................... 27

Projekt Verschiedene Anwendergruppen .............................................................. 28

Projekt Neue Technologie / Architektur ................................................................. 29

Project N Entwickler -Teams ................................................................................. 30

Projekt WTO-Ausschreibung ................................................................................. 31

Kapitel 6: Anhang ................................ ................................................................ 32

Ergebnisse zu den Szenarien ............................................................................... 32

Ergebnisse zu Szenario 0-8-15 ......................................................................... 33

Ergebnisse zu Szenario Verschiedene Anwendergruppen ................................ 34

Ergebnisse zu Szenario Neue Technologie / Architektur ................................... 35

Ergebnisse zu Szenario N Entwickler -Teams ................................................... 36

Ergebnisse zu Szenario WTO-Ausschreibung .................................................. 37

Begriffe .................................................................................................................. 39

_________________________ Kapitel 1: Zweck 7777

KapKapKapKapitel itel itel itel 1111: : : :

ZwecZwecZwecZweckkkk Der Leitfaden zeigt auf, wie HERMES Projekte, in denen Software entwickelt wird, durch die Einbindung agiler Methoden in den Phasen Konzept, Realisierung und Einführung nach agilen Prinzipien effizient umgesetzt werden können. Er soll insbesondere Projektleitern, aber auch allen anderen Projektbeteiligten als Hilfsmittel und Entscheidungsgrundlage für die Initialisierung und Abwicklung von HERMES Projekten mit agilem Vorgehen dienen. Dabei ersetzt der Leitfaden weder HERMES als zugrunde liegende Projektführungsmethode noch Lehrbücher zu agilen Vorgehensmethoden. Es wird vorausgesetzt, dass diese Methoden weitgehend bekannt sind.

AusgangslageAusgangslageAusgangslageAusgangslage Die Projektführungsmethode HERMES ist beim Bund und bei bundesnahen Betrieben etabliert. Die Methode hat dazu beigetragen, dass Projekte, auch wenn jedes Projekt einzigartig ist, nach einem festen Muster abgewickelt werden. Die Phasen und Ergebnisstrukturen geben sowohl den Projektbeteiligten wie auch allen betroffenen Stellen und Personen einen gewissen Halt und Sicherheit, was die Projektdurchführung betrifft. HERMES ist sehr gut in den Beschaffungs- und Finanzierungsprozessen des Bundes integriert. HERMES wurde in vielen Projekten erfolgreich eingesetzt. HERMES zeichnet sich wie folgt aus:

• HERMES ist beim Bund und bei bundesnahen Betrieben etabliert. • Die Methode deckt den gesamten Lifecycle eines Informatikprojektes ab. • Standardisiertes Vorgehen für unterschiedliche Projekttypen wie

Systementwicklung, Systemadaption und Organisationsprojekte. • Klar definierte Ergebnisse und Entscheidungspunkte. • Submodelle für wichtige Teilaspekte eines Projektes: Projektmanagement,

Qualitätssicherung, Risikomanagement, Konfigurationsmanagement und Projektmarketing.

• Gute Einbindung in die IT-Prozesse des Bundes. • Erfüllt alle Auflagen für öffentliche Ausschreibungen.

Durch das Bestreben von HERMES, für möglichst viele IKT-Projekte anwendbar zu sein, ist die Methode ziemlich umfangreich. Ein Projektleiter benötigt viel Know-how und Erfahrung, um ein adäquates Tailoring durchzuführen.

8888 Leitfaden Agiles HERMES ________________________

Sind dieses Know-how und Erfahrungen nicht vorhanden, so werden die Tailoring-Möglichkeiten nicht oder nicht konsequent genug ausgeschöpft. Dies führt dazu, dass der Projektführungsmethode HERMES gewisse Nachteile vorgehalten werden: • Schwerfällig und dokumentenlastig, produziert lange Zeit nur viel Papier

und kein Ergebnis. • Mangelnde Flexibilität bei Änderungen von Anforderungen. • Wenig Substanz bei der Geschäftsprozessanalyse und beim

Requirements Engineering. • Mangelnde Qualität im Ergebnis, der Kunde erhält nicht zuverlässig, was

er will / was er braucht. • Kein Eingehen auf die Zusammenarbeit der Projektmitarbeiter und Soft-

Skills. • Mangelnde Einbindung der Zulieferer in den IT-Projektprozess. Es stehen verschiedene Praktiken und Techniken im Raum, wie agile Methoden der Softwareentwicklung, womit diese Problempunkte gelöst oder entschärft werden sollen. Um diese Praktiken und Techniken innerhalb von HERMES anzuwenden, muss HERMES einem starken Tailoring unterzogen werden. In diesem Leitfaden versuchen wir, einheitliche Grundlagen zu schaffen und als Best Practice festzuhalten. Dass dies möglich ist, wird durch die folgende HERMES Aussage untermauert: Grundsätzlich ist jede Phase einmal zu durchlaufen. Es ist jedoch möglich, mittels «Tailoring» gewisse Phasen zusammenzufassen oder die zu erstellenden Ergebnisse der einzelnen Phasen in mehreren Iterationen zu erarbeiten. Dies ist jeweils für ein konkretes Projekt festzulegen. [HERMES SA 2.2]

ZielZielZielZiel Ziel des Leitfadens ist es, HERMES als Projektführungsmethode um die agilen Ansätze zu erweitern. Dabei wird HERMES einem starken Tailoring unterzogen, welches aber die Prinzipien von HERMES nicht verletzt.

In der «Studie HERMES und Agilität» des Informatikstrategieorgans Bund ISB vom 16.09.2010 wurde zudem offiziell festgestellt, dass es möglich ist, innerhalb von HERMES agil zu arbeiten. Der Leitfaden soll diese Aussage konkretisieren und als praktische Wegleitung für Projektleiter und Projektbeteiligte dienen.

_____________________ Kapitel 2: Grundlagen 9999

Kapitel 2: Kapitel 2: Kapitel 2: Kapitel 2:

GrundlagenGrundlagenGrundlagenGrundlagen Unabhängig davon, nach welcher Methode ein Projekt durchgeführt wird, ist der Projekterfolg vorwiegend von den beteiligten Personen abhängig und von deren Überzeugung und Willen, die Projektziele zu erreichen. Die Interaktion zwischen den Beteiligten und eine Zusammenarbeit, welche auf Vertrauen und Hilfsbereitschaft beruht, bilden dabei das Fundament des Projekterfolges. Wir verweisen daher als Erstes, wie alle agilen Methoden, auf das Agile Manifest, in dem genau diese Aspekte hervorgehoben sind:

Wir erschliessen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt: Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Funktionierende Software mehr als umfassende Dokumentation

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heisst, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

[agilemanifesto.org]


GrundsätzeGrundsätzeGrundsätzeGrundsätze und Prinzipienund Prinzipienund Prinzipienund Prinzipien Der Leitfaden baut auf folgenden Grundsätzen auf: a. HERMES wird als Projektführungsinstrument verwendet und bildet somit

den Rahmen für ein Projektvorhaben. Dieser Rahmen beschreibt, WAS während eines Projektes zu tun ist. Die Ergebnisse in Dokumentenform werden dabei ausschliesslich aus HERMES übernommen. Es werden aber nur die Ergebnisse verwendet, welche für das Projekt einen Mehrwert bringen. Das Gleiche gilt für die Rollen, es werden die Rollen von Scrum besetzt und nach Bedarf weitere Rollen von HERMES besetzt.

b. Die agilen Methoden wie Scrum und extreme Programming XP zeigen auf, WIE im Projektrahmen effizient gearbeitet werden kann. Die Methoden fokussieren die Softwareentwicklung. Die Arbeitspraktiken können aber auch für alle anderen Arbeitsschritte oder Aufgaben innerhalb eines Projektes angewendet werden, wie zum Beispiel für: Systemziele definieren, Lösungen suchen, Projektmarketing, Prozess und Organisation vorbereiten usw.

c. Das Projekt wird nach Abschluss der Phase Voranalyse iterativ abgewickelt. Die Phase nach der Voranalyse nennen wir Phase Umsetzung KRE . Dabei werden in dieser Phase in einer Iteration die drei HERMES Phasen Konzept, Realisierung und Einführung in einer einzelnen Mini-Phase (einem KRE-Sprint) durchlaufen, so dass nach jeder Iteration eine lauffähige Software bereitsteht. Die Iterationen haben alle eine feste Länge von 2 bis 4 Wochen. Die konkrete Iterationsdauer wird im Projekt festgelegt.

Für die Bezeichnung von Rollen, Ergebnissen und Aktivitäten verwenden wir die Begriffe aus der agilen Methode Scrum, in Klammern wird, sofern vorhanden, der entsprechende HERMES Begriff verwendet.

_____________________ Kapitel 2: Grundlagen 11111111

Es gelten folgende Prinzipien: 1. Alle Ergebnisse und Aktivitäten werden nach «Business Value» priorisiert,

also nach dem grösstmöglichen Wert für den Auftraggeber oder für die Zielgruppe des Projektes. Dies gilt für Anforderungen wie auch zum Beispiel für Themen in Sitzungen. Die Priorität ist dabei eindeutig, d.h., es gibt keine Ergebnisse oder Aktivitäten mit gleicher Priorität.

2. Es wird strikt nach den Prioritäten gearbeitet. Das gewünschte Ergebnis mit der höchsten Priorität wird als Erstes erarbeitet, oder die Aktivität mit der höchsten Priorität wird als Erste durchgeführt.

3. Wenn immer möglich erfolgen Aktivitäten nach dem Timeboxing-Prinzip, d.h., für die Aktivitäten wird ein Zeitrahmen definiert, der nicht überschritten werden darf. Ist der Zeitrahmen erreicht, wird die Aktivität abgebrochen. Bei einer Iteration/einem Sprint bedeutet dies, dass die nicht erstellten Funktionen im Product Backlog neu priorisiert werden.

4. Wiederkehrende Aktivitäten werden in festen Perioden erledigt (tägliche, wöchentliche usw.).

5. Alle erstellten Ergebnisse werden dem Auftraggeber nach Fertigstellung präsentiert, spätestens am Ende der entsprechenden Iteration.

6. Am Ende einer Iteration wird in einer Retrospektive nach Möglichkeiten gesucht, um die Arbeit im Projekt effizienter zu gestalten.

7. Die Softwareentwicklung richtet sich nach dem agilen Vorgehen Scrum. Zum Beispiel werden die Anforderungen für die Softwareentwicklung in einem Product Backlog (Anforderungen, Pflichtenheft) geführt und verfeinert.

8. Das kleinste Projekt nach diesem Leitfaden hat folgende Ergebnisse, geordnet nach «Business Value»:

a. Informatiksystem b. Projektantrag c. Product Backlog (Anforderungen, Pflichtenheft) d. Projekthandbuch inkl. Projektplan e. Sprint Backlog (Anforderung, Pflichtenheft für eine Iteration) f. Burndown Chart (Performance-Messung über den gesamten

Projektverlauf) 9. Das kleinste Projekt nach diesem Leitfaden durchläuft folgende Phasen,

wobei die Initialisierung und die Voranalyse in einer Phase zusammengefasst werden:

a. Initialisierung (Projektantrag, Projekthandbuch inkl. Projektplan) b. Voranalyse (Erstellen des Initial Product Backlog) c. Umsetzung KRE mit einem Sprint, mit Auslieferung der fertigen

Software d. Abschluss (Beenden und Schliessen des Projekts)


RahmenbedingungenRahmenbedingungenRahmenbedingungenRahmenbedingungen und Herausforderungenund Herausforderungenund Herausforderungenund Herausforderungen Die Rahmenbedingungen für ein agiles Projekt unterscheiden sich nicht von den Rahmenbedingungen eines Projektes, welches nach einer anderen Methode vorgeht. Die Projektinitialisierung ist nach wie vor eine der wichtigsten Phasen. Im Projektantrag muss das Vorgehen definiert sein, zum Beispiel mit einer Referenz auf diesen Leitfaden. Der Auftraggeber muss das Vorgehen unterstützen, dies macht er durch die Genehmigung des Projektantrages und durch die Freigabe der Phase Voranalyse. Da agile Vorgehensweisen in der Softwareentwicklung weit verbreitet, aber für die Fachseite der Projektbeteiligten weitgehend unbekannt sind, müssen die Projektbeteiligten geschult werden. Es empfiehlt sich auch, mindestens für die ersten 2 bis– 3 Sprints einen Coach zu engagieren, welcher die Projektbeteiligten in ihren Rollen unterstützt. Alle Projektbeteiligten müssen sich als Team verstehen und gut miteinander kommunizieren, auch wenn die Fachseite (Leistungsbezüger) und die technische Seite (Leistungserbringer oder Zulieferer) örtlich voneinander getrennt sind und vorgängig eventuell auch noch nicht zusammengearbeitet haben. Die einzelnen Beteiligten müssen daher über grosse Sozialkompetenz verfügen. Das Arbeiten nach agilen Vorgehensweisen ist für alle Beteiligten sehr transparent, d.h., es wird sehr schnell ersichtlich, wenn irgendwo im Projekt etwas nicht funktioniert, Probleme auftreten oder der Fortschritt nicht so ist, wie er erwartet wurde. Nicht alle Personen können mit dieser Transparenz umgehen und versuchen zum Teil, beim Auftreten von Problemen gegen dieses transparente Vorgehen zu arbeiten. Diese Transparenz ist aber sehr wichtig. Sie fördert das gegenseitige Vertrauen der involvierten Parteien und ist ein Grundbaustein für erfolgreiche Projekte. In jedem Projekt treten Probleme auf. Dies ist bei agilen Projekten nicht anders. Gerade aus diesem Grund wickelt man schwierige Vorhaben in Form von Projekten ab, da diese spezielle Organisationsform rascher auf Probleme reagieren kann. Bei nicht agilem Projektvorgehen wird oft versucht, Probleme so lange wie möglich zu vertuschen. Dies ist beim agilen Vorgehen aufgrund der Transparenz der Methode praktisch nicht möglich.

_________________ Kapitel 3: Agiles HERMES 13131313

Kapitel 3:Kapitel 3:Kapitel 3:Kapitel 3:

Agiles Agiles Agiles Agiles HERMESHERMESHERMESHERMES Wir zeigen nun Schritt für Schritt, wie das HERMES agil umgesetzt werden kann.

Abbildung 1: Vorgehen aus Sicht HERMES

Aus Sicht von HERMES bleiben die Phasen Initialisierung, Voranalyse und Abschluss unverändert bestehen. Nach der Phase Voranalyse folgt die Phase «Umsetzung KRE». Die HERMES Phasen Konzept, Realisierung und Einführung werden innerhalb eines Sprints einmal durchlaufen. Da in der Regel mehrere Sprints für das Erreichen eines Projektzieles nötig sind, werden diese Phasen entsprechend mehrmals durchlaufen.

Abbildung 2: Vorgehen aus Sicht Scrum

Aus Sicht von Scrum beginnt die Entwicklung nach Abschluss der Phase Voranalyse. Ab diesem Zeitpunkt werden die Arbeiten der Softwareentwicklung nach dem Vorgehen Scrum abgearbeitet. Dafür wird in der Voranalyse ein Initial Product Backlog erstellt. Die Submodelle Qualitätssicherung, Konfigurationsmanagement und Risikomanagement sind dabei fester Bestandteil der Sprints. Die Submodelle Projektmanagement und Projektmarketing werden parallel zur Entwicklung nach Scrum erledigt resp. durchgeführt, wobei im Idealfall die entsprechenden Tätigkeiten durch den Product Owner durchgeführt werden.


Abbildung 3: Streams

Grössere und komplexe Projekte werden in der Regel mit mehreren Scrum Teams abgewickelt. Die Scrum Teams arbeiten an einem gemeinsamen Product Backlog, besitzen aber je ein eigenes Sprint Backlog. Dabei werden die User Stories resp. Anforderungen idealerweise nach fachlichen Kriterien auf die Teams verteilt. Bei solchen Projekten sollte wenn möglich mit einem Scrum Team gestartet werden. Das Scrum Team nimmt sich als Erstes der grundlegenden Aufgaben an, d.h., technische und fachliche Grundkonzepte werden anhand erster fachlicher Funktionen umgesetzt. Dies können auf der fachlichen Seite Usability-Konzepte sein und auf der technischen Seite das Zusammenspiel der wichtigsten Frameworks und Integration der Funktionen auf der Zielplattform. Besteht Gewissheit über die Zweckmässigkeit und Funktionstüchtigkeit der entsprechenden Grundkonzepte, können mehrere Teams parallel arbeiten.


Abbildung 4: Entscheidungspunkte


Folgende Entscheide sind durch den Projektausschuss (PA) während des Projektes zu treffen:

• Bei der Freigabe der Phase Voranalyse muss bereits entschieden werden, ob das Projektvorgehen nach diesem Leitfaden erfolgen soll.

• Bei der Freigabe für die Entwicklung wird das Initial Product Backlog formell freigegeben. Wie vollständig aus Sicht dieses Zeitpunktes das Product Backlog sein muss, hängt stark von den Rahmenbedingungen ab.

• Wie bereits erwähnt, wird bei grösseren Projekten idealerweise mit einem Scrum Team gestartet, welches in den ersten Sprints Funktionen umsetzt, in welchen gezeigt wird, dass die Grundkonzepte zweckmässig und tauglich für das Vorhaben sind. In diesem Fall gibt es eine formelle Entscheidung für das Weiterführen des Projektes mit parallelen Scrum Teams, die nach Streams arbeiten.

• Pro Stream wird dann über die Freigabe für die Entwicklung entschieden.

Der Product Owner entscheidet am Ende jedes Sprints, ob die versprochenen Funktionen/Anforderungen des Sprints umgesetzt wurden und als abgenommen gelten.

PhasenPhasenPhasenPhasen

PhasePhasePhasePhase IIIInitialisierungnitialisierungnitialisierungnitialisierung In der Phase Initialisierung werden der Projektantrag und im Minimum das Projekthandbuch mit dem Projektplan erstellt. Im Projekthandbuch in Kapitel 3 ist ggf. auf diesen Leitfaden zu verweisen. Mit der Genehmigung des Projektantrages gibt der Projektausschuss u.a. das Vorgehen gemäss diesem Leitfaden frei. Wenn die Initialisierung nicht bereits durch den Product Owner gemacht wird, so muss in dieser Phase der Product Owner bestimmt werden, da dieser in der Phase Voranalyse massgeblich für das Erstellen des Initial Product Backlogs zuständig ist.

PhasePhasePhasePhase VoranaVoranaVoranaVoranalyselyselyselyse In der Phase Voranalyse wird das Initial Product Backlog erstellt. Damit der grobe Rahmen in Bezug auf Aufwand und Dauer abgeschätzt werden kann, werden die Product Backlog Items grob geschätzt und nach Business Value priorisiert. Beim Bestimmen des Business Values sollten technische Aspekte mit berücksichtigt werden. Die technischen Aspekte können durch den Scrum Master eingebracht werden. Als Regel gilt: Nicht-funktionale Anforderungen oder globale Anforderungen besitzen meistens den grössten Business Value, da bei Nichterfüllen dieser Anforderungen das Produkt resp. die Software meistens unbrauchbar ist.


In dieser Phase wird auch entschieden, mit welcher Technologie die Entwicklung erfolgen und auf welchen Plattformen das zukünftige System laufen soll. Mit dem Bericht <<Voranalyse>> wird die Freigabe der Phase Umsetzung KRE beantragt, in welcher dann nach Scrum gearbeitet wird.

Phase Phase Phase Phase UmsetzungUmsetzungUmsetzungUmsetzung KREKREKREKRE

Abbildung 5: Phase Umsetzung KRE

Im Rahmen der Phase Umsetzung KRE wird «usable» Software entwickelt. Die Softwareentwicklung folgt dabei dem Softwareentwicklungsprozess nach Scrum.

Phase Phase Phase Phase AbschlussAbschlussAbschlussAbschluss Die Phase Abschluss wird gemäss HERMES durchgeführt.


RollenRollenRollenRollen In agilen Projekten gibt es mindestens die drei Rollen Product Owner, Scrum Master und Scrum Team. Sind für das Projekt weitere Rollen nötig, so werden die Bezeichnungen vorwiegend gemäss HERMES verwendet. In vielen Fällen ist es zum Beispiel zweckmässig, explizit einen Projektleiter zu bestimmen, welcher die finanziellen, terminlichen und administrativen Aspekte des Projektes im Auge behält.

Abbildung 6: Rollen

In den folgenden Kapiteln werden die drei Rollen beschrieben. In Klammern stehen die möglichen entsprechenden HERMES Rollen. Besteht im Projekt das Bedürfnis, weitere Rollen oder Rollen-Gruppen aus HERMES in die Projektorganisation aufzunehmen, so ist dies durchaus möglich.

Product Product Product Product OwnerOwnerOwnerOwner,,,, PO PO PO PO ((((PLPLPLPL, AnwV, AnwV, AnwV, AnwV)))) Der Product Owner legt das gemeinsame Ziel fest, welches das Team zusammen mit ihm erreichen muss. Zur Definition der Ziele dienen ihm meist User Stories. Er setzt regelmässig die Prioritäten der einzelnen Product Backlog Items. Dadurch legt er fest, welches die wichtigsten Features sind, aus denen das Scrum Team eine Auswahl für den nächsten Sprint trifft. Der Product Owner führt den Entwicklungsaufwand durch die Vermittlung seiner fachlichen Vision für das Team, skizziert Arbeit im Product Backlog und priorisiert es basierend auf der Wert-Analyse. In dieser Rolle muss der Product Owner dem Scrum Team die Fragen beantworten und die Richtung vorgeben.


Die Scrum-Werte Selbstorganisation und als Ergebnis den eigenen Aktionsplan zu erstellen, muss der Product Owner respektieren. Dies bedeutet, dass es dem Product Owner verboten ist, dem Scrum Team in der Mitte des Sprints mehr Arbeit zu geben. Der Umfang eines Sprints sollte unberührt bleiben. Allerdings kann das Scrum Team den Product Owner ersuchen, weniger priore Anforderungen während eines Sprints zurückzustellen. Auch wenn sich die Anforderungen ändern oder eine konkurrierende Organisation ein neues Produkt stellt, welches die Arbeit des Scrum Teams überflüssig macht, kann der Product Owner nichts an der Sprint-Planung bis zum nächsten Planning Meeting ändern, er kann allerdings den laufenden Sprint jederzeit beenden. Darüber hinaus ist es in der Verantwortung des Product Owners, zu prüfen, welche Massnahmen den meisten geschäftlichen Nutzen erzeugen. Der Product Owner muss konsequent und proaktiv prüfen, welche Funktionen eines Produktes am wichtigsten sind und wann sie entwickelt werden. So wie das Scrum Team die ausgehandelte Arbeit für den Product Owner erledigen und das entsprechende Ergebnis produzieren muss, muss der Product Owner das Produkt an den Kunden liefern. Dem Produkt Owner obliegen folgende Aufgaben: • Definiert die fachliche Funktionalität in Form von User Stories • Definiert die Qualitätsanforderungen • Legt die Reihenfolge der Umsetzung fest (aus fachlicher Sicht) • Nimmt die umgesetzten Funktionen ab • Koordiniert die Funktionalität • Sichert die Qualität der User Stories • Koordination des Informationsflusses • Koordination externer und interner Projektbeteiligter • Koordination mehrerer Scrum Teams • Zuweisung der User Stories an die Scrum Teams • Sicherstellung des Know-how-Transfers (projektspezifisch) • Projektplanung • Projektmarketing • Projektberichterstattung Bezug zu HERMES: Der Produkt Owner entspricht in vielen Fällen dem Projektleiter (PL), er kann aber durchaus auch die Schlüsselperson der Anwendungsvertreter (AnwV) sein.

Scrum Scrum Scrum Scrum MasterMasterMasterMaster, SM, SM, SM, SM (PL(PL(PL(PL----AN, Arch, Entw)AN, Arch, Entw)AN, Arch, Entw)AN, Arch, Entw) Der Scrum Master hat die Aufgabe, die Aufteilung der Rollen und Rechte zu überwachen. Er hält die Transparenz während der gesamten Entwicklung aufrecht und unterstützt dabei, Verbesserungspotenziale zu erkennen und zu nutzen.


Er ist keinesfalls für die Kommunikation zwischen Scrum Team und Product Owner verantwortlich, da diese direkt miteinander kommunizieren. Er steht dem Scrum Team zur Seite, ist aber kein Product Owner. Der Scrum Master sorgt mit allen Mitteln dafür, dass das Scrum Team produktiv ist, also die Arbeitsbedingungen stimmen und die Scrum Teammitglieder zufrieden sind. Er tritt somit für die ordnungsgemässe Durchführung und Implementierung von Scrum im Rahmen des Projektes ein. Dem Scrum Master obliegen folgende Aufgaben: • Garantiert die Einhaltung des Scrum-Prozesses • Moderation des Scrum Teams • Problemlöser für das Scrum Team resp. den Scrum-Prozess

Bezug zu HERMES: Der Scrum Master kann nicht direkt einer HERMES Rolle zugeordnet werden. Es kann der Projektleiter Auftragnehmer (PL-AN), der Lösungsarchitekt (Arch) oder eine Schlüsselperson des Entwicklerteams (Entw) sein.

Scrum Scrum Scrum Scrum TeamTeamTeamTeam, ST, ST, ST, ST ((((Entw, ArchEntw, ArchEntw, ArchEntw, Arch, Tst, Tst, Tst, Tst, BetrV, BetrV, BetrV, BetrV)))) Das Scrum Team hat die Aufgabe, die Software / das Produkt zu erstellen, und besteht aus allen dafür notwendigen Rollen. Dem Scrum Team obliegen folgende Aufgaben: • Implementierung der Funktionalität der User Stories gemäss Sprint

Backlog • Einhaltung der Guidelines • Sicherstellung der Qualitätsanforderungen • Dokumentiert seine Arbeit transparent am Scrum Board • Formuliert technische Tasks im Rahmen von User Stories • Definition und Dokumentation des Systems (technisch) • Dokumentation des Systems (fachliche Dokumentation) • Aufwandschätzung Bezug zu HERMES: Das Scrum Team entspricht im Kern den Entwicklern (Entw) von HERMES. Der Lösungsarchitekt (Arch) und/oder der Tester (Tst) können aber auch Bestandteil des Scrum Teams sein.

ErgebnisseErgebnisseErgebnisseErgebnisse Benötigte Dokumente, welche für das Projekt einen Mehrwert bringen, werden grundsätzlich aus HERMES übernommen. In den folgenden Kapiteln werden Scrum-spezifische Ergebnisse beschrieben, welche in HERMES nicht enthalten sind.


Product Product Product Product BacklogBacklogBacklogBacklog Das Product Backlog repräsentiert in Form einer Liste die Product Backlog Items. Die Backlog Items können Anforderungen in irgendeiner Form sein, sei es eine Formulierung mit Textschablonen wie z. B. einer User Story nach dem Muster:

«Als Anwender mit der Rolle x benötige ich die Funktionalität,

damit ich den Nutzen y erhalte», oder in einer anderen geeigneten Form, welche dem Product Owner als Gedächtnisstütze für das Sprint Planning 1 dient oder den Sachverhalt den Entwicklern verständlich macht. In welcher Form und wie fein granular die Product Backlog Items sind, hängt stark vom Projekt ab und von der Art, wie der Product Owner arbeitet. Dabei ist folgende Aussage zu beachten: «In einem Scrum-Projekt sollte niemand davon ausgehen, dass das Backlog Item etwas aussagt, was unbesprochen geliefert werden kann.» Die Product Backlog Items werden nach deren Business Value priorisiert in einer Liste geführt. Das Product Backlog wird üblicherweise in Story Points geschätzt. In der Regel wird diese Schätzung mit der Methode Planning Poker durch das Team erstellt. Die Story Points stellen den relativen Aufwand der Product Backlog Items untereinander dar. Die Schätzung wird nach dem Erstellen des Initial Product Backlogs vorgenommen und in regelmässigen Estimation Meetings während der Sprints.

InitialInitialInitialInitial ProduProduProduProducccct Backlogt Backlogt Backlogt Backlog Das Initial Product Backlog wird in der Phase Voranalyse erstellt und bildet den Startpunkt für die Entwicklung nach Scrum. Damit der Product Owner eine erste Priorisierung vornehmen kann, muss das ganze Initial Product Backlog grob geschätzt werden, so dass die Dimensionen in Bezug auf die Komplexität für die Umsetzung sichtbar werden. Wird von einem Auftragnehmer ein Festpreis verlangt (WTO, Werkvertrag), so muss das Initial Product Backlog bereits sehr detailliert erstellt werden. Neue Funktionen, welche zu einem späteren Zeitpunkt in das Product Backlog aufgenommen werden, unterliegen dann einem klassischen Change-Prozess. Wird das Projekt nach Aufwand abgewickelt, so muss das Initial Product Backlog so weit detailliert sein, dass ein Kostenrahmen abschätzbar ist und eine Anzahl von Sprints geschätzt werden kann.

Sprint BacklogSprint BacklogSprint BacklogSprint Backlog Das Sprint Backlog enthält alle Aufgaben, die notwendig sind, um das Ziel des Sprints zu erfüllen. Eine Aufgabe sollte dabei in einem Tag erledigbar sein.


Längere Aufgaben sollten in kurze Teilaufgaben zerlegt werden. Bei der Planung des Sprints werden nur so viele Aufgaben eingeplant, wie das Scrum Team in diesem Sprint für realistisch durchführbar hält. Üblicherweise wird dies aus der Geschwindigkeit des vorangegangenen Sprints geschätzt.

Burndown ChartBurndown ChartBurndown ChartBurndown Chart Das Burndown Chart ist eine grafische, pro Tag zu erfassende Darstellung des noch zu erbringenden Restaufwands pro Sprint. Im Idealfall fällt die Kurve kontinuierlich (daher Burndown), und der Restaufwand ist am Ende des Sprints Null. Das Chart lässt anhand der Verlängerung des Gefälles bereits während des Sprints erkennen, ob der anfangs geschätzte Aufwand umgesetzt werden kann. Es ist möglich, mehrere Burndown Charts zu führen. Zum Beispiel ein Sprint Burndown Chart, welches dem Scrum Team dient, und ein Stream Burndown Chart, welches dem Product Owner dient, mit welchem er abschätzen kann, ob der entsprechende Stream in den vorgesehenen Anzahl Sprints die Funktionen umsetzen kann.

ImpedimentImpedimentImpedimentImpediment BacklogBacklogBacklogBacklog In das Impediment Backlog werden alle Hindernisse des Projekts eingetragen. Der Scrum Master ist dafür zuständig, diese gemeinsam mit dem Team auszuräumen.

DefinitiDefinitiDefinitiDefinition of Done (DoD)on of Done (DoD)on of Done (DoD)on of Done (DoD) In der Definition of Done wird festgehalten, welche generellen Voraussetzungen beim Review Meeting erfüllt sein müssen, damit die Funktionalität vom Product Owner abgenommen wird. Dies können zum Beispiel Angaben zur Testabdeckung sein oder zur Umgebung, auf welcher die Funktionalität vorgeführt werden muss, oder einzuhaltende Codier-Richtlinien oder weitere Merkmale. Die Definition of Done ist nicht eine mehrseitige Auflistung von Dingen, die getan werden müssen, um einen Task auf erledigt zu setzen. Wie immer, wenn es darum geht, Qualitätsmerkmale zu definieren, muss man Schwerpunkte setzten. Die Definition of Done muss auf dem Scrum Board oder neben dem Scrum Board Platz haben. Sie ist in der Regel sehr kurz gehalten und kann also nicht grösser als eine A4-Seite sein, die auch aus 3 Metern Entfernung lesbar ist. Beispiele sind:

1. Alle Unit-Tests laufen ohne Fehler auf der Integrationsumgebung durch. 2. Die Testabdeckung ist > 60%.

Ein zweiter Entwickler hat die Funktion getestet resp. es wurde ihm die Funktion demonstriert und der Code gezeigt (Vier-Augen-Prinzip).


MeetingsMeetingsMeetingsMeetings

Sprint Sprint Sprint Sprint PlanningPlanningPlanningPlanning 1111 In diesem Treffen, welches maximal 4 Stunden dauert, erklärt der Product Owner dem Scrum Team so viele Backlog-Einträge, wie das Scrum Team glaubt, im nächsten Sprint umsetzen zu können. Ausserdem einigt er sich mit dem Scrum Team auf das Sprint-Ziel. Dieses Sprint-Ziel bildet nach dem Sprint die Basis für die Abnahme. Die höchst priorisierten Einträge des Product Backlogs werden entsprechend dem Ergebnis des Treffens in den Sprint Backlog übernommen.

Sprint Sprint Sprint Sprint PlanningPlanningPlanningPlanning 2222 Dieses Treffen, welches maximal 4 Stunden dauert, organisiert das Scrum Team eigenverantwortlich. Hier werden die ausgewählten Product Backlog Items in Tasks zerlegt und die Komplexität mittels Story Points geschätzt. Nach dem Sprint Planning 2 ist klar, welche Product Backlog Items effektiv im nächsten Sprint abgearbeitet werden können, basierend auf der Schätzung der Tasks und der Velocity des entsprechenden Scrum Teams. Die Velocity wird basierend auf dem vorgängigen Sprint berechnet und entspricht den Story Points, welche beim letzten Sprint abgearbeitet wurden. Im ersten Sprint, wo noch keine Messung vorliegt, wird die Velocity vom Scrum Team geschätzt.

Daily ScrumDaily ScrumDaily ScrumDaily Scrum An jedem Tag findet ein kurzes (maximal 15-minütiges) Daily Scrum statt. Scrum definiert keine konkrete Uhrzeit für das Meeting, das Meeting sollte jedoch täglich zur gleichen Zeit stattfinden. Empfohlener Zeitpunkt für das Scrum Meeting ist die Zeit nach dem Mittagessen, da morgendliche Scrum Meetings oft mit flexiblen Gleitzeitregelungen kollidieren und der müde Punkt nach dem Mittagessen bei einem Scrum Meeting, das durchaus im Stehen abgehalten werden kann, nicht so stark ins Gewicht fällt wie bei anderen Tätigkeiten. Die Meetings sind so kürzer als am Morgen, weil allgemeine Dinge und Neuigkeiten schon vorher diskutiert wurden und die Mitarbeiter mit dem Kopf ganz bei der Arbeit sind. Jedes Teammitglied beantwortet die folgenden Fragen: • Welche Aufgaben hast du seit dem letzten Meeting fertiggestellt? • Welche Aufgaben wirst du bis zum nächsten Meeting bearbeiten? • Gibt es Probleme, die dich bei deinen Aufgaben behindern? Die Sitzung dient dem Informationsaustausch des Teams untereinander. Hier geht es darum, dass möglichst alle alles wissen. Falls neue Hindernisse erkannt wurden, müssen diese vom Scrum Master bearbeitet werden. Dazu werden sie in den Impediment Backlog eingetragen. Im Daily Scrum haben nur die Teammitglieder und der Scrum Master eigenständiges Rederecht; alle


anderen Zuhörer (Interessierte, z. B. Product Owner, Vorgesetzte, Kunden, Gäste, andere Scrum Teams) reden nur, wenn sie gefragt werden. Grössere Projekte werden durch das Einführen von Scrum-of-Scrum-Meetings, Product Owner Daily Scrums und Scrum Master Weekly gesteuert.

ReviewReviewReviewReview In einem Review Meeting, welches maximal 4 Stunden dauert, wird nach einem Sprint das Sprint-Ergebnis einem informellen Review durch das Scrum Team und durch den Product Owner unterzogen. Dazu wird das Ergebnis des Sprints (die laufende Software) vorgeführt, eventuell werden technische Eigenschaften präsentiert. Der Product Owner prüft, ob das Sprint-Ergebnis seinen Anforderungen entspricht. Eventuelle Änderungen können in Form von Erweiterungen, Umpriorisierungen oder durch das Entfernen von Elementen des Product Backlogs dokumentiert werden.

RetrospektiveRetrospektiveRetrospektiveRetrospektive In der Retrospektive, welche maximal 3 Stunden dauert, wird die zurückliegende Sprint-Phase betrachtet. Es handelt sich dabei nicht um «Lessons Learned», sondern um einen zunächst wertungsfreien Rückblick auf die Ereignisse des Sprints. Das Team und der Scrum Master stellen sich folgende Fragen: • Was war gut? • Was könnte verbessert werden?

Jedes Verbesserungspotenzial wird priorisiert und einem Verantwortungsbereich (Scrum Team oder Organisation) zugeordnet. Alle der Organisation zugeordneten Themen werden vom Scrum Master aufgenommen und ins Impediment Backlog eingetragen. Alle Scrum-Team-bezogenen Punkte werden ins Product Backlog aufgenommen. Egal, wie die Retrospektive gestaltet wird, das Ziel ist, den vergangenen Sprint zu beleuchten und daraus zu lernen.

Estimation MeetingEstimation MeetingEstimation MeetingEstimation Meeting In der Regel wird pro Sprint einmal ein Estimation Meeting abgehalten, in dem der Product Owner neue Einträge im Product Backlog grob vorstellt, so dass das Scrum Team eine grobe Schätzung vornehmen kann. Die Schätzung ist für den Product Owner ein wichtiges Hilfsmittel, um die Priorisierung der einzelnen Einträge vornehmen und den Gesamtaufwand des Projektes abschätzen zu können. Als Werkzeuge zum Schätzen eignen sich Planning Poker oder Smart Poker. Mit den Werkzeugen wird nicht direkt der Aufwand in Stunden oder Tagen geschätzt, sondern die Komplexität mittels Story Points.


PlanungPlanungPlanungPlanung Ein Plan dient dazu, einen Weg zum angestrebten Ziel aufzuzeigen, um während der Reise Abweichungen sichtbar zu machen und wenn nötig bewusst neue Ziele definieren zu können. Die Planung wird durch den Product Owner erstellt. Der Scrum Master kann den Product Owner unterstützen.

Planung startenPlanung startenPlanung startenPlanung starten Beim Erstellen des Initial Backlogs werden die Items priorisiert. Danach wird jedes Item grob geschätzt. Anhand der Schätzung kann die Menge der benötigten Sprints festgelegt werden. Damit die fachlichen Tester wissen, ab welchem Zeitpunkt sie mit einem Fachthema rechnen können, ist es möglich, die Sprints auch bereits mit einem Thema gemäss Prioritäten des Product Backlogs zu belegen. Ein Thema entspricht dabei einer Sammlung von Product Backlog Items.

PlanenPlanenPlanenPlanen Während des Projektes kann nun bei jedem Sprint, bei der Initialisierung, nach dem Planning Meeting 2 die Planung überprüft und angepasst werden. Dabei werden die Anzahl der geplanten Sprints überprüft und die Themen pro Sprint angepasst. Für alle Projektbeteiligten ist so ersichtlich, wenn mehr Sprints benötigt werden oder die Themen der Sprints verschoben oder umpriorisiert werden.

Neue Product Backlog ItemsNeue Product Backlog ItemsNeue Product Backlog ItemsNeue Product Backlog Items Es ist in der Natur eines Softwareprojektes, dass während des Projektes neue Funktionen oder ganze Themen auftauchen, an die bei der Initialisierung des Projektes niemand gedacht hat. Die Themen oder Funktionen werden ins Product Backlog übernommen. Die neuen Items werden durch das Scrum Team in einem Estimation Meeting während eines Sprints geschätzt.

26262626 Leitfaden Agiles HERMES _______________________

Kapitel Kapitel Kapitel Kapitel 4444::::

QualitätsQualitätsQualitätsQualitäts---- und Risikomanagementund Risikomanagementund Risikomanagementund Risikomanagement

QualitätsmanagementQualitätsmanagementQualitätsmanagementQualitätsmanagement Um die Qualität der Ziele und Anforderungen sicherzustellen, empfiehlt es sich, während der Phase Voranalyse eine klassische Qualitätskontrolle resp. einen Freigabeprozess zu etablieren. Für die Qualität des Informatiksystems während der Phase Umsetzung KRE ist das Scrum Team verantwortlich. Die Qualitätserwartung des Product Owners wird in der Definition of Done festgehalten. In der Definition of Done wird festgehalten, welche generellen Voraussetzungen beim Review Meeting erfüllt sein müssen, damit die Funktionalität vom Product Owner abgenommen wird. Dies können zum Beispiel Angaben zur Testabdeckung sein oder zur Umgebung, auf welcher die Funktionalität vorgeführt werden muss, sowie weitere Merkmale. Die Qualität für die Endbenutzer, also ob das System brauchbar und für den täglichen Einsatz geeignet ist, muss klassisch durch fachliche Tests erhoben und überprüft werden.

RisikomanagementRisikomanagementRisikomanagementRisikomanagement Risiken werden grundsätzlich durch das agile Vorgehen minimiert. Durch die Priorisierung der Anforderungen nach Business Value werden hohe Risiken automatisch früh angegangen, wenn die Risikobewertung richtig gemacht wird. Es ist wichtig, dass bei der Bewertung der Risiken sowohl der Product Owner und die Anwender einbezogen werden als auch der Scrum Master und das Scrum Team. Ein Risiko muss immer mit Kosten und Eintrittswahrscheinlichkeit bewertet werden. Das Produkt der beiden Werte ergibt den Business Value. Damit werden die Massnahmen, mit welchen dem Risiko entgegengewirkt wird, priorisiert. Die aus den Massnahmen abgeleiteten Aufgaben oder erweiterten Anforderungen werden dem Business Value entsprechend im Product Backlog priorisiert aufgenommen.

_____________________ Kapitel 5: Szenarien 27272727

Kapitel Kapitel Kapitel Kapitel 5555: : : :

SzenarienSzenarienSzenarienSzenarien Folgend werden fünf Szenarien vorgestellt. Diese dienen als Rahmen für die verschiedenen beschriebenen Vorgehensmöglichkeiten und sollen dem leichteren Verständnis dienen. Je nach Risiken und Eigenschaften eines konkreten Projektes ist es möglich, verschiedene Szenarien zu kombinieren.

Projekt 0Projekt 0Projekt 0Projekt 0----8888----15151515

Abbildung 7: 0-8-15-Projekt

In einem 0-8-15-Projekt ist der Umfang von Anfang an für alle Beteiligten klar ersichtlich. Es besteht weitgehend Konsens bei allen Beteiligten darüber, welche Ziele erreicht werden müssen. Es existieren nur beschränkt Risiken in Bezug auf die Technologie und die Umsetzung.

Eigenschaften:

• Klare Vision des Auftraggebers. • Alle Stakeholder sind sich über die zu erreichenden Ziele einig. • Die Infrastruktur, auf welcher das zukünftige System laufen soll, ist

bekannt und wird für andere Systeme bereits vom vorgesehenen Betreiber eingesetzt.

• Es wird nur ein Scrum Team mit maximal 8 Personen benötigt. • Der grösste Teil des Scrum Teams hat bereits agil zusammengearbeitet

und ein ähnliches System mit der gleichen Technologie erstellt. Risiken:

• Es bestehen keine grösseren Risiken bezüglich Anforderungen und Technologie.

Vorgehen: Die Phasen Initialisierung und Voranalyse können zusammengefasst werden. Der Projektausschuss entscheidet über die Freigabe der Phase Umsetzung KRE. In der Phase Umsetzung KRE wird das System erstellt und eingeführt. Es ist auch in diesem Szenario denkbar resp. empfohlen, dass mehrere Versionen oder Release-Einheiten bis zum Anwender ausgerollt werden. Ergebnisse: Siehe Anhang Tabelle 1: Ergebnisse zu Szenario 0-8-15


Projekt Verschiedene AnwendergruppenProjekt Verschiedene AnwendergruppenProjekt Verschiedene AnwendergruppenProjekt Verschiedene Anwendergruppen

Abbildung 8: Verschiedene Anwendergruppen

In einem Projekt mit verschiedenen Anwendergruppen muss für die Erarbeitung einer konsolidierten Sicht auf das Problem und die einheitliche Vorstellung über die Ziele für das Softwaresystem genügend Zeit eingeplant werden. Die Vision und die Ziele müssen Schritt für Schritt erarbeitet werden, damit keine Unterbrechung in der Phase Umsetzung KRE durch langwierige Abklärungen des Product Owners riskiert wird. Eigenschaften:

• Es existieren verschiedene Anwendergruppen, welche verschiedene Meinungen über den Zweck und die Ziele des zu erstellenden Softwaresystems haben.

• Die Vision steht nicht von vornherein fest und muss mit dem Auftraggeber erarbeitet werden.

• Die Infrastruktur, auf welcher das zukünftige System laufen soll, ist bekannt und wird für andere Systeme bereits vom vorgesehenen Betreiber eingesetzt.

• Es wird nur ein Scrum Team mit maximal 8 Personen benötigt. • Der grösste Teil des Scrum Teams hat bereits agil zusammengearbeitet

und ein ähnliches System mit der gleichen Technologie erstellt. Risiken:

• Es bestehen Risiken bezüglich der Festlegung konsolidierter Ziele sowie der Anforderungserhebung.

• Es bestehen keine Risiken bezüglich vorgesehener Technologien. Vorgehen: Die Phasen Initialisierung und Voranalyse werden gemäss HERMES SE durchlaufen. Es kann durchaus sein, dass während der Initialisierung und beim Start der Phase Voranalyse noch kein Product Owner, Scrum Master und Scrum Team existiert resp. bestimmt wurde. Dies kann durchaus erst in der Phase Voranalyse geschehen. Da die Technologien in diesem Szenario bekannt sind, muss in der Phase Umsetzung KRE kein Entscheid über die Architektur getroffen werden, resp. dieser Entscheid wird bereits bei der Freigabe der Phase Umsetzung KRE getroffen. Es ist auch in diesem Szenario denkbar resp. empfohlen, dass mehrere Versionen oder Release-Einheiten bis zum Anwender ausgerollt werden. Ergebnisse: Siehe Anhang Tabelle 2: Ergebnisse zu Szenario Verschiedene Anwendergruppen


Projekt Projekt Projekt Projekt NeueNeueNeueNeue TechnologieTechnologieTechnologieTechnologie / Archite/ Archite/ Archite/ Architekkkkturturturtur

Abbildung 9: Neue Technologie / Architektur

In diesem Szenario gehen wir davon aus, dass wie beim Szenario 0-8-15 die Vision und die Ziele von vornherein klar sind, die Herausforderung aber in neuen Technologien liegt, die für das Team neu sind oder in einer neuen Version benutzt werden. Es kann auch sein, dass die Technologien bekannt sind, aber die Architektur neu für das Team ist. In diesem Fall können nicht-funktionale Anforderungen wie Antwortzeitverhalten oder Stabilität nicht bei einem bestehenden System verifiziert werden.

Eigenschaften:

• Klare Vision des Auftraggebers. • Alle Stakeholder sind sich über die zu erreichenden Ziele einig. • Die Infrastruktur, auf welcher das zukünftige System laufen soll, ist nicht

bekannt, oder die vorgesehenen Softwarekomponenten sind neu, oder die gewählte Architektur ist für den Anwendungsbereich neu.

Risiken:

• Es bestehen keine Risiken bezüglich Anforderungen resp. des Erhebens konsolidierter Ziele und Anforderungen.

• Es bestehen Risiken bezüglich vorgesehener Technologien. Vorgehen: Die Phasen Initialisierung und Voranalyse werden wie in Szenario 0-8-15 zusammengelegt. In den ersten Sprints müssen die nicht-funktionalen Anforderungen verifiziert werden. Dies wird immer durch ein Scrum Team gemacht. Die Resultate müssen dem Projektausschuss vorgelegt werden, damit er die Freigabe für die Entwicklung der restlichen Funktionen gibt. Das bedeutet, dass die Freigabe für die Phase Umsetzung KRE in zwei Schritten erteilt wird. Nach der Phase Initialisierung/Voranalyse erfolgt die Freigabe für die ersten Sprints, in welchen ein Teil der Anforderungen umgesetzt wird, mit dem Ziel, die Erfüllbarkeit der nicht-funktionalen Anforderungen mit der zugrunde liegenden Technologie resp. Architektur zu beweisen. Ist der Projektausschuss von den vorgelegten Resultaten überzeugt, erfolgt die Freigabe für die restlichen Anforderungen. Ergebnisse: Siehe Anhang Tabelle 3: Ergebnisse zu Szenario Neue Technologie / Architektur


Project N Project N Project N Project N EntwicklerEntwicklerEntwicklerEntwickler ----TeamsTeamsTeamsTeams

Abbildung 10: N Entwickler-Teams

In diesem Szenario wird in der Phase Umsetzung KRE mit mehreren Scrum Teams das System erstellt. Wir gehen in diesem Szenario auch davon aus, dass mehrere Anwendergruppen bestehen. Das Szenario entspricht in der Regel einem mittleren bis grossen Projekt.

Eigenschaften:

• Es existieren verschiedene Anwendergruppen, welche verschiedene Vorstellungen vom Zweck und von den Zielen des zu erstellenden Softwaresystems haben.

• Die Vision steht nicht von vornherein fest und muss mit dem Auftraggeber erarbeitet werden.

• Die Entwicklung erfolgt mit mehreren parallel arbeitenden Scrum Teams, ggf. fachlich organisiert in mehreren Streams.

Risiken:

• Es bestehen Risiken bezüglich Anforderungen resp. des Erhebens konsolidierter Ziele und Anforderungen.

• Es bestehen Risiken bezüglich koordinierten Vorgehens und einheitlichen Umsetzens der Anforderungen.

• Es können auch Risiken bezüglich Stabilität und Antwortzeitverhalten bestehen.

Vorgehen: Die Phasen Initialisierung und Voranalyse erfolgen analog dem Szenario Verschiedene Anwendergruppen. Damit mit parallelen Scrum Teams gearbeitet werden kann, muss eine gemeinsame Vorstellung über die Umsetzung der Anforderungen und eingesetzten Entwicklungstechniken und der Entwicklungsart bestehen. Dies ist am einfachsten zu erreichen, wenn bereits ein paar Anforderungen umgesetzt wurden. Wie beim Szenario Neue Technologie / Architektur werden zuerst mit einem Scrum Team die ersten Anforderungen in ein oder mehreren Sprints umgesetzt. Die Funktionalität und der dafür entwickelte Code dienen als Richtlinie für die anderen Scrum Teams. Die Phase Umsetzung KRE wird in zwei Schritten freigegeben, da beim Starten der parallelen Scrum Teams


die Freigabe von vielen Ressourcen erfolgt. Die Freigabe erfolgt durch den Projektausschuss. Ergebnisse: Siehe Anhang Tabelle 4: Ergebnisse zu Szenario N Entwickler Teams

Projekt Projekt Projekt Projekt WTOWTOWTOWTO----AusschreibungAusschreibungAusschreibungAusschreibung

Abbildung 11: WTO-Ausschreibung

Der Bund und die Bundesbetriebe müssen Projekte, bei denen die Projektkosten eine gewisse Grösse erreichen, nach einem strikten Verfahren ausschreiben. Beim Erstellen der Ausschreibungsunterlagen müssen Anforderungen für das zukünftige System festgelegt werden. Dieses Vorgehen entspricht nicht den agilen Ansätzen, verhindert sie aber auch nicht. Änderungen in den Anforderungen während der Umsetzung müssen in diesem Fall über ein striktes Changemanagement behandelt werden. Dies erhöht den administrativen Aufwand für den Product Owner, betrifft aber die Arbeitsweise der Scrum Teams nicht. Eigenschaften:

• Die Projektgrösse bedingt eine WTO-Ausschreibung. Risiken:

• Es bestehen Risiken bezüglich des Erhebens der vollständigen und konsistenten Anforderungen.

• Es bestehen Risiken bezüglich formeller Fehler beim Ausschreibungsprozess.

• Es bestehen Risiken bezüglich der Erfüllung der nicht-funktionalen Anforderungen der angebotenen Lösungen.

Vorgehen: Das Vorgehen entspricht im Grundsatz dem Szenario N Entwickler-Teams. Nach der Voranalyse muss die Phase Evaluation nach HERMES SA durchlaufen werden. Ergebnisse: Siehe Anhang Tabelle 5: Ergebnisse zu Szenario WTO-Ausschreibung


Kapitel Kapitel Kapitel Kapitel 6666: : : :

AnhangAnhangAnhangAnhang

Ergebnisse zu den SzenarienErgebnisse zu den SzenarienErgebnisse zu den SzenarienErgebnisse zu den Szenarien Auf den folgenden Seiten werden die möglichen Ergebnisse eines Szenarios festgehalten. In den Spalten A (Ausführender), mA (Mitarbeitender), E (Entscheider) werden die verantwortlichen Rollen angegeben. Die Ergebnisse aus der Methode Scrum sind grün hinterlegt. Die Entscheidungspunkte sind hellblau hinterlegt. Die angegebene Phase, in welcher die Ergebnisse aufgeführt sind, markiert den Initialzeitpunkt des Ergebnisses. In einem iterativen Vorgehen werden alle Ergebnisse bei Bedarf laufend verfeinert und angepasst. Bei der Auflistung der Rollen wird verdeutlicht, wie die Rollen von Scrum und HERMES verwendet werden können. Mit Ausnahme des Szenarios 0-8-15 ist auch der Übergang einer HERMES Rolle in eine Scrum-Rolle aufgezeigt, in dem in der Voranalyse der Projektleiter (PL) durch den Product Owner (PO) ersetzt wird. Diese können gemäss dem Rollengedanken durchaus dieselbe Person sein, welche ab einem gewissen Zeitpunkt eine andere Rolle einnimmt.

_____________________ Kapitel 6: Anhang 33333333

Ergebnisse zu SzenariErgebnisse zu SzenariErgebnisse zu SzenariErgebnisse zu Szenario 0o 0o 0o 0----8888----15151515 Ergebnis A mA E Phase Initialisierung / Voranalyse Projekthandbuch inkl. Projektplan, QS-Plan (Ziele), Risikokatalog

PO SM, Arch

Projektantrag inkl. Systemziele und Lösungsvorschlag PO AG Systemarchitektur Arch BetrV Initial Product Backlog (Systemanforderungen)

PO SM, AnwV, BetrV

Wirtschaftlichkeit PO ISDS-Konzept ISDSV Datensammlung Anmeldung PO ISDSV Ausbildungskonzept AnwV Einführungskonzept PO AnwV, ST,

BetrV Freigabe Phase Umsetzung KRE PO SM,

AnwV, BetrV

AG, PA

Phase Umsetzung KRE Product Backlog PO SM, AnwV Sprint Backlog SM ST Definition of Done PO SM,

ST Informatiksystem ST SM, AnwV,

BetrV Betriebshandbuch ST BetrV Migrationsverfahren PO ST, BetrV Freigabe Phase Abschluss PO Arch,

AnwV, BetrV

AG, PA

Phase Abschluss Bericht «Projektschlussbeurteilung» PO SM,

ST Projektabschluss PO ST,

AnwV, BetrV, SM

AG, PA

Tabelle 1: Ergebnisse zu Szenario 0-8-15


Ergebnisse zu Szenario Verschiedene AnwendergruppenErgebnisse zu Szenario Verschiedene AnwendergruppenErgebnisse zu Szenario Verschiedene AnwendergruppenErgebnisse zu Szenario Verschiedene Anwendergruppen Ergebnis A mA E Phase Initialisierung Projekthandbuch PL AG,

Arch Projektplan PL Arch Projektantrag PL AG Risikokatalog RV PL,

AG QS-Plan (Ziele) QV QM Projektauftrag PL AG,

PA Phase Voranalyse Systemziele Arch Team Lösungsvorschlag PL Arch,

AnwV, BetrV

Systemarchitektur Arch BetrV Wirtschaftlichkeit PL ISDS-Konzept ISDSV Datensammlung Anmeldung PL ISDSV Systemanforderungen PL AnwV,

BetrV Initial Product Backlog

PO SM, AnwV, BetrV

Ausbildungskonzept AnwV Einführungskonzept PO AnwV,

ST, BetrV

Freigabe Phase Umsetzung KRE PO SM, AnwV, BetrV

AG, PA

Phase Umsetzung KRE Product Backlog PO SM,

AnwV Sprint Backlog SM ST Definition of Done PO SM,

ST Informatiksystem ST SM,

AnwV, BetrV

Betriebshandbuch ST BetrV Migrationsverfahren PO ST,

BetrV Freigabe Phase Abschluss

PO Arch, AnwV, BetrV

AG, PA



AnwV, BetrV, SM

AG, PA

Tabelle 2: Ergebnisse zu Szenario Verschiedene Anwe ndergruppen

_____________________ Kapitel 6: Anhang 35353535

Ergebnisse zu Szenario Neue Technologie / ArchitekturErgebnisse zu Szenario Neue Technologie / ArchitekturErgebnisse zu Szenario Neue Technologie / ArchitekturErgebnisse zu Szenario Neue Technologie / Architektur Ergebnis A mA E Phase Initialisierung / Voranalyse Projekthandbuch inkl. Projektplan, QS-Plan (Ziele), Risikokatalog

PO SM, Arch

Projektantrag inkl. Systemziele und Lösungsvorschlag PO AG Systemarchitektur Arch BetrV Initial Product Backlog (Systemanforderungen)

PO SM, AnwV, BetrV

Wirtschaftlichkeit PO ISDS-Konzept ISDSV Datensammlung Anmeldung PO ISDSV Ausbildungskonzept AnwV Einführungskonzept PO AnwV,

ST, BetrV

Freigabe Phase Umsetzung KRE für Initial Sprints PO SM, AnwV, BetrV

AG, PA

Phase Umsetzung KRE Freigabe Phase Umsetzung KRE restliche Anforderungen PO Arch,

AnwV, BetrV

PA

Product Backlog PO SM, AnwV

Sprint Backlog SM ST Definition of Done PO SM,


AnwV, BetrV


BetrV Freigabe Phase Abschluss

PO Arch, AnwV, BetrV

AG, PA



AnwV, BetrV, SM

AG, PA

Tabelle 3: Ergebnisse zu Szenario Neue Technologie / Architektur


Ergebnisse zu Szenario N Ergebnisse zu Szenario N Ergebnisse zu Szenario N Ergebnisse zu Szenario N EntwicklerEntwicklerEntwicklerEntwickler ----TeamsTeamsTeamsTeams Ergebnis A mA E Phase Initialisierung Projekthandbuch PL AG,



PA Phase Voranalyse Systemziele Arch Team Lösungsvorschlag PL Arch, AnwV,

BetrV Systemarchitektur Arch BetrV Wirtschaftlichkeit PL ISDS-Konzept ISDSV Datensammlung Anmeldung PL ISDSV Systemanforderungen PL AnwV, BetrV Initial Product Backlog

PO SM, AnwV, BetrV

Ausbildungskonzept AnwV Einführungskonzept PO AnwV, ST,

BetrV Freigabe Phase Umsetzung KRE für Initial Sprints

PO SM, AnwV,BetrV

AG, PA


AnwV, BetrV

PA




AnwV, BetrV


BetrV Freigabe Phase Abschluss PO Arch,

AnwV, BetrV

AG, PA



AnwV, BetrV, SM

AG, PA

Tabelle 4: Ergebnisse zu Szenario N Entwickler Team s

_____________________ Kapitel 6: Anhang 37373737

Ergebnisse zu Szenario Ergebnisse zu Szenario Ergebnisse zu Szenario Ergebnisse zu Szenario WTOWTOWTOWTO----AusschreibungAusschreibungAusschreibungAusschreibung Ergebnis A mA E Phase Initialisierung Projekthandbuch PL AG,



PA Phase Voranalyse Systemziele Arch Team Lösungsvorschlag PL Arch,

AnwV, BetrV

Systemarchitektur Arch BetrV Wirtschaftlichkeit PL ISDS-Konzept ISDSV Datensammlung Anmeldung PL ISDSV Systemanforderungen PL AnwV,

BetrV Ausbildungskonzept AnwV Einführungskonzept PL AnwV,

Arch, BetrV

Freigabe Phase Evaluation

PL Arch, AnwV, BetrV

AG, PA

Phase Evaluation Alle Ergebnisse gem. HERMES SA müssen erarbeitet werden PL Arch,

AnwV, BetrV

Initial Product Backlog

PO SM, AnwV, BetrV

Freigabe Phase Umsetzung KRE für Initial Sprints

PO SM, AnwV, BetrV

AG, PA



AnwV, BetrV

PA




AnwV, BetrV


BetrV Freigabe Phase Abschluss PO Arch,

AnwV, BetrV

AG, PA



AnwV, BetrV, SM

AG, PA

Tabelle 5: Ergebnisse zu Szenario WTO-Ausschreibung

_____________________ Kapitel 6: Anhang 39393939

BegriffeBegriffeBegriffeBegriffe Begriffe Beschreibung Iteration Im Kontext dieses Leitfadens ist eine Iteration das Durchlaufen der HERMES

Phasen Konzept, Realisierung und Einführung.

Sprint Synonym für eine Iteration respektive das einmalige Durchlaufen der HERMES Phasen Konzept, Realisierung und Einführung.

Product Backlog Eine Liste, in welcher Anforderungen und Tätigkeiten nach Priorität für das gesamte Projekt festgehalten werden. Dabei ist der erste Eintrag in der Liste das am höchsten priorisierte Element.

Sprint Backlog Eine Liste, in welcher Anforderungen und Tätigkeiten nach Priorität für einen Sprint festgehalten werden. Dabei ist der erste Eintrag in der Liste das am höchsten priorisierte Element. Im Idealfall ist der Aufwand zum Erledigen eines Elementes maximal ein Tag.

Burndown Chart Performance-Messung eines Teams während eines Sprints.

Impediment Backlog

Liste mit Hindernissen, welche während des Projektes auftreten und den Erfolg des Projektes gefährden.

Timeboxing Prinzip nach dem für alle Aktivitäten ein Zeitrahmen definiert wird, der nicht

überschritten werden darf. Ist der Zeitrahmen erreicht, wird die Aktivität konsequent abgebrochen.

KRE Abkürzung für die HERMES Phasen Konzept, Realisierung und Einführung

User Stories Eine Form, um Anforderungen festzuhalten. Dabei werden die Anforderungen nach einer Schablone formuliert.

Definition of Done (DoD)

In der Definition wird festgehalten, welche generellen Voraussetzungen beim Review Meeting erfüllt sein müssen, damit die Funktionalität vom Product Owner abgenommen wird.

Rollen AG AnwV Arch BetrV Entw ISDNSV PA PL PO QM QV SM ST Team Tst

Auftraggeber Anwendervertreter Architekt Betriebsverantwortlicher Entwickler ISDN-Verantwortlicher Projektausschuss Projektleiter Product Owner Qualitätsmanager Qualitätsverantwortlicher Scrum Master Scrum Team Tester

Leitfaden Agiles HERMES · Matthias Roth leitet die Java-Abteilung der Born Informatik. ......

Documents

Transcript of Leitfaden Agiles HERMES · Matthias Roth leitet die Java-Abteilung der Born Informatik. ......