Bei agilen Projekt ist Scrum zurzeit die Nr. 1. Trotzdem entscheiden sich Unternehmen immer wieder Scrum nur unvollständig einzuführen. Aber ist das wirklich eine gute Idee und kann das funktionieren?
In diesem Vortrag wird anhand von Praxisbeispielen gezeigt, was eine teilweise Einführung in der Realität bedeutet. Wir erfahren hierdurch, welche Elemente von Scrum unabhängig eingeführt werden können, aber was verloren geht, wenn Scrum nicht vollständig eingeführt wird. Außerdem gehen wir der Frage nach, ob es wirklich immer Scrum sein muss.
10. Tourismus: Was wurde
umgesetzt?
Rollen Ereignisse Artefakte
DailysSprints
SM PO
Product
Backlog
Sprint
Planning
Refinement
Review Retrospective
DEV
SM PO
DEV
Cross-funktionales
Developmentteam
Scrum
Master
Product
Owner
Sprint
Backlog
PSP
15. Logistik
PO nicht alleinig entscheidungsbefugt
Fachabteilung ist unerfahren & unterbesetzt
Fachabteilung als PO
*
16. Logistik: Was wurde umgesetzt?
Rollen Ereignisse Artefakte
DailysSprints
SM PO
Product
Backlog
Sprint
Planning
Refinement
Review Retrospective
DEV
SM PO
DEV
Cross-funktionales
Developmentteam
Scrum
Master
Product
Owner
Sprint
Backlog
PSP
19. Wartung
Neuer Ansatz zur Begutachtung von technischen Anlagen
Mehrfach verändertes Geschäftsmodell
Innovationsprojekt
Viele technische Unbekannte
*
?
20. Wartung: Was wurde umgesetzt?
Rollen Ereignisse Artefakte
DailysSprints
SM PO
Product
Backlog
Sprint
Planning
Refinement
Review Retrospective
DEV
SM PO
DEV
Cross-funktionales
Developmentteam
Scrum
Master
Product
Owner
Sprint
Backlog
PSP
27. 1 - Iterationen
Sprints sind zeitlich begrenzt
2Variabel, 4 < Dauer <= 6 Wochen
4Variabel, Dauer <= 4 Wochen
5Konstant für die letzten 3 Sprints,
Dauer = 1 Monat
6Konstant für die letzten 3 Sprints,
Dauer = 4 Wochen
8Konstant für die letzten 3 Sprints,
Dauer = 3 Wochen
10
Konstant für die letzten 3 Sprints,
Dauer <= 2 Wochen
28. 2 - Qualitaetssicherung
Softwarefunktionen sind getestet und funktionieren am Ende der Iteration
2Automatisches Deployment mit allen
autom. Akzeptanztests alle 24 Stunden
1Einige Entwicklertests (Unit Tests)
1Entwicklertests (Unit Tests)
pro Story
2Funktionen werden vor
Review getestet
2Funktionen werden direkt nach
Fertigstellung getestet
2Team automatisiert Akzeptanztest
für jede Story
29. 3 - Sprint Stories
Spezifikation der Backlog Items
1Anforderungen für Sprint Items sind
spezifiziert
1Anforderungen sind unabhängige
und priorisierte User Stories
2User Stories starten mit „Als <Rolle>,
möchte ich <Ziel/Wunsch>, damit <Nutzen>“
2User Stories haben nachprüfbare
Akzeptanztests
2Das Team hat eine Definiton of Ready
2Das Team hat eine Definiton of Done
39. Prinzipien hinter dem Agilen
Manifest
1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung
wertvoller Software zufrieden zu stellen.
2. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse
nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und
bevorzuge dabei die kürzere Zeitspanne.
4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die
Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines
Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
40. Prinzipien hinter dem Agilen
Manifest
7. Funktionierende Software ist das wichtigste Fortschrittsmaß.
8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer
sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
10. Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell.
11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch
selbstorganisierte Teams.
12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt
sein Verhalten entsprechend an.
54. Wer das will ...
Empirische
Prozesssteuerung Agile Werte & Prinzipien
Transparenz
Überprüfung
AnpassungAnpassung
Unterschiedliche Perspektiven
Commitment
Kundenzufriedenheit
Direkte Kommunikation
Selbstorganisation
Einfachheit
Regelmäßige Auslieferungen
55. Muss das machen ...
Rollen Ereignisse Artefakte
DailysSprints
SM PO
Product
Backlog
Sprint
Planning
Refinement
Review Retrospective
DEV
SM PO
DEV
Cross-funktionales
Developmentteam
Scrum
Master
Product
Owner
57. MURCS
Wir machen jetzt Scrum, aber das Meeting passt leider
nicht und einen PO haben wir irgendwie auch nicht...
Ulf Mewe
@mewflu
Editor's Notes
Direkte Ansprache!
Warum diese Projekte!
(u.a. durch rechtliche Rahmenbedingungen) => Dokumentation
(u.a. durch rechtliche Rahmenbedingungen) => Dokumentation
Refinement und Review mit dem Kunden unregelmäßig
(u.a. durch rechtliche Rahmenbedingungen) => Dokumentation
(u.a. durch rechtliche Rahmenbedingungen) => Dokumentation
(u.a. durch rechtliche Rahmenbedingungen) => Dokumentation
Review: gemeinsamer Termin mit allen
(u.a. durch rechtliche Rahmenbedingungen) => Dokumentation
Review: gemeinsamer Termin mit allen
2011
Einfachheit -> Es wurde viel umgesetzt was nicht mehr nötig war, aber nie gestrichen / depriorisiert wurde
Commitment -> Es wurde sich nie auf diesen Umfang mit diesem Liefertermin von dem Team commitet.
