Softwareentwicklungsprozesse – One Size Fits All?

Paderborn, 27.01.2017

Softwareentwicklungsprozesse folgen der Logik, dass Produkte und Dienstleistungen, die auf individuelle Bedürfnisse eingestellt sind, typischerweise einen höheren Nutzen haben. Es hat sich die Erkenntnis durchgesetzt, dass deshalb One-Size-Fits-All-Ansätze für Softwareentwicklungsprozesse regelmäßig scheitern.

Seit mehreren Jahren geht der Trend bei der Softwareentwicklung eindeutig in Richtung schlanke und agile Entwicklungsprozesse. Gerade in diesem Umfeld ist das Team angehalten, die Freiräume mit eigenen Aktivitäten und Regeln zu füllen und über Retrospektiven den Entwicklungsprozess stetig zu hinterfragen und anzupassen – also „Method Engineering“ zu betreiben. Darüber hinaus gilt es, Themen wie komplexe Lieferantenbeziehungen, klassische Organisationsstrukturen und Festpreis-Verträge ausrechend zu berücksichtigen. Jedes IT-Projekt hat also seine Eigenheiten, die bei der Auswahl und Anpassung eines Softwareentwicklungsprozesses entsprechend zu berücksichtigen sind.

Beispielsweise müssen im Kontext von Offshore-Projekten Aktivitäten für Kommunikation und Transparenz eingebaut werden, die in kleineren Vor-Ort-Projekten unnötigen Overhead darstellen würden und entgegen einem One-Size-Fits-All-Ansatz besser entfallen. Im Offshore-Kontext muss der Status von Entwicklungsaufgaben detailliert erfasst und gepflegt werden, während man im Vor-Ort-Projekt stattdessen auf effiziente, direkte Kommunikation ausweichen kann.

Die Auswahl und Zusammenstellung der Aktivitäten ist nicht ganz einfach und birgt je nach Projekt seine ganz eigenen Herausforderungen. Wenn zum Beispiel in einem agilen Projekt zwei Softwarelieferanten involviert sind, muss Scrum dann erweitert werden, damit die Softwarelieferungen zusammen funktionieren? Nicht nur betroffene Projektleiter beschäftigen sich regelmäßig mit dieser und ähnlicher Thematik. Auch die Wissenschaft forscht aktiv an dem Thema „Method Engineering“ – der Bereitstellung von passenden Softwareentwicklungsprozessen und Methoden für IT-Projekte und -Produkte. Eine der Fragestellungen lautet, wie man für jedes Projekt einen individuellen Entwicklungsprozess bereitstellt, ohne jedes Mal das Rad neu zu erfinden.

Bausteinbasierte Entwicklungsprozesse

Bausteinbasierte Entwicklungsprozesse

Mit dieser konkreten Fragestellung hat sich unser S&N-CQM-Mitarbeiter Mitarbeiter Dr. Masud Fazal-Baqaie im Rahmen seiner Dissertation beschäftigt und ein Konzept für einen Baustein-basierten Ansatz erarbeitet [1][2]. Die Grundidee ist dabei, dass typische Prozessbausteine in verschiedenen Varianten in einer Baustein-Datenbank vorgehalten und für jedes Projekt passend zusammengestellt werden. Ein Prozessbaustein kann eine ausführliche Analyse und Beschreibung der Anforderung vorsehen, wie sie bei plangetriebenen Vorgehensweisen typisch ist. Ein leichtgewichtigerer Prozessbaustein kann hingegen auf eine kürzere Analyse und verkürzte Beschreibung setzen, so wie sie bei agilen Ansätzen typisch ist. Bei der Auswahl von Prozessbausteinen werden die Projekteigenschaften dann entsprechend berücksichtigt. Beispielsweise legt ein Offshore-Kontext die Verwendung von ersterem Prozessbaustein nahe, da räumliche, zeitliche, organisatorische und kulturelle Distanzen direkte Kommunikation erschweren. Diese ist aber für die Nutzung des zweiten Prozessbausteins eine Voraussetzung. In seiner Arbeit beschreibt Dr. Fazal-Baqaie wie solche Bausteine aus der Unternehmenspraxis und Literatur abgeleitet werden können, so dass Unternehmen auf ihren gewohnten Softwareentwicklungsprozessen aufsetzen können, gleichzeitig aber auch offen für neue Best Practices sind. Beschrieben wird auch, wie Bausteine zu konsistenten Entwicklungsprozessen zusammengestellt werden und welche Qualitätseigenschaften dabei zu berücksichtigen sind. Andernfalls droht die Gefahr, dass wichtige Prozessbausteine fehlen und der Softwareentwicklungsprozess nur unvollständig beschrieben ist. Dies könnte dann bei der Projektdurchführung dazu führen, dass Aktivitäten vergessen oder erst sehr spät gestartet werden, wodurch sich das Projekt verzögert und die Qualität der Software leidet. Für seinen bausteinbasierten Ansatz greift der Autor auch auf die Erfahrungen zurück, die er im Rahmen von S&N-Projekten gesammelt hat [3][4][5]. Hier hat er bestehende Softwareentwicklungsprozesse in laufenden Projekten verbessert.

Verbesserung bestehender Softwareentwicklungsprozesse

Verbesserungspotentiale in Softwareentwicklungsprozessen werden oft erst in laufenden Projekten aufgedeckt und adressiert. Damit stellt sich die Frage, wie in solch einem Fall damit umzugehen ist. In einem Offshore-Projekt war das Entwicklungs-Team wiederholt nicht in der Lage zum Ende des Sprints die zugesagten Funktionalitäten zu liefern. Gleichzeitig gab es auf Seiten des Auftraggebers große Schwierigkeiten und Kraftanstrengungen, die Anforderungen in der geforderten Detailliertheit zu liefern, wobei diese dann auch nur zum kleinsten Teil umgesetzt wurden.

Unser typisches Vorgehen in einem solchen Fall ist es, in einer kurzen Ist-Aufnahme mit Hilfe von Interviews, Workshops und Dokumentensichtungen die Problemursachen zu identifizieren. Im konkreten Projektbeispiel waren fehlende Kommunikation und Abstimmung zwischen On- und Offshore, aber auch innerhalb des Offshore-Teilteams die Ursache. Des Weiteren war der Ansatz der Anforderungsbeschreibung zu ausführlich und schwergewichtig, während Lösungsalternativen nicht im Vorfeld diskutiert und beschrieben wurden.

Auf die Ist-Aufnahme folgt die Konzeption der Prozessverbesserung. Im besagten Projekt wurden Word- und Excel-basierte Spezifikationen durch Tickets in einem Ticket-System ersetzt. Jede Anforderung wurde in einem Ticket beschrieben und nach dem Prinzip des spätmöglichsten Zeitpunkts schrittweise verfeinert. Zu jeder Anforderung wurden im Laufe der Verfeinerung Lösungsalternativen stichpunktartig skizziert und geschätzt und schließlich eine Alternative ausgewählt. Zwischen den einzelnen Verfeinerungs- und Entscheidungsschritten wurden Abstimmungsgespräche vorgesehen und explizite Ticket-Status eingeführt.

Die Einführung von Prozessänderungen sollte gerade bei größeren Veränderungen systematisch erfolgen. Im dargestellten Projekt wurden alle Projektteilnehmer in einem Webinar durch den neuen Prozess geführt. Außerdem wurde im Ticket-System einen Beispielsprint erstellt, der Tickets in allen Stufen der Verfeinerung enthält und zur Orientierung diente. Zusätzlich wurde eine Dokumentation erstellt, die beschreibt, wer wann und mit welchem Ziel ein Ticket verfeinert und den Status entsprechend aktualisiert.

Über diese Veränderungen im Entwicklungsprozess wurden erfolgreich die Probleme des Projektes adressiert: Vorher gab es oft Sprints bei denen die Funktionalitäten nicht geliefert wurden. Jetzt wurden die Entwickler im Vorfeld eines Sprints gezwungen Lösungsalternativen und verbundene Aufwände mir den Business Analysten zu diskutieren. Damit waren die Schätzungen besser und der zugesagte Sprintumfang wurde eingehalten. Außerdem war es vorher für die Business Analysten des Auftraggebers nicht einfach, die Anforderungen wie gefordert zu beschreiben. Jetzt wurden Anforderungen leichtgewichtiger beschrieben und auch erst kurz vor dem Zeitpunkt verfeinert, zu dem sie auch tatsächlich entwickelt wurden. Damit wurden Aufwände zielgerichteter fokussiert.

Über passende Prozesse zu hoher Qualität

Oft werden Verbesserungspotentiale von Softwareentwicklungsprozessen nicht aufgedeckt, sondern stattdessen Reibungsverluste unwissend in Kauf genommen. Eine typische Ursache liegt darin begründet, dass die Projektbeteiligten Veränderungen am Prozess nicht als Problemlösungsdimension betrachten. Stattdessen werden z.B. Personen ausgetauscht oder zusätzliche Personen ins Projekt aufgenommen.

Die hier vorgestellten Ansätze der Erstellung und Verbesserung von Softwareentwicklungsprozessen können ihren Beitrag dazu leisten, die Teams mit Best Practices und Verbesserungen zu versorgen. Softwareentwicklungsprozesse sollten nicht entsprechend One-Size-Fits-All als starrer, unveränderlicher Umstand verstanden werden. Stattdessen sind sie ein wichtiger Faktor für Verbesserungen und damit für effizient entwickelte, hochqualitative Software.

Ansprechpartner: Dr. Masud Fazal-Baqaie

 

Literatur:

[1] Fazal-Baqaie, Masud: Project-specific software engineering methods: composition, enactment, and quality assurance. Dissertation, Universität Paderborn (2016)

[2] Masud Fazal-Baqaie, Gregor Engels: Software Processes Management by Method Engineering with MESP. In: Managing Software Process Evolution. Springer (2015)

[3] Masud Fazal-Baqaie, Baris Güldali, Marvin Grieger: Ganzheitliches Qualitätsmanagement in agilen Groß- Projekten. In: Proceedings of Projektmanagement und Vorgehensmodelle 2016. GI Lecture Notes in Informatics (LNI), pp. 109-120 (2016)

[4] Masud Fazal-Baqaie, Anu Raninen: Successfully Initiating a Global Software Project. In: Industrial Proceedings of the 22nd European Systems Software & Service Process Improvement & Innovation Conference (EuroSPI²2015). WHITEBOX, Denmark (2015)

[5] Masud Fazal-Baqaie, Stefan Sauer, Torsten Heuft: Agile Entwicklung mit On- und Offshore-Partnern – Methodenverbesserung in der Praxis. In: Proceedings of Projektmanagement und Vorgehensmodelle 2014. GI Lecture Notes in Informatics (LNI) (2014) 

Kontakt

Barbara Buthmann

Marketing

Person_Bild

Telefon +49 5251 1581-61
E-Mail senden