Wie erstelle ich ein Datenmodell in einem agilen Projekt?

1. © OPITZ CONSULTING 2017
Informationsklassifikation:
Öffentlich
 Überraschend mehr Möglichkeiten
© OPITZ CONSULTING 2017
Thimo Fußbroich
Wie erstelle ich ein
Datenmodell in einem
agilen Projekt?

2. © OPITZ CONSULTING 2017
Informationsklassifikation:
ÖffentlichDOAG 2018 Seite 2
Vorstellung
 Thimo Fußbroich
 seit 2009 Entwickler und Berater bei OPITZ CONSULTING
 seit 2014 mit dem Schwerpunkt Oracle DB und APEX

3. © OPITZ CONSULTING 2017
Informationsklassifikation:
ÖffentlichDOAG 2018 Seite 3
Ausgangslage/Motivation
 Immer mehr agile Projekte
 Einführung eines Sprint 0 für Projektsetup
 Meistens werden Anforderungen als User Story beschrieben
 häufig wird nur das UI/UX beschrieben
 Datenmodell kaum oder gar nicht beschrieben
 Neues „Grüne Wiese“-Projekt

4. © OPITZ CONSULTING 2017
Informationsklassifikation:
ÖffentlichDOAG 2018 Seite 4
Vortragsziel
 Projektbericht hinsichtlich der Datenmodellierung
 Hineinnehmen in Überlegungen zur Datenmodellierung in agilen
Projekten
 Aufzeigen der verschiedenen Möglichkeiten in unterschiedlichen
Projektkontexten
 Kriterienkatalog als Entscheidungshilfe/Diskussionsgrundlage

5. © OPITZ CONSULTING 2017
Informationsklassifikation:
ÖffentlichDOAG 2018 Seite 5
Projektbeschreibung
 Kunde stellt bestehenden Geschäftsprozess um
 Bestehende Anwendung und DB soll/kann nicht weiter genutzt werden
 Umfang der Anforderung steht fest und ist projektkritisch
 Über Vorgehen bei Datenmodellierung kann frei entschieden werden
 Anwendung „WabO“
 „Grüne Wiese“-Projekt mit ~100PT Volumen
 Zwei weitere Module mit je ~25PT Volumen
 Oracle 12c und APEX 5.1

6. © OPITZ CONSULTING 2017
Informationsklassifikation:
ÖffentlichDOAG 2018 Seite 6
Die Grundlagen
 Festlegung von grundlegenden Dingen wie Code-Richtlinien, Code-
Versionierung, Ticketpflege etc.
 Gerade auch in agilen Projekten bei evtl. Personalwechsel, kurzen
Projekten und „Kontextwechseln“ wichtig
 Insbesondere wichtig die Code-Richtlinien dauerhaft einzuhalten, um
Code-Mischmasch zu vermeiden und damit Qualität und Produktivität zu
steigern

7. © OPITZ CONSULTING 2017
Informationsklassifikation:
ÖffentlichDOAG 2018 Seite 7
Die Möglichkeiten
 Erste Überlegung: Es gibt zwei Möglichkeiten!
 Möglichkeit 1: Datenmodell wird Sprint für Sprint aufgebaut
 Möglichkeit 2: Datenmodell wird in einem Sprint 0 fertig aufgebaut
Wir wissen aus dem Anforderungsworkshop doch
schon, welche Beziehungen die Tabellen
zueinander brauchen.
Dann müssen wir ja fertig entwickelte Sachen
ständig wieder anpacken und weitere Spalten in
Tabellen anlegen.
Aber wir kennen noch nicht alle Anforderungen
im Detail.
Das ist vertane Zeit sich vorab in alles im Detail
reinzudenken.

8. © OPITZ CONSULTING 2017
Informationsklassifikation:
ÖffentlichDOAG 2018 Seite 8
Möglichkeit 1 – Sprintweise Entwicklung
 Im Sinne vom agilen Vorgehen
 Es wird in jedem Sprint nur das entwickelt was benötigt wird
 Auf der DB nur das entwickelt, was auch in der Oberfläche benötigt wird
 Es kann direkt entwickelt werden und bedarf keiner Vorarbeit
 Datentypen und Co. werden dann bestimmt, wenn die zugehörige
Anforderung auch spezifiziert wird

9. © OPITZ CONSULTING 2017
Informationsklassifikation:
ÖffentlichDOAG 2018 Seite 9
Möglichkeit 2 – Sprint 0
 Robustes Datenmodell kann in einem Zug (vollständig) entwickelt werden
 Abhängigkeiten zwischen Entitäten können von Anfang an sauber gestaltet
werden
 Kein möglicherweise sehr aufwendiges Refactoring notwendig
 Keine Entwicklung von Altlasten/Code Smells
 Wissen aus dem Anforderungsworkshop muss nicht zurückgestellt
werden, weil aktuelle Anforderung evtl. eine Spalte noch nicht benötigt, es
aber sinnvoll wäre sie für später schon anzulegen
 Alle notwendigen Spalten sind vorhanden  Entwickler muss dies nicht
ständig prüfen

10. © OPITZ CONSULTING 2017
Informationsklassifikation:
ÖffentlichDOAG 2018 Seite 10
Umsetzung im Projekt
 Datenmodellierung als Mix aus beiden Möglichkeiten
 Nutzung von Vorteilen beider Möglichkeiten
 Datenmodell wurde größtenteils im Sprint 0 entwickelt
 Zwei größere unspezifizierte und eigenständige Bereiche ausgelassen
 Einige Nice-to-have-Anforderungen ausgelassen (z.B. Tabelle Kommentare)
 Alle beteiligen Entwickler wussten über Ausnahmen Bescheid
 Ansonsten nur wenig Anpassungen von Datentypen erforderlich
 Gründe für gewähltes Vorgehen:
 „Grüne Wiese“-Projekt mit klarem Anforderungsumfang
 Gefühl/Sicherheit der Entwickler wichtig für Produktivität
 Unspezifizierte Bereiche konnten in Sprint 0 nicht umgesetzt werden; waren eigenständig

11. © OPITZ CONSULTING 2017
Informationsklassifikation:
ÖffentlichDOAG 2018 Seite 11
Übertrag in andere Projekte
 Unterschiedliche Projekttypen/-rahmenbedingungen brauchen
unterschiedliches Vorgehen
 Welchen Umfang hat das Projekt?
 Sind die Anforderungen bereits fertig spezifiziert?
 Sind die Anforderungen zusammenhängend oder voneinander losgelöst?
 Welcher Umfang ist projektkritisch? Können Anforderungen auch nur teilweise umgesetzt
werden?
 Wie ist das Projektteam aufgestellt?

12. © OPITZ CONSULTING 2017
Informationsklassifikation:
ÖffentlichDOAG 2018 Seite 12
Übertrag in andere Projekte
Sprintweise Sprint 0
„Grüne Wiese“-Projekt Für weitestgehend unspezifizierter
Anforderungen und Nice-to-have‘s
Für projektkritische und
spezifizierte Anforderungen
Entwicklung neuer Module Eher Nice-to-have’s Eher in einem umzusetzen
Viele kleine voneinander
unabhängige Anforderungen
Sinnvoll Eher weniger sinnvoll

13. © OPITZ CONSULTING 2017
Informationsklassifikation:
Öffentlich Seite 13
Fragen & Antworten
 Kommen Sie zum Stand von OC
(Ebene 2 direkt an der Rolltreppe)
DOAG 2018

14. © OPITZ CONSULTING 2017
Informationsklassifikation:
Öffentlich
 Überraschend mehr Möglichkeiten
@OC_WIRE
OPITZCONSULTING
opitzconsulting
opitz-consulting-bcb8-1009116
WWW.OPITZ-CONSULTING.COM
Seite 14
Vielen Dank für Ihre Aufmerksamkeit
Thimo Fußbroich
Developer
Kirchstraße 6
51647 Gummersbach
Tel: 02261/6001-0
thimo.fussbroich@opitz-consulting.com
DOAG 2018