Es besteht kein Zweifel, dass wir in einer vom Marketing dominierten Gesellschaft leben. Es gibt Begriffe und Konzepte, die sich gut verkaufen. Sie fungieren als Aushängeschild, mit dem sich viele schmücken wollen, auch wenn die Übereinstimmung mit der Realität in vielen Fällen nur teilweise gegeben ist.
Heute werden wir über Scrum sprechen, ein Framework, das in aller Munde ist. Es ist agil und modern (wenn auch nicht neu). Und es ist klar, dass agil und modern besser klingt als langsam und altmodisch. Die Wahrheit ist jedoch, dass Scrum zwar Vorteile, aber auch Nachteile hat und nicht für jede Art von „Projekt“ geeignet ist.
In der Tat ist Scrum kein Rahmenwerk für Projekte, sondern für Produkte. Dennoch glauben (oder behaupten zumindest) viele Entwickler, dass sie Scrum anwenden. Warum? Weil das Wort Scrum sexier ist als realistischere Alternativen. Aber das werden wir später sehen. Lasst uns einen Schritt nach dem anderen machen.
Woher wir kommen: Wasserfall Entwicklung
Zunächst einmal ist es interessant, sich daran zu erinnern, woher wir kommen. Die traditionelle Softwareentwicklung erfolgte nach der Wasserfallmethode. Kurz und bündig lässt sie sich wie folgt zusammenfassen: Die Entwicklung ist in mehrere Phasen unterteilt, die nacheinander in einer bestimmten Reihenfolge durchgeführt werden:
- Analyse der Anforderungen
- Entwurf des Systems
- Umsetzung
- Prüfung
- Bereitstellung
Diese Methodik hat einen großen Nachteil: Sie ist einseitig. Das Hauptproblem besteht darin, dass die Anforderungen nicht mehr geändert werden können, sobald die Umsetzung begonnen hat. Leider sind in der Software-Welt die Anforderungen nicht von Anfang an völlig klar, oder sie müssen während der Entwicklung geändert werden, entweder weil der Kunde seine Meinung ändert oder weil sich die Bedürfnisse geändert haben. Dies gilt insbesondere für langfristige Projekte.
Ist die Wasserfallentwicklung also eine schlechte Methode? Ganz und gar nicht. Es handelt sich einfach um eine Arbeitsmethodik, die bei Projekten, bei denen alle Informationen von Anfang an festgelegt sind, gut funktioniert. Es gibt viele Branchen, in denen die Wasserfallentwicklung erfolgreich eingesetzt wird. Die Flexibilität ist einfach begrenzt, was für die Entwicklung eines Softwareprojekts ein Problem darstellen kann.
Einführung in Scrum
Scrum ist ein agiles Framework, das auf der Bereitstellung von Teilschritten in Arbeitszyklen basiert, die Sprints genannt werden. In jedem Sprint wird ein voll funktionsfähiger Teil des Produkts geliefert. Jeder Sprint hat eine Phase der Anforderungsanalyse, des Systementwurfs, der Implementierung, des Testens und der Bereitstellung.Einer der Vorteile dieses Frameworks ist, dass die Anforderungen vor jedem Sprint definiert (oder zumindest diskutiert) werden. Daher legt das Team in jedem Sprint fest, was als nächstes umgesetzt werden soll. Dies ermöglicht es, auf mögliche Veränderungen auf dem Markt zu reagieren oder einfach im Interesse der Endverbraucher des Produkts zu handeln
Projekt vs. Produkt
Vielleicht ist euch aufgefallen, dass ich bei der Wasserfallentwicklung von Projekt gesprochen habe, während ich bei Scrum von Produkt gesprochen habe. Das war kein Zufall.
Die Wasserfallmethodik ist ein Projektmanagementmodell. Ein Projekt hat ein Budget und eine feste Laufzeit. Mit anderen Worten: Wenn ein Projekt durchgeführt wird, muss bekannt sein, wie viel es kosten wird und wann es abgeschlossen sein wird.
Mit dem Scrum-Framework wird die Entwicklung eines Produkts gemanagt, und daher gibt es kein Enddatum. Scrum wird für die periodische Produktentwicklung über einen unbestimmten Zeitraum hinweg eingesetzt. Zu Beginn der Entwicklung ist das Endergebnis noch nicht bekannt, da die zu implementierenden Funktionen im Laufe der Produktentwicklung und in Abhängigkeit von den Entscheidungen, die zur Erfüllung der Marktanforderungen getroffen werden, festgelegt werden. Deshalb ist sie flexibel.
Kann ich Scrum in meinem Projekt einsetzen?
Wenn wir genau gelesen haben, ist die Antwort einfach: Nein. Scrum kann für die Produktentwicklung eingesetzt werden, nicht für ein Projekt (obwohl in den letzten Jahren Scrum-Ansätze für Projekte entwickelt wurden). Und in der beratenden Softwareentwicklung gibt es reichlich Projekte.
Aus diesem Grund scheitern Projekte, die im Rahmen von Scrum entwickelt werden, häufig, oder diese Projekte werden tatsächlich mit einer Methodik entwickelt, die an Scrum erinnert, aber nicht wirklich Scrum ist, da das Framework nicht richtig angewendet wird (in einem Projekt kann es sogar überhaupt nicht angewendet werden). Infolgedessen können genau deswegen auch die Prinzipien, die Scrum ausmachen, nicht erfüllt werden.
Pseudo-Scrum ist eine Annährung der Wasserfall-Entwicklung und Scrum, mit den Vorteilen von beiden. Die Vorsilbe Pseudo mag den Eindruck erwecken, dass es sich um eine weniger gültige Methode als Scrum handelt, aber das ist nicht so. Manchmal wird auch der Begriff Hybrid verwendet, was besser klingt. Aber es kommt nicht darauf an, wie wir es nennen, sondern auf die Methodik selbst. Es ist wichtig, die Arbeitsmethode zu wählen, die am besten zu den Bedürfnissen passt, und sich nicht danach zu richten, was gerade in Mode ist oder gut klingt. Oberstes Ziel ist es, den Erfolg des Projekts oder Produkts und die Zufriedenheit sowohl des Kunden als auch des intern arbeitenden Teams zu gewährleisten.
Zusammenfassend bezeichnen wir ein Framework, das scheinbar Scrum-Merkmale verwendet, aber kein reines Scrum ist, als Pseudo-Scrum-Framework. Im Folgenden erklären wir, wie wir das bei WATA Factory machen.
Pseudo-Scrum bei WATA Factory
Zunächst einmal möchten wir erwähnen, dass wir bei WATA Factory die Arbeitsmethode anwenden, die am besten zum jeweiligen Projekt passt. Bei der Entwicklung einiger Produkte verwenden wir Scrum, aber dieses Framework ist im Allgemeinen nicht an die Anforderungen unserer Kunden angepasst. In den meisten Fällen müssen die Kunden wissen, was sie erhalten werden, wie viel die Entwicklung kosten wird und wann die Lieferung erfolgen wird. Dies ist per Definition unvereinbar mit Scrum.
Unser Pseudo-Scrum ist ein Hybrid aus Wasserfallentwicklung und Scrum, die die Vorteile beider Methoden vereint.
Zunächst haben wir eine Phase der Anforderungserfassung und -analyse. Anschließend erstellen wir einen interaktiven Prototyp, damit der Kunde sehen kann, wie das Produkt aussehen wird. Zusätzlich unterbreiten wir ein Angebot, das die Entwicklungskosten und den Liefertermin enthält, es sei denn, wir können gemeinsam mit dem Kunden auf der Grundlage von Stundenbudgets für die kontinuierliche Verbesserung eines bestimmten Produkts arbeiten, wobei wir in diesem Fall reines Scrum anwenden würden
Bei der Wasserfallentwicklung hätte das technische Team bis zum Liefertermin keinen weiteren Kontakt mit dem Kunden, da alles im Voraus festgelegt wäre. Doch genau hier kommt Scrum ins Spiel.
Die Umsetzung erfolgt in Produkt-Teilschritten mit voll funktionsfähigen Lieferungen. Das heißt, der Kunde könnte die gelieferte Funktionalität bereits nutzen. Dies hat zwei Vorteile. Erstens kann der Kunde Ihr Produkt bereits vor der endgültigen Lieferung nutzen. Der zweite ist, dass der Kunde die Funktionalität sehen und testen kann. Nach der Implementierung stellt der Kunde manchmal Verbesserungen in dem entwickelten Teil des Produkts fest. Eine Implementierung mit Pseudo-Scrum erlaubt es dem Kunden, die Funktionalitäten, die er für angemessen hält, während der Entwicklung neu zu definieren
Natürlich müssen die Änderungen in der gleichen Größenordnung liegen wie die ursprüngliche Implementierung, damit der Liefertermin und die Entwicklungskosten eingehalten werden können. Alternativ wird dies durch den Verzicht auf andere Funktionen oder deren Vereinfachung kompensiert. Dabei arbeiten wir mit einem priorisierten Backlog, in dem der Kunde die Reihenfolge der Umsetzung der Funktionalitäten bestimmt.
Nutze Pseudo-Scrum mit Stolz
Häufig werden Arbeitsweisen kritisiert, die an Scrum erinnern oder vorgeben, Scrum zu sein, sich aber in Wirklichkeit nicht getreu an das Framework halten. Zum Teil ist dies verständlich. Wenn Sie Scrum nicht verwenden, sollten Sie nicht predigen, dass Sie es verwenden. Es ist nicht richtig, zu sagen, dass die reine Umsetzung die richtige ist und jede andere Option nur ein Versuch der Nachahmung ist Nichts könnte weiter von der Wahrheit entfernt sein.
Wende die Methode an, die für die jeweilige Situation am besten geeignet ist, und verteidige sie mit erhobenem Haupt.
