So geht agile Softwareentwicklung 2.0

Stillstand ist Rückschritt. Das gilt auch für die agile Softwareentwicklung. Der IT-Dienstleister Avision hat den agilen Ansatz über mehrere Jahre hinweg analysiert und Lehren aus der Vergangenheit gezogen. Pünktlich zum 1. April schlägt er einige revolutionäre Schritte zur Modernisierung der agilen Softwareentwicklung vor.

Das zeichnet Agilität 2.0 aus:

• Je weniger Entwickler, desto besser. Viele Entwickler kosten auch viel Geld. Am Ende diskutieren sie noch rum und verzögern damit das Projekt. Am effizientesten ist ein Team, das aus exakt einem Entwickler besteht. Das ist am billigsten und der Kommunikationsaufwand innerhalb des Teams sinkt auf null.
   
• Sicherheit ist überbewertet. Auch bei der Sicherheit einer Software gibt es Einsparpotenziale. Und was macht es angesichts eines lachenden Geldbeutels schon, wenn dann in der Produktion mal ein oder zwei Datensätze verloren gehen? Hundertprozentige Sicherheit braucht kein Mensch, 95 Prozent reichen auch.
   
• Die Codequalität spielt keine Rolle. Mal ehrlich: Bei Code kommt es doch nur darauf an, dass er funktioniert. Wie er das macht, ist am Ende des Tages völlig wurscht. Und wenn ein anderer Entwickler den Code nicht lesen kann, dann ist er halt einfach ein schlechter Entwickler. 
   
• Die Kommentierung muss weg. Auch die Kommentierung des Codes kann man sich schenken. Der große Vorteil dabei: Er wird um bis zu ein Drittel kleiner und man muss weniger lesen. Und in den Kommentaren steht doch sowieso meistens was anderes als das, was der Code macht.
   
• Testumgebungen sind sowas von überflüssig. Was an einer Software wirklich funktioniert und was nicht, sieht man erst im Produktivbetrieb.
  Also warum vorher in Testumgebungen testen? Dann lieber gleich mit echten Testfällen in der Produktion. Also: Einfach ausrollen das Teil und der Anwender schaut dann mal wie’s läuft. Auch das spart jede Menge Kohle.
   
• Product Owner ist der Anwender. Direktes Feedback heißt die Devise. Einen Product Owner braucht es nicht, er steht dem Anwender eh nur im Weg. Soll der dem Entwickler lieber selber sagen, was er braucht. Der Entwickler kann dann direkt in der Produktivumgebung Änderungen vornehmen und der Anwender guckt, ob‘s passt.

„Genau so sollte man es natürlich nicht machen“, sagt Nadine Riederer, CEO bei Avision, mit einem Augenzwinkern. „Dennoch begegnen einem solche Vorstellungen immer wieder. Und man denkt sich dann intuitiv: das kann nur ein Aprilscherz sein!“

www.avision-it.de