Peter Scheurig 17. April 2013 - doag.org · PDF fileOracle BI Server DAC Oracle Business...

© 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


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


Inhalt


2 Überblick Scrum



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


Agiles Manifest


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.


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.


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


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


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


Inhalt


2 Überblick Scrum



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


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.


eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertriebsmitarbeiter


Rel

ease

1R

elea

se x

Rel

ease

n

Priorität

Wer?

Was?

Warum? = Wert


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


eine Liste mit Wert und Gewinnwahrscheinlichkeit der neuen Angebote pro Vertiebsmitarbeiter











INVEST Test(nach Bill Wake)

� Independent� Negotiable� Valuable� Estimable� Small� Testable

























Kontinuierliche Verfeinerung der User Stories als Teil des Backlog Grooming

Reports / Analysen







Unternehmen &Geschäftsmodell

� Markt� Geschäftsprozesse� Kultur

� Rollen� Sicherheit

� Struktur� Vollständigkeit� Qualität

Datenquelle(n)

Benutzer

Analyse

� Bestehende� Neue


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


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



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



Physical Layer

Business Layer

Presentation LayerKatalog Objekte

anpassen / erstellenKatalog Objekte

anpassen / erstellen



Sprint 1

Sprint 1

Sprint 2

Sprint 3


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


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

��


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)


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


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)

��


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


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


Kontakt

Office: Mobile: Email:

Peter ScheurigSenior Managing ConsultantOracle Service Line

IBM GBSMünchen, Deutschland +49 175 432 7787 [email protected]

Peter Scheurig 17. April 2013 - doag.org · PDF fileOracle BI Server DAC Oracle Business...

Documents

Transcript of Peter Scheurig 17. April 2013 - doag.org · PDF fileOracle BI Server DAC Oracle Business...