Fazit

Das hier vorgestellte und erarbeitete Softwareprodukt ist, verglichen mit aktuellen Beispielen aus der Wirtschaft, winzig. Es beschränkt sich auf ein Arbeitsgebiet eines Regionalbereichs und darin zunächst nur auf eine Abteilung. Der entstandene Prototyp eignet sich als Grundbaustein für eine iterativ weiterwachsende Software. Die Programmierung mit dem Software-Engineering ist jedoch nur die eine zu betrachtende Seite. Auf der anderen Seite stehen die Mitarbeiter und die Geschäftsprozesse, die ebenfalls in diesen Veränderungsprozess einbezogen werden müssen. Durch sogenanntes Change-Management lässt sich die Transformation zur Arbeitswelt 4.0 vollziehen.

Auswertung Thesen

1. Mithilfe der agilen Methoden im Management kann nahezu jedes Projekt erfolgreich abgeschlossen werden.
   Diese These kann nicht bestätigt werden. Agilität ist eine Möglichkeit im Projektmanagement und kann nur erfolgreich funktionieren, wenn alle Beteiligten bedingungslos mitwirken. Im Fokus steht das Verhalten der Mitarbeiter. Wenn diese nicht lernen wollen oder können, sich vom Team abwenden und intrigieren, verursacht dies einen großen Schaden und Vertrauensverlust. Die Masterarbeit bezieht die Agilität darum direkt auf das Software-Engineering. Zweifelsohne kann jedoch festgestellt werden, dass agiles Management nur erfolgreich sein kann, wenn es einer Abteilung und den Mitarbeitern darin nicht aufgezwungen wird. Motiviertes und einsatzbereites Personal führt das agile, selbstorganisierte Team und damit das Projekt zum Erfolg. Das klassische Projektmanagement mit seinen festen Strukturen, Hierarchien und Prozessen kann Projekte ebenso zum erfolgreichen Abschluss verhelfen; jedoch aktuell auf Kosten des Personals. Burnout, psychischer Druck oder hohe Arbeitslast führen zur Unzufriedenheit der Mitarbeiter. Agilität ist eine Möglichkeit den Menschen, seine Fähigkeiten und seinen natürlichen Ehrgeiz in den Mittelpunkt zu stellen. Die Arbeitswelt 4.0, der Einsatz von Robotern, künstlichen neuralen Netzen und künstlicher Intelligenz erfordert ein gesellschaftspolitisches Umdenken und die Zentralisierung der Arbeitsabläufe auf die Sicht des Mitarbeiters.

2. Durch agiles Software-Engineering mit Scrum werden die klassischen Phasen und Rollen vollständig abgelöst. Es gibt keine Programmierer, Designer, Tester und dergleichen mehr.
   Diese These ist falsch. Die klassischen Phasen werden auch durch den Einsatz der agilen Scrum-Methode nicht abgelöst. Lediglich die Übergänge zwischen den Entwicklungsschritten sind fließender geworden. Im Grunde hilft der Sprint in der Scrum-Methode die klassischen Entwicklungsphasen öfter und gezielter zu durchlaufen. Die Konzentration liegt damit nicht mehr auf der gesamten Software, sondern auf dem Teil, der dem Kunden zur nächsten Auslieferung einen Mehrwert liefert. Um diesen Mehrwert in der Kürze eines Sprints zu erreichen, sind die Mitglieder des Entwicklungsteams dazu aufgefordert, auf die Arbeit ihrer Kollegen zu vertrauen und unabhängig ihres erlernten Berufs an der Umsetzung der Einträge im Sprint-Backlog mitzuwirken. Der klassische Software-Tester beispielsweise, würde die Anwendung erst am Ende übernehmen und prüfen, ob die Anforderungen erfüllt wurden. Im Sprint wird er jedoch bereits zu Beginn mit den Programmierern und Designern die Testfälle ausarbeiten, Datentypen und Benutzerinteraktionen diskutieren und mit den künftigen Administratoren des Kunden, über weitere Akzeptanzkriterien sprechen. Während der Testdurchführung wird er dann wiederum von den anderen Fachexperten unterstützt. Funktioniert diese echte Teamarbeit, entwickeln die Mitarbeitern eine hohe Motivation, Einsatzbereitschaft und das Verständnis für die fremden Fachbereiche. Darauf aufbauend steigern die Team-Mitglieder ihre Bereitschaft zur Teamarbeit und zum lebenslangen Lernen. Trotzdem wird es keine Experten geben, die in allen Fachbereichen gleichermaßen eingesetzt werden können. Dafür ist das zu erwerbende Wissen zu komplex.

3. Das moderne Software-Engineering lebt von wenigen Dokumenten, im Grunde ist jede erstellte Dokumentation vergeudete Arbeitskraft und Zeit.
   Die Erstellung von Dokumentationen zu einer Software kann nie als Ressourcenvergeudung betrachtet werden. Selbst das agile Manifest verneint Dokumentation nicht, es stuft die funktionierende Software lediglich wichtiger ein. Gerade bei komplexer Software ist es unabdingbar, dem Benutzer eine Hilfefunktion zur Verfügung zu stellen. Durch die agilen Entwicklungsteams ist es nötig, den Programmierern die bestehenden Funktionen, Methoden, Datenmodelle und Entwürfe zu erläutern, damit die Anwendung wartbar bleibt und ihre Weiterentwicklung nicht gefährdet wird. In jedem Fall ist von Beginn an eine dauerhafte Dokumentationsart festzulegen und zu pflegen. Eine gute Art ist eine Webseite mit Wiki-Aufbau. Diese unterstützt das Vorhalten von Echtzeit-Informationen für den Benutzer, das Editieren veralteter Einträge und das Neuerfassen. Durch die Benutzerverwaltung können mehrere Entwickler zeitgleich darin arbeiten und dem Benutzer, den Administratoren und dem Entwicklungsteam selbst, einen großen Mehrwert bieten.

4. Die Definition of Done kann erst erfüllt sein, wenn alle Software-Tests bestanden wurden. Es macht keinen Sinn, ein unvollständig getestetes Produkt-Inkrement zu übergeben.
   Wie die Definition of Done festgelegt wurde, hängt vom Scrum-Team und den Stakeholdern ab. Ein unvollständig getestetes Produkt-Inkrement kann an den Kunden überge-ben werden, wenn dies mit ihm in der Definition of Done spezifiziert wurde. Selbstverständlich muss die Anwendung zum Zeitpunkt der Auslieferung lauffähig sein. Je nach Vereinbarung ermöglicht die zeitige Auslieferung beispielsweise die Durchführung von Benutzerakzeptanztests, umfangreiche Systemtests im Produktivsystem oder die probehalber inbetriebnahme auf den Produktivservern. Dadurch erhöht sich die gelieferte Qualität, die Anpassbarkeit und die Steuerbarkeit des Entwicklungsprozesses. Es ist schließlich nicht definiert, dass ein erstelltes Produkt-Inkrement bereits allen Mitarbeitern zur Verfügung gestellt wird. Viel mehr entscheidet die Administration beim Kunden, ob sie die lauffähige Produktversion einsetzt, die nächste Iteration abwartet oder bestimmten Test-Usern und Multiplikatoren die Anwendung vorab zur Verfügung stellt.

5. Die Anwendung wird nie fertig. Immer wieder treten Fehler auf, obwohl diese bereits vor einiger Zeit gemeldet wurden.
   Unabhängig davon, ob die Beteiligten agil oder klassisch vorgehen: durch Wartung, Anpassung und Weiterentwicklung sind Veränderungen an der Software nie ausgeschlossen. Gerade deshalb hat sich Agilität im Software-Engineering etabliert und ermöglicht den organisierten Umgang mit Veränderungen. Eine Anwendung kann nie fertig werden, da sich permanent Anforderungen von Hard- und Software ändern, neue Geschäftsprozesse abgebildet werden müssen, Prozessoptimierungen durchgeführt wurden oder Wünsche der Benutzer umgesetzt werden. Die Software wird daher nie fertig und muss durch ununterbrochene Wartung, Weiterentwicklung und Dokumentation fortgeführt werden. Dazu ist es unerlässlich, Hilfsprozesse unter den Anwendern einzuführen, um die Benutzerwünsche zu selektieren und zu priorisieren. Damit auf Hard- und Softwareänderungen eingegangen werden kann, müssen diese frühzeitig dem Product Owner über geeignete Kanäle mitgeteilt werden. In regelmäßigen Besprechungen müssen diese Änderungen zwischen dem agilen Team und den Stakeholdern diskutiert und in das Product-Backlog aufgenommen werden. Durch Transparenz und Kommunikation ist zu erreichen, dass aufgetretene Fehler und deren Behebung an die Benutzer übermittelt werden. Dadurch etabliert sich das Team innerhalb des Unternehmens und wird zu einem verlässlichen Partner.

Ausblick

Die Erstellung einer Anwendungssoftware ist mit hohem Aufwand verbunden. Innerhalb des Datenmanagements wurde der Wunsch nach einer maßgeschneiderten Lösung bereits seit 2016 geäußert und die Anforderungen dafür formuliert. Mit der vorliegenden Arbeit ist es ge-lungen den theoretisch-fachlichen Anspruch zu vertiefen und zu dokumentieren.

Der entstandene Prototyp wird künftig zu einem MVP weiterentwickelt. Er soll in den kommenden Wochen zur ersten Version reifen und den Mitarbeitern die Grundfunktionen zur Verfügung stellen. Neben der Benutzerverwaltung und Formularausführung an sich, soll das System bestimmten Personen die Möglichkeit bieten Aufträge zu erfassen und die Bestellungen den betreffenden Fachbereichen, Segmenten und Sachbearbeitern zuzuweisen. Geplant wird außerdem die Datenbankerweiterung mit PostGIS, um die Aufträge raumbezogen auswerten zu können. Nicht zu vernachlässigen ist hierbei die Migration der Altdaten, die seit 2013 in unterschiedlicher Güte erhoben wurden. In Zeitintensiver Arbeit sind diese Daten zu sichten, zu bereinigen und in das neue System zu importieren.

Die Weitergabe von Informationen durch die Datenbank unterliegt natürlich dem Datenschutz und dieser muss auch in Zukunft durch permanente Risikountersuchungen und Rücksprachen mit den Datenschutzbeauftragen des DB-Konzerns sichergestellt werden. Für die Datensicherheit sind die Systemadministratoren verantwortlich. Auch hier müssen in Zukunft enge Absprachen mit den Serveradministratoren und IT-Spezialisten von DB Systel erfolgen.