Alles unter einem Hut – Eine individualisierbare Entwicklungsmethodik für bimodales Software-Engineering


07.11.2017 von

https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png iteratec GmbH

Lange Lieferzeiten und hohe Kosten im Software-Engineering

Zu langsam, zu teuer, zu unflexibel!

Häufig sind das die Attribute, die seitens der Fachseiten und der Anwender den Softwareentwicklungsbereichen gegeben werden. Die Time-to-Market ist gefühlt immer deutlich länger als die Anforderer sich dies wünschen würden. Die Kosten schnellen, fragt man die Geldgeber, ebenso in die Höhe. Selbst einfache Anpassungen bestehender System werden mit jedem Release aufwändiger.

Die Ursachen sind dabei nicht immer trivial. Es gibt jedoch grundlegende Tendenzen, die diesen Symptomen zugrunde liegen können.

In dieser Situation wurden wir zu unserem Kunden – einer Bank – gerufen. Hier sollte die etablierte Softwareentwicklungsmethodik überprüft und an die aktuellen Entwicklungen angepasst werden. Beim Kunden wird seit langer Zeit Software nach einem klassischen, wasserfallartigen Vorgehen entwickelt. In neuerer Zeit sind Projekte dazu gekommen, die sich eines agilen Vorgehens nach Scrum oder Kanban bedienen. Für diese sind die Vorgaben, die auf die klassischen Projekte maßgeschneidert waren, natürlich vollkommen ungeeignet. Die Vielzahl der zu erstellenden Dokumente läuft der Agilität der Projekte entgegen.

Anforderungen an das Engineering sind umfassend und häufig widersprüchlich

Nun sehen wir uns an, wo hier die Ursachen zu finden sein können. Die Anforderungen kommen von verschiedenen Seiten, die jeweils ihren spezifischen Blickwinkel einbringen.

  • Die Fachseiten als eigentliche Auftraggeber eines Softwaresystems legen neben den fachlichen Anforderungen, also welche Funktionen das System zur Verfügung zu stellen hat, vor allem Wert auf schnelle Time-to-Market, ohne dabei den Blick für die Kosten zu verlieren.
  • Der IT-Betrieb hat dagegen vollkommen andere Ansprüche an eine Software. Hier interessieren Stabilität, leichte Betreibbarkeit und Sicherheitsaspekte.
  • Die Ziele der IT-Governance und damit die Anforderungen, die sie an zu erstellende Software richten, betreffen ebenfalls eher nichtfunktionale Aspekte wie Transparenz, Zukunftssicherheit und die Reduzierung von Risiken in der Entwicklung und durch die neue Software.

Die Entwicklungsmethodik muss sich am tatsächlichen Bedarf orientieren

Softwareentwicklung wird in vielen Organisationen nach einem vorgegebenen Modell betrieben. Solche Entwicklungsmethodiken orientieren sich an verschiedenen Standards (z. B. V-Modell) und geben in der Regel die im Rahmen der Software-Entwicklung durchzuführenden Aufgaben sowie die zu erstellenden Artefakte und den Zeitpunkt, wann die Aufgaben durchzuführen bzw. die Artefakte vorzuliegen haben, fix vor.

Auch wenn in den Organisationen bereits Software nach agilen Modellen entwickelt wird, sind die Entwicklungsmethodiken oft noch rein klassisch aufgesetzt. Eine Flexibilisierung der verwendeten Softwareentwicklungsmethodik ist daher ein möglicher Ansatzpunkt um die beschriebenen Probleme anzugehen und potenzielle Lösungswege aufzuzeigen.

Wir erstellen eine flexible Softwareentwicklungsmethodik

Die Ausgangslage, die wir bei unserem Kunden vorgefunden haben entspricht in etwa der oben beschriebenen. In einer bestehenden Softwareentwicklungsmethodik wurden alle Eventualitäten behandelt und die zu erstellenden Dokumente detailliert vorgegeben.

Ziel war es, eine neue, schlankere Entwicklungsmethodik zu erstellen, die sowohl den Ansprüchen der IT-Governance bzw. den Anforderungen des Regulierers genügt, die aber auch von den Entwicklern akzeptiert und vor allem gelebt wird. Neben der Entwicklung nach klassischen Vorgehensmodellen wie Wasserfall sollten auch agile Vorgehen wie Scrum und Kanban unterstützt werden.

Erfolgsfaktor „Einbindung agiler Softwareentwicklung“

Eine Kernanforderung an die neue Softwareentwicklungsmethodik war die Einbindung der bei unserem Kunden vorkommenden Vorgehensmodelle Wasserfall, Scrum und Kanban. Wir haben uns bewusst dafür entschieden, eine gemeinsame Methodik für klassische und agile Entwicklungsprojekte aufzusetzen. Um dies zu ermöglichen, wurden die Ausprägung eines geforderten Ergebnisses (z.B. Erstellung in Form eines Dokumentes oder durch Pflege eines Tools) sowie der Zeitpunkt seiner Erstehung (ohne fixe Phasenzuordnung) dem Projekt überlassen.

Dies führt zu einer generellen Flexibilität, von der auch Entwicklungsprojekte nach klassischem Vorgehen profitieren.

Erfolgsfaktor „Einbindung der Entwickler“

Die Softwareentwickler, Designer und Architekten sind diejenigen, die letztlich mit einer Entwicklungsmethodik arbeiten müssen. Bei unserem Kunden konnten wir durch die aktive Einbindung von Entwicklern verschiedener Teams in der Aufbauphase, aber auch später nach Einführung in regelmäßigen Nutzertreffen, einen hohen Grad an Identifikation mit der Entwicklungsmethodik erreichen.

Zudem fanden sich im Fundus vieler Entwicklungsteams, unabhängig von den geforderten Vorgaben der früheren Pflichtdokumente, bestehende Werkzeuge und Vorlagen, die im Laufe der Jahre soweit optimiert wurden, dass sie genau die Themen umfassen, die von den Entwicklern als interne Dokumentation herangezogen werden.

Diese „Schätze“ wurden von uns gehoben und soweit möglich integriert. Durch die Integration dieser gelebten Vorgehensweisen konnten Reibungsverluste im Rahmen der Einführung minimiert werden.

Erfolgsfaktor „Einbindung der Stakeholder“

Die generellen Anforderungen an die Softwareentwicklung, wie sie seitens Fachseite, IT-Governance und Betrieb gestellt werden, müssen grundsätzlich in die Betrachtungen einer Entwicklungsmethodik einfließen.

Dementsprechend war es im vorliegenden Fall zentral, die eigentlichen Kernanforderungen der Stakeholder zu ermitteln. Es zeigte sich beispielsweise, dass die Einhaltung spezifischer Programmierrichtlinien zur Vermeidung von Sicherheitsrisiken deutlich relevanter war, als eine strikte Vorgabe von einheitlichen Vorlagen.

Durch eine regelmäßige Vorstellung des aktuellen Arbeitsstandes bei den unterschiedlichen Stakeholdern und deren Einbindung in konkrete Entscheidungen wie beispielsweise notwendigen Tradeoffs, konnten alle Seiten zufrieden gestellt werden.

Erfolgsfaktor „projektspezifisches Tailoring“

Durch ein projektspezifisches Tailoring kann frühzeitig festgelegt werden, welchen Einfluss verschiedene Faktoren auf ein Projekt und auf die zu erstellende Software haben. Für die Softwareentwicklungsmethodik unseres Kunden haben wir ein Tailoring gewählt, das anhand weniger Parameter zu Beginn des Projektes ermittelt, welche Ergebnisse verpflichtend im Projekt zu erstellen sind.

Die Haupt-Faktoren, für die wir uns entschieden haben, sind dabei die Art des Projektes (z.B. Neuentwicklung, Integration von Kauf-Software, kleine Software-Anpassung, ….) und das Vorgehensmodell (klassisch oder agil).

Weitere Faktoren waren beispielsweise die fachliche Erfahrung des Entwicklungsteams, architekturelle Besonderheiten oder auch der Realisierungsort (intern, extern, onsite, nearshore, farshore, …).

Die Größe des Projektes (nach Aufwand, Kosten oder Dauer) wurde bewusst nicht zur Bewertung herangezogen, da hierdurch keine Aussage darüber möglich ist, ob eine der generellen Anforderungen der Stakeholder betroffen sind – auch kleine Projekte können große Probleme bereiten. Außerdem verleitet die Gruppierung in Größenklassen dazu, Projekte künstlich zu verkleinern, um in eine geringere Dokumentationskategorie zu gelangen.

Erfolgsfaktor „firmenspezifisches Vorgehen“

Die grundlegenden Prinzipien des Software-Engineering sind unabhängig davon, wo Software entwickelt wird. Dennoch mussten bei der Einführung der Softwareentwicklungsmethodik für unseren Kunden spezifische Rahmenbedingungen (z.B. Branchentypische Formate und Regulierungen) berücksichtigt werden. Dies ist zwingend erforderlich, um die Methodik in die Organisation und ihre Prozesse integrieren zu können.

Dies zeigt sich auch in unterstützenden Hilfsmitteln, wie einem Prozesslotsen, der den Anwendern Hilfestellung bei der Einbindung ihrer Projekte in die Prozesslandschaft gibt. Nicht zuletzt spielte für unsere Entwicklungsmethodik auch der „Stallgeruch“, das heißt speziell (gute) Angewohnheiten, die bei unserem Kunden Usus sind eine nicht zu vernachlässigende Rolle.

Ende gut, alles gut

Die Einführung der neuen Softwareentwicklungsmethodik erfolgte mit einer Übergangszeit von drei Monaten und wurde von Schulungen, Roadshows und anderen Einführungsveranstaltungen begleitet. Regelmäßige Kontrollen der Projekte belegen eine erfolgreiche Nutzung der Methodik.

Die Belastung der Entwickler durch die Erstellung unnötiger Dokumentation wurde deutlich reduziert. Dies belegen positive Rückmeldungen aus den regelmäßig stattfindenden Nutzertreffen.

Die Einbindung agiler Projekte und die damit einhergehende Flexibilisierung der Methodik ist für alle Seiten positiv. Agile Projekte können seither der vom Regulierer geforderten Überprüfung unterzogen werden, wobei praktisch keine Zusatzaufwände in den Projekten entstehen.

Nach mehr als einem Jahr aktiver Laufzeit kann ein positives Fazit gezogen werden: Seit der Einführung wurden mehr als 100 Projekte in der neuen Entwicklungsmethodik umgesetzt. Die Rückmeldungen aller Stakeholder sind durchweg positiv.

Diesen Artikel bewerten
 
 
 
 
 
 
 
3 Bewertungen (100 %)
Bewerten
 
 
 
 
 
 
1
5
5
 

Artikel im Warenkorb:

0