Changes for page Scrum

Summary

• insert_drive_file Page properties (1 modified, 0 added, 0 removed)

Details

insert_drive_file Page properties

Content

...	...	@@ -70,23 +70,104 @@
70	70	*** Am Ende der Sitzung Verteilung neuer Aufgaben (jeder hat mindestens ein Ticket)
71	71	*** Im Weekly werden keine Lösungen diskutiert, dies kann im weiteren Verlauf der Sitzung passieren
72	72	* **Artefakte:**
73		-** **Product Backlog**
74		-*** Die Anforderungen für das finale Produkt
75		-*** Eine Liste aller gewünschten Projektarbeiten
76		-*** Eigentlich immer mehr, als im aktuellen Sprint gebraucht wird
77		-*** Im SWP: Zu Beginn füllen und später ergänzen
78		-*** Vom Product Owner priorisiert
79		-*** Zu Beginn des Sprints repriorisiert
80		-** **Sprint Backlog**
81		-*** Team-Mitglieder wählen Tasks aus (Arbeit wird nie zugewiesen)
82		-*** Aber**:**
83		-**** Im SWP hat jeder am Ende einer Sitzung eine Aufgabe!
84		-**** Im Zweifelsfall durch Zuweisung...
85		-*** Jedes Team-Mitglied kann Tasks hinzufügen, löschen oder ändern (basierend auf dem aktuellen Ziel)
86		-*** Wenn Arbeit unklar ist, definieren Sie erstmal einen Task mit größerer Schätzung und erstelle Unteraufgaben, sobald die Arbeit klarer wird
87		-*** Definieren Sie für die Tickets eine Definition of Done ([[https:~~/~~/www.scrum-events.de/was-ist-die-definition-of-done-dod.html>>url:https://www.scrum-events.de/was-ist-die-definition-of-done-dod.html]])
88		-** **Produktinkrement**​​​​​​​
	73	+** Product Backlog
	74	+** Sprint Backlog
	75	+** Produktinkrement
89	89
	77	+=== **Rollen** ===
	78	+
	79	+Product Owner:
	80	+
	81	+* Definiert Product-Features
	82	+* Bestimmt Auslieferungsdatum und Inhalt
	83	+* Akzeptiert oder weist Arbeitsergebnisse zurück
	84	+* Im SWP der Tutor in Absprache mit Marco und das Team
	85	+
	86	+Scrum Master:
	87	+
	88	+* Repräsentiert das Management gegenüber dem Projekt
	89	+* Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken
	90	+* Beseitigt Hindernisse
	91	+* Stellt sicher, dass das Team vollständig, funktional und produktiv ist
	92	+* Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen
	93	+* Schützt das Team vor äußeren Störungen
	94	+
	95	+ → Im SWP ein spezielles Mitglied der Gruppe
	96	+
	97	+ → Soll trotzdem auch mit entwickeln
	98	+
	99	+Entwicklungs-Team:
	100	+
	101	+* Typischerweise 5-9 Personen
	102	+* Funktionsübergreifend
	103	+** QS, Programmierer, UI-Designer, etc.
	104	+* Mitglieder sollen Vollzeitmitglieder sein
	105	+* Teams organisieren sich selbst
	106	+* Mitgliedschaft kann nur zwischen Sprints verändert werden
	107	+
	108	+ → Es kann helfen, einen Projektleiter zu bestimmen (ist nicht Scrum-Konform, aber im SWP kann es hilfreich sein)
	109	+
	110	+=== **Meetings** ===
	111	+
	112	+Sprint Planning
	113	+
	114	+* Sprint Priorisierung
	115	+** Product Backlog analysieren und auswerten
	116	+** Sprint-Ziel festlegen
	117	+* Planung
	118	+** Entscheiden, wie man das Sprint-Ziel erreichen kann (Design)
	119	+** Sprint Backlog (Tasks) aus Product Backlog (User Stories/Features) erstellen
	120	+*** Team wählt Einheiten, zu deren Implementierung es sich verpflichten kann, aus dem Product Backlog aus
	121	+* Sprint Backlog schätzen (Planning Poker, Magic Estimation, etc.)
	122	+* Sprint-Ziel
	123	+** Kurze Angabe dessen, worauf sich die Arbeiten während des Sprints fokussieren
	124	+** Wichtig! Wird gerne unterschätzt
	125	+** Hilft, das Ziel im Auge zu behalten
	126	+
	127	+Daily Scrum //(hier: Weekly)//
	128	+
	129	+* Wöchentliches Treffen startet mit Scrum-Meeting
	130	+* Am Ende der Sitzung Verteilung neuer Aufgaben (jeder hat mindestens ein Ticket)
	131	+* Im Weekly werden keine Lösungen diskutiert, dies kann im weiteren Verlauf der Sitzung passieren
	132	+
	133	+Sprint-Review
	134	+
	135	+* Das Team präsentiert, was es während eines Sprints erreicht hat
	136	+* Typischerweise in Form einer Demo mit neuen Features oder der zugrunde liegenden Architektur
	137	+* Das ganze Team nimmt teil!
	138	+
	139	+Sprint-Retrospektive
	140	+
	141	+* Regelmäßig prüfen, was gut und was nicht so gut funktioniert
	142	+* ca. 15-30 min lang
	143	+* Nach jedem Sprint
	144	+* Das gesamte Team kommt zusammen und diskutiert, wie es sich verbessern möchte
	145	+* Methode hierfür bspw: Starfish (siehe Bild)
	146	+* Weitere Methoden für die Retrospektiven finden sich z.B. hier: [[https:~~/~~/retromat.org/>>url:https://retromat.org/]]
	147	+
	148	+[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/e505851f2237f527759101e71f2207f9/Retrospektive.png~|~|alt="Retrospektive.png" height="393" width="524"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/e505851f2237f527759101e71f2207f9/Retrospektive.png]]
	149	+
	150	+=== **Artefakte** ===
	151	+
	152	+Product Backlog:
	153	+
	154	+* Die Anforderungen für das finale Produkt
	155	+* Eine Liste aller gewünschten Projektarbeiten
	156	+* Eigentlich immer mehr, als im aktuellen Sprint gebraucht wird
	157	+* Im SWP: Zu Beginn füllen und später ergänzen
	158	+* Vom Product Owner priorisiert
	159	+* Zu Beginn des Sprints repriorisiert
	160	+
	161	+Sprint Backlog:
	162	+
	163	+* Team-Mitglieder wählen Tasks aus (Arbeit wird nie zugewiesen)
	164	+* **Aber:**
	165	+** Im SWP hat jeder am Ende einer Sitzung eine Aufgabe!
	166	+** Im Zweifelsfall durch Zuweisung...
	167	+* Jedes Team-Mitglied kann Tasks hinzufügen, löschen oder ändern (basierend auf dem aktuellen Ziel)
	168	+* Wenn Arbeit unklar ist, definieren Sie erstmal einen Task mit größerer Schätzung und erstelle Unteraufgaben, sobald die Arbeit klarer wird
	169	+* Definieren Sie für die Tickets eine Definition of Done ([[https:~~/~~/www.scrum-events.de/was-ist-die-definition-of-done-dod.html>>url:https://www.scrum-events.de/was-ist-die-definition-of-done-dod.html]])
	170	+
90	90	= Scrum im Detail =
91	91
92	92	== Scrum-Prozess ==