nachteile von scrum - hs-augsburg.degori/agileswe/script-scrum-03.pdf · wpf - in7, wi7, ti7, iam7...

WPF - IN7, WI7, TI7, IAM7

Scrum

Nachteile von Scrum


Scrum

Nachteile von Scrum

● Rahmenwerk, aber kein Werkzeug● Die Sprintdauer● Die Planung & Das Design● Der Scrum Master● Die Skalierung● Thema “Festpreis”● Braucht eine gewisse Anlaufphase für

valide Schätzungen


Scrum

Nachteile von Scrum

● „Tunnelblick-Gefahr" bei ausschließlicher Fokussierung auf Tasks

● Erschwerte Koordination mehrerer Entwicklungsteams bei Großprojekten

● Potenzielle Verunsicherung aufgrund fehlender Zuständigkeiten und Hierarchien

● Potenzielle Unvereinbarkeit mit bestehenden Unternehmensstrukturen


Scrum

Nachteile von Scrum

● Kein Gesamtüberblick über die komplette Projektstrecke

● Hoher Kommunikations- und Abstimmungsaufwand

● Wenige konkrete Handlungsempfehlungen

● Zeitverluste bei zu „defensiven" Sprintplanungen


Scrum

Gründe, warum Scrum scheitern kann

● Lange Entwicklung, kaum Änderungen ○ Ist ein Projekt absolut überschaubar

und stets mehr bekannt, als unbekannt, braucht man Scrum nicht zwingend.


Scrum


● Scrum Basics werden nicht beherrscht○ Selbstorganisation, Timeboxing,

Gemeinsam verantwortung übernehmen, ...


Scrum


● Keine klaren Ziele ○ Wichtig ist eine übergreifende

Produkt-Vision sowie Teilziele für jeden einzelnen Sprint


Scrum


● Mangelnde Transparenz ○ Wofür mach ich das hier eigentlich?○ Schaffen wir es, alle Features

tatsächlich bis Q4 fertig zu stellen?


Scrum


● Fehler sind nicht zulässig ○ „Du musst Fehler machen, sonst lernst

du nichts!“○ Ziel: Fehler frühzeitig erkennen!


Scrum


● Falsche Rollenbesetzung ○ Product Owner ○ Scrum Master


Scrum


● Rollen als Teilzeit-Job ○ Ein Product Owner sollte nie mehrere

Teams oder Projekte managen○ Scrum Master zu Beginn auch nur für

ein Team!


Scrum


● Ignoranz gegenüber agilen Werten ○ Jeder versteht sie in der Theorie, aber

in der Praxis muss man hart dafür arbeiten


Scrum


● Lost in Management und Reports○ Ziel: Man überträgt mehr

Verantwortung auf jeden einzelnen und benötigen daher keine Kontroll-Reports mehr


Scrum


● Zu viele Störungen von außen/Management○ v.a. während eines laufenden Sprints


Scrum Features

Überblick - Scrum sonstige Features

● Sprintabbruch● POC● Spike● Generalist vs. Spezialist● Brown Bag Session● Nexus Scrum


Scrum Features

Sprintabbruch● vorzeitige Abbruch durch ScrumMaster● sollte eine absolute Ausnahme sein ● gerade unerfahrene Teams verschätzen sich● ScrumMaster zum Abbruch des Sprints drängen● meistens ist das jedoch nicht erforderlich● geeignete Gegenmaßnahmen rechtzeitig ergreifen


Scrum Features

Sprintabbruch Mögliche Gründe● unvorhersehbar drastische Änderungen des

Arbeitsumfelds● die Unmöglichkeit, Hindernisse (rechtzeitig) aus dem

Weg zu räumen ● massive Fehleinschätzung der Aufwände für den

aktuellen Sprint


Vorgehensmodelle

Spike


Vorgehensmodelle

Spike Notwendigkeit:● Team hat nicht genug Informationen/Erfahrung für eine

realistische Schätzung● Team fehlt Verständnis für die Komplexität einer

Aufgabe Ziel: sinnvolle Schätzung oder ein sinnvoller Storyschnitt (oder auch: Es gibt keine Lösung)


Vorgehensmodelle

Spike Ein Spike ● ist eine experimentelle Lösung, die auch durch alle

Layer gehen kann.● ist zeitlich begrenzt● wird am Ende immer verworfen (geht nicht produktiv)● endet in einer Dokumentation des Ergebnisses


Vorgehensmodelle

Spike

Wann? Ein Spike sollte die Ausnahme sein. Indiz für die Notwendigkeit ist, dass ● sich das Team nicht auf eine Komplexität einigen kann● die Story als zu komplex erachtet wird (und fachlich

nicht mehr geschnitten werden kann) ● keine Gewissheit im Team über die grobe Umsetzung

der Story herrscht


Vorgehensmodelle

POC

● Proof of Concept● Ähnlich zu Spike● Shipable Code? ● Ergebnis: Prototyp + Testlauf● Einsatzgebiet: z.B.

○ Performancetests ○ Neue Libaries○ Neue Techniken


Vorgehensmodelle

Brown Bag Session

● Trainings- oder Informationsveranstaltung während der die Zuhörer Speisen und Getränke einnehmen können

● Ziel: Nutzung von regulären Pausen, z. B. der Mittagspause, um Informationen zu vermitteln

● freiwillige Teilnahme und eine informelle Atmosphäre aus


Vorgehensmodelle

Generalist vs. Spezialist


Vorgehensmodelle


Weitere Agile Methoden

Überblick - Alternativen

● eXtreme Programming● Feature Driven

Development● Crystal● Kanban



Überblick - Scrum auf einen Blick

● Relativ leicht zu erlernen● Lässt sich schnell einsetzen● Definiert klare Rollenverteilung (Team, PO,

SM)● Definiert einen gut strukturierten, aber

dennoch flexiblen Entwicklungsprozess● Setzt auf selbstorganisierte Teams● Reine Managementmethode - macht keine

Vorgaben bzgl. Programmierung



eXtreme Programming

● anspruchsvolle agile Methode● recht genaue Vorgaben für:

○ Programmierung○ Zusammenarbeit Entwicklerteam○ gemeinsames Anforderungsmanagement

● Ineinander verzahnte Rückkopplungszyklen● "XP-Maschinerie mit Zyklen

unterschiedlicher Dauer



Die fünf Werte des eXtreme Programming

● Kommunikation● Rückkopplung● Einfachheit● Mut● Respekt



Die 14 Prinzipien des eXtreme Programming

● Menschlichkeit● Wirtschaftlichkeit● gegenseitiger

Vorteil● Selbstähnlichkeit● Verbesserung● Mannigfaltigkeit● Reflexion

● Fluss● Gelegenheit● Redundanz● Fehlschlag● Qualität● Babyschritte● akzeptierte

Verantwortlichkeit



Die 13 Primärpraktiken des eXtreme Programming

● Räumlich zusammensitzen

● Energiegeladene Arbeit

● Informative Arbeitsumgebung

● Komplettes Team● Pair-Programming● Stories

● Wochenzyklus ● Quartalszyklus● 10-Minuten-Build● Continuous Integration● Freiraum● Testgetriebene

Entwicklung● Inkrementeller Entwurf



Die 11 Folgepraktiken des eXtreme Programming

● echte Kundenbeteiligung● inkrementelles Deployment● Team-Kontinuität● schrumpfende Teams● ursachliche Analysen● gemeinsamer Code● Codierung und Testen● eine zentrale Codebasis● tägliches Deployment● verhandelbarer, vertraglicher Funktionsumfang● Bezahlung pro Benutzung



Zusammenfassung eXtreme Programming

● Legt großen Wert auf Qualitätssicherung durch testgetriebene Entwicklung und Pair-Programming

● Macht klare Vorgaben für Management, Team und Programmierung

● Äußerst mächtige, aber anspruchsvolle Methode



Feature-Driven Development● agile Methode, die sich deutlich von Scrum und

XP unterscheidet● stellt in vielen Organisationen eine gute Alternative

dar● Im Mittelpunkt: der Feature-Begriff:

○ jedes einzelne Feature stellt einen Mehrwert für den Kunden dar

○ die Softwareentwicklung wird durch die Features gesteuert



Feature-Driven DevelopmentIn FDD-Projekten sind die folgenden fünf Prozesse vorgesehen:

1. Entwickle ein Gesamtmodell2. Erstelle eine Feature-Liste3. Plane je Feature4. Entwirf je Feature5. Konstruiere je Feature



Feature-Driven Development



Feature-Driven Development - Zeitlicher Ablauf● "Entwickle Gesamtmodel" bis "Plane je

Feature" beanspruchen nur kurze Zeiträume (wenige Tage, max. 3 Wochen)

● Entwurf und Konstruktion im ständigen Wechsel

● Feature in max zwei Wochen realisiert● FDD Projekt kleiner 6 Monate● Rolle "Chefprogrammierer/Architekt"● Harmonisiert mit klassischen

Unternehmensstrukturen



Vorteile Feature-Driven Development● Stellt elegante Strukturierungsmöglichkeiten

für Anforderungen vor● Ist auch für große und heterogene

Projektteams gut geeignet● Bietet durch sein Rollenmodell eine gesunde

Basis für ein diszipliniertes Vorgehen● Ist für Festpreisprojekte sehr gut geeignet● Lässt sich leichter als andere agile Methoden

in große Organisationen einführen



Crystal● Keine einzelne Methode sondern Methodenfamilie● Grundidee:

○ kein Projekt gleicht dem anderen○ jedes Projekt ist in einer speziellen Situation

angesiedelt○ jedes Team ist besonders

● Fazit: Jedes Team stellt seine eigene Methode vor Projektbeginn zusammen

● Crystal bietet wenig allgemeine Vorgaben, aber einige generelle Prinzipien

● eine Reihe von optionalen Beispieltechniken



Kategorisierung nach Projekteigenschaften● zwei Dimensionen von Projekten

○ Anzahl der Personen ○ Größe des Risikos

● Sehr große Teams erfordern andere Methoden als Teams mit nur wenigen Mitgliedern

● lebenskritische Software muss nach anderen Kriterien entwickelt werden als ein Bibliothekssystem



Kategorisierung nach Projekteigenschaften● vier verschiedene Risikostufen und sieben

Projektgrößen● Den Projektgrößen werden unterschiedliche

Farben zugeordnet, nach denen er dann einzelne Methoden aus der Crystal-Familie benennt: Crystal Clear, Crystal Yellow, Crystal Orange usw.)



Crystal



Die Prinzipien von Crystal● Häufige Auslieferung ● Verbesserung durch Reflektion ● Enge Kommunikation● Persönliche Sicherheit ● Fokus● Leichter Zugriff auf (Experten-) Anwender● Technische Umgebung mit automatisierten Tests,

Konfigurationsmanagement und häufiger Integration


Beispiel Crystal Clear (allgemein)

1. Projekt klassifizieren2. Team erstellen aus

- Executive Sponsor- Lead Designer- weitere Designer und Programmierer - ein oder mehrere erfahrene User

3. "Exploratory 360" durch das Team um Informationen über das Projekt zu sammeln und zu bestimmen, ob es einen Mehrwert für die Organisation ergibt und ob es technisch machbar ist.4. Fine-Tuning der Methodik für das Projekt (basiert auf Erfahrungen der Vergangenheit und alle Praktiken, die vom Management vorgegeben werden)


Beispiel Crystal Clear (allgemein)

5. Das Team erstellt einen initialen Projektplan (z.B via "Blitz Planung")6. Das Team startet den ersten "Lieferungs-Zyklus" (eine oder mehrere Iterationen). Ergebnis: getestetes, lauffähiges Increment und Retrospektive7. Das Team startet den nächste "Lieferungs-Zyklus"(falls erforderlich: Release Plan anpassen)8. Diesen Workflow wiederholen, bis das Projekt Executive Sponsor gestoppt wird oder die Ziele des Projekts erreicht wurden



Die Vorteile von Crystal● individuelle Zusammenstellung einer eigenen

Methode● auch für sehr große Projekte geeignet● auch Festpreisprojekte werden ausdrücklich

berücksichtigt● auf die Akzeptanz der neuen Software wird

großer Wert gelegt● nicht so strikt wie eXtreme Programming, daher

guter Einstieg● individuelle Unterschiede der Teammitglieder

werden berücksichtigt



Was ist Kanban

● ein agiler Ansatz, der Erkenntnisse aus der Lean Production mit Ergebnissen der Engpasstheorie und der Fluss-basierten Produktentwicklung verbindet

● Übertragung dieser auf die IT ● Fokus auf die gesamte Wertschöpfungskette● über die reine Softwareentwicklung hinaus● Kanban auch häufig in Wartung und Betrieb



Three Basic Principles

● Visualize what you do today (workflow)

● Limit the amount of work in progress (WIP)

● Enhance flow



Kanban● Menge an paralleler Arbeit, den Work in Progress (WIP),

beschränken ● Durchlaufzeiten von einzelnen Anforderungen verkürzen● Kanban-Board mit verschiedenen Prozessschritte ● Anforderung durchläuft den jeweiligen Workflow ● Anforderungen wandern als Tickets durch alle Stationen

bis sie komplett erledigt sind● Für jede einzelne Station Limits (parallel bearbeitet) ● Puffer zwischen den einzelnen Stationen möglich ● Anforderungen dürfen nur dann zur nächsten Station

weiterwandern, wenn diese freie Kapazitäten hat (Pull-Prinzip)



Kanban



Vorteile Kanban

● Schafft schnell hohe Transparenz über Projektfortschritt und akute Probleme.

● Geht über die reine Softwareentwicklung hinaus und beleuchtet auch Bereiche wie Testing, Wartung und Systemadministration.

● Gut geeignet für Organisationen mit starker Arbeitsteilung und Spezialisierung.

● Lässt sich behutsam in bestehende Prozesse (gleichgültig ob agil oder nicht) integrieren und schrittweise anpassen.

● Fördert eine gleichmäßige und nachhaltige Geschwindigkeit (Sustainable Pace).



Vergleich


Scrum Tools

Überblick - Scrum Tools

● Version Control (GIT/SVN)● Jenkins ● Confluence● Fisheye● Jira


Scrum Tools

Subversion


Scrum Tools

Subversion - Branchen


Scrum Tools

Subversion - Mergen


Scrum Tools

Subversion - Ziele

● Merge Aufwände niedrig halten● Branches/Tags niedrig halten● Maximale Flexibilität


Scrum Tools

Jenkins - Buildumgebung● Continuous Integration Tool● Webbasiert● Monitoring Tool● Automatische Builds● Automatische Container Tests● Feedback Panel● Schöne GUI


Scrum Tools


Scrum Tools

Confluence - Wiki● webbasierte Anwendung● Wiki für Unternehmen● Gutes Rechte/Rollen System● Wiki Markup Language● Viele Plugins● Performante Suche● HTML5 Features● http://www.atlassian.com/software/confluence/

overview


Scrum Tools

Confluence - Wiki


Scrum Tools

Crucible Fisheye● webbasierte Anwendung● Code Review Tool● Gute Integration mit SVN oder CVS● Kann nur Änderungen anzeigen● Gute farbliche Markierung der Änderungen● Diskussionsplattform


Scrum Tools - Code Review Tool


Scrum Tools - Crucible


Scrum Tools

JIRA● webbasierte Anwendung● Fehlerverwaltung bzw. Problembehandlung● operatives Projektmanagement● frei konfigurierbar● Unterstützt Drag and Drop Haptik


Scrum Tools - JIRA - Taskboard


Scrum Tools - JIRA - Planning


Scrum Tools - JIRA - Allgemein


Teambuilding

Überblick Teambuilding

● Phasenmodell● Johari Fenster● DISG● Kommunikation


Teambuilding

Teamuhr


Teambuilding

Teamuhr

● Forming (Orientierungsphase) ● Storming (Konfrontationsphase)● Norming (Kooperationsphase)● Performing (Wachstumsphase)● Adjourning (Auflösungsphase)


Teambuilding

Johari Fenster


Teambuilding

Johari Fenster

Öffentlich: sich selbst und anderen bekanntAnteile der Persönlichkeit, die nach außen sichtbar und von anderen wahrgenommen werden. (im Vergleich mit den anderen Teilen meist eher klein)

Geheim: sich selbst bekannt, anderen verborgenGeheim ist alles, was der Betroffene weiß oder kennt, aber anderen nicht zugänglich macht oder aktiv vor ihnen verbirgt.


Teambuilding

Johari FensterBlinder Fleck: sich selbst unbewußt, das nehmen andere wahrAlles, was vom Betroffenen ausgesendet und vom Empfänger wahrgenommen wird, ohne dass sich der Betroffene dessen bewusst ist. Andere erkennen Charakteristika, die der Betroffene bei sich selbst nicht erkennt.

Unbekannt: Weder einem selbst noch anderen bekanntEs handelt sich um unenthülltes Terrain, welches (noch) niemandem bekannt ist


Teambuilding

Johari Fenster

Ziel: das linke obere Feld vergrößern

Möglichkeiten: ● sich preisgeben● Feedback annehmen


Teambuilding

DISG Persönlichkeitstest

● Dominanz● Initiative ● Stetigkeit ● Gewissenhaftigkeit


Teambuilding

DISG Persönlichkeitstest


Teambuilding

Dominanter Typ

Ziel: Durchsetzten eigener Ziele und Absichten

Grundangst: Versagen

Grundbedürfnis: Erfolg zu haben

Motivation: Möglichkeint, etwas zu bewegen, andere zu motivieren; Fehler auszumerzen; Konflikte einzugenen und bestehen; sich durchsetzen


Teambuilding

Initiativer Typ

Ziel: Das Umfeld formen, andere einbinden, um Ergebnisse zu erzielen

Grundangst:Benachteiligt zu werden

Grundbedürfnis: Akzeptiert zu werden

Motivation: Möglichkeit, Spaß zu haben; die Gefühle anderer verstehen; mit Menschen umgehen; Angst unterdrücken, indem sie in Bewegung bleiben und Zeit u. Mühe nicht aufrechnen


Teambuilding

Stetiger Typ

Ziel: Mit anderen zusammenarbeiten, um Ergebnisse zu erzielen

Grundangst:Alleine zu sein

Grundbedürfnis: Sicherheit

Motivation: Möglichkeit, die wahren Gefühle auszudrücken; ablehnen, was ihren Vorstellungen widerspricht; von anderen wichtig genommen werden; Forderungen ggü. anderen rechtfertigen


Teambuilding

Gewissenhafter Typ

Ziel: Mit anderen über mögliche Konsequenzen von Aktivitäten reden

Grundangst: Kritisiert zu werden

Grundbedürfnis: Dinge richtig machen

Motivation: Möglichkeit, andere fair zu behandeln; die Welt verbessern; Fehler ausmerzen; die eigene Ansicht rechtfertigen; alles nach einer einheitlichen Vorstellung beurteilen, sich von bedrohlichen Dingen fern halten


Teambuilding

Fremdwahrnehmung - Eingenwahrnehmung


Teambuilding

Motivation


Dynamische Kommunikation


Teambuilding

DISG - Hinweise

● Es handelt sich um beobachtbares Verhalten, nicht um Eigenschaften oder Einstellungen

● Das Verhalten wird relativ zu anderen beschrieben● Jeder Typ möchte emotional und sachlich

angesprochen werden● Das Verhalten ist vom Kontext (priv./brfl.)

abhängig● Alle Typen haben ihre spezifischen Vorteile● Es gibt einen bevorzugten und stellvertretenden

Stil


Teambuilding

Schulz von Thun - Vierseitenmodell


Teambuilding

Schulz von Thun - Vierseitenmodell

1. Sachinhalt: „Worüber ich informiere“

2. Selbstoffenbarung: „Was ich von mir selbst kundgebe“ (Ich-Botschaft)

3. Beziehung: „Was ich von dir halte oder wie wir zueinander stehen“

4. Appell „Wozu ich dich veranlassen möchte“


Teambuilding

Sachebene

Auf der Sachebene vermittelt der Sprecher Daten, Fakten und Sachverhalte. Aufgaben des Sprechers sind Klarheit und Verständlichkeit des Ausdrucks. Mit dem „Sach-Ohr“ prüft der Hörer die Nachricht mit den Kriterien der Wahrheit (wahr/unwahr), der Relevanz (von Belang/belanglos) und der Hinlänglichkeit (ausreichend/ergänzungsbedürftig). In einem eingespielten Team verläuft dies meist problemlos.


Teambuilding

Selbstoffenbarung

Jede Äußerung bewirkt eine nur teilweise bewusste und beabsichtigte Selbstdarstellung und zugleich eine unbewusste, unfreiwillige Selbstenthüllung (siehe Johari-Fenster). Jede Nachricht kann somit zu Deutungen über die Persönlichkeit des Sprechers verwendet werden. Das „Selbstoffenbarungs-Ohr“ des Hörers lauscht darauf, was in der Nachricht über den Sprecher enthalten ist (Ich-Botschaften).


Teambuilding

Beziehungsebene

Auf der Beziehungsebene kommt zum Ausdruck, wie Sprecher und Hörer sich zueinander verhalten, und wie sie sich einschätzen. Der Sprecher kann – durch die Art der Formulierung, seine Körpersprache, Tonfall und anderes – Wertschätzung, Respekt, Wohlwollen, Gleichgültigkeit, Verachtung in Bezug auf den Anderen zeigen. Abhängig davon, was der Hörer im „Beziehungs-Ohr“ wahrnimmt, fühlt er sich entweder akzeptiert oder herabgesetzt, respektiert oder bevormundet.


Teambuilding

Appell

Wer sich äußert, will in der Regel auch etwas bewirken. Mit dem Appell will der Sprecher den Hörer veranlassen, etwas zu tun oder zu unterlassen. Der Versuch, Einfluss zu nehmen, kann offen oder verdeckt sein. Offen sind Bitten und Aufforderungen. Verdeckte Veranlassungen werden als Manipulation bezeichnet. Auf dem „Appell-Ohr“ fragt sich der Empfänger: „Was soll ich jetzt denken, machen oder fühlen?“


Teambuilding

Beispiel

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Vielen Dank für Ihre Aufmerksamkeit!


Teambuilding

DISG - Test

http://www.psychomeda.de/online-tests/persoenlichkeitstest.html

Google: "DISG test online" -> 3. Link

WPF - IN7, WI7, TI7, IAM7WS 2011/12

http://www.psychomeda.de/online-tests/persoenlichkeitstest.html

http://www.business-wissen.de/personalmanagement/disg-persoenlichkeitsprofil-persoenliche-staerken-und-schwaechen-besprechbar-machen/beispiele-und-ziele-vom-disg-persoenlichkeitsprofil/

http://de.wikipedia.org/wiki/Johari-Fenster

nachteile von scrum - hs-augsburg.degori/agileswe/script-scrum-03.pdf · wpf - in7, wi7, ti7, iam7...

Documents