Die Entwicklungszeit in Projekten ist teuer und sollte deshalb möglichst Wert schöpfend und effizient genutzt werden. Dazu sollte das Entwicklungsziel immer im Auge behalten werden und nur die vom Kunden bzw. Stakeholder geforderten Produktfunktionen implementiert werden.
Grundsätzlich handelt es sich bei dem YAGNI (You Aren't Gonna Need It) Prinzip um ein einfaches Prinzip, dass in der Praxis aber schwer einzuhalten ist. Besonders Softwareentwickler neigen dazu, ungeplante Funktionen „schnell mal“ einzubauen.
Werden Funktionen in das Produkt eingebaut, die nicht vom Stakeholder gefordert sind, ergeben sich daraus einige Probleme für das Produkt:
-
Da die zusätzlichen Funktionen dem Kunden keinen Wert liefern, wird er sehr wahrscheinlich nicht bereit sein hierfür zu bezahlen. Zudem verlängert sich die Entwicklungszeit für das Produkt. Beides wird sich negativ auf die Zufriedenheit des Kunden auswirken.
-
Der vereinbarte Produktumfang ändert sich (Scope creep) und wird schwerer planbar.
-
Für die zusätzlichen Funktionen müssen Tests entwickelt und Dokumentation geschrieben werden. Im Laufe des Produktzyklus müssen dies Stellen ebenfalls angepasst werden, wodurch noch zusätzlicher Pflegeaufwand entsteht.
-
Die Komplexität des Produkts steigt ohne Nutzen an und das Risiko für Fehler in der Software steigt an.
In der Praxis sind es meistens nicht vollständig neue Funktionen, die in ein Produkt eingebaut werden. Ich erlebe es immer wieder, dass etwas in „weißer Voraussicht“ eingebaut wird, da entweder die Spezifikation noch nicht vollständig fertig ist, aber man schon mal etwas implementiert oder da davon ausgegangen wird, dass die Funktion in Zukunft mal gebraucht wird. Es kann aber auch oft vor, dass nicht mehr gebrauchte Funktionen deaktiviert oder nur teilweise entfernt werden. Dieses Vorgehen birgt zusätzliche Risiken:
-
Für die neuen, ungebrauchten Funktionen müssen bereits Tests implementiert werden, was zusätzlichen Aufwand bedeutet.
-
Werden erst gar keine oder nicht ausreichend Tests für die ungenutzte Funktionalität implementiert, stellt dies ein erhebliches Qualitäts- und Sicherheitsrisiko in der Software dar, auch wenn sie noch nicht verwendet werden. Zudem fehlen bei ungenutzten Funktionen auch System- bzw. explorative Tests, da sie noch niemand verwendet oder verwenden kann.
-
Die Komplexität und der Speicherverbrauch der Software steigt ohne Nutzen an. Dies ist im Embedded-Systems Bereich ein besonderes Problem, da die Software hier ressourcenschonend entwickelt werden muss.
Das YAGNI Prinzip lässt sich einfach anwenden, wenn folgende Punkte beachtet werden:
-
Es werden nur Funktionen eingebaut, für die es eine nachvollziehbare Anforderung von mindestens einem Stakeholder gibt. Ist eine Anforderung oder Spezifikation unklar, muss dies vorab geklärt werden.
-
Wähle eine Architektur, die sich im Produktzyklus einfach skalieren bzw. anpassen lässt, z.B. durch Softwareupdates. Dadurch sinkt der Druck in der Entwicklung, vorausschauend und noch ungenau spezifizierte Funktionen einzuplanen bzw. einzubauen.
-
Entferne Funktionen vollständig aus deiner Software, wenn sie nicht mehr verwendet werden.
-
Es kann es sinnvoll sein, regelmäßig mithilfe von Tools oder durch ein Review die nicht mehr benötigten Teile der Software zu finden, damit sie nachträglich entfernt werden können.