Softwarequalität beginnt mit der Anforderungsanalyse zum System, in unserem Fall mit den Anforderungen für unser ERP-System. Analysieren wir unsere Anforderungen falsch, unvollständig oder gar nicht kann die Qualität unseres ERP-Systems kaum genügend sein. Die Usability, fester Bestandteil von Softwarequalität, wird sich bedingt proportional zu der Integration von Anforderungen durch uns in unser System verhalten. Implementieren wir viele unglaubliche Features die niemand braucht mag und das zwar viel Entwicklungsspaß bringen, bei den Anforderungen haben wir aber klar gepatzt und unsere Usability … ihr ahnt es bereits. Nun hatte ich in meinem letzten Beitrag bereits festgestellt, dass die vollständige Umsetzung aller Anforderungen ein Bestandteil des Qualitätpunktes Anforderungsanalyse ist – ungünstig das die Summe der Anforderungen ein ungesunden Verhältnis zu unserer Arbeitszeit hat.
Ich kann mir nicht helfen, aber in dieser Situation entsteht für uns ein Konflikt. Natürlich wollen wir ein super System bauen und alle Anforderungen der Anwender umsetzen, trotzdem müssen wir mit den vorhanden Entwicklern auch an dem großen Gesamtziel – Gesamtumsetzung ERP-System – hinterher eilen. Vor geraumer Zeit haben wir bereits angefangen zu scrumen.Wir hatten den Vorteil eines agilen Vorgehensmodelles für uns erkannt und kommen alle zwei Woche zusammen um zu beraten welche Punkte umgesetzt werden sollen und was wir für diese Punkte an Umsetzungsaufwandveranschlagen, ganz wie es SCRUM verlangt. Toll, alles super – wir haben einen Plan und nun kann nix mehr schief gehen. Ich muss etwas ausholen um zu meinem Problem zu kommen. Wir setzen unser System modular um und geben einzelne Module nach Fertigstellung zur Nutzung frei. Bereits aktive Module wären Bestellwesen, Stücklistenwesen und 23 weitere Module. Der nächste dicke Fisch ist unser Planungsmodul, geplante Freigabe dieses Jahr. Wir haben also folgende Komponenten: Anforderungsanalyse nach agilen Ansatz betreiben wir, Planung der Aufgaben mit Zeitschätzung und Verbuchung von Zeiten haben wir, einen Haufen cooler freigegebener Module haben wir und ein Ziel für das nächste Modul haben wir auch. Toll.
Irgendwie nicht toll. Etwas gnaschig musste ich jüngst feststellen, dass die gebuchten Stunden zu der Implementierung des Moduls Planung nicht für eine rasche Umsetzung des Moduls sprechen. Wie kann das sein? Das Problem ist die vollständige Umsetzung aller Anforderungen, ihr wisst der Unterpunkt für gute Softwarequalität. Wir investieren soviel Energie in die Abrundung und Verbesserung der freigegebenen Funktionen, dass die Arbeiten für das gänzlich neue Modul nicht fokussiert genug betrieben werden. Fazit: Softwarequalität steht in Konkurrenz zu zügiger Weiterentwicklung. Antwort: Wir müssen nicht nur die Zeiten der Aufgaben schätzen die wir umsetzen wollen, sondern im Vorfeld prozentual festlegen wie viel Zeit wir zum abrunden und weiterkommen aufbringen wollen – na klar, ist einfach, haben wir aber nicht gemacht, haben wir nun aber vor. Ideen sind toll, aber unserer Stammtisch hat gesagt nur kontrollierte Ideen haben eine Chance – der Informatiker würde sagen wir brauchen eine Metrik. Gefühlt können wir uns mit einem einfachen Report helfen, sobald ich was habe reiche ich das nach.
