Vorträge der Modern RE 2018

1. Konferenztag2. Konferenztag3. Konferenztag

Teams auf speed: Mit dem Design Sprint zur geteilten Verantwortung der Produktanforderung und -lieferung

Zeiten ändern sich: Bisher dachten und arbeiteten Softwareentwicklerteams oft in ihrer Sphäre. Während das Anforderungsmanagement durch den PO lange vor der Umsetzung geschieht, finden User Tests erst spät nach der Umsetzung statt. Die Produktverantwortung des Teams ist somit lediglich auf den Schritt der Softwareentwicklung begrenzt. Das führte in der Vergangenheit oft dazu, dass Entwickler Anforderungen nicht vollständig verstanden oder für die Ergebnisse ihrer Arbeit nicht gerade stehen konnten. Die klassische Aufteilung von Ausdenken, Umsetzen und Auwerten hat bei idealo einfach nicht mehr funktioniert.

Heute versuchen wir, ein ganzheitliches Anforderungs- und Produktverständnis zu schaffen. Hierfür braucht es einen Rahmen, der die vollständige Wertschöpfungskette der Produktentwicklung verdichtet und rollenübergreifend ermöglicht. Mit dem „Design Sprint“ wird eine Arbeitsumgebung geschaffen, in der beginnend von der Markt- und Problemanalyse, Produktideen vom Papier in die greifbare Realität überführt werden. Nahm dieser Prozess zuvor noch 8-12 Wochen in Anspruch, so gelangen wir mit dem „Design Sprint“ bereits in fünf Tagen zu greifbaren Ergebnissen. In diesem kurzen Zeitraum erschaffen wir mit dem Endnutzer testbare Produktprototypen und fördern ein rollenübergreifendes „Wir“, das Identität zum Produkt und Verantwortung für den Prozess erzeugt.

In diesem Vortrag werden Erfahrungen und praxisnahe Handlungsempfehlungen aus Sicht des Facilitators geteilt, die jeden Zuhörer ermutigen sollen, den Sprung in das kalte Wasser anhand eigener Herausforderungen zu wagen. Der Vortrag zeigt, wie ein Team autonom, zielgerichtet und strukturiert Ergebnisse liefert, die dem Endkunden und jedem einzelnen Teammitglied Nutzen schaffen.

Was lernen die Zuhörer in dem Vortrag?

  • Jeder kann den Design Sprint organisieren und moderieren
  • Jeder kann Produktprototypen bauen
  • Jeder kann malen (Sketches, Ideen) :)
  • Softwareentwickler sind auch Product Owner, spätestens nach dem Design Sprint
  • Skills sind nicht rollenbasiert "verteilt", sondern entlang des Prozesses
  • Der Sprung in das kalte "Produktwasser" ist garnicht so kalt, sondern spannend und lehrreich
Emre Sönmez
Emre Sönmez

Emre Sönmez (32, Berlin) ist seit 2014 Agile Coach bei der idealo Internet GmbH und arbeitet in einem Produktentwicklungsbereich mit knapp 40 Kollegen bzw...

45 Minuten Vortrag

Fortgeschritten
Zeit

11:10-11:55
08. Oktober


Zielgruppe

Agile Coaches, POs, Teamleads, Developers, Head Ofs, UX/Grafik,...


Themengebiet

Erfahrungsberichte


Raum

tba


ID

Di1.1

Visual RE - wie durch den systematischen Einsatz visueller Methoden Feedbackschleifen beschleunigt werden

"Das steht da aber anders!"
"Das hatte ich so aber nicht gemeint!"

Immer schwierig: Das gegenseitige Verstehen zwischen Fachbereich und Umsetzungsteams. Egal, wie präzise Anforderungen geschrieben werden, das Risiko für Missverständnisse bleibt. Erst durch schnelle Feedbackzyklen wird gegenseitiges Verständnis möglich.
Was tun, so lange noch keine anfassbaren Ergebnisse existieren, zu denen man Feedback geben kann?

Ok, User Stories und direkt, zeitnah miteinander reden? Sehr gut!
Kombiniert mit Bildern & visuellen Methoden? Noch besser!
Diesen Ansatz nennen wir Visual User Stories. Wir stellen Ihnen vor, wie wir damit Kundenbedarfe visuell kommunizieren und bereits im Gespräch schnelles Feedback ermöglichen.

Ein guter Anfang. Lasst uns das noch weiter entwickeln.
Wir zeigen anhand von praktischen Beispielen, wie wir etablierte visuellen Methoden wie z.B. Impact Mapping, Story Maps, Wireframes und eben auch Visual User Stories in einen systematischen Zusammenhang bringen, und nicht nur standalone oder als Themensammlung behandeln.

Ergebnis ist, wie wir es nennen, "Visual RE", ein durchgängiges Rahmenwerk, durch das Informationen konsequent bildhaft und sichtbar festgehalten und kommuniziert werden können.

Was lernen die Zuhörer in dem Vortrag?

In diesem Vortrag erleben die Teilnehmer wie sie Ihren RE-Werkzeugkasten sortieren & erweitern können.
Sortieren: Was ist Visual RE - Wie kann ich etablierte visuelle Methoden in einen Gesamtzusammenhang sehen und wie spielen diese zusammen?
Erweitern: Was sind Visual User Stories - Wie kann ich Kundenbedürfnisse mit visuellen Informationen anreichern, um schnelles Feedback bereits im Gespräch zu ermöglichen?

Olaf Bublitz
Olaf Bublitz

Ich habe in verschiedenen Bereichen der Softwareindustrie als Abteilungsleiter, Softwareentwickler, Projektmanager und Produktmanager Erfahrungen...


Thomas Starz
Thomas Starz

In meiner langen Karriere konnte ich Erfahrung sammeln als technischer Autor, Teamleiter, Projektleiter, Agile Instruktor und Coach. Früh war mir...

45 Minuten Vortrag

Experte
Zeit

11:10-11:55
08. Oktober


Zielgruppe

Klassische und Agile Requirements Engineers, Product Owner, Produkt Manager, Projektleiter, Entwickler, Fachbereichsmitarbeiter...


Themengebiet

Techniken


Raum

tba


ID

Di2.1

Was darf man eigentlich SAFe noch sagen? - Zitat und Aphorismen von Leuten die SAFe leben aus Sicht eines RElers.

Agilität richtig zu skalieren ist ein geistige Kraftanstrengung, dem wir uns nun seit fast 2 Jahrzehnten stellen. Dieser Diskurs hat die verschiedensten Konzepte und ein vielfaches an Variationen dieser sogenannten Scaled Agile Frameworks hervorgebracht. Und genau so Variantenreich ist die Bewertung dieser agilen Rahmenwerke. Eines der am bekanntesten Frameworks für skaliertes agiles Arbeiten ist SAFe, dem Ken Schwaber persönlich das recht sich agil zu nennen abgesprochen hat. Doch wie lang ist etwas noch agil? Welche Rolle spielt RE für eine agile Projektstruktur? Dieser Vortrag widmet sich einem bunten Blumenstrauß an verschiedensten Meinungen und Aussagen über den Fluss von Anforderungen innerhalb eines großangelegten SAFe Value Streams mit aktuellen vier Release Trains, an über vier Standorten in Deutschland und in Polen. Diese Sammlung und Analyse von Statements von verschiedensten Rollen, die mir als RE in diesem Projekt begegnet sind, zeigt wie Groß der Einfluss von RE auf die Wahrnehmung ist, ob überhaupt agil gearbeitet wird.

Was lernen die Zuhörer in dem Vortrag?

Welchen Einfluss hat der Umgang mit Anforderungen auf die Wahrnehmung den Grad an Agilität der Arbeit in einem skalierten Vorgehen?

Jan Dovica
Jan Dovica

Die Suche nach einer Herausforderung hat mich nach dem Studium zu SOPHIST geführt. Als Berater kann ich meine Talente im analytischen Denken und der...

45 Minuten Vortrag

Fortgeschritten
Zeit

12:05-12:50
08. Oktober


Zielgruppe

PO und PM in agilen Teams. Scrum Master und alle die in einem skaliertem agilen Umfeld arbeiten.


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Di1.2

The Perfect Match? Anforderungsmanagement und Agilität im Beziehungs-Check

Agiles Vorgehen ist in aller Munde. Dabei ist die Gefahr allgegenwärtig, dass bei der Einführung von Agilität bewährte Methoden und Konzepte „aus der alten Welt“ gänzlich vernachlässigt werden. Dies betrifft unter anderem das Anforderungsmanagement. In meinem Vortrag werde ich aufzeigen, dass Anforderungsmanagement und Agilität Hand in Hand gehen - dass sich beide Kompetenzen sogar gegenseitig stärken und nur gemeinsam zum Projekterfolg führen. Dabei werde ich fünf Aspekte einer guten Beziehung beleuchten und meine These mit gängigen Modellen untermauern.

Was lernen die Zuhörer in dem Vortrag?

Die Zuhörer erfahren in dem Vortrag, wie die beiden Kompetenzen Anforderungsmanagement und Agilität sich gegenseitig stärken und nur gemeinsam zum Projekterfolg führen.

Sabine Kunigowski
Sabine Kunigowski

Sabine Kunigowski ist als Konzepterin und Anforderungsmanagerin seit mehr als 13 Jahren für verschiedene Agenturen im IT-Bereich tätig und nunmehr seit...

45 Minuten Vortrag

Fortgeschritten
Zeit

12:05-12:50
08. Oktober


Zielgruppe

Anforderungsmanager


Themengebiet

Techniken


Raum

tba


ID

Di2.2

Agile Scheidung

Nach 11 Jahren Beziehung - mit Kind - ist eine Scheidung keine leichte Entscheidung. Meine Ex-Frau und ich haben uns über ein Jahr intensiv mit unserer Beziehung agil auseinandergesetzt und dabei viel gelernt: über uns, über uns selbst und darüber, wie großartig ein agiles Mindset unterstützt zu einem Punkt zu kommen, der wirklich für alle Beteiligten gut ist.

Warum agil?

Unsere Trennung war unerwartet. Wir haben uns als in einem System wiedergefunden, das hochgradig chaotisch, unüberschaubar und stetig ändernd war. Es hat sich praktisch alle 2 Wochen massiv die Anforderungen geändert und irgendwie mussten wir damit umgehen, um zu unserem Ziel zu kommen, dass wir einen Weg finden, der für uns beide ok ist.

Warum einen Talk darüber halten?

Ich hab mit unglaublich vielen Menschen über ihre Trennungen geredet. Was sie von Beziehungen halten (sehr diffuses Thema: die einzige Gemeinsamkeit ist, dass die meisten recht überzeugt davon sind, wie Beziehungen auszusehen haben). Und die Art, wie wir unsere Trennung durchgezogen haben ist ungewöhnlich und schön.

Ich würde gern die Leute mit auf eine Reise durch die Trennung nehmen. Sie miterleben lassen, die Lernerfahrungen die für agile Softwareentwicklung wichtig sind herausheben und nebenbei noch ein philosophisches Grundkonstrukt der Agilität darstellen - in 45 Minuten - mit Puffer für Fragen.

Was lernen die Zuhörer in dem Vortrag?

Unbekanntere Aspekte des agilen Arbeitens, die in der Softwareentwicklung nicht so präsent sind, dennoch einen hohen Einfluss haben. Außerdem hautnahes Erleben, was echte Agilität bringt und warum.

Gustav Messany-Oberwandling
Gustav Messany-Oberwandling

Gustav Messany-Oberwandling ist Scrum Master, Requirements Engineer und Coach bei Catalysts. Liefert agile Software seit 7 Jahren und lebt dabei...

45 Minuten Vortrag

Fortgeschritten
Zeit

14:00-14:45
08. Oktober


Zielgruppe

Product Owner, Scrum Master, aber auch für das Dev-Team interessant =)


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Di1.3

Wie wir unsere Produktentwicklung neu denken sollten

Aus der klassischen Produktentwicklung kommend werden auch in den ersten agilen Projekten meist Konzepte vollständig erarbeitet, bevor diese umgesetzt werden. Es entfällt zunächst häufig nur das „über den Zaun werfen“ des Konzeptes, das Produkt wird aber weiterhin meist in große Scheiben zerschnitten, die nacheinander entwickelt und am Ende wieder zusammengesetzt werden. Ist das Projekt endlich abgeschlossen, sind trotzdem alle unzufrieden weil das Projekt zu lange gedauert hat, zu teuer war oder der Kunde doch etwas anderes haben wollte.

Wollen wir die Produktentwicklung wirklich agil machen sollten wir uns an horizontalen Wertströmen entlang bewegen. So werden wir in die Lage versetzt, zu jeder Zeit ein funktionsfähiges Produkt in der Hand zu halten und immer in einer Entscheidungsposition zu sein, ob alle noch das gemeinsame Verständnis / Vision für das Produkt haben, ob etwas ergänzt oder geändert werden sollte oder das Produkt sogar möglicherweise schon eine erste Marktreife hat. Mit etwas Umdenken und gar nicht so neuen Methoden werden alle Beteiligten in die Lage versetzt, immer zu wissen, wo man aktuell steht und wie genau es jetzt weitergehen sollte.

Was lernen die Zuhörer in dem Vortrag?

Die Teilnehmer lernen, wie man sich mit Hilfe von User Story Mapping und Impact Mapping langsam vom MVP (Minimum Viable Product) bis zum Wohlfühlrelease bewegen kann und jederzeit die Möglichkeit hat sein Produkt zu benutzen, zu releasen und entsprechend zu verproben. Sie werden in die Lage versetzt, die wirklich essentiellen Funktionalitäten zu priorisieren und 80% des Kundenmehrwertes mit 20% der eingesetzten Ressourcen zu entwickeln und entsprechend schneller echten Mehrwert für Ihre Kunden zu generieren. Sie lernen, wie sie es schaffen, einen Elefanten nicht mehr in Scheiben zu zerschneiden, die am Ende zusammengesetzt werden müssen, sondern wie man einen Babyelefanten langsam aber sicher großziehen und erwachsen werden lässt.

Thorsten Schiffer
Thorsten Schiffer

Thorsten Schiffer ist freiberuflicher Agile Coach und zertifizierter LEGO Serious Play Facilitator. Mit 20 Jahren Erfahrung in Software Entwicklungsprojekten in...


Sonja Roßbach
Sonja Roßbach

Sonja Roßbach...

45 Minuten Vortrag

Fortgeschritten
Zeit

14:00-14:45
08. Oktober


Zielgruppe

Product Owner, Requirements Engineers, Business Analysten, Geschäftsführer


Themengebiet

Techniken


Raum

tba


ID

Di2.3

Process driven requirements engineering in an agile approach

Im agilen Kontext geraten oft klassischere Methoden, wie z. B. prozessgetriebene Anforderungserhebung, in den Hintergrund. Trotz alledem bestehen häufig große Probleme, den Zusammenhang zwischen einzelnen Epics und User Stories herzustellen und diese in eine sinnvolle Reihenfolge zur Schaffung einzelner Inkremente zu bringen. Ein Versuch, dies in der agilen Methodik zu heilen, bildet das User Story Mapping, welches aber in diesem Zusammenhang oftmals nur einen Reverse Engineering Ansatz darstellt. Diese Lücke lässt sich jedoch leicht schließen, wenn man klassische Methoden in den Erhebungsprozess der Anforderungen einfließen lässt. Hier bildet das process driven requirements engineering einen wundervollen Ansatz, diese oft schwierigen Abhängigkeiten und Zusammenhänge von Beginn an mit zu betrachten und zu erheben. Ebenfalls kann es so in der Kommunikation zum Thema deutlich leichter fallen, die Zusammenhänge und Abhängigkeiten darzustellen, was zu mehr Transparenz beiträgt und die Refactoring Aufwände verringert. Gerne möchten wir hier anhand eines Erfahrungsberichtes in die Methodik einführen und unsere gewonnenen Erkenntnisse mit ihnen teilen.

Was lernen die Zuhörer in dem Vortrag?

  • Verknüpfung klassischer und agiler Methoden
  • Strukturiertes Vorgehen zur Anforderungserhebung
  • Zusammenspiel Ereignisgesteuerter-Prozessketten und User-Story-Mapping
  • Zusammenspiel Ereignisgesteuerter-Prozessketten und UX-Design
  • Wertvolle Learnings, wo process driven requirements management in der Kommunikation mit dem Team helfen kann
Marco Ley
Marco Ley

Marco Ley machte 2006 seinen Studiumsabschluss zum M.A. Information Science und arbeitete danach in der Managementberatung. Von 2012-2018 war er...


Tilman Müller-Gerbes
Tilman Müller-Gerbes

Tilman Müller-Gerbes...

45 Minuten Vortrag

Einsteiger
Zeit

14:55-15:40
08. Oktober


Zielgruppe

Product Owner, Anforderungsmanager, Scrum Master, Dev. Teams, Stakeholder, Projektleiter, etc.


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Di1.4

Wir sind jetzt agil – wir dokumentieren keine Anforderungen mehr!

„Wir sind jetzt agil – wir dokumentieren nicht mehr!“ Oder: „Die User Stories reichen uns als Dokumentation.“ Solche oder ähnliche Aussagen habe ich schon öfter von Softwareentwicklungsteams gehört.

Für die Entwicklung von überschaubaren Systemen mit kürzerer Lebensdauer kann das gut funktionieren. Genauso, wenn das Team, das das System gebaut hat, auch nach der Inbetriebnahme des Systems verfügbar ist, um eventuell aufkommende Fragen von Nutzern oder Systembetreuern zu beantworten.

Schwieriger wird es bei der Entwicklung von komplexen Systemen mit langer Lebensdauer, wie zum Beispiel in der Raumfahrt. Softwaresysteme sind hier gut und gerne über zehn Jahre im Betrieb und müssen über den gesamten Zeitraum gewartet und betreut werden. Viele der an der ursprünglichen Realisierung beteiligten Person haben das Unternehmen dann vielleicht schon wieder verlassen oder arbeiten in anderen Projekten, so dass ihre Unterstützung nicht kurzfristig eingeholt werden kann. Wenn die Dokumentation dann nur im Sourcecode vorliegt, müssen sich projektfremde Personen erst mühsam in den Code einarbeiten. Bei Fehlern im Live-System kann genau das wertvolle Zeit kosten.

Gar nicht zu dokumentieren ist also keine gute Idee. Also wäre es doch theoretisch im eigenen Interesse des Entwicklungsteams, Dokumentation außerhalb des Quellcodes zu schreiben, oder? Leider nur theoretisch. Dokumentationserstellung zählt in der Softwareentwicklung (mit einigen wenigen Ausnahmen!) eher zu den unliebsamen Tätigkeiten. Ein „notwendiges Übel“ quasi, um das man sich nur kümmert, wenn kein Weg daran vorbeiführt. Falls niemand nach einer Dokumentation fragt, kann das eine Weile gut gehen. Zumindest solange, bis dann besagte Fehler im Live-System auftauchen und alle angestrengt überlegen, welcher Service denn noch mal für was zuständig war…

Falls aber am Ende doch eine Dokumentation mit ausgeliefert werden muss, weil der Kunden oder der Gesetzgeber dies verlangen, kommen „dokumentationsfaule“ Teams früher oder später ins Schwitzen. Manche machen dann „Dokumentationssprints“, in denen alle Teammitglieder zum Projektende – oft über mehrere Wochen – nur noch dokumentieren. Aus eigener Erfahrung weiß ich, dass dies meist ein äußerst mühsames Unterfangen ist. Denn bei sehr komplexen Systemprozessen reichen schon ein paar Wochen oder sogar Tage, um beispielsweise Details beispielsweise über Prozessabläufe zu vergessen. Diese dann aus dem Quellcode zu rekonstruieren, ist oft langwierig und fehleranfällig.

Wahrscheinlich ist es mit der Dokumentation also ein bisschen, wie mit dem guten Vorsatz, mehr Sport zu treiben: Wir wissen alle, dass Sport gesund ist. Trotzdem hindert uns oft unser innerer Schweinehund daran, uns mehr zu bewegen. Wenn dann schließlich das schlechte Gewissen groß genug ist, wird versucht, dies durch lange und intensive Trainingseinheiten zu kompensieren. Prompt stellt sich ein heftiger Muskelkater ein, der dann auf dem Sofa auskuriert werden muss. Stattdessen wäre es vermutlich besser, regelmäßiger und moderater zu trainieren…

Der Vortrag will aufzeigen, wie es ein agiles Team schafft, den inneren „Dokumentations-Schweinehund“ zu überlisten und Dokumentation zur guten Gewohnheit zu machen.

Verschiedene Techniken werden hierzu vorgestellt, wie z. B. die Integration der Dokumentationserstellung in den Entwicklungsprozess über eine Definition of Done oder Unteraufgaben, die Nutzung von angepassten Standardtemplates zur Dokumentation und dem Ansatz "Docs as Code". Außerdem lernen die Zuhörer das Konzept der "Lean Documentation" kennen, bei dem Soll- und Ist-Zustand im selben Dokument beschrieben werden und auf eine eigene Anforderungsdokumentation verzichtet werden kann.

Was lernen die Zuhörer in dem Vortrag?

  • Verknüpfung klassischer und agiler Methoden
  • Strukturiertes Vorgehen zur Anforderungserhebung
  • Zusammenspiel Ereignisgesteuerter-Prozessketten und User-Story-Mapping
  • Zusammenspiel Ereignisgesteuerter-Prozessketten und UX-Design
  • Wertvolle Learnings, wo process driven requirements management in der Kommunikation mit dem Team helfen kann
Kathrin Herrmann
Kathrin Herrmann

Seit 2004 bin ich im Softwarebereich tätig und kenne sehr gut die Herausforderungen, die die Einführung einer neuen Softwarelösung und die Weiterentwicklung...


Michael Herrmann
Michael Herrmann

Michael Herrmann...

45 Minuten Vortrag

Fortgeschritten
Zeit

14:55-15:40
08. Oktober


Zielgruppe

Product Owner, Entwickler, Scrum Master


Themengebiet

Techniken


Raum

tba


ID

Di2.4

Erfahrungsbericht: Experiment Mindset-Change in einem Software-Entwicklungs-Projekt

In agilen Softwareprojekten finden wir häufig heterogene Mindsets bei den Teammitgliedern vor. Dies beruht zum einen auf unterschiedliche Erfahrungen aus früheren Projekten, aber auch auf das kulturelle Umfeld (während der Kindheit) sowie die Erziehung. Auch das Unternehmensumfeld spielt eine Rolle, Verhaltensweisen von Kollegen und vor allem Führungskräften werden gerne übernommen.

Diese unterschiedlichen Mindsets führen häufig zu Missverständnissen und Spannungen im Projektalltag. Dies wiederum beeinflusst die Leistungsfähigkeit der Teammitglieder und damit die Ergebnisse der Projekte.

Im Zuge dieser Erkenntnis starten wir ein Experiment, das die heterogenen Mindsets positiv beeinflussen soll, um letzten Endes ein homogenes, agiles Mindset zu erreichen. Von diesem agilen Team-Mindset erhoffen wir uns eine bessere Zusammenarbeit und damit bessere Ergebnisse. In diesem Experiment werden wir verschiedene Mindset-Veränderungs-Tools einsetzen und regelmäßig die Veränderungen im Team messen. Die Ergebnisse möchten wir in diesem Slot gerne mit Interessierten teilen und so den unternehmensübergreifenden Austausch fördern.

Was lernen die Zuhörer in dem Vortrag?

Was passieren kann, wenn man bewusst Tools für den Mindset-Change einsetzt.

Jessica Emma Clark
Jessica Emma Clark

Die studierte Informatikerin ist als Senior Consultant bei der T-Systems on site services GmbH angestellt. Nach jahrelanger Erfahrung als Requirements...


Andrea Klann
Andrea Klann

Andrea Klann...

45 Minuten Vortrag

Experte
Zeit

16:10-16:55
08. Oktober


Zielgruppe

alle Menschen, die mit Menschen arbeiten (möchten)


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Di1.5

Angriff ist die beste Verteidigung

Es ist eine zunehmend wichtigere Aufgabe von Behörden die Digitalisierung zu überwachen und mit Maßnahmen zu regulieren, die die Sicherheit von IT-Produkten und deren Nutzer gewährleisten. Prozesse, Technologien und Werkzeuge stehen hier im Fokus und werden im Rahmen von Zulassungen geprüft.

Insbesondere bei der Entwicklung neuer und innovativer Produkte sind Regularien und Security Anforderungen “lästig“, deren Umsetzung häufig teuer, aber dennoch unumgänglich! Denn die neuesten Schlagzeilen von Cyber Angriffen, in vernetzten Autos namhafter Hersteller oder Datenklau in sozialen Netzwerken von Klinik- und Pflegeeinrichtungen sind reale Straftaten. An diesen gegenwärtigen Vorkommnissen orientieren sich Regulierungsbehörden und schaffen mit Maßnahmen, die in Gesetzen verabschiedet werden, einen Schutz für Einrichtungen und Einzelpersonen.

Regulatorische Anforderungen sind meist abstrakt, bringen keinen direkten Business Nutzen und können nur teilweise mit Hilfe der bewährten Requirements Engineering Techniken konkretisiert werden. In der Konsequenz ist man versucht, sich im Requirements Engineering auf einige naheliegende Sicherheitsaspekte wie User-Rollen und -Berechtigungen zu beschränken und überlässt den “Rest“ der Architektur und der Entwicklung. Vom Regulator definierte Anforderungen laufen meist als separater Planungsvorgang parallel zu den ersten Phasen des Entwicklungsprojektes und werden häufig zu spät angegangen.

Im Vortrag möchten wir Ihnen zeigen, wie Sie Security Aspekte frühzeitig und über den kompletten Entwicklungsprozess integrieren ohne dabei auf Agilität und Innovation in der Produktentwicklung zu verzichten. Im Weiteren konzentrieren wir uns auf die Erhebung von Security Anforderungen und verwenden dabei Techniken, die über die gängigen Requirements Engineering Skills hinausgehen. Auf Basis eines groben Architekturentwurfs erheben und analysieren wir mögliche Bedrohungsszenarien für die Anwendung und leiten daraus konkrete Security Anforderungen ab.

Mit Hilfe strukturierter Checklisten und geeigneter Modellierungsansätze schaffen wir schon in der frühen Entwurfsphase einen möglichst vollständigen Überblick über die Sicherheitsrisiken. Diese können so frühzeitig priorisiert und von Beginn an “bewusst“ eingeplant werden. Dies spart Kosten für spätere Architekturänderungen und zusätzlich notwendige Sicherheitsmaßnahmen in der Produktion. Wer dem Cyber Angriff einen Schritt voraus ist, kann flexibel und kostengünstig der Zukunft begegnen.

Was lernen die Zuhörer in dem Vortrag?

Bewusstsein, dass IT Security Know-How auch für den Requirements Engineer relevant ist; Integration von IT Security Aktivitäten in SCRUM; Einführung in die Bedrohungsmodellierung am praktischen Beispiel

Sabine Wildgruber
Sabine Wildgruber

Sabine Wildgruber: Requirements Engineering auf Basis agiler und klassischer Vorgehensweisen sowie Mischformen; Begleitung des Projektes von Ideation bis...


Dagmar Moser
Dagmar Moser

Dagmar Moser: Selbständige IT Beraterin mit Schwerpunkt IT Architektur, IT Security und Requirements Engineering in klassischen IT-Anwendungsentwicklungs-...

45 Minuten Vortrag

Experte
Zeit

16:10-16:55
08. Oktober


Zielgruppe

Requirements Engineering, Security Specialist, Architekt, Product Owner


Themengebiet

Techniken


Raum

tba


ID

Di2.5

Blackbox RE – Reverse Engineering – Produkt(weiter)entwicklung einer Whitelabellösung

Whitelabel Lösungen für ein Unternehmen anzupassen heißt nicht nur Farben zu adaptieren oder ein neues Logo einzufügen.

Dieser Vortrag wird etwas darüber erzählen, welche Aufgaben, an und um eine App herum anfallen, die man scheinbar als Unternehmen nur "übernimmt". Wie viel "Neues" kann der Dienstleister umsetzen und wie können Anforderungen an eine Anwendung definiert werden, wenn Programmierung und Struktur der Applikation nicht transparent sind.

Neben unterschiedlichen Interessen von Anbieter und eigener Organisation wurden Herausforderungen in Infrastruktur und Prozessen sichtbar, sollte doch die "Fremd"App am Ende Teil des internen Ökosystems werden.

Was lernen die Zuhörer in dem Vortrag?

Ein Beispiel aus der Praxis – was funktioniert hat und was wir so sicher nicht noch einmal machen würden.

Diana Frank
Diana Frank

Diana Frank beschäftigt sich seit über 20 Jahren mit nutzerzentrierten Prozessen, Kommunikation, Interaktionskonzepten und Orientierungssystemen...

45 Minuten Vortrag

Fortgeschritten
Zeit

17:05-17:50
08. Oktober


Zielgruppe

Product Owner, Produktentwicklung, Anforderungsklärung, User Experience, Zusammenarbeit mit externen Dienstleistern


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Di1.6

„Als Biometrics-API möchte ich, dass neue Fingerabdruck-Daten nach maximal 10ms entpackt vorliegen“ - technische User Stories und nichtfunktionale Requirements in agilen Backlogs

Nachdem wir auf der ModernRE 2018 einen Vorschlag für die Zusammenführung von agilem und klassischem RE vorgestellt haben, reichen wir hier die beiden Themen nach, die wir seinerzeit noch nicht abgeschlossen hatten.

Das erste: Wohin mit nichtfunktionalen Requirements in einem Product Backlog? Konsultiert man WWW und Literatur, gibt es dazu fast keinen Vorschlag, den man nicht findet (z.B. man solle sie als Akzeptanzkriterien formulieren – meist keine gute Idee! – oder sie in Constraints, technische Stories oder DoD-Einträge umwandeln). Wir haben diese verschiedenen Vorschläge bewertet und daraus ganz konkret einen Entscheidungsbaum entwickelt, den wir im Vortrag vorstellen.

Und das zweite: „technische User Stories“, die gerne mit „Als Entwickler/Als Architekt/Als Komponente(!)…“ oder ähnlichem beginnen. Wir erleben in Projekten oft, dass Product Owner solche Stories nicht priorisieren, nicht abnehmen und im Sprint keine Rückfragen dazu beantworten können. Auch hierfür haben wir eine konkrete Lösung als Hilfestellung anzubieten.

Und wie immer schlagen wir bei all dem die Brücke zum Test und zeigen, wie die Testbarkeit der fraglichen Anforderungen von unserem Vorgehen profitiert.

Was lernen die Zuhörer in dem Vortrag?

Nach einer kurzen Zusammenfassung, wie klassisches RE sinnvoll in ein agiles Vorgehen integriert werden können, zeigen wir konkret, wie nichtfunktionale Requirements sowie "technische Stories" in agilen Backlogs behandelt und getestet werden können.

Christian Brandes
Christian Brandes

Dr. Christian Brandes arbeitet als Principal Consultant und Team Lead für die QualityMinds GmbH. Der promovierte Mathematiker ist seit vielen Jahren...


Ralph Reithmeier
Ralph Reithmeier

Ralph Reithmeier...

45 Minuten Vortrag

Experte
Zeit

17:05-17:50
08. Oktober


Zielgruppe

Mitglieder in agilen Teams, Product Owner, Requirements Engineers, Tester, Entwickler, Architekten, Produktmanager


Themengebiet

Techniken


Raum

tba


ID

Di2.6

Traces als Dreh- und Angelpunkt für agiles Anforderungsmanagement: Eine Fallstudie

In diesem Vortrag wird eine Fallstudie eines Herstellers von Prothesen aus den nordischen Ländern vorgestellt. Seit vielen Jahren verfolge dieser einen zuverlässigen, dokumentenbasierten Ansatz in der Produktentwicklung. Dies führte zwar zu zuverlässigen Produkten, die Entwicklung war jedoch langsam, und das Änderungsmanagement war sehr zeitaufwändig. Darüber hinaus stellten sie fest, dass einige Produkte 60% bis 70% der gleichen Kernanforderungen erfüllen. Die dokumentenbasierte Wiederverwendung war mühsam und ineffizient. Diese Dynamik, verbunden mit dem zunehmenden Marktdruck, führte zum Übergang zu einer modernen Plattform für das Anforderungsmanagement.

Der Wegbereiter, der zu einer signifikanten, meßbaren Verbesserung führte, war die Nachverfolgbarkeit über Traces. So sah die erste Gruppe der Pilotanwender den Wert der Lösung, noch bevor sie überhaupt mit dem System zu arbeiten begannen: Durch den Import bestehender Anforderungsdokumente in einzelne Elemente wurden Rückverfolgbarkeitslücken sichtbar, die zuvor maskiert wurden. Während der alte Ansatz sie auch gefunden hätte, hätte es Stunden oder Tage gedauert, anstatt Minuten. Auch im Betrieb führte die Nachverfolgbarkeit zu einem drastisch vereinfachten - und schnelleren – Umgang mit Änderungen, da die betroffene Elemente automatisch identifiziert und auch nur diese erneut validiert werden mussten. Die Traceability machte weiterhin kontextbasierte Zusammenarbeit und Wiederverwendung möglich.

Die Benutzerfreundlichkeit führte zu einer schnellen Anpassung durch die Beteiligten. Da das System konkrete Kennzahlen lieferte, waren die Entscheidungsträger interessiert und bereit, auch auf das System zuzugreifen.

Was lernen die Zuhörer in dem Vortrag?

  • Warum agiles Anforderungsmanagement mit einem dokumentenbasierten Ansatz kaum möglich ist
  • Wie von dokumentenbasiertem RE aufs Datenmodell-basiertes RE im laufenden Betrieb gewechselt werden kann
  • Wie Nachverfolgbarkeit für agiles Anforderungsmanagement eingesetzt werden kann
  • Wie der Wert von agilem Anforderungsmanagement quantifiziert werden kann
Michael Jastram
Michael Jastram

Dr. Michael Jastram ist Systems Engineer mit Schwerpunkt auf die Anforderungsmodellierung. Er ist Gründer und Projekt Lead des Eclipse Requirements...

45 Minuten Vortrag

Einsteiger
Zeit

10:40-11:25
09. Oktober


Zielgruppe

Projektverantwortliche, IT-Verantwortliche


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Mi1.1

Design Critique - Kritik als Analysewerkzeug zur kontinuierlichen Verbesserung von Designs

Du sitzt im Meeting, zeigst was Du zuletzt entwickelt hast, und bekommst gleich mal auf die Fresse: das sieht ja Scheisse aus! Das musst du so machen! Du rechtfertigst dich und gibst Konter, denkst dir “ihr habt doch alle keine Ahnung”. So geht das eine Weil hin und her, bis die geplanten 60 Minuten rum sind und das Meeting mit zwanzig minütiger Verspätung beendet wird. Bis zum nächsten Mal.

Wie es anders geht, zeige ich in diesem Vortrag. Design Critique ist eine Methode für Teams mit dem Ziel Designs nicht zu beurteilen oder gar verurteilen, sondern mit Hilfe von kritischem Denken als Analysewerkzeug kontinuierlich zu verbessern.

Erfahre den theoretischen Hintergrund zu Feedback und Kritik. Erlebe anhand eines Praxisbeispiels wie sich Design Critique im Team anfühlt. Nimm Dir Templates mit in Dein Projekt um Design Critique sofort in deinem Team auszuprobieren.

Was lernen die Zuhörer in dem Vortrag?

Verschiedene Formen von Feedback und Kritik.
Theoretischer Hintergrund zu Design Critique.
Strukturiertes Vorgehen zu Design Critique in Teams.
Arbeitsblätter für das eigene Projekt.
Erleben von Design Critique anhand eines Praxisbeispiels.

Andreas Lehner
Andreas Lehner

Trainer und Berater bei der OPITZ CONSULTING Deutschland GmbH. Er verfügt über 12 Jahre Erfahrung in der IT-Beratung von Großunternehmen. Seine Schwerpunkte...

45 Minuten Vortrag

Experte
Zeit

10:40-11:25
09. Oktober


Zielgruppe

Entwickler, Designer, Anforderungsmanager


Themengebiet

User Experience


Raum

tba


ID

Mi2.1

Der „Haben-Wollen“-Effekt

Anforderungserhebung mal anders! Der digitale Arbeitsplatz greift um sich, so auch bei der GMH Gruppe in Georgsmarienhütte. Und was bringt das mit sich, oh Wunder? Richtig, ganz viele betroffene Mitarbeiter mit noch viel mehr Anforderungen. Diese Anforderungen kennt nur keiner. Und das ist blöd. „Was hätten Sie denn gerne?“ bringt leider auch nichts, die Mitarbeiter wissen ja gar nicht, was es alles gibt bei dieser „Arbeitsplatzdigitalisierung“.

„Wollen, nicht wollen sollen“ - das hat sich das sechsköpfige Programmteam auf die Fahne geschrieben. Wir erklären in dieser interaktiven Session das Vorgehen, wie wir aus den Mitarbeitern herausbekommen haben, was sie tatsächlich bei der Arbeit nervt. Aber auch - für uns noch viel wichtiger - was sich doch Bitteschön auf keinen Fall ändern soll!

Vor allem aber: wir zeigen, wie wir es geschafft haben, dass wir die Mitarbeitern nicht um ihre Beteiligung bitten mussten, sondern sie das Programmteam darum gebeten haben. Der Haben-Wollen-Effekt.

Und wir werden nicht nur darüber reden, wir werden es in der Session vor allem in einer Kurzversion machen!

Was lernen die Zuhörer in dem Vortrag?

Wie bekomme ich heraus, was die Mitarbeiter WIRKLICH brauchen.

Thiemo Laubach
Thiemo Laubach

Thiemo Laubach beschäftigt sich bereits im 15. Jahr ausschließlich mit dem Thema "Kommunikation und Zusammenarbeit in digitalen Kontexten". Mit einem...


Thorsten Bertmer
Thorsten Bertmer

Thorsten Bertmer...

45 Minuten Vortrag

Einsteiger
Zeit

10:40-11:25
09. Oktober


Zielgruppe

Alle, die bereit sind mal umzudenken


Themengebiet

Anforderungserhebung


Raum

tba


ID

Mi3.1

INVESTiere in User Stories: Wenn Tester User Stories schreiben - ein Erfahrungsbericht

Verbreitete Qualitätskriterien wie INVEST für User-Stories legen nahe, dass eine gut formulierte User-Story folgende Merkmale aufweist:

Independent: Sie ist unabhängig von anderen User-Stories.
Negotiable: Sie ist verhandelbar, d.h. Kunden und Entwickler besprechen und präzisieren sie gemeinsam.
Valuable: Sie ist nützlich, d.h. sie zeigt der Mehrwert der Implementierung der User Story auf.
Estimable: Sie ist schätzbar, d.h. sie ermöglicht es, den Aufwand für die Implementierung zu schätzen.
Small: Sie hat einen angemessenen Umfang, um in einem Sprint erfolgreich umgesetzt werden zu können.
Testable: Sie ist testbar.

Diese Kriterien klingen plausibel. Versucht man diese konkret in einem Projekt umzusetzen, steht man vor diverse Problemen:

  • Eine umfangreiche Anforderung des Kunden kann häufig nicht in einer User Story abgebildet werden. Wird diese Anforderung in einzelne User Stories zerlegt, sind diese häufig stark abhängig voneinander.
  • Kunden haben bisweilen konkrete Vorstellungen von der Umsetzung einer Anforderung. Es ist in solchen Fällen schwierig, gemeinsam mit den Kunden und Entwicklern alternative Lösungen zu finden.
  • Hat der Kunden vage Vorstellungen von der Umsetzung einer Anforderung, ist es schwierig testbare Akzeptanzkriterien zu formulieren.
  • Kunden wollen bekannte Funktionen eines Altsystemen auch in einem neuen System umgesetzt bekommen, auch wenn der Nutzen nicht klar ist.

Insgesamt stellt sich die Frage, wie User-Stories entsprechend der INVEST-Kriterien praktisch formuliert werden können? Dieser Vortrag stellt Lösungen für die genannten Probleme anhand eines Erfahrungsberichtes aus einem größeren Projekt für die Entwicklung einer Portallösung eines technischen Prüfdienstleisters vor.

Was lernen die Zuhörer in dem Vortrag?

Die Zuhörer lernen pragmatische Ansätze, um eine User-Story so zu formulieren, dass sie folgende Merkmale aufweist:

Independent: Sie ist unabhängig von anderen User-Stories.
Negotiable: Sie ist verhandelbar, d.h. Kunden und Entwickler besprechen und präzisieren sie gemeinsam.
Valuable: Sie ist nützlich, d.h. sie zeigt der Mehrwert der Implementierung der User Story auf.
Estimable: Sie ist schätzbar, d.h. sie ermöglicht es, den Aufwand für die Implementierung zu schätzen.
Small: Sie hat einen angemessen Umfang, um in einem Sprint erfolgreich umgesetzt werden zu können.
Testable: Sie ist testbar.

Oral Avci
Oral Avci

Dr. Oral Avcı verantwortet bei der adesso AG ein Competence Center mit dem Schwerpunkt Testen. Er hat an der Universität zu Köln im Bereich...


Julian Loschelders
Julian Loschelders

Julian Loschelders...

45 Minuten Vortrag

Fortgeschritten
Zeit

11:35-12:20
09. Oktober


Zielgruppe

Scrummaster, Requirements Engineer, Tester


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Mi1.2

Agile Usability 911 – Best Practices für das ganze Team

Die Software sieht so aus, weil wir keinen UI-Experten hatten!
Nur ein Fachmann kann das Projekt jetzt noch retten! Oder doch nicht?

Eine gute Software ist vor allem Eins - das Ergebnis einer Teamarbeit. Die Teams aber stehen wiederholt vor gleichen Herausforderungen und Problemen, wenn es um komplexe Interfaces geht: Klassische Usability-Themen gekoppelt mit Organisations- und Ressourcenengpässen steigern die Aufwände und senken die Qualität des Projekts. Trotzdem braucht Ihr Projekt nicht unbedingt einen dedizierten Usability-Experten, um gut zu werden. Stanislaw Traktovenko, der UI-Experte der Saxonia Systems AG zeigt in diesem Vortrag, wie es auch ohne geht. Vier Jahre Enterprise-Usability in einer Session.

Wer ist wofür verantwortlich? Wie pflegt man Usability-Anforderungen? Welche klassische Usability-Probleme lassen sich leicht verhindern? Was kann man tun, wenn der Stakeholder schweigt und warum Tabellen immer eine schlechte Wahl sind? Antworten auf diese und andere Fragen gibt es hier dekonstruiert anhand von UX-Prinzipien und Erfahrungsberichten zum Mitnehmen. Klar und verständlich. Immer anwendbar.

Was lernen die Zuhörer in dem Vortrag?

Die Zuhörer lernen:

  • Arbeit mit Usability Themen ohne Usability Experten im Team
  • Warum kann man das Thema im agilen Projekt nicht ignorieren?
  • Verständnis für Usability als Anforderung
  • Erzeugen von Sichtbarkeit im agilen Projekt
  • Erhebung und Pflege der Usability Anforderungen
  • Umgang mit Usability-Fehlern im Team

Als Bonus: 6 Kurze Design Practices zu Standart-Elementen

Stanislaw Traktovenko
Stanislaw Traktovenko

Stanislaw Traktovenko ist Senior Consultant für Business Analyse und Usability Engineering bei der Saxonia Systems AG. Er beschäftigt sich seit 2011...

45 Minuten Vortrag

Fortgeschritten
Zeit

11:35-12:20
09. Oktober


Zielgruppe

Entwickler, Analysten, Scrum Master, POs


Themengebiet

User Experience


Raum

tba


ID

Mi2.2

Modern RE braucht Digital Design – Die neue Gestaltungsprofession für die Digitalisierung

Digitalisierung und digitale Transformation sind Stellvertreterbegriffe. Sie beschreiben den Wandel zu einer Gesellschaft und Wirtschaft, die maßgeblich auf Digitaltechnologie beruht. Der Unterschied zwischen dem „Vordigitalisierungszeitalter“ und dem Zeitalter der Digitalisierung besteht darin, dass sich Digitaltechnologie von einer realisierenden zu einer gestaltenden Technologie gewandelt hat.
Die gute Nachricht: RE als systematischer Ansatz für Spezifikation und das Management von Anforderungen ist und bleibt eine Kernkompetenz für erfolgreiche Entwicklung.
Die schlechte Nachricht: In innovativen Kontexten der Digitalisierung oder der digitalen Transformation fällt Stakeholdern das Formulieren klarer Anforderungen schwer. Die Methoden des RE kommen daher schnell an ihre Grenzen.
Es braucht daher eine neue Profession. Bitkom nennt sie Digital Design und hat dazu ein Manifest verfasst: www.digital-design-manifest.de.
Digital Designer kombinieren gestalterische und technische Kompetenzen. Durch diese Mischung können sie erfolgsversprechende Produktideen gemeinsam mit allen relevanten Stakeholdern erdenken und realisieren. Der Certified Digital Design Professional von IREB ist ein Ausbildungsmodell, das genau diese Kompetenzen vermitteln wird: www.digitaldesign.org

Was lernen die Zuhörer in dem Vortrag?

Dieser Vortrag motiviert Digital Design, stellt sein Kompetenzspektrum vor und illustriert Anhand von Beispielen, wie Digital Design die Softwareentwicklung verändern wird.

Kim Lauenroth
Kim Lauenroth

Dr. Kim Lauenroth leitet bei der adesso AG das Competence Center für RE. Er ist erster Vorsitzender des IREB e.V. und engagiert sich im Bitkom für die...

45 Minuten Vortrag

Einsteiger
Zeit

11:35-12:20
09. Oktober


Zielgruppe

Requirements Engineers, Business Analysten und alle, die Digitalisierung aktiv gestalten wollen


Themengebiet

Anforderungserhebung


Raum

tba


ID

Mi3.2

Reifegradmodell für empirisches Requirements Engineering

Traditionelle Reifegradmodelle gehen davon aus, dass das Befolgen eines klar definierten, guten Prozesses automatisch zu guten Produkten führt. Je volatiler, unsicherer und komplexer aber das Umfeld wird, desto weniger hilfreich ist die Befolgung starrer Prozesse und Pläne. Agile Vorgehensweise unterstützen daher das Denken und Handeln in Organisationen um die Menschen in die Lage zu versetzen, produktiv und kreativ Produkte mit höchstmöglichem Wert auszuliefern und sich dabei immer wieder neu an sich verändernde Umfelder anzupassen.
Dies bedeutet, dass auch heutige Reifegradmodelle diesen Gegebenheiten angepasst und andere Kriterien zur Einschätzung angesetzt werden müssen.

Die Theorie der empirischen Prozesssteuerung wird von drei Säulen getragen: Transparenz, Überprüfung und Anpassung. Diese 3 Säulen bilden auch die Basiskategorien bei der Darstellung des Reifegradmodells für empirisches Requirements Engineering‘, das die DATEV zusammen mit der HOOD Group entwickelt hat.

Was lernen die Zuhörer in dem Vortrag?

Wir zeigen auf, wie eine sinnvolle Reifegraderhebung in einem agilen Umfeld gelingen kann und teilen unsere Erfahrungen und Erkenntnisse.
Haben wir mit der Vorstellung das Interesse geweckt, würden wir gern in einen Erfahrungsaustausch treten wie man mögliche Synergien mit ihren und anderen Unternehmen schaffen kann.

Veit Joseph
Veit Joseph

Veit Joseph ist … bei der DATEV eG in einer zentralen Einheit als Requirements Engineer tätig. Sein Schwerpunkt ist hierbei die Ausbildung und Qualifikation...


Renate Böck
Renate Böck

Renate Böck ist … bei der DATEV eG als Requirements Engineer in einer zentralen Einheit tätig, die die Professionalisierung der Disziplin vorantreibt. Ihre...

45 Minuten Vortrag

Experte
Zeit

13:30-14:15
09. Oktober


Zielgruppe

Requirements Engineer, Product Owner


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Mi1.3

Psychologie der Veränderung

Was kommt nach der Anforderung? Die Veränderung. Das Problem: keiner will sich verändern.

Stopp! Das stimmt nicht ganz. Es gibt viele Menschen, die Veränderungen völlig offen gegenüberstehen. Sie wollen nur nicht verändern WERDEN.

Diese Session klärt die Hintergründe auf, warum sich der Mensch eigentlich so schwer mit Veränderung tut und welche Wand sich dadurch auftut, wenn es darum geht Anforderungen zu definieren oder bei der Definition von Anforderungen zu unterstützen. Belegt werden die verwendeten Praxisbeispiele dabei durch wissenschaftliche Erkenntnisse aus der psychologischen Forschung.

Die schlechte Nachricht: weil es wissenschaftliche Fakten sind, können wir das auch nicht ändern. Aber die gute Nachricht: wenn man das erstmal akzeptiert hat, kann man sich darauf einstellen und hervorragend damit arbeiten.

Was das bedeutet - dafür gibt dieser Vortrag die Impulse.

Was lernen die Zuhörer in dem Vortrag?

Auf der richtigen Ebene anzusetzen, wenn man auf Ablehnungsverhalten trifft.

Thiemo Laubach
Thiemo Laubach

Thiemo Laubach beschäftigt sich bereits im 15. Jahr ausschließlich mit dem Thema "Kommunikation und Zusammenarbeit in digitalen Kontexten". Mit einem...


Katrin Rösing
Katrin Rösing

Katrin Rösing...

45 Minuten Vortrag

Einsteiger
Zeit

13:30-14:15
09. Oktober


Zielgruppe

Alle, die sich häufig wundern, wie veränderungsresistent doch alle sind


Themengebiet

User Experience


Raum

tba


ID

Mi2.3

Videos im Requirements-Engineering

In jedem Projekt ist das Erstellen einer Spezifikation eine sehr wichtige, vielleicht sogar die wichtigste, Aufgabe, um die sich allerdings wohl die Wenigsten reißen. Daher haben wir uns von SOPHIST die Frage gestellt, ob es nicht eine spannendere Möglichkeit gibt, Anforderungen zu dokumentieren, und ob man mit dieser Möglichkeit Anforderung auch er- und vermitteln kann. Ideal scheint dafür ein Video. Dies wirft allerdings auch viele Fragen auf. Ist es möglich Videos für die Ermittlung von Anforderungen einzusetzen? Welche Qualitätskriterien besitzt so ein Video und lassen sich damit die Qualitätskriterien für Anforderungen erfüllen? Was muss in dem Video zu sehen sein und wie kann ich das Video bearbeiten? Und lässt sich dieses Video kostengünstig und zeiteffizient produzieren? Diesen und weiteren Fragen sind wir nachgegangen und stellen hier unsere Ergebnisse vor!

Was lernen die Zuhörer in dem Vortrag?

Wie man Videos nicht nur für die Ermittlung von Anforderungen verwenden kann

Michael Bezold
Michael Bezold

Als Fußballtrainer und ehemaliger Lehramtsstudent für Mathematik und Physik weiß ich, wie wichtig eine präzise Planung für Training und Unterricht ist. Dieses...

45 Minuten Vortrag

Einsteiger
Zeit

13:30-14:15
09. Oktober


Zielgruppe

Requirements Engineers, Requirements Manager, Product Owner


Themengebiet

Anforderungserhebung


Raum

tba


ID

Mi3.3

Requirements Engineering und Scrum - Ein Erfahrungsbericht

In der agilen Welt gibt es eine Menge von Ideen wie das Requirements Engineering ablaufen sollte. Allerdings kann das nicht eins zu eins in der Praxis umgesetzt werden, wenn die Voraussetzungen nicht stimmen. Wenn das der Fall ist, geht man dazu über die Methoden dementsprechend anzupassen.

In diesem Vortrag wird gezeigt wie Requirements Engineering in einem an Scrum angelehnten Vorgehen gelebt wurde. Es wird berichtet, wie der Wandel vom klassischem Vorgehen zu einem agilen Vorgehen ausgesehen hat, was alles schief gelaufen ist und welche Lehren daraus gezogen wurden.

Speziell darauf eingegangen wird auch welche Besonderheiten einer agilen Vorgehensweise in einem reguliertem Umfeld aufgetreten sind wie das Scrum-Team mit dem Product Owner damit umgegangen ist. Es wird berichtet wie das Product Backlog ausgesehen hat, wie Product Backlog Items formuliert wurden und wie die Anforderungen vom Product Owner an das Team weiter gegeben wurden. Auch die Erkenntnis, dass gut ausformulierte Anforderungen durchaus auch manchmal erst nach der Implementierung geschrieben werden könne wird Gegenstand des Vortrags sein.

Was lernen die Zuhörer in dem Vortrag?

Die Zuhörer lernen, wie Requirements Engineering mit einem Scrum-Team in der Praxis gelebt wurde.

Carsten Pflug
Carsten Pflug

Seit 2002 bin ich Berater und Trainer bei der SOPHIST GmbH. In zahlreichen Projekten unterstütze ich die Kunden bei der Erhebung, Dokumentation und dem Prüfen...

45 Minuten Vortrag

Fortgeschritten
Zeit

14:25-15:10
09. Oktober


Zielgruppe

Requirements Engineers, Product Owner


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Mi1.4

Brücken bauen für eine brillante UX

Bitte stellen Sie sich jeden Menschen als auf einer Insel lebend vor. Dieser Satz beschreibt mit dem einfachen Bild der Insel hoch komplexe Zusammenhänge des menschlichen Lebens. Denn die Insel beinhaltet alles was Sie je erlernt haben, ihre Hoffnungen, Ängste, Motive, Ziele, Meinungen und ihre eigene Beschreibung der Welt. Um eine gute Kommunikation zwischen Inseln aufzubauen, braucht es tragfähige Brücken zwischen diesen. Sowohl ihr Produkt-Team als auch ihre Nutzer leben auf unterschiedlichen Inseln. Wie gelingt es nun gute tragfähige Brücken von Ihrem Produkt-Team zu Ihren Nutzern aufzubauen? Der Grundstein für den Weg von der Strategie bis hin zu einem entsprechenden Oberflächendesign basiert sowohl auf den Bedürfnissen des Unternehmens als auch auf den Bedürfnissen der Nutzer. Nur, wenn Sie sich bei dem Design der UX Schritt für Schritt von der Insel des Unternehmens als auch von der Insel der Nutzer nähern, werden Sie tragfähige Brücken mit einer brillanten UX bauen.

Was lernen die Zuhörer in dem Vortrag?

Die Zuhörer lernen, dass jeder Mensch einzigartig ist und damit sehr individuelle Bedürfnisse hat. Dies ist auch im Rahmen der Erstellung von einer ausgezeichnet UX nicht zu vernachlässigen.
Die Zuhörer lernen ein Modell mit 5 Schritten kennen, wie sie Kommunikationshürden zwischen ihrem Unternehmen und ihren Nutzern/Kunden/Sofwareanwendern überwinden können.
Die Zuhörer können in interaktiven Übungen die einzelnen Schritte ausprobieren.
Die Zuhörer lernen unsere Beraterhaltung kennen, die besagt: es gibt keine Rezepte und allgemeingültige Blaupausen – gut ist, was nützt und am besten ist es, wenn es leicht geht.

Monika Schubert
Monika Schubert

Monika Schubert ist für die IT-Beratung OPITZ CONSULTING tätig. Neben ihrer Projekttätigkeit treibt sie als Leiterin des Kompetenzteam Anforderungs- und...


Manuel Juschkewitz
Manuel Juschkewitz

Manuel Juschkewitz...

45 Minuten Vortrag

Einsteiger
Zeit

14:25-15:10
09. Oktober


Zielgruppe

UX Designer, Entwickler, Teamleiter, Scrum Master, Product Owner


Themengebiet

User Experience


Raum

tba


ID

Mi2.4

Continuous Requirements Engineering

Beim Wechsel vom klassischen Requirements Engineering hin zum agilen, reicht es nicht, nur das Feature zu definieren und die Lösung dem Team zu überlassen. Es wird erst dann vollständig, wenn die gesamte Strecke bis hin zum Nutzer betrachtet wird. Damit wird der Nutzer zum festen Bestandteil des agilen Requirements Engineering. Ich werde hier das dafür erforderliche Vorgehen, sowie das passendes Handwerkszeug vorstellen, das die individuellen Anforderungen der Teilstrecke unterstützt. Das erfordert ein anderes Vorgehen, das hier vorgestellt wird. Außerdem stelle ich passendes Handwerkszeug vor, das die individuellen Anforderungen der Teilstrecke unterstützt.

Was lernen die Zuhörer in dem Vortrag?

  • Produkte zum Erfolg führen
  • Kundenbedarf kontinuierlich klar haben
  • Überblick über notwendiges Handwerkszeug um das Ziel zu erreichen
Mick Hohmann
Mick Hohmann

Mick Hohmann blickt auf 15 Jahre Projektmanagementerfahrung zurück und ist seit 2015 sowohl als Product Owner als auch als Scrum Master für Mayflower in...

45 Minuten Vortrag

Einsteiger
Zeit

14:25-15:10
09. Oktober


Zielgruppe

Product Owner, Requirements Engineers, Projektleiter, Manager, Entscheider


Themengebiet

Anforderungserhebung


Raum

tba


ID

Mi3.4

Agiles Anforderungsmanagement im Connected Car-Umfeld: Ein Erfahrungsbericht

Der Features-Prozess besteht aus unterschiedlichen Phasen, welche mit verschiedenen Werkzeugen der Attlassian Suite abgebildet werden. Er setzt auf dem SCRUM-Framework auf und ist an manchen Stellen abgewandelt. Der Features-Prozess besteht aus folgenden Bestandteilen:

Das Feature-Team besteht aus Business-/IT-Consultants, welche für die Ausarbeitung der Spezifikation zuständig sind. Darüber hinaus stehen ein Testmanager, ein Requirements Manager zur Koordination der Anforderungen und kundenseitig ein IT-Ansprechpartner, sowie der Produktverantwortliche als Teambestandteile zur Verfügung.

  1. Sammeln von Features.
    Grundsätzlich kann jedes einzelne Teammitglied Ideen für neue Features in dem eigens dafür angelegten Confluence-Bereich aufnehmen und be-schreiben. Anforderungen von außerhalb des Teams wurden an den Produktverantwortlichen des Kunden herangetragen und in das Requirements Backlog übernommen. Regelmäßig wird dieser Be-reich an Features vom Features-Team und dem Produktverantwortlichen inspiziert und initial be-wertet. Anhand dieser Bewertung wird ein JIRA-Ticket (Epic) erstellt und in das Feature- oder Requirements Backlog zu den anderen Tickets einpriorisiert.
  2. Priorisieren von Features.
    Das Epic wird auf das Kanban-Board aufgenommen, welches den gesamten Features-Prozess abbildet und somit den aktuellen Status, sowie die aktuelle Priorität jedes Features transparent macht.
  3. Spezifizieren von Features.
    Die Spezifikation der einzelnen Features erfolgt im Confluence-Bereich des Feature-Teams. Confluence bietet hierfür eine optimale Basis aufgrund der Vielzahl an unterschiedlichen, integrierten Werkzeugen und Strukturierungsmöglichkeiten, aber auch durch die enge Verzahnung und Verlinkung mit JIRA oder anderen Confluence-Bereichen in denen beispielsweise Besprechungsnotizen für Workshops erstellt und verwaltet werden. Dadurch werden alle relevanten Bestandteile der Spezifikation nahtlos miteinander verlinkt. Die Nachverfolgung und Bereitstellung von Informationen oder Beschlüssen wird somit aufgrund des deutlich minimierten Suchaufwands deutlich verbessert.
  4. Überprüfen von Features.
    Die Überprüfung der spezifizierten Features, das Review, erfolgt über einen definierten Zeitraum innerhalb des Features-Teams unter Zuzug des Produktverantwortlichen, eines Testmanagers, eines Requirements Managers und eines IT-Ansprechpartners des Kunden.
    Während des Review-Zeitraums sind alle Teilnehmer dazu aufgerufen, ihr Feedback zur Spezifikation in Form von Kommentaren direkt auf der Confluence-Seite zu dokumentieren. Jeder Teilnehmer sieht so alle Feedback-Kommentare der Vorgänger. Dadurch wird das Feedback an einer zentralen Stelle gesammelt und vollständige Transparenz über das gesamte Feedback geschaffen. Abschließend ist jeder Review-Teilnehmer dazu aufgefordert, sich in eine Liste einzutragen und, falls gewünscht, den Bedarf eines erneuten Reviews oder einer Abstimmungsbesprechung zu signalisieren.
    Das Review vor dem IT-Refinement ist kein Bestandteil des SCRUM-Frameworks, hat sich im Projektverlauf jedoch als äußerst sinnvoll herausgestellt, da so jeder Review-Teilnehmer den Gesamtkontext des Features kennt, bereits Feedback gegeben hat und auf dieser Basis das IT-Refinement nach dem Einarbeiten des Review-Feedbacks ohne unvorhergesehene „Show-Stopper“ stattfinden kann.
  5. Einarbeiten des Review-Feedbacks.
    Die Einarbeitung des Review-Feedbacks beginnt nach Ablauf des definierten Review-Zeitraums durch den Autor der Spezifikation. Rückfragen werden meist bilateral mit dem jeweiligen Feed-back-Geber besprochen. Falls von mehreren Feed-back-Gebern eine Nachbesprechung verlangt wird, wird dies bestenfalls in einem der Projekt-Regeltermine mit allen notwendigen Teilnehmern geklärt. Ein weiteres Review ist je nach Umfang und fachlicher Tiefe des Feedbacks durchzuführen. Dies erfolgt jedoch optional und ausschließlich auf expliziten Wunsch eines Review-Teilnehmers. Die Übergabe im IT-Refinement der fertiggestellten Spezifikation an den IT-Bereich (an den IT-Ansprechpartner) symbolisiert das Ende des Features-Prozesses. Die Implementierung im Entwicklungsteam erfolgt nach dem Standard-SCRUM-Framework.

Herausforderungen & Lösungen im Projekt.
Der Prozess, wie zuvor beschrieben, wurde im Laufe des Projekts Stück für Stück entwickelt. Im Folgen-den wird auf einzelne Veränderungen, Herausforderungen und Lösungen in der Entwicklung des Prozesses genauer eingegangen.

Einbindung der notwendigen Stakeholder in Spezifikation und Review.
Herausforderung. Die Identifikation der Stakeholder ist in jedem Anforderungsprozess eine der zentralen Herausforderungen. Die nächste Frage ist die, wie sehr diese Stakeholder während der Spezifikation eines Features eingebunden werden sollen. Zu Beginn des Projekts stammten diese Stakeholder ausschließlich aus dem Fachbereich. Ein dedizierter IT-Ansprechpartner war nicht benannt – nach der klassischen RE-Vorgehensweise, nach der die Anforderung vom Fachbereich kommt und der IT-Bereich diese umsetzt ohne vorher einbezogen zu werden. Erst bei der Übergabe wurde ein IT-Ansprechpartner hinzugezogen, was dazu führen konnte, dass an der Spezifikation grundlegende Änderungen (eventuell inklusive neuem Review) vorgenommen werden mussten.
Lösung. Dieses Problem wurde durch die Etablierung eines dedizierten IT-Ansprechpartners und eines wöchentlichen Abstimmungstermins zwischen IT- und Fachbereich behoben. Darüber hinaus wurde der IT-Ansprechpartner in den initialen Teilnehmerkreis für ein Review einer Spezifikation aufgenommen. Durch diese deutlich engere Zusammen-arbeit und die neuen Abstimmungsmöglichkeiten konnte eine Spezifikation deutlich genauer auf Bedürfnisse des IT-Bereichs abgestimmt werden, wodurch bei er
Übergabe von Fach- an IT-Bereich deutlich weniger unerwartete und kritische Feedback-Kommentare aufkamen. Neben den genannten Punkten etablierte sich dadurch auch der persönliche Kontakt zwischen dem Fach- und IT-Team, wodurch viele Abstimmungen in ad-hoc-Gesprächen schnell und effizient gelöst werden konnten.

Umgang mit Medienbrüchen in der Spezifikation.
Herausforderung. Zunächst war eine Vielzahl an unterschiedlichen, nicht miteinander vernetzten Werkzeugen im Einsatz (MS Office, JIRA, Confluence, MS SharePoint, etc.), um Besprechungen oder Workshops zu dokumentieren, den Fortschritt einzelner Features festzuhalten und für die Spezifikation selbst. Eine ständige Herausforderung war also, möglichst an der richtigen Stelle oder im richtigen System nach der entsprechenden Dokumentation zu suchen oder den Bezug zur ursprünglichen Spezifikation zu behalten, da keine transparente Verlinkung zwischen Spezifikation und User Stories möglich war.
Lösung. Die Lösung für diese Herausforderung war, dass alle relevanten, beschriebenen Bereiche in die Attlassian Suite zusammengezogen wurden und die Alt-Systeme lediglich als Archiv für eventuell not-wendige Recherchen dienen. Durch eine optimale Vernetzung aller Bereiche, sowie der Verlinkung von JIRA zu Confluence sind alle Querverweise nachvollziehbar und transparent verlinkt. Der Business-Bereich verwaltet die Tickets im IT-JIRA wodurch die Stories des IT-Bereichs direkt an das Business-Epic der Spezifikation gehängt werden können und so eine noch enge-re Kopplung von IT- und Fachbereich erfolgt. Dies steigert die Transparenz, sowie die Übersichtlichkeit und erhöht die Effizienz im Features-Team.

Review der Spezifikationen.
Herausforderung. Das Review der Spezifikationen erfolgte, indem jeder Review-Teilnehmer ein eigenes Word-Dokument zur Verfügung gestellt bekam. In dieses Dokument wurden Kommentare eingetragen und am Ende des Reviews vom Autor der Spezifikation aus allen Review-Dokumenten zusammengetragen, sowie ein großer Termin in dem Maßnahmen vereinbart.
Lösung. Durch den Zusammenzug aller relevanten Bereiche in die Attlassian Suite erfolgt der Review-Prozess ebenfalls in Confluence. Aus vielen einzel-nen Dokumenten mit Kommentaren wurde ein einziges Dokument, an dem jeder Review-Teilnehmer kommentieren kann. Jeder Review-Teilnehmer sieht alle Kommentare des Vorgängers, wodurch keine Dopplungen mehr entstehen und eine interaktive Kommunikation im gesamten Review-Prozess aller Teilnehmer möglich ist. Für den Autor der Spezifikation entfällt der Aufwand der Zusammenführung aller Dokumente, wodurch mehr Zeit und Konzentration auf die eigentliche Bearbeitung des Feedbacks verbleibt.
Umfang der Features und Anforderungen.
Herausforderung. Das Produkt wurde als Produkt mit einigen Basisfunktionen auf den Markt gebracht. Folglich dauerte es nicht lange, bis neue Features identifiziert wurden, um das Produkt weiterzuentwickeln. Diese Features mussten zunächst spezifiziert werden. Unklar war, wie die Features fachlich geschnitten werden sollten. Werden größere Spezifikationen erstellt, welche mehrere Features bündeln oder sollen einzelne Kleinstspezifikationen auf möglichst feingranularer Ebene entstehen. Darüber hinaus fehlte ein geeignetes Spezifikationstemplate, welches alle relevanten (nicht mehr und nicht weniger) Bestandteile einer solchen Spezifikation bein-haltet.
Lösung. Die Entscheidung der Spezifikationsumfänge fiel auf kleinstmögliche Spezifikationen, die dennoch für sich selbst abgeschlossene Features behandeln. Dadurch konnte das Leistungsangebot des Produkts Schritt für Schritt erweitert werden. Des Weiteren bietet dieser Ansatz die größtmögliche Flexibilität, um auf neue, sehr wichtige oder dringend benötigte Features und Marktanforderungen zu reagieren. Für diese Spezifikationen wurde ein Spezifikationstemplate erstellt, welches im Laufe des Projekts, beispielsweise um „Reporting“ oder rollout-spezifische Abhängigkeiten, weiterentwickelt wurde.

Zusammenfassung.
Die Telematikdatenplattform wurde als funktionsfähiges Produkt mit Basisfunktionalitäten auf den Markt gebracht. Dieser Sachverhalt bildet eine per-fekte Basis, um dieses Produkt in jeder Hinsicht agil weiterzuentwickeln.
Durch eine kontinuierliche Priorisierung neuer Features und Anforderungen ist stets gewährleistet, dass das Thema als nächstes bearbeitet wird, welches den größten oder den am dringendsten benötigten Mehrwert für Nutzer und Betreiber der Telematikdatenplattform liefert.
Ferner erlauben die kurzen Spezifikationszyklen durch kleine in sich geschlossene Features schnelle und flexible Reaktionszeiten auf neue Features und Anforderungen, die beispielsweise direkt aus dem Markt kamen.
Durch den jetzigen frühzeitigen Einbezug des IT-Bereichs in der Spezifikationsphase steigerten sich die Qualität der Spezifikationen und der Abstimmungsaufwand während der Spezifikation selbst, sowie vor und bei der Übergabe.
Der Features-Prozess bildet einen kontinuierlichen Verbesserungsprozess des Produkts, der Telematikdatenplattform, ab, da das Produkt mit jeder noch so kleinen Spezifikation, die umgesetzt wird, Schritt für Schritt verbessert und erweitert wird.

Was lernen die Zuhörer in dem Vortrag?

Das Zusammenspiel zwischen Fach- und IT-Bereich bei der Spezifikation neuer Features/Anforderungen im agilen Requirements & Software Engineering-Umfeld, sowie ein Best-Practice des Einsatzes von Spezifiaktionswerkzeugen.

Dennis Wagenblast
Dennis Wagenblast

Nach Beendigung des Wirtschaftsinformatik-Masters an der Hochschule Ravensburg-Weingarten im Sommersemester 2017 zog es Dennis Wagenblast aus privaten...


Findan Eisenhut
Findan Eisenhut

Findan Eisenhut...

45 Minuten Vortrag

Einsteiger
Zeit

15:40-16:25
09. Oktober


Zielgruppe

Requirements Engineers, Business Consultants, IT-Consultants, Product Owner, Projektmanager


Themengebiet

Erfahrungsberichte


Raum

tba


ID

Mi1.5

Herausforderung Business Agilität: Was kommt nach dem Requirements Engineering?

Im Zeichen der Digitalisierung stehen Unternehmen und öffentliche Verwaltung unter Druck: Produktinnovationen und neue Services müssen in immer kürzeren Zyklen bereitgestellt werden. Das erfordert eine hohe Business Agilität. Agile Frameworks wie Scrum, SAFe und LESS, interaktive Arbeitstechniken wie Design Thinking sowie cloud-basierte Technologien u.a. für Continuous Delivery sind dafür heute die Mittel der Wahl. Ihr Versprechen: Schnelligkeit bei der Umsetzung von Innovation, Flexibilität im Umgang mit Veränderung und Beherrschung von Managementkomplexität. Zur Business Agilität gehört neben diesen drei Fähigkeiten noch eine weitere, nämlich Chancen für Innovation überhaupt zu erkennen und den damit zu erzielenden Geschäftswert einzuschätzen. Wie kann eine Organisation diese Fähigkeit erwerben? Hilft das Requirements Engineering auf dem Weg zu mehr Business Agilität? Spielt es in seiner klassischen Ausprägung zukünftig noch eine Rolle? Die Antwort lautet: Ja – aber nur dann, wenn wir das Requirements Engineering in einem erweiterten Scope als Teil der agilen Business Analyse verstehen und die Rolle des Requirements Engineers zum Digital Business Analyst weiterentwickeln.

Was lernen die Zuhörer in dem Vortrag?

Die Zuhörer lernen agile Business Analyse, ihre Artefakte, Prozesse und ihre agilen Planungstechniken kennen. Sie erfahren, wie man damit den Weg vom erkannten Innovationsbedarf bis zur realisierten Lösung nachvollziehbar macht und wodurch Business Agilität entsteht. Es wird aufgezeigt, wie das klassische Requirements Engineering in die agile Business Analyse einzuordnen ist.

Ursula Meseberg
Ursula Meseberg

Ursula Meseberg (Dipl. Math.) hat die Berliner microTOOL GmbH 1984 mitbegründet und ist Geschäftsführerin des Unternehmens. Zu Beginn ihrer beruflichen Laufbahn...

45 Minuten Vortrag

Experte
Zeit

15:40-16:25
09. Oktober


Zielgruppe

Requirements Engineers, Business Analysten, Projektmanager, Produktmanager, Product Owner


Themengebiet

Business Analyse


Raum

tba


ID

Mi2.5

Schätzen heißt Lügen

In vielen agilen Projekten entstehen Probleme im Umgang mit Schätzungen: Entwickler müssen Schätzungen abgeben, die viele unbekannte Variablen enthalten. Product Owner bauen ihre Planungen auf diesen Schätzungen auf und müssen ihren Stakeholdern hierüber berichten. Wenn die Schätzungen dann nicht zur Realität passen, kommt es zum Konflikt zwischen allen Beteiligten.

Wenn niemand also Schätzungen wirklich mag und sie zu Konflikten führen, wofür sind sie gut und wie kann man sie gewinnbringend einsetzen? Dieser Vortrag versucht die Wogen zu glätten, Schätzungen an ihren richtigen, konstruktiven Platz im Projektalltag zu rücken und Alternativen zu Schätzungen aufzuzeigen.

Der Vortrag richtet sich an Product Owner, Business Analysten, Entwickler in agilen Teams und Stakeholder im Managementbereich, die sich einen besseren Einblick in Schätzfragen und die Planbarkeit von Softwareprojekten wünschen.

Was lernen die Zuhörer in dem Vortrag?

Planung & Pläne

  • Warum planen wir überhaupt?
  • Welche Pläne benötigen wir wirklich?
  • Das Spannungsfeld zwischen Agilen Vorgehensweisen und äußeren Erfordernissen (Zeit- und Budgetplanung insbesondere im Konzern)

Schätzungen

  • Wie kann man schätzen?
  • Was bringt schätzen wirklich?

Messen statt Schätzen?

  • Grundlagen / Anwendung von NoEstimates
  • Helfen uns NoEstimates wirklich weiter?
Ulf Mewe
Ulf Mewe

Ulf Mewe ist als Berater bei der HEC GmbH in Bremen tätig. Er berät und unterstützt Unternehmen, Fachbereiche und Teams in den Bereichen...


Roman Schmidt
Roman Schmidt

Roman Schmidt...

45 Minuten Vortrag

Fortgeschritten
Zeit

15:40-16:25
09. Oktober


Zielgruppe

Product Owner, Business Analysten, (Scrum Master), (Entwickler in agilen Teams)


Themengebiet

Techniken


Raum

tba


ID

Mi3.5

Das innovative Zusammenspiel zwischen dem JtbD-Framework und der agilen Produktorganisation

In diesem Praxisbericht wird über eine Transformation einer klassischen Organisationsstruktur hin zu einer agilen Produktorganisation berichtet, bei der funktionale Silos sowie zahlreiche Hierarchieebenen abgebaut wurden. Dabei bildeten kleinste Organisationseinheiten funktionsübergreifende Produktteams, die in der Organisationsstruktur verankert wurden.

Gleichzeit wurde die Notwendigkeit eines übergreifendes Anforderungsartefakts erkannt, das besonders auf die Innovationsfähigkeit der Organisation abzielt und eine fachliche Klammer über mehrere agile Scrum-Teams spannt. Der dabei gewählte Jobs-to-be-Done- Ansatz (JtbD) ist ein sehr vielfältig einsetzbares Framework, um die Bedürfnisse von Kunden zu hinterfragen und um ein gemeinsames Verständnis zu erarbeiten.

Die JtbD-Methode stellt die Kundenzentrierung in den Mittelpunkt und gleichzeitig wird die Organisation auf die Bedürfnisse der digitalen Kunden ausgerichtet. Das dadurch entstandene Zusammenspiel einer leichtgewichtigen Organisationsstruktur mit einem innovativen Anforderungs-Framework hat sich für diese Organisation als agile Vorgehensweise im Sinne der agilen Prinzipien des Agilen Manifests bewährt.

Was lernen die Zuhörer in dem Vortrag?

Die Zuhörer lernen das in Deutschland noch eher unbekannte Jobs-to-be-Done-Framework kennen und dessen Potential.
Zudem die konkreten Einsatzmöglichkeiten in einer agilen Produktorganisation als Skalierungsartefakt.

Andreas Becker
Andreas Becker

Andreas Becker ist Gründer und Inhaber von COMPLEXcellence und als Coach, Trainer und Berater für agile und digitale Transformationen tätig. Seine...

45 Minuten Vortrag

Experte
Zeit

16:35-17:20
09. Oktober


Zielgruppe

Product Owner, ScrumMaster, Agile Coaches, Change-Manager, Führungskräfte, Interessierte an agilen Transformationen


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Mi1.6

Die Digitale Transformation des Requirements Engineering

„Digitalisierung“ gehört ohne Zweifel zu den besonders strapazierten Begriffen. Die öffentliche Verwaltung soll digitalisiert werden, die Schulen sowieso und Unternehmen, die jetzt nicht ganz schnell digitalisieren, riskieren ihre Zukunft.

Diese Debatte kann auch am Requirements Engineering nicht spurlos vorübergehen: Was bedeutet überhaupt Digitalisierung? Was ändert sich für den Requirements Engineer? Hat er nun andere Aufgaben? Benötigt er neue Techniken? In dem Vortrag plädiere ich dafür, den Blick zu erweitern, um auch der Digitalisierung gerecht zu werden. Ging es bisher vor allem darum, die Anforderungen der (internen) Kunden aufzunehmen und festzuhalten, erfordert die Digitalisierung, die Geschäftsmodelle weiterzuentwickeln, um die Möglichkeiten, welche die digitale Technik bietet, auch erkennen und nutzen zu können.

Wie das konkret aussehen kann, soll ebenfalls in dem Vortrag vorgestellt werden. Dabei werden bewährte Techniken wie Story Maps, Jobs to be Done oder Business Model Canvas neu kombiniert, um den Bogen von der Entwicklung der Geschäftsmodelle, über die Geschäftsprozesse bis hin zu den Anforderungen zu spannen.

Was lernen die Zuhörer in dem Vortrag?

Wie muss sich das Requirments Engineering anpassen, um den Herausforderungen der Digitalisierung gerecht zu werden.

Marcus Winteroll
Marcus Winteroll

Dr. Marcus Winteroll ist Mitglied der oose Innovative Informatik eG und beschäftigt sich als Trainer und Berater mit der Analyse sowie Verbesserung von...

45 Minuten Vortrag

Experte
Zeit

16:35-17:20
09. Oktober


Zielgruppe

Product Owner, Business Analysten, Requirements Engineere


Themengebiet

Business Analyse


Raum

tba


ID

Mi2.6

Beyond User Stories - Backlogs priorisieren, wenn's anspruchsvoll wird

Die Entscheidungen, die ein Product Owner bei der Priorisierung des Backlogs treffen muss, sind alles andere als einfach.
Was ist wichtiger: Security oder Usability?
Kommt als nächstes ein weiteres Feature oder werden technische Schulden abgebaut?
Welche der drei Funktionen soll als erstes realisiert werden?

In diesem Vortrag werden Wege vorgestellt, wie man diese Entscheidungen treffen kann und zwischen den hunderten Anforderungen nicht die Balance verliert.
Angeknüpft wird immer dort, wo die gängigen Modelle wie Business Modelling, Value Proposition oder Story Mapping aufhören - immer geleitet von der Frage: Wie kann eine Product Ownerin all die Ideen, Wünsche und Notwendigkeiten operationalisieren?
Dabei geht es auch um Anschlussfähigkeit agiler Anforderungsprozesse in klassischen Organisationen, mit all den anspruchsvollen Rahmenbedingungen, die Product Ownership in solchen Umgebungen mit sich bringt.

Was lernen die Zuhörer in dem Vortrag?

Wie funktionieren Backlog-Strukturen aus einer Anforderungsperspektive?
Wie funktioniert ein Anforderungsprozess, der ein Backlog strukturiert füllt?
Was macht das Scrum-Team in Anforderungsmanagement?
Wie treffe ich als Product Owner Entscheidungen zu Anforderungen?
Was passiert mit alten Anforderungen?
Wie balanciere ich konkurrierende Anforderungen aus?

Gerrit Beine
Gerrit Beine

Gerrit Beine ist Manager bei der DARCBLUE AG und Coach für Agile- und Lean-Methoden. Seit dem Jahr 2001 ist er mit agilen Methoden unterwegs und liebt es...

45 Minuten Vortrag

Fortgeschritten
Zeit

16:35-17:20
09. Oktober


Zielgruppe

Product Owner, Product Manager, Projektleiter, Business Analsysts, Agile Coaches


Themengebiet

Techniken


Raum

tba


ID

Mi3.6

Anforderungsmanagement mit Lego Serious Play

In dem Workshop werden Techniken des Haptischen Denkens für das Anforderungsmanagement praktisch vorgestellt und mit den Teilnehmenden durchgeführt. Der Schwerpunkt liegt dabei auf dem Einsatz der Methodik "Lego Serious Play", aber auch andere Varianten des Haptischen Denkens kommen zum Einsatz. Durch das dreidimensionale Bauen von Objekten kann auf einfache Weise eine gemeinsame Sprache zwischen Kunden und Entwicklern gefunden werden, die das Definieren von Anforderungen gerade bei IT-fernen Kunden wesentlich erleichtern kann.

Haptisches Denken fördert den Prozess, Ideen und Vorstellungen konkret und beschreibbar zu machen, die sonst leicht als unklare Vorstellung im Kopf des End-Users oder Kunden bleiben. Dadurch kann ein gemeinsamer agiler Prozess auf Augenhöhe zwischen Product Owner und Dev Team auf der einen und den Auftraggebern auf der anderen Seite wesentlich unterstützt werden. Lego Serious Play als etablierte und evaluierte Methode des Haptischen Denkens ist ein klares Framework mit einfachen Prinzipien, dass gute Laune verbreitet und gleichzeitig greifbare Ergebnisse liefert.

Was lernen die Zuhörer in dem Vortrag?

Methoden des Haptischen Denkens für RE, Lego Serious Play für RE, Ideen und Vorstellungen für andere leichter nachvollziehbar machen, bessere und klarere Kommunikation zwischen Auftraggebern und Product Owner/ Dev Team, zufriedenere Kunden, weniger Reklamationen

Anne Hoffmann
Anna Hoffmann

Innovationsmanagerin, Scrum- Trainerin, Design Thinkerin, certified Product Owner, certified Scrum Master, Trainerin für partizpatives Leadership, Beraterin in...


Nico Murawski
Nico Murawski

Nico Murawski...

120 Minuten Workshop

Alle Level
Zeit

20:00-22:00
09. Oktober


Zielgruppe

Agile Coaches, Product Owner, Dev Teams, Scrum Master


Themengebiet

Techniken


Raum

tba


ID

Abendevent

Agiles Produktmanagement mit Usertesting im Musikmarkt

Die zunehmende Globalisierung und Virtualisierung ist allgegenwärtig, die Märkte sind gesättigt, die Produktstruktur eher homogen und schnell zu imitieren. Diese Erkenntnisse gibt es nicht erst seit gestern und die Idee zur Lösung lautet oft genug: Die Digitalisierung ist der Treiber und der Schlüssel zur Veränderungskur eines Unternehmens und der Differenzierung am Markt. Öffne die Tür zur Digitalisierung! Sei Innovator und Treiber deiner Branche! Wir stellen fest - einfacher gesagt, als getan. Aber es zu versuchen lohnt sich.

Wir nehmen euch mit auf eine aufregende Reise an deren Ende der Kunde und auch wir in ein neues Verständnis von Agilität hineingewachsen sind. Ein Erfahrungsbericht aus einem Projekt in einem fachlich komplexen Kundenumfeld, mit einem engen Zeitplan, festem Budget, vielen Abhängigkeiten und einem völlig neuem Team. Und mit der Idee und dem Mut genau in diesem Umfeld mit einem Produkt auf der grünen Wiese zu starten.

Wie schafft man es, das Potential einer Lösung vollständig zu erschließen und dabei genau das umzusetzen, was die Endnutzer wirklich begeistert? Wie schafft man es flexibel in den Anforderungen und innovativ in der Lösung zu sein, wenn sich im Projektumfeld die gängigen Restriktionen wie Zeit, Geld und Skeptik tummeln? Wie transportiert man dies über die Grenzen eines einzelnen Projektes hinaus in die Innen- und Außensicht eines Unternehmens?

Wir nähern uns den Antworten auf diese Fragen vom Kleinen zum Großen und möchten Euch angefangen vom richtigen Projektsetup, einer Vielzahl an einfachen Methoden sowie dem notwendigen Mindset erzählen, was für uns das Rüstzeug für den Weg zum Projekterfolg war.

Was lernen die Zuhörer in dem Vortrag?

Agiles Mindset, wertegetriebene Softwareentwicklung, Agiles Projektmanagement, User-Experience, User-Interface, User-Testing

David Fornol
David Fornol

Als Projektleiter für Softwareentwicklungsprojekte ist David Fornol seit 2 Jahren für die adesso im Einsatz. Zumeist waren die Kundenprojekte in dieser Zeit...


Bernhard Heintzen
Bernhard Heintzen

Als Produktmanager im Mitglieder- und Repertoiremanagement bei der GEMA rückt Bernhard Heintzen die Kreativen in den Mittelpunkt und bearbeitet digitale...

45 Minuten Vortrag

Fortgeschritten
Zeit

10:40-11:25
10. Oktober


Zielgruppe

Projektleiter, Requirements Engineer, UX-Konzepter


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Do1.1

Agilität in der Schulentwicklung

Schulen sind autonom in der Erfüllung ihres Bildungsauftrages. Sie sollen den Schülerinnen und Schülern den Erwerb der vordefinierten Zielkompetenzen ermöglichen, müssen in ihrem jeweiligen Kontext aber selbst eine Systematik dafür finden. Der Weg zu einer eigenen Haltung, einem Rahmen für Schule in der Praxis, ist ein Entwicklungsprozess, der Jahre dauern kann. Wir möchten zeigen, warum in diesem Prozess agile Werte eine große Rolle spielen und Tools bei der Strukturierung, Dokumentation, Evaluierung und gezielten Modifizierung des Prozesses hilfreich sind.

Was lernen die Zuhörer in dem Vortrag?

Wie man in einer eher klassischen Umgebung wie einer Schule agil an die Entwicklungsorganisation heran gehen kann.

Bastian Stehmann
Bastian Stehmann

Bastian Stehmann arbeitet als Berater bei der neusta portal services GmbH, einem team neusta Unternehmen. Dort setzt er seine langjährige Erfahrung in...


Patrick Zeising
Patrick Zeising

Patrick Zeising...

45 Minuten Vortrag

Einsteiger
Zeit

10:40-11:25
10. Oktober


Zielgruppe

Bildungseinrichtungen, Schulentwickler, Berater


Themengebiet

Zusammenspiel klassisch/agil


Raum

tba


ID

Do2.1

Mit Künstlicher Intelligenz die Qualität von Anforderungen nachhaltig steigern

Einer der schwierigsten Aspekte komplexer Engineering-Projekte von heute ist die schiere Datenmenge, die Teams für die Verwaltung benötigen. Da Produktdesigns versuchen, immer schwierigere Probleme zu lösen, kommt es zu einer Explosion von Daten. So übertrifft beispielsweise in den heutigen Automobilen die Komplexität der Software die Komplexität des Fahrzeugs selbst. Ein Auto kann z.B. mehr als eine Million Zeilen Code haben. Die menschliche Lern- und Anpassungsfähigkeit kann mit diesem Datenzuwachs einfach nicht Schritt halten, was bedeutet, dass die Verwaltung von Anforderungen mit Hilfe von Tabellenkalkulationen und Dokumenten - oder sogar einem traditionelle Anforderungsmanagementlösung nicht mehr machbar ist. IBM Requirements Quality Assistant (RQA), eine in bestehende Anforderungsmanagementlösungen eingebettete Watson-Funktion, wendet die KI auf den Anforderungsprozess an. Es verbessert die Vollständigkeit, Konsistenz und Genauigkeit der Anforderungen, während sie geschrieben werden, um Unklarheiten zu beseitigen und kostspielige Fehler zu vermeiden. RQA findet und lokalisiert Probleme und bietet fachkundige Anleitung zu deren Behebung.

Was lernen die Zuhörer in dem Vortrag?

  • Watson, IBM‘s KI System für Business (B2B)
  • Was ist Künstliche Intelligenz (KI) bzw. Artifical Intelligence (AI) und warum man sich nicht davor fürchten muß?
  • Warum IBM bei KI eher von Cognitive Computing und Augmented Intelligence spricht?
  • Wie gehört Machine Learning zu KI und welche Formen gibt es?
  • Exemplarische KI Lösungen von Kunden
  • Requirements Management und KI
  • Requirements Quality Assistant (RQA)
  • Live Demo
  • Fragen & Antworten
Dominik Jergus
Dominik Jergus

Dominik Jergus, mit Sitz in München, arbeitet seit über 20 Jahren in internationalen Projekten im Bereich Application Lifecycle Management und Systems...

45 Minuten Vortrag

Einsteiger
Zeit

10:40-11:25
10. Oktober


Zielgruppe

Alle Anwender, die sich mit dem Verfassen oder der Qualität von Anforderungen beschäftigen


Themengebiet

Tooleinsatz


Raum

tba


ID

Do3.1

Verteiltes agile Coaching - Wie standortübergreifendes Arbeiten gelingen kann

Gemeinsam mit einem Kollegen durfte ich, in der Rolle eines Agile Coach, ein Projekt zur agilen Transition im Großkonzern begleiten. Besonders daran war, dass wir dabei ein Team betreuten, welches sich über zwei Standorte verteilte. Die Rolle des Product Owners war dabei doppelt besetzt. Auch mein Kollege und ich sind an unterschiedlichen Standorten unserer Firma tätig. So waren wir zunächst gezwungen eine eigene Methodik zu entwickeln, die es uns trotz der geographischen Trennung erlaubte erfolgreich zusammenzuarbeiten. Hierbei war uns zunächst wichtig, ein gemeinsames Zielbild für das Coaching des Kunden zu entwickeln, das sich auch kontinuierlich weiterentwickeln ließ. Außerdem legten wir verstärkt Wert auf die transparente Dokumentation unserer Arbeitsergebnisse, sowie eine effiziente Aufgabenverteilung zwischen uns als Coaches. Unser Ansatz führte uns zum Erfolg und ermöglichte es, innerhalb weniger Monate ein erfolgreiches Team aufzubauen und dabei den fest geplanten Abstimmungsaufwand zwischen meinem Kollegen und mir auf ein dreißigminütiges Telefonat pro Woche zu beschränken.

Was lernen die Zuhörer in dem Vortrag?

Dieser Vortrag ist ein Erfahrungsbericht aus unserer Perspektive als Coaches. Neben einem Einblick in die angewandte Methodik und Tools erhalten die Besucher auch eine Übersicht an Tipps und Tricks, die sich auch allgemein auf das Arbeiten in verteilten Teams übertragen lassen.

Ingo Sobik
Ingo Sobik

Als Consultant und Agile Coach unterstützt Ingo Sobik für die esentri AG Kunden bei ihrem digitalen Wandeln. Dabei versteht er es als Digital Native...

45 Minuten Vortrag

Fortgeschritten
Zeit

11:35-12:20
10. Oktober


Zielgruppe

Agile Coaches, Scrum Master, Verteilte Teams


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Do1.2

Hybrides Anforderungsmanagement - Anforderungen sinnvoll klassifizieren und angemessen agil oder klassisch behandeln

Unserer Erfahrung nach gibt es in jedem Projekt unterschiedliche Typen von Anforderungen. Die einen sind vorhersehbarer und es herrscht eine vernünftige Einigkeit unter den Stakeholdern, oft gibt es bei diesen Anforderungen jedoch besonders viele Abhängigkeiten, die eingeplant werden wollen.
Andere Anforderungen sind unsicher, es nicht wirklich vorhersagbar, was man will, wie es umsetzbar ist, wie lange es dauern wird, ob es überhaupt geht und letztendlich: Ob der Anwender es wirklich braucht. Man kann ewig diskutieren und kommt doch zu keinem zufrieden stellenden Ergebnis.

Unpraktisch, dass beide Anforderungs-Typen (plus beliebige Mischformen) oft in ein und demselben Projekt auftauchen.

Statt mit einem neuen agilen, oder - ganz aktuell - hybriden Prozess alle zu überfordern, schlagen wir ein weniger disruptives, aber sehr effektives Vorgehen vor, das sich insbesondere in solchen gemischten Umgebungen bewährt hat: Wir schauen uns unsere Anforderungen genauer an, bewerten Sie nach Risiko und machen transparent, wie viel man durch ausprobieren und Feedback einholen vs. detailliertere Analyse erreichen kann.

Was lernen die Zuhörer in dem Vortrag?

Die Teilnehmer erfahren anhand von Beispielen, die wir aus unserer Praxis mitbringen, welche Vorgehensweise bei welcher Art von Anforderungen welche Auswirkungen hat bzw. haben kann.
Damit können wir, wo es möglich ist, mit traditionellen Methoden eine hohe Effizienz sicherstellen. Wo es notwendig ist, erzeugen wir mit agilen Methoden und Feedback-Schleifen Ergebnissicherheit.

Thomas Starz
Thomas Starz

In meiner langen Karriere konnte ich Erfahrung sammeln als technischer Autor, Teamleiter, Projektleiter, Agile Instruktor und Coach. Früh war mir klar, dass...


Olaf Bublitz
Olaf Bublitz

Ich habe in verschiedenen Bereichen der Softwareindustrie als Abteilungsleiter, Softwareentwickler, Projektmanager und Produktmanager Erfahrungen...

45 Minuten Vortrag

Einsteiger
Zeit

11:35-12:20
10. Oktober


Zielgruppe

Projektleiter, Produktmanager, klassische und Agile Requirements Engineers, Product Owner, Entwickler, Fachbereichsmitarbeiter


Themengebiet

Zusammenspiel klassisch/agil


Raum

tba


ID

Do2.2

„Mach‘ mehr aus dem, was du hast!“ – Anforderungsmanagement mit Jira und Confluence

Es ist immer wieder erstaunlich, wie viele Firmen auch in größeren Softwareprojekten ihre Anforderungen noch mit Word und/oder Excel verwalten. Irgendwann kommt man aber in Softwareprojekten mit einer größeren Anzahl von Anforderungen an den Punkt, zu dem der Ruf nach einem dedizierten Tool für das Anforderungsmanagement im Team immer lauter wird.

Die Einführung eines Anforderungstools ist jedoch oft mit hohem Aufwand verbunden. Daher gilt es aufzuzeigen, wie sich auch bestehende Tools für die Verwaltung von Anforderungen nutzen lassen – frei nach dem Motto „Mach’s mehr aus dem, was du hast!“

Über ein Ticketing-System und auch ein Enterprise-Wiki verfügen mittlerweile recht viele Softwareunternehmen. Sehr weit verbreitet sind hier Jira und Confluence von Atlassian. Beide Tools lassen sich in Kombination sehr gut für ein integriertes Anforderungsmanagement in agilen Projekten nutzen. Wie das in der Praxis aussehen kann, wird im Vortrag am Beispiel der Implementierung einer Auftragserfassungssoftware aufgezeigt.

Zunächst werden Jira und Confluence kurz vorgestellt. Hierbei wird auf die jeweiligen Schwerpunkte der Tools fokussiert, aber auch darauf, für welche Aufgaben sie sich weniger gut eignen. Im Folgenden wird dann der Prozess für das Anforderungsmanagement mit diesen Werkzeugen anhand eines Prozessmodells illustriert.
Anhand des Beispiels einer konkreten Anforderung aus dem Projekt können die Zuschauer dann den kompletten Lebenszyklus einer Anforderung in Jira und Confluence verfolgen: Von der ersten Idee, über die Anforderungsanalyse und –dokumentation, das Anforderungsreview, die Bearbeitung der Anforderung im Entwicklerteam bis zum Akzeptanztest durch den Nutzer.

Am Ende werden die Vorteile des Anforderungsmanagements mit Jira und Confluence noch einmal zusammengefasst. Um das Bild zu vervollständigen soll jedoch auch auf die Grenzen dieses Ansatzes im Vergleich zu der Arbeit mit dedizierten Anforderungstool hingewiesen werden.

Der Vortrag schließt mit einer durch die Vortragenden moderierten Fragerunde, in dem die Zuhörer von ihren eigenen Erfahrungen berichten können und natürlich auch Fragen zum Vortrag stellen können.

Was lernen die Zuhörer in dem Vortrag?

Ziel des Vortrags ist es, den Zuschauern aufzuzeigen, dass es auch ohne dediziertes Requirements Engineering Tool möglich ist, Anforderungen effizient zu verwalten. Am Beispiel eines Projektes für die Implementierung eines Auftragserfassungssystems im Raumfahrtbereich soll vorgestellt werden, wie das Ticketing-Tool Jira und das Enterprise-Wiki Confluence des Herstellers Attlassian zu diesem Zweck eingesetzt werden können.

Kathrin Herrmann
Kathrin Herrmann

Seit 2004 bin ich im Softwarebereich tätig und kenne sehr gut die Herausforderungen, die die Einführung einer neuen Softwarelösung und die Weiterentwicklung...


Michael Herrmann
Michael Herrmann

Michael Herrmann...

45 Minuten Vortrag

Einsteiger
Zeit

11:35-12:20
10. Oktober


Zielgruppe

Product Owner, Requirements Engineers, Scrum Master, Systemingenieure, Projektleiter, Entwickler


Themengebiet

Tooleinsatz


Raum

tba


ID

Do3.2

The Best Business Software in Town – wie agiles Requirements Engineering die Systemauswahl beflügelt

Andreas Schlier hat ein Problem. Sein altes Excel-VBA-System tut es nicht mehr. Das einst so verlässliche Tool für die Auswertung von Fahrzeugproduktionsvorgängen ist in die Jahre gekommen. Das Datenvolumen steigt kontinuierlich. Die Fachbereiche möchten immer neue Funktionen. Und zu allem Überfluss verabschiedet sich der Software-Verantwortliche als einziger Wissensträger in die Altersteilzeit. Was soll Andreas Schlier tun?

Im Konferenzbeitrag unterstützt Christopher Schulz. Live, interaktiv und praxisnah. Er nimmt Andreas Schlier und die Teilnehmer mit auf einen Weg, von der initialen Software Vision bis zum konkreten Proof of Concept. Software Auswahl ist ein Entscheidungsprozess. Agiles Requirements Engineering beschleunigt das Vorgehen und sichert die langfristige Investition in ein Tool nachhaltig ab.

Was lernen die Zuhörer in dem Vortrag?

  • FOR-DEC Methode >> Business Software sicher und agil auswählen
  • 6S Modell >> Nie mehr wichtige Anforderungsquellen vergessen
  • Anforderungs- & Softwarekataloge >> bei der Auswahl Zeit und Aufwand sparen
  • System Canvas >> Vision & Scope einer Business Software visuell erfassen
  • Test- & Erkenntniskarte >> Software Piloten systematisch und schnell verproben
  • …und noch viele weitere praxiserprobte Tools & Methoden verpackt in einer Story.
Christopher Schulz
Christopher Schulz

Business Analyse, Requirements Engineering und Enterprise Architecture – das sind die drei Beratungsschwerpunkte von Dr. Christopher Schulz. Aktuell ist...

45 Minuten Vortrag

Fortgeschritten
Zeit

13:30-14:15
10. Oktober


Zielgruppe

Alle Teilnehmer, die ihren Requirements Engineering Techniken für die Auswahl der optimalen Business Software erweitern möchten


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Do1.3

Agilität und das "International Requirements Engineering Board e.V." (IREB) - Ein Widerspruch?

Sebastian Neumeyer ist seit mehr als 10 Jahren Berater und Projektmanager in klassischen und agilen Projekten und bei insendo GmbH zusätzlich als Chief Quality Officer tätig. Er schrieb seine Masterarbeit zum Thema "Vom klassischen zum agilen Requirements Engineering" und kann eine Zertifizierung nach IREB (Certified Professional for Requirements Engineering) vorweisen. In den letzten Jahren hat er erfolgreich MitarbeiterInnen zur Vorbereitung auf diese Zertifizierung geschult.

Seit 2013 bemerkte er bei verschiedenen Kunden in unterschiedlichen Branchen vermehrt, dass zwar mit einem agilen Ansatz gearbeitet wird, auf historisch etablierte Prozesse aber nicht komplett verzichtet werden kann. Meistens arbeiten nicht Alle an einem Projekt beteiligten Organisationseinheiten (extern / intern) agil. Somit stellt sich die Herausforderung, die agile Welt und die klassische Welt miteinander in Einklang zu bringen. Gerade in einer so relevanten Disziplin, dem Requirements Engineering, stellt die Harmonisierung dieser beiden Welten einen großen Erfolgsfaktor für einen erfolgreichen Projektabschluss dar.

Doch wie können diese zwei verschiedenen Welten harmonisiert werden? Wie gelingt in einem solchen Fall ein angemessenes Requirements Engineering?

Herr Neumeyer stellt in seinem Vortrag zuerst einen Vergleich zwischen den Kernpunkten von Requirements Engineering nach IREB dar und wie diese in einem agilen Umfeld angemessen eingesetzt werden können.

Was lernen die Zuhörer in dem Vortrag?

Verbindung zwischen Requirements Engineering nach IREB und Agilität.

Sebastian Neumeyer
Sebastian Neumeyer

Sebastian Neumeyer ist seit mehr als 10 Jahren Berater und Projektmanager in klassischen und agilen Projekten und bei insendo GmbH zusätzlich als Chief...

45 Minuten Vortrag

Fortgeschritten
Zeit

13:30-14:15
10. Oktober


Zielgruppe

Requirements Engineer, Business Analyst, Projekt Manager (klassisch, agil), Studenten, Praktikanten


Themengebiet

Zusammenspiel klassisch/agil


Raum

tba


ID

Do2.3

Tools im (agilen) Anforderungsmanagement - Die Qual der Wahl?

Auch wenn Interaktion und Kommunikation stets über Prozessen und Tools stehen sollten, sind letztere dennoch unabdingbar, um Projekte überhaupt effektiv und effizient durchführen zu können. Doch welches ist das wirklich adäquate Tool für den eigenen Kontext? Das, was eh schon im Haus ist, das, womit am wenigsten Lernaufwand besteht, das, was anderen Firmen auch nutzen, oder vielleicht etwas, an was man noch garnicht gedacht hat?

Genauso wie man zum Festziehen einer Schraube einen einfachen Schraubzieher, einen Drehmomentschlüssel oder einen Akkuschrauber verwenden kann, gibt es auch unterschiedliche Werkzeugtypen für das Anforderungsmanagement. Alle haben ihre Berechtigung sowie Vor- und Nachteile. Deshalb erachten wir es als zielführend zu hinterfragen, was man von einem Tool eigentlich genau benötigt und was man generell mit dem Tool machen möchte.

Wenn wir auf Veranstaltungen mit Personen ins Gespräch kommen und uns über Tools im Anforderungsmanagenent austauschen, merken wir jedoch immer wieder, dass vielen Beteiligten häufig nicht klar ist, weshalb überhaupt ein gewisses Tool in ihrer Firma verwendet wird. Oftmals wird angeführt, dass dies "historisch" bedingt sei, "in anderen Bereichen vorher auch schon genutzt wurde" oder "nicht viel koste".

In unserem Vortrag möchten wir deshalb die Vor- und Nachteile verschiedener Tool-Kategorien (nicht einzelner Tools) im Hinblick auf das Anforderungsmanagement vorstellen und eine Auswahlempfehlung geben, wann sich welche Tool-Kategorie am ehsten eignet.

Was lernen die Zuhörer in dem Vortrag?

  • Warum man Tools eigentlich braucht und warum diese auch im agilen Kontext nicht unwichtig sind
  • Welche wesentliche Tool-Kategorien im Anforderungsmanagement Anwendung finden
  • Welche Vor- und Nachteile die verschiedenen Tool-Kategorie haben
  • Was für und gegen verschiedene Tool-Kategorien spricht
Sebastian Adam
Sebastian Adam

Dr. Sebastian Adam ist Geschäftsführer der OSSENO Software GmbH und operativ für die Bereiche Produktinnovation und Marketing verantwortlich. Vor seiner...

45 Minuten Vortrag

Einsteiger
Zeit

13:30-14:15
10. Oktober


Zielgruppe

Personen, die sich über adäquate Werkzeugunterstützung in ihrem (agilen) Anforderungsmanagement Gedanken machen


Themengebiet

Tooleinsatz


Raum

tba


ID

Do3.3

Hypothese: User Stories sind Hypothesen!?

Viele Organisation behandeln User Stories wie Anforderungen. Wenn jemand etwas anfordert, bedeutet das, dass er sich hinsichtlich des Nutzes sehr sicher ist. Aber stimmt das in einer komplexen, dynamischen und postindustriellen Welt überhaupt? Oder gilt der alte Spruch, dass die Kunden eher stärkere Pferde statt eines Autos angefordert hätten? Ich meine, dass User Stories vielmehr Hypothesen und Experimente sind und berichte aus der Praxis, wie man dann mit ihnen umgeht.

Was lernen die Zuhörer in dem Vortrag?

  • Warum können wir in einer post-industriellen Welt nicht mehr sicher sein, was die richtigen Features sind?
  • Weshalb sollten wir möglichst schnelles Feedback zu unseren Ideen einholen?
  • Wie formuliert man User Stories als Hypothesen mit Experimenten?
  • Wie kann ich die Ergebnisse meiner Experimente messen?
  • Wie verändert das Arbeiten mit Hypothesen und Experimenten den Software-Entwicklungsprozess?
Konstantin Diener
Konstantin Diener

Konstantin Diener ist CTO bei cosee. Seit 2007 ist er mit dem agilen Virus infiziert. Er hat etliche agile Projekte und Produkte als Scrum Master, Product...

45 Minuten Vortrag

Einsteiger
Zeit

14:25-15:10
10. Oktober


Zielgruppe

Product Owner, Product Manager, Business Experts, Marketing, Sales, Software-Entwickler


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Do1.4

Metriken für agile Softwareentwicklung

Bei agiler Softwareentwicklung nach dem Vorgehensmodell SCRUM, beschrieben von Jeff Sutherland und Ken Schwaber, stehen die Anpassung an veränderte Bedingungen bzw. Anforderungen und die Optimierung des Prozesses im Mittelpunkt. Dabei gehen Anpassungen und Optimierungen vom Entwicklungsteam selbst aus. Das Team reflektiert regelmäßig und passt seine Vorgehensweise und Planungen entsprechend an. Um den Verlauf einer Iteration begründet beurteilen zu können, kommen in der Regel Metriken zum Einsatz. Als Grundlage für diese Metriken benötigt das SCRUM Team Daten zu Arbeitszeiten und Aufgaben der Teammitglieder im Betrachtungszeitraum.

Im Vortrag werden Metriken und passende Visualisierungen zur Beantwortung von Fragen von agilen Entwicklungsteams diskutiert. Die Metriken ermöglichen den Teammitgliedern einen besseren Zugang zu den Metadaten Ihrer eigenen Arbeitsrealität. Damit soll es dem Team möglich sein, die eigene Arbeit besser zu verstehen und auf Basis der gewonnenen Informationen seine Prozesse sinnvoll anzupassen.

Was lernen die Zuhörer in dem Vortrag?

  • Welche Fragen haben agile Teams?
  • Wo bekommt man die Daten her, um die Fragen zu beantworten?
  • Welche Metriken kann man aus den Daten bauen?
  • Wie lassen sich die Metriken sinnvoll einsetzen / missbrauchen?
  • Was kann ein agiles Team aus den Metriken lernen?
Richard Fichtner
Richard Fichtner

Richard Fichtner ist als Senior Architect bei XDEV Software in verschiedenen Projekten eingebunden. Als zertifizierter Scrum Master und Product Owner...

45 Minuten Vortrag

Fortgeschritten
Zeit

14:25-15:10
10. Oktober


Zielgruppe

Entwickler, SCRUM Master


Themengebiet

Zusammenspiel klassisch/agil


Raum

tba


ID

Do2.4

Was kann Künstliche Intelligenz für Requirements Engineering tun?

Der Vortrag untersucht was Machine Learning, Artificial Intelligence und Natural Language Processing für Requirements Engineering tun kann. Er beschäftigt sich damit, ob diese Technologien so weit sind, dass sie einem Requirements Engineer die Arbeit erleichtern können, indem die Algorithmen seine, bzw. ein Teil der Aufgaben übernehmen können. Als Herausforderungen wurden die manuellen, aufwändigen und repetitiven Aufgaben ausgesucht, wie z.B. Identifizieren und Importieren von Requirements aus Dokumenten verschiedener Formate, Klassifizierung von Requirements, Vergleich von Projekt Requirements, Suche nach ähnlichen Requirements etc. Für die Lösugnssuche wurde die Design Thinking Methode angewandt. Die interessantesten Ergebnisse werden in diesem Vortrag präsentiert: Identifikation, Klassifizierung, semantische Suche und semantischer Vergleich von Requirements. Der Vortrag ist für Requirements Engineers und deren Manager von Interesse. Weiter wird erklärt, wie die Unternehmen die AI Lösungen in Requirements Engineering Prozesse integrieren können.

Was lernen die Zuhörer in dem Vortrag?

Sie lernen wo die Künstliche Intelligenz bei Requirements Engineering eingesetzt werden kann

Marija Kopf
Marija Kopf

Dr. Marja Kopf ist promovierte Informatikerin mit zwei Jahrzehnten Berufserfahrung als IT Berater für verschiedene Automotive Hersteller und First Tier...

45 Minuten Vortrag

Experte
Zeit

14:25-15:10
10. Oktober


Zielgruppe

Requirements Engineers, C-Level


Themengebiet

Tooleinsatz


Raum

tba


ID

Do3.4

Manage the Shortage - Wie Sie das Richtige, richtig machen.

Wer kennt dieses Problem nicht? Einer begrenzten Anzahl von Möglichkeiten oder Mitteln steht eine schier unendliche Anzahl von Anforderungen gegenüber. Sobald es um das Management des Engpasses geht, bewegen wir uns oft im Komplexen. Agile Methoden helfen hier, nicht nur Transparenz zu schaffen, sondern auch das Richtige richtig zu machen. Im vorliegenden Erfahrungsbericht stelle ich den Entstehungsprozess eines wertschöpfungsorientierten Projektportfolio-Managements bei einem Rolls-Royce Flugzeugtriebwerks-Überholer in Thüringen dar. Beginnend auf der grünen Wiese wurde in kürzester Zeit ein Prozess und System etabliert, welches die unzähligen Anforderungen an den IT Bereich transparent macht, vorklassifiziert und -priorisiert sowie in einem für alle Stakeholder aktiven und nachvollziehbaren Entscheidungsprozess in die Umsetzungs- oder Implementierungsphase überleitet. Der Vortrag geht auf die damals vorherrschende Situation ein und erzählt anschaulich den Prozess hin zu Etablierung des agilen Projektportfolio-Managements. Dabei bespreche ich nicht nur die Systematik und Technik, sondern auch die damit einhergehende Ermächtigung und Ermöglichung der Business Analysten bei der Gestaltung des Prozesses als auch die Wirkung des Systems in die tayloristisch geprägte Organisation. Daneben gebe ich konkrete Hinweise, wie eine solche Vorpriorisierung aufgebaut und in anderen Bereichen adaptiert werden kann.

Was lernen die Zuhörer in dem Vortrag?

Wie kann ein agiles Projektportfolio-Backlog aufgebaut werden
Wie können Projekt-Entscheidungen transparent gemacht und gemeinsam getroffen werden
Was sind Hürden und mögliche Wiederstände eines agilen Projektbacklogs in klassisch, hierarchischen Organisationen

Jens-Michael Ruppelt
Jens-Michael Ruppelt

Meine Name ist Jens-Michael Ruppelt und bis Mitte 2019 war ich CIO / Director IT eines Unternehmens zur Überholung und Wartung von Triebwerken ziviler...

45 Minuten Vortrag

Einsteiger
Zeit

15:40-16:25
10. Oktober


Zielgruppe

Business Analysten, IT Manager, CIO, Portfolio Manager, Projektleiter


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Do1.5

Adaptive leadership for agile and sociocratic group dynamics – a field report

Requirements engineering often is perceived as the mere managing of lists. We use powerful tools to collect and track work items. Each item has an ID, status information, a priority and is linked for traceability.
What is frequently forgotten is that today’s complex products or services are the result of countless conversations, discussions and decisions made. These countless micro decisions need to be tracked, filtered and visualized as well. The environment described here is one with high-speed decision making, beyond status meeting and jour fixes.
At the same time, our customers demand citius, altius, forties – we need to deliver better products faster, which is the promise of Agile methodologies. Is the incremental and iterative approach in Agile methodologies compatible with Requirements Engineering, where we need sign-offs, baselines and design freezes?
Assuming Agile methodologies are the solution to leaner and faster decision making: Which leadership style best supports a high-speed dynamic decision making? Which group structures or project types require which leadership style, to avoid chaos?
This paper is a field report, based on the author’s leading a transition towards sociocratic organization while at the same time working as product owner for client projects.

Was lernen die Zuhörer in dem Vortrag?

Which leadership style best supports a high-speed dynamic decision making and why? Which group structures or project types require which leadership style, to avoid chaos?

Martin Brüggemann
Martin Brüggemann

Martin Brüggemann hat Informatik und Kommunikationswissenschaften in Berlin, Potsdam und Aachen studiert. Seine Ausbildung an der Schnittstelle zwischen...

45 Minuten Vortrag

Fortgeschritten
Zeit

15:40-16:25
10. Oktober


Zielgruppe

Führungskräfte, Scrum Master, Product Owner


Themengebiet

Rollen im agilen Anforderungsmanagement


Raum

tba


ID

Do2.5

Techniken zum Managen von Abhängigkeiten

In grossen wie in kleinen Projekten tauchen Abhängigkeiten auf. In vielen Fällen lassen sich diese Abhängigkeiten geschickt umgehen oder sogar gut managen. Wir betrachten dabei verschiedene Ebenen: Innerhalb eines Teams, zwischen Teams, Abhängigkeiten zu Stakeholdern sowie selbstgemachte Abhängigkeiten, die bis in die softwareseitige Architektur hineinreichen. Der Vortrag liefert Impulse und Ideen, wie du Abhängigkeiten identifizieren und diese lösen kannst - auch ohne Skalierungs-Framework.

Was lernen die Zuhörer in dem Vortrag?

  • Umgang mit Abhängigkeiten auf unterschiedlichen Ebenen
  • Lernen von Techniken, damit umzugehen
  • Und damit bessere Produkte schneller zu liefern
Björn Schotte
Björn Schotte

Björn Schotte ist Geschäftsführer und Executive Consultant der MAYFLOWER GmbH. Er berät Kunden in Fragen der Digitalen und Agilen Transformation. Die...

45 Minuten Vortrag

Fortgeschritten
Zeit

15:40-16:25
10. Oktober


Zielgruppe

Product Owner, Requirements Engineers, Projektleiter


Themengebiet

Techniken


Raum

tba


ID

Do3.5

Unser direkter Umweg zum Requirements Engineering

Am Anfang stand das Scheitern des Requirements Engineering. "Zu komplex - wir müssen agil vorgehen."

Vier Jahre und viele Retrospektiven später haben wir das RE richtig in unser agiles Vorgehen eingebaut. Vielleicht. Denn, dass wir es richtig machen, glaubten wir schon oft. Und mit jedem Mal stieg die Überzeugung in das gewählte Vorgehen.

Auf unserem Weg haben wir für viele Fragen eigene Antworten gefunden. Brauchen wir RE als eigenen Schritt vor dem "agilen Prozess"? Sind Stories unsere Requirements? Testen wir gegen Stories? Tragen wir die Anforderungen aus den Stories im Nachhinein zusammen? Wer macht das? Der Tester? Der Entwickler? Der Product Owner? Wo ist eigentlich der Requirements Engineer?

Am (vorläufigen) Ende unserer Odyssee wissen wir: Ursprünglich ist nicht unser Requirements Engineering im eigentlichen, d.h. handwerklichen Sinne gescheitert. Wir haben es nur nicht geeignet mit dem agilen Vorgehen verbunden. Und wir haben gelernt: Manchmal sind Umwege die kürzeste Verbindung zum Ziel.

Was lernen die Zuhörer in dem Vortrag?

    Eine mögliche Antwort auf die Frage, "Wie sollen wir das Requirements Engineering mit dem agilen Vorgehen zusammenführen?", und der Weg zur Antwort.
Stefan Mintert
Stefan Mintert

Stefan Mintert macht aus guten Teams sehr gute Teams, hilft Unternehmen dabei ihr Business und Management agil zu gestalten und begleitet sie auf dem Weg von...

45 Minuten Vortrag

Einsteiger
Zeit

16:35-17:20
10. Oktober


Zielgruppe

Product Owner, Tester, Entwickler, die eine Idee brauchen, wie sie RE in ihre (jungen) agile Vorgehensweise einbauen


Themengebiet

Erfahrungsbericht


Raum

tba


ID

Do1.6

Wie Teams wirklich stark werden

Die Erstellung von Software im einsamen Keller gehört der Vergangenheit an. Heutzutage ist Software so komplex geworden, dass sie in größeren Teams entwickelt werden muss. Doch wie schaffen wir es die zusammengewürfelten Teams zu Hochleistungsteams zu formen? Hochleistungsteams sind bunt und interdisziplinär aufgestellt. Die Teammitglieder, egal ob Anforderungsanalyst, Entwickler oder Tester ergänzen sich gegenseitig und pflegen kontinuierlich ihre Teamkultur. Dies ist elementar für eine erfolgreiche Anwendung.

Lassen Sie sich von uns inspirieren, wie Sie Ihr Team anhand von einfachen, lösungsorientierten Fragen reflektieren und voranbringen. In einem interaktiv-kreativen Vortrag erarbeiten wir gemeinsam die grundlegenden Bausteine, die ein erfolgreiches Team auszeichnet und kritische Themen, mit denen sich auch ein Spitzenteam auseinandersetzen muss. Sie haben Lust darauf Dinge aktiv anzupacken? Dann sind Sie in unserem Vortrag genau richtig. Lernen Sie ein einfach handhabbares Teamcoaching-Werkzeug kennen und profitieren Sie von unserem anschaulichen Erfahrungsbericht aus der Praxis!

Was lernen die Zuhörer in dem Vortrag?

Die Zuhörer lernen

  • Was gute Teams auszeichnet
  • Anhand von welchen Kriterien, die Teamkultur verbessert werden kann
  • Fragen kennen, die im Rahmen von Retrospektiven verwendet werden können, um ein Team kontinuierlich zu verbessern
Monika Schubert
Monika Schubert

Monika Schubert ist für die IT-Beratung OPITZ CONSULTING tätig. Neben ihrer Projekttätigkeit treibt sie als Leiterin des Kompetenzteam Anforderungs- und...


Manuel Juschkewitz
Manuel Juschkewitz

Manuel Juschkewitz...

45 Minuten Vortrag

Einsteiger
Zeit

16:35-17:20
10. Oktober


Zielgruppe

Scrum Master, Teamleiter und alle, die ihr Team voranbringen wollen


Themengebiet

Rollen im agilen Anforderungsmanagement


Raum

tba


ID

Do2.6

Doppeltes Lottchen im agilen Projekt

In Unternehmen gibt es oft mehrere Wissensträger, die nur gemeinschaftlich die Gesamtsicht auf eine Produktanforderung haben. Im agilen Team wird daher die Rolle des Product Owners oft mehrfach besetzt. Eine Variante ist dabei die Trennung in den "fachlichen" und den "technischen PO".
Solche Konstellationen führen jedoch schnell zu Unklarheiten, bei Absprachen und zwischen den Mitgliedern eines solchen PO-Teams. Im Rahmen unterschiedlicher Projekte mit diesem Ansatz, standen wir immer wieder vor der Herausforderung die Transparenz des Arbeitsprozesses zu erhöhen und gleichzeitig Abstimmungs- und Kommunikationsaufwand zu reduzieren. Dieser Vortrag schildert unserer Erfahrungen im Umgang mit diesen Herausforderungen, anhand eines konkreten Projekts in der Versicherungsbranche.

Was lernen die Zuhörer in dem Vortrag?

Besucher erhalten einige bewährte Praktiken an die Hand, um im PO-Team effektiver zu arbeiten, Stress und Unklarheiten zu reduzieren und damit nachhaltige Veränderung im Unternehmen zu gestalten. Der Vortrag zeigt auch auf, wie ein PO-Team zu einem wichtigen Schritt hin zum agilen Unternehmen werden kann und wie diese Erkenntnisse auch auf die Zusammenarbeit in anderen Teams angewandt werden können.

Ingo Sobik
Ingo Sobik

Als Consultant und Agile Coach unterstützt Ingo Sobik für die esentri AG Kunden bei ihrem digitalen Wandeln. Dabei versteht er es als Digital Native...

45 Minuten Vortrag

Fortgeschritten
Zeit

16:35-17:20
10. Oktober


Zielgruppe

Product Owner Teams, Coaches, Scrum Master, Requirements Manager, Business Analysten


Themengebiet

Techniken im agilen Anforderungsmanagement


Raum

tba


ID

Do3.6

Copyright © 2019 HLMC Events GmbH