Software-Entwicklung: Sollten wir die Beweise weiterhin ignorieren?

Herausgeber: Luc ist der CEO von Xebia Frankreich. Dies ist eine englische Übersetzung eines Beitrags von Luc im französischen Xebia-Blog. Wir haben es wieder einmal festgestellt, ein Mal zu viel, zweifellos. Einer unserer Kunden (denn die Verantwortlichen für eine solche Situation arbeiten im selben Unternehmen wie die Person, bei der unser Ansprechpartner tätig ist) hat sich bei einem Projekt, das zu einem Festpreis entwickelt wurde, in eine Lose/Lose-Situation mit seinem Integrator gebracht. Wie lauten die Fakten? Wir könnten, ohne ihn zu Wort kommen zu lassen, alle Schwierigkeiten, auf die er stößt, eine nach der anderen aufzählen und sie wie einen Rosenkranz aufzählen. Es wurde eine Ausschreibung veröffentlicht, die sich an die wichtigsten Integratoren des Ortes richtete, denn je nach Einkaufsabteilung ist dies die einzige Möglichkeit, ein IT-Projekt durchzuführen (wir haben Ihnen in einem früheren Posting (auf Französisch) davon berichtet: "Eloge de la qualité"). Laut denselben Fachleuten, die für ihre IT-Kenntnisse bekannt sind, ist dies eine Möglichkeit, die Kosten und die Vorlaufzeiten zu kontrollieren, das Risiko mit dem ausgewählten Unternehmen zu teilen und eine Hebelwirkung zu erzielen (denn es versteht sich von selbst, dass im Vertrag einige wunderbare Strafklauseln für verspätete Lieferungen festgelegt wurden). Die Wahl fiel auf den Integrator X. Das lag vor allem daran, dass er ein verlockendes Angebot unterbreitete und in der Lage war, alle Grundsätze dieses "Vertrauensvertrags" zu akzeptieren, ohne ein Wort zu sagen. Die Weichen waren also gestellt: eine ruhige Atmosphäre, gegenseitiges Vertrauen, die Einbeziehung der besten Profile von Unternehmen X, die Berücksichtigung der Wünsche der Benutzer... Wie Sie vielleicht erwarten, ist der letzte Satz ironisch gemeint. Der Projektleiter stand unter Druck, sein Unternehmen hatte ihm dreieinhalb Praktikanten zugewiesen, und ein Viertel eines Architekten, denn nach erbitterten Verhandlungen stellte sich heraus, dass das ausgehandelte Geschäft weniger profitabel war als erwartet. Und innerhalb von Unternehmen X führt ein schlecht verhandeltes Projekt dazu, dass unerfahrene Entwickler eingesetzt werden ("Sie zahlen Peanuts, Sie bekommen Affen", wie wir alle wissen). Die Einkäufer des Kunden rieben sich die Hände, sie hatten ihr Schiff gut gesteuert. Der Projektleiter war gezwungen, alle härter arbeiten zu lassen, als es die Vernunft gebietet, um unzumutbare Fristen einzuhalten. Das Wort "Strafe" wurde erst diskret geflüstert und dann in den Projektbesprechungen offen ausgesprochen und wie die ultimative Drohung ausgesprochen. Die Rechtsabteilungen beider Parteien zogen den Vertrag heraus und gingen ihn mit einem feinzahnigen Kamm durch. Und jeder verbrachte mehr Zeit damit, nach Möglichkeiten zu suchen, die andere Partei zu überrumpeln, als tatsächlich zu versuchen, die Probleme gemeinsam und in gutem Glauben zu lösen. Und was war mit den Nutzern? Sie waren beunruhigt. Die Anwendung, die sie bestellt hatten, war für sie von entscheidender Bedeutung, um ihre Arbeit erledigen zu können. Das Projektmanagement erklärte ihnen, dass sie ihre Arbeit nicht richtig gemacht hätten, dass ihre Spezifikationen zu vage seien und dass ihre unaufhörlichen Änderungswünsche inakzeptabel seien. Sie wurden sogar als zweite in der Reihe genannt, die die Verantwortung für dieses Chaos zu tragen hatten, natürlich nach dem Integrator. Dieses Projekt wurde schnell zu einem Fass ohne Boden. Der Kunde war zu weit gegangen, um noch eine Kehrtwende zu machen. Die Büchse der Pandora war geöffnet: Die "Addenda", so hieß es schließlich zur großen Zufriedenheit aller Beteiligten, denn nur so konnte man am Ende auf beiden Seiten erhobenen Hauptes aus der Sache herausgehen. Aber Vorsicht, der Einsatz einer solchen Hinterlist in einem Vertrag zwischen zwei Parteien sollte natürlich sehr sparsam erfolgen, denn sie soll dem Integrator lediglich ermöglichen, sein Defizit bei dem Projekt in Bereichen, in denen er wirklich nicht zur Rechenschaft gezogen werden kann, "ein wenig" zu verringern. Dieses Täuschungsmanöver erlaubt es ihm lediglich, das Projekt in einem vegetativen finanziellen Zustand zu halten (weniger Verluste oder bestenfalls Null-Profitabilität). Das Paradigma der Softwareentwicklung zum Festpreis basiert auf Prinzipien (wenn nicht gar auf Werten), die verfälscht, unehrlich, utopisch und veraltet sind. Erfolgreiche Unternehmen wie Google, Amazon und Microsoft, um nur die bekanntesten zu nennen, wissen das schon seit langem. Agile Methoden sind eine ernsthafte Alternative. Die Grundsätze dieser Methoden lauten wie folgt:

Kompetenz und Motivation des Teams

Die Mitarbeiter, die den Projekten zugewiesen werden, verfügen über das erforderliche Maß an Erfahrung, um modulare, evolutive, effiziente, dokumentierte, integrierbare und funktionsfähige Anwendungen zu entwickeln. Diese Mitarbeiter engagieren sich bei der Kalkulation und Erstellung der Anwendung. Iterative Entwicklung"¨Die Entwicklung von Projekten erfolgt iterativ. Der Tunneleffekt wird ausgemerzt. Die gelieferten Module sind sofort einsatzbereit.

Eine positive Akzeptanz des Wandels

Das Schreiben vollständiger, detaillierter Spezifikationen Monate vor der Auslieferung erweist sich als etwas utopisch. In diesem Zusammenhang ist die Akzeptanz der Änderung von Prioritäten und Funktionalitäten ein integraler Bestandteil des agilen Entwicklungsprozesses von Xebia.

Enge Zusammenarbeit mit den Benutzern

Die starke Einbindung des Managements und der Benutzer während des gesamten Projekts ist auf ein ständiges Feedback ausgerichtet, das durch systematische Demonstrationen orchestriert wird, die es bei jeder Iteration ermöglichen, die geleistete Arbeit zu validieren und die Prioritäten für die nächste Phase zu definieren.

Kontinuierliche Aufmerksamkeit für technische Spitzenleistungen

Die Java/J2EE-Hyperspezialisierung ermöglicht es, von Beginn des Projekts an auf allen Ebenen des Projekts die aktuell besten Praktiken der Branche einzusetzen: von erfahrenen Architekten entworfene Architektur, laufende Integrationspolitik, Leistungstests, Fehlermanagement, Betriebsfähigkeit der Anwendungen, nachhaltige technologische Entscheidungen...