APM - Agiles Projektmanagement

Anspruchsvolle Softwareprojekte erfolgreich steuern

Uwe Vigenschow

• Verlag: dpunkt
• Jahr: 2015
• ISBN:
  9783864916328
• Thema: Informatik
• Thema: Projektmanagement

APM steht für Agiles Projektmanagement und ist eine Methodik für die konsequente und praxisnahe Umsetzung agiler Projekte im Kontext anspruchsvoller Softwareprojekte. Der Leser erfährt in diesem Buch, wie er von der Projektvorbereitung und dem Requirements Engineering bis hin zu einer durchgängigen Softwarearchitektur agil entwickeln kann. Dabei wird auch auf das skalierbare und flexible APM-Rollenmodell eingegangen, um unterschiedlich große Projekte unter verschiedenen Rahmenbedingungen adressieren zu können.Das Buch gliedert sich in fünf Teile: - Teil I erläutert die Konzepte hinter dem Begriff Agilität und gibt einen Überblick über APM.- Teil II behandelt das Aufsetzen eines agilen Projekts.- Teil III legt dar, wie Softwarearchitektur und APM zusammenspielen.- Teil IV beschreibt detailliert die Struktur und Dynamik innerhalb von Iterationen sowie die fortlaufende Backlog-Arbeit hin zu hochwertigen Releases. Dabei wird auch auf Projektcontrolling sowie Kanban und Lean Management eingegangen.- Teil V zeigt, wie Sie APM für große Projekte skalieren und in verteilten Teams anwenden können. Erörtert werden auch die Besonderheiten im regulierten Umfeld und wie Agilität im Unternehmen eingeführt wird.APM stellt somit einen gut gefüllten Werkzeugkasten für viele unterschiedliche Situationen in agilen Projekten dar. Dem Buch liegt das zweiseitige Poster "Product-Owner-Werkzeugkoffer" und "Anforderungen agil zerlegen" bei.

Teil IV
Konstruktion und Releases

14 Struktur und Dynamik einer Iteration 199

Die innere Struktur einer Iteration in APM wird mit den dazugehörigen Aktivitäten beschrieben. Die Planung einer Iteration wird ebenso detailliert dargestellt wie der Entwicklungsmikroprozess und die testgetriebene Entwicklung. Abschließend wird die Durchführung von Retrospektiven am Ende jeder Iteration und ihr Wert für die kontinuierliche Prozessverbesserung skizziert.

15 Fortlaufende Backlog-Arbeit 219

Das zentrale Konzept der Timbox wird beschrieben. Wir gehen auf die fortlaufende und hierarchische Zerlegung vom Epos bis zur verfeinerten einzelnen User Story über eine Reihe von praktischen Splitting Patterns ein. Des Weiteren werden die Themen Refactoring und Planungsreserven abschließend betrachtet.

16 Regelmäßige hochwertige Releases 257

Das Schneiden von Releases sowie die Unterscheidung zwischen internen und externen Releases und deren Planung werden genau betrachtet. In diesem Zusammenhang gehen wir auch auf Aspekte der Qualität ein.

17 Projektcontrolling und -steuerung 275

Das auf der Velocity basierende agile Projektcontrolling wird mit seinen Visualisierungen beschrieben. Dabei geht es um die Steuerung des Projekts sowie der Aktivitäten innerhalb einer Iteration. Agile Metriken und ihr Nutzen bei der Selbststeuerung der Teams werden erläutert.

18 Kanban und Lean Management 313

Kanban und Lean Management als eine der Säulen von APM werden in diesem Kapitel genauer beschrieben. Diese Werkzeuge helfen besonders bei der Ergebnisorientierung und der Früherkennung von Trends in der Projektumsetzung.

19 Der agile Coach im täglichen Einsatz 333

Die vielfältigen und zahlreichen Aufgaben eines agilen Coaches werden beleuchtet und das Konzept der adaptiven und dienenden Führung erläutert. Dazu kommt ein abschließender Blick auf die agilen Werte und wie sie zum Leben erweckt werden.

14 Struktur und Dynamik einer Iteration

In der Konstruktionsphase sind wir im Projektverlauf nun dort angelangt, wo Agilität vollends ihre Stärke zeigt. In dieser längsten Phase eines Projekts laufen die Iterationen nach einem festen Schema ab und wir erstellen eine Abfolge nutzbarer Releases.

14.1 Schema einer Iteration

In Abbildung 14-1 ist das Schema einer Iteration für ein Featureteam eines mittleren Projekts dargestellt. Unser Beispiel umfasst mit vier Wochen eine Dauer am oberen Ende der sinnvollen Möglichkeiten. Welche Anpassungen für große Projekte vorzunehmen sind, betrachten wir in Kapitel 20.

Abbildung 14-1: Schema einer Iteration von vier Wochen

Ein Iteration dauert, wie in Abbildung 14-1 dargestellt, eine exakte Anzahl von Wochen. Es ist natürlich auch eine feste Anzahl von Tagen denkbar, jedoch in den allermeisten Fälle aus organisatorischen Gründen ungünstig. Obwohl eine Iteration zwei, drei oder vier Wochen dauert, ist es meist praktischer, sie nicht am Wochenbeginn zu starten, sondern in der Mitte der Woche. So liegen alle wichtigen Meetings zwischen Dienstag und Donnerstag, also an den Wochentagen, an denen wir die höchste Wahrscheinlichkeit haben, dass alle relevanten Personen auch anwesend sein können.

Tests und Vorabnahmen finden so weit wie möglich bereits parallel zur Entwicklung statt. In Abbildung 14-1 ist das durch die kleinen Lupen in der unteren Hälfte angedeutet. Diese Prüfungen finden bei Bedarf statt und werden meist nicht explizit eingeplant.

14.1.1 Eine Iteration beginnen

Eine Iteration beginnt mit einem gemeinsamen Kick-off der Featureteams, dem direkt die Iterationsplanung der jeweiligen Featureteams folgt (Abb. 14-1, links). Sie besteht, wie in Abschnitt 5.4.1 beschrieben, aus drei Teilen:

• Lookahead
• Planung I
• Planung II

Die Iterationsplanung muss dafür vom Teamprojektleiter in Abstimmung mit dem Team, den anderen Teamprojektleitern, dem Projektleiter und anderen Stakeholdern vorher vorbereitet werden. Dazu finden zum Ende einer Iteration oder für die erste Iteration am Ende der Vorbereitung Treffen statt, in denen basierend auf dem letzten Lookahead die Einträge im Backlog für das Produkt bezüglich Reihenfolge, Inhalt und sinnvoller weiterer Zerlegungen bearbeitet werden (»Backlog Pflege und Verfeinerung«, in Abbildung 14-1 oben rechts). Die agilen Coaches bereiten den Kick-off vor und moderieren ihn. Danach moderiert jeder agile Coach den Planungsworkshop seines Teams.

14.1.2 Die inhaltliche Arbeit

An die Planung schließt sich direkt die inhaltliche Arbeit an. Die Basis dafür bilden die vom Teamprojektleiter geordneten Aufgaben und die von den Entwicklern daraus abgeleiteten Tasks auf dem Taskboard. Der Teamprojektleiter verbringt an jedem Tag ein paar Stunden seiner Zeit beim Team, um weitere Aufgabenklärungen vorzunehmen, erste Ergebnisse zu begutachten, Prioritäten zu setzen und das Team fachlich zu unterstützen.

Das Entwicklungsteam trifft sich jeden Tag um die gleiche Zeit zu einem kurzen Standup-Meeting, um sich abzustimmen und zu koordinieren. Der agile Coach moderiert das Meeting. Der Teamprojektleiter darf als Gast zuhören, jedoch dient dieses Meeting primär den Entwicklern und nicht der Information des Teamprojektleiters. Bevor das Standup-Meeting beginnt, wurden spätestens die Karten auf dem Taskboard aktualisiert, sodass das Taskboard zu diesem Meeting stets aktuell ist.

Dieser Teil der Iteration ist bei Weitem der längste und umfangreichste (Abb. 14-1, Mitte). Der Teamprojektleiter unterstützt und begleitet sein Team die ganze Zeit lang. Jedoch nutzt er etwa die Hälfte bis 2/3 seiner Zeit, um das Projekt inhaltlich weiter voranzubringen. Dazu trifft er sich mit anderen Stakeholdern wie fachlichen Vertretern usw. Die Ergebnisse dieser Meetings dokumentiert er im Backlog und ggf. in weiteren Modellen oder Dokumenten, auf die in den Backlog-Einträgen verwiesen wird.

Zum Ende der Iteration bereitet er den nächsten Planungsworkshop und Kick-off inhaltlich vor, mit dem die nächste Iteration beginnt (»Backlog Pflege und Verfeinerung«, in Abbilung 14-1 oben rechts). Dazu holt er sich punktuell Unterstützung aus dem Entwicklungsteam, um wichtige Themen vorab gemeinsam zu durchdenken und zu zerlegen. Außerdem stimmt er sich an diesen Tagen mit seinen Teamprojektleiterkollegen und dem Projektleiter über die Inhalte und ihre Prioritäten ab, sodass keine wichtige Arbeit vergessen wird und keine versehentlichen Aufgabendopplungen entstehen.

Von besonderer Bedeutung ist, dass der Teamprojektleiter gemeinsam mit seinen Kollegen und dem Projektleiter dafür sorgt, dass es keine äußeren Störungen für das Team in der laufenden Iteration gibt. Für Änderungen an den Anforderungen gibt es ein definiertes Vorgehen und für den Abbruch einer Iteration, eines Releases oder des Projekts ebenfalls. Wir kommen in Abschnitt 17.7 darauf zurück. Weitere Verfeinerungen und Klärungen erfolgen in der laufenden Iteration in den Gesprächen der Entwickler mit dem Teamprojektleiter und ggf. mit fachlichen Stakeholdern. Das geschieht aber alles im Rahmen des geplanten Vorgehens für die laufende Iteration. Wenn eine Anforderung noch zu instabil ist, bleibt sie im Backlog und kommt nicht auf das Taskboard.

Der agile Coach unterstützt in der Zeit das Team und hierbei insbesondere einzelne Teammitglieder, die auf Schwierigkeiten stoßen. Dies macht er nicht technisch, sondern auf der Ebene der Zusammenarbeit und Arbeitsabläufe. Der agile Coach versucht also die Abläufe weiter im Sinne der agilen Werte zu verbessern und die Zusammenarbeit zu optimieren. Er sorgt auch für die regelmäßige Aktualisierung der Information Radiators und ermittelt statistische Werte wie die Velocity für das Projektcontrolling.

14.1.3 Vorabnahmen und Tests

Parallel zur laufenden inhaltlichen Arbeit erfolgen die Vorabnahmen und Tests der bereits fertiggestellten Tasks und Aufgaben. Die integrierten automatisierten Tests geben dabei den Entwicklern eine erste, direkte Rückmeldung zu möglichen Seiteneffekten ihrer Arbeit. Durch Pair Programming bei besonders wichtigen, schwierigen Tasks und gegenseitige, formlose Peer-Reviews der Softwareentwickler untereinander findet eine laufende interne erste Qualitätskontrolle der Projektarbeit statt.

Der Tester prüft abgeschlossene Aufgaben über die Akzeptanzkriterien und betrachtet das fachliche Zusammenspiel der umgesetzten User Stories. Nach diesem Prüfschritt kommt es zusätzlich zu Vorabnahmen der umgesetzten Aufgaben durch den Teamprojektleiter und ggf. zusätzliche fachliche Stakeholder. Dies ist insofern wichtig, als dass zum Ergebnisreview nur bereits als fertig erkannte Teile in das zu demonstrierende Inkrement aufgenommen werden.

14.1.4 Taskboard-Pflege und Verfeinerung

Die Iterationsplanung zu Beginn einer Iteration ist ein Meeting mit einer Timebox. Es kann daher sein, dass nicht alle Tasks in der notwendigen Weise heruntergebrochen sind. Da in der Planung streng priorisiert vorgegangen wird, betrifft dieses Manko erst Tätigkeiten, die zum Ende der Iteration relevant werden.

Dazu kommt, dass es bei längeren Iterationen von drei bis vier Wochen auch nicht sinnvoll sein kann, alle Tasks bereits komplett vorab zu definieren. Abhängigkeiten zwischen den Tasks und die Auswirkungen von Risiken können z. B. gar nicht vorab genau vorgedacht werden bzw. wir möchten diese Zeit nicht in der Planung investieren. Erst die Umsetzung der ersten Tasks wird uns die notwendige Klarheit dafür geben.

Damit das Entwicklungsteam aber auch im letzten Drittel einer Iteration kontinuierlich arbeiten kann, ergänzen und verfeinern wir diese Tasks in einem Meeting von ein bis zwei Stunden, der Taskboard-Pflege und Verfeinerung. Es handelt sich dabei um die Fortsetzung des Planung-II-Meetings vom Beginn der Iteration zu dem Zeitpunkt, wo es notwendig wird und wir ausreichend Neues gelernt haben, um die Tasks sinnvoll erstellen zu können. Meist liegt dieser Zeitpunkt zwischen der Hälfte und 2/3 Dritteln der Iterationsdauer. Dieses Meeting wird also bei Bedarf durchgeführt. Sowohl das Entwicklungsteam als auch der agile Coach sowie der Teamprojektleiter haben ein Auge darauf zu richten, ob und wann eine Taskboard-Pflege und Verfeinerung notwendig wird.

14.1.5 Ergebnisreview

Das Ergebnisreview (Abb. 14-1, rechts) wird entsprechend seiner Bedeutung als offizielle Vorstellung und Demonstration der in der Iteration erreichten Ergebnisse vorbereitet. Die dafür notwendigen Rechner und zusätzliche Infrastruktur wie Beamer, Flipcharts und aktualisierte Information Radiators sind vorzubereiten und der Raum entsprechend herzurichten. Die Teilnehmer werden vorab dazu eingeladen. Dabei sind eher mehr als zu wenige Stakeholder zu berücksichtigen, um ein möglichst breites Feedback zu erhalten.

Der Charakter des Ergebnisreviews ist eher der einer Demonstration der Software denn der eines harten Reviews. Die neuen Features werden gezeigt und die Teilnehmer werden um Feedback gebeten. Dabei sollte es nur wenige Überraschungen geben, da die Vorabnahmen bereits weitestgehend erfolgt sind. Dennoch sind die Rückmeldungen und Anmerkungen der Stakeholder von besonderer Bedeutung. Zum einen nimmt eine Reihe von Managern und Führungskräften daran teil, die in der Regel nicht an den Vorabnahmen beteiligt sind. Zum anderen können die gezeigten Ergebnisse in einen größeren Kontext gebracht werden und dadurch von den kundenseitigen Entscheidern wertvolle Aussagen zu den fachlichen Prioritäten und Bedürfnissen gemacht werden. Letztere Informationen sin...

Inhaltsverzeichnis

• Cover
• Autoren
• Titel
• Impressum
• Vorwort
• Aufbau und Überblick
• Inhaltsverzeichnis
• Teil I Agilität und APM-Einführung
• Teil II Das Projekt aufsetzen
• Teil III Agile Architektur
• Teil IV Konstruktion und Releases
• Teil V Agile Großprojekte
• Abschlussbemerkung und Literaturtipps
• Referenzen und weiterführende Literatur
• Index
• Fußnoten
• oose Poster