Agile BI in der Praxis

Transkript

1 Warum SCRUM im DWH-Umfeld funktioniert Andreas Ballenthin Solution Architect OPITZ CONSULTING Deutschland GmbH DOAG-Konferenz Nürnberg, OPITZ CONSULTING GmbH 2012 Seite 1

2 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 2

3 1 Vorstellung OPITZ CONSULTING OPITZ CONSULTING GmbH 2012 Seite 3

4 Mission Wir 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. Leistungsangebot Business IT Alignment Business Information Management Business Process Management Anwendungsentwicklung SOA und System-Integration IT-Infrastruktur-Management Märkte Branchenübergreifend Über 600 Kunden 29% Industrie / Versorger / Telekommunikation Eckdaten Gründung Mitarbeiter 8 Standorte 29% Handel / Logistik / Dienstleistungen 42% Öffentliche Auftraggeber / Banken und Versicherungen / Vereine und Verbände OPITZ CONSULTING GmbH 2012 Seite 4

5 2 Scrum als Projektmanagementmethode & das Scrum-Team OPITZ CONSULTING GmbH 2012 Seite 5

6 Was macht Scrum aus? Individuen und Interaktionen Funktionierende Software Mut und die Offenheit für Änderungen Stetige Zusammenarbeit mit dem Kunden Prozesse und Werkzeuge umfassende Dokumentation Befolgen eines festgelegten Plans Verträge Wir schätzen die Punkte auf der rechten Seite, aber wir bewerten die Punkte auf der linken Seite höher. OPITZ CONSULTING GmbH 2012 Seite 6

7 Rollen / Besonderheiten in Scrum Nur drei Rollen im Team SM PO T Anzahl Personen im Team begrenzt (7 ± 2) Das Team besteht aus Generalisten, nicht aus Spezialisten Entwicklungsteam ist für die Ergebnisse verantwortlich, nie ein Einzelner Das Team ist insgesamt eigenverantwortlich und selbstorganisiert Eigenverantwortung fördert Motivation OPITZ CONSULTING GmbH 2012 Seite 7

8 Scrum-Workflow im Überblick Product Backlog PO Daily Scrum Burndown Chart Sprintziel PO T Sprint Backlog T Sprint (1-4 Wochen) T SM SM Sprint Planning Meeting (Planning I, Planning II) PO T? T Auslieferbares Inkrement Sprint Review SM SM Sprint Retrospective OPITZ CONSULTING GmbH 2012 Seite 8

9 3 Typische Herausforderungen im DWH/BI- Umfeld OPITZ CONSULTING GmbH 2012 Seite 9

10 SWOT Analyse Agile BI (S)Trengths - Stärken Schnelle Lieferung Richtige Umsetzung der Anforderung Schnelle Reaktion auf veränderte Anforderungen Risiken werden minimiert (W)eaknesses - Schwächen Langfristige Ergebnisse schwieriger planbar Keine Festpreise/Werkverträge SLA kompliziert Einsatz verteilter Teams schwierig (O)pportunities - Chancen Kundenzufriedenheit wird gesteigert Schlechter Ruf der unflexiblen DWH- Lösungen wird abgebaut Spaß im Projektteam durch neues Vorgehen wird gefördert (T)hreats - Risiken Das Team spielt nicht mit Der Auftraggeber/Fachbereich lässt sich nicht ausreichend involvieren DWH/Datenmodell wird unnötig komplex OPITZ CONSULTING GmbH 2012 Seite 10

11 Wir nutzen Scrum, um das Risiko zu minimieren! DWH/BI Projekte - klassisch DWH/BI Projekte - agil 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 11

12 Das magische Dreieck gilt trotzdem! fix Ressourcen (Budget, Team) Zeit (Termine) Qualität Umfang (Funktionalität, Features) laufend angepasst geschätzt OPITZ CONSULTING GmbH 2012 Seite 12

13 4 Praktische Erfahrungen im Kundenprojekt OPITZ CONSULTING GmbH 2012 Seite 13

14 Zu Beginn bestand das Team aus Spezialisten Architektur PO+SM Kenntnis des Kunden Agile BI Informatica Business Objects IT-Analyst Tester Architekt ETL-Entwickler BO-Entwickler Erfahrung Testen OPITZ CONSULTING GmbH 2012 Seite 14

15 OPITZ CONSULTING GmbH 2012 Seite 15 Kopfmonopole und Truck Factor B O W F A T J J B O W F A T J J B O W F A T J J Extreme Generalisten TF 2 Extreme Spezialisten TF = 1 Ausgewogen TF > 2 Verbreiterung notwendig! TF = 2 B O W F A T J J

16 Heute besteht das Team aus Generalisten Architektur PO+SM Kenntnis des Kunden Agile BI Informatica Business Objects IT-Analyst Tester Architekt ETL-Entwickler BO-Entwickler Erfahrung Testen OPITZ CONSULTING GmbH 2012 Seite 16

17 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 17

18 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 18

19 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 19

20 Storyschnitt (II) Eigenschaften guter User Stories Sicht des Benutzers oder Kunden Wertvoll - Greifbarer Mehrwert oder Bedeutung Sprache der Anwendungsdomäne Ohne Lösungsvorgabe, nur fachliche Anforderung Abschließbar Unabhängig Schätzbar 8 Klein Testbar 1 13 MuSCoW Must Have Should Have Could Have Won t have this time OPITZ CONSULTING GmbH 2012 Seite 20

21 Stories werden fachlich geschnitten Frontend Data Mart Core Staging Quellen Vorher: POC Story 1: Dimensionen 1&2 AdHoc-Reporting Vertragsebene Story 2: Dimensionen 1-4 AdHoc-Reporting Vertragsebene & Aggregationen Story 3: Alle 6 Dimensionen AdHoc-Reporting und Standardreport Vertragsebene & Aggregationen Jede Story muss einen fachlichen Mehrwert erbringen OPITZ CONSULTING GmbH 2012 Seite 21

22 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 22

23 Automatisiertes Deployment DDL, DCL, Datenmigrationen Entwicklung Test Abnahme Produktion DB-Schema (DWH_SA ) DB-Schema (DWH_SA ) DB-Schema (DWH_SA ) DB-Schema (DWH_SA ) Schemaverwaltung Schemaverwaltungspackage Objektskripte Schemaverwaltungspackage Schemaverwaltungspackage Schemaverwaltungspackage Schemaverwaltungssteuertabellen Schemaverwaltung (Ant-Scripte, Subversion) deltarelevante Objektskripte Mindestens täglich Pro Release Pro Release OPITZ CONSULTING GmbH 2012 Seite 23

24 Automatisiertes Deployment Informatica Entwicklung Test Abnahme Produktion Informatica Client Informatica Repository Informatica Repository Informatica Repository Informatica Repository Objektliste pmrep ExecuteQuery pmrep ObjectExport pmprep ObjectImport pmprep ObjectImport pmprep ObjectImport Subversion Mindestens täglich Pro Release Pro Release OPITZ CONSULTING GmbH 2012 Seite 24

25 Automatisiertes Deployment Business Objects Entwicklung Test Abnahme Produktion BO Client BO Webtier BO Repository BO Repository BO Repository BO Repository Release-Nummer am Objekt Subversion lcm.jar action=export ExportQuery ci_infoobjects über Release- Nummer lcm.jar action= promote lcm.jar action= promote lcm.jar action= promote Mindestens täglich Pro Sprint Pro Release OPITZ CONSULTING GmbH 2012 Seite 25

26 Anzahl Funktionalitäten Automatisierte Tests sind Pflicht! S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 Sprint Alte Funktionalitäten (Regressionstests) Neue Funktionalitäten Aufwand für Regressionstests steigt stetig Testabdeckung darf nicht Zufall überlassen bleiben Testautomatisierung ist Pflicht! OPITZ CONSULTING GmbH 2012 Seite 26

27 Automatisierte Backendtests Deployment DDLs Deployment Informatica Baseline (Sprint -1) Leeren DWH- Schemata Import Baseline Automatisiertes Deployment ist notwendige Vorbedingung Die Testsysteme müssen vom Sprintteam verantwortet werden Es muss zum Ende eines Sprints einen konsistenten, produktionsnahen Aufsatzpunkt geben OPITZ CONSULTING GmbH 2012 Seite 27

28 Automatisierte Backendtests Deployment DDL, Informatica 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 OPITZ CONSULTING GmbH 2012 Seite 28

29 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 29

30 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 30

31 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 31

32 Kontakt Andreas Ballenthin OPITZ CONSULTING Deutschland GmbH OPITZ CONSULTING GmbH 2012 Seite 32