Kolumne: A² – alles Agile

Agile Methoden: Planung ist alles
Kommentare

Agile Prozesse wie Scrum und Kanban spielen Ihre Stärken dadurch aus, das geregelt im Team kommuniziert wird, die Abstände zwischen den Regelkommunikationen gering sind und jeder im und außerhalb des bzw. der Entwicklungsteams weiß, wie die Kommunikation zu erfolgen hat. Ebenso müssen Regelprozesse und Vereinbarung eingehalten werden, um die Stärken der agilen Prozesse nicht zu gefährden.

Die Arbeit in Kanban kann mittels Tickets, welche auf Story Cards festgehalten werden, visualisiert werden. Wann die Tickets abgearbeitet werden, wird in einem Meeting, dem Queue Replenishment Meeting, entschieden, mehr dazu später. Alle Tickets werden in Kanban vom Grundsatz her mit der gleichen Priorisierung abgearbeitet, sobald sie vom Backlog in die Input Queue gekommen sind.

Dieser theoretische Ansatz bildet die Praxis allerdings nur sehr unzureichend ab. Im realen Projektumfeld kommt es oft vor, dass bestimmte Features oder auch Bugs „sofort“ behoben werden müssen, da es sonst zu Strafen oder Gewinnausfällen kommen kann. Daher haben sich Kanban Service-Level-Agreements (SLA) etabliert. Mittels SLA kann zum Beispiel verhindert werden, dass Tickets im Backlog über Monate oder Jahre ungeachtet liegen bleiben, ohne bearbeitet zu werden. Ein Pendant zu SLA gibt es in Scrum nicht.

Kanban – SLA

Serviceklassen sind in jedem Unternehmen individuell herauszuarbeiten, da Umfeld und Stakeholder sehr verschieden sein können. Unternehmen, die medizinische Geräte oder Software herstellen, müssen bei Softwarebugs wesentlich schneller reagieren und reagieren können als Unternehmen, wo zum Beispiel nicht unmittelbar Menschenleben gefährdet sind. Dennoch gibt es mindestens drei gängige SLA in Kanban: Beschleunigt, Fester Liefertermin und Standard.

Beschleunigt: Das Service-Level-Agreement Beschleunigt wird angewendet, wenn ein Nichtbearbeiten des Tickets sofort hohe Kosten nach sich ziehen würde. Dies könnte zum Beispiel dann der Fall sein, wenn in einem Shopsystem die Warenkorbfunktion dahingehend defekt wäre, dass ein Check-out nicht mehr funktioniert und so keine Verkäufe stattfinden könnten. Im positiven Fall könnten Quick-win-Geschäftsfälle bearbeitet werden. Bei dieser SLA sollten vorranging folgende Regeln für Beschleunigt-Tickets gelten. Das WIP-Limit ist für dieses Ticket in jedem Prozessschritt außer Kraft, das heißt, selbst wenn die In Progress-Spalte keine neuen Tickets zulassen würde und erst getestet werden müsste, darf und muss das Beschleunigt-Ticket in die Progress-Spalte gezogen werden. Sobald ein Beschleunigt-Ticket in der Input Queue ist, muss es als Nächstes von einem Team-Member gezogen werden. Das globale WIP-Limit für diese Klasse ist 1; es darf somit nur ein Ticket dieser Art im Prozess vorhanden sein. Um den Vorteil der beschleunigten Bearbeitung wirksam werden zu lassen, müssen Beschleunigt-Tickets sofort online gestellt werden, sobald sie den Prozess und zur Sicherheit ein nachgelagertes Continuous-Integration-System durchlaufen haben.

A² – alles Agile

  1. Agile Methoden – eine Einführung
  2. Agile Methoden: Story Cards und agile Prozesse
  3. Agile Methoden: Planung ist alles

Fester Liefertermin: Stakeholder würden sicher allzu gern und allzu oft Beschleunigt-Tickets in die Teams geben. Dies würde jedoch dazu führen, dass der Agile Prozess unterlaufen wird und seine Vorteile kaum ausspielen kann, wieder würde viel auf Zuruf oder dergleichen abgearbeitet werden. Daher sollten Beschleunigt-Tickets zur Ausnahme gehören. Um eine gefestigte Releaseplanung zu ermöglichen, kann das SLA Fester Liefertermin etabliert werden. Hier ist es dem Team freigestellt, wann ein Ticket gezogen wird – solange der Liefertermin eingehalten wird. Um den Liefertermin zu halten, müssen diese Tickets in Bezug auf Größe und Aufwand analysiert werden, damit sie früh genug vor Abgabe begonnen werden können. Das WIP-Limit wird nicht außer Kraft gesetzt, und die Lieferung erfolgt zum nächsten geplanten Release.

Standard: Standard-Tickets sollten den Großteil der Tickets ausmachen, welche den Kanban-Prozess durchlaufen. Sie werden bearbeitet, wenn keine Tickets der beiden vorangegangenen SLA vorliegen. Hierbei durchlaufen sie das System nach dem First-in-First-out-Prinzip. Im Gegensatz zum Festen Liefertermin werden diese Tickets nicht nach Größe und Aufwand geschätzt. Lediglich eine grobe Einteilung nach small, medium und large kann stattfinden.

Meetings

Tickets, welche zukünftig bearbeitet werden müssen, werden sowohl in Kanban als auch in Scrum im Backlog gepflegt. Scrum unterscheidet hierbei in Product Backlog und Sprint Backlog. Im Scrum Product Backlog bzw. im Kanban Backlog werden jene Anforderungen an das Produkt gepflegt, welche in den nächsten Produktiterationen umgesetzt werden sollen. Die Backlogs erheben hierbei nicht den Anspruch auf Vollständigkeit. Sie sind lebende Dokumente, welche gepflegt werden und wachsen. Sie spiegeln jeweils den aktuellen Stand der Anforderungen wider. Tickets, welche im nächsten Zyklus (Scrum: Sprint, Kanban: nicht zwingend definiert) abgearbeitet werden sollen, daher vom (Product) Backlog in den Sprint Backlog (Scrum) oder in die Input Queue (Kanban) wandern, werden in folgenden Meetings besprochen.

Sprint Planning (Scrum)

Im Sprint-Planungsmeeting, an welchem das Scrum-Team und der Product Owner teilnehmen, werden zwei Aspekte besprochen. Zum einen, welche Tickets im kommenden Sprint abgearbeitet werden und zum zweiten, wie diese abgearbeitet werden. Da dies meist komplexe Fragestellungen sind, wird dieses Meeting in zwei Teile aufgeteilt, die auch zu unterschiedlichen Zeitpunkten stattfinden können. Zu unterschiedlichen Zeitpunkten kann es kommen, wenn im ersten Teil des Meetings Fragen an den Product Owner gestellt werden, welche dieser erst im Detail bei seinen Stakeholdern klären muss.

PHP Magazin

Entwickler MagazinDieser Artikel ist im PHP Magazin erschienen. Das PHP Magazin deckt ein breites Spektrum an Themen ab, die für die erfolgreiche Webentwicklung unerlässlich sind.

Natürlich können Sie das PHP Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Teil 1: Das Meeting beginnt mit der Vorstellung jener Tickets durch den Product Owner, die er im folgenden Sprint entwickelt haben möchte. Hierfür hat der Product Owner „seine“ Tickets im Vorfeld des Meetings eindeutig priorisiert, um dem Team eine Abarbeitungsreihenfolge vorzugeben. Zum Thema Schätzung finden Sie weitere Details im Kasten „Exkurs – Product Backlog Refinement und Planning Poker“.


Exkurs: Product Backlog Refinement und Planning Poker

In einigen Teams ist festzustellen, dass das Schätzen des Aufwands für die Entwicklung der einzelnen Tickets im Sprint-Planungsmeeting geschieht. Diese Aufgabe sollte in einen wiederkehrenden Prozess – dem Product Backlog Refinement – ausgelagert werden. In diesem Meeting wird der Product Backlog (zum Beispiel einmal pro Woche) gepflegt. Die Pflege beinhaltet das Ordnen der Einträge, das Ausarbeiten, das Zusammenführen, aber auch das Löschen und Schätzen der Einträge. Um schätzen zu können, müssen die Tickets und deren Anforderungen vom Product Owner erläutert werden. Das Team ist angehalten, solange Rückfragen zu stellen, bis die Anforderung verstanden ist. Danach kann geschätzt werden. Ist ein Ticket zu groß, um es zu schätzen, empfiehlt es sich, das Ticket in kleinere Tickets aufzuteilen.

Eine gängige Methode, um Tickets und deren Anforderungen zu schätzen, ist das Planning Poker. Hierfür erhält jeder im Team Karten, mit folgenden Punktzahlen (0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100). Bei jedem Ticket gibt jedes Teammitglied verdeckt seine Schätzung des Aufwands ab. Nachdem jedes Teammitglied dies getan hat, werden die Karten aufgedeckt. Hier zeigt sich sehr schnell, ob alle im Team die Aufgabe gleich verstanden haben, oder ob es noch Unklarheiten gibt. Legen drei Mitglieder aus dem Team eine 5, einer eine 13 und wieder jemand eine 1, muss diskutiert werden, woher die Abweichung vom Durchschnitt kommt. Allzu oft liegt hier ein Mangel an Verständnis und Definition der Aufgabe vor. So verfährt das Team zusammen mit dem Product Owner mit allen Tickets, welche es zu schätzen gilt. Diese Punkte sind abstrakt zu verstehen; über die Zeit, von Sprint zu Sprint, entwickelt das Team ein Gefühl dafür, wie viele Punkte es in Summe pro Sprint abarbeiten kann.

Im Sprint-Planungsmeeting erarbeitet das Team zusammen mit dem Product Owner und den geschätzten und priorisierten Tickets ein Verständnis dafür, welche Arbeiten im folgenden Sprint zu bearbeiten sind. Das Team bespricht die Eigenschaften und Akzeptanzkriterien der Aufgaben und einigt sich zusammen mit dem Product Owner auf eine Definition of Done (DoD). Die DoD legt jene Kriterien fest, welche darüber entscheiden, ob eine geforderte Funktionalität am Ende als fertig und entwickelt gilt. Im Anschluss – unter Zuhilfenahme der Schätzungen – entscheidet das Team, wie viele Tickets es im nächsten Sprint abarbeiten kann, der Product Owner hat hier kein Mitspracherecht. Lediglich die Reihenfolge wurde durch den Product Owner mittels der Priorisierung festgelegt.


Teil 2: In Teil 1 des Meetings hat sich das Team zusammen mit dem Product Owner auf die abzuarbeitenden Tickets geeinigt. Im zweiten Teil erörtert das Team (der Product Owner ist nicht zwingend von Nöten, sollte aber in Reichweite sein, so Fragen auftauchen), wie die einzelnen Tickets abzuarbeiten sind, um das Sprint-Ziel und die DoD der Tickets zu erreichen. Das Team kann sich hierzu in Kleingruppen/Spezialistengruppen aufteilen, um zum Beispiel Architekturfragen oder Datenbankfragen zu erörtern. Nach dem Meeting steht der Sprint Backlog mit allen Aufgaben im Detail. Da Sprints in Scrum geschützt sind, werden dem Sprint Backlog von außen keine neuen Tickets oder geänderte Prioritäten hinzugefügt.

Queue Replenishment (Kanban)

Kanban kennt keine Iterationszyklen, à la Sprints, wie sie in Scrum üblich sind. Im Kanban-Umfeld finden regelmäßig Releaseplanungen statt, auch ein fester Releasezyklus wird angestrebt, üblich sind hier ähnlich wie in Scrum, zwei oder vier Wochen. Bevor ein Release herausgegeben werden kann, werden die Tickets aus dem Backlog in die Input Queue gezogen. Dieser Vorgang findet im Queue-Replenishment-Meeting statt, an welchem alle Stakeholder teilnehmen, die Tickets in den Backlog gegeben haben. Auch die Input Queue besitzt ein WIP-Limit, was bedeutet, dass in dem Meeting zusammen mit den Stakeholdern ermittelt werden muss, welche Tickets den meisten Business Value besitzen. Die Tickets und Anforderungen werden mit den Stakeholdern erörtert und beschrieben. Anders als in Scrum findet keine Aufwandschätzung statt, Ausnahme bilden hier Tickets mit dem SLA Fester Liefertermin. Der Zyklus des Queue-Replenishment-Meetings und des Releaseplanungsmeetings muss nicht gleich sein, das Queue-Replenishment-Meeting empfiehlt sich mindestens einmal pro Woche.

Nach dem Sprint-Planungsmeeting und dem Start des Sprints, wie auch nach dem Queue-Replenishment-Meeting, wird kein neuer Input in die Teams gegeben. Der Sprint und die Input Queue sind geschützt. Neue Tickets werden in den Backlogs gepflegt und geordnet in den jeweiligen Meetings an die Teams gegeben. Ausnahme in Kanban ist das SLA Beschleunigt, welches nach den definierten Regeln in den Kanban-Prozess gegeben werden darf.

 

Aufmacherbild: Chess photographed on a chessboard von Shutterstock / Urheberrecht: carlo fornitano

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -