Wie bringe ich meinem Auftraggeber bzw. meiner Auftraggeberin bei, dass ich zukünftig testbasiert entwickeln möchte? Wann rechnet sich welches Qualitätsniveau? Wie argumentiere ich für dieses Vorgehen?
Teil 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | Kapitelauszug aus "Software-Qualität in PHP-Projekten", 2. Auflage. Erschienen im Hanser-Verlag, April 2013.
Testbasierte Entwicklung verkaufen

Durch die testbasierte Entwicklung fokussiert das Software-Team auf die Erstellung neuer Software-Funktionen. Testbasiert zu arbeiten führt zu einem geringeren Bedarf an Wartungsarbeiten (in Form von Fehlerbehebungen). Die Motivation, auf eine testbasierte Ent- wicklung umzusteigen, ist also groß. Nicht nur, weil technisch schönerer Code entsteht, sondern vor allem weil sich das Software-Team darauf konzentrieren kann, neue Funktionen zu bauen.
Diesem Ausblick steht das Wissen gegenüber, dass die Umstellung und die initiale Phase testbasierter Entwicklung teurer ist als das bisherige Vorgehen. Wie kann das Software- Team diese Aufwände gegenüber dem Auftraggeber beziehungsweise der Auftraggeberin vertreten – und eine Zustimmung, das heißt eine Kostenübernahme für den initialen Mehraufwand, erreichen?
Die nachfolgenden Erläuterungen sind aus der Sicht eines Software-Teams, das mit einem Auftraggeber beziehungsweise einer Auftraggeberin ein verändertes, testbasiertes Entwicklungsverfahren vereinbaren möchte, formuliert. Für andere Rollen im Projekt – beispielsweise Vorgesetzte des Software-Teams – sind die inhaltlichen Begründungen für die testbasierte Entwicklung gleich beziehungsweise ergeben sich im Umkehrschluss. Die eigentliche Verhandlungssituation ist nur aus der Sicht des Software-Teams beschrieben.
Alle Argumente gelten sowohl für eine im Unternehmen intern durchgeführte Software- Entwicklung als auch für Dienstleister, die für einen externen Auftraggeber beziehungsweise eine externe Auftraggeberin Software entwickeln. Zur Vereinfachung wird im Folgenden von dem Software-Team und einem Auftraggeber beziehungsweise einer Auftraggeberin gesprochen.
Vom prozeduralen Code zum testbasierten Vorgehen
Viele Software-Projekte starten – entsprechend des Ausbildungsstands der Entwickler und Entwicklerinnen – mit prozeduralem Code. Es folgt der Umstieg in objektorientierte Pro- grammierung. Mit dieser ist die Einführung testbasierter beziehungsweise testgetriebener Entwicklung möglich. Mit wachsender Erfahrung formulieren Entwickler und Entwicklerinnen das Ziel, qualitätsvolle Software entwickeln zu wollen. Der Weg dorthin erfolgt über ein durch Tests abgesichertes Verfahren, wie es in diesem Buch für PHP beschrieben wird.
Während sich der Umstieg von prozeduraler zur objektorientierten Programmierung aus Auftraggebersicht nahezu kostenneutral darstellt, führt die Einführung testbasierter Ent- wicklung zu Mehraufwänden. Weil der erste Schritt sich weitestgehend kostenneutral für den Auftraggeber oder die Auftraggeberin darstellt, wird dieser gegenüber den Auftraggebern häufig nicht erwähnt.
Mit der Umstellung auf ein testbasiertes Vorgehen verändert das Software-Team den Kostenrahmen. Initial sind höhere Aufwände zu finanzieren. Es entsteht Kommunikationsbedarf über die Übernahme dieses Mehraufwands, indirekt entsteht Kommunikationsbedarf über das Vorgehen des Software-Teams. Dieser Kommunikationsbedarf wird induziert durch einen Vorgehensvorschlag – Vorgehensmodelle sind häufig zu diesem Zeitpunkt nicht Bestandteil der üblichen Projektkommunikation. Mit der Kostendebatte, die durch den Wunsch nach einer testbasierten Entwicklung ausgelöst wird, wird erstmals ein Vor- gehensmodell zwischen dem Software-Team und dem Auftraggeber beziehungsweise der Auftraggeberin verhandelt.
Die Erläuterung, warum nicht testbasiert entwickelt wird, enthält häufig eine Konjunktiv-Formulierung: „Das würde unser Auftraggeber sowieso nicht zahlen.“ Dieser Konjunktiv zeigt an, dass die eigentliche Verhandlung um die initialen Mehraufwände für testbasierte Entwicklung nicht geführt wurde. Die Software-Teams verzichten wider besseren Wissens auf eine testbasierte Entwicklung, weil sie die einmalige Verhandlung beziehungsweise Auseinandersetzung um die Herangehensweise des Teams fürchten.
Dabei sind zwei hauptsächliche Beweggründe zu bemerken, die Software-Teams davon abhalten, testbasierte Entwicklung in das Projektvorgehen hinein zu verhandeln:
-
Im Projektumfeld herrscht ein hoher Kostendruck. Zum üblichen Ritual zwischen dem Auftraggeber beziehungsweise der Auftraggeberin und dem Software-Team gehört es, dass der Auftraggeber beziehungsweise die Auftraggeberin unter Hinweis auf den hohen Kostendruck eine Kürzung der anfangs vorgelegten Aufwandsschätzung verlangen. In diesem Umfeld ist es schwer, für ein verändertes Vorgehen Mehraufwände aufzurufen.
-
Das Software-Team fürchtet um seine Reputation. Die offensive Benennung von Qualitätssicherung oder Tests als Aufwandstreiber führt zu der Frage, ob das Team bisher nicht auf Qualität geachtet hat. Das veränderte Vorgehen stellt das bisherige Vorgehen infrage.
Im ersten Fall ist durch Aufruf höherer, initialer Kosten eine unangenehme, druckvolle Ver- handlung zu erwarten. Das Software-Team fürchtet, durch die Erhöhung der Kosten nicht mehr als Entwicklungspartner beauftragt zu werden. Im zweiten Fall verspürt das Software- Team ein latent schlechtes Gewissen über die bisherige, nicht ausreichende Qualität.
Aus dieser Haltung heraus sind Mehraufwände schlecht zu vermitteln und positiv zu verhandeln. Dabei ist testbasierte Entwicklung im Interesse des Software-Teams und des Auftraggebers beziehungsweise der Auftraggeberin: Funktionale, gebrauchstaugliche, zuverlässige, effiziente und wartbare Software reduziert die Betriebs- und Wartungskosten.
Software-Teams entscheiden sich für eine durch Tests abgesicherte Entwicklung, um die interne Qualität der Anwendung zu erhöhen. Im laufenden Betrieb notwendige Erweiterungen sind leichter implementierbar. Es ist insbesondere möglich, fachlich wie technisch sicherzustellen, dass die vorgenommenen Änderungen beziehungsweise Erweiterungen keine ungewollten Seiteneffekte im bereits vorhandenen Code auslösen.
Die Umstellung auf ein testbasiertes Vorgehen führt initial zu Mehraufwänden. Wie können Software-Teams intern wie extern diese initialen Mehraufwände sinnhaft erläutern?
Teil 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | Kapitelauszug aus "Software-Qualität in PHP-Projekten", 2. Auflage. Erschienen im Hanser-Verlag, April 2013.
- Nächster Artikel: PHP Magazin | Erfolgreich lernen!
- Vorheriger Artikel: In eigener Sache: Schreibstille
Kommentar schreiben
Christoph (Donnerstag, 04 April 2013 14:01)
Eines vorab: Ich unterstütze Bestrebungen bezüglich geschlechtergerechtem Formulieren in Texten.
Hier jedoch finde ich, ist es etwas über die Stränge geschlagen.
Schon in diesem kurzen Auszug wird das Wort "beziehungsweise" 12 mal verwendet. 8 mal allein nur um "Auftraggeber" und "Auftraggeberin" zu unterscheiden.
Hier würde ich mir ein besseres Korrekturlesen wünschen. Wenn sich diese Anhäufung durch mehrere Kapitel (geschweige denn durch das gesamte Buch) durchzieht, wird das Lesen sehr anstrengend werden.
Judith Andresen (Donnerstag, 04 April 2013 17:01)
Hallo Christoph,
alle anderen Kapitel im Buch sind geschlechterneutral geschrieben. Alle anderen Kapitel stammen von Männern ;-)
Ich war in Bezug auf die vielen "beziehungsweise" auch unsicher, wusste mir aber leider nicht besser zu helfen. Ich werde - nach Deinem Feedback - in der nächsten Runde deutlicher mit dem Lektorat diskutieren, wie mit einer geschlechtergerechten Formulierung umzugehen ist.
Judith
Christoph (Donnerstag, 04 April 2013 17:20)
Ich habe das Buch so oder so vorbestellt. ;)
Hier war es eben nur ein Beispiel, was mir ziemlich schnell auffiel, weil mein Lesefluss davon betroffen war. Gut möglich, dass ich an dieser Stelle pedantischer als andere Leser bin, wollte den Hinweis dennoch hinterlassen.
Ansonsten ist es ja ein guter und nachvollziehbarer Text.
Ich freue mich jedenfalls, das Buch demnächst in der Post zu haben.
Vielen Dank!
Nils (Mittwoch, 10 April 2013 14:30)
Bezüglich der geschlechtsneutralen Schreibweise.
Ich meine gehört zuhaben, dass dies eine Erlaubte Form ist:
http://de.wikipedia.org/wiki/Gendering
Also wären dies zwei denkbare Schreibweisen: AuftraggeberIn oder Auftraggeber_in