<< Zurück

Der Agile Practice Guide.

Editorial
Der Agile Practice Guide.

Zwar ist das Thema Agile nun im aktuellsten PMBoK Guide umfangreich enthalten – zur Vertiefung gibt es aber einen eigenen Practice Guide. Schauen wir kurz hinein.

  • Agile Manifesto, Principles & Mindset.  Gleich in der Einleitung wird klargestellt, wo die agile Denke eigentlich herkommt – und wo sie hinführen soll. Es wird kein Hehl daraus gemacht, dass das Thema im IT-Development daheim ist – wenn auch die eine oder andere Methode auch bei anderen Entwicklungsprojekten verwendet wird. Natürlich muss man die Kirche im Dorf lassen: Einiges gibt es schon lange und wurde halt mit dem Titel „Agile“ in neue Kleider gesteckt.
  • Agile = Blanket Term. Es beschreibt nicht „eine“ Methode, sondern viele verschiedene, die zusammengefasst tatsächlich als „Lean (Management/SW-Development) Methods“ verstanden werden. Konkret genannt werden Kanban (übrigens nicht den agilen Entwicklungsmethoden im engeren Sinn zugeordnet), ScrumBan, Scrum, Crystal, Extreme Programming (XP), Feature Driven Development (FDD), Agile Unified Process (AUP) und die Dynamic Systems Development Method (DSDM).
  • Unsicherheit: Es wird beschrieben, in welchen Dimensionen sich Unsicherheit bei der Entwicklung bewegt. Nämlich einerseits im Bereich der Anforderung (Wie klar und konkret sind die Anforderungen?) und andererseits im Bereich der Lösung (Wie genau weiß ich, was ich entwickeln werde – und überhaupt entwickeln kann?).
  • Auswahl des Development Life Cycles. Für die konkrete Hautaufgabe der Entwicklung werden die unterschiedlichen Lebenszyklen beschrieben – inkl. die agilen. Es gibt auch spezielle Hinweise zur Kombination von Vorgehensweisen – also zB Entwicklungen, die agil starten und zu einem bestimmten Zeitpunkt vorhersagend (sequentiell und endgültig) werden.
  • Servant Leadership: Die Besonderheiten in agilen Umgebungen was „Führung“ betrifft – und in erster Linie das „Befähigen“ der Leute, so zu arbeiten, wie es für sie am besten und effektivsten ist – stehen in diesem Kapitel.
  • Agile Teams: Es wird beschrieben, was bei agilen Teams zu beachten ist – u.a. welche Rollen es gibt, welche Attribute auf diese zutreffen und welches Ziel man damit jeweils verfolgt.
  • „Liefern“.  Agile Methoden haben mit Entwickeln und Liefern zu tun. In diesem Zusammenhang ist die Rede von der Project Charter, regelmäßigen Retrospektiven, dem Umgang und der (Weiter-) Entwicklung des Backlogs, täglichen Standups, Demos und Reviews, der spezifischen Planung und dem Steuern von Iterationen sowie ausführenden Aktivitäten (u.a. Testen und Abnahme).
  • Troubleshooting: Agile Methoden bringen Schwierigkeiten mit sich. Wie man damit umgehen kann, wird hier beschrieben.
  • Diverse Charts.  Also zB das Burndown/-up oder Feature Chart sind enthalten.
  • Kanban: Diese Methode, wenn auch nicht direkt dem agilen Development zugeordnet, wird kurz beschrieben.
  • Earned Value und Cumulative Flow: Dem Thema „Wie viel habe ich schon gebaut“ vs. „Wie viel fehlt noch“ kommt bei agiler Entwicklung im Sinne einer Fortschrittsbetrachtung eine besondere Bedeutung zu.
  • Change Management: Dieses Thema wird aus zwei Dimensionen beleuchtet. Einerseits gibt es den Change im Zuge einer konkreten agilen Entwicklung – bedeutet: Leute müssen mit einer anderen Art des „Ergebnisse-Erzeugens und -Abnehmens“ umgehen. Da liegt die Challenge beim Projektleiter. Und dann gibt es den Change in der Organisation an sich, der mit der Einführung von agilen Methoden einher geht. Hier ist zB das PMO gefragt.
  • Agile Development „einführen“.  Als Faktoren sind hier das Thema „Sicherheit“ genannt – also dass die Einführung von agilen Methoden ein „Umfeld der Sicherheit“ verlangt. Es geht außerdem um den kulturellen Fit: Wie sieht die Bereichs- oder Unternehmenskultur aus – und wie passt Agilität hinein? Was bedeutet agile Entwicklung in Bezug auf Beschaffung und Verträge? (egal ob man einkauft oder Dienstleister ist) Und was bedeutet agile Entwicklung in einem Projekt, Programm oder Portfolio?
  • Das agile PMO: Hier ist u.a. die Rede davon, dass ein agiles PMO auf den jeweiligen Mehrwert für die Entwickung achtet, nur auf Einladung in die Entwicklung im Projekt „hineingreift“ und auf jeden Fall multi-disziplinär denkt und tickt. Da ein PMO in erster Linie das Projekt als Ganzes sieht, und nicht unbedingt auf den Teilbereich des Developments schaut, hat es hier logischerweise wenn dann eher eine unterstützende Funktion.
  • Mapping von Prozessen   zu agilen Methoden: Es gibt eine Zuordnung zwischen den Prozessen des PMBoK und dazupassenden agilen Methoden.
  • In a nutshell.  Alle genannten agilen Methoden werden konkret und in aller Kürze vorgestellt.
  • Tailoring: Hier wird beschrieben, in welcher Situation man wie die jeweilige (agile) Vorgehensweise am effektivsten einsetzen könnte.
  • Wie agil sollte man sein?  Ein eigenes Tool hilft dabei, zu prüfen, inwiefern die Organisation und Struktur überhaupt für den Einsatz agiler Entwicklungsmethoden geeignet sind. Dabei werden die Dimensionen „Projekt“ (Wie viel Veränderung erwarte ich? Wie kritisch ist es? Wie möchte ich entwickeln?), „Kultur“ (Unterstützung, Vertrauen und Entscheidungsfähigkeit) und „Team“ (Teamgröße, Erfahrung und Zugriffsmöglichkeit) betrachtet.
Die Inhalte in den Dokumenten wie u.a. dem PMBoK Guide oder Agile Practice Guide beschreiben die aktuelle Best Practice im jeweiligen Thema. Sie stammen aus der PMI-Community als weltgrößter PM-Community – die sich beim Thema Agile mit der   Community der Agile Alliance   ( Link)   zusammengeschlossen hat.  Die Inhalte werden ständig weiterentwickelt – melde dich bei uns, wenn du hier mit dabei sein möchtest. (Autor: Daniel Hendling, President PMI Austria Chapter)

Suche

Archiv

Thank you for completing our survey!

Click below to view Eric's presentation and other items related to Office 365 and Project Online!

Presentation