{"id":247,"date":"2022-01-25T10:25:00","date_gmt":"2022-01-25T10:25:00","guid":{"rendered":"https:\/\/www.cybermedian.com\/de\/?p=247"},"modified":"2022-03-24T09:18:49","modified_gmt":"2022-03-24T01:18:49","slug":"why-scrum-defined-process-vs-empirical-process","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/de\/why-scrum-defined-process-vs-empirical-process\/","title":{"rendered":"Warum Scrum: Definierter Prozess vs. empirischer Prozess"},"content":{"rendered":"

Es gibt Projekte, die ziemlich geradlinig und relativ vorhersehbar sind und bei denen rationale Planungs- und Entscheidungswerkzeuge angewendet werden k\u00f6nnen.\u00a0Andere Projekte, die komplexer oder unvorhersehbarer sind, erfordern einen anderen Ansatz, der mehr auf Selbstorganisation und Innovation setzt.<\/span><\/p>\n

Die meisten Softwareentwicklungsprojekte gelten aufgrund der Konvergenz von drei Faktoren als komplex und unvorhersehbar: Menschen, Anforderungen und Technologie.\u00a0Die verschiedenen Ans\u00e4tze zur Durchf\u00fchrung und Verwaltung von Projekten k\u00f6nnten im Kontext von Prozesssteuerungsmodellen und Projektkomplexit\u00e4t leichter verstanden werden.<\/span><\/p>\n

Prozesssteuerungstypen<\/span><\/figcaption><\/figure>\n

Definierter Prozess \u2013 Ein traditioneller plangesteuerter Ansatz<\/span><\/strong><\/p>\n

Traditionell wird zu Beginn eines Projekts ein Anforderungspaket erstellt und dann \u201eabgezeichnet\u201c.\u00a0Der Projektleiter geht davon aus, dass diese Freigabe zu einem festen Anforderungskatalog f\u00fchrt und nun mit der Planung begonnen werden kann.\u00a0Der Projektleiter sch\u00e4tzt, wie lange es dauern wird, die Anforderungen zu erf\u00fcllen, und erstellt den Projektplan.\u00a0Der Plan sieht vor, dass das Projekt bis zu einem bestimmten Datum abgeschlossen sein wird, und dieses Datum wird dem Kunden mitgeteilt.<\/span><\/p>\n

Der grundlegende Fehler bei diesem Ansatz besteht darin, dass der Plan, der alles vorantreibt, auf der Annahme basiert, dass die Anforderungen feststehen und sich nicht \u00e4ndern werden.\u00a0Die Erfahrung hat uns gezeigt, dass dies niemals der Fall ist;\u00a0Anforderungen sind nie festgelegt \u2013 sie \u00e4ndern sich st\u00e4ndig.\u00a0Wenn sich die Anforderungen \u00e4ndern, wird der Plan beeinflusst;\u00a0und infolgedessen muss sich auch das Fertigstellungsdatum \u00e4ndern.\u00a0Leider ist das in vielen F\u00e4llen unm\u00f6glich, und das Team muss bis zu dem Termin liefern, zu dem es sich verpflichtet hat.\u00a0Dies ist der Zeitpunkt, an dem eine gro\u00dfe Krise eintritt und das Projekt au\u00dfer Kontrolle ger\u00e4t.<\/span><\/p>\n

Empirischer Prozess \u2013 Agiler wertorientierter Ansatz<\/span><\/strong><\/p>\n

Der wertorientierte agile Ansatz basiert auf\u00a0\u00a0<\/span>Empirie\u00a0<\/span><\/strong>\u00a0, die das gesamte Mindset ver\u00e4ndert.\u00a0Es geht von Anfang an davon aus, dass die Anforderungen, die im Voraus bestehen, nicht festgelegt sind und sich \u00e4ndern werden.<\/span><\/p>\n

Das agile Mindset geht auch davon aus, dass Sie bis zu einem bestimmten Termin liefern m\u00fcssen.\u00a0Dieser Ansatz legt Zeit und Ressourcen fest und l\u00e4sst die Anforderungen unbestimmt.\u00a0F\u00fcr uns \u00e4hnelt dieser Ansatz eher der Realit\u00e4t der Softwareerstellung.\u00a0Jetzt macht der ganze Begriff der Wertorientierung vollkommen Sinn.\u00a0Wenn Sie eine festgelegte Zeit haben, in der Sie nicht sicher sind, ob Sie alle Anforderungen erf\u00fcllen k\u00f6nnen (weil sie sich \u00e4ndern werden und sich daher die Zeit, die ben\u00f6tigt wird, um sie zu erledigen, \u00e4ndert), besteht die nat\u00fcrliche Reaktion darin, die Anforderungen zu priorisieren und zuerst fertig zu werden diejenigen, die dem Kunden den gr\u00f6\u00dften Mehrwert bieten.<\/span><\/p>\n

Sie denken vielleicht: \u201eWas ist mit den Anforderungen, die zum Liefertermin noch nicht fertig sind?\u201c\u00a0Aus diesem Grund verwenden Sie den wertorientierten Ansatz.\u00a0Sie nehmen zur Kenntnis, dass bis zum Liefertermin nicht alle Anforderungen erf\u00fcllt sein werden.\u00a0Die wichtige Frage ist, ob Sie gen\u00fcgend Funktionen bereitgestellt haben, um ein System zu unterst\u00fctzen, das dem Kunden einen Mehrwert bietet.<\/span><\/p>\n

Ausfallrate von Softwareprojekten<\/span><\/strong><\/p>\n

Der\u00a0\u00a0<\/span>CHAOS-Bericht<\/span><\/a>\u00a02015 \u00a0wurde k\u00fcrzlich von der\u00a0\u00a0<\/span>Standish Group<\/span><\/a>\u00a0ver\u00f6ffentlicht .\u00a0Die CHAOS-Berichte werden seit 1994 jedes Jahr ver\u00f6ffentlicht und sind eine Momentaufnahme des Zustands der Softwareentwicklungsbranche.\u00a0In diesem Jahr untersuchte der Bericht 50.000 Projekte auf der ganzen Welt, die von winzigen Verbesserungen bis hin zu massiven Systemumgestaltungen reichten.\u00a0In diesem Jahr enth\u00e4lt der Bericht eine erweiterte Definition von Erfolg, bei der einige zus\u00e4tzliche Faktoren ber\u00fccksichtigt werden, die in fr\u00fcheren Umfragen abgedeckt wurden.<\/span><\/p>\n

Die Ergebnisse zeigen, dass es noch viel zu tun gibt, um erfolgreiche Ergebnisse aus Softwareentwicklungsprojekten zu erzielen.\u00a0Diese Tabelle fasst die Ergebnisse von Projekten der letzten f\u00fcnf Jahre unter Verwendung der neuen Definition von Erfolgsfaktoren (in time, on budget with a befriedigenden Ergebnis) zusammen.<\/span><\/p>\n

Ausfallrate von Softwareprojekten<\/span><\/figcaption><\/figure>\n

Mit der Einf\u00fchrung agiler Entwicklungsmethoden in den letzten Jahren war es m\u00f6glich, Projektergebnisse zwischen agilen und traditionellen Wasserfallprojekten zu vergleichen.\u00a0\u00dcber alle Projektgr\u00f6\u00dfen hinweg f\u00fchrten agile Ans\u00e4tze zu erfolgreicheren Projekten und weniger v\u00f6lligen Misserfolgen, wie diese Tabelle zeigt<\/span><\/p>\n

<\/figure>\n

Was sind die Probleme des traditionellen Ansatzes?<\/span><\/strong><\/p>\n

Der traditionelle planbasierte Ansatz ist an und f\u00fcr sich nicht fehlerhaft;\u00a0es ist einfach nicht f\u00fcr die heutige Softwareindustrie geeignet.\u00a0Der planbasierte Ansatz basierte urspr\u00fcnglich auf traditionellen Projektmanagementkonzepten, die aus der Baubranche stammen.\u00a0In der Baubranche eignet sich der planbasierte Ansatz: Die Blaupausen, also die Anforderungen, stehen fest und werden sich w\u00e4hrend des Baus wahrscheinlich nicht \u00e4ndern.\u00a0Sie k\u00f6nnen absch\u00e4tzen, wie lange es dauern wird, die Stahlpfeiler zu bauen, den Beton zu gie\u00dfen und so weiter.<\/span><\/p>\n

Der Grund, warum der traditionelle planbasierte Ansatz f\u00fcr die Bauindustrie, aber nicht f\u00fcr die Softwareindustrie geeignet ist, liegt in der unterschiedlichen Art und Weise, wie wir empirische Systeme (wie Softwareentwicklung) und definierte Systeme (wie Konstruktion oder Fertigung) kontrollieren ).\u00a0Die folgende Tabelle zeigt die Unterschiede zwischen den Eigenschaften eines definierten Prozesses und denen eines empirischen Prozesses.<\/span><\/p>\n

Definierter Prozess vs. empirischer Prozess<\/span><\/figcaption><\/figure>\n

Nach dem Lesen der Tabelle ist leicht zu erkennen, dass Softwareentwicklung definitiv ein empirischer Prozess ist, kein definierter Prozess.\u00a0Das Problem ist, dass wir die Softwareentwicklung seit Jahren als einen definierten Prozess angehen \u2013 und dieser Ansatz funktioniert nicht.<\/span><\/p>\n

Verweise<\/span><\/span><\/h3>\n
    \n
  1. Chaosbericht 2015 der Standish Group<\/span><\/a><\/li>\n
  2. Agil werden in einem unvollkommenen Wort \u2013 von Greg Smith & Ahmed Sidky<\/span><\/li>\n<\/ol>\n

    Andere Scrum-Lesungen<\/span><\/span><\/h3>\n