schneller, besser, flexibler, kostengünstiger?
Als IT Consultant – insbesondere im Umfeld der ServiceNow Implementierung – stellen wir in den letzten Jahren fest, dass so gut wie alle unsere Kunden auf den Agile-Development Zug aufspringen. Nicht alle landen sanft oder genau auf dem Waggon, den sie erreichen wollten.
Wir möchten hier einige Erfahrungen aus unseren Tätigkeiten in verschiedenen Projekten darstellen.
Scrum Meeting
Beim erstmaligen Start eines agilen Projektes erleben wir immer wieder, dass die Projektmitgliedern oft nicht in dieser Projektmethode ausgebildet sind. Die meisten haben nur gehört, dass es tägliche Scrum Meetings gibt. Die weiteren Elemente sind oft nicht bekannt.
Kommunikation ist essentiell für das Gelingen (nicht nur) eines agilen Projektes. Nur wenn diese aufrechterhalten wird und in vernünftigen Bahnen läuft, kann das Projekt einen erfolgreichen Abschluss finden. Die Scrum-Methode fordert ein tägliches, kurzes Meeting, in dem jeder berichtet, was er am vergangenen Tag erreicht hat, was er für diesen Tag plant und ob er durch etwas behindert wird.
In meinem letzten Projekt wurden zu diesem Treffen auch einige Stakeholder eingeladen und ein Timeslot an das Meeting gehängt, in dem mit Hilfe der Stakeholder Detailfragen zu den Stories geklärt und sonstige Hindernisse aus dem Weg geräumt werden konnten. Dies geschah nicht mit der gesamten Runde, sondern nur zwischen dem verantwortlichen Mitglied des Scrumteams und dem Stakeholder der Story. In diesem Fall handelte es sich um ein weltweit verteiltes Projekt, das durch die unterschiedlichen Lokationen und Zeitzonen besondere Kommunikationsprobleme aufwirft. In diesem verteilten Projektumfeld hat sich die Methode sehr bewährt.
Anforderungen – Story
Agile Entwicklung bedeutet nicht, dass Anforderungen „mal eben schnell über den Zaun geworfen“ werden können. Das Ziel des Projektes sollte zu Beginn des Projektes definiert werden und Anforderungen nicht zum „moving target“ werden. Auch ein agiles Entwicklungsteam benötigt Zeit, Anforderungen zu verstehen und insbesondere zu implementieren. Wir haben Stories gesehen, die beschrieben, wie etwas implementiert werden soll, aber nicht die eigentliche Anforderung, was deren Zweck ist und wer die Funktion nutzen soll. Dies führte zu Kollisionen mit anderen Anforderungen oder unerwünschten Ergebnissen. Dem Scrum-Team sollte die Freiheit gelassen werden, eine Anforderung sinnvoll zu implementieren. Dabei hilft es, sich an die Regeln zu halten, wie Stories geschrieben werden sollten. Wie zum Beispiel die Rolle zu benennen, die die Funktion nutzen möchte (… als User möchte ich …) und welche Funktionalität (oder Layout oder…) erwartet wird.
Es ist für alle Beteiligten einfacher, die Implementierung zu verifizieren, wenn die Akzeptanzkriterien angegeben werden. Oft findet der Entwickler in den Akzeptanzkriterien weitere wichtige Detailinformationen für die geforderte Funktionalität. Die Definition dieser Kriterien erleichtert selbstredend auch die Erstellung von Testcases.
In einem großen Projekt kann es hilfreich sein, den Stories Themen zuzuordnen, um darzustellen, welche Stories thematisch zusammengehören. Größere Anforderungsblöcke lassen sich in einem Epic beschreiben, das für die Implementierung in Sprint-taugliche Stories unterteilt wird.
Status
Auch bei einem agilen Projekt möchten Teammitglieder und Management über den Fertigstellungsgrad des Projektes informiert sein. Dies gelingt nur, wenn das Backlog, der Status von Stories und die Zuordnung von Stories zu Themen und Entwicklungsteams konsequent und möglichst an einer Stelle gepflegt wird.
In einem Kundenprojekt wurde die Zuordnung zu Themen und Teams und der Status sehr unterschiedlich gepflegt. Die Dokumentation war – soweit überhaupt vorhanden – in verschiedenen Tools über die Sharepoints verschiedener Firmen verteilt. Damit wurde die Erstellung eines regelmäßigen Statusreports zur Sisyphusarbeit und ein aussagekräftiger, verlässlicher Statusreport konnte nicht erstellt werden.
ServiceNow bietet in seinem Agile Development Modul die besten Voraussetzungen, den Überblick zu behalten, ohne EXCEL oder ähnliche Hilfsmittel einzusetzen. Mit Hilfe dieses Moduls und des ServiceNow Reportings lässt sich bei konsequenter Dokumentation jederzeit der aktuelle Status feststellen, sowie wunderbar der nächste Sprint planen.
Retrospektive
Auf die regelmäßige Retrospektive sollte nicht verzichtet werden. Der große Benefit der agilen Vorgehensweise ist die Flexibilität. Diese lässt sich am sinnvollsten nutzen, wenn aus Fehlern gelernt wird. Am besten gelingt dies, wenn Fehler nicht als Versagen, sondern als Chance für eine Verbesserung begriffen werden. Im Gegensatz zum Sprint-Review, in dem die implementierte Funktionalität vorgestellt und abgenommen wird, wird in der Retrospektive der Sprint selbst analysiert und Verbesserungsmöglichkeiten besprochen. Dadurch kann auch der Softwareentwicklungsprozess selbst kontinuierlich verbessert werden.
Testen
Agiles Projektmanagement – das klingt lässig. Es sollte aber nicht darüber hinwegtäuschen, dass die in diesem Rahmen erstellte Software ebenso Fehler enthalten kann und getestet werden muss.
In einem kleinen Projekt mit einem Team und einem Product Owner lässt sich der Test am Ende eines Sprints gut organisieren.
In einem unserer großen Projekte waren die Aufgaben auf mehrere Entwicklungsteams verteilt. Jedes Team implementierte Funktionsbereiche unabhängig voneinander. Dies hat zu neuen Problemen geführt. Es gab für fast jeden Funktionsbereich einen separaten Product Owner. Diese waren für diese Rolle sehr unterschiedlich geschult und motiviert. Insbesondere für den Test fehlte die Motivation.
Unsere ausdrückliche Empfehlung lautet, die Erstellung von Testcases und das regelmäßige Testen frühzeitig einzuplanen. Regressionstests sollten auf jeden Fall definiert werden. ServiceNow bietet mit ATF eine Möglichkeit, diese zu automatisieren.
Ist agile Softwareentwicklung schneller, besser, flexibler, kostengünstiger?
Kommt darauf an!
Schneller und kostengünstiger: Durch stetige Kommunikation und Überprüfung kleinerer Funktionseinheiten kann die Schere zwischen Anforderung und Implementierung nicht so weit auseinander laufen. Differenzen werden schneller erkannt und können beseitigt werden.
Besser und flexibler: Durch die Flexibilität der agilen Projekte kann das Ergebnis besser werden, da es leichter ist, die Anforderungen neuen Erkenntnissen anzupassen als zum Beispiel in der klassischen Wasserfallmethode.
