Flink und Flexibel - Datenbank- und Betriebsoptimierung dank Agilem Projektmanagement

Transkript

1 Flink und Flexibel - Datenbank- und Betriebsoptimierung dank Agilem Projektmanagement DOAG Konferenz , Nürnberg Lars Eisenblatt info@coniatos.com

2 Agenda Einleitung SCRUM Überblick Organisation und Rollen Requirements, User Stories und Backlogs Sprints Betriebsoptimierung mit SCRUM Das Optimierungsprojekt SEK-DBIO Implementierung Anforderungen Team Projektcontrolling Fazit 2 / 50

3 Einleitung Agilität [lat. agilis - flink, beweglich ] 3 / 50

4 Einleitung Agilität bedeutet aus Business-Sicht, sich schnell und effizient auf Veränderungen anzupassen [adapting to changes] Eigenschaften und Leitlinien Offen für Änderungen iterativ inkrementelle Entwicklung Feste Iterationszyklen mit Feedback-Schleifen Team ist selbst-organisierend Inspect & Adapt empirische Methode Beweglichkeit durch Näherung an Ziel 4 / 50

5 Einleitung In welchen Fällen kann uns Agilität helfen? Für komplexe Probleme, bei denen Prozess vorab nicht komplett definiert werden kann, brauchen wir empirische Prozesskontrolle Agilität ist kein Set of Practices, sondern basiert auf Werten und Leitlinien aus dem Agilen Manifest Agile Prozesse erfordern andere Denkweisen und Kulturen 5 / 50

6 Einleitung Wir suchen nach besseren Wegen, Produkte 1 zu entwickeln, indem wir es selbst praktizieren und anderen dabei helfen, dies zu tun. Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen. Funktionsfähige Produkte 2 haben Vorrang vor ausgedehnter Dokumentation. Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen. Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung. Wir erkennen dabei sehr wohl den Wert der Dinge auf der rechten Seite an, wertschätzen jedoch die auf der linken Seite noch mehr. 6 / 50

7 Einleitung Bedingungen des Agilen Manifests [2001, Schwaber Sutherland Kommunikation Kooperation Individuen vor Tools Kundenzusammenarbeit vor Verträgen Mut zu Änderungen Mensch und Team im Mittelpunkt! Rugby Scrum 7 / 50

8 Einleitung Kompliziert Not Simple, but ultimately knowable [Aircraft Wiring] 8 / 50

9 Einleitung Komplex Not Simple and never fully knowable [Aircraft Wiring with Crew and Passengers] 9 / 50

10 Einleitung Agile Methoden Defined Process Alle Prämissen sind bekannt Pro Aktion gibt es exakte Instruktionen Kann kompliziert sein aber letztendlich bekannt Es gibt Best Approach Empirical Process Environment / Voraussetzungen sind nicht komplett bekannt Requirements ändern sich im zeitlichen Ablauf (Change) Kann komplex sein zumindest nicht simple und nicht alles komplett bekannt Best Approach ist unvollständig Für Bearbeitung von komplexen Problemen brauchen wir empirische Prozesskontrolle Agile Methoden bieten Unterstützung! 10 / 50

11 Einleitung Agile Methoden Agile Methods are for Complex Problems Complex 11 / 50

12 Einleitung Agiles PM Agiles Projektmanagement APM / Scrum Inhalt / Aufgaben des Projektmanagements: Aktivitäten koordinieren, Produkt in gewünschter Qualität + Zeit erstellen, Prozesse steuern, Ziele setzen, Planen, Überwachen, Organisieren, Informieren, Entscheiden + Führen Maximen erfolgreicher Projekte Motiviertes Team (statt perfekte Regeln) Gute Kommunikation (statt formelles Berichtswesen) Akzeptieren kontinuierliche Änderungen Aktives Risikomanagement (statt Krisenbewältigung) 12 / 50

14 Scrum Überblick Agiles Managementframework zur Entwicklung von Produkten / Software Besteht aus wenigen klaren Regeln: Verwendung eines priorisierten Product Backlogs Drei Rollen: Product Owner, Team und Scrum Master Erstellen von Produktinkrementen innerhalb Sprints Scrum verkörpert Werte des Agilen Manifests Empirischer Prozess: Inspect & Adapt Kein Wundermittel, sondern harte Arbeit Scrum ist Lernprozess, der Disziplin, Zeit und Geduld benötigt! 14 / 50

15 Scrum Überblick Warum Scrum? Probleme frühzeitig erkennen Handlungsspielraum sichern Komplexe Projekte erfordern Innovation und Kreativität Problem in traditionellen Vorgehensweisen: Wir versuchen frühzeitig, alle Eventualitäten und Arbeitsdetails zu antizipieren, um anschließend unseren Plan auszuführen... oft erst sehr spät Feedback über tatsächlichen Fortschritt In Scrum werden Probleme frühzeitig offensichtlich durch Verwendung kurzer Arbeitszyklen, mit Mehrwert am Ende 15 / 50

16 Scrum Überblick Warum Scrum? Durch Sprint bekommen wir bereits nach wenigen Wochen Feedback über Fortschritte + Hindernisse Projektplanung basiert auf tatsächlichem Fortschritt: Regelm. Check Umsetzung Req. Richtige Maßnahmen Probleme, Hindern. frühzeitig erkennen Ursachen finden, Lösungen entwickeln 16 / 50

17 Scrum Überblick Product Backlog Rücksendung Stornieren Stornieren Daily Meetings Geschenkpapier Gutscheine Sprint Ziel Sprint 2-4 Wochen (max. 30 Tage) Rücksendung Sprint Backlog Potentiell auslieferbares Produkt-Inkrement 17 / 50

18 Scrum Rollen Others Kunden, Marketing, Vertrieb, Managers, Support, Fremd- Teams, Anwender, Scrum Team Product Owner Development Team Scrum Master 18 / 50

19 Scrum Rollen Product Owner (1/2) Repräsentiert Endkundenbedürfnisse Steuert Entwicklung und arbeitet eng mit Team über Projektverlauf zusammen Rolle vereint Produktmanagement Projektmanagement Integration in Entwicklung / Produktion Zentrale Stellung Beeinflusst Projekterfolg und ist für diesen verantwortlich 19 / 50

20 Scrum Rollen Product Owner (2/2) Vollzeitaufgabe / abhängig von Art + Struktur Häufig Produktmanager oder Marketingmitarbeiter Verantwortlich für Erfassen der Kundenbedürfnisse Beschreibung der Anforderungen Erstellen des Konzepts & Product Backlogs Bearbeitet Product Backlog kontinuierlich Hinzufügen / Entfernen von Anforderungen Priorisieren existenter Anforderungen Ziel: Mehrwert aus Kundensicht bestimmen 20 / 50

21 Scrum Rollen Team (1/3) Team führt alle Arbeiten zur Umsetzung der Anforderungen aus Entwicklung ist teambasiert Interdisziplinär besetzt Cross-Skilling General-Specialist Bsp: Architekten, Entwickler, UI-Designer, DB-Experten, Tester, Konfig-Manager, Doku-Experten,... Mitarbeiter sollten mitbestimmen, an welchen Projekten sie arbeiten möchten 21 / 50

22 Scrum Rollen Team (2/3) Srcum-Team ist bevollmächtigt (empowerd) entscheidet, wie viel Arbeit es im nächsten Sprint erledigen kann... Srcum-Team ist autonom in der Lage, Sprint-Ziel ohne externe Abhängigkeiten zu erreichen... Scrum-Team ist selbstorganisiert Mitglieder entscheiden gemeinsam, welche Aufgaben notwendig und wer welche Aufgaben übernimmt, um Sprint-Ziel zu erreichen... Sprint-Backlog Sprint-Burndown-Bericht Daily-Scrum Meetings Scrum-Team wird durch Scrum-Master unterstützt 22 / 50

23 Scrum Rollen Team (3/3) Srcum-Teams sind klein: 5 9 Mitglieder Team-Mitglieder arbeiten in der Regel Vollzeit Empfehlung: Pairing Arbeitsplätze in unmittelbarer Nähe (Collocation) Echtes Team: Einer für Alle, Alle für Einen! Teamnormen und Standards etablieren Visualisieren von Informationen / Ergebnissen: Teamraum ohne Putzpersonal 23 / 50

24 Scrum Rollen Scrum Master (1/2) Agiert als Coach und Change Agent Aufgabe: Prozess und neues Denken etablieren Unterstützung der Teammitglieder Sicherstellung der direkten Zusammenarbeit von Product Owner und Team Hindernisse beseitigen Servant-Leader Besondere Eigenschaften: Offenheit + guter Zuhörer! 24 / 50

25 Scrum Rollen Scrum Master (2/2) Moderation / Brainstorming-Verfahren Coaching Teambildung Kollaborative Entscheidungsverfahren Konfliktmanagement Vom Team bestimmt Keine Personalverantwortung / Leistungsbeurteilung Wichtig für konstruktives Feedback 25 / 50

26 Scrum Rollen Scrum & traditionelles Projektmanagement Aufgabenbereich Scope-Management Zeit-Management Kosten-Management Kommunikations-Mgmt Risikomanagement Qualitätsmanagement Lieferantenmanagement Personalmanagement Scrum-Rollen Product Owner für Produktversion Team für Sprints Product Owner für Releaseplan Team für Sprint Backlog Product Owner Product Owner für Release-Reporting Team für Sprint-Reporting Product Owner mit Input vom Team Product Owner, Team, Scrum Master Product Owner und Team Management Team für Produktivität und KVP 26 / 50

27 Scrum Requirements Zentrales Mittel zum Erfassen / Managen von Requirements: Product Backlog Enthält alle bekannten Anforderungen und Ergebnisse zur Erreichung des Projektziels Funktionale & Nichtfunktionale Anforderungen Kann auch Arbeitsergebnisse (Einrichten von Umgebungen, Bug-Beseitigung,...) enthalten Wird vom Product Owner erstellt und verfeinert Keine Aktivitäten werden vom Team identifiziert und im Sprint Backlog dokumentiert Verändert sich über gesamte Projektlaufzeit: Wächst iterativ-inkrementell 27 / 50

28 Scrum Requirements Da Product Backlog lebt kein Change-Request-Verfahren Tipp: Versionierung des Product Backlogs Priorisierung nach Nutzen, Risiko & Kosten Aufwandschätzungen mit Story Points durch Team, das für Umsetzung verantwortlich sein wird 28 / 50

29 Scrum Requirements Form des Product Backlogs Prio Thema Beschreibung Akzeptanz- Kriterien 1 Kalender Als Basisanwender möchte ich eine Besprechung anlegen 2 Kalender Als Basisanwender möchte ich eine Besprechung stornieren 3 Kalender Als Basisanwender möchte ich eine Besprechung ändern Teste ungültige Eingabe von Werten, z.b.... Teste, dass dieselbe B. nicht zweimal gelöscht Teste, ob... Persistiert... : : : : : Aufwand / 50

30 Scrum Requirements Techniken zur Identifizierung von Requirements: Fokusgruppen Interviews Anforderungs-Workshop Beobachtung der Anwender in Praxis Anforderungs-Workshop vor dem ersten Sprint und später auch während der Sprints Kriterien zur Priorisierung: Wert/Nutzen, Risiko, Kosten 30 / 50

31 Scrum User Stories Beschreiben Anforderungen aus Sicht des Endanwenders Bestehen aus: Name Kurze textuelle Beschreibung Reihe von Akzeptanzkriterien (Conditions of Satisfaction [COS]) 3C-Kriterien: Card (Platz auf Karteikarte), Conversation (Gespräch zwischen PO und Team), Confirmation (überprüfbar und testbar) 31 / 50

32 Scrum Beispiel Productbacklog 32 / 50

33 Scrum Sprints Sprint mit Planning Mode Doing Mode Iteration mit fester Dauer 33 / 50

34 Konvergieren gegen ein bewegliches Ziel durch Einsatz agiler Verfahren 34 / 50

36 Die Anwendung Das Projekt SEK DBIO Ausgangssituation DB-Betrieb eines großen RZ-Servicebetriebes Seit 1995 DB2 LUW mit aktuell ca Datenbanken DB2 Monitoring und Verwaltung mit selbstentwickelten Tools Leitstand Alarmierung mit Leutek Tool ZIS Oracle seit 2006 Auf Solaris mit 50 Datenbanken ( , /4) Davon 5 Zwei- Knoten RAC Systeme Gridcontrol für Verwaltung und Monitoring Anbindung über GC an das selbstenwickelte Überwachungstool Jeweils eine DB virtualisiert über Solaris Zone, teilw. mit SUN Cluster Maximal 2-3 neue Datenbanken pro Monat Aufstellung nach Plan-Build-Run über zwei Bereiche Plan-Build bei Systemtechnik Run bei Betrieb 36 / 50

37 Die Anwendung Das Projekt SEK DBIO Veränderung durch ein gewonnenes Outsouring Projekt: Betrieb von zusätzlichen 120 Oracle Datenbanken, sowie 25 MS-SQL Datenbanken innerhalb eines Jahres Nebenbedingungen Vereinheitlichung der Überwachungsprozesse und Vorgaben zwischen MS-SQL, Oracle und DB2 Logische Trennung der Projekt-spezifischen DBs vom Bestand (Sicherheit) Aufnahme der Version ins Produktportfolio 37 / 50

38 Die Anwendung Das Projekt SEK DBIO Herausforderungen Bereitstellungsaufwand von ca. 10 PT pro DB reduzieren Betriebsverfahren für MS-SQL in Anlehnung an bestehende DB2/Oracle Verfahren entwickeln Betriebsaufwände pro DB halbieren Zusätzliche Anforderungen an Betrieb aus Projekt umsetzten, z.b. Produktionskopien User-Management durch Dritte Verwaltung von Support-User 38 / 50

39 Implementierung SCRUM bei SEK-DBIO Februar 2010: Workshop zur Identifizierung der initialen Optimierungspotenziale April 2010: Grosses zweitägiges Kick-Off Meeting zur Teambildung Teambuilding durch gemeinsame Aktivitäten Visionsarbeit mit den Führungskräften durch Zukunftsprojektion Einführung in den SCRUM-Prozess Auswahl als Key-Projekt Bereichsübergreifende Zusammenarbeit (Plan-Build: Systemtechnik und Run: Betrieb) Projektorganisation etabliert Product Owner: Abteilungsleiter der jeweiligen betroffenen Abteilungen Team: 15 Personen aus beiden Bereichen mit Anteilen für SEK-DBIO zwischen 5% und 40% 39 / 50

40 Implementierung SCRUM bei SEK-DBIO Mai 2010: Explorationsprint zur Füllung des Productbacklogs Daily Scrum Meetings auf zwei Veranstaltungen a 15 min pro Woche Sprintlänge in der Regel 4 Wochen Sprintplanning 1 + Sprintplannig 2 = 8h Review + Retrospective = 4-6h Synchronisation mit Unternehmens Controllingrunde jeweils nach Sprintende Releaseplan für mittelfristige Ziele 40 / 50

41 Anforderungsquellen Anforderungen aus der Organisation Anforderungen aus dem Outsourcing Projekt Backlog Anforderungen aus täglichen Betrieb Anforderungen aus dem Sprint und internen Regularien 41 / 50

42 Team: Erfahrungen in der Gruppe Begegnung der Gegensätze Treiber & Beschützer - Unterschiedliche Rollen des SCRUM Master im Daily SCRUM Kontinuierliche Motivation der Gruppe fehlende Selbstmotivation mangelnde Projektaktzeptanz im Team führt Demotivation andere Gruppenmitglieder Performanceschwächung - Gruppenbildungen über Meinungsführerschaften die nichts zum Erfolg beitragen - Worstcase in SCRUM Störung der Teamautonomie durch viele Fremdeinflüsse Die zwei Gesichter - Team hat mehrere Rollen: Anforderer und Umsetzer Der Lernprozess Aufbau von Kompetenzen im Team: Planung, Schätzungen, Konzeption Selbstorganisation im Team - Bildung von Fachuntergruppen und Integration von Teammitgliedern 42 / 50

43 Team: Individuelle Erfahrungen Die Selbstfindung Der Spezialist - Fokussierung einzelner Teammember auf besondere Aufgaben (Self-Service Oberflächen, UNIT Tests) Selbstorganisation - Selbstdisziplin einzelner Member Wertschätzung der Ergebnisse und Entscheidungen des Teams und der Member Die Unternehmenskultur zusätzlich zu altbewährten Strukturen mehr Mut zu neuen Ideen Glück oder Frust Die Retrospective: Echte Probleme werden nicht offen angesprochen, sondern im verborgenen diskutiert. Der Schäfer und seine Schäfchen - Die schweigende Herde und die ewige Last der Erste zu sein 43 / 50

44 Team: Verbesserung-Veränderung offener Umgang mit Einwänden und Vorwänden, diese direkt und konstruktiv ansprechen, nicht auf die lange Bank schieben Kritik ist wie ein Geschenk, man kann es nicht ablehnen und damit machen was man will Schaffung von Freiräumen für neue Ideen um den eigenen Blickwinkel zu erweitern Zusammenführung / Tausch der Verantwortlichkeiten und Aufgabengebiete zur Schaffung von Verständnis und Transparenz des Anderen (Rotationsprinzip) Selbstmotivation durch intensives und vertrautes Miteinander (Teambuilding) Vermeidung von Ressourcenverluste durch klare Definitionen und Absprachen Steigerung der Teamdynamik - Jeder ist und wird gefordert Verantwortung zu übernehmen und zum Erfolg des einzelnen Sprints und des gesamten Projekts beizutragen 44 / 50

45 Zusammenarbeit mit dem Projekt-Controlling SCRUM kann als alternative Vorgehensmethode in ein Projekt-VGM integriert werden Der aktuelle Zustand des Projektes kann am Projektziel gemessen werden Die jeweiligen Sprint stellen ein Product-Increment zur Verfügung Während des Sprints wird der Fortschritt über den Sprint Burndown Report dokumentiert Der Burndown-Report in Verbindung mit dem Inpediment Report und einem Risikomanagementreport/Risikomonitor ersetzt den Projekt-Statusbericht Workitems entsprechen Meilensteinen 45 / 50

46 Zusammenarbeit mit dem Projekt-Controlling Mit Hilfe eines Releaseplans vom Product Owner kann eine mittel-langfristige Planung durchgeführt werden Die Aufwands-Perspektive kann an Hand der Entwicklung der Sprint-Velocity ermittelt werden Die Inhalts-Perspektive über die Veränderungen des Product-Backlogs Der Termin über die Kombination aus Product-Backlog und Sprint-Velocity 46 / 50

48 Fazit Optimierungsprojekte eignen sich gut für SCRUM Zielrichtung ist vorgeben, die einzelnen Maßnahmen nicht Maßnahmen können in Sprint-Planning jeweils nach maximalem Nutzen ausgewählt werden Quick-Wins sind möglich, wenn Personen des Tagesgeschäfts im Team sind SCRUM stellt hohe Ansprüche an das Team Eigenverantwortliches Handeln (Autonomie!) Vertrauen zu den anderen Teammitgliedern (auch fachlich!) Selbstorganisationsfähigkeit : Priorisierung, Koordination, Kommunikation Übernahme von Verantwortung, statt nur Kritik Kompetenz in Strukturierung von Aufgaben 48 / 50

49 einfach. gut. beraten. Vielen Dank für Ihre Aufmerksamkeit!