TestmanagementDie Welt verändern, ein Bug nach dem anderen…

  • Was ist Scrum???

    Open or Close
    Scrum
    Scrum ist ein agiles Managementframework zur Entwicklung von Software. Als agiles Framework verkörpert Scrum die Wert des Agilen Manifests (Beck et al. 2001). Dieses stellt den Menschen in den Mittelpunkt der Softwareentwicklung. Scrum ist nicht technologie- oder toolorientiert. Das Agile Manifest formuliert die Optimierung von Kundenzufriedenheit und Wertschöpfung als Ziel der Softwareentwicklung.
    Scrum ist ist ein Framework für eine kontinuierliche Produktentwicklung und nicht eine Projektmanagement-Methode.
    Die Rolle des klassischen Projektleiters kennt Scrum nicht.
    Eine hervorragende Übersicht über die Zusammenhänge zeigt Mahud Laulin (Auszug) via Scrum Alliance:
    Scrum Übersicht

  • Kleine Projekte

    Open or Close

    • Rollen in Scrum

      Open or Close
      Das Scrum Framework kennt 3 Rollen (=Scrum Team): Product Owner, Scrum Master und Entwicklungsteam. Für die Organisation größerer Einheiten und mehrerer Teams gibt es spezielle Frameworks mit weiteren Rollen.
      Produkt Owner (PO)
      Der PO ist verantwortlich für den Mehrwert des Produkts und der vom Team gelieferten Produktinkremente.
      Er pflegt das Product-Backlog.
      Er ist Produktverantwortlicher gegenüber dem Unternehmen.
      Der PO ist verantwortlich für die Aufnahme, Pflege und Priorisierung aller Anforderungen.
      Der PO erstellt den Releaseplan und die Releaseberichte.
      Der PO sollte täglich ca. eine Stunde mit dem Team arbeiten, z.B. nach dem Daily-Scrum.

      Scrum Master (SM)
      Der SM ist verantwortlich, dass Scrum verstanden, richtig angewendet wird, das Team effizient und mit bestmöglicher Qualität arbeiten kann.
      Unterstützung des PO bei der Erstellung des Product-Backlogs.
      Sicherstellung der benötigten Testumgebung.
      Schützen des Teams vor Zuweisung von Spezialaufgaben und Abziehen von Mitarbeitern aus dem laufenden Sprint.
      Der SM fungiert als Servant-Leader (= dienende Führungskraft).
      Hilfreiche Skills des SM: Moderationstechniken, Coaching und Erfahrung in der Software-Entwicklung.
      Der SM beseitigt Hindernisse.
      Der SM ist nicht der Projektleiter und er weist dem Team auch keine Aufgaben zu.
      Der SM zählt meist nicht zu dem Team hinzu.

      Entwicklungsteam (=Team)
      Das Entwicklungsteam erstellt bis zum Ende eines jeden Sprints ein fertiges und potentiell auslieferbares Produktinkrement.
      Darf keine Anweisungen außer vom PO entgegennehmen.
      Nur der PO darf das Team anweisen die Anforderungen aus dem Product-Backlog umzusetzen.
      Das Team besteht nur aus Entwicklern (Tester, Administratoren u.a. Spezialisten).
      Das Team besteht aus 3 bis 9 Mitgliedern.
      Das ideale Teammitglied ist sowohl Spezialist als auch Generalist.

      Stakeholder
      Stakeholder sind Rollen außerhalb von Scrum. Zu den Stakeholdern zählen: Marketing-, Vertriebs-, Service-, IT-Mitarbeiter und Kunden/Anwender.

    • Berichte, Hilfsmittel, User Stories, Definitionen u.a.

      Open or Close
      Anforderungsworkshop
      Verfeinerung der hochprioren Anforderungen durch den PO mithilfe eines oder mehreren Anforderungsworkshops vor dem ersten Sprint unter Einbeziehung des gesamten Teams.

      Story Cards
      Das sind Anforderungen, die auf Karteikarten geschrieben werden.

      Teamkapazität
      Ca. 20-35 % liegt die Nettoteamkapazität unter der Bruttokapazität.

      Aufwandsschätzung
      Zur Aufwandsbestimmung werden Story Points verwendet, z.B. nach der Fibonacci-Funktion:

      Bildschirmfoto 2016-02-08 um 19.37.41

      Das ergibt eine Punktereihe:
      • 0 (kein Aufwand),
      • 1 (sehr kleiner Aufwand),
      • 2 (kleiner Aufwand),
      • 3 (mittlerer Aufwand),
      • 5 (großer Aufwand),
      • 8 (sehr großer Aufwand),
      • 13 (riesiger Aufwand).
      Es werden meist mehrere Schätzklausuren noch vor dem ersten Sprint abgehalten. Das Ergebnis fließt in das Product Backlog ein. Auch während eines Sprints werden Schätzklausuren durchgeführt.
      Das Abschätzen erfolgt ausschließlich durch das Team.
      Zum Abschätzen kann auch ein Planungspoker verwendet werden.

      Planungspoker
      Das ist eine in Scum verwendete Methode, um Aufwände abzuschätzen. Unter Verwendung von Spielkarten auf denen Story Points abgedruckt sind, erfolgt nach Vorstellung durch den PO der jeweiligen User Story die unabhängige Schätzung der Teammitglieder solange bis ein Konsens vorliegt.
      Die in nachfolgender Abbildung verwendeten Spielkarten stammen von den Itemis AG bei der der Autor einen Scrum Master Kurs besucht hat.
      Releaseplan
      Der Releaseplan enthält die Anzahl der benötigten Sprints und die Reihenfolge der Umsetzung der Anforderungen aus dem Product Backlog.
      Der PO erstellt diesen Plan.

      Release Burndown Bericht
      Dieser Plan wird am Ende eines jeden Sprints aktualisiert.
      Er enthält die Summe der Aufwände im Product Backlog am Ende eines jeden Sprints. Die ideale Burndown-Linie berücksichtig keine Abwesenheitszeiten. Durch den Vergleich des idealen Fortschritts mit dem realen Fortschritt sieht man wie sich der tatsächliche Fortschritt entwickelt hat.

      Entwicklungsgeschwindigkeits Bericht
      (Entwicklungsgeschwindigkeit=Velocity)
      Die Velocity wird für den den Releaseplan benötigt. Die Entwicklungsgeschwindigkeit ist die Summe aller Aufwände der am Ende des Sprints vom PO abgenommenen Arbeitsergebnisse.
      Teilweise fertiggestellte oder defekte Arbeitsergebnisse fließen nicht mit ein.
      Wenn am Anfang der ersten Sprints kein Releaseplan vorliegen muss, kann die Entwicklungsgeschwindigkeit empirisch festgestellt werden. Beispielsweise wird eine maximale Geschwindigkeit mit 20 Punkten angenommen. Die Erfahrung zeigt, dass im ersten Sprint meist nur eine Geschwindigkeit von 60 % erreicht wird, die im Laufe der nachfolgenden Sprints zunimmt.

      Sprint-Endebericht (end-of-sprint report)
      Dokumentation wie viele der geplanten Anforderungen vom PO abgenommen wurden.
      Der Bericht enthält die wesentlichen Rahmendaten des Sprints.
      Erstellung durch den PO im Sprint-Review oder im Anschluss daran.
      Der Bericht ist wiederum Input für den Release-Burndown- und Entwicklungsgeschwindigkeitsbericht sowie den Releaseplan.

      Hindernisbericht (impediments charts)
      Erstellt der SM im Daily-Scrum. Aus dem Hindernisbericht wird u.a. ersichtlich wie viele Hindernisse den Sprint-Fortschritt behindern.
      Definition of Done (=DoD)
      Die Definition of Done zeigt auf, wann eine Arbeit als fertig bezeichnet werden kann.
      Das Scrum Team legt diese Bedingungen fest.
      Eine erledigte User Story ist fertig (= Definition of Done).
      Jedes Team definiert seine eigenen Definition of Done.
      Am Ende eines Sprints dient neben den DoD die Akzeptanzkriterien dazu, festzulegen ob ein Product Backlog Eintrag als fertig akzeptiert wird.
      DoD werden ständig weiterentwickelt.
      DoD enthalten auch Qualitätskriterien und nicht-funktionale Anforderungen.

      Taskboard/Kanban-Board
      Ein Taskboard dient der Visualisierung des Sprint Backlogs in mindestens vier Spalten.
      Spalte 1: Anforderungen aus dem Product Backlog
      Spalte 2: Alle zu erledigenden Aufgaben
      Spalte 3: Aufgaben in Bearbeitung (Development und Testing)
      Spalte 4: Erledigte Aufgaben
      Ein Taskboard ist kein Kanban-Board. Ein Taskboard ist für Teams, die ihre Arbeit in Sprints planen. Kanban-Boards kennen kein Product Backlog.
      Nachfolgendes Scrum-Board ist wie folgt aufgebaut:
      • Backlog (Stories)
      • Selected (To Do)
      • Development (In Progress)
      • Testing
      • Done
      Im Daily Scrum wird das Taskboard aktualisiert.
      Tasks, die einem Tag nicht beendet werden können, werden markiert.
      Idealerweise arbeitet das Team immer nur an einer User Story.
      User Stories, Akzeptanzkriterien und Akzeptanztests
      User Stories beschreiben die Anforderungen aus Sicht des Benutzers unter Verwendung der Alltagssprache.
      Eine User Story beschreibt immer die gewünschte Produkteigenschaft und den damit verbundenen Nutzen.
      Das Design der User Stories erfolgt im Sprint Planning. Hier werden die User Stories entworfen und die dazugehörigen Tasks festgelegt. Ein Task sollte innerhalb eines Arbeitstages erledigt werden können.
      Der PO formuliert die Akzeptanzkriterien, stimmt sie mit dem Kunden ab und notiert sie zu den jeweiligen User Stories. Der dazugehörige Akzeptanztest stellt dar wie die beschriebenen Eigenschaften getestet werden sollen.
      Auch für EPICS (große User Stories) sollten Akzeptanzkriterien erstellt werden.

      Eigenschaften guter User Stories (Akronym INVEST):
      IIndependentUser Stories sollen unabhängig voneinander sein
      NNegotiableUser Stories sollen verhandelbar sein
      VValuableUser Stories sollen einen Wert für den Kunden haben
      EEstimatableUser Stories sollen schätzbar sein
      SSmall User Stories sollen klein sein
      TTestableUser Stories sollen testbar sein
      Burn-Down-Chart
      Das Burn-Down-Chart dient der Visualisierung bereits geleisteter und noch verbleibender Arbeit.
      Das Entwicklungsteam aktualisiert im Daily Scrum das Sprint Burn-Down.
      Das nachfolgende Burn-Down-Charts zeigt 5 Sprints in denen jeweils genau 20 Story Points je Sprint an Arbeit geleistet wurden. Also wurden exakt insgesamt 100 Story Points auf der Ideallinie abgearbeitet. Liegt die Velocity unterhalb der Ideallinie, muss in nachfolgenden Sprints mit erhöhter Velocity der negative Trend ausgeglichen werden, um das angestrebte Endziel nicht zu gefährden.

    • Ereignisse (=Aktivitäten)

      Open or Close
      Statt von Meetings spricht man in Scrum von Ereignissen oder Aktivitäten. Diese haben feste Zeitfenster (Timeboxen).
      Sprint
      Ein Sprint ist ein Arbeitsabschnitt in dem ein Produktinkrement erstellt wird.
      Die Produktneu- und Weiterentwicklung verläuft in stets gleich langen Iterationen/Zyklen von max. 4 Wochen.
      Sprints sollten immer die gleiche Länge haben.
      Ein Sprint ist zu Ende, wenn die Zeit um ist.
      Sprints folgen unmittelbar aufeinander.
      Muss ein Sprint durch den PO abgebrochen werden, wird der aktuelle Sprint mit einer Sprint Retrospective beendet.

      Explorationssprint
      Bei innovativen und komplexen Scrum Projekten können vor den eigentlichen Sprints n-Explorationssprints vorgeschaltet werden, um das notwendige relevante Wissen zu erwerben (Prototyp). Es werden keine auslieferbaren Inkremente erstellt. Explorationssprints sollten jeweils nicht länger als eine Woche dauern.

      Releasesprint
      Release-Sprints schaffen aus Kundensicht keinen Mehrwert. Dennoch können sie erforderlich sein, wenn beispielsweise eine kundenspezifische Konfiguration zum Einsatz kommen muss.
      Sprint Planning (Teil 1 und 2)
      Dauer: Max. 2 Stunden je Sprintwoche, also maximal 8 Stunden für einen 4-wöchigen Sprint.
      Teil 1
      Der PO stellt eine Vorauswahl der priorisierten und umzusetzenden Anforderungen vor.
      Das Produkt Backlog sollte im Product Backlog Refinement vorbereitet worden sein (für den nächsten Sprint).
      Das Team identifiziert die notwendigen Aufgaben, legt den Aufwand und die umzusetzenden Anforderungen fest.
      PO und Team einigen sich über die Definition of Done.
      Der SM moderiert die Sitzung.
      Teil 2
      Hier erstellt das Team ein realistisches Sprint Backlog auf Basis von Teil 1 und die Aufgaben zu deren Umsetzung.

      Daily Scrum
      Im Daily Scrum wird die Auswahl der Aktivitäten koordiniert.
      Im Daily Scrum werden keine Probleme gelöst - es erfolgt lediglich ein Informationsaustausch. Die Beantwortung von Fragen sollte im Anschluss an diese Aktivität erfolgen.
      PO und SM können anwesend sein, jedoch generell nicht aktiv beteiligt.
      Jedes Teammitglied zu Beginn eines jeden Arbeitstages berichtet über die gestern erledigte Arbeit, die heute geplante Arbeit und identifiziert Verbesserungsnotwendigkeiten.
      Dauer: Max. 15 min.

      Sprint Review
      Am Ende des Sprints und vor der Retrospektive.
      Präsention des erstellten Produktinkrements und Einholung von Feedback insb. von den Stakeholdern.
      Das Team präsentiert seine Ergebnisse.
      Der PO entscheidet über die entwickelten Funktionalitäten.
      Dauer: Max. 1 Stunde je Sprintwoche.
      Teilnehmer: PO, SM, Team und optionale Stakeholder.

      Sprint Retrospektive
      Findet unmittelbar im Anschluss an das Sprint Review statt, als am Ende des Sprints.
      Besprechung im gesamten Scrum-Team über das Vorgehen, die Arbeitsmethoden und die Zusammenarbeit. Vereinbarung von Optimierungen.
      Dauer: Ca. 45 min je Woche, also bei einem 4-wöchigen Sprint 3 Stunden.
      Teilnehmer: PO, SM, Team und grundsätzlich KEINE Stakeholder.

      Product Backlog Refinement (= Backlog Grooming, auch Estimation Meeting)
      Ist ein fortlaufender Prozess, der nicht mehr als 10 % des Entwicklungsteams in Anspruch nehmen sollte.
      PO, Team und ausgewählte Stakeholder nehmen daran teil, um die Einträge zu bearbeiten, zu schätzen und Releases zu planen.

    • Artefakte

      Open or Close
      Scrum kennt 3 Artefakte.
      Product Backlog
      Pflegt der PO.
      Liste aller priorisierten Anforderungen und Arbeitsergebnisse, die für das künftige Produkt benötigt werden.
      Das Product Backlog wächst iterativ-inkrementell. Es liegt zu Beginn grobgranular vor und wird im Laufe der Sprints immer weiter detailliert und verfeinert.
      Scrum kennt kein Change-Request-Verfahren.
      Das Product Backlog enthält auch die Akzeptanzkriterien und den Aufwand der einzelnen Anforderungen.
      Das Product Backlog sollte zu Beginn des Projekts genügend Anforderungen für die ersten 2-3 Sprints enthalten.
      Das Product Backlog ist nach Risiken zu priorisieren. Die Priorisierung führt der PO mit dem Team durch.
      Da Use Cases komplexer als User Stories sind, sollten möglichst User Stories im Product Backlog Anwendung finden.

      Sprint Backlog
      Ausgewählte Product-Backlog Einträge für den aktuellen Sprint und der vom Scrum-Team prognostizierte Lieferumfang für das nächste Produktinkrement.
      Die Aktivitäten sind in Personenstunden geschätzt.
      Ein Sprint Backlog wird in der Sprint Planungssitzung zu Beginn des jeweiligen Sprint erstellt.

      Product Increment
      Entspricht der Summe aller Product-Backlog Einträge die während des aktuellen und der vorangegangenen Sprints fertiggestellt wurden.

  • Große Projekte

    Open or Close
    Große Projekte in Scrum sind solche, die mehr als aus einem Team bestehen. Jedes Team hat i.d.R. seinen eigenen PO und SM.
    Wir unterscheiden verteilte und große Scrumprojekte.
    Bei verteilten Scrumprojekten können die Teams auf verschiedene Gebäude, Standorte, Zeitzonen aufgeteilt sein und ggf. verschiedenen Organisationen angehören.
    Bei verteilten/großen Projekten steigt der Kommunikations- und Integrationsbedarf.
    Da jedes Team einen PO hat, macht es Sinn, aus dem PO-Team einen Chief Product Owner festzulegen und ggf. weitere Stakeholder/Spezialisten hinzuzuziehen.
    Der Chief Product Owner sollte bei mehr als 5 POs kein eigenes Team mehr betreuen.
    Die Teams können ggf. in Komponenten- und Featureteams unterschieden werden.
    In einem Komponententeam entspricht die Struktur der Softwarearchitektur.
    Featureteams sind nach Anforderungen organisiert.
    Grundsätzlich ist zu beachten, möglichst nur mit einem Produkt Backlog zu arbeiten.
    I.R. der Multiteamplanung sollte ein Releaseplan erstellt werden, der für alle Teams gilt. Meist sind synchrone Sprints die Regel, jedoch können auch asynchrone Sprints vorkommen.
    Scrum of Scrums
    Darunter versteht man nichts anderes als ein Daily Scrum, das projektweit durchgeführt wird. Jedes Team entsendet einen Vertreter, der an dem Meeting teilnimmt.
    Meta Scrum
    Ein Meta Scrum entspricht der Scrum of Scrums und wird projektübergreifend ausgeführt.
U
Scrum bietet viele Vorteile in der Softwareerstellung. Wir prüfen Ihr Vorhaben auf Eignung für die Umsetzung in Scrum und führen Scrum ein.
Wir unterstützen Sie bei kleinen und großen Scrum-Vorhaben und sorgen auch für eine Anpassung der klassischen Organisation an eine agile Organisation.
Scrum
© 2016 Holger Mayer Consulting HMC2