Original-URL des Artikels: https://www.golem.de/news/softwareentwicklung-agiles-arbeiten-ein-fallbeispiel-1901-138483.html    Veröffentlicht: 14.01.2019 09:09    Kurz-URL: https://glm.io/138483

Softwareentwicklung

Agiles Arbeiten - ein Fallbeispiel

Kennen Sie Iterationen? Es klingt wie Irritationen - und genau die löst das Wort bei vielen Menschen aus, die über agiles Arbeiten lesen. Golem.de erklärt die Fachsprache und zeigt Agilität an einem konkreten Praxisbeispiel für eine agile Softwareentwicklung.

Praxisnähe ist tatsächlich das, was agile Arbeitsweisen vor allem ausmacht. Im Kern geht es darum, sich einem Ziel durch wiederholende Entwicklungsperioden Stück für Stück bis zum Erreichen zu nähern. Die agile Entwicklung startet bei der groben Beschreibung des Ziels und passt sich im Verlauf des Prozesses immer weiter an. Trotzdem muss es von Anfang an ein klar vereinbartes Endergebnis geben. Sonst laufen auch agile Projekte Gefahr, nie zu enden und zu finanziellen Desastern zu werden. Wir zeigen die Vorgehensweise an einem Fallbeispiel.

Ein Kunde aus dem Bereich Personalmanagement beauftragt die Entwicklung einer Mitarbeiter- und Freelancer-Datenbank. Das grobe Ziel ist es, ein gut zu benutzendes Verzeichnis mit Kontaktkarten von Personen und möglichst vielen beruflichen Informationen zu diesen Personen zu erstellen. Die dort gesammelten Mitarbeiter und Freelancer können einer Erfassung ihrer Daten in diesem Netzwerk zustimmen und auch selbst Daten übermitteln, um beispielsweise für neue Projekte angefragt zu werden und um Talente zu fördern, die anderen Teams womöglich unbekannt sind. Es kann zum Beispiel vorkommen, dass Unternehmen nicht das komplette Potenzial ihrer Mitarbeiter kennen, also nicht wissen, welche Fähigkeiten, über die nie gesprochen wird sie noch haben. Diese Fähigkeiten können als Talente von den Usern selbst erfasst werden. Durch diese Daten können crossfunktionale Teams zusammengestellt und Mitarbeiter und Freelancer zu bestimmten Aufgaben angefragt werden.

Außerdem soll die Datenbank dazu genutzt werden, Kontaktpflege zu betreiben, Notizen zu hinterlegen und Erinnerungen wie Geburtstage einzustellen. Auch soll es möglich sein, Dateien wie Lebensläufe oder Zeugnisse an einer Kontaktkarte einer Person abzulegen wie in einem Cloud-Speicher. Als Design wurde vom Entwicklungsteam das von Google bekannte Material-Design vorgeschlagen und vom Kunden ausgewählt. Die bekannten Icons und das kachelartige Design erinnern an moderne Webanwendungen oder Android. Kompatibel sollte die Datenbank mit allen gängigen und natürlich mit mobilen Browsern sein.

Der agile Start ist grob

Bei der klassischen Arbeitsweise werden nach der grundlegenden Klärung des Projektes die Pflichten- und Lastenhefte geschrieben. Designs, Wireframes und Mockups werden ausgetauscht, jede Funktion wird bis ins Detail beschrieben. Das ist meist alles sehr theoretisch, es bedarf einer Menge Vorstellungskraft, bis überhaupt die erste Codezeile geschrieben wird.

Nicht so bei der agilen Entwicklung. Hier geht es mit der Teamzusammenstellung los. In unserem Fall besteht das Team aus drei Entwicklern (Front-End und Back-End), einem Projektmanager, einem Scrum Master und einem Product Owner. Die legen auch gleich mit dem Erstellen des sogenannten Backlogs los.

Das Backlog kann als Sammelbecken der Anforderungen und Funktionen verstanden werden. Diese werden zunächst grob beschrieben. Jede Funktion wird in einem gesonderten Backlog-Eintrag aufgeschrieben. Das sind in unserem Fall zum Beispiel:



Sind die Funktionen grob beschrieben, entscheidet das Entwicklungsteam, dass die erste Version der Mitarbeiter- und Freelancer-Datenbank erzeugt werden kann. Dazu werden die Tickets, also die einzelnen Items aus dem Backlog, sortiert und priorisiert und es wird ein erster Sprint, also eine erste Entwicklungsperiode, gebaut. Dabei wird gemeinsam entschieden, welche Aufgaben ausreichend definiert sind, um in den Sprint aufgenommen zu werden. Für den Sprint wird - ebenfalls gemeinsam - ein Sprintziel definiert, das den Umfang der Aufgaben im Sprint gut beschreibt.

In unserem Fall ist das erste Sprintziel das Fertigstellen eines benutzbaren Klickdummys, also einer sehr groben Online-Version der Datenbank. Es sollten jedoch schon einzelne Karten für Personen angelegt werden und es sollte ebenfalls schon möglich sein, die ersten Daten zu den Personen zu erfassen. Somit kann parallel zur Entwicklung schon mit dem Aufbau von Personendaten begonnen und es kann getestet werden. Die Entwicklung startet also in einer sehr frühen Phase mit der Definition und Ausarbeitung der Details.

Tägliche Meetings und Soll-Ist-Abgleich

Im Entwicklungsprozess arbeitet das Team eigenständig. Ein Sprint dauert in der Regel zwischen zwei und vier Wochen. Während das Team die ersten Aufgaben abarbeitet, werden im Backlog die nächsten Aufgaben vom Projektmanager und dem Product Owner verfeinert und bestehende ergänzt. So werden zum Beispiel die Icons und Symbole aus dem Material Design ausgewählt und ihren jeweiligen Buttons und Funktionen zugeordnet.

Außerdem organisiert der Scrum Master mit dem Entwicklungsteam die tägliche Arbeit am Sprint. Die Aufgabe des Scrum Masters ist es, dem Entwicklungsteam einen möglichst reibungslosen Ablauf zu ermöglichen. Dafür organisiert er die täglichen Meetings, versucht Konflikte zu lösen und Probleme für das Team zu klären. Alle Teammitglieder können also Probleme, die sie bei der Arbeit aktuell behindern, an den Scrum Master herantragen. Er ist deshalb nicht nur Organisator, sondern auch Konfliktlöser, Coach, Trainer und Zuhörer in einer Person.

Der Product Owner steht als Eigentümer des Backlogs für Rückfragen zur Verfügung, während er gleichzeitig an neuen Aufgaben und User-Stories schreibt und mit den Auftraggebern spricht. User-Stories sind kurze Software-Anforderungen, die aus der Benutzersicht verfasst sind, so dass sich zum Beispiel ein Entwickler schnell in die Rolle des Benutzers hineindenken kann, um die Aufgabe bestmöglich für ihn zu lösen. Im sogenannten Daily Scrum, einem täglichen kurzen Meeting, das vom Scrum Master organisiert wird, werden die wichtigsten aktuellen Schritte besprochen, Probleme (fachsprachlich: Impediments) angesprochen und aus dem Weg geräumt. In unserem konkreten Fallbeispiel der Datenbank für Mitarbeiter und Freelancer wird das Entwicklungsteam mit direkten Nachfragen des Kunden bei der Arbeit unterbrochen. Das sind Fragen wie: "Wann können wir mit den neuen Icons rechnen? Wie lange dauert euer Sprint noch? Könnt ihr in euren aktuellen Sprint bitte noch eine Sache mit aufnehmen?"

Eigentlich sollte das Entwicklungsteam von solchen Fragen unbehelligt bleiben. Deswegen übernimmt der Scrum Master die Moderatorenrolle und federt die dringenden Anfragen von außen für das Team ab. Dadurch kann die Konzentration gehalten werden und eine produktive Arbeitsatmosphäre wird geschaffen.

Der Unterschied zwischen einem klassischen Teamleiter und einem Scrum Master ist, dass der Scrum Master vom Team selbst gewählt wird und keine personellen Befugnisse über die Teammitglieder hat. Deshalb gilt er mehr als Vertrauensperson und nicht als Vorgesetzter. Jeder kennt es, dass man einer vertrauten Person eher von seinen aktuellen Problemen im Team erzählt als einem Vorgesetzten. Aus diesem Grund ist der Scrum Master in der agilen Entwicklung eine entscheidende Position.

Der erste Sprint, das erste Produkt und die Retrospektive

Ist der Sprint beendet, folgt die sogenannte Retrospektive. In diesem Meeting können alle über die vergangene Entwicklungsperiode sprechen, Verbesserungsvorschläge für die nächste machen und ihre persönliche Empfindung zum Ausdruck bringen.

Im Fall der Mitarbeiter- und Freelancer-Datenbank ist das Resümee des ersten Sprints in der ersten Retrospektive positiv. Es wird zum Beispiel angemerkt, dass die Aufgaben für einen ersten Sprint schon ganz gut durchdacht und definiert gewesen seien und dieses Niveau gehalten und weiter verbessert werden solle. Kritisch gesehen werden die schon genannten Einwürfe von außen, denn das Entwicklungsteam wird sehr oft auf dem Flur oder per Telefon von Angestellten des Kunden befragt, da dieser im gleichen Haus sitzt.

Als konkrete Maßnahme überlegen wir uns, an alle eine Meldung zu versenden, dass das Entwicklungsteam während des aktiven Sprints "on air" sei und daher keine direkten Nachfragen gestattet seien, sondern über den Scrum Master oder Product Owner laufen müssen. Eine Retrospektive sollte nie ohne konkrete Arbeitsschritte etwa zur Verbesserung der Atmosphäre, der Produktivität oder des Sprint-Umfangs verlassen werden.

Nach dem ersten Sprint ist der erste Klickdummy bereit, also ein benutzbares, wenn auch rudimentäres Produkt, mit sehr wenigen Funktionen, das der Kunde aber immerhin schon verwenden kann. Es ist ein einfaches Online-Verzeichnis, in dem man Karten von Personen anlegen und die ersten Informationen, wie Telefonnummer und E-Mail-Adresse, bereits erfassen kann. Die Anwendung wird in diesem Schritt aus Sicherheitsgründen noch lokal betrieben, gibt aber schon ein erstes Gefühl für die Bedienbarkeit. Die Rückmeldung vom Kunden ist positiv. Vor allem, dass es nach so kurzer Zeit bereits etwas zum Ausprobieren gibt, überzeugt. Der nächste Sprint kann geplant werden.

Sprinten bis zum Ziel

Bei unserem Beispielprojekt werden insgesamt acht Sprints durchgeführt, an deren Ende eine funktionierende Mitarbeiter- und Freelancer-Datenbank in einem ansprechenden Design steht. Nach jedem Sprint wird der Zwischenstand dem Kunden präsentiert, der sein Projekt stetig wachsen sehen kann.

Während der Arbeit fällt einem Entwickler auf, dass man das Netzwerk Xing mit einer API-Schnittstelle anbinden könnte, um öffentliche Informationen von Profilen der Plattform direkt in die Datenbank zu übertragen. Dem Kunden wird diese Möglichkeit vorgestellt und es wird sogar noch etwas mehr Budget zur Verfügung gestellt, um dies zu realisieren. Durch die agile Arbeitsweise kann die neue Anforderung während der Entwicklung aufgenommen, definiert und in einem Sprint umgesetzt werden.

Dieses Beispiel zeigt besonders gut die Vorteile von agiler Entwicklung. An erster Stelle steht die Kundenzufriedenheit. Denn durch die aktive Einbindung des Kunden, indem er nach jedem Sprint eine funktionsfähige Vorabversion sehen und testen, Feedback geben und Wünsche äußern kann, fühlt er sich bestätigt und verstanden.

Als zweiter Punkt ist die selbstständige Arbeitsweise der Teams zu nennen, die ihre Arbeitspakete in den Sprints selbst schnüren und umsetzen können. So ist es unter anderem möglich, sich auf Änderungen und Anpassungen wie die Xing-API einzustellen und diese umzusetzen, um damit eine maximale Flexibilität trotz des festgesetzten Projektrahmens zu erhalten.

Neben allen positiven Punkten muss aber auch gesagt werden, dass einige agile Projekte in einem derartigen Unwissen gestartet werden, dass finanzielle Mittel während des Projekts ausgehen können oder eine Software so lange weiter wächst, dass der Prozess der Entwicklung nie abgeschlossen werden kann ("und diese Funktion noch… und diese Funktion noch…"). Es gibt also auch Risiken. Die Arbeit ist zudem herausfordernd, denn tägliche Meetings und Besprechungen, wie man den Arbeitsablauf verbessern und optimieren könnte, sagen nicht jedem zu.

Das ständige Überprüfen der eigenen Arbeit und der verfügbaren Zeit im Hinblick auf die Ziele (Sprintziele, generelle Ziele, finanzielle Ziele) kann auch anstrengend sein. Aus diesem Grund braucht es neben Entwicklern auch Scrum Master, Product Owner und finanziell Verantwortliche, die den agilen Prinzipien folgen. Funktioniert dieses Team und werden Probleme und Hindernisse offen kommuniziert, ist die agile Arbeitsweise für alle Beteiligten und vor allem für die Kunden ein Zugewinn, die in agilen Projekten nachweislich zufriedener sind.

Die Datenbank für Mitarbeiter und Freelancer ist schon vor einiger Zeit entwickelt worden und bis heute im Einsatz. Immer wieder werden Erweiterungspakete vereinbart, um die Entwicklung in kleineren Schritten voranzubringen, das Design zeitgemäß anzupassen oder neue Funktionen einzubauen - für mich ist das ein Paradebeispiel für agile Softwareentwicklung.  (mae)


Verwandte Artikel:
Change-Management: Was Unternehmen falsch machen, wenn sie agil sein wollen   
(11.02.2019, https://glm.io/138864 )
Enterprise Resource Planning: Drei Gründe für das Scheitern von SAP-Projekten   
(05.02.2019, https://glm.io/139065 )
Agilität: Wenn alle bestimmen, wo es langgeht   
(29.10.2018, https://glm.io/137206 )
IT-Jobs: Achtung! Agiler Coach gesucht?   
(07.08.2018, https://glm.io/135524 )

© 1997–2019 Golem.de, https://www.golem.de/