Agile Business Intelligence in der Praxis - Scrum im DWH-Umfeld

© OPITZ CONSULTING GmbH 2012 Seite 1Agile BI in der Praxis

Warum SCRUM im DWH-Umfeld funktioniert

Agile BI in der Praxis

Andreas Ballenthin

Solution Architect

OPITZ CONSULTING Deutschland GmbH

DOAG-Konferenz

Nürnberg, 21.11.2012


Agenda

1.Vorstellung OPITZ CONSULTING

2. Scrum als Projektmanagementmethode &

das Scrum-Team

3. Herausforderungen im DWH/BI-Umfeld

4. Praktische Erfahrungen

im Kundenprojekt


1 Vorstellung OPITZ CONSULTING


MissionWir entwickeln gemeinsam mit allen Branchen Lösungen, die dazu führen, dass sich diese Organisationen besser entwickeln als ihr Wettbewerb.

Unsere Dienstleistung erfolgt partnerschaftlich und ist auf eine langjährige Zusammenarbeit angelegt.

LeistungsangebotBusiness IT AlignmentBusiness Information ManagementBusiness Process ManagementAnwendungsentwicklungSOA und System-Integration IT-Infrastruktur-Management

MärkteBranchenübergreifendÜber 600 Kunden

29%Industrie / Versorger /

Telekommunikation

29%Handel / Logistik / Dienstleistungen

42% Öffentliche Auftraggeber / Banken und Versicherungen / Vereine und Verbände

EckdatenGründung 1990 400 Mitarbeiter8 Standorte


2 Scrum als Projektmanagement-methode & das Scrum-Team


Was macht Scrum aus?

Wir schätzen die Punkte auf der rechten Seite, aber wir bewerten die Punkte auf der linken Seite höher.

Individuen und Interaktionen

Funktionierende Software

Mut und die Offenheit für Änderungen

Stetige Zusammen-arbeit mit dem Kunden

Prozesse und Werkzeuge

umfassende Dokumentation

Befolgen eines festgelegten Plans

Verträge


Nur drei Rollen im Team

Rollen / Besonderheiten in Scrum

SM PO T

Anzahl Personen im Team begrenzt (7 ± 2)

Das Team ist insgesamt eigenverantwortlich und selbstorganisiert

Entwicklungsteam ist für die Ergebnisse verantwortlich, nie ein Einzelner

Das Team besteht aus Generalisten, nicht aus Spezialisten

Eigenverantwortung fördert Motivation


Scrum-Workflow im Überblick

Product Backlog

Sprintziel Sprint Backlog

PO

PO

T T

Sprint(1-4 Wochen)

Burndown Chart

T

SM

SM

Sprint Planning Meeting(Planning I, Planning II)

Sprint Review

PO

T

SM

T

SM

?

Sprint Retrospective

Auslieferbares Inkrement

Daily Scrum


3 Typische Herausforderungen im DWH/BI-Umfeld


SWOT Analyse Agile BI

• Das Team „spielt nicht mit“

• Der Auftraggeber/Fachbereich lässt sich nicht ausreichend involvieren

• DWH/Datenmodell wird unnötig komplex

• Kundenzufriedenheit wird gesteigert

• Schlechter Ruf der unflexiblen DWH-Lösungen wird abgebaut

• Spaß im Projektteam durch neues Vorgehen wird gefördert

• Schnelle Lieferung

• Richtige Umsetzung der Anforderung

• Schnelle Reaktion auf veränderte Anforderungen

• Risiken werden minimiert

• Langfristige Ergebnisse schwieriger planbar

• Keine Festpreise/Werkverträge

• SLA kompliziert

• Einsatz verteilter Teams schwierig

(S)Trengths - Stärken (W)eaknesses - Schwächen

(O)pportunities - Chancen (T)hreats - Risiken


DWH/BI Projekte - klassisch DWH/BI Projekte - agil

Wir nutzen Scrum, um das Risiko zu minimieren!

Werden langwierig geplant

Dauern zu lange

Liefern am Ende doch nicht den nötigen

Mehrwert

Sind am Ende zu starr und zu unflexibel

Kundenfeedback erfolgt erst nach langen

Zyklen

Werden nur von wenigen Personen

genutzt

Projekte sind lange intransparent

Langwierige Planung entfällt

Releasezyklen werden kürzer

Ergebnisse entsprechen den

Anforderung des Kunden

Gehen direkt auf Kundenbedürfnisse ein

Kundenfeedback erfolgt unmittelbar

Werden vielfältiger und häufiger benutzt

Projekte werden transparent


Das magische Dreieck gilt trotzdem!

Qualität

Ressourcen (Budget, Team)

fix fix

Umfang (Funktionalität, Features)

geschätztlaufend

angepasst

Zeit (Termine)


4 Praktische Erfahrungen im Kundenprojekt


Architektur

Informatica

Business Objects

TestenErfahrung

Agile BI

Kenntnis des Kunden

PO+SM

IT-Analyst

Tester

Architekt

ETL-Entwickler

BO-Entwickler

Zu Beginn bestand das Team aus Spezialisten


Kopfmonopole und „Truck Factor“

B

O

W

F

A

T J

JB

O

W

F

A

T J

J

B

O

W

F

A

T J

J

Extreme Generalisten ≙ TF ≫ 2Extreme Spezialisten ≙ TF = 1

Ausgewogen ≙ TF > 2Verbreiterung notwendig! ≙ TF = 2

B

O

W

F

A

T J

J


Architektur

Informatica

Business Objects

TestenErfahrung

Agile BI

Kenntnis des Kunden

PO+SM

IT-Analyst

Tester

Architekt

ETL-Entwickler

BO-Entwickler

Heute besteht das Team aus Generalisten


Pair Design / Pair Programming

Qualität der Software wird verbessert

Fehler werden früh erkannt

Mehr Spaß an der Arbeit

Wissen verbreitet sich im gesamten Team

Kommunikation im Team verbessert sich

Design- und Entwicklungskosten erhöhen sich minimal

Fehler sind umso teurer, je später sie entdeckt werden.Die Folgekosten übersteigen i. d. R. die leicht höheren Design- und Entwicklungskosten


Definition of Done - Wann ist fertig fertig?

Akzeptanzkriterien erfüllt

Notwendige Tests erfolgreich

Notwendige Doku erstellt

Betriebliche Anforderungen erfüllt

Software auf Integrationsumgebung eingespielt, technisch lauffähig, rollbackfähig

Review durch PO erfolgt

Ziel ist immer ein funktionierendes, auslieferungsfähiges Inkrement


Storyschnitt

Jede Story muss einen fachlichen Mehrwert erbringen.Technische Storyschnitte haben sich nicht bewährt

Die Summe aller User Stories ist das, was sich unsere Anwender von jener Lösung erwarten, die wir Entwickler für sie umsetzen sollen.

User Stories enthalten funktionale Anforderungen nicht-funktionale Anforderungen Rahmenbedingungen

Es ist anfangs schwierig, wirkliche User Stories zu schreiben„Als <Benutzerrolle> möchte ich <Ziel/Wunsch>, um <Nutzen>“


Storyschnitt (II)

Eigenschaften guter User Stories Sicht des Benutzers oder Kunden Wertvoll - Greifbarer Mehrwert oder

Bedeutung Sprache der Anwendungs-

domäne Ohne Lösungsvorgabe,

nur fachliche Anforderung Abschließbar Unabhängig Schätzbar Klein Testbar

MuSCoW Must Have Should Have Could Have Won‘t have this time

2

♥

3

♥

5

♥

8

♥

13

♥

1

♣

40

♣

100

♣

20

♥


Stories werden fachlich geschnitten

Quellen

Staging

Core

Data Mart

Frontend

Story 1:Dimensionen 1&2AdHoc-ReportingVertragsebene

Story 2:Dimensionen 1-4AdHoc-ReportingVertragsebene & Aggregationen

Story 3:Alle 6 DimensionenAdHoc-Reporting und StandardreportVertragsebene & Aggregationen

Jede Story muss einen fachlichen Mehrwert erbringen

Vor-her:POC


Automatisiertes Deployment & Automatisierte Tests

Wir sind faul und oft nicht faul genug.

These: Ein guter Software-Entwickler, Tester oder Administrator sollte von Natur aus faul sein, je fauler, desto besser.

Wer faul ist, erledigt ungern monotone, langweilige, sich ständig wiederholende, fehleranfällige Aufgaben.

Wer faul ist, investiert Zeit in einen möglichst hohen Automatisierungsgrad für Build, Test und Deployment.


Schema-verwaltung

Automatisiertes Deployment – DDL, DCL, Datenmigrationen

Entwicklung Test Abnahme Produktion

Schema-verwaltung

(Ant-Scripte, Subversion)

Schema-verwaltungs-

package

Schema-verwaltungs-

package

Schema-verwaltungs-

steuertabellen

DB-Schema(DWH_SA…)


Mindestens täglich Pro Release Pro Release

Schema-verwaltungs-

package

Schema-verwaltungs-

package



Objekt-skripte

deltarelevante Objektskripte


Automatisiertes Deployment – Informatica


pmrep ObjectExport

pmprepObjectImport

InformaticaClient

Informatica Repository


Mindestens täglich Pro Release Pro Release

pmprepObjectImport

pmprepObjectImport



Objektlistepmrep ExecuteQuery

Subversion


Automatisiertes Deployment – BusinessObjects


lcm.jaraction=export ExportQuery

ci_infoobjects über Release-

Nummer

lcm.jaraction=promote

BO ClientBO Webtier

BO Repository

BO Repository

Mindestens täglich Pro Sprint Pro Release



BO Repository

BO Repository

Release-Nummer am Objekt

Subversion


Automatisierte Tests sind Pflicht!

S1 S2 S3 S4 S5 S6 S7 S8 S9 S1005

101520253035404550

Alte Funktionalitäten (Regressionstests)Neue Funktionalitäten

Sprint

An

zah

l F

un

ktio

nal

ität

en

Aufwand für Regressionstests steigt stetigTestabdeckung darf nicht Zufall überlassen bleibenTestautomatisierung ist Pflicht!


Automatisierte Backendtests

Deployment DDLs

Deployment Informatica

Automatisiertes Deployment ist notwendige Vorbedingung

Baseline(Sprint -1)

Leeren DWH-Schemata

Import Baseline

Die Testsysteme müssen vom Sprintteam verantwortet werden

Es muss zum Ende eines Sprints einen konsistenten, produktionsnahen Aufsatzpunkt geben


Automatisierte Backendtests

Fullload/Deltaload Vertragssystem

Fullload/Deltaload Umsätze

Fileschnittstellentests

Negativtests / Rollback Negativtests

Ausführung Test-SQLs

Protokollierung

Nächtliche Testläufe

Es wird täglich konfiguriert, welche Test(gruppen) durchlaufen werden

Codestände werden komplett vertestet

Testergebnisse liegen morgens vor, Fehler werden tagsüber behoben

Deployment DDL, Informatica


Werkzeugpalette einfach halten

Testsuite läuft auf Windows-Server

Windows-Aufgabenplanung als Scheduler

Oracle-Bordmittel Data Pump SQL*Plus für SQL-Scripte Polling auf Statusänderungen

Batchfiles

WinSCP zur Kommunikation Windows Linux


Wichtige Artefakte immer vor Augen haben

Eine Aufgabe übernehmen wird sicht- und erlebbar!

Haptik statt Mausklick - man hat die Sache jetzt wahrlich „in die Hand genommen“. Damit entsteht fast von selbst ein gewisses Maß an Verpflichtung und Verbindlichkeit.

• .


Unsere Botschaft

Scrum im DWH/BI-Umfeld funktioniert tatsächlich

Automatisiertes Deployment und automatisierte Tests müssen etabliert werden

Es ist schwierig, das Entwicklungsteam durch den PO „abzuschirmen“.

Es ist notwendig, dass das Team räumlich beieinander sitzt!

Wichtige Artefakte immer vor Augen haben

Generalisten statt Spezialisten

Nicht sklavisch das Sprintbacklog betrachten

Pair Design und Pair Programming sind wertvoll und notwendig


Kontakt

Andreas Ballenthin

OPITZ CONSULTING Deutschland GmbH

[email protected]

+49 2261 6001 0

Agile Business Intelligence in der Praxis - Scrum im DWH-Umfeld

Technology

praxis opitz consulting

rechten seite

umfeldagile bi

scrumteamagile bi

vorstellung opitz consulting2

linken seite hher

macht scrum aus

wir nutzen scrum