Scrum: Unterschied zwischen den Versionen

aus www.kruedewagen.de, Homepage von Ralf und Judith Krüdewagen (Kruedewagen)
Zur Navigation springen Zur Suche springen
(21 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 96: Zeile 96:
*Bindeglied zwischen Product Owner und Team, aber letztendlich nicht verantwortlich für Projekterfolg
*Bindeglied zwischen Product Owner und Team, aber letztendlich nicht verantwortlich für Projekterfolg
*je besser das Team Scrum anwendet, desto geringer wird die Rolle des Scrum Masters
*je besser das Team Scrum anwendet, desto geringer wird die Rolle des Scrum Masters
Literatur:
*[https://www.it-agile.de/fileadmin/agile_review/einzelartikel/Was_MachtDerScrumMasterDenGanzenTagArtikelagilereview201501hw.pdf Was macht der Scrum Master den ganzen Tag?] (PDF, it-agile.de)


== Artefakte und Ereignisse ==
== Artefakte und Ereignisse ==
Zeile 112: Zeile 115:
=== Priorisierung ===
=== Priorisierung ===
*[https://entwickler.de/online/agile/product-owner-backlogs-priorisieren-costs-of-delay-579754688.html Product Owner: Backlogs priorisieren mit Costs of Delay und Monte-Carlo-Simulationen] (entwickler.de) - ökonomische Aspekte in Kombination mit Simulationen als Grundlage
*[https://entwickler.de/online/agile/product-owner-backlogs-priorisieren-costs-of-delay-579754688.html Product Owner: Backlogs priorisieren mit Costs of Delay und Monte-Carlo-Simulationen] (entwickler.de) - ökonomische Aspekte in Kombination mit Simulationen als Grundlage
**Cost of Delay: Was kostet es, etwas '''nicht''' gemacht zu haben bzw. zu spät (verzögert) zu liefern?


== Probleme und Schwierigkeiten ==
== Probleme und Schwierigkeiten ==
Zeile 126: Zeile 130:
*Das Team soll die für die Entwicklung nötigen Tools selbst aussuchen können. Je nach Projekt sind verschiedene Tools nötig, die ggf. im Unternehmen nicht "unterstützt" werden. Beispiel: Revision Control Systeme.
*Das Team soll die für die Entwicklung nötigen Tools selbst aussuchen können. Je nach Projekt sind verschiedene Tools nötig, die ggf. im Unternehmen nicht "unterstützt" werden. Beispiel: Revision Control Systeme.
*Wie werden Change Requests bearbeitet ? -> Abbildung in die Scrum Methodik
*Wie werden Change Requests bearbeitet ? -> Abbildung in die Scrum Methodik
== Training ==
*[https://www.agile42.com/en/blog/2018/05/21/a-csm-a-cspo-scrum-training/ Advanced ScrumMaster and Scrum Product Owner training] (Agile42)


== Zertifizierung ==
== Zertifizierung ==
Zeile 152: Zeile 159:
*[http://www.heise.de/developer/artikel/Kriterien-fuer-eine-Entscheidung-fuer-Scrum-oder-Kanban-1071172.html Kriterien für eine Entscheidung für Scrum oder Kanban] (heise.de)
*[http://www.heise.de/developer/artikel/Kriterien-fuer-eine-Entscheidung-fuer-Scrum-oder-Kanban-1071172.html Kriterien für eine Entscheidung für Scrum oder Kanban] (heise.de)
*Scrum - Agiles Projektmanagement erfolgreich einsetzen, dpunkt.verlag; ISBN: 3898644782, [http://www.amazon.de/Scrum-Agiles-Projektmanagement-erfolgreich-einsetzen/dp/3898644782 Amazon]
*Scrum - Agiles Projektmanagement erfolgreich einsetzen, dpunkt.verlag; ISBN: 3898644782, [http://www.amazon.de/Scrum-Agiles-Projektmanagement-erfolgreich-einsetzen/dp/3898644782 Amazon]
*[https://www.dpunkt.de/buecher/12524/9783864903762-large-scale-scrum.html Large-Scale Scrum] (LeSS): Craig Larman und Bas Vodde, dpunkt, 2017, siehe c't 16/17 S.186
*[https://entwickler.de/online/agile/agile-infografik-579747334.html Das Agile Adventure – Infografik]
*[https://entwickler.de/online/agile/agile-infografik-579747334.html Das Agile Adventure – Infografik]
*[http://www.extremeuncertainty.com extremeuncertainty.com] [http://www.extremeuncertainty.com/deploy-not-same-as-release/],[http://www.extremeuncertainty.com/most-common-reason-agile-fails/]
*[http://www.extremeuncertainty.com extremeuncertainty.com] [http://www.extremeuncertainty.com/deploy-not-same-as-release/],[http://www.extremeuncertainty.com/most-common-reason-agile-fails/]
*[https://entwickler.de/online/agile/scrum-anpassen-hybrid-agile-579764517.html Scrum richtig anpassen: Vor- und Nachteile von Agile Hybrid-Frameworks]


*Kombination von Agil und Lean in der Softwareentwicklung (Scrum und Kanban), [[Informatik Spektrum]] 01/2014 S.28
*Kombination von Agil und Lean in der Softwareentwicklung (Scrum und Kanban), [[Informatik Spektrum]] 01/2014 S.28
Zeile 163: Zeile 172:
*[https://entwickler.de/online/produkt-planung-mit-produkt-roadmap-und-produkt-backlog-das-sind-die-unterschiede-2-149971.html Produkt-Planung mit Produkt-Roadmap und Produkt-Backlog – das sind die Unterschiede] (entwickler.de)
*[https://entwickler.de/online/produkt-planung-mit-produkt-roadmap-und-produkt-backlog-das-sind-die-unterschiede-2-149971.html Produkt-Planung mit Produkt-Roadmap und Produkt-Backlog – das sind die Unterschiede] (entwickler.de)
**[http://java.dzone.com/articles/product-roadmap-and-product The Product Roadmap and the Product Backlog]
**[http://java.dzone.com/articles/product-roadmap-and-product The Product Roadmap and the Product Backlog]
**https://www.thisisproductmanagement.com/episodes/working-with-engineers/ -> Roadmap mit Zielen (What, Why) statt Features (How)
*[http://www.agile42.com/en/blog/2015/03/28/there-no-planning-agile-right/ There is no Planning in Agile. Right?] (agile42.com)
*[http://www.agile42.com/en/blog/2015/03/28/there-no-planning-agile-right/ There is no Planning in Agile. Right?] (agile42.com)
*[https://www.scrumalliance.org/scrum/media/scrumalliancemedia/files%20and%20pdfs/state%20of%20scrum/scrum-alliance-state-of-scrum-2015.pdf The 2015 State of Scrum Report] (scrumalliance.org), siehe auch [https://entwickler.de/online/agile/scrum-bericht-2015-172593.html entwickler.de]
*[https://www.scrumalliance.org/scrum/media/scrumalliancemedia/files%20and%20pdfs/state%20of%20scrum/scrum-alliance-state-of-scrum-2015.pdf The 2015 State of Scrum Report] (scrumalliance.org), siehe auch [https://entwickler.de/online/agile/scrum-bericht-2015-172593.html entwickler.de]
Zeile 168: Zeile 178:
*Warum ist mein agiles Team langsam? (entwickler.de): [https://entwickler.de/online/agile/warum-ist-mein-agiles-team-langsam-193552.html Teil 1], [https://entwickler.de/online/agile/warum-ist-mein-agiles-team-langsam-teil-2-193576.html Teil 2]
*Warum ist mein agiles Team langsam? (entwickler.de): [https://entwickler.de/online/agile/warum-ist-mein-agiles-team-langsam-193552.html Teil 1], [https://entwickler.de/online/agile/warum-ist-mein-agiles-team-langsam-teil-2-193576.html Teil 2]
*[https://entwickler.de/online/agile/der-perfekte-scrum-master-195168.html Der perfekte Scrum Master – das unbekannte Wesen?] (entwickler.de)
*[https://entwickler.de/online/agile/der-perfekte-scrum-master-195168.html Der perfekte Scrum Master – das unbekannte Wesen?] (entwickler.de)
*[http://www.agile42.com/en/blog/2017/04/26/epic-budgeting-meeting-deadlines/ Epic Budgeting, or how Agile teams meet deadlines], [https://media.agile42.com/PCV17-EpicBudgeting-DaveSharrock.pdf Slides]
*[http://williamgill.de/2016/10/15/why-speed-is-not-the-same-as-velocity/ Speed is Not the Same As Velocity]
*[https://www.scrumalliance.org/community/articles/2014/december/why-do-agile-teams-fail Why Agile Teams Fail]
*[https://www.scrumalliance.org/community/articles/2013/september/how-to-manage-the-7-wastes%E2%80%9D-of-agile-software-dev The 7 Wastes of Agile]


*User Story Mapping, O'Reilly
*User Story Mapping, O'Reilly
Zeile 173: Zeile 187:
*[https://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/ Splitting user stories -- the hamburger method]
*[https://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/ Splitting user stories -- the hamburger method]
*[https://medium.com/@sherifmansour/how-weve-destroyed-user-stories-8b36120645c6 How we’ve destroyed user stories]
*[https://medium.com/@sherifmansour/how-weve-destroyed-user-stories-8b36120645c6 How we’ve destroyed user stories]
*[https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27 Replacing The User Story With The Job Story]


*Scum und Kanban
*Scum und Kanban
Zeile 185: Zeile 200:
**[https://entwickler.de/online/agile/die-details-der-definition-of-done-579760929.html Die Details der Definition of Done] (entwickler.de)
**[https://entwickler.de/online/agile/die-details-der-definition-of-done-579760929.html Die Details der Definition of Done] (entwickler.de)


*[https://entwickler.de/online/agile/product-owner-backlog-agile-scrum-579793245.html Der Product Owner: Backlog-Boss und Chaos-Bezwinger] (entwickler.de)
*[https://entwickler.de/online/agile/top-5-fehler-agile-579837449.html Die Top 5 der Fehler in der agilen Führung] (entwickler.de)
*[https://entwickler.de/online/agile/effektiverer-einsatz-scrum-579873512.html Scrum effektiver einsetzen? So geht’s!] (entwickler.de)
*Produktivität (messen/bewerten/planen)
**[https://nortal.com/us/blog/the-myth-of-developer-productivity/ The myth of developer productivity]
*[https://www.manage-agile.de/ Managed Agile]
**Flight Levels siehe [https://www.manage-agile.de/files/manageagile/site/vortraege2018/tag2/M3.1_Flughoehe-Manage_Agile_2018-10-17.pdf Präsentation] S.22 aus [https://www.manage-agile.de/archiv/downloads/handouts-2018.html Handouts der Manage Agile 2018]


=== Videos ===
=== Videos und Podcasts ===
*[https://www.youtube.com/watch?v=502ILHjX9EE Agile Product Ownership in a Nutshell]
*[https://www.youtube.com/watch?v=502ILHjX9EE Agile Product Ownership in a Nutshell]
*[https://meinscrumistkaputt.de meinscrumistkaputt.de] - Podcast für alle Agil-Interessierten
*[https://www.youtube.com/watch?v=c-8khkF77HQ Agiles Requirements Engineering], siehe auch [https://entwickler.de/online/agile/agiles-requirements-engineering-579884340.html entwickler.de]
*Spotify: https://www.youtube.com/watch?v=4GK1NDTWbkY , https://www.youtube.com/watch?v=vOt4BbWLWQw


== Quellenangaben ==
== Quellenangaben ==

Version vom 29. September 2019, 06:38 Uhr

Der Scrum-Prozess (Quelle Wikipedia)

Überblick

Was ist Scrum

  • Scrum ist eine Methodologie bzw. ein Vorgehensmodell für die Entwicklung von Produkten
  • iterativer und inkrementeller Prozess
    • für Produktentwicklung und Projektmanagement
    • oft und ursprünglich in der Softwareentwicklung
  • klassische Rollen und Strukturen werden ersetzt durch agile Methoden und Abläufe

Vorteile von Scrum

Wenn Scrum richtig angewandt wird, können sich folgende Vorteile ergeben:

  • schnellere Reaktion auf Kundenanforderungen durch frühzeitige Rückmeldungen
  • schneller Richtungswechsel möglich
  • klares Scoping gemäß Wert für den Kunden
  • kleine Produkt-Inkrements (Releases) mit wenigen Features, die dann aber auch funktionieren
  • kein endloses Entwickeln (mit zu vielen Features)
  • Ergebnisse sind schneller am Markt / beim Kunden
  • höhere Identifikation der Beteiligten am Produkt
  • größere Kreativität, Effizienz und Produktivität (und damit auch die Mitarbeiterzufriedenheit)
  • bessere Produkte

Drei Rollen

Product Owner und Team

Scrum kennt drei gleichberechtigte Management-Rollen:

  • Product Owner
  • Scrum Master
  • Team

Eigenschaften von Scrum

  • eingeteilt in Sprints (kurze zeitliche Projektabschnitte bzw. Arbeitszyklen) fester Länge
  • basiert oft auf Schätzungen (Zeit)
  • hohes Maß an Selbstorganisation (kein Teamleiter vorhanden)
  • Kundenzufriedenheit und Menschen stehen im Mittelpunkt (Vermeidung von Überlastungen)
  • Arbeitsweise und das Produkt werden fortlaufend bewertet und angepasst
  • Es werden nur Anforderungen umgesetzt, die einen Mehrwert bieten
  • Anforderungen mit höchster Priorität werden zuerst angegangen
  • Anforderungen mit den größten Risiken werden zuerst angegangen (um schnell andere Richtung einschlagen zu können)
  • Keine neuen Anforderungen oder Änderungen während des Sprints; diese werden ins Product Backlog eingetragen
  • Aufgaben/Features sind erst erledigt und werden "released", wenn wirklich alles fertig ist (auch Doku etc.)
  • Sprint-Ende wird niemals verlängert

Scrum erfordert

  • große Disziplin
  • hohe Selbstverantwortung
  • direkte Kommunikation aller Beteiligten (möglichst räumlich nahe)
  • Umdenken bei allen Beteiligten bzgl. der Rollen

Organisation

  • Sprint Planning Meeting (alle)
    • Team wählt aus dem Product Backlog Anforderungen aus, die im Sprint umgesetzt werden sollen. Diese werden ins Sprint Backlog übernommen.
  • Daily Scrum Meeting (alle, Product Owner optional)
    • Jedes Team-Mitglied berichtet über seine Aktivitäten der letzten Arbeitsstunden und über die nächsten Schritte. Hindernisse werden angesprochen.
  • Sprint Review Meeting (alle)
    • Arbeitsergebnisse werden dem Product Owner vorgestellt und von diesem abgenommen.
  • Sprint Retrospektive Meeting (alle)
    • Reflexion des Sprints
    • Was war gut bzw. schlecht ? Was kann verbessert werden ?
  • Product Backlog und Sprint Backlog als wichtige Mittel zur Dokumentation des Projekts

Rollen

Product Owner

  • ist verantwortlich für das Produkt (Deliverables) bzw. Ergebnisse des Projekts
  • vereint die klassischen Rollen des Produktmanagers, Chief Engineers, Projektmanagers (aus Business-Sicht)
  • erstellt und pflegt Produktvision (Releaseplan, Big Picture)
  • ist verantwortlich für finanzielle Ergebnisse und wirtschaftliche Ziele (Budget, Marge)
  • Schnittstelle zwischen Team und Stakeholdern (Kunde, Vertrieb, Support, 3rd Party, etc.)
  • erstellt Requirements aus den Kundenanforderungen (im Product Backlog)
    • in Zusammenarbeit mit dem Kunden
    • sortiert nach Priorität gemäß Wert für den Kunden (Business Value)
    • möglichst über den nächsten Sprint hinweg (im voraus)
  • erstellt User Stories (im Product Backlog)
    • detaillierte Beschreibung dessen, was vom Team geliefert werden soll (Features)
    • aus Sicht des Kunden und anderer Stakeholder
  • prüft Ergebnisse des Teams am Ende des Sprints (Abnahme)
  • prüft Qualität
  • Eigenschaften: kommunikativ, diplomatisch, technisches Wissen

Team

  • eigenverantwortlich für Produktentwicklung und technische Umsetzung
  • organisiert sich selbst (ohne Leader)
  • legt selbst verbindlich fest, welche und wieviele Anforderungen (Requirements) zu einer vorgegebenen Zeit (Sprint) bearbeitet und als User Stories umgesetzt werden (Commitment)
  • erstellt sich selbst Aufgaben (Tasks), um die Features (User Stories) umzusetzen
  • wähle kleine Tasks <= 1 Arbeitstag
  • dokumentiert Zustand der Tasks im Sprint Backlog (mit Angabe der noch benötigten Zeit)
  • Nicht die Zahl der Arbeitsstunden zählt sondern der geleistete Mehrwert
  • 80% der Arbeitszeit als Netto-Auslastung für das Projekt (Kapazität)

Scrum Master

  • Agile Leader, Team-Coach, Moderator
  • nur in Teilen mit der klassischen Rolle des Projektmanagers vergleichbar (nur als Projektbegleiter), ist aber nicht der Projekt Manager
  • verantwortlich für Einhaltung der Scrum-Regeln und Methoden
  • verantwortlich für das Beseitigen von Hindernissen und Konflikten, die das Team am weiterentwickeln hindern
  • schafft optimale Arbeitsbedingungen für das Team (Infrastruktur, Kommunikation, Tools, etc.)
  • sollte kein Entwickler sein (höchstens in einem anderen Projekt), da er sonst nicht objektiv genug seine Rolle wahrnehmen kann
  • auch hat er keine Personalverantwortung für das Team
  • Bindeglied zwischen Product Owner und Team, aber letztendlich nicht verantwortlich für Projekterfolg
  • je besser das Team Scrum anwendet, desto geringer wird die Rolle des Scrum Masters

Literatur:

Artefakte und Ereignisse

Backlogs


Sprint Planning Meeting

Planning

Priorisierung

Probleme und Schwierigkeiten

  • Team soll eigentlich die Anforderungen (Requirements) mit höchster Priorität bearbeiten, was viel Disziplin erfordert
  • Product Owner muss viele Talente (Skills) haben: Bei komplexen Themen und großen Projekten ggf. ein Product Owner Team bilden
  • Neue Rolle für den klassischen Projektmanager bestimmen: Product Owner (Business, Budget, Customer, Controlling) oder Scrum Master (Agile Leader, Prozess, als Projektbegleiter)
  • Anpassung an Unternehmensstrukturen nötig
  • Es ist nicht immer einfach, Prioritäten bei vielen Stakeholdern zu bestimmen.
  • Beseitigung von Risiken und Hindernissen oft nicht in der Hand des Projekts (je weniger man abhängig ist von äußeren Einflüssen desto besser) -> externe Abhängigkeiten
  • Alle am Produkt beteiligten müssen Scrum verstehen und daran beteiligt sein
  • Das Scoping im Team muss mit den Kundenwünschen übereinstimmen, was über die Priorität gesteuert wird. Das muss dem Kunden aber auch so "verkauft" worden sein.
  • da Product Owner und Scrum Master nicht notwendigerweise Mitglied des Entwicklungsteams sein sollen, sind mindestens 4-5 Personen pro Scrum-Projekt nötig.
  • Je größer das Projekt ist und je mehr Entwicklungsprojekte involviert sind, desto umfassender müssen die Anpassungen im Unternehmen sein (Enterprise Scrum).
  • Das Team soll die für die Entwicklung nötigen Tools selbst aussuchen können. Je nach Projekt sind verschiedene Tools nötig, die ggf. im Unternehmen nicht "unterstützt" werden. Beispiel: Revision Control Systeme.
  • Wie werden Change Requests bearbeitet ? -> Abbildung in die Scrum Methodik

Training

Zertifizierung

Siehe Über uns.

Siehe meine Blog-Beiträge:

Literatur / weitere Infos

Videos und Podcasts

Quellenangaben

  • Bild "Der Scrum Prozess": Quelle Wikipedia, CC-Lizenz

Siehe auch