Kolumne: A² – alles Agile

Agile Methoden: Story Cards und agile Prozesse
Kommentare

Besonders in der agilen Softwareentwicklung ist Refactoring ein integraler Bestandteil des Softwareentwicklungsprozesses und beschränkt sich nicht auf spezifische Phasen oder Zeiten. Die Zielsetzung des Refactorings darf bei diesem Prozessschritt nicht außer Acht gelassen werden.

Refactoring findet nicht zum Selbstzweck statt. Es empfiehlt sich, sowohl beim manuellen als auch beim automatischen Review nur vorher abgestimmte Regeln zu kontrollieren. Vielfach werden die Coderegeln etc. schon vor dem Reviewabeitsschritt durch das Team festgelegt. Dabei gilt es, Regeln, die für ein Projekt als nicht sinnvoll empfunden werden, herauszufiltern.

Werden Regeln aufgestellt, die vom Team nicht akzeptiert werden, können sie zwar durchgesetzt werden, behindern aber einen qualitativen Reviewprozess. Ziel ist es, die Codequalität zu verbessern, um Wartung und Erweiterbarkeit effizienter gestalten zu können. Insgesamt muss der Aufwand, um das zu erreichen, um ein Vielfaches geringer sein als der Aufwand für die Wartung/Erweiterbarkeit ohne diese Regeln.

Automatisierte Tests und Unit Tests unterstützen das Refactoring in besonderem Maße. Nach jedem Refactoring-Schritt stellen sie sicher, dass der veränderte Codeteil die bedienten Requirements nach wie vor abbildet.

Story Cards

Im klassischen Projektmanagementprozess wie etwa dem V- oder dem Wasserfallmodell werden sämtliche Requirements in der Spezifikationsphase erfasst und in entsprechenden Dokumenten festgehalten. Oft sind das Lasten- und Pflichtenhefte, die je nach Projekt entsprechend umfangreich werden können. Auch im agilen Projektmanagement gibt es Spezifikationsphasen, allerdings nicht allumfassend für das gesamte Projekt, sondern lediglich – wie z. B. im Scrum-Prozess – vor jedem Sprint.

Ein Hilfsmittel, das in dieser Phase Anwendung findet, sind die Story Cards. Mit ihnen wird den Stakeholdern die Anforderung genommen, ein vollumfängliches Lastenheft zu erstellen, das unter anderem schon technische Aspekte betrachtet. Auf einer Story Card wird jeweils eine User Story beschrieben, die darlegt, welche Funktionalität aus Usersicht gewünscht ist. Das geforderte Verhalten des zu erstellenden Systems wird durch prosaische Kurzbeschreibungen spezifiziert. Durch diese Art der Darlegung wird es den Stakeholdern erleichtert, die Beschreibung in ihrer eigenen Sprache zu verfassen, ohne zum Beispiel technische Fachbegriffe zu benutzen.

A² – alles Agile

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

Story Cards finden sich unter anderem im Scrum-Prozess wieder, bei dem am Anfang eines Sprints vom Team zusammen festgelegt wird, welche Storys im Sprint umgesetzt werden. Um sie angemessen ein- und abschätzen zu können, ist es unabdingbar, dass pro Story – und demzufolge pro Story Card – nur kleine Teilaspekte des Gesamtsystems betrachtet und niedergeschrieben werden.

Die Storys sollten hierbei so gestaltet sein, dass sie für sämtliche am Softwareentwicklungsprozess Beteiligten verständlich sind. Ist das nicht der Fall, müssen diese Missverständnisse zeitnah adressiert und kommuniziert werden. Auf diese Weise rückt auch bei den Story Cards wieder die Kommunikation in den Vordergrund – diesmal zwischen dem Anforderer und dem Umsetzer.

Auf den Story Cards können neben der eigentlichen Story auch weitere Aspekte vermerkt werden. Etabliert hat es sich, auf der Rückseite die Akzeptanzkriterien der Story zu hinterlegen. Damit beschreibt der Anforderer, wie er die korrekte Umsetzung der User Story zu testen gedenkt. Diese Kriterien können bereits im vorgelagerten Reviewprozess vom Reviewer Beachtung finden und gemeinsam erörtert werden.

Agile Prinzipien und Methoden bilden die Basis für agile Softwareentwicklung.

Agile Prinzipien und Methoden bilden die Basis für agile Softwareentwicklung, und die hier exemplarisch erörterten Praktiken finden sich in agilen Prozessen wie Scrum, Kanban oder XP wieder. Dennoch ist eine Verwendung in klassischen Wasserfall- oder V-Modell-Projekten denkbar, um die Vorteile, wie eine verbesserte Kommunikation, auch in sie zu transportieren.

Agile Methoden wie Pair Programming, Code-Reviews, testgetriebene Entwicklung, Refactoring und Story Cards finden entweder Anwendung in nicht agilen Prozessen wie dem V-Modell, um sie punktuell zu verbessern, oder in agilen Prozessen wie Scrum, Kanban oder XP. Agile Prozesse sind dadurch gekennzeichnet, dass sie die Bürokratie auf ein Minimum reduzieren und eher die menschlichen Aspekte in den Vordergrund stellen.

Eine negative Auslegung dieses Aspekts ist häufig in der Behauptung anzutreffen, in agilen Prozessen wie z. B. Scrum werde keine Dokumentation erstellt. Dieses Extrem ist jedoch kritisch zu betrachten und in Frage zu stellen. Die Dokumentation soll zielgerichtet und angemessen im Nutzen sein, aber nicht vollkommen eliminiert werden.

Dabei handelt es sich vor allem um eine negative Auslegung aus Entwicklersicht; allerdings werden agile Prozesse auch aus Managementsicht oft missverstanden. Sätze wie „Ihr seid ja agil, also können wir diese und jene Anforderung schnell noch reinnehmen“ oder „das müssen wir jetzt schnell ändern“ sind vielen agilen Teams sicher bekannt – und ein Dorn im Auge. Dem Management muss verständlich gemacht werden, was Agilität bedeutet, wie sie entsteht und wie sie zu verstehen ist.

Agilität entsteht durch die Entschlackung und Verkürzung der Prozesse und Prozessschritte.

Agilität entsteht durch die Entschlackung und Verkürzung der Prozesse und Prozessschritte. Durch diese Herangehensweise ist es möglich, schneller qualitativ hochwertige Software in kurzen Intervallen zu liefern und Feedback für diese Software zu erhalten. Das bedingt allerdings, dass die Prozessschritte, z. B. Sprints in Scrum, geschützt sind und geplant und ungestört durchlaufen können. Dann, und nur dann, kann Agilität – also die Fähigkeit, in kurzen Zeitintervallen auf Feedback reagieren und Anpassungen vornehmen zu können – entstehen, die agil und nicht chaotisch ist.

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.

Agile Prozesse

Zwei wesentliche Arbeitsweisen stehen bei der Betrachtung von agilen Prozessen seit einigen Jahren im Vordergrund: Scrum und Kanban. Oft ist hierbei zu beobachten, dass Scrum in Entwicklungsteams eingesetzt wird, während Kanban in Wartungs- oder Daily-Business-Teams zum Einsatz kommt. Eine folgende Gegenüberstellung soll verdeutlichen, was die Stärken und Schwächen von Scrum und Kanban sind und wie beide Prozesse optimal eingesetzt werden können.

Scrum

Klassische Projektmanagementmethoden (Wasserfall- oder V-Modell) können sehr lange Durchlaufzeiten nach sich ziehen. Hierdurch vergeht zwischen der Spezifikation eines Softwareprodukts und dessen Auslieferung viel Zeit – teilweise bis zu mehreren Jahren. Dadurch verlieren sowohl die auftraggebenden Stakeholder als auch die Entwickler schnell den Überblick über die Anforderungen und deren Notwendigkeit.

Ebenso kann es sein, dass sich der Markt, also die abnehmenden Stakeholder, in eine völlig andere Richtung entwickeln und nach der Auslieferung das Produkt gar nicht oder zumindest nicht mehr in dieser Form benötigen. Durch einen iterativen Projektmanagementansatz wie Scrum kann verhindert werden, dass eine falsche oder eine an den Anforderungen des Markts vorbeigehende Software entwickelt wird.

Der Scrum-Prozess ist durch in ihrer Länge fixierte iterative Schritte gekennzeichnet.

Der Scrum-Prozess als Projektmanagementframework ist dadurch gekennzeichnet, dass die iterativen Schritte, in Scrum Sprints genannt, die zu einem möglichen Softwareendprodukt führen, in ihrer Länge fixiert sind. Man spricht hierbei auch vom Time Boxing. Durch diese feste Länge wird eine Vergleichbarkeit der Iterationsschritte erreicht, die es dem Team perspektivisch ermöglicht, verlässlicher in ihren Zusagen bezüglich der gelieferten Softwarefeatures zu werden. Ebenso ermöglicht eine feste Sprintlänge auch anderen Bereichen im Unternehmen die Planung von Softwarereleases.

In Scrum wird die Arbeit im Product Backlog vorgehalten. Vor jedem Sprint bespricht der Product Owner zusammen mit dem Team, welche Storys er zur Bearbeitung im nächsten Sprint wünscht. Das Team lässt sich die einzelnen Storys vom Product Owner darlegen und spezifiziert mit ihm zusammen die Anforderungen und Abnahmekriterien, die dann auf der Rückseite der Story Card notiert werden.

Oft schätzt das Team in diesem Schritt den Aufwand in so genannten Story Points und notiert sie ebenfalls auf der Story Card, die im Anschluss im Sprint Backlog hinterlegt wird. Durch die feste Sprintlänge hat das Team Erfahrungswerte und kann beurteilen, wie viele Story Points pro Sprint insgesamt abgearbeitet werden können.

Entsprechend der Priorisierung der Storys durch den Product Owner werden im Sprint die Storys abgearbeitet. Das Team legt sich am Anfang des Sprints darauf fest, eine bestimmte Anzahl von Story Points und Storys beim Product Owner abzuliefern. Durch die Priorisierung wird sichergestellt, dass der Product Owner am Ende des Sprints in jedem Fall die für ihn wichtigen Storys erhält.

Kanban

Im Gegensatz zu Scrum ist Kanban kein ausschließliches Projektmanagementframework, sondern kann seine Stärken im gesamten Unternehmen ausspielen und Prozesse entlang der Wertschöpfungskette verbessern. Kanban kann als Kombination aus Projektmanagement- und Change-Management-Methoden gesehen werden.

Dabei bedingt Kanban keine besonderen Voraussetzungen, die für die Einführung in Unternehmen oder ein Entwicklungsteams nötig sind; vielmehr kann es schrittweise und an relevanten Prozessschritten der Wertschöpfungskette eingeführt werden.

Die Einführung von Kanban in Form eines Change-Management-Prozesses kann einfacher sein als eine Einführung von Scrum, da die Grundprinzipien von Kanban wie folgt umschrieben werden können:

  1. Starte mit dem, was du hast
  2. Verfolge inkrementelle, evolutionäre Veränderung
  3. Respektiere Initialprozesse, Rollen und Verantwortlichkeiten
  4. Fördere Leadership auf allen Ebenen

Durch diese Grundprinzipien ist es nicht nötig, ein Unternehmen bei oder vor der Einführung von A bis Z zu analysieren, die Prozesse aufzunehmen und Verbesserungen für sie insgesamt zu erarbeiten. Ähnlich wie bei Scrum und der inkrementellen Softwareentwicklung arbeitet auch Kanban stufenweise und verbessert unter Zuhilfenahme kurzer Iterationen und dem Einholen von Feedback Schritt für Schritt beliebige Prozesse im Unternehmen.

Kanban zeichnet sich durch verschiedene Kernpraktiken aus.

Das gelingt mit Kanban durch Kernpraktiken wie die Sichtbarmachung und der Limitierung der Arbeit, der Planung des Arbeitsdurchflusses, expliziten Prozessregeln, definierten Feedbackmechanismen und gemeinschaftlichen Verbesserungen.

Das Ziel von Kanban ist es, einen kontinuierlichen Arbeitsfluss im Unternehmen zu etablieren, der dem Kunden einen Mehrwert bietet. Er wird hierbei z. B. mittels Story Cards und Kanban-Board visualisiert. Dadurch wird ersichtlich, wer im Unternehmen mit wem interagieren und kommunizieren muss.

Auch das Pull-Prinzip wird wie im ursprünglichen Kanban angewendet. Es besagt, dass Prozessschritte nicht geschoben, sondern gezogen werden. Somit wird sehr schnell ersichtlich, welcher Prozessschritt zum Flaschenhals in der Wertschöpfungskette wird.

Um diesen Flaschenhals sichtbar zu machen, bedarf es einer Limitierung der Arbeit, dem WiP (Work in Progress). Ein klassisches Kanban-Board könnte wie folgt aus vier Spalten bestehen:

  • Input Queue
  • Entwicklung
  • Test
  • Bereit für Release

Für jede Spalte wird ein WiP (Ausnahme: Bereit für Release) festgelegt, z. B. 4, 2, 2. In der Input Queue dürfen vier Story Cards vorhanden sein, in der Entwicklung und im Test jeweils zwei. Der Flaschenhals wird ersichtlich, sobald ein Team, z. B. die Entwicklung, keine Story Cards mehr ziehen kann, da bereits zwei Karten vorhanden sind, das Testteam es aber nicht schafft, sie per Pull-Prinzip zu ziehen.

Der Prozess muss nun entsprechend verbessert werden, indem dem Testteam mehr Ressourcen zur Verfügung gestellt werden, oder, sofern es keine getrennten Teams gibt, bestehende Story Cards erst getestet werden, bevor neue in die Entwicklung gezogen werden können. Die Befüllung der Input Queue findet in regelmäßigen Abständen statt – z. B. einmal pro Woche am Wochenanfang. Bis zur Befüllung befinden sich die Story Cards, ähnlich wie in Scrum, im (Product) Backlog.

Aufmacherbild: Business card blank von Shutterstock / Urheberrecht: Irina Bg

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -