Revolutionäre Vorschläge für mehr Agilität Agile Entwicklung 2.0

Redakteur: Stephan Augsten

Agil muss die Softwareentwicklung heutzutage sein, aber wie kann man Development-Prozesse und den Code noch leichtgewichtiger gestalten? Der IT-Dienstleister Avision hat sich mit dieser Frage befasst und einige originelle, wenn nicht gar revolutionäre Vorschläge.

Firmen zum Thema

Gerade in Cloud-Zeiten muss man Entwicklung und Code doch noch leichtgewichtiger gestalten können? Avision hat pünktlich zum 1. April einige Tipps.
Gerade in Cloud-Zeiten muss man Entwicklung und Code doch noch leichtgewichtiger gestalten können? Avision hat pünktlich zum 1. April einige Tipps.
(Bild: SarahRichterArt / Pixabay )

Stillstand ist Rückschritt, das gilt auch für die agile Softwareentwicklung, schreibt Avision. Der IT-Dienstleister hat den agilen Ansatz über mehrere Jahre hinweg analysiert und nach eigenen Angaben Lehren aus der Vergangenheit gezogen.

Die wichtigsten Erkenntnisse und Lehren daraus hat das Unternehmen unter „Agilität 2.0“ zusammengefasst. Mit folgenden revolutionären Schritten lässt sich die agile Softwareentwicklung modernisieren und weiter beschleunigen:

1. 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.

2. 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.

3. 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.

4. Die Kommentierung muss weg

Auch das Kommentieren 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.

5. 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.

6. Product Owner ist der Anwender

„Direktes Feedback“, lautet die Devise. Einen Product Owner braucht es nicht, er steht dem Anwender eh nur im Weg. Soll der dem Entwickler lieber selbst 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“, merkt Nadine Riederer, CEO bei Avision, mit einem Augenzwinkern an. „Dennoch begegnen einem solche Vorstellungen immer wieder. Und man denkt sich dann intuitiv: das kann nur ein Aprilscherz sein!“

(ID:47321315)