View
217
Download
4
Category
Preview:
Citation preview
© 2013 IBM Corporation
Oracle BI Applications Implementierung mit Scrum -Ein Erfahrungsbericht
Peter Scheurig
17. April 2013
© 2013 IBM CorporationDOAG 2013 BI
Inhalt
1 Überblick Oracle BI Applications
2 Überblick Scrum
3 Erfahrungen mit Scrum und Oracle BI Applications
© 2013 IBM CorporationDOAG 2013 BI
Inhalt
1 Überblick Oracle BI Applications
2 Überblick Scrum
3 Erfahrungen mit Scrum und Oracle BI Applications
© 2013 IBM CorporationDOAG 2013 BI
Oracle Business Intelligence Applications
Oracle BI Presentation
ServerDashboards & Reports
Semantisches Model Oracle BI Server
DA
C
Oracle Business Analytics Warehouse (OBAW)
� Komplette Data Warehouse / Business Intelligence Lösung mit vorgefertigten analytischen Anwendungen:� Star Schema basiertes Data Warehouse
(Kimball)� ETL-Adapter für Siebel CRM, PeopleSoft,
eBusiness Suite� Rollenspezifische Dashboards und
Analysen
� Technologieplattform� Oracle Business Intelligence Enterprise
Edition (OBIEE) 11g (ab 7.9.6.3)� OEM-Version Informatica PowerCenter� Data Warehouse Administration Console
(DAC)
Mobile
CRM Analytics ERP Analytics
SalesService &
CCMarketing Financials
HumanResources
Supply Chain &Order Mgmt.
und mehr
Financial Services
Insurance & Health
Life Sciences und mehr
AutomotiveCommunications
& MediaConsumer Energy
Industry Analytics
Price Loyalty und mehr Mobile
CRM Analytics ERP Analytics
SalesService &
CCMarketing Financials
HumanResources
Supply Chain &Order Mgmt.
und mehr
Financial Services
Insurance & Health
Life Sciences und mehr
AutomotiveCommunications
& MediaConsumer Energy
Industry Analytics
Price Loyalty und mehr
Info
rmat
ica
Pow
erC
ente
r
© 2013 IBM CorporationDOAG 2013 BI
Inhalt
1 Überblick Oracle BI Applications
2 Überblick Scrum
3 Erfahrungen mit Scrum und Oracle BI Applications
© 2013 IBM CorporationDOAG 2013 BI
Planung ist alles, Pläne sind nichts
�Traditionelle Planung/Entwicklung� Festlegung der gesamten Funktionalität� Schätzung der Kosten und Zeitdauer� Plan enthält alle notwendigen Aktivitäten und
wird sequentiell abgearbeitet� Funktionalität steht erst am Ende zur Verfügung
- Im besten Fall wie zu Beginn festgelegt
�Agile Vorgehensweise� Festlegung von Zeitdauer und Kosten� Iterative Lieferung von so viel Funktionalität wie
möglich und so schnell wie möglich:� Funktionalität mit höchstem Nutzen/Wert zuerst� Nur was wirklich benötigt wird
� Detailentscheidungen werden zum spätest möglichen Zeitpunkt getroffen� Änderungen können berücksichtigt werden
Anforderungen
Analyse
Design
Entwicklung
Test
Einführung?
Funktionalität 1 Funktionalität 2 Funktionalität n
Analyse Design Entwicklung TestAnalyse Design Entwicklung Test
© 2013 IBM CorporationDOAG 2013 BI
Was ist Scrum?
� Agile Vorgehensweise
� Rahmenwerk zur Entwicklung komplexer Produkte
� Basiert auf der Theorie der empirischen Prozesssteuerung� Transparenz: Alle Aspekte des Prozesses welche das Ergebnis
beeinflußen, müssen für diejenigen sichtbar sein, die für das Prozessergebnis verantwortlich sind.
� Inspektion: Der Prozess und die Arbeitsgegenstände sind durch sachkundige Personen ständig zu überprüfen.
� Anpassung: Bei Feststellung einer Abweichung des Prozesses bzw. der Arbeitsergebnisse muss sofort eine entsprechende Anpassung vorgenommen werden.
� Ziel: Reduktion von Komplexität und damit Verbesserung der Vorhersehbarkeit und Risikokontrolle durch einen iterativen, inkrementellen Entwicklungsansatz.
© 2013 IBM CorporationDOAG 2013 BI
Das Scrum FrameworkRollen, Artefakte, Ereignisse
� Scrum strukturiert die Entwicklung in mehrere unmittelbar aufeinanderfolgende Iterationen (Sprints) mit fixer Zeitdauer, üblicherweise 2-4 Wochen.
� Im Sprint Planning Meeting am Anfang eines jeden Sprints wählt das Development Teamaus einer Liste von Anforderungen (Product Backlog) diejenigen aus, zu deren Fertigstellung es sich im Rahmen des Sprints verpflichtet (Sprint Backlog).
� Das Product Backlog ist die Gesamtheit der gewünschten Produktfunktionalitäten und –eigenschaften. Es wird vom Product Owner erstellt und gepflegt. Er ist verantworlich für das Produktergebnis.
� Das Development Team (7 ± 2 Mitglieder) entscheidet eigenständig wie und mit welchen Werkzeugen die Anforderungen umgesetzt werden.
� Der Entwicklungsfortschritt wird täglich im Daily Scrum Meeting besprochen.
� Der Scrum Master ist verantworlich für den Prozessablauf und die Produktivität des Teams.
� Am Ende eines Sprints steht ein fertiges, benutzbares Produktinkrement, welches im Rahmen des Sprint Review Meeting allen Stakeholdern vorgeführt wird.
� Im Sprint Retrospective Meeting analysiert das Team den Entwicklungsprozess und plant Verbesserungen für den nächsten Sprint.
© 2013 IBM CorporationDOAG 2013 BI
Wichtige Instrumente zur Fortschrittskontrolle
�Sprint Burndown Chart� Zeigt den verbleibenden
Arbeitsaufwand je Sprinttag� Erlaubt Rückschlüsse über eine
rechtzeitige Fertigstellung aller Sprinttasks.
�Velocity� Summe der Schätzungen der
fertiggestellten Funktionalitäten eines Sprints
�Task Board� Visualisierung aller Tasks in einem
Sprint� Wird im Daily Scrum Meeting
aktualisiert
Sprint -Tage
Ver
blei
bend
er A
ufw
and
Idealisierte Linie
Aktuelle Schätzung der verbleibenden Arbeit
Burn-down Linie
© 2013 IBM CorporationDOAG 2013 BI
Generischer Scrum Ablauf
RollenProductOwner
Scrum Master
DevelopmentTeam
Produktverbesserung
Prozessverbesserung
24hSprint
(1-4 Wochen)
VisionSprint Review
(max. 4 h)
“Done”
InkrementSprint 1
InkrementSprint 2
InkrementSprint n
Sprint Retrospective(max. 3h)
Daily Scrum Meeting(max. 15 min)
Gestern?Heute?Hindernisse?
Sprint Planning(max. 8h)
Teil 1: Sprint Ziel = Was wird getan?Teil 2: Planung der notwendigen Tasks
Artefakte
ProductBacklog
SprintBacklog
AuslieferbaresProdukt-
inkrement
© 2013 IBM CorporationDOAG 2013 BI
Herausforderungen Agiler BI Projekte
�Mehrstufige komplexe Architektur�Benutzerfunktionalität z.B. Report nicht innerhalb eines Sprints
lieferbar�Hoher initialer Aufwand für den „ersten Report“
�Vielzahl an unterschiedlichen proprietären Tools �Nicht unbedingt geeignet für Test-driven development�Für die Softwareentwicklung verfügbare Tools für Continuous Build,
Deployment und Integration können nicht ohne weiteres verwendet werden
�Team: Spezialisten statt Generalisten�Bottle-necks bei speziellen Aufgaben�Zeitverlust durch Warten und Hand-over
© 2013 IBM CorporationDOAG 2013 BI
Inhalt
1 Überblick Oracle BI Applications
2 Überblick Scrum
3 Erfahrungen mit Scrum und Oracle BI Applications
© 2013 IBM CorporationDOAG 2013 BI
Wichtige Baussteine und Voraussetzungen für den erfolgreichen Einsatz von Scrum
�User Stories & Developer Stories
�Release-Zyklus
�Definition von Done
�Sprint Zero
�Technische Voraussetzungen für Scrum� Automatisierte Tests� Automatisierte Deployments
�Kultureller Wandel
© 2013 IBM CorporationDOAG 2013 BI
User Stories
� Methode für das Management von Anforderungen
� Einfach verständlich für Entwickler und Benutzer
� Platzhalter für eine Funktionalität. Ersetzt nicht die Spezifikation.
� User Stories werden im Lauf der Zeit verfeinert (backlog grooming).
� User Stories sind so zu definieren, dass sie innerhalb eines Sprints umgesetzt werden können.
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertriebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertriebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
Rel
ease
1R
elea
se x
Rel
ease
n
Priorität
Wer?
Was?
Warum? = Wert
© 2013 IBM CorporationDOAG 2013 BI
Scrum macht Analyse und Design nicht überflüssig!
Logisches Daten Modell
� Dimensionen, Dimensions-Hierarchien, Fakttabellen
� Hauptattribute und Kennzahlen
Dashboardkonzept
� Inhalt, nicht layout� Analytische Workflows� Zuordnung zu Benutzerrollen
Sicherheitskonzept� Web Catalog Objekte (Dashboards,
Analysen)� Datensatzebene
Dashboard Design
� Dashboard layout� Report layout� Navigation
Physiches Daten Modell
� Dimensionen, Dimensions-Hierarchien, Fakttabellen
� Alle Attribute und Kennzahlen
ETL� Mappings und Workflows� DAC
Ready for Sprint?
Design Sprint
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertiebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertiebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertiebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertiebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
INVEST Test(nach Bill Wake)
� Independent� Negotiable� Valuable� Estimable� Small� Testable
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertiebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertiebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertiebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertiebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertiebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertiebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertiebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertiebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
Kontinuierliche Verfeinerung der User Stories als Teil des Backlog Grooming
Reports / Analysen
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertiebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
Als Vertriebsleiter möchte ich
eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertiebsmitarbeiter
damit ich sehen kann, ob wir unsere Kapazitäten richtig einsetzen.
Unternehmen &Geschäftsmodell
� Markt� Geschäftsprozesse� Kultur
� Rollen� Sicherheit
� Struktur� Vollständigkeit� Qualität
Datenquelle(n)
Benutzer
Analyse
� Bestehende� Neue
© 2013 IBM CorporationDOAG 2013 BI
Developer Stories als Bindeglied zwischen User Story undEntwicklungsschritt
� Um einen Wert zu bieten, muss sich eine User Story über alle Architektur-Schichten erstrecken. Das ist nicht immer möglich.
� Developer Stories bieten die Möglichkeit der Aufsplittung von zu großen User Stories falls alle sonstigen Möglichkeiten ausgeschöpft sind.
� Jede Developer Story ist so mit einer User Story verbunden, das die Fertigstellung der Developer Story zu der Fertigstellung der User Story beiträgt.
� Wichtig!� Das Konzept muss vom Product Owner verstanden
und akzeptiert werden� INVEST Test gilt auch für Developer Stories� + Developer Stories müssen demonstriert werden
können
User StoryUser Story
Developer
Story
Developer
Story
Physical Layer
Business Layer
Presentation Layer
Physical Layer
Business Layer
Presentation Layer
Physical Layer
Business Layer
Presentation Layer
Physical Layer
Business Layer
Presentation Layer
Physical Layer
Business Layer
Presentation Layer
Physical Layer
Business Layer
Presentation Layer
© 2013 IBM CorporationDOAG 2013 BI
Developer Story
Als Account Manager möchte ich …
Als Account Manager möchte ich …
Datenextraktions-Story
DDLs erstellenDDLs erstellen
ETL anpassen / erstellenETL anpassen / erstellen
DAC anpassenDAC anpassen
Tests erstellenTests erstellen
DokumentationDokumentation
RPDStory
DashboardStory
Katalog Objekte anpassen / erstellen
Katalog Objekte anpassen / erstellen
Tests erstellenTests erstellen
DokumentationDokumentation
User Story(max 1 Release)
Developer Story(max. 1 Sprint)
Development Task(max 0,5-2 Tage)
Präsentation inSprint Demo
� Ad-hoc Analyse� BI Office Plugin
� Dashboard� Report
� OBIEE Direct SQL� SQL-Tool
� OBIEE Direct SQL� SQL-Tool
OBI ApplicationsSchicht
Datenlade-Story
DDLs erstellenDDLs erstellen
ETL anpassen / erstellenETL anpassen / erstellen
DAC anpassenDAC anpassen
Tests erstellenTests erstellen
DokumentationDokumentation
Physical Layer
Business Layer
Presentation LayerKatalog Objekte
anpassen / erstellenKatalog Objekte
anpassen / erstellen
Tests erstellenTests erstellen
DokumentationDokumentation
Sprint 1
Sprint 1
Sprint 2
Sprint 3
© 2013 IBM CorporationDOAG 2013 BI
Releasezyklus
Initiierung
Exploration
Entwicklung
Implem
entierung
Releasezyklus
ReleaseBacklog
… Sprint
PlanungEntwicklung
Demo
Retrospektive
Inkremente
SprintBacklog
� Release Roadmap
� Zusammenstellung des Teams
� Scrum Training� Initiale Planung und Schätzung
� Release Roadmap
� Zusammenstellung des Teams
� Scrum Training� Initiale Planung und Schätzung
� Business Analyse
� Quellsystemanalyse
� Gap-Analyse Daten� Gap-Analyse OBI Apps
� Design (“JEDUF”)
� Business Analyse
� Quellsystemanalyse
� Gap-Analyse Daten� Gap-Analyse OBI Apps
� Design (“JEDUF”)
� Detaildesign
� Entwicklung
� Dokumentation� Unit Test
� IntegrationsTest
� Detaildesign
� Entwicklung
� Dokumentation� Unit Test
� IntegrationsTest
� Benutzer Akzeptanz Test
� Implementierung in Produktionsumgebung
� Schulung
� Benutzer Akzeptanz Test
� Implementierung in Produktionsumgebung
� Schulung
Rn
R2
R1
ProductBacklog
R1
© 2013 IBM CorporationDOAG 2013 BI
Definition von Done
�Wichtigstes Kommunikationsmittel über die Fertigstellung einer User Story
�Wichtig ist nicht die Anzahl der Kriterien, sondern das gemeinsame Verständnis von allen Beteiligten
�Ziel: Kann mit dem nächsten Release ausgeliefert werden
Dokumentation ist erstellt
Alle Akzeptanzkriterien sind erfüllt und durch den Produkt Owner bestätigt
Alle Integrationstest sind erfolgreich durchgeführt
Alle Konfigurationstests sind erfolgreich durchgeführt
Alle Unit Tests sind erfolgreich durchgeführt
Alle Entwicklungs Tasks sind erledigt
Minimum User Story Defininion of Done
������
© 2013 IBM CorporationDOAG 2013 BI
Test Automatisierung
� Je niedriger der Automatisierungsgrad, desto höher die Anzahl der User Stories die am Ende des Sprints nicht “done” sind
� Ziel: Nachts testen, am nächsten Tag aufgetretene Fehler beheben
� “Code Check” - Überprüfung von DAC und Informatica Repository Objekte auf wichtige Konfigurationsmerkmale:� DAC: z.B. Truncate Table Option für Staging Tabellen aktiviert?� Informatica: z.B. Bulk Load Option deaktiviert für Incremental Load Workflows?
� ETL Tests � Initial Load � Delta Load � Daten Migration
� Eingesetzes Tool: FitNesse � OpenSource� Erweiterbar durch eigene sog. Fixtures (Java)
© 2013 IBM CorporationDOAG 2013 BI
Automatisiertes Deployment
� Voraussetzung für automatisiertes Testen
� Identisches Deployment auf alle Umgebungen
� Alle OBI Apps Repository Exporte/Importe sind skriptbar
� “Einfachste Lösung”: � Alle benötigten Artefakte und Repositories
werden in eine Folderstruktur kopiert und darin aufdas Zielsystem transferiert
� Dort starten Skripts dieentsprechenden Kommandozeilen-tools
� Der Deployment Folder ist versioniert (Subversion).
WebCatalog
RPD
Informatica
DAC
Datenbank
Sonst. Files
WLST
WLST
pmrep
IMPORT
SQLPlus
cp
Deployment Folder
Zielsystem
Steuerskript
© 2013 IBM CorporationDOAG 2013 BI
Spezielle Sprints
�Sprint Zero� Unmittelbarer Zeitraum for Sprint 1� Gewährleistet, daß “alles” für den ersten Entwicklungssprint bereit ist
�Performance Optimierung� Aus Erfahrung ist es besser, Code für neue Funktionalität und für
Performance Optimierung nicht zur selben Zeit zu implementieren� Hohe Datenvolumina erlauben kein tägliches Testen von Full- u. Delta Loads
Konfigurationsstandards sind definiert, kommuniziert und verstanden
Konzept für autom. Testen ist erstellt, idealerweise schon umgesetzt
Konzept für autom. Deployment ist erstellt, idealerweise schon umgesetzt
Relevanter Out-of-the-box DAC Execution Plan erfolgreich ausgeführt (technisch)
Benötigte Systeme und Software sind installiert, konfiguriert und getestet
Ausreichende Anzahl fertiger User Stories für Sprint 1, besser 1u.2
Verfügbar vor Sprint 1 (minimum)
������
© 2013 IBM CorporationDOAG 2013 BI
Kultureller Wandel
� Die Arbeit eines jeden wird transparent (Daily Scrum)� Kann als permanenter Druck wahrgenommen werden�Fehler machen ist erlaubt: Fail fast and fix quickly
� Das Team steht im Vordergrund, nicht der einzelne� Geringere Motivation für erfahrene Entwickler od. Team Leads�Neue Motivation durch Wissenserweiterung, Wissensweitergabe im Team
� Bereitschaft zum ständigen Lernen� Erweiterung der Kenntnisse innerhalb der Oracle BI Applications� Neue Tools und Technologien (z.B. Testautomatisierung)
� Die Eigenverantwortlichkeit des Team anerkennen und in die Fähigkeiten des Teams vetrauen
� Bei Problemen nicht in klassisches Mikro-Management zurückfallen
� Teammitglieder auf Änderung vorbereiten � Scrum Training vor Projektbegin für alle involvierten Personen� Begleitung durch erfahrenen Scrum Master / Scrum Developer während der ersten Sprints
© 2013 IBM CorporationDOAG 2013 BI
Fazit
� Die Scrum Regeln sind einfach – die Umsetzung ist es nicht
� Aufgrund der Komplexität und der oft vagen Benutzeranforderungen eignen sich Oracle BI Applications Projekte sehr gut für eine agile Vorgehensweise wie Scrum
� Das OBI Apps ETL-Framework, die vorgefertigten Star Schemas und das BI Repository reduzieren den Anfangsaufwand für ein DWH / BI Projekt erheblich
Recommended