Die PHP-Kolumne: Zeit für PHP

Von gescheiterten IT-Projekten lernen
Keine Kommentare

Entwickler kennen das Problem: Man hat viel Zeit, Geld und Nerven in ein Projekt gesteckt und dann geht irgendetwas schief. Das IT-Projekt scheitert. Jetzt gilt, den Kopf nicht in den Sand zu stecken und das Beste daraus zu machen. Das Beste bedeutet in diesem Fall: aus den eigenen Fehlern lernen.

Laut einem Report des Project Management Institute (PMI) aus dem Jahr 2017 scheitern 14 Prozent aller IT-Projekte. Und zwar komplett. Von den übrigen Projekten, die nicht komplett scheitern, erreichen 31 Prozent nicht (alle) ihre Ziele, 43 Prozent überschreiten das geplante Budget und 49 Prozent liefern zu spät. Was in einem gescheiterten Projekt schlecht (oder was in einem erfolgreichen Projekt gut) lief, bleibt meist im Verborgenen beziehungsweise das Wissen darum nur den Projektbeteiligten vorbehalten.

Damit nicht nur der individuelle Entwickler, das beteiligte Entwicklungsteam oder das betroffene Unternehmen aus der Projekterfahrung lernen kann, sondern auch unsere Industrie als Ganzes, bedarf es einer öffentlichen Diskussion von IT-Projekten. Das ist jedoch die Ausnahme und passiert viel zu selten. Beispielsweise dann, wenn eine 655 Millionen US-Dollar teure Raumsonde verloren geht. Oder wenn eine Fortune 500 Company (Hertz) eine andere Fortune 500 Company (Accenture) wegen eines gescheiterten IT-Projektes verklagt. Die Mars-Climate-Orbiter-(MCO-)Mission der NASA ist ein Beispiel für ein IT-Projekt, dessen Scheitern gut dokumentiert ist. Hierbei ging eine Sonde, die das Klima des Planeten Mars erforschen sollte, am 23. September 1999 aufgrund eines Einheitenfehlers im Navigationssystem verloren. Nur eine Woche später, am 30. September 1999, machte die NASA die Fehlerursache öffentlich: ein Teil des Teams hatte mit Inches, Feet und Pounds gerechnet während der Rest des Teams mit metrischen Einheiten gerechnet hatte. Bemerkenswert ist folgende Aussage: „The problem here was not the error, it was the failure of NASA’s systems engineering, and the checks and balances in our processes to detect the error”. Der technische Fehler, der zum Verlust der Sonde führte, wird also nicht als zugrunde liegende Ursache angesehen, sondern als Folgefehler von Unzulänglichkeiten im Entwicklungsprozess: zu wenig Kommunikation zwischen den Teams und fehlende Integrationstests.

Ist immer die Software schuld?

Im Oktober 2018 verunglückte ein Flugzeug des Typs Boeing 737 MAX 8 kurz nach dem Start in Indonesien (Lion Air Flug 610). Im März 2019 stürzte ein Flugzeug desselben Typs ebenfalls nur Minuten nach dem Start in Äthiopien ab (Ethiopian Airlines Flug 302). In beiden Fällen kamen alle Menschen an Bord ums Leben. In beiden Fällen war Software, das Maneuvering Characteristics Augmentation System (MCAS), die Ursache für den Absturz. Robert C. Martin, Softwareentwicklern als Uncle Bob und Autor von „Clean Code“ bekannt, hat in einem Artikel analysiert, was über die Softwareprobleme des MCAS der Boeing 737 MAX 8 bekannt ist. Seine Perspektive ist dabei nicht auf die eines Experten für Softwareentwicklung beschränkt, da er als Pilot auch den Kontext, in dem die fragliche Software operiert, kennt. So weit bekannt ist, wurden der MCAS-Software in beiden Fällen fehlerhafte Daten von einem Anstellwinkelsensor geliefert. Auf Basis dieser Daten entriss das MCAS daraufhin den Piloten die Kontrolle über das Flugzeug. Die Software verließ sich auf die Daten dieses Sensors, ohne sie mit anderen Daten wie Fluggeschwindigkeit, Vertikalgeschwindigkeit oder Flughöhe abzugleichen. Oder mit den Daten eines weiteren Anstellwinkelsensors. Ein solcher Cross-Check der Daten geht einem Piloten bei der Ausbildung für den Instrumentenflug in Fleisch und Blut über. Schließlich kann ein Instrument so ausfallen, dass der Ausfall nicht direkt zu bemerken ist. In seinem Artikel stellt Robert C. Martin die Frage, warum die Softwareentwickler von MCAS diese grundlegenden Prinzipien der Luftfahrt nicht berücksichtigten.

International PHP Conference

PHP in 2020: Fully Loaded

by Arne Blankerts (thePHP.cc)

PSR-14: A Major PHP Event

by Larry Garfield (Platform.sh)

Leaving a Legacy

by (PHPUnit, open source contributor)


Im April 2019 sorgte die Klage der US-amerikanischen Autovermietung Hertz gegen ihren IT-Dienstleister Accenture für Aufsehen. Die öffentlich gewordene Klageschrift enthält viele Details, die tiefe Einblicke in ein gescheitertes IT-Projekt gewähren. Im August 2016 erteilte Hertz Accenture den Auftrag, eine neue Onlinepräsenz zu entwickeln. Die sollte im Dezember 2017 in Produktion gehen. Diese erste Deadline wurde ebenso verfehlt wie eine zweite (Januar 2018) und dritte (April 2018). Hertz verklagt Accenture nun auf 32 Millionen US-Dollar an bereits gezahltem Honorar sowie weitere Millionen, die benötigt werden, um das von Accenture hinterlassene Chaos aufzuräumen. Laut Hertz hat Accenture weder eine funktionierende App noch eine funktionierende Webseite geliefert. Obwohl von Hertz eine Lösung gefordert war, die zum einen auch für die Marken Dollar und Thrifty sowie zum anderen auch in Märkten außerhalb Nordamerikas eingesetzten werden kann, entwickelte Accenture eine Software, die nur für die Marke Hertz und nur in Nordamerika verwendet werden konnte. Also hätte verwendet werden können, so sie denn fertiggestellt worden wäre. Es mag verlockend sein, Schadenfreude darüber zu empfinden, dass auch große Firmen wie Hertz und Accenture ein Projekt in den Sand setzen können, aber das einzige, was das Scheitern dieses Projektes besonders macht, ist die Tatsache, dass zum einen sehr viel falsch gelaufen ist und zum anderen all das jetzt durch die Klage ans Licht der Öffentlichkeit gelangt.

Accenture hat die entwickelte Software nicht getestet, zumindest weder gründlich noch rechtzeitig. Die Klageschrift kann so gelesen werden, dass weder automatisierte Tests im Allgemeinen noch Test-driven Development im Besonderen zum Einsatz kamen. Die fehlenden automatisierten Tests wird man nachträglich nicht implementieren können, weil nicht klar genug ist, wozu der Code eigentlich existiert. Warum nicht klar sein sollte, warum der zu testende Code eigentlich existiert? Das lässt sich zwischen den Zeilen der Beschreibung von anderen Projektproblemen herauslesen. Beispielsweise waren die Accenture-Entwickler nicht in der Lage, den Backend-Code (Java) fehlerfrei, performant und sicher mit dem Frontend-Code (Angular) zu integrieren.

Aus den eigenen Fehlern lernen

Es wäre wohlfeil und würde zu kurz greifen, würde man die Ursache für das Scheitern des Projektes nur bei Accenture suchen. Hertz hatte kein eigenes Entwicklungsteam, das das Projekt im eigenen Haus hätte umsetzen können, weil man alle Entwickler Anfang 2016 entlassen hat. Für ein erfolgreiches Gelingen des Projekts hätte zumindest die Rolle des Product Owners, um einen Begriff aus der Scrum-Welt zu bemühen, inhouse besetzt werden müssen. Da das nicht passierte, lag die Verantwortung dafür, welche Anforderungen im Product Backlog stehen und in welcher Reihenfolge sie abgearbeitet werden, nicht in der Hand des Auftraggebers, sondern beim Dienstleister. Die daraus resultierende schlechte Kommunikation zwischen Hertz und Accenture dürfte eine der Hauptursachen für das Scheitern des Projektes gewesen sein. Und egal, ob Hertz es gefordert hat oder nicht, Accenture hat sich auf ein Go-Live-Datum committed. Anstelle des geplanten Big Bang Deployments, das nie zustande kam, wäre es sinnvoll gewesen, in kurzen Iterationen Use Case für Use Case nicht nur zu implementieren, sondern auch kontinuierlich auszurollen.

Das C3-Projekt ist ein Beispiel für ein IT-Projekt, aus dem viel Gutes entstanden ist.

Moderne Entwicklungsprozesse sehen Retrospektiven und Postmortems vor, um aus den eigenen Fehlern zu lernen. Sie helfen den individuellen Entwicklern, den einzelnen Teams sowie dem gesamten Unternehmen dabei, besser zu werden. Ich finde es lobenswert, wenn Unternehmen ihre Post-incident Analysis beispielsweise auf dem Firmenblog öffentlich machen, wenn etwas bei ihnen passiert ist. Als Beispiele seien hier GitHub und Travis genannt. Das eröffnet die Möglichkeit, aus den Fehlern anderer zu lernen.

Natürlich kann man auch aus Dingen lernen, die gut in einem Projekt gelaufen sind. Ich schaue mir beispielsweise gerne Videos der Classic Game Postmortem Vorträge von der Game Developers Conference an. Da lerne ich nicht nur etwas über Spiele wie Maniac Mansion oder Civilization, die ich als Kind auf dem Amiga gespielt habe, oder darüber, wie die Programmierer mit trickreicher Programmierung die limitierte Hardware der damaligen Computer ausgereizt haben. Sondern auch, wie zu der Zeit Software entwickelt wurde, wie Projekte verwaltet wurden (oder auch nicht) et cetera. Da bin ich hinterher immer froh, dass Software heute anders entwickelt wird.

Das Chrysler Comprehensive Compensation System (C3-Projekt) ist ein Beispiel für ein IT-Projekt, aus dem viel Gutes entstanden ist. Zu Beginn der 1990er Jahre beschloss der US-amerikanische Automobilhersteller Chrysler, eine neue Software für die Lohn- und Gehaltsabrechnungen von 87 000 Angestellten zu entwickeln. Die Entwicklung (in SmallTalk) begann im Jahr 1994. Zwei Jahre später, die Software hatte noch keine einzige Lohn- oder Gehaltsabrechnung durchgeführt, engagierte man Kent Beck, um das Projekt zu retten. Dieser wiederum holte Ron Jeffries an Bord. Im März 1996 schätzte das Team, dass die Software gut ein Jahr später einsatzbereit sein würde. Das C3-Projekt ging in die Geschichte der Softwareentwicklung ein, weil sich das Team 1997 entschloss, die Art, wie es arbeitete, zu ändern. Diese neue Art, zu arbeiten, wurde später unter dem Namen Extreme Programming bekannt. Die Schätzung, dass die Software binnen eines Jahres einsatzbereit sein würde, erwies sich als fast zutreffend. Mit nur wenigen Monaten Verspätung (aufgrund von einigen wenigen unklaren Anforderungen) ging eine erste Version, mit der monatliche Lohn- und Gehaltsabrechnungen für 10 000 Mitarbeiter abgewickelt wurden, in Betrieb. Die von Kent Beck, Ron Jeffries und ihrem Team angewandten Praktiken wie Test-First-Programmierung, Pair Programming und engere Einbeziehung des Kunden, insbesondere in Verbindung mit kurzen Feedbackzyklen, die im C3-Projekt erfolgreich ausprobiert und in dessen Nachgang formalisiert und popularisiert wurden, haben die Art, wie wir alle Software entwickeln, nachhaltig verändert.

Klare Vorgaben und Ziele führen zum Erfolg

Erfolgreich Software zu entwickeln bedeutet, zielgerichtet vorzugehen. Diese Ziele sollten sich aus mit dem Business abgestimmten Akzeptanzkriterien ergeben. Ohne eine klare Vorgabe von Zielen (im Sinne von Tasks) läuft der Entwickler Gefahr, sich bei der Arbeit zu verlieren. Er weiß im Besonderen nicht, wann er mit einem Task fertig ist. Es bietet sich an, Akzeptanzkriterien durch automatisierte Tests zu dokumentieren und zu überprüfen. So oder so müssen die Ziele definiert werden, bevor Produktionscode geschrieben wird. Das ist testgetriebene Entwicklung, egal ob man es so nennen will oder nicht. Die Hauptaufgabe eines Entwicklers ist nicht das Schreiben von Code, sondern das Verstehen eines Problems. In seinem Artikel über die MCAS-Software der Boeing 737 MAX 8 formuliert Robert C. Martin das so: „Programmers must not be treated as requirement robots. Rather, programmers must have intimate knowledge of the domain they are programming in.“

Ein Entwickler kann nur dann sinnvoll arbeiten, wenn er die Domäne versteht, in der das Unternehmen, für das er Software entwickelt, agiert. Meiner Erfahrung nach funktionieren IT-Projekte dann schlecht, wenn „das Business“ mit der „Kostenstelle IT“ nur über Tickets kommuniziert, und zwar ohne Kontext, warum etwas geändert oder umgesetzt werden soll. Und IT-Projekte funktionieren meiner Erfahrung nach dann gut, wenn die Softwareentwickler verstehen, wie das Unternehmen funktioniert und wie eine Änderung zum Unternehmenserfolg beitragen kann. Das gelingt, wenn allen Beteiligten klar ist, dass Softwareentwicklung mehr Mensch-Mensch- als Mensch-Maschine-Kommunikation ist.

PHP Magazin

Entwickler MagazinDieser Artikel ist im PHP Magazin erschienen. Das PHP Magazin deckt ein breites Spektrum an Themen ab, die für die erfolgreiche Webentwicklung unerlässlich sind.

Natürlich können Sie das PHP Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Kiosk ist das PHP Magazin ferner im Abonnement erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -