Verstehen Product Owner Rolle

Verantwortung

  • Muss eine Shared Vision haben
  • Entwickelt Winning produkt

Product Owner steuert den Entwicklungsaufwand, um ein Artikel zu erstellen, das höhste Nutzen Erzeugt

Andere Eigenschaften

A) Produktvision Entwickeln
B) Pflege des Product Backlog
C) Veröffentlichung planen
D) Kunden, Mitglieder und Stakeholder involvieren
E) Budget verwalten
F) Produkt starten
G) Scrum Meetings BESUCHEN und mit DM-Team Kommunizieren
H) Produkt-Lebenslauf Verwalten

Als ScrumTeam-Mitglied – eng mit DM-Team Kommunizieren

A) Sicher sein, dass entstehende Aufgaben erledigt werden
B) Von Development Support Team das geschätzte Product Backlog verlangen.

Integration Team in Multi-Team Scrum


Wenn ein Team in Scrum nicht genug ist, ist es ratsam, ein neues Multi-Team einzusetzten. Aber hier erhalten Sie noch ein Problem – wie kann man mehr als ein Team steuern. Und die Antwort: Mit dem Integration Team. Mit Multi-Team ihre Scrum wird einige Besonderheiten haben.

Multi-team Sprint Planning

  • Alle Teams oder mindestens Team-Vertreter besuchen Sprint Planning
  • Product Owner gibt die Vision für die Sprint
  • Vertreter finden die Abhängigkeiten heraus
  • Vertreter finden heraus, wie die teamübergreifende Abhängigkeiten zu minimieren
  • Dann jedes Team machen ihre üblichen Sprint Planning Meetings

Integration Team Daily Scrum

Nicht das gleiche wie ein regulärer Daily Scrum – nicht „3 Fragen“
Dieses Treffen kann weniger als 15 Minuten dauern
Ziel: Heraus finden, ob die Integration auf dem richtigen Weg ist?
– „Haben wir irgendwelche Probleme mit der Integration gestern?“
– „Gibt es heute Integration Probleme?“

Multi-team Sprint Review

Ziel: Das fertige und integrierte Software finden, sowie sammeln das Feedback

Multi-team Sprint Retrospectives

  • Vertreter der Teams kommen zusammen
  • Es findet eine Diskusion statt, wo alle teamübergreifende Probleme identifiziert werden
  • Vertreter gehen zu ihre regelmäßigen Sprint Retrospektiven

Scrum mit mehreren Teams


Scrum sagt ein Team soll 3-9 Mitglieder haben. Aber manchmal müssen Sie mehr Teams hinzuzufügen. Dieser Prozess heißt Multi-Team Scrum oder Scaled Scrum.

Herausforderungen der Multi-Team Scrum

Nun müssen Sie nicht nur ein einzelnes Team koordinieren
Scrum Master müssen ihr Augenmerk auf Abhängigkeiten in der Product Backlog legen
Verwalten auch Abhängigkeiten im Sprint
Neue Verantwortung – Arbeitsintegration von mehreren Teams

DONE in einem One Team vs. mehrere Teams

Im Einzel-Team
– Ziel: funktionierende Software.
-Wenn es die DoD nicht erfüllt, dann ist es nicht Done.

In Multiple Teams
– Ziel: funktionierende und integrierte Software.
– Wenn sie nicht erfüllen die DoD und wenn es nicht integriert ist, ist es nicht getan.

Multi-Team PBI Empfehlungen

  • PBIs sollen von einem Team in einem Sprint erledigt werden
  • Abhängigkeiten verwalten zwischen PBIs
  • Erstellen Sie eine neue Integrationsteam: Job ist es, sicherzustellen, dass alles integriert ist
  • Ein Product Owner für alle Teams
    -ein Produkt – ein Product Owner

Wie machen Sie Scrum unter Waterfall?

scrum-under-waterfall
Sehr oft wird der Scrum unter Wasserfall in den Unternehmen verwendet. Diese Methode ist vielleicht nicht formal existiert, aber es kommt durch Vertrag oder wird gesetzlich vorgeschrieben. Oder der Scrum kann ein Teil des Agile Experiments sein.

Was wird die gleiche/unterschiedliche Verwendung von Scrum unter Waterfall?

Gleich

Konzentrieren auf ‘Definition of Done’
Daily Scrum
Sprint Planning
Sprint Review
Sprint Retrospective

Unterschiedlich

Backlog = Project Plan
Weniger Zeit für Backlog refinement
Weniger Zeit für Sprint planning
Weniger Verhandlungen während Sprint

Aber beachten Sie, beim Wasserfall Verwendung:

Wasserfall hat schlechte Kommunikation / Missverständnisse
Mangel an Transparenz
Loslösung von der Realität
Langsame Feedback / Kein Feedback
Nichts getan

So müssen Sie folgende Dinge tun:

1: Arbeiten in Sprints

Der Wasserfall kann beispielsweise für 12 Monate eingeplant werden. Wenn der Sprint 30 Tagen dauert, wird es 12 Sprints.

2: Vermeiden Sie „Earned Value ‚

Die Aufgabe kann nicht für 85,6 oder 98% durchgeführt werden. Die Aufgabe wird getan oder nicht getan!

3: Fokus auf Done

Erstellen Sie eine Definition von Done (DoD), arbeiten mit DoD

4: Testen, testen, testen

Testing während ganzen Sprints. Testing bis zum Ende

5: Holen Sie sich häufige Rückmeldungen

Feedback sammeln früh.

Waterfall vs. Scrum

Was ist “Waterfall”?

Wasserfall ist ein plangetriebenes Projektmanagement in der Softwareentwicklung. Also in der Regel wird mit Gantt-Diagrammen und Microsoft Project gearbeitet, es gibt Start- und Enddaten und Projektphasen. Im Wasserfall haben Entwicklungsphasen die vordefinierte Reihenfolge: zuerst werden die Anforderungen  geschrieben, dann sie werden designt und entwickelt, am Ende kommt Testing und Deployment-Phase.

Waterfall vs. Scrum

Waterfall

Anforderungsdokumente
Resistent gegen Veränderung
-Change ist ein Bug
Niedrige „Kunden“ Beteiligung
Start-Ziel-Projekt-Plan
Große Teamgröße
Mehrere Phasen
-eventual Lieferung
Contract angetrieben
Fixed-Feature-Set

Scrum

Just-in-Time-Anforderungen
Kontinuierliche Veränderung
-Change ist eine Funktion,
Permanent „Kunde“ Beteiligung
Plan für den Sprint. Product Backlog
Kleine Teams (3-9 Personen)
Increment jeden Sprint
Vertrag ist näher an T & E
-keine feste Feature-Set

Definition of DONE in der Softwareentwicklung


Stellen sie sich vor, dass am Ende jeder Iteration in SCRUM oder anderer Agile Softwareentwicklung Methode, der Entwickler kommt zu ihnen und sagt: „Ich bin mit dieser Funktionalität fertig oder Done“. Man kann natürlich fragen: „Was meinst du damit? Bist du Done oder komplete Done?“

Was will ich hier sagen: Software-Entwickler denken, dass Software-Entwicklung beginnt und endet mit ihnen. Es ist eigentlich nicht wirklich falsch, aber …
Die Software-Entwicklung ist viel größer als nur das Schreiben des Codes. Code selbst ist nicht so nützlich. Wenn das Team beginnt Definition von Done (DoD) definieren, wird es am Ende viel mehr als „nur Codierung“ sein.

Beispiel Definition of Done

Entwicklung / Coding

  • Code wird mit Unit-Tests geschrieben
  • Code ist in Main zusammengelegt
  • Code ist von jemand anderem als dem Autor bewertet

Testing / Deployment

  • Geschriebene QA Tests
  • Geprüft durch QC
  • Getestet von QA
  • Geschriebene und getestete UI Tests
  • Von Product Owner akzeptiert

Wie Sie sehen können, reale Done Funktionalität enthält viel mehr Schritte, als nur Code. Und wie kann man diese Definition of Done (DoD) bestimmen?

Definieren Definition of Done (DoD)

  • Holen Sie das Team zusammen, bevor oder am Projektbeginn
  • Starten Sie den Diskus in welcher Phase die Funktionalität kann als erledigt genannt werden
  • Versuchen Sie die Unklarheiten und Unterschiede in der Definition zu vermeiden
  • Schreib es auf!
  • Alle Teammitglieder sollten das DoD folgen

So im nächsten Fall, wenn Entwickler kommt und sagt: „Ich bin fertig!“, Alle werden genau wissen, was es bedeutet.

9 haupt Agile Softwareentwicklungsmethoden

agile software development methodologies

Agile Modeling

Reihe von Konzepten, Prinzipien und Techniken (Praxis), die sich Konstruktion und Dokumentation schnell und einfach durchzuführen, um die Software-Entwicklungsprojekte ermöglichen. Nicht enthalten sind detaillierte Anweisungen für die Ausgestaltung. Enthält Beschreibungen, wie man Diagramme in UML baut. Das Hauptziel – effektive Modellierung und Dokumentation, aber nicht die Programmierung, Tests, Projektmanagement, Implementierung und Wartung des Systems. Allerdings beinhaltet die Überprüfung der Modellcode.

Wer ist eigentlich der Scrum Master?

scrum master coach

Der Scrum Master hilft dem Team produktiv zu sein und verwenden sein Kreativität, um eine fertige Software zu liefern.

Der wichtigste Punkt hier ist, dass der Scrum Master das Team führt, aber nicht befehlt.

Der Scrum Master ist ein Coach. Er ist kein Chef. Die Teammitglieder müssen dem Scrum Master nicht reporten.
Der Scrum Master ist kein Manager und befehlt nicht, was gemacht werden soll.