Projektmanagement Flashcards

Question

Was sind agile Methoden und agile Techniken und was ist der Unterschied?

Answer 1

Agile Methoden: - Scrum - Kanban …sind konkret Modelle, die agilen Techniken einen Rahmen/ eine Gesamtstruktur geben. Agile Techniken: - WIP-Limits - Task Boards - Dailys - User Stories - Retrospective …sind konkrete Vorgehensweisen/ Tools, die sich aus den agilen Methoden ableiten lassen & die auch „isoliert“ einsetzbar sind

Answer 2

1. Visualisiere die Arbeit (am Kanban Board) 2. Limitiere die Menge angefangener Arbeit (durch WIP limits) 3. Manage den Fluss der Arbeit (z.B. Warteschlangen, Zykluszeiten) 4. Mache Prozess-Regeln explizit 5. Implementiere Feedback Loops 6. Verbessere dich kontinuierlich

Answer 3

Spalten: Backlog/Next/In-Progress/Done * Backlog: alle Aufgaben, die gemacht werden müssen * Next: Welche Aufgaben nimmt man sich für den kommenden Zeitraum vor? * In-Progress: Woran arbeitet man aktuell? * Done: bereits erledigt

Answer 4

Scrum vs. Kanban *Objekte*: Produkt vs. Aufgaben Steuerung: effektive Taktung (Sprints) vs. kontinuierlicher Fluss *Elemente*: Stories, Aufgaben vs. Aufgaben *Kontext*: Projektmanagement vs. Aufgabenmanagement *Verbesserung von:* Projektergebnis, Prozess vs. Prozess *Anwendung*: Entwicklungsprojekte vs. Persönlich, Teams, Projekte **Scrum:** * Deutlich restriktiver/ Klarere Vorgaben (z.B. 3 Artefakte, 3 Rollen, 4 Meetings) * Schwieriger zu implementieren **Kanban:** * Nur 2 Vorgaben: Visualisierung des Workflows & Limitierung des WIP * Deutlich einfachere Implementierung

Answer 5

Scrum beruht auf der Ansicht, dass komplexe Entwicklungsprojekte zu **komplex** sind, um **durchgängig planbar** zu sein. Scrum basiert auf **drei Säulen/ Prinzipien **zur Komplexitätsreduktion: 1. *Transparenz*: Fortschritt & Hindernisse eines Projektes werden täglich und für alle sichtbar festgehalten 2. *Überprüfung*: In regelmäßigen Abständen werden Produktfunktionalitäten geliefert und beurteilt 3. *Anpassung*: Die Anforderungen an das Produkt werden nicht einmalig festgelegt, sondern nach jeder Lieferung neu bewertet und bei Bedarf angepasst

Answer 6

kWM: Erst WAS, dann WANN * Legt zunächst das 1. WAS fest * Also alle (Zwischen-) Ergebnisse, die im Projektverlauf erreicht werden sollen * Darauf aufbauend: Schätzung des Aufwandes & Dauer, also das 2. WANN Scrum: Erst WANN, dann WAS * Vorgabe des 1. WANN („Timeboxing“) --> Das "WANN" ist der Sprint! * Zu Beginn jeder „Zeitbox“/ Sprint wird vereinbart 2. WAS am Ende erreicht werden soll * Iterative Bestimmung der Etappenziele * Navigation “auf Sicht“ **Zusammenfassend:** **kWM: Plan/Plan/Plan/.../Build everything/Show** **Scrum: Plan/Build small thing/Show ... Plan/Build Small Thing/Show ...**

Answer 7

1. Product Backlog ...priorisierte Liste, die alles enthält, das zum entsprechenden Zeitpunkt im Produkt enthalten sein soll 2. Sprint Backlog ...Plan des Teams für den kommenden Sprint 3. Potentially Releaseable Increment ...Das Inkrement ist die mit den Stories des Sprints hinzukommende Funktionalität, die die bestehenden Funktionalitäten erweitert

Answer 8

„Definition of Done“ ist eine Liste von Fertigstellungskriterien. Auf der Basis der DoD weist der Product Owner am Ende eines Sprints das Arbeitsergebnis (Increment) ab oder akzeptiert es. Beispiel: Punkte einer DoD können sein: * Alle Akzeptanzkriterien der User Stories werden erfüllt und * der Software-Code ist fertiggestellt & im Versionierungssystem eingespielt und * es wurde ein Test durchgeführt und es gibt keine größeren Bugs

Answer 9

- Scrum Master - Product Owner - Entwicklungsteam

Answer 10

Der PO ist dafür verantwortlich WAS entwickelt wird * Er trägt die volle Verantwortung für das Produkt & seinen geschäftlichen Erfolg * Aber: Weniger bis gar nicht soll er sich darum kümmern, wie das Produkt umgesetzt wird (Aufgabe des Entwicklungsteams)

Answer 11

* Das (Entwicklungs-) Team ist dafür verantwortlich WIE das Produkt WANN umgesetzt wird * Bestimmt was es im Sprint bewältigen kann * Trägt höhere Verantwortung als in der klassischen Entwicklung, hat aber auch höhere Rechte

Answer 12

Der Scrum Master coacht das Team, beseitigt Hindernisse & stellt sicher, dass das Team effektiv arbeiten kann.

Answer 13

- Vor dem Sprint: Sprint Planning - Während des Sprints: Daily Scrum - Nach dem Sprint: Sprint Review - Nach dem Sprint: Sprint Retrospective

Answer 14

Ziel: Festlegung, was im Sprint entwickelt wird Oft 2 Teile: (1) Präsentation, Klärung von Fragen & Schätzung (durch Product Owner) (2) Feinarbeit: Runterbrechen der User Stories in einzelne Tasks/ Aufgaben (oft Entwicklungsteam alleine) Ergebnis: Sprintziel & Sprint Backlog als Summe aller für den kommenden Sprint geplanten User Stories, zu dem sich alle committen („common ownership“)

Answer 15

Ziel: Synchronisierung & Abstimmung im Team Beantwortung von drei vorgegebenen Fragen in Bezug auf das Sprintziel * Was habe ich gestern erreicht? * Was werde ich heute erledigen? * Sehe ich Hindernisse (impediments)? Ergebnis: Die Teammitglieder wissen im Blick auf das Sprintziel, wo das gesamt Team steht, was jeweils erledigt ist & was an diesem Tag erledigt werden soll

Answer 16

Ziel: Einholen von Feedback von den Kunden: „Machen wir das richtige Produkt?“ & „Abnahme“ des Increments auf Basis der Definition of Done Ablauf: * Product Owner berichtet über Sprint & Produkt * Team erzählt über Sprint und präsentiert das Increment (kein pptx, sondern das reale Produkt!) * Produkt Backlog wird diskutiert und überarbeitet * Ausblick auf die kommende Phase Ergebnis: „Was wollen unsere Kunden, was brauchen sie um ein für sie gutes Produkt zu erhalten?“ & „Stellen wir unsere Kunden zufrieden?“

Answer 17

Team schaut darauf, wie es arbeitet. Fokus: Arbeitsweise, Zusammenarbeit & „Miteinander“ im Team Frage: Machen wir das Produkt richtig? Ablauf * Eröffnung: Stimmungsbild (z.B. “Wie geht es Dir?“) * Rückblickende Datensammlung (siehe Beispiele) * Analyse & Lösungssuche: Brainstorming * Entscheidung & Transfer: Was ändern wir? * Schluss: Wertschätzung & Dank Ergebnis: „Was wollen/ müssen wir ändern oder anpassen um besser zu werden?“

Answer 18

* Scrum ist ein Rahmen zur Durchführung von komplexen Entwicklungsprojekten * Iterativ-Inkrementelle Vorgangsweise & höchste Kundenorientierung * Säulen: Transparenz, Überprüfung, Anpassung * 3 Artefakte: Product Backlog, Sprint Backlog, Potentially Releaseable Increment * 3 Rollen: Product Owner, Entwicklungsteam, Scrum Master * 4 Meetings: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospektive * Ablauf in Sprints von 2-4 Wochen

Answer 19

1. Die (klassischen vs. Scrum) Rollen: Wodurch unterscheiden sie sich? * Projektleiter vs. Product Owner & Scrum Master * Projektteam vs. Entwicklungsteam 2. Die (klassischen vs. Scrum) Tools/ Artefakte: Wodurch unterscheiden sie sich? * Projektstruktur- und Ablaufplan vs. Product und Sprint Backlog * Arbeitspaket vs. User Story * Projektergebnis vs. Potentially Releasable Increment * Statusreport und Abnahme vs. Review und Retrospektive

Answer 20

* Mut haben, nicht umfassend zu planen: Starten Sie schnell mit der Implementierung! * Daily Scrum: Wirklich kurz & knackig! Keine große Diskussion! & „kein Reporting“ i.e.S. * Selbständiges Arbeiten: Verzichten Sie auf Zuweisung von Tasks! * Scrum Master: Coach, kein aktiver Mitarbeiter & keine technischen Vorgaben! * Product Owner: Muss immer eingebunden & greifbar sein! Darf nicht „Abtauchen“ * Sprint Planning: Keine Vorgaben von „außen“ – nur das Team entscheidet wie viele Tasks es abarbeiten kann! * Wir-Gefühl des Teams: Keine Alleingänge von Einzelnen oder Sub-Gruppen! * Keine Unterbrechungen innerhalb eines Sprints: Der Sprint muss geschützt werden – keine Änderungen, höchstens Abbruch in absoluten Ausnahmefällen! * Zielorientiertes Vorgehen: Sprintziele gilt es unbedingt einzuhalten, „Go live“ muss bei abgenommenen Stories jederzeit möglich sein – lieber auf ein Feature verzichten! * Komprimierte Teams: Am Besten in einem Raum! Verteilte Teams sind möglich, aber nicht optimal! * Änderungen des Scrum Teams vermeiden: Ein Scrum Team braucht Kontinuität! * Augenmerk auf Qualität: Implementierte Features müssen immer auch ausreichend getestet werden!

Answer 21

* User Story ist eine “Anwendererzählung“ und beschreibt einen Nutzer & dessen Grundwarum er ein Produkt/ eine Funktionalität des Produktes nutzt * Sie ist eine „Was-Warum“ Verknüpfung: Sie verlinkt eine Funktionalität (was) mit einem Nutzen (warum) * Letztlich sind User Storys in kleine Parts/ Geschichten heruntergebrochene Nutzeranforderungen **Syntax:** Als (Nutzer/ User-Typ) will ich (ein Produkt/ Funktionalität nutzen) damit (diese Anforderungen erfüllt werden) Beispiel: Als Leser eines Fachbuches will ich ein Glossar haben damit ich Fachbegriffe nachschlagen kann

Projektmanagement Flashcards

(45 cards)