Applying a Requirements-Focused Agile Management Approach for Machine Learning-Enabled Systems

Technische Zusammenfassung: Anwendung eines anforderungensorientierten agilen Managementansatzes für Machine-Learning-gestützte Systeme

Problemstellung
Machine-Learning (ML)-gestützte Systeme stellen die traditionelle Requirements Engineering (RE) und das agile Management vor einzigartige Herausforderungen. Im Gegensatz zu deterministischer Software hängen ML-Systeme von Datenabhängigkeit, Experimenten und unsicherem Modellverhalten ab, wodurch die Ergebnisse von der Datenqualität und den Modellierungsentscheidungen abhängen. Während das agile Management konzeptionell mit der iterativen Natur von ML übereinstimmt, scheitert die direkte Anwendung oft aufgrund von:

• Unrealistischen Kundenerwartungen und mangelnder Abstimmung zwischen Business-Stakeholdern und ML-Praktikern.
• Schwierigkeiten bei der Sprintplanung und Aufwandsschätzung aufgrund der experimentellen Natur von ML-Aufgaben (z. B. Datenvorverarbeitung, Feature Engineering).
• Einem Mangel an gut definierten Leitlinien zur Anpassung agiler Praktiken an ML-Projekte, was zu Kommunikationslücken und Mehrdeutigkeiten in den Anforderungen führt.
  Bestehende Ansätze versäumen es oft, vollständig zu adressieren, wie ML-spezifische Belange identifiziert und von Projektbeginn an in umsetzbare Anforderungen überführt werden sollten.

Methodik: Der RefineML-Ansatz
Die Autoren schlagen und evaluieren RefineML vor, einen anforderungsfokussierten Ansatz zur kontinuierlichen und agilen Verfeinerung von ML-gestützten Systemen. RefineML integriert drei Kernkomponenten, die aus dem aktuellen Stand der Forschung und einer systematischen Mapping-Studie abgeleitet wurden:

1. PerSpecML: Ein Ansatz zur Anforderungsspezifikation, der ML-Belange in fünf Perspektiven strukturiert: Systemziele, Nutzererfahrung, Infrastruktur, Modell und Daten.
2. Agile4MLS: Ein agiles Management-Framework, das Scrum für ML adaptiert, indem es duale Backlogs (Software und ML), „Data Stories“ und „Model Stories“ sowie ein „Two-Sprints-Ahead“-Prinzip einführt, um die ML-Experimentation von der Softwareentwicklung zu entkoppeln.
3. Lean R&D Konzepte: Speziell das Minimal Valuable Model (MVM) (ein lebensfähiges, nicht optimales Modell zur frühen Wertschöpfung) und Layers of Done (LoD) (Meilensteine, die die Robustheit und Validierung des Modells definieren).

RefineML Prozessphasen
Der Ansatz strukturiert den Projektlebenszyklus in vier Phasen:

• Initial Specification (Initiale Spezifikation): Unter Verwendung von PerSpecML definiert das Team Anforderungen über die fünf Perspektiven hinweg, um ein gemeinsames Verständnis von Zielen und Bewertungskriterien zu etablieren.
• Conception (Konzeption): Der Product Owner strukturiert zwei komplementäre Backlogs: ein Software-Backlog (konventionelle User Stories) und ein ML-Backlog (Data und Model Stories). „Enabler“ werden definiert, um Infrastruktur- und Architekturabhängigkeiten zu verwalten.
• Technical Feasibility (Technische Machbarkeit): Das Team führt eine Daten-Machbarkeit (Bewertung der Datenverfügbarkeit/-qualität) und eine Modell-Machbarkeit (Bewertung der Eignung des Algorithmus) durch und implementiert eine Demo API. Die Demo API emuliert die erwartete ML-Ausgabe, was dem Software-Team ermöglicht, mit der Integration fortzufahren, während das ML-Team die Experimentation fortsetzt.
• Agile Development (Agile Entwicklung): In Anlehnung an Agile4MLS führt das Team synchronisierte Iterationen aus. Das ML-Team arbeitet „zwei Sprints im Voraus“, entwickelt die Demo API zu einem MVM und nachfolgenden LoDs weiter, während das Software-Team Funktionen basierend auf der emulierten Schnittstelle implementiert.

Evaluierungskontext und Datenerhebung
RefineML wurde im Rahmen einer sechsmonatigen Industrie-Akademien-Kooperation (IAC) zwischen der PUC-Rio und EXA, einem brasilianischen Cybersicherheitsunternehmen, angewendet. Das Ziel des Projekts war die Entwicklung von ML-Funktionen für den Online-Betrugsschutz, einschließlich der Erkennung von Scam-Nachrichten, URL-Analyse und Screenshot-Analyse.

• Teilnehmer: Ein Team aus zehn Praktikern (Entwickler und Data Scientists), ein Projektleiter und Business Owner.
• Datenerhebung: Ein Fragebogen basierend auf dem Technology Acceptance Model (TAM) wurde an das Entwicklungsteam verteilt, um die wahrgenommene Nützlichkeit, die Benutzerfreundlichkeit und die Nutzungsabsicht zu bewerten. Semi-strukturierte Interviews wurden mit dem Projektleiter und dem Business Owner geführt.
• Analyse: Quantitative Daten wurden mittels deskriptiver Statistik analysiert, während qualitative Daten einer thematischen Analyse unterzogen wurden.

Wichtigste Ergebnisse und Erkenntnisse

• Problemlösungsfähigkeit: RefineML lieferte erfolgreich innerhalb von sechs Sprints eine produktionsreife Suite von ML-Komponenten. Das Team lieferte früh im Zyklus ein funktionierendes MVM, das die bestehende Betrugspräventionslösung übertraf. Der Ansatz erleichterte die Orchestrierung der dualen Arbeitsweise (ML-Experimentation vs. Produktlieferung) und reduzierte blockierende Abhängigkeiten.
• Eignung der Phasen:
  • Initial Specification: Wurde als effektiv für die Abstimmung der Erwartungen wahrgenommen, obwohl einige sie ohne starke Moderation als „langatmig“ empfanden.
  • Conception & Feasibility: Die duale Backlog-Struktur und das „Enabler“-Konzept wurden als entscheidend für die Trennung von Experimentation und Integration angesehen. Daten- und Modell-Machbarkeit wurden als „Must-have“-Schritte betrachtet, um eine Analyse-Paralyse zu vermeiden.
  • Development: Das „Two-Sprints-Ahead“-Prinzip und der MVM-Ansatz wurden hoch geschätzt, da sie den Data Scientists „Sicherheit“ gaben und die „Suche nach 99 % Genauigkeit“ verhinderten.
• Gesamtakzeptanz: Die Stakeholder berichteten von einer hohen wahrgenommenen Nützlichkeit und der Absicht, RefineML weiterhin zu nutzen. Der Business Owner bezeichnete den Ansatz als „sinnvoll“ und äußerte die Absicht, ihn für zukünftige Initiativen einzusetzen.
• Einschränkungen:
  • Operationalisierung: Die Übersetzung von PerSpecML-Belangen in umsetzbare ML-Backlog-Items (Data/Model Stories) erwies sich für weniger erfahrene Praktiker als schwierig und hing stark von erfahrener Moderation ab.
  • Schätzung: Die stochastische Natur von ML machte die Aufwandsschätzung zu einer anhaltenden, ungelösten Herausforderung. Praktiker merkten an, dass die Vorhersage von Ergebnissen (z. B. Genauigkeitsverbesserungen) weiterhin unzuverlässig bleibt.
  • Komplexität: Junior-Entwickler empfanden den Ansatz ohne erfahrene Anleitung als komplex, während erfahrene Stakeholder ihn als „wirklich einfach“ wahrnahmen.

Bedeutung und Ansprüche
Das Paper behauptet, dass RefineML einen praktischen, anforderungsfokussierten Rahmen bietet, der die Lücke zwischen agilem Management und der experimentellen Natur von ML schließt. Die primäre Bedeutung liegt in:

1. Verbesserter Kommunikation: Durch die Explizitmachung von ML-Anforderungen, -beschränkungen und -fortschritten mittels Artefakten wie LoDs und dualen Backlogs reduziert der Ansatz die Wahrnehmung von ML als „Black Box“ und verbessert die Abstimmung zwischen Business- und Technik-Teams.
2. Scaffolding der Machbarkeit: Die frühen Machbarkeitsphasen (Daten/Modell) bieten einen strukturellen Rahmen, um Projekte in der technischen Realität zu verankern, Risiken frühzeitig aufzudecken und Spätphasen-Fehler zu verhindern.
3. Governance der Co-Evolution: Die duale Struktur ermöglicht die kontinuierliche Verfeinerung von ML-Modellen, ohne die Softwarelieferung zu verzögern, was eine inkrementelle Wertschöpfung durch das MVM-Konzept ermöglicht.

Die Autoren schließen bescheiden, dass RefineML zwar die Kommunikation und Governance effektiv steuert, jedoch nicht die intrinsische Unsicherheit der ML-Aufwandsschätzung löst. Sie schlagen vor, dass zukünftige Verbesserungen darauf abzielen sollten, die Eintrittsbarrieren für weniger erfahrene Praktiker zu senken und bessere Mechanismen für eine ML-bewusste Aufwandsschätzung zu entwickeln.