Es gibt Projekte, die ziemlich geradlinig und relativ vorhersehbar sind und bei denen rationale Planungs- und Entscheidungswerkzeuge angewendet werden können. Andere Projekte, die komplexer oder unvorhersehbarer sind, erfordern einen anderen Ansatz, der mehr auf Selbstorganisation und Innovation setzt.
Die meisten Softwareentwicklungsprojekte gelten aufgrund der Konvergenz von drei Faktoren als komplex und unvorhersehbar: Menschen, Anforderungen und Technologie. Die verschiedenen Ansätze zur Durchführung und Verwaltung von Projekten könnten im Kontext von Prozesssteuerungsmodellen und Projektkomplexität leichter verstanden werden.
Definierter Prozess – Ein traditioneller plangesteuerter Ansatz
Traditionell wird zu Beginn eines Projekts ein Anforderungspaket erstellt und dann „abgezeichnet“. Der Projektleiter geht davon aus, dass diese Freigabe zu einem festen Anforderungskatalog führt und nun mit der Planung begonnen werden kann. Der Projektleiter schätzt, wie lange es dauern wird, die Anforderungen zu erfüllen, und erstellt den Projektplan. Der Plan sieht vor, dass das Projekt bis zu einem bestimmten Datum abgeschlossen sein wird, und dieses Datum wird dem Kunden mitgeteilt.
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 ändern werden. Die Erfahrung hat uns gezeigt, dass dies niemals der Fall ist; Anforderungen sind nie festgelegt – sie ändern sich ständig. Wenn sich die Anforderungen ändern, wird der Plan beeinflusst; und infolgedessen muss sich auch das Fertigstellungsdatum ändern. Leider ist das in vielen Fällen unmöglich, und das Team muss bis zu dem Termin liefern, zu dem es sich verpflichtet hat. Dies ist der Zeitpunkt, an dem eine große Krise eintritt und das Projekt außer Kontrolle gerät.
Empirischer Prozess – Agiler wertorientierter Ansatz
Der wertorientierte agile Ansatz basiert auf Empirie , die das gesamte Mindset verändert. Es geht von Anfang an davon aus, dass die Anforderungen, die im Voraus bestehen, nicht festgelegt sind und sich ändern werden.
Das agile Mindset geht auch davon aus, dass Sie bis zu einem bestimmten Termin liefern müssen. Dieser Ansatz legt Zeit und Ressourcen fest und lässt die Anforderungen unbestimmt. Für uns ähnelt dieser Ansatz eher der Realität der Softwareerstellung. Jetzt macht der ganze Begriff der Wertorientierung vollkommen Sinn. Wenn Sie eine festgelegte Zeit haben, in der Sie nicht sicher sind, ob Sie alle Anforderungen erfüllen können (weil sie sich ändern werden und sich daher die Zeit, die benötigt wird, um sie zu erledigen, ändert), besteht die natürliche Reaktion darin, die Anforderungen zu priorisieren und zuerst fertig zu werden diejenigen, die dem Kunden den größten Mehrwert bieten.
Sie denken vielleicht: „Was ist mit den Anforderungen, die zum Liefertermin noch nicht fertig sind?“ Aus diesem Grund verwenden Sie den wertorientierten Ansatz. Sie nehmen zur Kenntnis, dass bis zum Liefertermin nicht alle Anforderungen erfüllt sein werden. Die wichtige Frage ist, ob Sie genügend Funktionen bereitgestellt haben, um ein System zu unterstützen, das dem Kunden einen Mehrwert bietet.
Ausfallrate von Softwareprojekten
Der CHAOS-Bericht 2015 wurde kürzlich von der Standish Group veröffentlicht . Die CHAOS-Berichte werden seit 1994 jedes Jahr veröffentlicht und sind eine Momentaufnahme des Zustands der Softwareentwicklungsbranche. In diesem Jahr untersuchte der Bericht 50.000 Projekte auf der ganzen Welt, die von winzigen Verbesserungen bis hin zu massiven Systemumgestaltungen reichten. In diesem Jahr enthält der Bericht eine erweiterte Definition von Erfolg, bei der einige zusätzliche Faktoren berücksichtigt werden, die in früheren Umfragen abgedeckt wurden.
Die Ergebnisse zeigen, dass es noch viel zu tun gibt, um erfolgreiche Ergebnisse aus Softwareentwicklungsprojekten zu erzielen. Diese Tabelle fasst die Ergebnisse von Projekten der letzten fünf Jahre unter Verwendung der neuen Definition von Erfolgsfaktoren (in time, on budget with a befriedigenden Ergebnis) zusammen.
Mit der Einführung agiler Entwicklungsmethoden in den letzten Jahren war es möglich, Projektergebnisse zwischen agilen und traditionellen Wasserfallprojekten zu vergleichen. Über alle Projektgrößen hinweg führten agile Ansätze zu erfolgreicheren Projekten und weniger völligen Misserfolgen, wie diese Tabelle zeigt
Was sind die Probleme des traditionellen Ansatzes?
Der traditionelle planbasierte Ansatz ist an und für sich nicht fehlerhaft; es ist einfach nicht für die heutige Softwareindustrie geeignet. Der planbasierte Ansatz basierte ursprünglich auf traditionellen Projektmanagementkonzepten, die aus der Baubranche stammen. In der Baubranche eignet sich der planbasierte Ansatz: Die Blaupausen, also die Anforderungen, stehen fest und werden sich während des Baus wahrscheinlich nicht ändern. Sie können abschätzen, wie lange es dauern wird, die Stahlpfeiler zu bauen, den Beton zu gießen und so weiter.
Der Grund, warum der traditionelle planbasierte Ansatz für die Bauindustrie, aber nicht für 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 ). Die folgende Tabelle zeigt die Unterschiede zwischen den Eigenschaften eines definierten Prozesses und denen eines empirischen Prozesses.
Nach dem Lesen der Tabelle ist leicht zu erkennen, dass Softwareentwicklung definitiv ein empirischer Prozess ist, kein definierter Prozess. Das Problem ist, dass wir die Softwareentwicklung seit Jahren als einen definierten Prozess angehen – und dieser Ansatz funktioniert nicht.
Verweise
- Chaosbericht 2015 der Standish Group
- Agil werden in einem unvollkommenen Wort – von Greg Smith & Ahmed Sidky
English
简体中文
繁體中文
Deutsch
Español
Français
العربية
Italiano
Português
日本語
Nederlands
Русский