Agiles Projektmanagement

Mit agilem Projektmanagement in der Softwareentwicklung sollen die bisher vorhandenen, sehr bürokratisch gehaltenen Prozesse abgebaut, und durch stärkere Berücksichtigung menschlicher Aspekte effektiver gestaltet werden. Die reine Entwurfsphase soll auf ein Mindestmaß reduziert, und im Entwicklungsprozess so früh wie möglich zu ausführbarer Software gelangt werden. Diese kann dem Kunden somit in kurzen Abständen zur gemeinsamen Abstimmung vorgelegt werden. Hierbei soll flexibler auf den Kunden und dessen Wünsche eingegangen, und somit die Kundenzufriedenheit erhöht werden. Hierfür gibt es unter anderen ein spezielles Vorgehensmodell: Das sogenannte Scrum.

Bei dieser Methode organisieren die Teammitglieder ihre Arbeit weitestgehend selbst und wählen auch die eingesetzten Software-Entwicklungswerkzeuge und -Methoden. Jedoch gibt es drei klar getrennte Rollen, die von Mitarbeitern ausgefüllt werden, die im selben Projekt zusammenarbeiten. Hierbei werden die Zuständigkeiten so aufgeteilt, dass jeder für das zuständig und verantwortlich ist, was er zu leisten imstande ist.

Die 3 Rollen in Scrum:

Product Owner: Stellt fachliche Anforderungen und priorisiert diese
ScrumMaster: Managt den Prozess und beseitigt Hindernisse
Team: Entwickelt das Produkt

Zusätzlich können noch Stakeholder eingesetzt werden. Diese agieren als Ratgeber und Beobachter.

Die Anforderungen (Requirements) für das jeweilige Projekt werden in einer Liste (Product Backlog) gepflegt, erweitert und priorisiert. Das Product Backlog ist ständig im Fluss. Monatlich wird in Kooperation mit dem Produkt Owner ein definiertes Arbeitspaket aus dem Produkt Backlog entnommen und komplett in Funktionalität umgesetzt. Dies beinhaltet auch Tests und notwendige Dokumentationen. Wichtig hierbei ist, dass das Arbeitspaket stets dem oberen, höheren priorisierten Ende des Produkt Backlogs entnommen werden muss. Besonders muss darauf geachtet werden, dass das definierte Arbeitspaket während der laufenden Iteration (Sprint), nicht durch Zusatzanforderungen modifiziert wird. Somit wird eine Fertigstellung des Arbeitspaketes nicht gefährdet. Die restlichen Teile des Product Backlogs können als Vorbereitung für nachfolgende Sprints vom Product Owner verändert bzw. neu priorisiert werden.

Jedes Arbeitspaket wird in kleinere Arbeitspakete (Tasks) heruntergebrochen. Diese werden mit dem jeweils zuständigen Bearbeiter in einer weiteren Liste, dem Sprint Backlog, festgehalten. Um einen vollständigen und potenziell produktiven Anwendungsteil umzusetzen, sollte das Team während des Sprints, die Tasks aus dem Sprint Backlog konzentriert und ohne Störung von außen bearbeiten. Um einen täglichen Informationsaustausch zu gewähren, sollte dafür ein streng auf 15 Minuten begrenztes Informations-Meeting (Daily Scrum Meeting) abgehalten werden. Somit weiß jeder, woran der andere zuletzt gearbeitet hat, was er als Nächstes vorhat, und welche Probleme es eventuell gibt.

Am Ende des Sprints wird dem Product Owner in einem Sprint Review Meeting die bisher implementierten Funktionalitäten präsentiert. Neue Anforderungen vom Product Owner, und das Feedback der Stakeholder, fließt in das nächste Sprint Planning Meeting ein, und der Prozess beginnt von Neuem.

Für die Einhaltung der Regeln ist während des gesamten Prozesses der ScrumMaster zuständig. Er sorgt auch dafür, dass der Status aller Tasks im Sprint Backlog von den jeweils zuständigen Team-Mitgliedern täglich aktualisiert wird. Durch zusätzliche Burndown Charts wird der Fortschritt für die aktuellen Sprints mittels einer Kurve visualisiert. Durch eingezeichnete Trendlinien können mögliche Probleme und Verzögerungen frühzeitig erkannt werden.

Scrum basiert demnach auf einer inkrementellen Vorgehensweise. Die Entwicklungsabschnitte und Meetings werden in vordefinierten Zeitabschnitten organisiert (Time-Boxes). Das Resultat hieraus ist, dass ein funktionierendes Produkt wichtiger ist als eine seitenlange Spezifikation.

Ähnliche Beiträge

Scrum Burn-Down-Chart mit Excel Der Beitrag ist zwar schon etwas älter, aber er ist mir leider erst jetzt aufgefallen. PHPHatesMe hat einen interessanten Blog-Beitrag über den Einsat...

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.