Wie kann agile IT die IT-Branche verändern?

Inhalt

• Warum Agile IT?
• Wie begegnet die agile Methodik den Problemen des Wasserfallmodells?
• Wie hat sich Agile auf die IT-Branche ausgewirkt?
• Keine Bugs, kein Stress - Ihre schrittweise Anleitung zur Erstellung lebensverändernder Software, ohne Ihr Leben zu zerstören
• Gründe für die Verlagerung von BT zu agilen Praktiken
• Schlechtes Management von Anforderungen
  
• Schlechtes Software-Design
• Entwicklungsbeschränkungen
• Was hat BT unternommen, um die oben genannten Probleme zu lösen?
• Fazit

Quelle: Darkovujic / Dreamstime.com

Wegbringen:

Für viele war das Wasserfallmodell der Softwareentwicklung jahrzehntelang der Standard, aber jetzt wird es durch die viel flexiblere agile Methodik ersetzt.

Die agile Methodik für die Softwareentwicklung kann sich positiv auf die IT-Branche auswirken. Die Ergebnisse der Einführung agiler Methoden können auf verschiedene Arten gemessen werden. Die schnelle Bearbeitung von Software-Änderungsanforderungen, die Reduzierung von Fehlern, die quantitative Messung der Teamleistung und Engpässe sind Beispiele für eine erfolgreiche Implementierung von Agile. Um die Auswirkungen von Agile erfolgreich messen zu können, muss ein Unternehmen verschiedene Kennzahlen im Zusammenhang mit der präagilen und postagilen Entwicklung vergleichen. Die tatsächlichen Auswirkungen von Agile lassen sich nicht nur an der Umsatzsteigerung oder an der Anzahl der behobenen Fehler messen. Mehrere interne Parameter müssen berücksichtigt werden, um die tatsächlichen Auswirkungen zu verstehen. (Weitere Informationen zur agilen Entwicklung finden Sie unter Agile Software Development 101.)

Warum Agile IT?

Die IT-Branche hat sich vor allem aufgrund der Einschränkungen des Wasserfallmodells der Softwareentwicklung auf agile Praktiken eingestellt. Im Allgemeinen wurde festgestellt, dass IT-Unternehmen mit dem Wasserfallmodell der Softwareentwicklung nicht in der Lage sind, auf sich ändernde Kundenanforderungen oder Marktsituationen zu reagieren oder Kosten zu senken. Auch wenn wir dieser überwältigenden Tendenz zur agilen Methodik entgegenwirken und die Aufregung teilweise nur als Hype betrachten, gibt es viele empirische Rückmeldungen zum Wasserfallmodell.

Einfach ausgedrückt, das Wasserfallmodell ist ein Softwareentwicklungsmodell, bei dem die Arbeiten nacheinander ausgeführt werden - eine Phase nach der anderen. Es gibt fünf Phasen dieses Modells: Anforderungen, Entwurf, Implementierung, Überprüfung und Wartung. Normalerweise ist es nach Abschluss einer Phase schwierig, wenn nicht unmöglich, Änderungen an einer früheren Phase vorzunehmen. Die Annahme ist also, dass die Anforderungen ziemlich fest sind. Der Hauptunterschied zum Agile-Modell besteht in der Annahme, dass sich die Anforderungen nicht ändern. Agile geht davon aus, dass sich die Geschäftssituation und die Anforderungen ändern werden. So wird Software in kleineren Stücken über SS ausgeliefert, wohingegen im Wasserfallmodell die erste Auslieferung oder Veröffentlichung nach langer Zeit erfolgt. (Weitere Informationen zur Entwicklung finden Sie unter Wie Apache Spark die schnelle Anwendungsentwicklung unterstützt.)

Die bemerkenswerteste Kritik am Wasserfallmodell war die Annahme, dass sich die Anforderungen nicht ändern werden. Die Annahme ist fehlerhaft und unrealistisch. Beispielsweise ergab eine Studie zu 1.027 IT-Projekten in Großbritannien im Jahr 2001, dass diese Annahme der größte Grund für das Scheitern von IT-Projekten war.

In einem anderen Beispiel hat Craig Larman, der Autor des Buches "Agile and Iterative Development: A Manager's Guide", darauf hingewiesen, dass eine Reihe von Projekten, die vom Verteidigungsministerium (DoD) unter Verwendung des Wasserfallmodells in den USA durchgeführt wurden, gescheitert sind ihre Ziele erreichen. In den 1980er und 1990er Jahren musste das DoD das Wasserfallmodell für seine Softwareentwicklungsprojekte gemäß den in DoD STD 2167 veröffentlichten Standards verwenden. Schockierende Statistiken ergaben, dass 75% dieser Softwareprojekte nie verwendet wurden. Im Anschluss an diesen Bericht wurde eine Task Force unter Dr. Frederick Brooks, einem bekannten Experten für Softwareentwicklung, ins Leben gerufen. Die Task Force veröffentlichte einen Bericht mit dem Kommentar: „DoD STD 2167 muss ebenfalls grundlegend überarbeitet werden, um modernen Best Practices Rechnung zu tragen. Evolutionäre Entwicklung ist technisch am besten, sie spart Zeit und Geld. “

Die folgenden vier Annahmen des Wasserfallmodells waren in realen Szenarien fehlgeschlagen:

• Die gestellten Anforderungen sind hinreichend genau definiert und werden sich daher nicht wesentlich ändern.
• Selbst wenn sich die Anforderungen während der Entwicklungsphase ändern, sind sie klein genug, um im Entwicklungszyklus berücksichtigt zu werden.
• Die Systemintegration, die nach der Softwarelieferung erfolgt, verläuft planmäßig.
• Software-Innovation und der Aufwand für Innovationen erfolgen nach einem geplanten und vorhersehbaren Zeitplan.

Wie begegnet die agile Methodik den Problemen des Wasserfallmodells?

Die Agile-Methodik unterscheidet sich grundlegend vom Wasserfallmodell und das geht aus seinen Annahmen hervor:

• Niemand, nicht einmal der Kunde, kann die Anforderungen vollständig kennen oder verstehen. Es gibt keine Garantie dafür, dass sich die Anforderungen nicht ändern.
• Anforderungsänderungen sind möglicherweise nicht klein und überschaubar. In der Tat werden sie in verschiedenen Größen kommen und werden immer wieder kommen. Daher wird die Software in kleinen Schritten geliefert, um die Änderungen im Auge zu behalten.

Wie hat sich Agile auf die IT-Branche ausgewirkt?

Agile wird an vielen Orten eingeführt, während viele Unternehmen Pläne für die Einführung von Agile schmieden. Obwohl Agile die IT-Branche definitiv grundlegend verändert hat, ist es immer noch ein wenig schwierig, Daten und Fakten zu erhalten. Die Auswirkungen von Agile lassen sich jedoch anhand der folgenden Fallstudie von British Telecom (BT) nachvollziehen.

Keine Bugs, kein Stress - Ihre schrittweise Anleitung zur Erstellung lebensverändernder Software, ohne Ihr Leben zu zerstören

Sie können Ihre Programmierkenntnisse nicht verbessern, wenn sich niemand um die Softwarequalität kümmert.

Gründe für die Verlagerung von BT zu agilen Praktiken

BT hatte bereits 2004 einige Probleme mit seinen Softwareentwicklungspraktiken. BT entwickelte eine Reihe einfacher und komplexer Softwareprojekte. Viele Softwareprojekte konnten innerhalb des vereinbarten Zeitrahmens keine Qualitätsergebnisse erzielen. BT stellte fest, dass die Probleme auf das Wasserfallmodell zurückzuführen sind. Eine Verstärkung des Wasserfallmodells würde also nicht helfen. Die Hauptursachen für die Probleme sind nachfolgend aufgeführt:

Schlechtes Management von Anforderungen

• Es wurden zu viele Anforderungen gestellt, um in zu kurzer Zeit erfüllt zu werden.
• Viele Anforderungen waren für die geschäftlichen Anforderungen irrelevant.
• Fast alle, wenn nicht alle Anforderungen, erhielten einen hohen Prioritätsstatus.
• Die Anforderungen stellten die aktuellen Geschäftsanforderungen dar, ohne die zukünftigen Szenarien zu berücksichtigen. Das ließ die Möglichkeit zukünftiger Softwareänderungen offen.

Schlechtes Software-Design

• Angesichts der Vielzahl der Anforderungen haben die Designer zu viel Zeit darauf verwendet, herauszufinden, was die Anforderungen bedeuteten. Für das eigentliche Design blieb wenig Zeit.
• Die Anforderungsanalysten wechselten zu anderen Aufgaben und nahmen ungeschriebenes, implizites Wissen mit.
• Die obigen zwei Faktoren führten zu einem schlechten Design. Designer mussten immer noch gemäß der ursprünglichen Zeitlinie liefern.

Entwicklungsbeschränkungen

Die Codierung war voreilig und von schlechter Qualität, da das Software-Design fehlerhaft war. Die Entwickler würden erkennen, dass ein schlechtes Softwaredesign zu schlechtem Code führen würde, der jedoch zum vereinbarten Zeitpunkt geliefert werden musste. Während der Integration wurden viele Fehler gemeldet, da Unit-Tests und Regressionstests nicht ausgeführt wurden.

Zum Zeitpunkt der Softwarebereitstellung stellt der Kunde fest, dass sich die Anforderungen und das Geschäftsszenario bereits geändert haben. Die Software hat auch viele Probleme. Effektiv wird der gesamte Aufwand der Softwareentwicklung als Verschwendung betrachtet.

Was hat BT unternommen, um die oben genannten Probleme zu lösen?

BT erkannte, dass die Verstärkung des Wasserfallmodells nicht die Antwort auf die Probleme war. Es brauchte einen neuen Ansatz. Daher wurde beschlossen, den agilen Ansatz umzusetzen. Unter dem neuen Ansatz wurden die folgenden Dinge entschieden:

• Anstelle des 12-monatigen Entwicklungszyklus würde BT jetzt funktionsfähige Software in einem 90-Tage-Zyklus liefern. Die Idee war, sich auf ein oder zwei Geschäftsprobleme zu konzentrieren und innerhalb von 90 Tagen eine Softwarelösung zu liefern. Der Beginn dieses Zyklus war geprägt von einer intensiven Diskussion zwischen verschiedenen Stakeholdern, um die Anforderungen klar zu identifizieren, zu analysieren und zu priorisieren.
• Ziel war es, klare, greifbare Geschäftswerte zu liefern. Der interne Kunde stand unter dem Druck, klare Anforderungen zu stellen. Anstelle von vagen Zielen wurden User Stories mit klaren Akzeptanzkriterien angegeben.
• Die ausgelieferte Software würde vollständig getestet und dokumentiert. Die Software würde häufig Integrationstests durchlaufen, um Probleme im Voraus zu identifizieren.

Mit dem Agile-Ansatz kann sich BT leichter an sich ändernde Anforderungen oder Geschäftssituationen anpassen. Die Codequalität wurde verbessert und grundlegende Fehler in letzter Minute wurden behoben.

Fazit

Bei all seinen Vorteilen und dem damit verbundenen Hype befindet sich Agile noch in einem Stadium, in dem sein Potenzial nicht voll ausgeschöpft wird. Dies liegt daran, dass viele Unternehmen den Ansatz so anpassen, dass die ursprünglichen Prinzipien geändert werden. Infolgedessen feiert das Wasserfallmodell in einigen Fällen ein Comeback. Während die Anpassung fortgesetzt wird, ist es wichtig, die Grundprinzipien von Agiles beizubehalten. Viele Organisationen behaupten, sie seien vollständig agil, aber sie haben noch einen weiten Weg vor sich, um ein wirklich agiles Unternehmen zu werden.