agile business intelligence in der praxis - scrum im dwh-umfeld
DESCRIPTION
http://www.opitz-consulting.com/go/3-2-911 Eignet sich Scrum als Projektmanagementmethode im BI-/Data-Warehouse-Umfeld? Und welche Bedingungen sollte ein Scrum-Team erfüllen? Andreas Ballenthin berichtete bei der DOAG Konferenz 2012 in Nürnberg von seinen Erfahrungen mit einem agilen Vorgehen bei der Implementierung eines unternehmensweiten DWH in einem Kundenprojekt bei Congstar. Andreas Ballenthin ist Solution Architect bei OPITZ CONSULTING und Experte für Oracle Business Intelligence. Über uns: Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen. Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10 Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874 Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5TRANSCRIPT
© 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
© OPITZ CONSULTING GmbH 2012 Seite 2Agile BI in der Praxis
Agenda
1.Vorstellung OPITZ CONSULTING
2. Scrum als Projektmanagementmethode &
das Scrum-Team
3. Herausforderungen im DWH/BI-Umfeld
4. Praktische Erfahrungen
im Kundenprojekt
© OPITZ CONSULTING GmbH 2012 Seite 3Agile BI in der Praxis
1 Vorstellung OPITZ CONSULTING
© OPITZ CONSULTING GmbH 2012 Seite 4Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 5Agile BI in der Praxis
2 Scrum als Projektmanagement-methode & das Scrum-Team
© OPITZ CONSULTING GmbH 2012 Seite 6Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 7Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 8Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 9Agile BI in der Praxis
3 Typische Herausforderungen im DWH/BI-Umfeld
© OPITZ CONSULTING GmbH 2012 Seite 10Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 11Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 12Agile BI in der Praxis
Das magische Dreieck gilt trotzdem!
Qualität
Ressourcen (Budget, Team)
fix fix
Umfang (Funktionalität, Features)
geschätztlaufend
angepasst
Zeit (Termine)
© OPITZ CONSULTING GmbH 2012 Seite 13Agile BI in der Praxis
4 Praktische Erfahrungen im Kundenprojekt
© OPITZ CONSULTING GmbH 2012 Seite 14Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 15Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 16Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 17Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 18Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 19Agile BI in der Praxis
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>“
© OPITZ CONSULTING GmbH 2012 Seite 20Agile BI in der Praxis
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
♥
© OPITZ CONSULTING GmbH 2012 Seite 21Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 22Agile BI in der Praxis
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.
© OPITZ CONSULTING GmbH 2012 Seite 23Agile BI in der Praxis
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…)
DB-Schema(DWH_SA…)
Mindestens täglich Pro Release Pro Release
Schema-verwaltungs-
package
Schema-verwaltungs-
package
DB-Schema(DWH_SA…)
DB-Schema(DWH_SA…)
Objekt-skripte
deltarelevante Objektskripte
© OPITZ CONSULTING GmbH 2012 Seite 24Agile BI in der Praxis
Automatisiertes Deployment – Informatica
Entwicklung Test Abnahme Produktion
pmrep ObjectExport
pmprepObjectImport
InformaticaClient
Informatica Repository
Informatica Repository
Mindestens täglich Pro Release Pro Release
pmprepObjectImport
pmprepObjectImport
Informatica Repository
Informatica Repository
Objektlistepmrep ExecuteQuery
Subversion
© OPITZ CONSULTING GmbH 2012 Seite 25Agile BI in der Praxis
Automatisiertes Deployment – BusinessObjects
Entwicklung Test Abnahme Produktion
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
lcm.jaraction=promote
lcm.jaraction=promote
BO Repository
BO Repository
Release-Nummer am Objekt
Subversion
© OPITZ CONSULTING GmbH 2012 Seite 26Agile BI in der Praxis
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!
© OPITZ CONSULTING GmbH 2012 Seite 27Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 28Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 29Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 30Agile BI in der Praxis
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.
• .
© OPITZ CONSULTING GmbH 2012 Seite 31Agile BI in der Praxis
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
© OPITZ CONSULTING GmbH 2012 Seite 32Agile BI in der Praxis
Kontakt
Andreas Ballenthin
OPITZ CONSULTING Deutschland GmbH
+49 2261 6001 0