Software Development

Eine der ersten Entscheidungen, vor denen wir bei jedem unserer Entwicklungsprojekte stehen, lautet: „Welche Entwicklungsmethodik sollen wir anwenden?

Dies ist ein Thema, das viele Diskussionen (und oft hitzige Debatten) auslöst.

Wenn Sie noch nicht mit Software-Entwicklungspartnern gearbeitet haben, ist eine Definition der Entwicklungsmethodik angebracht; sehr einfach ausgedrückt, es ist eine Möglichkeit, die Arbeit der Software-Entwicklung zu organisieren.

Hier geht es NICHT um einen Stil des Projektmanagements oder einen bestimmten technischen Ansatz, obwohl Sie diese Begriffe oft alle zusammengewürfelt oder austauschbar verwendet hören werden.

Wasserfall Methodik

Wasserfall ist ein linearer Ansatz zur Software-Entwicklung. Bei dieser Methodik ist die Abfolge der Ereignisse in etwas so

  • Anforderungen sammeln und dokumentieren
  • Design und Konzeption der Anwendung
  • Code- und Einheitentest
  • Durchführen von Systemtests
  • Durchführen von Benutzerakzeptanztests (UAT)
  • Beheben aller identifizierten Mängel und Probleme
  • Lieferung und Einsatz des fertigen Produkts

In einem echten Wasserfall-Entwicklungsprojekt stellt jede dieser Phasen eine bestimmte Stufe der Softwareentwicklung dar, und jede Stufe wird im Allgemeinen beendet, bevor die nächste beginnen kann. In der Regel gibt es auch ein Stage-Gate zwischen den einzelnen Phasen; beispielsweise müssen die Anforderungen vom Kunden geprüft und genehmigt werden, bevor mit dem Design begonnen werden kann.

Der Wasserfall-Ansatz hat gute und schlechte Seiten.

Mögliche Probleme und Einschränkungen:

  • Ein Bereich, der fast immer zu kurz kommt, ist die Wirksamkeit von Anforderungen. Das Sammeln und Dokumentieren von Anforderungen in einer für den Kunden sinnvollen Weise ist unserer Erfahrung nach oft der schwierigste Teil der Softwareentwicklung. Kunden werden manchmal durch Details eingeschüchtert, und bei diesem Ansatz sind spezifische Details, die früh im Projekt bereitgestellt werden, erforderlich.

  • Darüber hinaus sind Kunden nicht immer in der Lage, eine Anwendung aus einem Anforderungsdokument heraus zu visualisieren. Wireframes und Mockups können helfen, aber es steht außer Frage, dass die meisten Endbenutzer einige Schwierigkeiten haben, diese Elemente mit schriftlichen Anforderungen zusammenzufügen, um sich ein gutes Bild davon zu machen, was sie bekommen werden.

  • Ein weiterer potenzieller Nachteil der reinen Wasserfall-Entwicklung ist die Möglichkeit, dass der Kunde mit seinem gelieferten Softwareprodukt unzufrieden sein wird. Da alle Deliverables auf dokumentierten Anforderungen basieren, kann es sein, dass ein Kunde nicht sieht, was geliefert wird, bis es fast fertig ist. Dann aber können Änderungen schwierig (und kostspielig) zu implementieren sein.

Vorteilhaft ist:

  • Entwickler und Kunden einigen sich schon früh im Entwicklungslebenszyklus darauf, was geliefert wird. Das macht die Planung und das Design unkomplizierter.

  • Der Fortschritt lässt sich leichter messen, da der gesamte Umfang der Arbeit im Voraus bekannt ist.

  • Während der gesamten Entwicklungsarbeit ist es möglich, dass je nach aktiver Phase des Projekts verschiedene Mitglieder des Teams beteiligt sind oder mit anderen Arbeiten fortfahren. Zum Beispiel können Geschäftsanalytiker sich darüber informieren und dokumentieren, was zu tun ist, während die Entwickler an anderen Projekten arbeiten. Tester können Testskripte aus der Anforderungsdokumentation vorbereiten, während die Programmierung läuft.
    Mit Ausnahme von Überprüfungen, Genehmigungen, Statusbesprechungen usw. ist eine Kundenpräsenz nach der Anforderungsphase nicht unbedingt erforderlich.

  • Da der Entwurf früh im Entwicklungszyklus abgeschlossen wird, eignet sich dieser Ansatz für Projekte, bei denen mehrere Softwarekomponenten (manchmal parallel) für die Integration mit externen Systemen entworfen werden müssen.

  • Schließlich kann die Software auf der Grundlage eines umfassenderen Verständnisses aller Softwareergebnisse vollständig und sorgfältiger entworfen werden. Dies ermöglicht ein besseres Software-Design mit geringerer Wahrscheinlichkeit des „Piecemeal-Effekts“, eines Entwicklungsphänomens, das auftreten kann, wenn Code-Stücke definiert und anschließend zu einer Anwendung hinzugefügt werden, wo sie vielleicht oder vielleicht auch nicht gut passen.

  • Da Funktionalistät und erwarteter Leistungsumfang abgegrenzt sind, ist es für den Ersteller leichter, den Aufwand zu schätzen und zu einem Festpreis anzubieten.

Agile Methoden

Agil ist ein iterativer, teambasierter Entwicklungsansatz. Es gibt verschiedene Varianten der agilen Entwicklung, die alle einige grundlegende Gemeinsamkeiten aufweisen. Dazu gehören u.a.:

  • Extreme Programming (XP)
  • Scrum
  • Kanban
  • Lean Software Development
  • Agile Unified Process

Agile Methoden legen den Schwerpunkt auf die schnelle Bereitstellung einer Anwendung in vollständigen funktionalen Komponenten.

Anstatt Aufgaben und Zeitpläne zu erstellen, wird die gesamte Zeit in Phasen, die als „Sprints“ bezeichnet werden, „zeitlich eingegrenzt“. Jeder Sprint hat eine festgelegte Dauer (normalerweise in Wochen) mit einer laufenden Liste von Deliverables, die zu Beginn des Sprints geplant werden. Die Deliverables werden nach dem vom Kunden festgelegten Geschäftswert priorisiert. Wenn nicht alle für den Sprint geplanten Arbeiten abgeschlossen werden können, werden die Arbeiten neu priorisiert, und die Informationen werden für die zukünftige Sprintplanung verwendet.

Wenn die Arbeit abgeschlossen ist, kann sie vom Projektteam und vom Kunden durch tägliche Builds und End-of-Sprint-Demos überprüft und bewertet werden. Agile verlässt sich auf ein sehr hohes Maß an Kundenbeteiligung während des gesamten Projekts, vor allem aber während dieser Überprüfungen.

Vorteile der agilen Methoden:

  • Einbeziehung des Auftraggebers und der Nutzer
    Agile bietet vielfältige Möglichkeiten für die Einbindung von Interessengruppen und Teams – vor, während und nach jedem Sprint. Durch die Einbeziehung des Kunden in jeden Schritt des Projekts wird ein hohes Maß an Zusammenarbeit zwischen dem Kunden und dem Projektteam erreicht, was dem Team mehr Möglichkeiten bietet, die Vision des Kunden wirklich zu verstehen. Die frühzeitige Bereitstellung von Arbeitssoftware erhöht häufig das Vertrauen der Beteiligten in die Fähigkeit des Teams, qualitativ hochwertige Arbeitssoftware zu liefern, und ermutigt sie, sich stärker in das Projekt einzubringen.

  • Transparenz
    Ein agiler Ansatz bietet eine einzigartige Gelegenheit für Kunden, während des gesamten Projekts beteiligt zu sein, von der Priorisierung von Funktionen über Iterationsplanung und Überprüfungssitzungen bis hin zu häufigen Software-Builds mit neuen Funktionen. Dies setzt jedoch auch voraus, dass die Kunden verstehen, dass sie als Gegenleistung für diesen zusätzlichen Vorteil der Transparenz ein in Arbeit befindliches Projekt sehen.

  • Frühe und vorhersehbare Lieferung
    Durch die Verwendung von Sprints von 1-4 Wochen mit festem Zeitplan werden neue Funktionen schnell und häufig mit einem hohen Maß an Vorhersehbarkeit geliefert. Dies bietet auch die Möglichkeit, die Software früher als geplant freizugeben oder einen Betatest durchzuführen, wenn ein ausreichender Geschäftswert vorhanden ist.

  • Vorhersagbare Kosten und Zeitplan
    Da es sich bei jedem Sprint um eine feste Dauer handelt, sind die Kosten vorhersehbar und auf den Arbeitsaufwand begrenzt, den das Team in der Zeitbox mit festem Zeitplan leisten kann. In Kombination mit den Schätzungen, die dem Kunden vor jedem Sprint zur Verfügung gestellt werden, kann der Kunde die ungefähren Kosten für jedes Feature leichter nachvollziehen, was die Entscheidungsfindung über die Priorität der Features und die Notwendigkeit zusätzlicher Iterationen verbessert.

  • Änderungen möglich
    Während sich das Team während jeder Iteration auf die Lieferung einer vereinbarten Teilmenge der Produktfunktionen konzentrieren muss, besteht die Möglichkeit, den gesamten Produktbestand ständig zu verfeinern und neue Prioritäten zu setzen. Neue oder geänderte Elemente im Backlog können für die nächste Iteration geplant werden, was die Möglichkeit bietet, innerhalb weniger Wochen Änderungen einzuführen.

  • Fokus auf Geschäftswert
    Indem es dem Kunden erlaubt, die Priorität von Funktionen zu bestimmen, versteht das Team, was für das Geschäft des Kunden am wichtigsten ist, und kann die Funktionen liefern, die den größten geschäftlichen Nutzen bringen.

  • Fokus auf Benutzer
    Agile verwendet häufig den Blickwinkel des Anwenders mit geschäftsorientierten Akzeptanzkriterien, um Produktmerkmale zu definieren. Durch die Fokussierung der Funktionen auf die Bedürfnisse der tatsächlichen Benutzer liefert jede Funktion schrittweise einen Mehrwert, nicht nur eine IT-Komponente. Dies bietet auch die Möglichkeit, die Software nach jedem Sprint einem Beta-Test zu unterziehen, wodurch bereits zu Beginn des Projekts wertvolles Feedback gewonnen wird und die Möglichkeit besteht, bei Bedarf Änderungen vorzunehmen.

  • Verbessert die Qualität
    Durch die Unterteilung des Projekts in überschaubare Einheiten kann sich das Projektteam auf hochwertige Entwicklung, Tests und Zusammenarbeit konzentrieren. Auch durch die Erstellung häufiger Builds und die Durchführung von Tests und Überprüfungen während jeder Iteration wird die Qualität verbessert, indem Fehler schnell gefunden und behoben und Erwartungsinkongruenzen frühzeitig erkannt werden.

Low Code

Low Code ist eine Entwicklungsform, in welcher mit Hilfe visueller modellbasierter Entwicklungsmethoden die Zeit bis zum fertigen Produkt minimiert wird. Demnach sind nur minimale oder oft auch gar keine Programmierkenntnisse von Nöten, was insbesondere hilfreich für Novizen im Programmiersektor ist. Trotz dieser vereinfachten Entwicklungsumgebung ist es dennoch möglich, Anwendungen und Applikationen seinen Bedürfnissen entsprechend anzupassen.

LowCode ermöglicht Mitarbeitern ohne klassische Programmierausbildung das vollständige Erstellen von verkaufsfertigen Programmen. So müssen nicht nur weniger bis gar keine Fachkräfte beauftragt werden, sondern auch die Entwicklungszeit verkürzt sich enorm. Selbst erfahrene Programmierer, wie auch unsere eigene Erfahrung bisher zeigte, entwickeln deutlich schneller auf LowCode-Umgebungen im Vergleich zu bisherigen.

Die Vergangenheit zeigte, dass sich der Trend bezüglich hardwarenaher Programmiersprachen immer mehr zu Programmiersprachen mit höheren Abstraktionsebene bewegte, sodass sich die Zielgruppe der Programmierenden erweitern konnte.

Auch die Idee von LowCode Umgebungen gab es bereits in den 1990er Jahren unter dem Namen Rapid Application Development („RAD“). Seit 2014 ist jedoch der Begriff des Low-Code-Development geläufiger geworden und erlebt seit jeher einen Boom: zahlreiche Low-Code-Dev Services von Technologiegiganten wie Google oder Microsoft werden bereits von einer Vielzahl von großen Unternehmen eingesetzt, um die Programmentwicklung zu optimieren.

Beschleunigte Entwicklung bedeutet nicht, dass Ressourcenoptimierung, Funktionalität und ein gutes Userinterface bei Nutzung der richtigen Tools auf dem Spiel stehen:

Der heutige technische Stand von LowCode Umgebungen wie

  • „Oracle Apex“,
  • „Intrexx“,
  • aber auch „Mendix“ oder „Outsystems“

ermöglicht das schnelle Erstellen eines fertigen Produktes nach höchstem Qualitätsstandard.

Kundenorientierung ist für alle Unternehmen der Schlüssel zum Erfolg. Der heutige Markt durchlebt einen Prozess der Individualisierung und Spezialisierung zahlreicher Unternehmen, weswegen Produktlösungen „von der Stange“ überholt sind. Trotz vereinfachter Umgebung ermöglichen zahlreiche Low-Code Umgebungen passgenaue Produktentwicklung ohne seine Vorzüge als simplifiziertes graphisches Arbeiten gegenüber klassischem hartem Codieren zu verlieren.