Methoden der Softwareentwicklung

Verschiedene Methodiken der Softwareentwicklung haben sich bewährt und beweisen (weiterhin) ihre Daseinsberechtigung.

Produkttypen

Es bedarf einer klaren Abgrenzung der Produkttypen in der Softwareentwicklung.

Vorproduktiv

☐ Der proof of concept [POC], ist eine Machbarkeitsstudie, die sich nicht um weitere Rahmenbedingungen kümmern (sollte) sondern sich auf die Klärung des technisch machbaren des Produktes / der Innovation fokussiert.

☐ Der proof of value [POV] ist als Folgeschritt zum POC zu sehen ist, der auch den wirtschaftlichen Aspekt einbezieht.

☐ Der Prototyp ist ein funktionsfähiges Produkt, welches auf der Zielarchitektur laufen sollte. Ein Prototyp verwendet häufig noch Mock-Funktionalitäten um Teile der Funktionalitäten vorzutäuschen.

☐ Die alpha-Version eines Produkts ist eine Version, die bewusst noch nicht fehlerbereinigt ist  bzw. zur ersten Fehlerbereinigung ausgeliefert wird. Ich empfehle ausdrücklich die semantische Versionierung für Software und auch für Daten und Dateien.

☐ Die beta-Version eines Produkts ist eine Version, von der angenommen wird sie enthalte keine Fehler mehr und zur Prüfung dieser Annahme die Software bereitgestellt wird. Bereits mit der Bezeichnung beta wird jedoch ausdrücklich vor Fehlern gewarnt.

Produktiv

☐ Das Produkt, häufig mit einer Version 1.0.0 beginnend, ist für den Echteinsatz gedacht. Alternativ sind Begriffe wie Produktions- / Produktivbetrieb oder auch Wirkbetrieb in Verwendung.

☐ Das minimum viable product [MVP] ist ein produktives Produkt, welches einen minimalen fachlichen / geschäftlichen Mehrwert hat und insbesondere bei der agilen Softwareentwicklung zum Einsatz kommt. Es ist kein Prototyp, sondern ein fertiges Produkt für den Echteinsatz / Produktionseinsatz / Wirkbetrieb.

Nachproduktiv

☐ Abgekündigte Versionen oder auch Vintage Produkte sind weiterhin im produktiven Einsatz möglich bergen jedoch Risiken bei einem weiteren Einsatz z.B. hinsichtlich Sicherheit oder technischer Abhängigkeiten.

☐ Ungepflegte Produkte sind sowohl im Bereich der OSS als auch bei kommerzieller Software zu finden, dort u.a. auch als auslaufende Produktlinien benannt. Risiken bestehen insbesondere wenn technische Abhängigkeiten bestehen und nicht die Möglichkeit (kommerzielle Produkte) oder das Know-How (OSS) besteht dies aufzufangen. Die Einordnung zu nachproduktiv erfolgt aufgrund der damit verbundenen technischen Schulden und Risiken.

Agile Softwareentwicklung

Methoden der agilen Softwareentwicklung zielen darauf ab, ein möglichst schnelle Produktivsetzung durch eine evolutionäre Fortentwicklung zu erreichen. Häufig wird dabei mit einem Produkt gestartet, welches aufs unbedingt notwendige beschränkt ist (minimum viable product - MVP).

Agile Methoden favorisieren die Anforderungen an die Software in kleinen Umsetzungsschritten. Dies beginnt beim MVP wird vor allem jedoch bereits bei der Anforderungsaufnahme umgesetzt und bedingt, dass während der kompletten Umsetzungszeit kein abschließendes, mit allen abgestimmten Bild des späteren fertigen Produktes vorhanden ist. Die häufig beschworene Nutzerzentrierung und häufigen Feedbackschleifen können auch das Look-and-Feel der Anwendung jederzeit ändern. Agile Methoden ergänzen sich im Backend daher gut mit dem Konzept der Microservices, da auch hier kleine Softwarekomponenten bei geänderten Anforderungen „leicht“ austauschbar sind.

Der Unterschied zu einer inkrementellen Softwareentwicklung ist, wenn auch fließend, dass die Agilität und Umsetzung in kleinen Schritten bereits bei den Anforderungen bzw. Lasten umgesetzt wird. Die Umsetzung der Software in inkrementell hingegen fokussiert sich auf ein Lastenheft mit zugehörigem Pflichtenheft, welches im Anschluss an die Erstellung in die inkrementell umzusetzenden Versionen zerlegt wird. 

KANBAN zielt u.a. darauf ab die Ziele der agilen Softwareentwicklung ohne neue Rollen, Prozesse etc. in der Organisation einzuführen. Mit dem KANBAN-Board wird der Bearbeitungsstand visualisiert. Begrenzte Ressourcen werden durch KANBAN abgebildet, indem die einzelnen Bearbeitungsschritte bewusst mit einem Limit der gleichzeitigen Aufgaben belegt werden. Ergänzt durch ein Pull-System, wo nachfolgende Bearbeitungsschritte sich ihre Aufgaben abholen wird der Arbeitsfluss gesteuert. In KANBAN werden Aufgaben nur entlang des Arbeitsfluss bearbeitet, so dass eine neue Aufgabe erst nach Abschluss der vorhergehenden begonnen wird. Hierdurch fokussiert sich KANBAN auf die Erledigung der Aufgabe. Mit Hilfe des kontinuierlichen Verbesserungsprozess (KVP / Kaizen) wird der Arbeitsfluss hierbei nachgesteuert. Regelmäßiges Feedback wird zu festgesetzten Terminen eingefordert.

Scrum führt ein sich selbstorganisierendes Team ohne direkte Hierarchien jedoch mit Rollen des Product Owner, des Entwicklers und des Scrum Master, mit einer üblichen Teamgröße möglichst nicht mehr als 12 Personen. Entwicklungsschritte werden in Sprints realisiert. 

Der Product Owner ist der fachliche Produktverantwortliche der im „Product Backlog“ die Anforderungen einträgt, welche ihn von Stakeholder und Entwicklungsteam benannt wird. Nach Scrum hat ein Product Owner Entscheidungskompetenz. Der Scrum Master steht neben dem Entwicklungsteam als Berater, Mediator, Coach und Kümmerer der die Befolgung und Scrum Regeln sicher stellen soll. Scrum als Framework ist hierbei spezifisch für das Projekt und die Organisation auszugestalten und kann beispielsweise dem Product Owner auch die Entscheidungskompetenz versagen. Das Team selbst wird interdisziplinär aufgestellt und trägt gemeinsam die Verantwortung für die Erreichung des Ziels sowohl im Ganzen als auch für den jeweiligen Sprint.

Ein Sprint ist eine Menge von Aufgaben die aus dem Backlog genommen werden und in dem definierten Zeitraum (= Sprint) umgesetzt werden. Nicht erledigte Aufgaben zum Ende des Sprint werden in das Backlog zurück gelegt. Hierdurch fokussiert sich Scrum auf die Einhaltung der Zeitvorgaben. Mit dem Daily Scrum des Teams wird die Selbstorganisation des Teams, ohne Product Owner und Scrum Master, zur Termintreue unterstützt.

Obwohl Nutzerzentrierung bei jedem Vorgehensmodell Anwendung finden kann ist die Verwendung bei linearer Softwareentwicklung ungleich schwerer.

Nutzerzentrierung bedeutet hierbei insbesondere, dass neben dem Auftraggeber auch die späteren Anwender bereits bei der Softwareentwicklung einbezogen werden und primär die Nutzer die Umsetzung der Funktionalitäten vorgeben.

Lineare Softwareentwicklung

Lineares Vorgehensmodelle gehen erst nach Abschluss eines Schrittes zum Nächsten über. Dabei profitieren diese Systeme von der Vorherbestimmtheit der Ergebnisse z.B. bei Werkverträgen. 

‍ 

Das Wasserfallmodell setzt anders als KANBAN beim Übergang zum nächsten Schritt im Arbeitsfluss die vollumfängliche Abarbeitung voraus, so dass die Anforderungen als Ganzes in einem Lastenheft formuliert sind, die dazugehörige Umsetzung anschließend im Pflichtenheft formuliert wird, dem nach Fertigstellung die Implementation folgt. Die Gesamtsicht auf die jeweiligen Schritte ermöglichen bei Auftragsvergabe (als Werkvertrag) jeder Seite einen verlässlichen Auftrags- / Vertragsgegenstand als Basis zu haben. Der komplette Produktumfang ist nach dem Lastenheft definiert und qualitativ und quantitativ verifizierbar.

Spätere Änderungen der Anforderungen müssen explizit neu beauftragt werden. Soweit Lasten- und Pflichtenheft auch im Rahmen der Wartung der fertigen Produkte gepflegt werden, liegt jederzeit ein dokumentiertes und pflegearmes Gesamtsystem vor.

Software kann auch mit dem Wasserfallmodell inkrementell entwickelt werden, indem mehrere Projekte nacheinander aufgesetzt werden.