SCRUM und physische Produkte: Eine Einführung20physische%20Produkte%20... · 2012-11-26 · SCRUM...

SCRUM und physische Produkte:Eine Einführung

© www.korn.ch

Dr. Hans-Peter Korn

1 2

3 4

56

7

Quelle: http://www.hermes.admin.ch/ikt_projektfuehrung/die-methode-hermes/

Vertrauter SW-Projektablauf:

Vertrauter SW-Projektablauf – genauer betrachtet:

Ist-Aufnahme

Analyse

Konzept Szenario A

Simulation Szenario A

Varianten-entscheid

Konzept Szenario B

Simulation Szenario B

Konzept Szenario C

Simulation Szenario C

RealisierungB Ausrollen /

Schulung

Nutzung

n Monate (Jahre??)

Der Kontext des Projekts (Markt, Gesetze, Innovationen, …)

Zeit

© www.korn.ch

… und es ist sogar noch komplexer:

Bereits die Kenntnis - oder das Gerücht - dass es so ein Projekt gibt, verändert den Markt (Kaufverhalten der Kunden, Produktentwicklungen der Konkurrenten, …)

Im Verlauf der Konzeption und Realisierung entstehen neue Ideen und Sichtweisen

Veränderungen innerbetrieblicher Macht- und Organisationsstrukturen (neuer Chef mit neuen Ideen, Bereichszusammnenlegungen etc) verändern die Kostenstrukturen … und damit die Wirtschaftlichkeit einzelner Lösungskomponenten

Ein Keyplayer im Projektteam wird für eine zweiwöchige "Feuerwehrübung" in ein anderes Projekt abkommandiert … bleibt dort aber vier Monate

etc etc etc

© www.korn.ch

Komplexe Projekte können nicht vorausgeplant werden.

Dave Snowden: Cynefin Sense making Framework source: http://en.wikipedia.org/wiki/Cynefin

Sense - Categorise - Respond

Sense - Analyze - RespondProbe - Sense - Respond

Act - Sense - Respond

Disorder

Sense - Categorise - Respond

Sense - Analyze - RespondProbe - Sense - Respond

Act - Sense - Respond

Disorder

The relationship between cause and effect is obvious to all, the approach is to Sense -Categorise - Respondand we can apply Best Practice.

The relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge, the approach is to Sense - Analyze - Respond and we can apply Good Practice.

The relationship between cause and effect can only be perceived in retrospect, but not in advance, the approach is to Probe - Sense - Respondand we can sense Emergent Practice.

There is no relationship between cause and effect at systems level, the approach is to Act -Sense - Respond and we can discover Novel Practice.

So – und jetzt??

Konzept

Resultat

<< Projekt >>

© www.korn.ch

Plan > Tun > Ergebnis

voraussehbar, berechenbar

© www.korn.ch

Schritt für Schritt:Probieren > Beobachten > Reagieren

unvorhersehbar AGIL vorgehen

?

?

?ok

ok

© www.korn.ch

Probe - Sense - Respond statt Sense - Analyze - Respond

Ab den 90er-Jahren:In der Informatik mehr und mehr alternative Formen des (Projekt)managements:

inkrementelles Erstellen einzelner kleiner bereits brauchbarer Lösungsteile; pro Inkrement nur wenige Wochen

rasches Feedback der Nutzer, damit Korrekturen / neue Ideen schon im nächsten Inkrement umgesetzt werden

permanente und enge Zusammenarbeit und persönliche Kommunikation mit den Nutznießern

Detailplanung und Erarbeitung der Lösung durch so weit als möglich sich selbst organisierenden Teams

2001 als "Essenz" der so funktionierenden Vorgehensweisen daraus entstanden:

>> Agiles Manifest <<

© www.korn.ch

Quelle: http://agilemanifesto.org/iso/de/

http://darkagilemanifesto.orgAndrea Janes is an Assistant Professor of Software Engineering at the Free University of Bolzano-Bozen, Italy. Andrea holds a MSc in Business Informatics (Technical University of Vienna, 2001). Giancarlo Succi Giancarlo Succi is Professor of Software Engineering at the Free University of Bolzano-Bozen, Italy. Before joining the Free University of Bolzano-Bozen, he has been Professor at the University of Alberta, Associate Professor at the University of Calgary, and Assistant Professor at the University of Trento, Italy. Giancarlo has been active in Agile Methods since the late '90s, is one of the two founders of the XP20KY conference series, has worked with companies in this areaand has also obtained research grants.

Die sechs Aspekte von Agilität in den Domänen der Operationsführung:

Robustheit: die Fähigkeit, aufgaben-, situations- und bedingungsübergreifend effektiv zu bleiben;

Belastbarkeit: die Fähigkeit, sich von Unglücksfällen, Schäden oder einer de-stabilisierenden Störung der Umgebung zu erholen oder sich darauf einzustellen;

Reaktionsfähigkeit: die Fähigkeit, auf eine Veränderung der Umgebung rechtzeitig zu reagieren;

Flexibilität: die Fähigkeit, mehrere Lösungsmöglichkeiten einzusetzen und nahtlos von einer zur anderen überzugehen;

Innovationsfähigkeit: die Fähigkeit, neue Dinge zu tun und die Fähigkeit, alte Dinge auf eine neue Art und Weise zu tun;

Anpassungsfähigkeit: die Fähigkeit, Arbeitsprozesse zu ändern und die Fähigkeit, die Organisation zu ändern.

Im Vergleich gemäss „Power to the Edge“:Quelle: homepages.hs-bremen.de/~whonekamp/P2tE_deutsch.pdf

… und viele weitere Definitionen …

Agil = Flexibilität / Adaptivität sichern mit „Empirical Process Control“als vereinfachte Spezialform des „Statistical process control“ in Form von „plan 1st step - act - inspect (=feedback) - adapt & plan 2nd step - act …“

gemäss Tom Gilb

Agil = Flexibilität / Adaptivität sichern mit „Empirical Process Control“plus „Lean Management Principles“ verbreitete Sicht

Agil = Primär eine Sammlung „post-tayloristischer“, hierarchie- und autoritätsfreier, partizipativer, selbststeuernd-kollaborativer, konversationsbasierter Praktiken und „Glaubenssätze“, mehr oder weniger explizit verbunden mit „Empirical Process Control“ plus „LeanManagement Principles“ „Agiles Manifest“ - ein Appell oder eine abgesicherte Strategie? (Andrea Janes, Giancarlo Succi, Free University of Bolzano)

Agil = überlebens- und entwicklungsfähig: Robustheit - Belastbarkeit -Reaktionsfähigkeit - Flexibilität - Innovationsfähigkeit -Anpassungsfähigkeit gemäss „Power to the Edge“

… und viele weitere Definitionen …

SCRUM – ein exemplarisches agiles „Framework“

Jeff Sutherland schuf den Scrum Process 1993.

Mit dem Wort "Scrum" bezog er sich auf eine 1986 im Harvard Business Review publizierte Studie von Takeuchi und Nonaka, in der "high-performing, cross-functional teams" mit der Scrum-Formation im Rugby verglichen wurden.

Ken Schwaber formalisierte den Prozess für die Software-Industrie in einem Artikel für die OOPSLA 1995.

© www.korn.ch© www.korn.ch

Weitere agile „Vorgehensmethoden“:

•Dynamic Systems Development Method(DSDM)

•SW-Kanban•Extreme Programming (XP)•Lean software development•Feature Driven Development (FDD) •Agile Unified Process (AUP)•Crystal Clear

SCRUM – ein exemplarisches "agiles" FrameworkDer “Product Owner” erstellt eine erste Version einer geordneten

(“priorisierten”) Liste der gewünschten Ergebnisse (“Product Backlog”)Die Projekt ist eine Abfolge stets gleich langer "Sprints" (2 bis 4 Wochen) Das Team nimmt zu Beginn eines Sprints vom Product Backlog jene hoch

priorisierten Ergebnisse, die es im Sprint realisieren kann (“Sprint Backlog”) Ergebnisse (“Product Increment”) sind sofort nach Sprintende nutzbar

Während des Sprints organisiert sich das Team selber: Es teilt die Aufgabenselbst untereinander auf und sorgt für die notwendige Detailplanung, Kommunikation und Kooperation.

Auf Prozessebene wird es dabei vom "Scrum Master" (dem “Servant Leader”des Teams) unterstützt.

ABCDEFGH

ACD

ACD

ABCDEFGH

BE

B

ABCDHFRGE

HFR

HFR

ACD B

ACD

ABCDHFRGE

Product Backlog

Sprint Backlog

ProductIncrement

Sprint

© www.korn.ch

Quelle: Barry Boehm (University of Southern California) Richard Turner (George Washington University); Using Risk to Balance Agile and Plan-Driven Methods; 0018-9162/03/$17.00 © 2003 IEEE; June 2003, pp 57 - 66

Wie gut passt „agil“ für uns?

Mindchange nötig:

© www.korn.ch

Product Owner (PO)Vertritt und formuliert gegenüber demTeam die Bedürfnisse der Nutzer und die Interessen des Auftraggebers

Multidisziplinäres EntwicklungsteamErarbeitet in jedem Sprint die mit demPO vereinbarten unmittelbar nutzbarenLösungenOrganisiert sich im Spint selbst

ScrumMaster (SM)“Servant Leader” des Teams, moderiertdie Besprechungen, sorgt für optimaleArbeitsvoraussetzungen

Andere “Stakeholder”Werden vor allem vom PO angemesseneinbezogen

Rollen bei agilen Projekten (am Beispiel von Scrum)

© www.korn.ch

Scrum-Team

Sprint Review

InitialePlanung

Sprint-Planung

ProductInkrement

SprintBacklog

ProductBacklog

2 – 4 Wochen

Geordnete Liste aller Ergebnisse (grob)

für den nächsten Sprint gemäss Sprintziel ausgewählte Ergebnisse (detailliert)

NUTZBARE Resultate des Sprints

Ziel? Was? Wie? Wer? Reihenfolge?

Was soll insgesamt erreicht werden? Erfolgskriterien?

tägliche Koordination im Team (nur 15 min!)

Ziele / Erfolgskriterien erreicht?Product Backlog ändern?

Product Owner(vertritt die Nutzniesser)

Scrum Team(selbstorganisiert,

ScrumMaster als Servant Leader)Nutzniesser

(vertreten duch Product Owner)

RetrospektiveReflexion der Teamarbeit

Product Owner& Nutznisser

Scrum Team

DailyScrum

Auf einem Blick:

© www.korn.ch

Ist all das ein „alter Hut“?

Ab hier keine Rück-kopplung

Stufenweise Realisierung angedacht, jedoch nicht weiter erläutert. Angedacht nur i.S. vorausgeplanter grosser Etappen.

Negative Feedbacks als „Misserfolg“, nicht als Orientierungshilfe.

Quelle: Walter F. Daenzer, ETH Zürich: Systems Engineering. Zürich: Verlag Industrielle Organisation, 2. Auflage 1978/79

Bis hier iterativ/inkrementell/adaptiv

Ab hier wird gemäss der umfassenden Detailkonzeption gebaut

Quelle: Walter F. Daenzer, ETH Zürich: Systems Engineering. Zürich: Verlag Industrielle Organisation, 2. Auflage 1978/79

Keine inkrementelle betriebliche Nutzung

Nur bis hier iterativ/ inkrementell/ adaptiv

SCRUMSchritt für Schritt

© www.korn.ch


Vision entwickelnals Basis für

Wird erarbeitet vom „Product Owner“ zusammen mit anderen Personen mit • Markt- und Nutzerkontakt• ökonomischer Verantwortlichkeit für das Ergebnis

© www.korn.ch

InitialePlanung

ProductBacklog


"Product Backlog“: Die Ergebnis-Wunschliste

Wird erarbeitet vom „Product Owner“ zusammen mit anderen Personen mit • Markt- und Nutzerkontakt• ökonomischer Verantwortlichkeit für das Ergebnis


© www.korn.ch

Realisierungsreihenfolge)

© www.korn.ch

InitialePlanung

SprintPlanung

SprintBacklog

ProductBacklog


für den nächsten Sprint gemäss Sprintzielausgewählte Ergebnisse (detailliert)



Erster „Sprint": Sprint Planning

© www.korn.ch

Erster "sprint": Sprint Planning – 1. Teil

Product Owner erklärt ausgehend von „Sprintziel“ die aus seiner Sicht im Sprint zu realisierenden Ergebnisse, die (z.B.) als „Stories“ vorliegen. Entw.Team stellt Verständnisfragen.

Entw. Team schätzt zu jeder Story den relativen Aufwand im Vergleich zu den anderen Stories anhand dieser "Gewichte":

1 2 3 5 8 13 20 30 50(modifizierte Fibonacci-Folge)

Entw.Team bestimmt in Abstimmung mit dem PO jene Stories mit hoher Priorität, die es seiner Schätzung nach im ersten Sprint erledigen kann

Entw.Team einigt sich mit dem PO verpflichtend auf das Ziel des Sprints (1 bis 3 kurze Sätze)

Entw.Team legt dem PO eine abschliessende Prognose (= ein Plan, keine garantierte Verpflichtung) vor, welche spezifischen Ergebnisse (z.B. „Stories“) es wird realisieren können

© www.korn.ch

Erster "sprint": Sprint Planning – 2. Teil

Entw.Team ohne PO (moderiert vom Scrum Master):

Legt für die prognostizierten Stories die Teilaufgaben ("Tasks") fest damit eine Aufgabenplanungstafel ("Sprint Task Board") in dieser Art:

Story

Story

Story

zu tun in Arbeit erledigtTask

Task

TaskTask

Task

TaskTask

© www.korn.ch

InitialePlanung

SprintPlanung

SprintBacklog

ProductBacklog

2-4 Wochen


Erster "sprint": Aufgaben erledigen => konkrete, nutzbare, Ergebnisse

DailyScrum

tägliche Koordination im Team




© www.korn.ch

Erster "sprint": Aufgaben erledigen => konkrete, nutzbare, Ergebnisse

Entw. Team (unterstützt vom Scrum Master)Erledigt die Aufgaben; "Sprint Task Board"

fortlaufend aktualisieren kontaktiert Product Owner zu DetailftragenProduct Owner bleibt im Hintergrund!Vereinbarte "Stories" dürfen nicht verändert

werden!!! (Wenn sie verändert werden müssen: Ok vom PO einholen)

Story

Story

Story

zu tun in Arbeit erledigtTaskTask

TaskTask Task

TaskTask

"Daily" Scrum (Dauer max. 15 min)

Das habe ich bis jetzt erledigt

Das insbesondere hat mir dabei geholfen / habe ich erkannt

Das werde ich jetzt beginnen / weitermachen

Das brauche ich von anderen im Team oder ausserhalb zusätzlich oder anders

© www.korn.ch

© www.korn.ch

© www.korn.ch

Sprint Review / Retrospective

ProductIncrement

SprintBacklog

ProductBacklog

NUTZBARE Resultate des Sprints


Ziele / Erfolgskriterien erreicht?Ist Product Backlog zu ändern?Reflexion der Teamarbeit

Sprint

Erster "sprint": Sprint Review / Sprint-Retrospektive

DailyScrum

tägliche Koordination im Team

InitialePlanung

SprintPlanung


für den nächsten Sprint gemäss Sprintziel ausgewählte Ergebnisse (detailliert)


© www.korn.ch

Erster "sprint": Sprint ReviewDas Entw. Team präsentiert dem Product Owner und - vor allem - den von

den Ergebnissen profitierenden und betroffenen Stakeholdern die VOLLSTÄNDIG erledigten ( Definition of Done) Resultate (z.B. "Stories, im Beispiel die erste und dritte)

Der Product Owner entscheidet spätestens jetzt (besser fortlaufend im Verlauf des Sprints), ob er diese Stories akzeptiert und das Sprintziel erreicht wurde.

UNvollständig erledigte Resultate (im Beispiel die zweite Storiy) werden NICHT berücksichtigt sondern wandern als Ganze zurück in das ProductBacklog.

Story

Story

Story

zu tun in Arbeit erledigtTask

Task

TaskTaskTask

TaskTask

© www.korn.ch

Erster "sprint": Sprint-Retrospektive: Was ist unsere Geschwindigkeit?

Das ganze Scrum-Team (= Entw.Team plus PO plus SM) ermittelt: Wie viel „Gewichtspunkte“ haben wir im ersten Sprint – bezogen auf die vom PO VOLLSTÄNDIG ABGENOMMENEN Stories geleistet?Als „Leistungsdiagramm“ darstellen:

Sprint

Gewichtspunkte (kumuliert)

1 2 3 4 5 6

Das erlaubt eine erste Prognose für die insgesamt leistbaren Stores.Dieses Diagramm wird nach jedem Sprint aktualisiert.

Fortlaufend genauere Schätzung der „velocity“Eine Schätzung ist immer eine Schätzung, nie eine Garantie!

© www.korn.ch

Erster "sprint": Sprint-Retrospektive: Prozess-Optimierung

Das ganze Scrum-Team (= Entw.Team plus PO plus SM) reflektiert:

Was hat gut geklappt?

Was lernen wir daraus?

Was wollen wir im nächsten Sprint weiterhin so oder sogar besser machen?

Was wollen wir vermeiden?

Was anders oder zusätzlich machen?

„Teamwork-Backlog“

© www.korn.ch


IntegralePlanung

ProductIncrement

ProductBacklogangepasst NUTZBARE Resultate des

Sprints


Ziele / Erfolgskriterien erreicht?Ist Product Backlog zu ändern?

zweiter "sprint":Anpassung


© www.korn.ch


IntegralePlanung

ProductIncrement

ProductBacklogangepasst NUTZBARE Resultate des

Sprints


Ziele / Erfolgskriterien erreicht?Ist Product Backlog zu ändern?

zweiter "sprint":Anpassung

Völlig unerwartet ist der Sponsor für „XXXXX“ ausgestiegen. Überarbeitet muss werden: …… weg fallen: ……..

hinzu kommen: …….


© www.korn.ch

ZWEITER "sprint": Product Backlog anpassen

Product Owner mit dem Entw. Team als "Lösungsexperten":

Welche Stories sind jetzt nach wie vor fertig?

Was muss bei den erledigten Stories geändert werden?

Was muss bei den noch offenen Stories verändert werden?

Product Backlog angepasst

© www.korn.ch

SprintPlanning

SprintBacklog


Zweiter "sprint": Sprint Planning 1. Teil / 2. Teil

IntegralePlanung

ProductBacklogangepasst

und so weiter …. wie beim ersten Sprint




© www.korn.ch

Verbindliche Spielregeln auf nur 16 Seiten:

Juli 2011

ABER: Diese „offiziellen“ Scrum-Spielregeln beschreiben nur diese Situation:

EIN Scrum-Team allein arbeitet an nur EINEM Produktdas von EINEM PO als „Kundenproxi“ vetreten wird.

Es gibt im Scrum Guide nur diesen Hinweis auf „mehrere Teams arbeiten an EINEM Produkt“:

Häufig arbeiten mehrere Scrum Teams zusammen am gleichen Produkt. Ein einziges Product Backlog wird zur Beschreibung der anstehenden Arbeit an dem Produkt verwendet. Dazu wird ein Attribut zur Gruppierung der Product Backlog Einträge eingeführt.

Für solche Situationen: Mehrere Teams arbeiten an mehreren ProduktenPro Produkt oder Produktgruppe gibt es

Releases mit dazugehörigen teamübergreifenden Planungen und Reviews

Koordination der „Team-POs“ (sie vertreten gegenüber ihrem Team mehrere Produkte) und der „Produkt-POs“ (bzw. der Produkt Manager)

müssen die Scrum-Spielregeln entsprechend erweitert werden. Z.B. so: http://scaledagileframework.com/

Scrum:

IllusionRealität

Scrum = „Container“als Vorgehens-Framework; kein Methodenersatz

Adaptivität, Qualität, Effektivität;insgesamt nicht schneller / billiger

Nicht nur inkrementell und adaptiv sondern vor allem auch „agil“

Strikte Professionalität

Agiles Anforderungs-management

Teams als Ganzes selbstverantwortlich innerhalb klarer Spielregeln

Nicht möglichst viel sondern das betrieblich relevanteste mit höchster Qualität zuerst. („Cost of Delay“)Rasches Feedback von den Nutzern rasche Adaption der jeweils relevantesten Funktionen.Scrum erhöht primär die Effektivität und unterstützt dabei die auf der Nutzerseite betrieblich nötige Flexibilität und Dynamik.Bezogen auf komplette Projekte gibt es keine Signifikanz, dass Scrum den Gesamtaufwand reduziert. (Masterarbeit Mark Harwardt; http ://www.fernuni-hagen.de/imperia/md/content/ps/masterarbeit-harwardt.pdf)

Adaptivität, Qualität, Effektivität

© www.korn.ch 2011

Scrum ist „leichtgewichtig“ weil es von Entwicklern ausgeht, die all das professionell beherrschen ohne in dicken Methodenhandbüchern nachsehen zu müssen:

Scrum = „Container“ als Vorgehens-Framework; kein Methodenersatz

© www.korn.ch 2011

Sitemap von OpenUP http://epf.eclipse.org/wikis/openup/ als Beispiel


Quelle: http://scaledagileframework.com

EDUF (Enough Design Up Front) statt BDUF (Big Design Up Front) und schrittweise Verfeinerung / Anpassung von Relase zu Release und Sprint zu Sprint.




Der Product Ownerals „Superman“?




Kunde

SwissQ Agile Trends & Benchmarks 2012. Zürich: SwissQ Consulting AG, 2012

„Wir liefern xyz per mm-jjjj“ widerspricht ja dem inkrmentell/adaptiven Vorgehen

Quelle: Studie „Status quo Agile“ 2012 in http://borisgloger.com/newsletter/oktober-2012/quo-vadis-agile/?utm_source=Newsletter&utm_campaign=89cc7711d1-NL201210&utm_medium=email

1

2

4

3

56

78

Rang

Wie geht das bei PHYSISCHEN Produkten?

Quelle: PTC.com/go/agility


Eine Lösung: Flexible CAD-Werkzeuge(entsprechend der Modellgetriebenen Softwareentwicklung)


Weitere Lösung:

AdaptiverKonstruktions-PROZESS

Quelle Basisbild: „Disziplinierte Agilität“ bei IBM, aus: S. Greter, W. Keller: Agilität skaliert. In: OBJEKTspektrum 2012 / 2

Bei der Entwicklung physischer Produkte ist ein inkrementell/iterativ/adaptives Vorgehen hier

üblich de facto üblich, oft aber„bürokratisch“ erschwert

oft zu teuer

viel zu teuer

Essentielle Unterschiede bei inkrementell/iterativ/adaptive Entwicklung • von Software• physischer Produkte

Softwareentwicklung ist die Herstellung einer modellhaften Beschreibung von Funktionen, die ein bereits vorhandenes und dazu vorbereitetes physisches System bieten kann, indem die maschinenlesbare Beschreibung das Systemverhalten steuert.Das iterative Entwickeln von Software ist wie das iterative Komponieren und Spielen eines neuen Musikstücks auf einem bereits vorhanden Instrument.

Die Entwicklung physische Produkte umfasst zunächst die Herstellung einer modellhaften Beschreibung des Produkts. Das geschieht i.a. iterativ, auch unter Nutzung rasch und kostengünstig herstellbarer Modelle. Diese Beschreibung (etwa als CAD-Modell) kann nur in seltenen Ausnahmen von einem bereits verfügbaren Fertigungsautomaten genutzt werden, um das Produkt vollautomatisch zu produzieren. In der Regel ist die Beschreibung die - stabile - Basis für die zeit- und kostenmässig aufwändige Einrichtung und Abwicklung der Produktion. Produkte bestehend aus physischen Modulen mit klaren und stabilen Schnittstellen erleichtern die flexible Realisierung von Produkten, jedoch nur im Rahmen dieser Architektur.

© www.korn.ch

Gesamtkonzept, Architektur, Modularisierungiterativ/adaptiv für Gesamtprodukt

Parallele Detailarbeitinkrementell/adaptiv für Teilprodukte / Module

Mögliches adaptives Vorgehen im Konstruktionsprozess

Quelle Basisbild: Hans Grabowski: Modellieren - neue Verfahren der Produktentwicklung. In: G. Schuh, H.P. Wiendahl: Koplexität und Agilität. Springer 1997

adaptivEDUF

adaptivEDUF

inkrementelladaptiv

inkrementell adaptiv

DIREKTER Kunde der Konstruktion DIREKTER Kunde von Montageplanung

iterativadaptiv

DIREKTER Kunde von Montagepl. & Prototyp

Interne Kunden und adaptiv bearbeitbare Bereiche bei einer kompletten Produktentwicklung (Beispiel: Achssystem)

Quelle Basisbild: A.-W. Scheeri: Modellieren von Geschäftsprozessen. In: G. Schuh, H.P. Wiendahl: Koplexität und Agilität. Springer 1997

A

A

AB

C

B

B

B

x

C

C

C

x

xx

x

x

xx

xx

x

x

xx

x

xx

x

xx

x

B

VISUELLE Koordination und Arbeitsplanung / Arbeitsverfolgung

Arbeitsstand der laufenden Iteration im Gesamtmodell:

Blau = geplant Orange = derzeit in ArbeitGrün = erledigt

Arbeitsplanung / Arbeitsverfolgung der laufenden Iteration; Schnappschuss am 2. Tag

© www.korn.ch basierend auf: Heinz Erretkamps, Johnson Controls: Nano Scrum – physische Produkte schnell entwickeln. In: Hans-Peter Korn, Jean Pierre Berchez (Hrsg.): Agiles IT-Management in großen Unternehmen. Symposion, erscheint Ende 2012

Agile Produktion?

Planung und SteuerungMaterialtransfers mit kleinen Losgrößen im Ziehprinzip, hybride Auftragsabwicklung mit differenzierten Steuerungsverfahren, Umstellung der Steuerungslogik, Anpassung der PPS, ERP-Einführung, durchgängige Kanban-Systeme

ArbeitsorganisationTeam- und Gruppenarbeit mit hoher Eigendynamik und Eigensteuerung, Integration indirekter Aufgaben, Mehrfachqualifikationen, flexible Arbeitszeitmodelle, anreizförderndeEntgelt-Systeme

Kontinuierlicher Verbesserungs-ProzessEinstieg in KVP in Korrelation mit Gruppenarbeit, angepasstem Führungsverhalten, Kulturverbesserung und systematischen organisatorischen Elementen, SelbststeuerndeProduktivitäts- und Qualitätszirkel, Quick-Umsetzungs-Projekte

Quelle: http://www.tundo.de/wertschoepfung/61-die-agile-produktion-ein-fahrplan-zur-konzeption-und-umsetzung-von-ganzheitlichen-produktionssystemen

Agile Produktion mit sich selbst organisierenden autonomen Produktionszellen

autonome Produktionszelle

Quelle: G. Reinharti: Autonome Produktionssysteme. In: G. Schuh, H.P. Wiendahl: Koplexität und Agilität. Springer 1997

Spezielle Aspekte zu:Produkt = Hardware + embedded Software

Dies und die folgenden slides sind Auszüge aus dem RASSP Education & Facilitation Program Module 14Als .ppt frei verfügar hier:http://www.google.ch/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&ved=0CEAQFjAE&url=http%3A%2F%2Fwww.eda.org%2Frassp%2Fmodules%2Fm14%2Fm14_03_00.ppt&ei=XEmMUNDzHsb44QSNoYHoCg&usg=AFQjCNGJt4pFGT25_C1foqIPn19pMDXolg

SystemConcepts

Sys/HWRequire.Analysis

Sys/SWRequire.Analysis

HardwareRequire.Analysis

SoftwareRequire.Analysis

Prelim.Design

Prelim.Design

DetailedDesign

DetailedDesign

Fabric.

Coding,Unit test.,Integ. test

HWCITesting

CSCITesting

SystemInteg. and test

Operation.Testing and Evaluation

SW Development

HW Development

Integrated Modeling Substrate

Integrated Modeling Substrate

© IEEE 1991

Integrated modeling substrateSupports evaluation at several stages of the design processSupports step-wise development and integration of hardware and

software

Inkremente

iterativ / adaptiv pro Inkrement

Wenn „agilophil“ & hohe Adaptivität nötig:Wie Agilität im Unternehmen neu einführen oder „redesignen“?

bigbang?

Agilität als adaptives und inkrementellesVorgehen schrittweise einführen!

Inkrementelle Einführung / Überarbeitung quer über alle (geeigneten) PRODUKT-TeamsSchritt 1

„Produkte“ bzw. „Services“ identifizieren und Teams (als Produkt- bzw. Service-„Supplier“) danach strukturieren.Je ein Product Owner bzw. Service Owner (als Repräsentant des „Customers“) pro Produkt- (bzw. Service-)Team. Verantwortung für „WAS“ und „WIE“ trennen:

PO/SO erstellen Product/Service Backlogs als einzige Basis für das „WAS“ der Arbeit der Teams.Teamleiter als „WIE-Verantwortliche“ etablieren. Sie sind Vorgesetzte der Entwickler, nicht aber der PO/SOs.

Pro Produkt-/Service-Gruppe quer über alle dazu beitragende Teams synchronisierte Releases mindestens alle 3 Monate (Agile Release Train)Abbau der „Vorgehens-Schulden“, z.B:• Welche strategisch relevanten Probleme sind zu lösen?• Was bedeutet für uns "Agilität", was soll sie - strategisch relevant - konkret bewirken? Assessment• Abstimmung mit der IT-übergordneten Produktentwicklung und dem Portfolio-, Programm- und

Release-Management• DoR & DoD der "potential shipable increments" pro Release und (später möglichen) Sprints und pro

Team; (Re-)Professionalisierung des Requirement Engineerings• Teamübergreifende Koordination pro Produkt und Release• (Re-)Professionalisierung der SW-Entwicklung; TDD & ATDD; Integration von Entwicklung & Test• Continuous Integration, Continuous Delivery und Testautomation• Reduktion der Systemheterogenität; Applikations- und Systemarchitektur modellieren & bereinigen

© www.korn.ch

Schritt 2 für Teams, die mehr in Richtung Agilität gehen möchten (sofern betr. Dynamik, Kritikalität & Entwicklerkompetenz vertretbar):

Entwicklungsarbeit innerhalb der Releases in Sprints (2 bis 4 Wochen) unterteilen. Planning, Review und Retrospektive und Sprint Backlog einführen.

Teamleiter statt Erteiler von Detailaufträgen und als Detail-Koordinatoren jetzt Rahmensetzer und Unterstützer („dienende Führungskraft“).Teams erhalten möglichst viel Eigenverantwortung und Raum zur Selbstorganisation.

Schritt 3 für Teams, die voll auf Basis von Scrum arbeiten möchten (sofern betr. Dynamik, Kritikalität & Entwicklerkompetenz vertretbar):

Bei längerfristig (> 18 Monaten) stabilen Produkt- oder Service-Teams: Teamleiter übernehmen auch die Rolle der Scrum Master

Bei kurzlebigen Produkt- oder Service-Teams: Entwickler gehören zu "Entwicklerpools" (je rund 25 Personen) mit je einem personellen Vorgesetzten. Teams haben je einen Scrum Master, aber keinen Teamleiter

© www.korn.ch

Der 3. Weg: Statt entweder agil oder plangetrieben sowohl als auch

Quelle: Barry Boehm (University of Southern California) Richard Turner (George Washington University); Using Risk to Balance Agile and Plan-Driven Methods; 0018-9162/03/$17.00 © 2003 IEEE; June 2003, pp 57 - 66

Wie verbreitet sind agile Methoden in deutschen Unternehmen? Mit dieser Frage rief Prof. AyeltKomus im Frühjahr 2012 zur Teilnahme an der Studie „Status quo Agile“ auf und 350 Vertreter deutscher Unternehmen antworteten. Seit 2008 boomen agile Methoden, vor allem Scrum wird eingesetzt, um die Produktentwicklung zu beschleunigen. Aber wie die Studie von Prof. Komus auch zeigt: Als „durchgängig agil“bezeichnen ihre Projekte nur 16% der Befragten. Wesentlich öfter sind Mischformen aus klassischen Methoden des Projektmanagements und agilen Ansätzen zu finden. Quelle: http://borisgloger.com/newsletter/oktober-2012/quo-vadis-agile/?utm_source=Newsletter&utm_campaign=89cc7711d1-NL201210&utm_medium=email

Spezielle Herausforderungen

an die OE / PE

Team A

Team B

Team C

Team D

Team F

Team G

Team H

Team E

Monat

Multiprodukt / M-team / M-projekt Management

Bereinigung: Produkt- statt ProjektfokusZitate aus „Scrum Guide 2011“:

Scrum ist ein Framework zur nachhaltigen Entwicklung komplexer Produkte.Der Product Owner ist für die Maximierung des Wertes des Produktsund der Arbeit, die das Entwicklungs-Team verrichtet, verantwortlich.

Das Product Backlog ist eine geordnete Liste mit allem, was in dem Produkt benötigt werden könnte. Es ist die einzige Quelle von Anforderungen für jedwede Änderungen an dem Produkt.

Anforderungen hören nie auf sich zu ändern, was das Product Backlog zu einem lebenden Artefakt macht. So lange ein Produkt existiert, existiert auch ein Product Backlog. ((.. und „sein“ PO & Team))

Jeder Sprint kann als Projekt verstanden werden, für das ein zeitlicher Rahmen von maximal einem Monat zur Verfügung steht.

Agile Methoden sind keine Projektmanagementmethoden, sondern Organisationsmethoden, bei denen man in einem kontinuierlichen Prozess zum Beispiel ein Produkt entwickelt und immer weiter entwickelt. Dabei wird ein kontinuierlicher, gleichmäßiger Fluss angestrebt, in dem die Leistung kontinuierlich gesteigert und die Ergebnissicherheit immer weiter verbessert wird.

Interessanterweise werden oft Aufgabenstellungen als Projekte verstanden, die im eigentlichen Sinne gar keine sind. Schließlich ist mit der Einführung eines Softwareproduktes, eines Geschäftsprozesses, eines neuen Autos oder einer neuen SAP-Lösung die Arbeit nicht abgeschlossen. Vielmehr geht es um kontinuierliche Verbesserung der Lösungen und der Nutzung derselben.

Wahrscheinlich ist das eines der Hauptprobleme klassischer Projektmanagementmethoden. Sie beruhen auf dem Gedanken „Es gibt eine Fertigstellung und dann ist die Arbeit getan.“ Außerdem verleitet diese Denkweise dazu, viel zu große Aufgabenstellungen in einem Stück zu bearbeiten.

Prof. Ayelt Komus, „Quo vadis Agil“, Oktober 2012http://borisgloger.com/newsletter/oktober-2012/quo-vadis-agile/?utm_source=Newsletter&utm_campaign=89cc7711d1-NL201210&utm_medium=email

Bereinigung: Produkt/Service- statt System-Fokus…

… schwierig bei Systemheterogenität

Überlegungen zum „Zuschneiden“ der Teams 1v2

• Teams werden in erster Linie nach den zu liefernden SW-Produktenoder SW-Services und nicht nach Projekten strukturiert.

• Sie sind längerfristig (mind. 18 Monate) personell stabil und daher auch als Organisationseinheiten der Primärorganisation gestaltet.

• Vorzuziehen ist dabei die Strukturierung nach nutzerorientierten Funktionen („Feature Teams“).

• Je grösser das für ein spezielles IT-System benötigte Expertenwissen und die Integritätsanforderung an dieses System ist und je häufiger es von verschiedenen nutzerorientierten Funktionen (d.h. von diversen Produkt/Service-Teams) benötigt wird, umso eher sollte dieses IT-System von einem spezifischen „Component Team“ bearbeitet werden.

• Jedes Team verfügt über permanente, stets voll aufgelastete und daher ungeteilte Mitglieder / Spezialisten die insgesamt zum Definieren / Realisieren / Testen der SW-Produkte oder -Services des Teams nötig sind.

© www.korn.ch

Überlegungen zum „Zuschneiden“ der Teams 2v2• Jedes Team kann pro Release und allein (= ohne Zulieferungen anderer Teams oder von Spezialisten ausserhalb des Teams jedoch mit temporär zum Team gehörenden „shared ressources“) ein technisch und funktional getestetes SW-Inkrement als in sich geschlossenen Teileiner teamübergreifenden end-to-end-Funktionalität herstellen

• Dieses SW-Inkrement ist abgegrenzt durch möglichst wenige und gut definierbare Schnittstellen zu den SW-Inkrementen der anderen Teams

• Das Inkrement ist zu Beginn der Releasebearbeitung so weit definiert, dass die Schnittstellen als stabile "Stubs" realisiert werden können

• Jedes Team realisiert innerhalb der Releasebarbeitung sein Inkrement entweder kontinuierlich (Kanban-basiert) oder timeboxed(in Sprints) schrittweise, sodass innerhalb dieser StubsZwischenresultate möglichst früh technisch integriert und funktional getestet werden können um den teamübergreifenden Integrations- und Testaufwand am Ende der Releaseentwicklung zu minimieren

© www.korn.ch

Der Product Owner als Rahmensetzer für das "WAS"Der Product Owner ist für die Maximierung des Wertes des Produkts und der Arbeit, die das Entwicklungs-Team verrichtet, verantwortlich. Für unterschiedliche Organisationen, verschiedene Scrum Teams und Einzelpersonen kann es viele Wege zur Erreichung dieses Ziels geben.Der Product Owner ist als einzige Person für die Verwaltung des ProductBacklog verantwortlich.

Der Scrum Master als Rahmensetzer für das „WIE“ (Vorgehen und die Methoden und Tools der Entwicklung) - nicht nur „Coach“ und „Berater“Der Scrum Master ist dafür verantwortlich, dass Scrum verstanden und korrekt angewandt wird. Dies erreichen Scrum Master durch die Sicherstellung, dass das Scrum Team sich konform zur Scrum Theorie verhält und die gültigen Praktiken und Regeln einhält. Der Scrum Master ist eine dienende Führungskraft („servant-leader") für das Scrum Team. Dazu gehört u.a:• Unterrichtung und Führung des Entwicklungs-Teams bei der Erstellung von Produkten mit hohem Wert;• Entfernung von Hindernissen, die den Arbeitsfortschritt des Entwicklungs-Teams aufhalten

Quelle: Scrum Guide 2011

Der Scrum Master: Eine jede Organisation überfordernde Idealisierung?Aus "Scrum Guide 2011":

Der Scrum Master dient dem Product Owner unter anderem indem er:Vision, Ziele und Einträge des Product Backlogs gegenüber dem Entwicklungs-Team klar kommuniziert;

„Sprachrohr“ & „Übersetzer“ des PO gegenüber dem Entw.-Team; Teil der Führungsverantwortung des „klassischen“Teamleiters

Ein Verständnis dafür schafft, wie langfristige Produktplanung in einem empirischen Arbeitsumfeld funktioniert;Berater für Produktentwicklung in komplexen Umgebungen

ein Verständnis dafür schafft, was Agilität ist und wie man sie lebt;Berater für das agile Vorgehen im allgemeinen - nicht nur für Scrum

Der Scrum Master dient dem Entwicklungs-Team. Dazu gehört:Coaching des Entwicklungs-Teams zu selbstorganisiertem und interdisziplinären Handeln;

OE- und PE-Experte und Coach (= ausserhalb des Teams stehend, Haltung der „Absichtslosigkeit“)Unterrichtung und Führung des Entwicklungs-Teams bei der Erstellung von Produkten mit hohem Wert;

Zentraler Teil der Führungsverantwortung des „klassischen“ Teamleiters; Rollenkonflikt mit der Rolle eines „Coaches“Entfernung von Hindernissen, die den Arbeitsfortschritt des Entwicklungs-Teams aufhalten;

Teil der Führungsverantwortung des „klassischen“ Teamleiters; erfordert sehr oft Eskalationen entlang der Führungslinie und somit eine Führungsposition in der Hierarchie

Coaching des Entwicklungs-Teams in Unternehmensumfeldern, in denen Scrum noch nicht voll verstanden oder genutzt wird. OE- Experte und Coach (= ausserhalb des Teams stehend, Haltung der „Absichtslosigkeit“)

Der Scrum Master dient der Organisation. Dazu gehört:Führung und Coaching der Organisation bei der Umsetzung von Scrum;

OE- und UE-Experte - mit einem klarem Auftrag von der Organisationsleitung. Achtung: „Führung“ und „Coaching“ sind einander ausschliessende Rollen. (Oder wird hier „Coaching“ als „Training“ verstanden?)

Planung von Scrum-Einführungen in der Organisation; Unterstützung der Mitarbeiter und Interessenvertreter dabei, Scrum und empirische Produktentwicklung zu verstehen und richtig anzuwenden;

wie obenAnstoßen von Veränderungsprozessen, welche die Produktivität des Scrum Teams verbessern;

Teil der Führungsverantwortung des „klassischen“ TeamleitersZusammenarbeit mit anderen Scrum Mastern, um den effektiven Einsatz von Scrum innerhalb der Organisation voranzutreiben.

Mitglied einer org-internen „Community of Practice“ mit Umsetzungskompetenz via klarem Auftrag von der Organisationsleitung.

Der Scrum/Agile Master als Führungskraft der Linienorganisation

aus http://scaledagileframework.com/scrum-agile-master/

The Scrum/Agile Master is the Agile Teams working servant leaderwho helps assure that the team follows the rules of Scrum/Agile,helps them meet their daily and iteration objectives, works to remove impediments, facilitates continuous improvement, and coordinatessolution implementation and delivery with other Scrum/Agile Masters on the Release Train.

The Scrum Master is the team-based management/leadership proxy whose role is to assist the team in its transition to the new method and continuously facilitate a team dynamic intended to maximize performance of the team.

In teams that do not adopt Scrum, a comparable leadership role typically falls to a team lead, an internal or external coach, or the team’s line manager.

NACHDENKANGEBOT:

Falls in einigen Bereichen der Entwicklung physischer Produkte ein iteratives / inkrementelles und adaptives Vorgehen angemessen ist, dann:

Von verschiedenen „agilen“Vorgehensweisen die passenden Elemente angepasst nutzen und weitere Elemente hinzufügen.

„Don‘t apply so called best practices for your specific situation!“

© www.korn.ch

SCRUM und physische Produkte: Eine Einführung20physische%20Produkte%20... · 2012-11-26 · SCRUM...

Documents

Transcript of SCRUM und physische Produkte: Eine Einführung20physische%20Produkte%20... · 2012-11-26 · SCRUM...