Softwareentwicklung bisher und in Zukunft

Bisher verlief die Softwareentwicklung in verschiedenen Phasen, die linear durchlaufen wurden. Aufgrund der Darstellung wird dieses Modell auch Wasserfallmodell genannt.
Hierbei stellen die Ergebnisse einer Phase die Grundlage der darauffolgenden Phase dar.

Die Phasen im Einzelnen:

• Definieren der Anforderungen
• Erstellen eines Konzepts (unterteilt in Grobkonzept und Feinkonzept)
• Codieren des Programms
• Verfassen der Anwenderdokumentation
• Qualitätssichern/Testen des Programms sowie der Anwenderdokumentation
• Schulung von Kundenberatern und Supportmitarbeitern
• Ausliefern des Produkts

Dieses Konzept ist durchaus effizient - allerdings nur unter der Voraussetzung, dass sich die Anforderungen zwischen dem ersten Auftrag und der Auslieferung nicht ändern!

Hinweis: Sofern das bei einem Projekt der Fall ist, gibt es meines Erachtens keine zwingende Notwendigkeit, an diesem Vorgehen etwas zu ändern.
Ich bin kein Freund davon, einen etablierten Prozess nur nur um der Änderung willen zu ändern.
Denn Änderungen kosten Zeit und Kraft, die anderweitig sicher besser investiert wäre.

Allerdings ist die Voraussetzung mittlerweile nicht mehr unbedingt gegeben - falls sie es jemals war.

Nachteilig an der bisherigen Softwareentwicklung ist

• für die Kunden, dass sie relativ lange warten müssen, bis sie das Produkt einsetzen können
• für den Hersteller, dass er relativ lange auf Einnahmen durch den Verkauf warten muss, da die Kunden in der Regel erst bei Lieferung des Produkts zahlen.

Da es jedoch mittlerweile eine wesentlich stärkere Vernetzung der Welt gibt, gibt es auch eine erheblich größere Konkurrenz. Und dadurch wächst die Gefahr, dass ein Konkurrent schneller auf die Wünsche der Kunden reagiert.

Softwareentwicklung in der Zukunft
Seit einigen Jahren geistert eine Methode durch die Softwareentwicklungsabteilung, die geradezu wunderbares verspricht:
Der Kunde soll das gewünschte Produkt sowohl innerhalb der vereinbarten Zeit erhalten und auch nicht mehr zahlen müssen als zu Beginn vereinbart.
Und das gilt selbst dann, wenn er während der Entwicklungszeit seine Wünsche ändert.

Klingt zu gut um wahr zu sein!?!
Die Lösung heißt agile Softwareentwicklung.

Diese gibt es in verschiedenen Ausprägungen. Die wohl in der Softwareentwicklung am häufigsten verwendete Methode heißt "Scrum", andere Methoden heißen Kanban oder eine Mischung aus beiden Methoden namens "Scrumban".
Ich möchte die Methoden in diesem Artikel gar nicht genau erklären, sondern mich auf die meiner Meinung nach wesentlichen Änderungen konzentrieren.
Wenn Ihr weitere Artikel zu einer bestimmten Methode möchtet, dann wäre es schön, wenn Ihr einen entsprechenden Kommentar hinterlassen würdet.

Das meiner Meinung nach Wichtigste ist, sich auf eine grobe Richtung einig zu sein und anschließend immer wieder gemeinsam neue Schritte zu vereinbaren.
Damit ist die Sozialkompetenz der Softwareentwickler viel mehr gefragt als früher.
Denn früher konnte man sich nach dem Herausarbeiten der Anforderungen in sein stilles Kämmerchen zurückziehen, um "ohne Tageslicht bei Pizza und Cola" und Kontakt zu anderen Menschen das Programm herunterzuschreiben.
Heutzutage ist man gezwungen, ohne eine genaue Spezifikation des gesamten Programms (aber erst nach einer genauen Spezifikation der nächsten Teilaufgabe!) loszulegen und dem Auftraggeber in relativ kurzen Zeitabständen eine (Zwischen-)Lösung zu präsentieren und dann evtl. zu hören, dass die Umsetzung nicht ganz den Vorstellungen entspricht oder sich die Ziele zwischenzeitlich geändert haben, weshalb man die zuletzt umgesetzte oder die als nächstes geplante Funktionalität nicht mehr benötigt. In diesem Fall ist es wichtig, diese Meinung zu akzeptieren und gemeinsam ein neues Ziel zu erarbeiten.

Was wird sich also in der Softwareentwicklung in Zukunft ändern bzw. ändert sich gerade?

Auftraggeber/Kunde
Die Rolle des Auftraggebers/Kunde wandelt sich vom Bittsteller zum Partner.
Früher musste man (zumindest gefühlt) dankbar sein, wenn sich ein "Programmierer" mit der Aufgabe beschäftigte, sich die Anforderungen anhörte, verschwand und dann irgendwann mit dem fertigen Programm ankam.
Heutzutage ist er ein Gesprächspartner, der zusammen mit dem Entwicklungsteam eine möglichst gute Lösung entwickelt und im Entwicklungsprozess dabei ist.
Wenn sowohl der Abgabetermin als auch die Kosten feststehen, muss er sich während des Entwicklungsprozesses immer wieder überlegen, welche Funktionen er haben möchte und auf welche er ggf. verzichten muss, weil sich seine Anforderungen geändert haben oder während des Entwicklungsprozesses unerwartete Schwierigkeiten aufgetreten sind.
Es ist also keinesfalls sicher, dass am Ende die zu Beginn geplanten Funktionen alle enthalten sind.

Programmierer/Entwickler
Der Programmierer wandelt sich zum Entwickler, da Softwareentwicklung weit mehr ist als nur das Erstellen eines Programms.
Die Sozialkompetenz wird erheblich wichtiger, da man sich nun immer wieder mit dem Kunden abstimmen muss. Das bedingt, jetzt dem Kunden verständlich zu erklären, warum gewisse Dinge erheblich aufwändiger als von ihm vermutet sind, wo man sich in der Machbarkeit oder Komplexität evtl. getäuscht hat (also nicht unfehlbar ist!) bzw. welche Konsequenzen bestimmte aktuelle Entscheidungen für die Zukunft haben ("wenn wir jetzt auf X verzichten, können wir später Y nicht bzw. nur aufwändiger realisieren").
Um kein Missverständnis aufkommen zu lassen: Technische Fähigkeiten bleiben nach wie vor wichtig - aber technische Exzellenz alleine wird nicht mehr ausreichen!