Samstag, 1. Februar 2020

Agile Arbeitsweisen


Im Februar 2001 entwickelt eine Gruppe um Kent Beck, Mike Beedle, Martin Fowler, Ken Schwaber und Jeff Sutherland das „Agile Manifest“ um neue Arten des Projektmanagements, nach denen sie arbeiten, zu beschreiben.

Das agile Manifest lautet wie folgt:
Wir erschließen 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 ihre Interaktionen stehen über Prozessen und Werkzeugen.
Funktionierende Software steht über einer umfassenden Dokumentation.
Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung.
Reagieren auf Veränderung steht über dem Befolgen eines Plans.
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Die später im Jahr gegründete Agile Alliance leitet daraus die 12 agilen Prinzipien ab.

Im Fokus agiler Arbeitsweisen stehen Kundenzentriertheit, Veränderungbereitschaft in Bezug auf Projektinhalt und Arbeitsweise und hochgradig eigenverantwortliche Teams. Die Aufgabe des Managements besteht in der Unterstützung beim Finden von Lösungen und dem Bereitstellen der benötigten Mittel, nicht in der Zuweisung von Aufgaben. Die unterschiedlichen agilen Vorgehensweisen sind Frameworks, an denen sich das Team orientiert um seine eigene, auf Projekt und Team angepasste Methode zu entwickeln.
Die adaptive agile Vorgehensweise ist gut geeignet für Projekte mit vielen für den Kunden sichtbaren Schnittstellen und einfacher Hintergrundverarbeitung, oder bei komplexen Problemen, bei denen viel unvorhergesehenes passieren kann. Die starren, von Beginn an durchgeplanten klassischen Projektvorgehensweisen eignen sich dagegen gut für Projekte mit einem komplizierten Rechenkern oder einer nicht in Einzellieferungen aufteilbaren Funktionalität.

Die bekanntesten agilen Frameworks sind

  • Scrum als Framework für das allgemeine Projektmanagement, insbesondere die Software-entwicklung
  • Kanban (als eine Technik der Lean Methoden) mit dem Schwerpunkt der Visualisierung im Kanban Board und der Optimierung des Workflowmanagements zur Sicherstellung eines kontinuierlichen Arbeitsflusses durch Limitierung der Work in Progress (WIP)
  • Extreme Programming (XP), das als einziges agiles Framework auch konkrete Methoden zur Softwareentwicklung vorgibt, wie Pair Programming durch die gemeinsame Arbeit von zwei Entwicklern an einem Computer oder das Test-First Programming, bei dem zuerst der automatisierte Test für die gewünschte Funktionalität geschrieben wird.

Und eingeschränkt auch 

  • DevOps mit der Zusammenbringung von Entwicklung und Betrieb und der Automatisierung des Workflows von der Entwicklung bis zum Kunden
  • Design Thinking als nutzerorientierter Innovationsansatz für komplexe Probleme und Herausforderungen.

Allen Frameworks gemeinsam sind die Konzepte der 
User Stories als eine einfache Beschreibung einer Produktanforderung hinsichtlich dessen, was diese Anforderung für wen erreichen soll. Komplexere Anforderungen werden Epics genannt. Sie werden im Projektverlauf in Features und diese dann in User Stories heruntergebrochen. 
Daily Meeting: ein kurzes tägliches Team-Event, bei dem jeder beschreibt, was sein aktueller Status ist. 
Inkrementelle Entwicklung: Entwicklung kleiner potenziell einsetzbarer Softwareteile mit für den Kunden sichtbaren Funktionen. 
Iterative Entwicklung: wiederholende Arbeiten am selben Objekt, durch Prototyping, Refactoring oder inkrementelle Weiterentwicklung. 
Team: ein kleines, eigenverantwortliches Team, das ausschließlich diesem Projekt zugeordnet ist. 
Retrospektive: regelmäßige Überprüfung und Anpassung der Methodik durch das ganze Team mit dem Ziel der stetigen Verbesserung. 
Personas: Falls im Projekt erforderlich, werden fiktive Nutzer mit eigenen Biographien und individuellen Eigenschaften kreiert um Nutzergruppen darzustellen.

Scrum ist das bekannteste und am weitesten verbreitete agile Framework. Es besteht aus 3 gleichberechtigten Rollen, 3 Artefakten und 5 Aktivitäten.

Der Product Owner repräsentiert die geschäftlichen Interessen des Projekts. Er verwaltet das Product Backlog und nimmt fertiggestellte Arbeit ab. Das Entwicklungsteam ist selbstorganisierend, nur einem Projekt zugeordnet und idealerweise an einem Standort angesiedelt. Der Scrum Master unterstützt das Team bei der Verbesserung des Arbeitsumfeldes.

Im Product Backlog wird die vollständige Liste der Anforderungen gepflegt, aus denen für den jeweiligen Sprint eine Auswahl für das Sprint Backlog getroffen wird. Das Produktinkrement ist dann die einsatzfähige, potenziell auslieferfähige Funktionalität.

Zu Beginn der Sprint genannten, maximal monatlichen Entwicklungszyklen werden im Sprint Planning die Ziele für diesen Zyklus definiert. Während des täglichen 15-minütigen Daily Scrums berichtet jeder über seinen aktuellen Status. Im Sprint Review wird das fertige Produktinkrement den Stakeholdern vorgeführt, während in der Sprint Retrospektive das Scrum Team mögliche Prozessverbesserungen bespricht.


Zu Beginn eines agilen Projektes definiert der Product Owner in einem Product Vision Statement das Ziel des Projektes. In der Definition of Done legt das Scrum Team fest, wann etwas als fertig und potenziell auslieferbar angesehen wird. Der Aufwand für User Stories wird vom Scrum Team in (willkürlich festgelegten) Story Points gemessen. Die durchschnittliche Anzahl an Story Points, die das Team in einem Sprint umsetzt, ist die Velocity des Teams. Im Burndown Diagramm werden die geschätzten Story Points für einen Sprint eingetragen und die für fertiggestellte Arbeiten geschätzten Story Points entfernt um so den Fortschritt zu visualisieren.

Um in größeren Projekten agil zu arbeiten müssen die agilen Methoden so skaliert werden, dass Veränderungsbereitschaft und direkte, schnelle Kommunikation erhalten bleiben. Dafür gibt es unterschiedliche Frameworks, wie Scrum of Scrums, Scrum at Scale, Large Scale Scrum (LeSS), Nexus, Scaled Agile Framework (SAFe) oder Enterprise Scrum (ES) oder auch das Spotify Modell.
Auch bei der Skalierung entwickeln Organisationen aus den verschiedenen Frameworks meist ihre eigene Skalierungsmethode.







Keine Kommentare:

Kommentar veröffentlichen

Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.