Ultimative Qualität für Software!

Das Bewusstsein für die Relevanz von „Software“ als kritischer Faktor für den Unternehmenserfolg ist gestiegen. Auch in Deutschland richten jetzt große Konzerne ihr Augenmerk immer mehr auf ihre IT-basierenden Anwendungen und untersuchen gezielt die Qualität derselbigen um sie dann zu verbessern.

Mir stellen sich – mal völlig ungeordnet – ein paar Fragen:

• Warum gibt es immer noch so große Software-Projekte mit 100 und mehr Programmierern?
• Wieso glaubt man immer noch, man könne durch hohe Spezialisierung (Requirement Engineering, Architektur, Qualität, Implementierung, Konfiguration oder Projekt Management …) und Arbeitsteiligkeit in globalen Entwicklungs-Dreiecken wie Indien-USA-Europa erfolgreich und kostengünstig entwickeln?
• Wieso lernt das Management aus den zahlreichen Fehlschlägen und Krisen bei so vielen IT-Projekten nichts?

Hier ein paar Antworten und Thesen, wie man es besser machen könnte:

• Konzentration auf die Zukunft!
  Um Qualität zu schaffen und so wirklich wertvolle Software zu gewinnen würde ich mich zuerst mal auf die neuen Software-Projekte in den Unternehmen  konzentrieren. Das ist an sich schon eine große Herausforderung. Die „alten“ Applikationen würde ich nur soweit anfassen, wie dies unbedingt notwendig ist (es sei denn, ich verfüge über zu viel Ressourcen und Geld). Denn zu groß sind hier in der Regel organisatorische, systemische und menschliche Widerstände, so dass jede hier erzielte Verbesserung sehr teuer erkauft ist.
  Bei neuen Projekten dagegen kann ich zumindest projekt- und methodentechnisch auf grüner Wiese starten und in aller Strenge dafür sorgen, dass falsche Strukturen und Entwicklungen erst gar nicht entstehen.
• Das Können der Mitarbeiter ist alles!
  Ich habe jetzt in über 30 Jahren Erfahrung in SW-Entwicklung gesammelt und immer wieder erlebt, dass nur ein Viertel bis maximal ein Drittel der Menschen, die als Programmierer in den Projekten arbeiten – ganz gleich mit welchen Titeln und Zertifikaten versehen – in der Lage sind, ultimative Qualität abzuliefern. Von den verbleibenden zwei Dritteln sehe ich bei vielleicht der Hälfte das Potential einer gewissen Verbesserung durch intensive Ausbildungs- und Trainingsmaßnahmen. Der Rest wäre besser nie Programmierer geworden. Dieses Verhältnis ist nach meiner Beobachtung in den letzten Jahren nicht besser sondern schlechter geworden. So tummeln sich viele nicht so gut ausgebildete und/oder talentierte Programmierer eifrig in übergroßen Projekten herum und verstecken sich dort in der Masse.
  Ich will damit keinesfalls einen Berufsstand schlecht machen. Ich brauche aber in der Software-Entwicklung durchgängig Ergebnisse mit einer „ultimativen Qualität“. Und die wird in der Tat nur von einem recht kleinen Teil der in den Projekten tätigen Programmierern erbracht.
  Bei „Architekten“ oder „Requirement Engineers“ dürfte die Quote der wirklich qualifizierten noch geringer sein als bei den „Implementierern“, was die Software-Entwicklung noch kritischer macht.
  Die Zahlen sind übrigens bei anderen Branchen nach meinem Eindruck nicht viel anderes. So habe ich auch bei „Handwerkern“ bemerkt, dass in der Regel nur ein Drittel ihren Job so beherrschen, dass qualitativ wirklich gute Werkstücke herauskommen. Und auch da hätte zirka ein Drittel besser einen anderen Beruf gewählt.
  Bei dem Aufbau eines neuen Teams dürfen also nur Kollegen ins Projekt aufgenommen werden, die ihr Handwerk wirklich beherrschen. Das gilt für alle Rollen, diese Selektion ist alles andere als einfach, das ganze viel leichter gesagt als getan – denn zu oft muss man „NEIN“ sagen. Obwohl man dringend Leute braucht. Aber Kompromisse gerade hier rächen sich in der Regel bei der Qualität der Ergebnisse. Und wenn man nur die „guten“ nimmt, dann braucht man viel weniger …
• Kommunikation
  Die Kommunikation im Entwicklungsteam wie zwischen allen Beteiligten im Projekt muss funktionieren! Wie soll das gehen, wenn in vielen Projekten schon gar keine gemeinsame Sprache mehr gesprochen wird? Oder wenn zwar alle Englisch sprechen, jeder dabei aber sein „eigenes Englisch“ dabei hat, das der andere kaum versteht?
  Wichtig ist hier die Anzahl von Meetings stark zu begrenzen. Die Meeting-Flut muss eingedämmt werden. Denn der Nutzen von Meetings sinkt mit der Anzahl von Personen, die teilnehmen und der Länge der Zeit, die sie dauern. Der Schaden steigt in gleichem Maße an. Eine Lösung dieses Dilemmas ist eine Organisation von Kommunikation durch sinnvolle „peer2peer“-Mechanismen.
• „Requirement Engineering“
  Der Versuch, Anwendungs-Software präzise und komplett vor der Implementierung zu beschreiben, hat noch nie zu optimalen Ergebnissen geführt. Immer stellt sich bei solchem Vorgehen heraus, dass dann vieles Unnötiges gebaut wird und dafür aber wesentlich Notwendiges fehlt. Die Folgen sind aufwendige und oft zu implementierten Funktionen widersprüchliche Change Requests. So hängt der Erfolg eines jeden Projekts wesentlich von der Qualität der Person oder den Personen ab, die den „Product Owner“ ausmachen.
  Gute Product Owner wissen nie alles im Voraus, sondern lernen im Entwicklungsprozess laufend dazu. Ein iterativer und agiler Prozess des „Requirement Engineerings“ ist zwingend notwendig. Bei neuen Projekten empfiehlt es sich hier in „user stories“ zu denken und dann (begrenzt) die dazugehörigen „use cases“ zu beschreiben. Das kann aber nur gehen, wenn die Architektur flexibel ist.
• „Flexible Architektur“
  Aufgrund des Lernprozesses der Product Owner und der sich iterativ verändernden Funktionalität wird eine offene und belastbare Architektur zur zentralen Voraussetzung für den Erfolg eines Projektes. Das erhöht die Anforderung an die Architekten aber auch den Anspruch an die Kommunikation zwischen „Product Owner“ und „Architekten“ und letzten Endes dem ganzen Team. Die beiden letzten Punkte gelten nach meiner Meinung übrigens auch nicht nur für Software-Projekte.
• Geisteshaltung
  Die Geisteshaltung streift viele Dimensionen. So müssen alle Projektteilnehmer sich vom ersten Tag einem ultimativen Qualititätsanspruch verpflichten. Sie müssen verstehen, dass sie Qualität in aller erster Instanz für sich selber schaffen. Eine gemeinsame Projektvision muss vorhanden sein. Die Zusammenarbeit muss auf Augenhöhe und gegenseitigem Respekt erfolgen, Politik im Projekt ist ein NOGO. Qualitätssichernde Maßnahmen wie Peer2Peer-Reviews werden zum Standard, Meetings extrem kurz und selten stattfinden und sich auf zwingend notwendige Abstimmungsprozesse beschränken. Dafür kann dann gerne mal öfter der Erfolg gefeiert werden.
  Unnötiger bürokratischer Aufwand ist ein weiteres NOGO, eine „gute“ Projektkultur macht Bürokratie überflüssig. Das Projekt und sein Status sind immer für alle transparent, „Insider“-und „Herrschafts-Wissen“ wird zur Ausnahme. Auf unnötige Aufwände für „estimate“ und „planning“ wird soweit möglich verzichtet!
• Verantwortung
  Die Projektteilnehmer dürfen sich nie auf eine Verantwortungs-Rolle reduzieren. Jeder muss in der Lage sein, „hands on“ anzulegen. Jeder ist zu einem – vielleicht auch nur kleinen Teil – für alles verantwortlich, für Requirement Engineering, Projektsteuerung, Architektur, Qualität, Integration, Konfiguration und Implementierung. Jeder muss mithelfen, unnötige Hürden für freie Kommunikation zwischen allen zu reduzieren. Das gilt für alle, denn alle sind für den Projekterfolg verantwortlich, entsprechend ihrer Qualifikation und Rolle dies natürlich auf unterschiedliche Art und Weise.
• Craftsmanship
  Und alle Beteiligten müssen sich ständig in ihrem Handwerk üben. Sie müssen bereit sein „vom Meister zu lernen“ und ihre besondere „Meisterschaft“ zu vermitteln, sprich auch ihr Können weiterzugeben und ihr Wissen zu teilen.

Wenn diese Bedingungen erfüllt sind, können auch überschaubare Teams Unglaubliches  sowohl in Qualität wie auch funktionaler Quantität leisten. Der oft unnötige Overhead der großen Teams fällt weg. Und die Verwunderung beim Management ist groß, dass ein Zehn-Mann-Team etwas schafft, an dem ein Team mit einer Hundertschaft vorher gescheitert ist.

RMD