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\u00e4ngeschild, mit dem sich viele schm\u00fccken wollen, auch wenn die \u00dcbereinstimmung mit der Realit\u00e4t in vielen F\u00e4llen nur teilweise gegeben ist.<\/p>\n\n\n\n\n\n\n\n
Heute werden wir \u00fcber 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\u00fcr jede Art von „Projekt“ geeignet ist. <\/p>\n\n\n\n
In der Tat ist Scrum kein Rahmenwerk f\u00fcr Projekte, sondern f\u00fcr Produkte. Dennoch glauben (oder behaupten zumindest) viele Entwickler, dass sie Scrum anwenden. Warum? Weil das Wort Scrum sexier<\/em> ist als realistischere Alternativen. Aber das werden wir sp\u00e4ter sehen. Lasst uns einen Schritt nach dem anderen machen.<\/p>\n\n\n\n Zun\u00e4chst einmal ist es interessant, sich daran zu erinnern, woher wir kommen. Die traditionelle Softwareentwicklung erfolgte nach der Wasserfallmethode. Kurz und b\u00fcndig l\u00e4sst sie sich wie folgt zusammenfassen: Die Entwicklung ist in mehrere Phasen unterteilt, die nacheinander in einer bestimmten Reihenfolge durchgef\u00fchrt werden:<\/p>\n\n\n\n Diese Methodik hat einen gro\u00dfen Nachteil: Sie ist einseitig. Das Hauptproblem besteht darin, dass die Anforderungen nicht mehr ge\u00e4ndert werden k\u00f6nnen, sobald die Umsetzung begonnen hat. Leider sind in der Software-Welt die Anforderungen nicht von Anfang an v\u00f6llig klar, oder sie m\u00fcssen w\u00e4hrend der Entwicklung ge\u00e4ndert werden, entweder weil der Kunde seine Meinung \u00e4ndert oder weil sich die Bed\u00fcrfnisse ge\u00e4ndert haben. Dies gilt insbesondere f\u00fcr langfristige Projekte.<\/p>\n\n\n\n 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\u00e4t ist einfach begrenzt, was f\u00fcr die Entwicklung eines Softwareprojekts ein Problem darstellen kann.<\/p>\n\n\n\n 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\u00e4higer Teil des Produkts geliefert. Jeder Sprint hat eine Phase der Anforderungsanalyse, des Systementwurfs, der Implementierung, des Testens und der Bereitstellung<\/em>.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\u00e4chstes umgesetzt werden soll. Dies erm\u00f6glicht es, auf m\u00f6gliche Ver\u00e4nderungen auf dem Markt zu reagieren oder einfach im Interesse der Endverbraucher des Produkts zu handeln<\/p>\n\n\n\n Vielleicht ist euch aufgefallen, dass ich bei der Wasserfallentwicklung von Projekt gesprochen habe, w\u00e4hrend ich bei Scrum von Produkt gesprochen habe. Das war kein Zufall.<\/p>\n\n\n\n Die Wasserfallmethodik ist ein Projektmanagementmodell. Ein Projekt hat ein Budget und eine feste Laufzeit. Mit anderen Worten: Wenn ein Projekt durchgef\u00fchrt wird, muss bekannt sein, wie viel es kosten wird und wann es abgeschlossen sein wird.<\/p>\n\n\n\n Mit dem Scrum-Framework wird die Entwicklung eines Produkts gemanagt, und daher gibt es kein Enddatum. Scrum wird f\u00fcr die periodische Produktentwicklung \u00fcber 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\u00e4ngigkeit von den Entscheidungen, die zur Erf\u00fcllung der Marktanforderungen getroffen werden, festgelegt werden. Deshalb ist sie flexibel.<\/p>\n\n\n\n Wenn wir genau gelesen haben, ist die Antwort einfach: Nein. Scrum kann f\u00fcr die Produktentwicklung eingesetzt werden, nicht f\u00fcr ein Projekt (obwohl in den letzten Jahren Scrum-Ans\u00e4tze f\u00fcr Projekte entwickelt wurden). Und in der beratenden Softwareentwicklung gibt es reichlich Projekte.<\/p>\n\n\n\n Aus diesem Grund scheitern Projekte, die im Rahmen von Scrum entwickelt werden, h\u00e4ufig,<\/strong> oder diese Projekte werden tats\u00e4chlich 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 \u00fcberhaupt nicht angewendet werden). Infolgedessen k\u00f6nnen genau deswegen auch die Prinzipien, die Scrum ausmachen, nicht erf\u00fcllt werden.<\/p>\n\n\n\n Pseudo-Scrum<\/strong> ist eine Ann\u00e4hrung der Wasserfall-Entwicklung und Scrum, mit den Vorteilen von beiden. Die Vorsilbe Pseudo<\/em> mag den Eindruck erwecken, dass es sich um eine weniger g\u00fcltige Methode als Scrum handelt, aber das ist nicht so. Manchmal wird auch der Begriff Hybrid<\/em> 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\u00e4hlen, die am besten zu den Bed\u00fcrfnissen 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\u00e4hrleisten.<\/p>\n\n\n\n Zusammenfassend bezeichnen wir ein Framework, das scheinbar Scrum-Merkmale verwendet, aber kein reines Scrum ist, als Pseudo-Scrum-Framework. Im Folgenden erkl\u00e4ren wir, wie wir das bei WATA Factory machen.<\/p>\n\n\n\n Zun\u00e4chst einmal m\u00f6chten wir erw\u00e4hnen, dass wir bei WATA Factory<\/strong> 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\u00e4llen m\u00fcssen 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.<\/p>\n\n\n\n Unser Pseudo-Scrum ist ein Hybrid aus Wasserfallentwicklung und Scrum<\/strong>, die die Vorteile beider Methoden vereint.<\/p>\n\n\n\n Zun\u00e4chst haben wir eine Phase der Anforderungserfassung<\/strong> und -analyse. Anschlie\u00dfend erstellen wir einen interaktiven Prototyp<\/strong>, damit der Kunde sehen kann, wie das Produkt aussehen wird. Zus\u00e4tzlich unterbreiten wir ein Angebot<\/strong>, das die Entwicklungskosten und den Liefertermin enth\u00e4lt, es sei denn, wir k\u00f6nnen gemeinsam mit dem Kunden auf der Grundlage von Stundenbudgets f\u00fcr die kontinuierliche Verbesserung eines bestimmten Produkts arbeiten, wobei wir in diesem Fall reines Scrum<\/em> anwenden w\u00fcrden<\/p>\n\n\n\n Bei der Wasserfallentwicklung h\u00e4tte das technische Team bis zum Liefertermin keinen weiteren Kontakt mit dem Kunden, da alles im Voraus festgelegt w\u00e4re. Doch genau hier kommt Scrum ins Spiel.<\/p>\n\n\n\n Die Umsetzung erfolgt in Produkt-Teilschritten mit voll funktionsf\u00e4higen Lieferungen. Das hei\u00dft, der Kunde k\u00f6nnte die gelieferte Funktionalit\u00e4t bereits nutzen. Dies hat zwei Vorteile. Erstens kann der Kunde Ihr Produkt bereits vor der endg\u00fcltigen Lieferung nutzen. Der zweite ist, dass der Kunde die Funktionalit\u00e4t sehen und testen kann. Nach der Implementierung stellt der Kunde manchmal Verbesserungen in dem entwickelten Teil des Produkts fest. Eine Implementierung mit Pseudo-Scrum<\/em> erlaubt es dem Kunden, die Funktionalit\u00e4ten, die er f\u00fcr angemessen h\u00e4lt, w\u00e4hrend der Entwicklung neu zu definieren<\/p>\n\n\n\n Nat\u00fcrlich m\u00fcssen die \u00c4nderungen in der gleichen Gr\u00f6\u00dfenordnung liegen wie die urspr\u00fcngliche Implementierung, damit der Liefertermin und die Entwicklungskosten eingehalten werden k\u00f6nnen. Alternativ wird dies durch den Verzicht auf andere Funktionen oder deren Vereinfachung kompensiert. Dabei arbeiten wir mit einem priorisierten Backlog<\/em>, in dem der Kunde die Reihenfolge der Umsetzung der Funktionalit\u00e4ten bestimmt.<\/p>\n\n\n\n H\u00e4ufig 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\u00e4ndlich. Wenn Sie Scrum nicht verwenden, sollten Sie nicht predigen, dass Sie es verwenden. Es ist nicht richtig, zu sagen, dass die reine<\/em> Umsetzung die richtige ist und jede andere Option nur ein Versuch der Nachahmung ist Nichts k\u00f6nnte weiter von der Wahrheit entfernt sein.<\/p>\n\n\n\n Wende die Methode an, die f\u00fcr die jeweilige Situation am besten geeignet ist, und verteidige sie mit erhobenem Haupt.<\/p>\n","protected":false},"excerpt":{"rendered":" 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\u00e4ngeschild, mit dem sich viele schm\u00fccken wollen, auch wenn die \u00dcbereinstimmung mit der Realit\u00e4t in vielen F\u00e4llen nur teilweise gegeben ist.<\/p>\n","protected":false},"author":16,"featured_media":15528,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[68,181],"tags":[280,146],"class_list":["post-7156","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-neuigkeiten","category-technologie","tag-pseudo-scrum-de","tag-scrum-de"],"yoast_head":"\nWoher wir kommen: Wasserfall Entwicklung<\/h2>\n\n\n\n
Einf\u00fchrung in Scrum<\/h2>\n\n\n\n
Projekt vs. Produkt<\/h2>\n\n\n\n
Kann ich Scrum in meinem Projekt einsetzen?<\/h2>\n\n\n\n
Pseudo-Scrum bei WATA Factory<\/h2>\n\n\n\n
Nutze Pseudo-Scrum mit Stolz<\/h2>\n\n\n\n