Moderne Methoden des Projektmanagements in der Entwicklung. Wir machen zukunftsfähig

Transkript

1 Moderne Methoden des Projektmanagements in der Entwicklung Wir machen zukunftsfähig

2 Moderne Projektmanagementansätze, die in der Praxis funktionieren Teamorientierte Stage-Gate-Ansatz Agiles Projektmanagement Führungsprozesse Controlling Strategie Hauptprozesse Supportprozesse Pilotproduktion & Optimieren/ Nachweisen von Funktionen Einkauf & Lieferanten managen Konstruieren, bauen & optimieren von Sondermaschinen Konstruieren, bauen & optimieren von Werkzeugen Seite 2

3 Moderne Projektmanagementansätze, die in der Praxis funktionieren 1. Was alle neueren Ansätze gemeinsam haben... Das Team Δ Erfolg liegt in der funktionierenden Teamarbeit Δ Ideal 5-7 Teammitglieder Δ Volle Verantwortung im Team Δ Maximale Autonomie in der Projektbearbeitung à Arbeiten im Auftragsprinzip! Die Rollen Δ Klare Rollen, Aufgaben und Verantwortlichkeiten Δ Jeder weiß was er zu tun hat Die Arbeitsweise Δ Methodisch entwickeln was der Kunde brauchen kann. Δ Mehrwert schaffen - Nur das Ergebnis zählt Δ Klare Zeitabschnitte, keine Verlängerung Δ Maximale Transparenz Die Tools Δ Tools dienen dazu die Grundidee des Ansatzes zu fördern und sind Mittel zum Zweck! Seite 3

4 Moderne Projektmanagementansätze, die in der Praxis funktionieren: 2. Besonderheiten des teamorientierten Stage-Gate-Ansatz Führungsprozesse Controlling Hauptprozesse Supportprozesse Pilotproduktion & Optimieren/ Nachweisen von Funktionen Strategie Einkauf & Lieferanten managen Konstruieren, bauen & optimieren von Sondermaschinen Konstruieren, bauen & optimieren von Werkzeugen Δ Grundgliederung in Führungs-, Haupt- und Supportprozess Δ Ganzheitlicher des Hauptprozesses: Die Entwicklung ist auf den Markt ausgerichtet Δ Gesamtprozess ist in klare Prozessabschnitte mit Start- und Endgate gegliedert Δ Fester Takt durch das Gateprinzip Δ Prozess ist die Blaupause des Projekts: Prozesselement = Arbeitspakt, Gate = Meilensteinen im Projekt Δ Klare z.t. auch detaillierte Rollen Δ Verantwortung durch ADMIN- Prinzip definiert, die auch die Zuständigkeiten in den Projektarbeitspaketen festlegen. Δ Entwicklung nach dem Bodenplattenprinzip. Man entwickelt zuerst das Gesamtkonzept und dann Funktionen. Seite 4

5 Moderne Projektmanagementansätze, die in der Praxis funktionieren: 3. Besonderheiten des agiles Projektmanagements/ SCRUM Δ kurzzyklischer Prozess: Planung Sprint Überprüfung - Verbesserung Δ Nur wenig Rollen, man hilft sich gegenseitig im Team aus Δ Im Sprint wird nur an einem Projekt gearbeitet Δ Fortschrittscontrolling erfolgt täglich im 15 Min.- Meeting Δ Zeitabschnitte fest durch Sprintlänge definiert, es werden höchstens Inhalte angepasst. Δ Entwickeln im Bausteinprinzip: In jedem Sprint wird eine funktionierendes Modul entwickelt Δ Planung erfolgt nur für ein Sprint Δ Von Sprint zu Sprint wird durch Reviews reflektiert und in die Planung des nächsten Sprints berücksichtigt Δ Nach jedem Sprint kann das Produktmodell erweitert/ verändert werden Seite 5

6 Moderne Projektmanagementansätze, die in der Praxis funktionieren Teamorientierte Stage-Gate-Ansatz Agiles Projektmanagement Führungsprozesse Controlling Strategie Hauptprozesse Supportprozesse Pilotproduktion & Optimieren/ Nachweisen von Funktionen Einkauf & Lieferanten managen Konstruieren, bauen & optimieren von Sondermaschinen Konstruieren, bauen & optimieren von Werkzeugen Seite 6

7 1. Strategiephase 2. Vertriebsphase 3. Lastenheftphase G Gatephase 4. Konzeptphase Kunde bzw. Markt G1 Business Case 5. Prototypenphase 6. Vorserienphase 7. Industrialisierungsphase P3 V3 G2 Produktlastenheft 8. Anlaufphase 9. Serienphase V8 P4 V4 Markteinführung G5 G3.1 Produkt- Pflichtenheft und Produktkonzept P5 V5 V7 P6 V6 G3.2 Prototypenteile G4 Teile aus reproduzierbarem Prozess Design Verification freigegeben Seite 7 7

8 SCRUM im Überblick Daily SCRUM Sprint Sprint Backlog Verwendbares Produkt Selected Backlog Idee Product Backlog SCRUM Planing Meeting Seite 8

9 Das Product Backlog mit User Stories Idee Product Backlog Das Product Backlog ist die Liste aller für das Produkt bekannter User Stories. Zu jedem Produkt existiert immer nur ein Product Backlog. Das Product Backlog entspricht in der klassischen Produktentwicklungssemantik dem Lastenheft. Es wird jedoch laufend erweitert. Warum nur mit User Stories? Δ Fokus auf den Mehrwert Δ Der Sinn/ Nutzen einer Anforderung wird deutlicher Δ Der Kundenbedarf wird nur mit der Sprache des Kunden dargestellt. Merkmale einer User Story Eigenschaften guter User Stories Δ Unabhängig Δ Verhandelbar Δ Schätzbar Δ Testbar Δ Wertvoll User Story Muster Sicht/ Rolle Ziel Grund Δ In der Sprache der Kunden Δ Entwickelt vom großen Ganzen zum Detail, nicht umgekehrt (s, Themen, Stories). Δ Jede Story ist nur aus der Sicht eines Mitglied des Buying- Centers (User (1-x), Buyer, Influencer und Decider) Als Elektriker Als Entscheider will ich schnell und sicher das Gerät anschließen, will ich zukunftsfähige Systeme haben, weil ich effizient arbeiten will weil ich mein Entwicklungskosten reduzieren will. Seite 9

10 Die User Story als zentraler Denkansatz Idee Product Backlog Selected Backlog Sprint Backlog Thema 1 Schneiden Thema 2 Thema 3 Schneiden Sprit Story 1 Sprit Story 2 Sprit Story 3 Sprit Story 4 Sprit Story 5 Sprit Story 6 Vorgehensschritte bei der Arbeit nach SCRUM 1. User Stories in Blöcken (s) beschreiben 2. Steht das Fundament, die s priorisieren. 3. s mit hoher Bewertung in Themenfelder und User Stories schneiden Schneiden nach Vertikal End zu End Horizontal nach Schicht Datenobjekt Aufwand Forschungsanteilen Qualität Buying- Center Rolle Akzeptenzkriterien Technischer Voraussetzung Seite 10

11 Die User Story als zentraler Denkansatz Idee Product Backlog Selected Backlog Sprint Backlog Thema 1 Schneiden Thema 2 Thema 3 Schneiden Sprit Story 1 Sprit Story 2 Sprit Story 3 Sprit Story 4 Sprit Story 5 Sprit Story 6 Vorgehensschritte bei der Arbeit nach SCRUM 1. User Stories in Blöcken (s) beschreiben 2. Steht das Fundament, die s bewerten. 3. s mit hoher Bewertung in Themenfelder und User Stories schneiden 4. User Stories für die Umsetzung für das selected Backlog freigeben 5. User Stories im selected Backlog detailliert bewerten und für das nächste Sprint Backlog freigeben Sicht/ Rolle Ziel Grund Als Elektriker Als Entscheider will ich schnell und sicher das Gerät anschließen, will ich zukunftsfähige Systeme haben, weil ich effizient arbeiten will weil ich mein Entwicklungskosten reduzieren will. Seite 11

12 Bewertung von User Stories Idee Product Backlog Selected Backlog Sprint Backlog Man unterscheidet grundsätzlich das Bewerten vom Aufwandschätzen von User Stories. Bewährtes Grundraster zur Bewertung von User Stories: Bewertung Faktor Finanzieller Erfolgsanteil (i.d.r. in%) Kostenanteil (i.d.r. in%) Kundennutzen nach KANO Basisanforderungen Binär: erfüllt 1, nicht erfüllt 0 Leistungsanforderungen Mehrheitlich erfüllt Markt erfüllt Premium Begeisterungsanforderungen Keine Nicht erkennbar Will ich haben Risiko Machbarkeit Unbekannt Prinzipiell gelöst Schon mal gelöst Herstellbarkeit Unbekannt Im Markt bekannt Bei uns etabliert Vertriebsfähigkeit Völlig neu Was zu lernen bekannt Lieferbarkeit Neue Lieferwege Bereits im Portfolio Standard Anwendbarkeit bzw. Verkaufbarkeit Ganz neue Lösung Ähnliche Prinzipien Dem Kunden vertraut Seite 12

13 Agiles Schätzen des Aufwandes Grundansatz: Die Planung darf nicht zu viel Zeit in Anspruch nehmen. Man muss nur hinreichend genau schätzen stimmen tut es sowieso nie genau! Folgende Regeln helfen: 1. Nicht die Dauer absolut, sondern den Aufwand relativ schätzen. Etwa gleich wie... Doppelt soviel wie Schätzen in Story Points Idee Product Backlog Selected Backlog Sprint Backlog Schätzen in Tagen ergibt sofort eine Verpflichtung. Folge man lasst Luft im System. Tage sind nicht gleich SCRUM Tage, da hier 100% nur für das Projekt gearbeitet wird Teamarbeit reduziert den Zeitaufwand oft nicht proportional Vorgaben der User Story sind nicht ganz scharf. Daher lässt sich auch nicht ganz schaf schätzen Folgende Abstände haben sich bewährt: 1, 3, 5, 8, 13, 20, 40, User Stories die in das Sprint Backlog sollen, müssen unterhalb 20 Story Points haben, größere müssen geschnitten werden. 4. Machen Sie eine Planungsrunde mit dem Planungspoker! Seite 13

14 Die User Story als zentraler Denkansatz Idee Product Backlog Selected Backlog Sprint Backlog 1 Punkt 3 Punkte 5 Punkte 8 Punkte 13 Punkte Sprit Story 1 Sprit Story 3 Sprit Story 5 Sprit Story Sprit Story 4 Sprit Story Schneiden Thema 1 Thema 2 Thema 3 Velocity: 15 Schneiden Sprit Story 1 Sprit Story 2 Sprit Story 3 Sprit Story 4 Sprit Story 5 Sprit Story 6 Seite 14

15 Der Sprint und der Daily SCRUM Daily SCRUM Sprint User Story Offen In Arbeit Fertig Sprit Story Burndown-Chart Sprit Story 3 5 Sprit Story 4 7 Sprit Story 2 4 IST SOLL Sprint- Ende Seite 15

16 Kontaktdaten Liebich & Partner AG Schützenstraße 3 D Baden-Baden Tel / Fax / info@liebich-partner.de Berater: Dr. Christoph Dill Mobil: +49 (173) dill@liebich-partner.de Seite 21