in Agilität, Anforderungsanalyse, Praxistipps

Fehler oder Feature, das ist oft die Frage!

Wenn es ein umfassendes und detailliertes Pflichtenheft gibt und dazu eine Fixpreisvereinbarung, dann ist es ganz wichtig, zwischen Fehlern und zusätzlichen Anforderungen zu unterscheiden. Wenn also beim Test oder gar bei der Endabnahme ein Verbesserungsvorschlag auftaucht, dann wird intensiv im Pflichtenheft und in Protokollen, Tickets etc. gesucht, ob diese Anforderung dort schon formuliert wurde und daher im Fixpreis enthalten ist oder ob dafür zusätzliches Budget erforderlich ist. Erfahrene Anwender machen daher versuchsweise eine Fehlermeldung und hoffen, auf diesem Weg das Gewünschte zu erreichen. Das wiederum bringt heftige Gegenreaktionen von Seiten der Entwickler, vor allem, wenn das ein gut organisiertes, budgetgetriebenes Unternehmen ist. Die Auseinandersetzung um solche Fragen kann oft deutlich mehr Aufwand verursachen als die rasche Umsetzung der Anforderung gekostet hätte, aber es geht ja ums Prinzip und es gilt „Wehret den Anfängen!“.

Solche Mechanismen können ein Projekt ganz schön belasten, ein Fallbeispiel habe ich an anderer Stelle schon geschildert. Wie löst man dieses Problem bei agilen Projekten? Ist das ein Wunschkonzert, bei dem Aufwand keine Rolle spielt? Kann wohl nicht sein, aber wie geht man damit um?

Fehler oder Feature – der Unterschied ist am Ende gering

Diese These wird viele provozieren: „Der Unterschied zwischen Fehlerbehebungen und der Implementierung von neuen Features ist minimal“. Technisch gesehen macht es einen Unterschied, ob man in eine bestehende Software eingreift oder ob man „from scratch“ eine Software erstellt. Letzteres ist allerdings die Ausnahme und das aus zwei Gründen: 1. bauen die meisten Softwareprojekte auf bereits vorhandenen Softwarekomponenten bzw. -bibliotheken auf, die angepasst, ergänzt und konfiguriert werden und 2. sobald man in einem Projekt weiter fortgeschritten ist, sind die meisten Features, die man implementiert Eingriffe in bereits vorher geschriebenen Code.

Fehlerkorrekturen sind so gut wie immer Eingriffe in bestehenden Code, der einzige Unterschied ist, dass jemand geglaubt hat, dass dieser Code schon die gestellten Anforderungen erfüllt und sich dabei geirrt hat. In der Auswirkung ist der Unterschied vernachlässigbar: Jeder Eingriff bringt die Gefahr neuer Fehler mit sich und es kann ja sogar der Eingriff selbst schon fehlerhaft sein.

Ob man eingegriffen hat, weil man ein Feature erstmals implementiert oder dies tut, weil der erste Implementierungsversuch nicht vollständig gelungen ist, macht keinen Unterschied hinsichtlich des damit verbundenen Aufwandes und Risikos. Der Unterschied ist einerseits ein emotionaler, es macht mehr Freude, etwas neu zu implementieren und meist wenig Freude, Fehler zu korrigieren. Andererseits ist es aus vertraglicher Sicht oft ein wesentlicher Unterschied, Fehler fallen eventuell unter Gewährleistung und sind von der Entwicklungsfirma zu tragen.

Lassen wir die Emotionen hier beiseite, bleibt nur der vertragliche und damit auch kaufmännische Aspekt. Aber auch der ist stark zu relativieren. In jeder Aufwandskalkulation ist ein gewisser Anteil für Fehlerbehebungen enthalten. Solange dieser Aufwand im Rahmen und das Projekt insgesamt im Budget bleibt, ist der Aufwand für Fehlerbehebungen eine interessante Metrik, aber ansonsten ohne Relevanz.

In einem agilen Projekt wird der Aufwand je User-Story geschätzt, einen echten Fixpreis kann es nicht geben. Auch wenn Autoren mit einem „agilen Festpreis“ werben, es ist kein Fixpreis, sondern eine mehr oder raffinierte Verrechnung nach tatsächlichem Aufwand („time and materials„). Meine Sicht auf das Thema habe ich schon an anderer Stelle dargestellt. Hier soll es um den konkreten Umgang mit Anforderungen und Fehlermeldungen in einem agilen Softwareprojekt gehen.

Priorisierung von Anforderungen – was zählt?

Anforderungen (ob in der Form von User-Stories, Use-Cases, Features etc. beschrieben, macht hier keinen Unterschied) sollten nach standardisierten Kriterien beurteilt werden. Prägnant nennt z.B. Dean Leffingwell folgende Kriterien (s. 209):

  1. Der Wert für die Anwender (User Value)
  2. Der Schaden, wenn man es nicht realisiert
  3. Das Risiko, es umzusetzen
  4. Die Kosten der Umsetzung
  5. Der potenzielle finanzielle Nutzen (ROI) der Umsetzung.

Nun ist die Frage, ob diese Kriterien sich im Verlaufe des Projektes ändern. Ich sage: Nein! Die Gewichtung der Kriterien ändert sich, aber nicht die Kriterien selbst. Gehen wir zum Ende eines Projektes, also knapp vor dem letzten Deployment. Hier wird das Risiko der Umsetzung (3) eine viel größere Rolle spielen als zu Beginn des Projektes, weil jeder Eingriff erfahrungsgemäß mit dem Risiko einer Destabilisierung des Systems verbunden ist. Daher geht man in dieser Phase oft dazu über, nur bei hohem Score im Kriterium 2 einer Umsetzung zuzustimmen. Das Kriterium 1 wird nicht mehr besonders gewichtet, weil man davon ausgeht, dass alles, was einen Geschäftsnutzen bringt, bereits identifiziert und umgesetzt wurde. Also werden nur noch Fehler korrigiert, die entweder gegen gesetzliche Vorgaben verstoßen und/oder zu Verarbeitungsfehlern mit Außenwirkung führen. Daraus entsteht oft der Eindruck, dass zwischen Fehlerkorrekturen und der Realisierung von Anforderungen ein grundsätzlicher Unterschied besteht.

Es ist aber egal, wie das System destabilisiert wird, auch eine Fehlerkorrektur kann einen massiven Eingriff erfordern und ist daher mit hohem Risiko verbunden. Vielleicht ist dieser Fehler durchaus tolerierbar (per Workaround neutralisierbar). Vielleicht ist hingegen ein zusätzliches Usability-Feature (z.B. eine zusätzliche formale Prüfung von Eingaben) mit geringem Risiko verbunden und senkt die Schulungskosten,  die Kosten für Fehlerkorrekturen in der laufenden Verarbeitung und verbessert so den ROI (5). Dann sollte man das Usability-Feature umsetzen, solange man genügend Kapazität bzw. Budget dafür zur Verfügung hat. Ich muss allerdings anmerken, dass ich noch keinen Auftraggeber erlebt habe, der es wagt, solche Entscheidungen in der heißen Phase eines Projektes zu treffen. Es wird regelmäßig ein Code-Freeze ausgerufen, dieser wird mehrfach aufgeweicht, weil Fehler zu korrigieren sind und jeder, der es wagt, ein Usability Feature in dieser Phase einzubringen, wird wegen mangelndem Verständnis für den Ernst der Lage zurechtgewiesen.
Wenn ein Projekt gut läuft, dann werden solche Themen ohne große Diskussion erledigt, vor allem wenn durch ein agiles Vorgehen enger Kontakt zwischen Anwendern und Entwicklungsteam besteht. Natürlich ist das tendenziell gefährlich, denn die Grenze zur Anforderungsdefinition per Zuruf ist schnell überschritten. Ein Product Owner, der seinen Job gut macht, kann entscheiden, was man auf kurzem Weg erledigt und welche Systemverbesserungen man blockieren muss, auch wenn es auf den ersten Blick harmlos wirkt.

Zusammen gefasst ist meine These: Zwischen Feature und Bug ist der wesentliche Unterschied, dass der Bug eine Abweichung von einer schon definierten Anforderung ist und dass gefordert wird, diese Abweichung zu beseitigen. Sofern es sich um ein Fixpreis-Projekt handelt, muss für diesen Aufwand die Entwicklungsfirma aufkommen und dem Kunden fällt es schwer, darauf zu verzichten, auch wenn es aus einer objektiven Priorisierungssicht sinnvoller wäre, auf diese Fehlerbehebung im Moment zu verzichten und dafür lieber ein zusätzliches Feature umzusetzen, dass hohen Wert für das Geschäft des Kunden hat.

In einem agilen Projekt, das letztlich nach Time&Materials abgerechnet wird, fällt so ein Abtausch leichter. Der Auftraggeber disponiert über die Ressourcen des Realisierungspartners und ob diese für die Behebung eines Fehlers oder für ein neues Feature eingesetzt werden, macht kommerziell keinen Unterschied. Wer jetzt glaubt, ich rede einem verantwortungslosen Umgang mit den Leistungen der Softwareentwickler das Wort, bei dem Fehler beliebig toleriert werden und folgenlos bleiben, bitte ich, meinen schon weiter oben erwähnten Beitrag zu diesem Thema zu lesen.

Hier noch das oben zitierte Buch von Dean Leffingwell, das ich generell sehr empfehlen kann:

Schreibe einen Kommentar

Kommentar