In dieser Rubrik finden Sie spannende Informationen zum Thema Requirements Engineering.

Herr Andreas Schlier hat ein Problem. Nach über 15 Jahren stößt seine selbstentwickelte Excel-Lösung zur Visualisierung von Steuergerät-Programmiervorgängen an technische Grenzen. Das Datenvolumen wird einfach zu groß. Auch übersteigen die Wartungsaufwände das jährlich eingeplante Budget. Obendrein verabschiedet sich sein treuer Kollege in Altersteilzeit und dass, obwohl dieser als einziger das Tool weiterentwickeln und warten kann. Was tun?

Ganz klar, eine neue Business Software muss her. Doch wie diese finden?

Im mosaiic Impuls finden Sie diese Woche einen rund 20-minütigen Videobeitrag zur Auswahl von Business Software.

Videobeitrag:

mosaiic GmbH - Finding perfect - Die optimale Business Software finden

Sie haben Fragen zum Thema Business Software Auswahl und möchten das Thema weiter vertiefen? Kontaktieren Sie uns für weitere Fragen. Wie freuen uns auf die Diskussionen.

Arbeiten Sie agil? Nach Scrum? Oder sind Sie bereits eine Stufe weiter und koordinieren mehrere agile Teams gleichzeitig? Wenn Sie aktuell ihre agile Vorgehensweise skalieren möchten, dann ist dieser mosaiic Impuls für Sie relevant. Wir haben uns die populärsten large-scale Ansätze detailliert angesehen und gegenübergestellt. Finden Sie damit das passende Agile Framework für Ihre Organisation.

Agile Framework – die Übersicht

Scaling Agile ist momentan ein großer Trend in den meisten Industrien. In nachfolgender Tabelle haben wir 5 der bekanntesten Large-Scale Agile Frameworks anhand von 10 Kriterien miteinander verglichen. Grundlage war eine intensive Literatur- und Webrecherche, entsprechende Quellen finden Sie direkt in den Zellen verlinkt.

Top-Kernerkenntnisse

  •  Alle betrachteten agilen Ansätze finden ihren Ursprung in Scrum.
  • Falls Ihr Unternehmen plant agil zu skalieren, empfehlen alle Frameworks zunächst die Prinzipien von Scrum zu verinnerlichen sowie Erfahrungen auf Teamebene zu sammeln.
  • Für die Umsetzung der Frameworks empfehlen alle betrachteten Ansätze die Unterstützung von erfahrenen Scrum Coaches zertifiziertem Personal.
  • Die Umsetzungsdauer der Agile Frameworks variiert. Auf keinem Fall handelt es sich um ein kurzzeitiges Unterfangen.
  • Das Scaled Agile Framework (SAFe) Framework ist sehr umfangreich und unflexibel, jedoch auch das Framework mit der besten Anleitung und ausgeprägtesten Struktur. Gerade wenn Ihre Organisationen von starken Strukturen bzw. geringer Agile Expertise geprägt ist, lohnt sich ein Blick auf diesen Ansatz

Kriterien

Agile Frameworks

Beschreibung

Scrum@Scale

Scaled Agile Framework (SAFe)

Large Scale Scrum (LeSS)

Disciplined Agile Delivery (DAD)

Nexus Framework

Lizenzierung

opensource

opensource

opensource

opensource

opensource

Notwendige Lizenzen, Personen-lizenzen, Unternehms-lizenzen

Teamanzahl

ideal mit 5 Teams à 5 Personen pro SoS
(25 Teams – SoSoS)

5 -15 Teams pro Release Train

< 8 Teams

unbestimmt

3-9 Teams

Minimale und maximale Anzahl der einsetzenden Teams (á 8 Personen)

Dokumentation

Wikis, Home-Website

Wikis, Home-Website, Bücher

Wikis, Home-Website, Bücher

Wikis, Home-Website, Bücher

Wikis, Home-Website, Bücher

Arten der Beschreibung des Frameworks

Qualifikation

Certified Scrum@Scale Practitioner

Certified SAFe® Program Consultant
Certified SAFe® Practitioner, etc.

Certified LeSS Practitioner
Certified LeSS for Executives
Certified LeSS Basics

Certified Disciplined Agile Coach
Certified Disciplined Agile Instructor

Scaled Professional Scrum Certification

Empfohlene Ausbildungs- und Trainings-maßnahmen

Verbindlich-keitsgrad

lose

sehr strikt

lose

strikt

Lose

Lose Empfehlungen bis zu strikten Vorgaben

Verteilte Arbeit
siehe Link

anwendbar

anwendbar jedoch nicht empfohlen

anwendbar

schwierig

anwendbar

Unterstützung global verteilter Teams durch das Framework

Anpassbarkeit
siehe Link

keine festen Vorgaben,
höchst anpassbar

viele Rollen-definitionen,
sehr unflexibel und schwerfällig

auf unter-schiedliche Situationen
gut anpassbar

flexibel durch mehrere optionen

flexibel, minimalistisch, geringe Abwandlung vom originellen Scrum

Alles oder nichts bis zu hochgradig adaptierbar

Suchvolumen
siehe Link

1.600 pro Monat (scrumscale)

11.908 pro Monat (safe agile)

2.400 pro Monat (less agile)

1.000 pro Monat (dad agile)

1,300 pro Monat (Nexus scrum)

Suchanfrage in Google

Ursprung
siehe Link

Scrum

Scrum, Kanban, etc.

Scrum

Scrum, Kanban, etc.

Scrum

Scrum vs Kanban Ansätze

Verantwortliche Organisation

Jeff Sutherland

 Dean Leffingwell and Drew Jemilo

Craig Larman und Bas Vodde
The LeSS Company B.V.

Scott Ambler and Mark Lines

Ken Schwaber und scrum.org

Unternehmen oder Universität oder Einzelperson oder öffentliche Organisation

  • Für Systemnutzer spielt nicht nur das Was (= die Funktion), sondern auch das Wie (= die Güte der Funktionserbringung) eine Rolle. Ein Ignorieren von Qualitätsanforderungen führt in vielen Fällen zur Ablehnung des (voll funktionsfähigen) Systems.
  • Qualitätsanforderungen bestimmen maßgeblich die Architektur eines Systems, also dessen Infrastruktur, Softwarearchitektur und Softwaredesign.

Sie haben Fragen zu einem Agile Framework? Gerne gehen wir mit Ihnen in die Diskussion! Kontaktieren Sie Herrn Viktor Korcok.

Text: Christopher Schulz, Analyse: Viktor Korcok

In den meisten von uns begleiteten Projekten sind sie der Star: die funktionalen Anforderungen. Was muss das neue IT-System alles können? Welche besonderen Eigenschaften besitzen? Welches spezifische Verhalten an den Tag legen?

Eine Nischenrolle spielen hingegen die Qualitätsanforderungen, also die Gütekriterien wie eine Funktion erbracht wird. Und genau hier liegt ein Risiko. Qualitätsanforderungen bestimmen maßgeblich die Systemarchitektur. Auch entscheidet ihre Erfüllung darüber, ob ein System vom Nutzer akzeptiert wird oder nicht. Grund genug das Thema Qualitätsanforderungen in einem mosaiic Impuls aufzugreifen.

Qualitätsanforderungen sind Nichtfunktionale Anforderungen

Funktionale Anforderungen, Qualitätsanforderungen, nicht-funktionale Anforderungen – schnell kommt man da durcheinander. Wann ist eine Anforderung eine Qualitätsanforderung? Und worin besteht der Unterschied zur Nicht-funktionalen Anforderung?

Beginnen wir den mosaiic Impuls mit drei Erklärungen. Frei übersetzt aus dem Englischen definiert der Glossary of Requirements Engineering Terminology des International Requirements Engineering Boards (IREB):

    null
  • Ein Funktionale Anforderung ist eine Anforderung, die sich auf Ergebnis eines Verhaltens einer Systemfunktion bezieht.
  • Eine Qualitätsanforderung betrifft ein Qualitätsanliegen an ein System, welches nicht durch eine Funktionale Anforderung abgedeckt wird.
  • Eine Randbedingung ist eine Anforderung, welche den Lösungsraum für eine Funktionale Anforderung oder Qualitätsanforderung limitiert.

IREB fasst Randbedingungen und Qualitätsanforderungen unter dem Begriff der Nicht-funktionalen Anforderungen zusammen. Randbedingungen betreffen sowohl das System, als auch die Vorgehensweise, mit welcher das System entwickelt wird (z.B. agiles Projektmanagement, Einbettung in das LeSS Framework).

Qualitätsanforderungen fristen in Projekten oft ein Nischendasein

In der Praxis stellen wir fest, dass sich die Stakeholder sehr stark auf die Funktionalen Anforderungen eines Systems konzentrieren. Wenn überhaupt, wird ganz am Schluss eines Anforderungstermins noch einmal auf die Qualitätsanforderungen eingegangen. Es fallen dann oft geschlossene Fragen wie „In Sachen Performance haben wir keine Einschränkungen, oder?“ bzw. „Wollen wir noch notieren, dass das System benutzerfreundlich ist?“.

Zudem werden die Funktionsqualitäten oft als gegeben angesehen. Aussagen wie „Ist doch klar, dass das neue System einfach bedienbar sein soll.“ oder „Natürlich wird die APP 24/7 weltweit verfügbar sein.“ fallen – wenn überhaupt – nur am Rande. Ein Fehler. Warum? Aus genau zwei Gründen.

  • Für Systemnutzer spielt nicht nur das Was (= die Funktion), sondern auch das Wie (= die Güte der Funktionserbringung) eine Rolle. Ein Ignorieren von Qualitätsanforderungen führt in vielen Fällen zur Ablehnung des (voll funktionsfähigen) Systems.
  • Qualitätsanforderungen bestimmen maßgeblich die Architektur eines Systems, also dessen Infrastruktur, Softwarearchitektur und Softwaredesign.
Das Qualitätsanforderungen Cheat Sheet

Robustheit, Portabilität, Benutzerfreundlichkeit, Wartbarkeit,… Sicher fallen Ihnen schnell mehrere typische Qualitätsanforderungen ein. Um nicht in jedem Projekt das Rad ständig neu erfinden zu müssen bzw. keine Qualitätsanforderung zu vergessen stützen wir uns in den Projekten auf den ISO/IEC 25010. Dieser Normteil ist fester Bestandteil der Standardserie ISO/IEC 25000 Systems and software engineering: System and Software Quality Requirements and Evaluation (SQuaRE). Die aktuelle Fassung ISO 25010 aus dem Jahr 2014 unterteilt die Qualität eines Softwareprodukts in acht Qualitätsmerkmale. Nachfolgende Abbildung zeigt die aus der englischen Sprache übersetzte Fassung.

Abbildung – Kategorien von Qualitätsanforderungen angelehnt an den ISO/IEC 25010


Nutzen Sie diese Übersicht als „Cheat Sheet“, also als Spickzettel für die systematische Betrachtung der definierten Anforderungen an eine Systemfunktion. Ergänzen Sie dazu einfach den Begriff ‚Anforderung‘, also beispielsweise ‚Sicherheitsanforderung‘ oder ‚Wartbarkeitsanforderung‘. Gerne können Sie den Ein-Seiter anpassen und für Ihre fachliche Domäne zurechtschneidern.

Eine detaillierte englischsprachige Beschreibung der Qualitätsmerkmale und -submerkmale finden Sie im Standard. Natürlich können Sie uns bei Fragen ebenfalls ansprechen.

Fazit

Qualitätsanforderungen spielen in der Anforderungserhebung meist eine unterordnete Rolle. Klarer Platzhirsch sind die Funktionalen Anforderungen. Für diese investieren die Stakeholder den Großteil ihrer Zeit und Energie. Dabei können übersehene Qualitätsanforderungen zur Nicht-Akzeptanz des Systems und einer brüchigen Architektur führen. Nutzen Sie das oben vorgestellte Cheat Sheet um Qualitätsanforderungen systematisch aufzuspüren.

Sie planen Requirements Engineering bei sich als Unternehmensfunktion zu etablieren? Bestehende RE-Prozesse sollen agil und fit für die Digitalisierung gemacht werden? Sie suchen ein passendes Requirements Engineering Tool?
Gerne unterstützen wir Sie dabei! Vereinbaren Sie ein Gespräch mit unserem Requirements Engineering Experten und decken Sie Verbesserungspotentiale in Ihrem Management von Anforderungen auf.

Stellen Sie sich vor, Sie wollen eine Process Mining Initiative starten. Bevor Sie loslegen können, müssen Sie bei der internen IT die erforderliche Infrastruktur beantragen. Datenbank, Application Server, Client Software, Schnittstellen – bis ihre Anträge durch sind und von den entsprechenden Stellen genehmigt wurden, können schnell ein paar Wochen vergehen. Dabei wollten Sie eigentlich nur testen, ob Process Mining überhaupt für Ihre Abteilung in Frage kommt.

Abhilfe schafft eine Cloud-basierte Lösung. Die Berliner Firma Signavio hat eine solche im Programm. Wir haben uns das Produkt Signavio Process Intelligence genauer angesehen und zeigen Ihnen in diesem mosaiic Impuls, worin die Stärken und Schwächen der Softwarelösung liegen.

Process Mining mit Signavio Process Intelligence

Seit 2016 bietet das Berliner Unternehmen Signavio GmbH die Lösung Signavio Process Intelligence zur Analyse von Geschäftsprozessen an. Das Tool ist damit ein eher junger Vertreter am Process Mining Software Markt. Signavio wurde 2009 als Spezialist für cloud-basierte, kollaborative und nutzungsfreundliche Prozessmodellierung gegründet und hat in den vergangenen 10 Jahren sein Produktportfolio rund um das Thema Prozesse kontinuierlich ausgebaut. Anfang 2019 zählen zur sogenannten Signavio Business Transformation Suite der Process Manager, der Workflow Accelerator, der Collaboration Hub und eben Process Intelligence.

Für die mosaiic Process Mining Tool Survey 2019 nehmen wir Signavio Process Intelligence in der Version 12.7.4 genauer unter die Lupe. Wie seine Schwesterlösungen ist Process Intelligence ebenfalls eine reine Software-as-a-Service (SaaS) Applikation, läuft vollständig Cloud-basiert im Rechenzentrum von Amazon Web Services (AWS). Für Software und Betrieb rechnet Signavio entweder pro Prozessinstanz (= ausgeführter Prozess) oder je End-zu-End Prozess ab.

Nach Einrichtung Ihrer virtuellen Instanz können Sie diese an Ihre Prozessdatentöpfe koppeln. Signavio unterstützt hier ein weites Feld, angefangen von IBM DB2 und Orcacle DB, über PostgreSQL und Microsoft SQL Server bis hin zu SAP Hana und Hadoop Data Lake. Die Lösung selbst nutzt PostgreSQL, Amazon S3 und eine speziell für die Anforderungen an Process Mining optimierte In-Memory Datenbank, in welcher die Mining Daten abgelegt werden.

Einmal importiert, steht in der sich anschließenden Prozessanalyse das sogenannte Investigation Notebook im Zentrum. Auf Grundlage Ihrer Fragestellungen bauen Sie sich in diesem Dashboard mittels modularen Widgets ein individuellen Process Mining Report zusammen. Eine kleine Auswahl von Widgets:

  • Process-Discovery-Widget: Visualisierung des erhobenen Ist-Prozesses.
  • Process-Conformance-Widget: Gegenüberstellung von erhobenen Ist- und modellierten Soll-Prozess.
  • KPI-Widget: Anzeige von Prozesskennzahlen wie Durchlaufzeit, Varianten, etc..
  • Process-Variant-Widget: Visualisierung der in der Praxis gelebten Varianten eines Prozesses.
  • Weitere Widgets wie Calculation-Widget, Histogram-Widget, Variable-Importance-Widget, Process-Funnel-Widget und Time-Series-Widget

Ein Widget erlaubt das Filtern der Daten. So bestimmen Sie mit wenigen Mausklicks, welche bestehenden Prozessinstanzen im Scope Ihrer Detailanalyse sind.

Pros
  • Signavio Process Intelligence gleicht Ist- und Soll ab: Den im Process Manager modellierten Soll-Prozess können Sie über den per Process Intelligence gewonnenen Ist-Prozess legen und detailliert abgleichen.
  • Signavio Process Intelligence bedient sich per Webbrowser: Sie nutzen das Tool einfach und flexibel mit Ihrem Webbrowser. Die Bedienung ist intuitiv, das Look & Feel wirkt für uns frisch und modern.
  • Signavio Process Intelligence ordnet und fasst zusammen: Alle wichtigenInfos zu einem Prozess finden Sie im frei konfigurierbaren Investigation Notebook. Dieses lässt sich mittels der Widgets individuell anpassen.
  • Signavio Process Intelligence unterstützt die Zusammenarbeit: Auf Basis des zusätzlichen Collaboration Hubs geben Sie die Kernerkenntnisse aus der Prozess Mining Analyse an die Prozessbeteiligten weiter. Unternehmensübergreifend.
Cons
  • Signavio Process Intelligence erfordert eine Internetverbindung: Zur Nutzung der Web-Lösung müssen Sie bzw. Ihre Kollegen online sein.
  • Signavio Process Intelligence nutzt Amazon Web Services: Ihre Prozessdaten verwaltet die Lösung beim Online Riesen Amazon. Dabei kann ein Kunde Ende 2018 zwischen den voneinander isolierten Hosting-Standorten Frankfurt, Virginia und Sydney wählen.
  • Signavio Process Intelligence spielt alle Vorteile nur im Verbund aus: Erst in Kombination mit dem Collaboration Hub und den Process Manager entfaltet die Process Mining Lösung ihr gesamtes Funktionspotential. Laut Signavio ist in 99 Prozent der Kundenszenarien ein zusammenschalten der Suite-Module notwendig.

Methode

Die Grundlage unserer Tool-Untersuchung bildet ein strukturierter Analysebogen. Auf Basis von 47 Fragen aus 8 verschiedenen Kategorien evaluierten wir im persönlichen Dialog mit dem Tool-Hersteller die Fähigkeiten und Eigenschaften seiner Process Mining Lösung. Zudem sichteten wir weiteres verfügbares Begleitmaterial wie Video Tutorials sowie Info Webinare.
Neben generellen Werkzeug- und Betriebsaspekten wie Schnittstellen, Softwarearchitektur und Lizenzierung untersuchten wir spezifische Aufgaben und Bedarfe aus der Disziplin des Process Minings. Den fachlichen Rahmen spannte dabei das Buch Process Mining: Data Science in Action des Process Mining Pioniers Wil M. P. van der Aalst auf.

Fazit

Als Spezialist für Prozessmodellierung ist es nachvollziehbar, dass Signavio ebenfalls eine Process Mining Lösung im Programm hat. Diese integriert sich reibungsfrei in die vorhandene Tool-Kette der Berliner. Die Kombination von Investigation Notebook und individuell hinzuschaltbaren Widget finden wir clever. Sowieso kann Signavio in Sachen Benutzerschnittstelle keiner etwas vormachen. Wollen Sie die Lösung testen, so können Sie auf der Hersteller-Webseite einen 30-Tage Testzugang anlegen. 

Analyse: Tobias Smuda, Text: Dr. Christopher Schulz

Sie planen Process Mining mit Signavio Process Intelligence umzusetzen? Informieren Sie sich detailliert über die Stärken und Schwächen dieser Softwarelösung. Laden Sie sich dazu das 8-seitige Fact Sheet herunter.

Die Montageplanung eines süddeutschen Automobilunternehmens entwickelt bisher ihre Prozesse und Systeme nach klassischer Wasserfall-Vorgehensweise. Nun soll ein neues Montage-Steuerungsplansystem auf Basis von Scrum realisiert werden. Der agile Ansatz verspricht schnellere Resultate und engere Zusammenarbeit zwischen der Fach- und IT-Seite. Das Problem dabei: die beauftragte Fachabteilung ist mit Scrum und dem notwendigen Product Backlog nicht vertraut. Wie soll das Team innerhalb kurzer Zeit ein fundiertes Backlog für die technischen Entwickler liefern?

Problem: Umstieg auf Scrum in der Fachabteilung – ein Product Backlog muss her

„Agil, agil, agil – ich kann das Wort langsam nicht mehr hören!“. Elke Berlitz – Leiterin der Montageplanung Automotive – stöhnte leicht und drehte frustriert ihren Kopf zur Seite. Ihr gegenüber saß Jens Karstens, ein junger IT-Projektleiter, der zuvor bei einem Technologie Start-up tätig gewesen war. Seit 1999 war Elke Berlitz jetzt in der Firma. Bisher hatte sie und ihre Kollegen Prozess- bzw. IT-Systementwicklungen klassisch mit einem Grob- und mit einem Fachkonzept definiert. Das Dokument übergab ihr Team dann an den verantwortlichen IT-Projektleiter. Dieser trieb die Implementierung voran und lieferte was die Fachseite zuvor spezifiziert hatte.

Soweit, so gut. Zumindest für ihre knapp 20 Jahre im Unternehmen. Nun sollte dieses bewährte Wasserfall-Vorgehen aus Analyse, Design, Umsetzung, Test und Roll-out abgelöst werden. Statt die einzelnen Phasen nacheinander zu durchlaufen, war Berlitz und ihr Team nun für ein sogenanntes Product Backlog verantwortlich. Eine Liste mit Anforderung, die Tag für Tag wuchs, stetig im Fluss war und als dynamische Diskussionsgrundlage mit den Entwicklern diente.

„Für das neue Montage-Steuerungsplansystem brauchen wir ein solides Product Backlog.“ insistierte Jens Karstens und ergänzte „Dieses untergliedert sich in Epics, die wiederum einzelne User-Stories enthalten. Jede User Story verfeinert ihr durch mehrere Akzeptanzkriterien und weist ihr schließlich eine Priorität zu. Was ist daran so kompliziert?“. Elke Berlitz rollte mit den Augen. „Jens, Du hast gut reden. Du kennst agile Entwicklungsverfahren wie Scrum von Deinem früheren Arbeitgeber. Doch bei uns? Backlog, Stories, Epics – das sind für die Fachkollegen doch alles nur böhmische Dörfer.“.

Jens Karstens ließ nicht locker: „Ich verstehe, der Scrum Ansatz ist hier neu. Doch beachte seine Vorteile. Statt ein großes Fachkonzept bis zur Perfektion zu treiben, nähern wir uns schrittweise der Ideallösung. In wenigen Monaten haben wir ein erstes lauffähiges IT-System auf Basis dessen Ihr Eure optimierten Fachprozesse umsetzen könnt. Stück für Stück erweitern wir dann dieses System.“. Berlitz nickte. Tatsächlich bot ein agiler Ansatz mehrere Vorteile. Nicht umsonst hatten sich ihre Chefs diesem neuen Modell verpflichtet. Doch half ihr das in Sachen Backlog auch nicht weiter.

Da das Meeting gleich zu Ende war, warf Frau Berlitz ein: „Ich schlage vor, wir lassen uns bei unserem ersten Product Backlog durch einen externen Experten unterstützen.  Jemanden, der die Struktur, das Vorgehen und die Eigenschaften eines guten Backlogs genau kennt. Ein Dienstleister, dem wir vertrauen können und der die Sache in unserem Sinne mit hoher Qualität vorantreibt.“. „Klingt gut.“ entgegnete Jens Karstens „An wen hast Du gedacht?“.

Vorgehen: Gemeinsame Arbeit an den User Stories – nach agilem Ansatz und klaren Kriterien

Elke Berlitz zögerte nicht lange und kontaktierte die fachkundigen Requirements Engineering Experten von mosaiic. In der Vergangenheit hatten diese für Ihr Unternehmen exzellente Grob- und Fachkonzepte in der Montageplanung verfasst. Von einem Kollegen aus dem Elektronik/Elektrik-Bereich hatte sie gehört, dass mosaiic auch den Scrum Product Owner bei der Erstellung des Product Backlogs zur Seite stand. Erfreut, Elke Berlitz unterstützen zu können, erfassten die mosaiic Berater zunächst den funktionalen Scope des Systems. Dazu klärten sie folgende Fragen:

  • Welche System- und Kontextgrenzen besitzt das Montage-Steuerungsplansystem?
  • Welche Anforderungsquellen sind zu berücksich-tigen (Dokumente, Systeme, Experten)?
  • Neben User Stories: wie soll das Montage-Steuerungsplansystem noch beschrieben werden?

Die Ergebnisse erfassten die Consultants in einem Big Picture (siehe Abbildung). Dem gesamten Team war damit jederzeit klar, aus welchen Quellen die Anforderungen kamen, wie das Product Backlog aufgebaut sein sollte und welche Ergebnisse neben dem Backlog Einträgen noch entstehen würden.

Montage-System: Von den Anforderungsquellen zum ausgereiften Product Backlog

Abbildung: Montage-System: Von den Anforderungsquellen zum ausgereiften Product Backlog

Die Berater bestanden darauf, mit der fachlich wichtigsten Epic zu beginnen – der Anlage eines Montage-Steuerungsplans. In einer Serie von zwölf 90-minütigen Arbeitssitzungen spezifizierten sie gemeinsam mit Elke Berlitz und ihren Kollegen rund 50 User Stories inklusive Akzeptanzkriterien. Grundlage war das aus Scrum bekannte CCC-Prinzip. Jede User Story fixierte das Team auf einer eigenen Karte (Card) Card, nutzte die Story als Gesprächsgrundlage (Conversation) und reicherte sie peu à peu mit Akzeptanzkriterien (Confirmation) an. Geprüft wurde eine User Story anhand der Scrum INVEST- Kriterien: Unabhängigkeit (Indenpent) der User Story von anderen, Verhandelbarkeit (Negotiable) des Story-Inhalts, fachlicher Wertbeitrag (Valuable), Schätzbarkeit (Estimable), handhabbare Größe in einem Entwicklungszyklus (Small) sowie Testbarkeit (Testable).

Zusätzlich zu den textuellen Epics, User Stories und Akzeptanzkriterien fertigten die mosaiic Berater Bildschirmmasken mit Microsoft Visio an. Die Masken halfen den Fach- und IT-Kollegen ein gleiches Verständnis von der graphischen Benutzerschnittstelle zu entwickeln.  Eine User Story verwies direkt auf die ihr zugehörigen Masken. Auch Begleitpapiere wie Wertetabellen, Schnittstellendetails und Attributlisten verknüpfte das Team direkt mit den User Stories. Alles war so an einer Stelle.

Ergebnisse: ein ausgereiftes Product Backlog, bereit für die technische Umsetzung

In weniger als drei Wochen stand die erste Fassung des Product Backlogs mit den beiden wichtigen Epics ‚ Montage-Steuerungsplan anlegen’ und ‚Montage-Steuerungsplan anzeigen’. Alle Stories waren spezifiziert, priorisiert sowie bereit für die Aufwandsschätzung und einer anschließenden technischen Umsetzung. Auf Empfehlung der mosaiic Consultants setzte sich Elke Berlitz noch vor Monatsende mit Jens Karstens in Kontakt.

Nun war die IT an der Reihe, auf Basis des Backlogs eine präzise Schätzung abzugeben und in die Implementierung zu gehen.

Frau Berlitz war zufrieden mit den Ergebnissen. Backlog, Bildschirmmasken sowie weiterführende Dokumente entsprachen ihren Erwartungen an Inhalt und Qualität. „Hoffentlich gehen die IT-Entwickler im Scrum Team ähnlich schnell und fokussiert zu Werk.“ sagte sie zu sich selbst „Wie gut, dass ich als Product Owner für das Team weiter zur Verfügung stehe.“.

Sie wusste, dass ihre Arbeit und die Unterstützung von mosaiic noch lange nicht zu Ende waren. Die User Stories mussten teilweise präzisiert und weitere Epics definiert werden. Der Weg bis zum fertigen Montage-Steuerungsplansystem war noch lang. Doch war nun ein erster wichtiger Schritt getan. Elke Berlitz war bereit die nächste Etappe in Angriff zu nehmen – gemeinsam mit mosaiic.

mosaiic Case zum Download
Laden Sie die Fallstudie als praktischen PDF 2-Seiter herunter.

Sie planen die Prozesse und Systeme ihrer Montageplanung agil weiterzuentwickeln? Gerne unter-stützen wir Sie in Ihrer Rolle als Product Owner mit unserem praxiserprobten Know-How und fundierten Methodenwissen. Sprechen Sie uns an.

Ansprechpartner: Tobias Smuda

Text: Dr. Christopher Schulz