Darf Agilität vor Qualität gehen?



  • Agile Prozesse liegen im Trend. Überall bemühen sich Unternehmen darum, ihre Teams schneller, autonomer und agiler arbeiten zu lassen. Die Qualität der Software-Produkte sollte darunter aber nicht leiden. Doch wie lässt sich das sicherstellen?

    Klicken sie hier um den Artikel zu lesen



  • Agile Arbeitsweise ist nicht nur eine, die wenig testet. Sie dient auch als Ausrede, nicht dokumentieren zu müssen was man tut. Damit ist es wieder möglich, so verfilzt zu programmieren, dass kein Kollege mehr durchblickt und man sich unentbehrlich macht. Diese Zeiten waren eigentlich schon lange vorbei, als Qualitätsstandards und vor allem objektorientierte Programmierung eingeführt wurden. Da sollte eigentlich jedes Objekt einzeln funktionieren und sich konstruktiv verhalten, damit es universell einsetzbar ist und zum Gelingen des Projekts beiträgt. Mit agiler Entwicklung ist es möglich, ein fehlerhaftes Objekt zu verwenden, wobei der Fehler dann in einem anderen Objekt durch einen weiteren Fehler wieder behoben wird. Dann wird am Ende getestet und alles passt. Wenn aber ein Kollege so ein Objekt verwenden will, wird seine Arbeit scheitern. Wenn dann ein anderer Kollege versucht, den Fehler zu beheben, wird der durch Korrektur des Objekts behoben. Aber dann funktioniert die andere Verwendung des Objekts nicht mehr, die den Fehler voraussetzte. Agilität ist oft die Ausrede für destruktives Programmierverhalten, wo ein einzelner das ganze Projekt zum Scheitern bringen kann und Korrekturen nur weitere Fehler erzeugen. Gelungene Projekte basieren auf konstruktiven Programmierern, deren Software auch elementar transparent und nachvollziehbar die Aufgaben löst und zur Synergie des Projekts beiträgt, indem sie vernünftig reagiert und bei Unerwartetem nicht gleich alles abbricht.



  • Hmm, ich bin mir nicht sicher, ob Agilität hier richtig verstanden wird. Das magische Dreieck ist mir aus dem Projektmanagement bekannt. Agilität kennt aber keine Projekte. Wenn agle arbeitsweisen genutzt werden (das werden sie leider noch viel zu oft), um Projektpläne "abzuarbeiten" bezweiflie ich, dass das die richtige Lösung ist. Ich zweifle auch daran, dass agile arbeitsweisen "schneller und günstiger" sind, wenn man Projekte abarbeiten will. Wenn sich Unternehmen so aufstellen, dass sie in Produkten denken und unabhängige Teams aufstellen, die mit dem Kunden agieren, aufgestellte Hypothesen stetig überprüfen und den Kunden Stück für Stück Futter geben, um seine Zufriedenheit zu steigern und damit kontinuierlich Wert zu schöpfen, ist das eine gute Sache. Ich mache zumindest die Erfahrung, dass das funktioniert. Aber eben nicht, wenn man in Projekten denkt. Ich glaube das kein Kunde sich mit qualitativ minderwertigen Produkten zufrieden gibt. Somit ist Qualität, wenn man dem Nutzer nah ist, immer ein Thema für agile Teams. Da kommt man garnicht dran vorbei. Wenn ein guter Scrum Master Kontinuität und Flow im Blick hat, kommt man auch nur schwer an CI und CD und der damit einhergehenden Testautomatisierung vorbei. So sind zumindest meine Erfahrungen.
    Ich kann verstehen, dass das Thema Agilität ankotzt, wenn es vom Unternehmen nicht richtig angegangen wird. Für mich findet Agilität vor allem im Management statt. Leider wird es oft nur auf Entwicklungsteams bezogen.


Log in to reply