HERMES 5 trifft Kanban

Die Kombination von HERMES 5 und agilen Vorgehensweisen in der Softwareentwicklung der Bundesverwaltung ist heute allgegenwärtig und verspricht viele Vorteile. Dieses Zusammenspiel vereint verschiedene Organisationseinheiten (Fachabteilung und Softwareentwicklung) bei der Abwicklung eines Projektes. Dabei treffen unterschiedliche Herangehensweisen auf diverse Denkweisen und Kulturen, die es durch die Förderung von gegenseitigem Verständnis und offener Zusammenarbeit zu überbrücken gilt.

Der vorliegende Artikel zeigt anhand eines konkreten Projektes, wie die Vereinbarkeit gelingen kann. Dabei agiert die Rolle des agilen Requirements Engineerings (Business Analyse) und des Testmanagements als Verbindungsbrücke zwischen HERMES 5 und der agilen Softwareentwicklung.

In der Bundesverwaltung wird eine neue E-Government Applikation entwickelt. Das Projekt wird nach der klassischen Projektmanagementmethode HERMES 5 abgewickelt, wobei die Entwicklung durch den Leistungserbringer nach der agilen Vorgehensweise Kanban erfolgt.

Abbildung 1: Das eingesetzte Zusammenspiel der Projektmanagementmethode HERMES und der agilen Entwicklung nach Kanban.

Das Phasenmodell nach HERMES (4 Projektphasen: Initialisierung, Konzept, Realisierung und Einführung) dient dabei als übergeordneter Rahmen. Darin wird die agile Entwicklung nach Kanban verordnet, welche bereits in der Konzeptphase beginnt und sich über die Realisierungsphase hinaus bis in die Einführungsphase erstreckt. Die agile Softwareentwicklung wird bereits in der Projektphase Konzept eingeführt, da die Anforderungen zunächst nur grob beschrieben und erst bei Bedarf weiter spezifiziert werden (Just-in-Time Spezifikation).

Während der agilen Entwicklung mit Kanban dient das Kanban-Board mit seinen sieben Feldern als Statusübersicht für die Bearbeitung der Anforderungen. Die priorisierten User Stories (Anforderungen) werden dabei durch den Product Owner aus dem Product Backlog in die «INBOX», das erste Feld des Kanban Boards, platziert.

Die Grobanforderungen wurden initial erhoben und werden im Laufe des Projektes iterativ festgelegt respektive ausspezifiziert. Von der «INBOX» werden die User Stories nach dem Pull-Prinzip weiterbearbeitet und durchlaufen dabei jedes Feld des Kanban-Boards von links nach rechts. Das Pull-Prinzip steht in diesem Kontext für die reibungslose Weiterarbeit im Durchlauf des Kanban-Boards, bei ausreichend verfügbaren Kapazitäten (Selbstorganisation des Teams).

Wenn die User Story sich im Feld «DESIGN» befindet, werden die Akzeptanzkriterien sowie die Testfälle der User Story definiert. Zusätzlich kann die Anforderung bei Bedarf weiter spezifiziert werden.

Anschliessend wandert die Anforderung weiter in das Feld «READY FOR DEVELOPMENT», wo sie darauf wartet, von Entwickelnden umgesetzt zu werden. Die eigentliche Entwicklung erfolgt im Feld «IN PROGRESS». Weiter wird die umgesetzte Anforderung sowohl fachlich als auch technisch im Feld «IN TESTING» auf ihre korrekte Umsetzung und Erfüllung der Akzeptanzkriterien untersucht.

Schliesslich wird die Anforderung im Feld «REVIEW» durch den Product Owner abgenommen, bevor die User Story auf «DONE» gesetzt werden kann, oder bei Nichterfüllung zurück in das Product Backlog/die «INBOX» gesetzt wird.

Die umgesetzten User Stories werden finalerweise gesammelt und periodisch durch verschiedene Stakeholder (z.B. User und Fachvertreter) getestet.

In unserem Beispielprojekt werden sowohl der Product Owner als auch die Business Analysten durch den Leistungsbezüger für die Produktrealisierung beim Leistungserbringer eingesetzt. Dies ermöglicht eine enge Zusammenarbeit und fördert eine nutzerorientierte Entwicklung.

Die Vertreter der unterschiedlichen Anspruchsgruppen stammen aus eigenständigen Organisationseinheiten und sind nicht unbedingt mit den agilen Vorgehensweisen vertraut. Hier treffen also verschiedene Menschen und Teams, mit allenfalls sehr unterschiedlichen Arbeitsweisen, Vorstellungen und Werten, aufeinander.

Damit die Zusammenarbeit gelingen und der zielgerichtete Austausch stattfinden kann, ist es wichtig, das gegenseitige Verständnis zu fördern. Dies gilt sowohl in Bezug auf das methodische Vorgehen als auch für die gemeinsame Arbeitsweise und multiple Vorstellungen. Zum Beispiel kann eine kurze Präsentation des Projektvorgehens und der eingesetzten Vorgehensweisen zuhanden der Stakeholder erstellt werden.

Im Projektteam können somit gemeinsam Werte oder Arbeitsgrundsätze definiert (und gelebt) werden. Insbesondere bieten aber das agile Requirements Engineering und Testing eine wichtige Gelegenheit, um den Austausch zwischen den beteiligten Protagonisten im Projekt zu fördern und die Sichtweise des Teams mit den Vorstellungen der unterschiedlichen Stakeholder in Einklang zu bringen.

Gelingt die Überwindung dieser Hindernisse, so ermöglicht die Kombination von HERMES mit agilen Methoden eine hohe Flexibilität und zudem eine tiefe Time-to-Market.

In unserem Beispielprojekt beträgt die Zeitdauer von der Aufnahme einer neuen Anforderung bis zur Umsetzung gerade einmal zwei Wochen. Gleichzeitig fördert der frühe und regelmässige Einbezug der Stakeholder die Nutzerorientierung des Produktes sowie die Akzeptanz der User. Des Weiteren sind alle zwei Wochen exakte Statusberichte vorhanden, welche sowohl zur Fortschrittsmessung als auch für die Weiterentwicklung und Verbesserung der Zusammenarbeit im Team verwendet werden können.

Möchten Sie mehr über dieses spannende Thema erfahren oder wissen, wie die APP auch Sie bei einem herausfordernden Vorhaben unterstützen kann? Wir freuen uns auf Ihre Kontaktaufnahme.