Agile

Scrum, eine agile Entwicklungsmethodik, ist ein Rahmen für das Projektmanagement, der Teamarbeit, Verantwortlichkeit und iterativen Fortschritt in Richtung eines klar definierten Ziels hervorhebt. Die drei Säulen von Scrum sind Transparenz, Überprüfung und Anpassung.

Wir empfehlen Scrum, wenn:

  • Sich die Projektanforderungen ändern und weiterentwickeln

  • Kontinuierliches Feedback erforderlich ist

  • Sie keinen festen Termin für das Release zusagen müssen

  • Das Projektteam Autonomie möchte

Scrum funktioniert gut für Projekte, bei denen es viele Unbekannte gibt oder die sich im Laufe der Zeit weiterentwickeln. Scrum geht sehr effektiv mit diesen Änderungen um, sodass Sie während des gesamten Prozesses problemlos neue Informationen oder Funktionen berücksichtigen können.

Rollen und Verantwortlichkeiten

Ein Scrum-Team benötigt drei spezifische und eine optionale Rolle:

  • Product Owner

  • Scrum Master

  • Entwicklungsteam

  • Kunde (optional)

Diese drei Rollen sind gleichwertig und alle haben bestimmte Verantwortlichkeiten.

Rollen und Verantwortlichkeiten

Product_Owner.png

Product Owner

Repräsentiert den Kunden und das Geschäft

  • Verantwortlich für die Verfolgung der Anforderungen

  • Verantwortlich für den Produkterfolg

  • Vermittelt die Produktvision

  • Definiert alle Produkteigenschaften

  • Pflegt das Produkt Backlog

  • Stellt sicher, dass das Team an den wertvollsten Funktionen arbeitet

Scrum_Master.png

Scrum Master

Stellt sicher, dass das Team alles hat, was es braucht, um Wert zu liefern. Er fungiert als Servant-Leader für das Entwicklungsteam

  • Ist Vermittler kein Manager

  • Beseitigt Hindernisse

  • Schützt das Team vor externen Störungen

  • Ist der Wächter des Prozesses

  • Unterstützt die verschiedenen Scrum Events

Team_Member.png

Entwicklungsteam

Konzentriert sich auf die Bereitstellung funktionierender Software

Das Entwicklungsteam ist funktionsübergreifend, selbstverwaltet, selbstorganisiert und engagiert. Diese Autonomie macht Scrum einzigartig. Es ist das eigentliche Herzstück des Prozesses. Aus diesem Ansatz resultiert eine starke Teambindung und ein positives Arbeitsumfeld, in dem sich die Mitarbeiter bei der Arbeit gestärkt fühlen.

  • Pflegt das Iteration Backlog

  • Führt die täglichen Scrum Meetings durch

  • Stellt sicher, dass am Ende der Iteration eine potenziell auslieferbare Funktion geliefert wird.

Customer.png

Kunde

Optional, da der Kunde der Product Owner sein kann

Wenn das Projekt intern entwickelt wird, ist der Kunde oft der Product Owner.

Wenn das Projekt extern entwickelt wird, ist der Kunde verantwortlich für:

  • Die Überwachung des Produkt Backlogs durch:

    • Das Priorisieren von Elementen, die in einer Iteration berücksichtigt werden sollen.

    • Das jederzeitige Hinzufügen von Elementen bei Bedarf.

    • Das Entfernen von Elementen, wenn erforderlich.

  • Testen der Ergebnisse und deren Validierung in Bezug auf die Abnahmekriterien.

Scrum-Lebenszyklus

Scrum_Life_Cycle.png

Innerhalb von Agile wird das Projekt von den Iterationen vorangetrieben. Der Scrum Master und der Product Owner erstellen für jede Iteration einen Vorschlag für ihren Inhalt (auch bekannt als Iteration Backlog), indem sie eine Liste von Backlog Items definieren, die Kriterien wie Business Value, Epics oder die vergangene Geschwindigkeit (d.h. die Fähigkeit, Story Points zu liefern) berücksichtigt. Dies wird als Iteration Planungsmeeting bezeichnet.

Der Vorschlag wird dann mit den Teammitgliedern besprochen. Story-Point-Schätzungen werden überprüft, damit sich das Team schließlich auf die Lieferung des Iteration Backlogs festlegen kann. Es gibt verschiedene Möglichkeiten, dieses Meeting mit der Planning Poker-Technik durchzuführen.

Während einer Iteration trifft das Team täglich kurz zusammen (tägliche (Scrum-)Meetings), um den Fortschritt, aber vor allem Probleme oder technische Schwierigkeiten zu besprechen.

Am Ende der Iteration sollten alle fertiggestellten Elemente lieferbar sein (als Teil ihres Releases). Ein Post-Mortem-Meeting kann organisiert werden, um die während der Iteration aufgetretenen Schwierigkeiten zu besprechen, die Geschwindigkeit zu überprüfen und für die nächste Iteration zu verbessern.

Produkt Backlog

Das Produkt Backlog listet alle Features, Funktionen, Anforderungen, Verbesserungen und Fixes auf, die die Änderungen darstellen, die in zukünftigen Releases am Produkt vorgenommen werden sollen. Das Produkt Backlog ersetzt die funktionalen Spezifikationen der Wasserfall Methode.

Das Produkt Backlog hat folgende Eigenschaften:

  • Jeder Eintrag muss für den Kunden einen Mehrwert haben.

  • Während des gesamten Projekts können Änderungen auftreten.

  • Vorgänge auf niedrigen Ebenen sollten nicht beschrieben werden.

  • Alle Einträge werden priorisiert, um das Produkt Backlog zu ordnen.

  • Alle Einträge werden im Allgemeinen in Story Points geschätzt.

Das Produkt Backlog muss in einem fortlaufenden Prozess vom Product Owner gepflegt werden.

Backlog Items

Das Produkt Backlog besteht aus Backlog Items.

Ein Backlog Item ist eine Arbeitseinheit, die klein genug ist, um von einem Team in einer Iteration abgeschlossen zu werden. Backlog Item werden in einen oder mehrere Vorgänge zerlegt.

Wenn sie in das Produkt Backlog eingetragen werden, können Backlog Items benutzerzentriert sein. In diesem Fall werden sie in Form von User Stories geschrieben.

Eine User Story ist eine sehr grobe Definition einer Anforderung, die gerade so viele Informationen enthält, dass die Entwickler den Aufwand für ihre Umsetzung vernünftig abschätzen können. Eine User Story beschreibt eine Funktionalität aus der Sicht eines Benutzers, die auf solide und kompakte Weise ausgedrückt wird. Sie spiegeln die Bedürfnisse einer bestimmten Benutzerklasse und den zu erzielenden Wert wider. Das Format ist sehr einfach und leicht zu verwenden.

Als <Benutzer einer bestimmten Klasse> möchte ich <in der Lage sein etwas auszuführen/zu tun>, damit <ich einen Wert oder Nutzen erhalte>

Example of a Product Backlog – User Centric

Das Schreiben von User Stories ist jedoch nicht zwingend erforderlich. Backlog Items können auch mit wenigen Schlüsselwörtern oder kurzen Sätzen eingegeben werden, sofern sie für das Projektteam und die Stakeholder verständlich sind.

Key_words.png

Iterationsplanung

An der Besprechung zur Iterationsplanung nehmen der Product Owner, der Scrum Master und das gesamte Projektteam teil. Externe Beteiligte können auf Einladung des Teams teilnehmen, obwohl dies in den meisten Unternehmen ehe selten vorkommt.

Während des Iterationsplanungsmeetings beschreibt der Product Owner dem Team die Funktionen mit der höchsten Priorität, um das Iterationsziel zu definieren. Dann bestimmen sie die Backlog Items, an denen sie während dieser Iteration arbeiten, nachdem sie sie geordnet und geschätzt haben.

Iterationen

Eine Iteration ist ein abgepackter Teil eines kontinuierlichen Entwicklungszyklus. Innerhalb einer Iteration muss der geplante Arbeitsumfang vom Team abgeschlossen und zur Überprüfung bereitgestellt werden. Der Begriff wird hauptsächlich in der Scrum-Methodik verwendet. Der Oberbegriff im agilen Ansatz ist Iteration (der in Sciforma verwendete).

Die durchschnittliche Iterationsdauer beträgt im Allgemeinen zwischen 2 und 4 Wochen.

Arbeitsschätzungen

Bei der Scrum-Methodik erfolgt die Schätzung der Arbeit nicht in Stunden, sondern in Story Points.

Story Points sind eine Maßeinheit, um eine Schätzung des Gesamtaufwands auszudrücken, der erforderlich ist, um ein Backlog Item oder eine andere Arbeit vollständig zu implementieren. Beim Schätzen mit Story Points wird jedem Backlog Item ein Punktwert zugewiesen.

Skalen wie die folgenden werden oft verwendet, um Story Points einzuschätzen:

  • Die Fibonacci-Folge (0.5, 1, 2, 3, 5, 8, 13, 21,...)

  • Die lineare Zahlenfolge (1, 2, 3, 4, 5, 6, 7, 8, …) – wird von Sciforma verwendet

Da die Übung kollaborativ durchgeführt werden kann, verwenden einige Unternehmen Techniken wie Planning Poker.

  1. Der Product Owner präsentiert die Backlog Items, die geschätzt werden müssen. Die Teammitglieder stellen Fragen und der Product Owner gibt weitere Details.

  2. Jedes Teammitglied, das einen Kartensatz erhält, wählt für sich die Karte aus, die der Schätzung entspricht.

  3. Wenn alle Teammitglieder ihre Schätzungen abgegeben haben, decken sie ihre Karten gleichzeitig auf. Wenn alle Schätzungen gleich sind, wird ein neues Backlog Item ausgewählt und der gleiche Vorgang wiederholt. Wenn die Schätzungen abweichen, diskutieren die Teammitglieder das Problem, um einen Konsens zu finden.

Team Velocity

Wenn Backlog Items geschätzt wurden, müssen Story Points mit der Team Velocity verglichen werden.

Die Team Velocity basiert auf den tatsächlich abgeschlossenen Story Points, die in der Regel ein Durchschnitt aller vorherigen Iterationen sind. Die Team Velocity wird verwendet, um zu planen, wie viele Backlog Items das Team während der nächsten Iteration planen und abschließen kann.

Um jedoch die Backlog Items zu erkennen, die in der nächsten Iteration berücksichtigt werden könnten, muss auch das Projekt Teamkapazität berücksichtigt werden. Die Kapazität gibt an, wie groß die Verfügbarkeit des Teams für die Iteration ist. Daher kann sie variieren, wenn Teammitglieder im Urlaub, krank usw. sind.

Ergebnis der Iterationsplanung

Das Ergebnis der Iterationsplanung ist der Iteration Backlog.

Iteration Backlog

Der Iteration Backlog ist eine Teilmenge des Produkt Backlogs. Der Iteration Backlog stammt aus dem Produkt Backlog und enthält die Backlog Items, die innerhalb der Iteration abgeschlossen werden können.

Im Gegensatz zum Produkt Backlog bleibt der Iteration Backlog während des Iterationszeitraums unverändert. Tatsächlich werden am Ende der Iterationsplanung die Backlog Items und Schritte zu ihrer Fertigstellung für die Dauer der Iteration eingefroren. Wenn am Ende der Iteration Backlog Items unvollendet bleiben, werden sie wieder dem Produkt Backlog hinzugefügt und während der nächsten Iteration bearbeitet.

Auf hoher Ebene kann ein Projekt als Epics, Themen oder Features beginnen, die dann in Backlog Items unterteilt werden.

Tasks werden verwendet, um Backlog Items bei Bedarf noch weiter aufzuschlüsseln. Tasks sind die kleinste Einheit, die verwendet wird, um Arbeit zu verfolgen. Ein Task sollte von einer Person im Team erledigt werden. Normalerweise hat jedes Backlog Item mehrere zugeordnete Tasks. Da das Team funktionsübergreifend ist, können Teammitglieder mit Tasks für ein einzelnes Backlog Items parallel an ihrem fachlichen Fachgebiet arbeiten, um das Item als Team abzuschließen.

Das Aufteilen von Backlog Items in Tasks hilft dem Team daher, zu bestimmen, wie es die zu erledigende Arbeit angehen wird. In dieser Detailebene, werden alle Unbekannten aufgedeckt.

Tägliches Scrum Meeting

Das Ziel von Daily Scrum Meetings (auch bekannt als Daily Stand-up Meetings) ist es, alle schnell über das Geschehen im Team zu informieren. Das strikt auf 15 Minuten begrenzte Meeting wird vom Scrum Master abgehalten, der jedem Teammitglied drei Fragen stellt.

Was hast du gestern gemacht?

Der Scrum Master möchte wissen, welche Tasks „erledigt“ sind und ob laufende Tasks wie erwartet abgeschlossen werden. Wenn Schätzungen erweitert werden oder neue Tasks entdeckt werden, ändert sich das Burndown Chart.

Was wirst du heute tun?

Diese Frage ersetzt Balkenpläne. Abhängigkeiten ändern sich ständig. Durch die Beantwortung dieser Frage wird die Projektstrategie täglich überarbeitet, indem das Team aufgrund von Abhängigkeitsänderungen, die durch die vorherige Frage aufgedeckt wurden, neu ausgerichtet wird.

Gibt es Probleme oder Hindernisse, die dich an deiner Arbeit hindern?

Der wichtigste Effekt dieser Frage besteht darin, eine Liste mit Hindernissen zu erstellen, die dem Team zugewiesen oder eskaliert werden. Eine Hauptaufgabe des Scrum Masters besteht darin, dieses Hindernis Backlog zu verwalten, zu priorisieren und sicherzustellen, dass es erledigt wird.

Task Board

Das Task Board ist eine visuelle Darstellung des Fortschritts des Projektteams während einer Iteration. Es stellt eine Momentaufnahme des aktuellen Iteration Backlogs dar, sodass jeder sehen kann, welche Tasks und Backlog Items noch gestartet werden müssen, welche in Bearbeitung und welche erledigt sind.

Das Task Board wird täglich während des Daily Scrum Meetings aktualisiert.

Task_board.png

Burndown Chart

Ein Burndown Chart ist eine grafische Darstellung der noch zu erledigenden Arbeit im Vergleich zur Zeit.

Burndown_Chart.png

Die X-Achse des Diagramms zeigt immer die Zeit an (normalerweise in Tagen).

Die Y-Achse repräsentiert die verbleibende Arbeit in der Iteration. Dies kann entweder durch verbleibende Tasks (Anzahl der Tasks) oder Restaufwand (in Story Points/Stunden) dargestellt werden.

Die Fortschrittslinie zeigt an, wie das Team bei seiner Iteration vorankommt. Es wird jeden Tag mit den neuen Restschätzungen aktualisiert. Im Verlauf der Iteration zeigt diese Zeile an, ob das Team auf dem richtigen Weg ist und ob Korrekturmaßnahmen erforderlich sind.

Die Leitlinie ist eine diagonale Linie, die von links nach rechts in der Grafik nach unten gezogen wird. Ihre Iterationsfortschrittslinie sollte idealerweise so nah wie möglich an der Leitlinie liegen. Wenn das Team während der gesamten Iteration alle Storys in einem gleichmäßigen Tempo abschließen kann, sieht Ihre Fortschrittslinie am Ende genau wie die Leitlinie aus.

Wenn die Linie für den Iterationsfortschritt über der Leitlinie liegt, bedeutet dies, dass das Projektteam hinter dem Zeitplan liegt und zu diesem Zeitpunkt mehr Arbeit hätte erledigen sollen.

Wenn die Iterationsfortschrittslinie und die Leitlinie dicht beieinander liegen, bedeutet dies, dass das Projektteam die gesamte Arbeit abschließt, wenn es seine Geschwindigkeit beibehält.

Wenn die Linie für den Iterationsfortschritt unterhalb der Leitlinie liegt, bedeutet dies, dass das Projektteam dem Zeitplan voraus ist und alle Arbeiten vor dem Enddatum der Iteration abschließen sollte. In diesem Fall kann das Projektteam der Iteration neue Backlog Items hinzufügen, um sicherzustellen, dass sie bis zum Enddatum der Iteration beschäftigt sind.

Stretch Item

Ein Stretch Item ist ein Backlog Item, das nicht Teil der Verpflichtung des Teams für eine Iteration ist. Es wird jedoch als etwas gekennzeichnet, das getan werden könnte, wenn die Teammitglieder ihre Verpflichtungen vorzeitig beendet haben.

Iteration Review Meeting

Am Ende der Iteration lädt der Product Owner das Projektteam und die wichtigsten Beteiligten zum Iteration Review Meeting ein. Während dieser Besprechung wird das Ergebnis anhand einer Demo überprüft, damit jeder Feedback zu der geleisteten Arbeit geben kann.

Der Zweck der Iterationsüberprüfung besteht nicht darin, Beteiligten eine Statusaktualisierung oder eine Präsentation bereitzustellen. Es dient dazu, Feedback zum aktuellen Inkrement zu sammeln und zu verarbeiten.

Hier ist die typische Agenda eines Iteration Review Meetings:

  • Der Product Owner erklärt, welche Backlog Items „erledigt“ wurden und was nicht „erledigt“ wurde.

  • Das Projektteam bespricht, was während der Iteration gut gelaufen ist, welche Probleme dabei aufgetreten sind und wie diese Probleme gelöst wurden.

  • Das Projektteam demonstriert die Arbeit, die es „erledigt“ hat, und beantwortet Fragen zum Inkrement.

  • Der Product Owner bespricht den aktuellen Stand des Produkt Backlogs und prognostiziert bei Bedarf Ziel- und Liefertermine basierend auf dem bisherigen Fortschritt.

  • Die gesamte Gruppe arbeitet gemeinsam daran, was als nächstes zu tun ist, sodass die Iterationsüberprüfung wertvollen Input für nachfolgende Iteration Backlogs liefert.

Rückblickende Analyse der Iteration

Die Iteration Retrospektive findet nach der Iterationsüberprüfung und vor der nächsten Iterationsplanung statt. Da dieses Meeting eine Zeit ist, um über die gerade gelieferte Iteration zu diskutieren, nehmen das Projektteam, der Scrum Master und der Product Owner daran teil.

Ziel der Retrospektive ist es, dass die Teammitglieder untereinander diskutieren, wie die Arbeit während der letzten Iteration gelaufen ist, damit bessere Wege gefunden werden können, die Projektziele zu erreichen und die Produktivität zu verbessern. Alle Mitglieder diskutieren Misserfolge und zukünftige Verbesserungen und verfolgen die gewonnenen Erkenntnisse.

Die Iteration Retrospektive könnte mit dem Post-Mortem-Meeting in der Wasserfall-Methodik verglichen werden. Da es jedoch am Ende jeder Iteration und nicht am Ende des Projekts stattfindet, können Prozessanpassungen häufiger vorgenommen und kleine Verbesserungen regelmäßig implementiert werden.

Was ist die beste Organisation bei der Verwendung von Agile?

Eine agile Organisation reagiert schnell auf Veränderungen im Markt oder in der Umgebung. Eine hoch agile Organisation reagiert erfolgreich auf das Aufkommen neuer Wettbewerber, schneller technologischer Fortschritte und plötzlicher Veränderungen der allgemeinen Marktbedingungen.

Was ist ein agiles Team nicht?

Ein agiles Team ist nicht einfach ein Projektteam, das sich aus verschiedenen Personen aus unterschiedlichen Unternehmensbereichen zusammensetzt, wie beispielsweise eine Task Force.

Ein agiles Team besteht nicht nur aus Entwicklerressourcen. Es ist auch kein Matrix-Team.

Was ist ein agiles Team?

Ein agiles Team ist eine funktionsübergreifende Gruppe von Personen, die so weit in sich geschlossen ist, dass die Personen in der Gruppe das Produkt (oder die nächste Iteration davon) liefern können, ohne auf Qualifikationen außerhalb der Gruppe zurückgreifen zu müssen.

Agile_Team.png

Ein agiles Team ist eine fest zugeordnete Gruppe von Personen, die nicht zwischen Produkten oder Teams wechseln, nur weil eine andere Arbeit eine höhere Priorität erhält.

Ein agiles Team ist selbstorganisiert. Es hat daher die Verantwortung und die Befugnis, eine funktionierende, interne Teamstruktur zu schaffen, indem es Teammitglieder nach Bedarf ersetzt, umschult oder umorganisiert.

Ein agiles Team ist selbstverwaltet. Die Teammitglieder sind für die Planung, Durchführung, Überwachung und Verwaltung ihrer Aktivitäten unter eingeschränkter oder keiner Aufsicht verantwortlich.

Man darf nicht vergessen, dass Agile ein anpassungsfähiger Ansatz und eine Denkweise ist. Es liegt an jedem Unternehmen, die Organisation so anzupassen, dass sie für ihre Projekte funktioniert.

Sciforma Datenmodell

Das Sciforma-Datenmodell wurde implementiert, um die Bedürfnisse und Anforderungen der Kunden zu erfüllen.

Sciforma_Data_Model.png

Storys, Mängel, Tasks und Probleme werden alle als Backlog Items verwaltet.

Dies erleichtert den Projektfortschritt insbesondere bei Verwendung des Task Boards, da alle Backlog Items auf derselben Ebene verwaltet werden.

Außerdem kann an Backlog Items eine Items-Checkliste angehängt sein. Diese Elemente können in Tasks umgewandelt werden. In diesem Fall wird eine Verbindung zwischen dem Backlog Item und diesem neu erstellten Task hergestellt.