Es gibt zahlreiche Hinweise darauf, dass massive Installationen von Unternehmenssoftware, einschließlich SAP und NASA, die meisten Frameworks ablehnen, die wir als agil einstufen.

Dies ist auf den Umfang solcher Lieferungen zurückzuführen, die eine erhebliche Menge an Vorausplanung erfordern, selbst wenn das Design noch nicht abgeschlossen ist. Die Kosten sind traditionell extrem hoch und es ist unwahrscheinlich, dass das System funktioniert, bis das Ganze zusammengebaut ist, obwohl es viele Testsuiten und Simulationen bestehen könnte.

Was verstehen wir unter Agilität?

Auch wenn Befürworter von Agile darüber mit den Zähnen knirschen könnten, müssen wir taktische Softwarebereitstellungsmuster von den allgemeinen Rahmenbedingungen trennen, die für die Bereitstellung verwendet werden.

Agilität kann spätestens in eine Handvoll Praktiken, Muster, Leitfäden, Techniken, Taktiken oder Ansätze destilliert werden.

Oder es könnten ein paar Dutzend sein ...

Oder man könnte argumentieren, dass Agile eigentlich aus über 100 verschiedenen Ansätzen und sich überschneidenden Mustern besteht.

Jemand könnte also in einer Wasserfallorganisation arbeiten, die einige agile Muster verwendet. Oder die Organisation ist größtenteils agil, aber eine Abteilung hat eine Art Wasserfallplanung eingeführt, obwohl sie große Befürworter von Agile ist.

Was meinen wir mit nicht agil?

Es wird sehr schwierig zu argumentieren, dass eine Organisation nicht agil arbeitet, wenn sie einige oder alle der oben aufgeführten Muster in irgendeiner Phase ihrer Bereitstellung übernommen hat. Abgesehen davon sollte es heißen , agil zu sein, nicht agil zu sein , aber es ist fast unmöglich, die Art und Weise, wie das Wort agil verwendet wird, umzukehren. Mit diesem Argument sind Sie auf der falschen Seite.

Welche Alternative gibt es?

Es gibt eine Brücke zwischen der traditionellen Wasserfallwelt und der agilen Landschaft; Wir nennen diese Technik Spiralentwicklung . Es kann eine wasserfallartige Planung und Erkennung im Voraus verwenden, um das bei gefährlichen Installationen erforderliche Maß an Gewissheit zu gewährleisten, ermöglicht jedoch eine schnelle Iteration, sobald bestimmte Variablen bekannt sind. Natürlich hat, wie alle Dinge, auch Spiral Development seine Puristen und Kritiker und wird von seinen eigenen Bikeshedding-Debatten geplagt.

Beispiel 1

Hier ist ein Peer-Review-Papier der NASA , das für The Business Case for Spiral Development in Heavy-Lift Launch Vehicle Systems argumentiert

Der spiralförmige Entwicklungsprozess wird jetzt in großem Umfang für den Erwerb großer staatlicher Programme eingesetzt und eignet sich für das hier beschriebene Projekt. Der Hauptvorteil dieses Konzepts besteht darin, dass es auf bestehenden Fähigkeiten und Vermögenswerten aufbaut, anstatt ein Fahrzeugprogramm „neu“ von Grund auf neu zu starten. Spiral Development-Designs rekombinieren vorhandene Assets in neuen Konfigurationen, um unter extrapolierten Betriebsbedingungen zu funktionieren.

Beispiel 2

SAP hat einen offiziellen Leitfaden für das Projecting Management der Bereitstellung einer SAP-Installation (in der Regel mehrere Jahre Arbeit) über das umfangreiche Handbuch veröffentlicht, das die 16 aufeinanderfolgenden Schritte beschreibt, die für ein erfolgreiches SAP-Projekt erforderlich sind.

Es gibt jedoch auch das offiziell unterstützte Accelerated SAP (ASAP), das im SAP-Blog eingesehen werden kann . Eine schöne Übersicht finden Sie auf SlideShare.

Es gibt auch detaillierte Anleitungen für einzelne SAP-Komponenten wie die Hana-In-Memory-Datenbank. Diese Projektmanagement-Richtlinien finden Sie hier .

Gegenbeispiel 1

Wie bei allen projektbezogenen Dingen finden Sie Beispiele und Widerlegungen in Hülle und Fülle. SpaceX hat die etablierten Lieferfristen der NASA erfolgreich herausgefordert, indem es aggressiv agilere Methoden für das Prototyping, die Herstellung und das Testen von Komponenten eingeführt hat; Sie bleiben jedoch, wie Tesla, aus vielen Gründen die Ausnahme von der Regel.

Wenn Sie daran interessiert sind, wie SpaceX agile Frameworks nutzt, würde ich Ihnen eine kritische Lektüre von Elon Musk: How the Billionaire CEO of SpaceX and Tesla is Shaping our Future vorschlagen . Ungeachtet des Titels enthält das Buch riesige Mengen an agilen und lieferungsbezogenen Erkenntnissen der Entwicklungsteams. Beispielsweise wurde das erste Tesla MVP in einem Excel-Dokument erstellt, bevor es woanders hinging.

Zusammenfassung

• Die meisten Unternehmen haben ein oder mehrere Softwaremuster eingeführt, die wir als agil erkennen würden
• Das bedeutet nicht, dass sie ganze agile Frameworks unterstützen
• Es gibt eine Brücke zwischen traditionellem Wasserfall und Agile; es heißt Spirale
• Bestimmte Organisationen benötigen aufgrund des schieren Umfangs ihrer Lieferungen immer noch eine Vorausplanung

Wie ich oben angemerkt habe, scheint dies weitgehend meinungsbasiert zu sein. Die einzige Möglichkeit, die mir einfällt, um einen objektiven Standpunkt zu der Frage „Ist agil effizienter als traditionell?“ zu haben. ist, sich Statistiken anzusehen.

Zum Glück haben wir dafür den CHAOS Report der Standish Group . Gehe nach diesen Zahlen...

Ja. Traditionell ist im Durchschnitt weniger effizient.

Beachten Sie jedoch, dass dies nur für den Durchschnitt gilt . Auch Situationsmodifikatoren müssen berücksichtigt werden.

Agil oder nicht agil: Meiner Meinung nach leitet sich der Projekttyp davon ab, zum Beispiel Scrum-Meeting – unser Projekt ist ein laufendes Entwicklungsprojekt mit 5 bis 10 Personen, dann ist ein agiles Scrum-Meeting sehr gut, wenn das gleiche mit einem Team von mehr als 100 Personen ist dann wird es etwas schwierig; Wenn unser Team aus 4 Mitgliedern besteht und 4 verschiedene Tools handhabt, sind tägliche Meetings möglicherweise nicht sinnvoll usw., also müssen wir analysieren, dann übernehmen und weiterentwickeln.