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:

1. Analyse der Anforderungen
2. Entwurf des Systems
3. Umsetzung
4. Prüfung
5. 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.

The post Pseudo-Scrum, unser eigenes angepasstes Framework bei WATA Factory appeared first on WATA Factory.

Es handelt sich um ein Verfahren mit einem Zeitrahmen (Time Box), bei dem unter allen Teammitgliedern (auch dem Scrum Master), basierend auf einem definierten Ziel, entschieden wird, WAS durchgeführt und WIE es durchgeführt wird.

In diesem Artikel werden wir uns auf das „WIE“ konzentrieren. In dem vorgegebenen Zeitrahmen sollte das Entwickler-Team die Entscheidung treffen, ob ein Hauptthema in kleine Aufgaben aufgeteilt werden soll. Das bedeutet, die Arbeit soll so organisiert werden, dass eine Erreichung der Ziele am Ende des Sprints sichergestellt ist.

Unser Team arbeitet nach den Prinzipien der eXtreme-Programmierung, wie CI/CD, TDD, Pair Programming, Automation und Devops (als Einstellung).

Unter Berücksichtigung dieser Prinzipien haben wir einige Regeln definiert, die uns bei der Durchführung der Arbeitsteilung helfen. Diese Regeln sind:

• Wir definieren einzelne Aufgaben auf der Grundlage der Definition Of Done (DoD). Hierzu spezifizieren wir das DoD auf der Ebene der Themen in technische Aufgaben und nicht-technische Aufgaben. Diese Vorgehensweise hilft uns zu erkennen, wann eine Aufgabe wirklich als Done gekennzeichnet werden kann.

• Wir machen Pausen, wenn sich jemand ausruhen muss. Dies ist wichtig, denn obwohl der Scrum-Guide Pausen als Time-Box-Event definiert (maximal eine Stunde für Sprints mit der Dauer von einem Monat), ziehen wir es vor, nicht den Druck einer Time Box zu haben. Unsere Planung (einschließlich der Auftragsvergabe) wird also so lange dauern, wie es sein muss. Um die Qualität nicht zu mindern, ist es notwendig Pausen zwischen den einzelnen Aufgaben zu machen.

• Wir definieren die Aufgaben auch auf der Grundlage des folgenden Zeitrahmens: an einem Arbeitstag muss das Pensum erledigt, also in Done, sein. Dies mag etwas aggressiv erscheinen, aber wir tun dies aus mehreren Gründen:
  • Es hilft uns, Abweichungen zu erkennen
  • Wenn eine Aufgabe mehr als einen Tag dauert, um ins Done überzugehen, wenden wir Pair Programming an (falls wir es nicht schon nutzen) oder unterteilen sie in eine andere Aufgabe.
  • Wir vermeiden Engpässe: kurze Aufgaben implizieren kurze Überprüfungen. Wenn sie mit Pair Programming und TDD durchgeführt werden, ist es außerdem nicht notwendig, eine Pull-Anfrage (pull request) zu stellen (trunk based development).
  • Wir verlieren den Fokus nicht aus den Augen, entweder indem wir einen Edge Case detailliert darlegen, welchen wir bei der Umsetzung testen müssen, oder indem wir den Fokus auf einen Refaktor legen, der die technische Verschuldung bereinigt.
  • Es entstehen weniger Blocks und Konflikte wenn mehrere Entwickler auf demselben Branch arbeiten. Die Änderungen kommen dadurch schnell auf dem Master Branch an und werden schnell in live/staging deployed.

• Bei der Definition von Aufgaben stützen wir uns auch auf den Quellcode, mit dieser Praxis sammeln wir Erfahrungen, wie wir an die Lösung herangehen können.

• Wenn es sich um ein Thema handelt, bei dem keine Vorerfahrung vorhanden ist, beziehen wir erfahrene Dritte in die Planung mit ein, um dem Team zu helfen und es zu beraten.

• Die sehr komplizierten Aufgaben werden als „Pairing mandatory“ gekennzeichnet.

Wir haben natürlich keine Kristallkugel, um zu sehen, ob die definierten Aufgaben ausreichen oder eventuell zu viele sein werden. Besonders in den ersten Wochen, wenn ein Scrum-Team mit der Arbeit beginnt, kann dies passieren. Wir lernen jedoch aus jedem Sprint, und die hier genannten Regeln helfen uns, immer mehr erfolgreiche Sprints zu erzielen.

The post Scrum Planning: die Bedeutung einer guten Aufgabenteilung appeared first on WATA Factory.