4-SCRUM agiles IT-PM

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge

• Funktionierende Software mehr als umfassende Dokumentation

• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

• Reagieren auf Veränderung mehr als das Befolgen eines Plans

[…] Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.[…]

1. Kunden durch frühe und kontinuierliche Auslieferung wertvoller Leistung zufrieden stellen

2. Änderungen sind selbst spät in der Entwicklung willkommen

3. Die Lieferung funktionierender Leistung sollte regelmäßig innerhalb weniger Wochen oder Monate erfolgen

4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten

5. Organisieren Sie ihre Arbeit rund um motivierte Individuen

6. Informationen werden am effektivsten durch persönliche Gespräche vermittelt

7. Funktionierende Leistung ist der wichtigste Maßstab des Fortschritts

8. Agile Prozesse fördern nachhaltige Entwicklung

9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität

10. Einfachheit ist essenziell

11. Die Selbstorganisation der Teams bei Planung und Umsetzung führt zu den besten Anforderungen, Entwürfen und Architekturen

12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an

Kurz gesagt fordert Scrum, dass Scrum Master ein Umfeld fördert, in dem

1. ein Product Owner die Arbeit für ein komplexes Problem in ein Product Backlog einsortiert;

2. das Scrum Team aus einer Auswahl dieser Arbeit innerhalb eines Sprints ein wertvolles Increment erzeugt;

3. das Scrum Team und Stakeholder die Ergebnisse überprüfen und für den nächsten Sprint anpassen;

4. diese Schritte wiederholt werden.

• SCRUM Master

• Product Owner

• Developer

• Stakeholder

• ist ergebnisverantwortlich für die Einführung von Scrum, wie es im Scrum Guide definiert ist.

• ist ergebnisverantwortlich für die Effektivität des Scrum Teams. Ein Scrum Master versetzt das Scrum Team in die Lage, seine Praktiken innerhalb des Scrum‐Rahmenwerks zu verbessern.

• dient dem Scrum Team auf unterschiedliche Weise:

  • die Teammitglieder in Selbstmanagement und interdisziplinärer Zusammenarbeit zu coachen.

  • sicherzustellen, dass alle Events von Scrum stattfinden, positiv und produktiv sind und innerhalb der Timebox bleiben.

• sind ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt.

• ist auch für ein effektives Product Backlog‐Management ergebnisverantwortlich, das Folgendes umfasst:

  • das Produkt‐Ziel zu entwickeln und explizit zu kommunizieren;

  • die Product Backlog‐Einträge zu erstellen und klar zu kommunizieren;

  • die Reihenfolge der Product Backlog‐Einträge festzulegen; und

  • sicherzustellen, dass das Product Backlog transparent, sichtbar und verstanden ist.

• sind jene Personen im Scrum Team, die sich der Aufgabe verschrieben haben, in jedem Sprint jeden Aspekt eines nutzbaren Increments zu schaffen.

• Die spezifischen Fähigkeiten, die von Developern benötigt werden, sind oft breit gefächert und variieren je nach Arbeitskontext. Sie sind jedoch immer ergebnisverantwortlich dafür,

  • einen Plan für den Sprint zu erstellen, das Sprint Backlog;

  • Qualität durch die Einhaltung einer Definition of Done einzubringen;

  • täglich ihren Plan zur Erreichung des Sprint‐Ziels anzupassen; und

  • sich wechselseitig als Fachwissende zur Verantwortung zu ziehen.

• wird eine Person oder Gruppe bezeichnet, die ein berechtigtes Interesse am Verlauf oder Ergebnis eines Prozesses oder Projektes hat.

• u.a. insbesondere der Kunde!

• Sprint Planning

• Sprint

• Daily SCRUM

• Sprint Review

• Sprint Retrospective

• Das Sprint Planning initiiert den Sprint, indem es die für den Sprint auszuführenden Arbeiten darlegt. dieser resultierende Plan wird durch die gemeinschaftliche Arbeit des gesamten Scrum Teams erstellt.

• Product Owner stellen sicher, dass die Teilnehmenden vorbereitet sind, die wichtigsten Product Backlog‐Einträge zu besprechen, und wie sie dem Produkt‐Ziel zuzuordnen sind.

• Das Sprint‐Ziel, die für den Sprint ausgewählten Product Backlog‐Einträge und der Plan für deren Lieferung werden zusammenfassend als Sprint Backlog bezeichnet.

• Das Sprint Planning ist zeitlich beschränkt auf maximal acht Stunden für einen einmonatigen Sprint.

• Sprints sind der Herzschlag von Scrum, wo Ideen in Wert umgewandelt werden. Es sind Events mit fester Länge von einem Monat oder weniger.

• Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigen Sprints.

• Alle Arbeiten, die notwendig sind, um das Produkt‐Ziel zu erreichen, einschließlich Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospective, finden innerhalb der Sprints statt.

• Der Zweck des Daily Scrums besteht darin, den Fortschritt in Richtung des Sprint‐Ziels zu überprüfen und das Sprint Backlog bei Bedarf anzupassen, um die bevorstehende geplante Arbeit zu justieren.

• Das Daily Scrum ist ein 15‐minütiges Event für die Developer des Scrum Teams. Um die Komplexität zu reduzieren, wird es an jedem Arbeitstag des Sprints zur gleichen Zeit und am gleichen Ort abgehalten.

• Falls Product Owner oder Scrum Master aktiv an Einträgen des Sprint Backlogs arbeitet, nimmt man als Developer teil.

• Zweck des Sprint Reviews ist es, das Ergebnis des Sprints zu überprüfen und künftige Anpassungen festzulegen. Das Scrum Team stellt die Ergebnisse seiner Arbeit den wichtigsten Stakeholder vor.

• Auch kann das Product Backlog angepasst werden, um neue Möglichkeiten wahrzunehmen. Das Sprint Review ist ein Arbeitstermin, und das Scrum Team sollte vermeiden, es auf eine Präsentation zu beschränken.

• Der Sprint Review ist das vorletzte Event des Sprints und ist für einen einmonatigen Sprint auf maximal vier Stunden zeitlich beschränkt.

• Der Zweck der Sprint Retrospective ist es, Wege zur Steigerung von Qualität und Effektivität zu planen.

• Das Scrum Team überprüft, wie der letzte Sprint in Bezug auf Individuen, Interaktionen, Prozesse, Werkzeuge und seine Definition of Done verlief.

• Die Sprint Retrospective schließt den Sprint ab. Sie ist für einen einmonatigen Sprint auf maximal drei Stunden beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer.

• Product Backlog

• Sprint Backlog

• Increment

• Ein Product ist ein Instrument, um Wert zu liefern. Es hat klare Grenzen, bekannte Stakeholder, eindeutig definierte Nutzende. Ein Product kann eine Dienstleistung, ein physisches Produkt oder etwas Abstrakteres sein.

• Ein Increment ist ein konkreter Schritt in Richtung des Product‐Ziels. Jedes Increment ist additiv zu allen vorherigen Increments und gründlich geprüft, um sicherzustellen, dass sie alle zusammen funktionieren. Um einen Mehrwert zu erzielen, muss das Increment verwendbar sein.

• Die Definition of Done ist eine formale Beschreibung des Zustands des Increments, wenn es die für ein Product erforderlichen Qualitätsmaßnahmen (u.a. die Anforderungen) erfüllt.

• Das Product Backlog ist eine geordnete Liste der Anforderungen (Requirements) an das Produkt. Product Owner sind ergebnisverantwortlich für das Product Backlog.

• Die Einträge (Product Backlog Items PBI) an Anfang des PB sind konkreter als die an Ende.

• Das Akzeptanzkriterium einer umgesetzten Anforderung wird als Definition of Done bezeichnet.

Das Sprint Backlog besteht aus dem Sprint‐Ziel (Wofür), den für den Sprint ausgewählten Product Backlog‐Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Increments (Wie). Das Sprint Backlog ist ein Plan von und für die Developer.

• Das Sprint‐Ziel ist die einzige Zielsetzung für den Sprint. Das Sprint‐Ziel wird während des Sprint Planning‐Events erstellt und dann zum Sprint Backlog hinzugefügt.

• Es gibt verschiedene Vorgehensweisen, um den Fortschritt vorherzusagen, wie Burn‐Down‐Charts, Burn‐Up‐Charts oder Cumulative‐Flow‐Diagramme.

• Wir formulieren den geschäftliche Nutzen primär

• Wir vermeiden, Details zu früh einzuführen, die Designoptionen verhindern und Entwickler unangemessen auf eine Lösung festlegen

• Wir vermeiden Darstellung von nicht vorhandener Vollständigkeit und Übersichtlichkeit

• Wir schaffen hinreichend kleine Teile, die für Verhandlung und Bewegung im Backlog sorgen im weiteren Verlauf

• Wir überlassen technische Funktionen dem Architekt, Entwicklern, Testern, …

• Erstellung: Kunde, Kunden-Proxy, Product Owner und andere Benutzer, die einen Bedarf für das Produkt identifizieren, können zu User Storys beitragen.

• Eigentum und Wartung: Der Product Owner ist Eigentümer der User Storys und für das Erstellen, Erfassen, Verwalten und Priorisieren verantwortlich.

• Verwendung: Entwickler, Tester und technische Redakteure verwenden User Storys, um zu wissen, was sie implementieren müssen und wann sie fertig sind.

Product Owners verfolgen den Gesamtfortschritt basierend auf dem Status der User Storys nach. Das Management verfolgt User Storys üblicherweise zusammengefasst als Epic Storys oder nach Funktionen.

Als “Benutzer“ will ich “Aktion“, um “Ergebnis“ zu erzielen.

Independent (of all others)

Negotiable (not a specific contract for features)

Valuable to the customer (keep the essence of the story)

Estimable (to a good approximation)

Small (so as to fit within an iteration)

Testable (in principle, even if there isn’t a test for it yet)

Die Ausnahmebehandlung ist zu reparieren

Nutzer wollen Bilder sehen können

Die verschiedenen Zimmergrößen anzeigen können Es den Nutzern ermöglichen, Reservierungen vorzunehmen