Leseprobe
Inhaltsverzeichnis
Abbildungsverzeichnis
Formelverzeichnis
Abkürzungsverzeichnis
1 Einleitung
2 Grundlagen
2.1 Scrum
2.1.1 Product Owner
2.1.2 Entwickler
2.1.3 Stakeholder
2.1.4 Scrum-Master
2.2 Mehrwert und agiles Reporting
2.3 Scrum-Metriken
2.3.1 Metriken
2.4 Mythen und Realität
3 Motivation
4 Problemstellung
5 Zielsetzung
6 Versuchsaufbau
6.1 Ausgangs-Situation des Versuch-Teams
6.2 Erstellung des Fragebogens
6.2.1 Ziel-Rollen
6.2.2 Persönliche Einstellung zu Scrum
6.2.3 Einschätzung zum aktuellen Stand, was die Pflege und Wartung des Backlogs betrifft
6.2.4 Aufwand zur Erhebung von Scrum-Metriken
6.2.5 Vorhandene Scrum-Metriken
6.2.6 Durchführung von Scrum-Metriken
6.2.7 Übernahme von Scrum-Metriken
6.2.8 Mögliche Motivation, um weitere Scrum-Metriken einzuführen
7 Auswertung des Fragebogens
8 Ergebnis
9 Handlungs-Empfehlung
10 Reflektion
11 Literaturverzeichnis
12 Anlage: Fragebogen
ABBILDUNGSVERZEICHNIS
Abbildung 1: Team-Verteilung
Abbildung 2: Einstellung von Team zu Scrum
Abbildung 3: Wartung und Pflege Backlog
Abbildung 4: Aufwand Scrum-Metriken
Abbildung 5: Einsatz von Metriken im Team
Abbildung 6: Verbesserung im Einsatz von Scrum-Metriken
FORMELVERZEICHNIS
Formel 1 Escpaed Defects Percentage
Formel 2 Defect Density
ABKÜRZUNGSVERZEICHNIS
Abbildung in dieser Leseprobe nicht enthalten
1 EINLEITUNG
Das Interesse an agilen Softwaremethoden ist nicht überraschend. Agile Methoden bieten die Möglichkeit, Software besser zu entwickeln, was in der heutigen Geschäftswelt immer mehr an Bedeutung gewinnt. Scrum ist für Unternehmen besonders interessant, weil es sich auf den Return on Investment konzentriert. Die Bemühungen der Innovatoren und frühen Anwender helfen uns zwar dabei, zu behaupten, dass agile Methoden besser sind als traditionelle Methoden, aber eine bessere Berichterstattung an das Management wäre hilfreich. Insbesondere müssen wir in der Lage sein, der Geschäftsleitung den Projektfortschritt auf überzeugendere Art und Weise zu vermitteln.
Dieses praktische Projekt soll im Unternehmen zeigen welche Scrum-Metriken möglich sind, angenommen werden und einen möglichst hohen Mehrwert generieren bei verhältnismäßigem Aufwand.
2 GRUNDLAGEN
Dieses Kapitel beschreibt die Grundlagen, die notwendig sind, um die Arbeit zu verstehen. Insgesamt wird jedoch ein fundiertes Grundwissen über Scrum vorausgesetzt.
2.1 SCRUM
Scrum ist ein leichtgewichtiges Framework, das Menschen, Teams und Organisationen hilft, durch adaptive Lösungen für komplexe Probleme Werte zu schaffen. Kurz gesagt, erfordert Scrum einen Scrum Master, der eine Umgebung fördert, in der:1 2
- Ein Product Owner ordnet die Arbeit für ein komplexes Problem in einem Product Backlog an.
- Das Scrum Team verwandelt eine Auswahl der Arbeit in einen Wertzuwachs während eines Sprints.
- Scrum Team und seine Stakeholder prüfen die Ergebnisse und passen sie für den nächsten Sprint an.
Das Scrum-Framework ist bewusst unvollständig und definiert nur die Teile, die für die Umsetzung der Scrum-Theorie erforderlich sind. Scrum entsteht aus der kollektiven Weisheit der Menschen, die es anwenden. Des Weiteren werden die bestehenden Praktiken umkreist oder machen diese überflüssig. Scrum macht die relative Wirksamkeit des derzeitigen Managements, der Umgebung und der Arbeitstechniken sichtbar, so dass Verbesserungen gezielt vorgenommen werden können.
Selbstorganisation hat absolut nichts mit Laissez-faire-Praktiken zu tun; im Gegenteil, selbstorganisierte Teams sind in hohem Maße selbstdiszipliniert.3
Ein Scrum-Team besteht aus 3 Rollen, dem Product Owner, den Teammitgliedern und dem Scrum Master. Alle Mitglieder des Scrum-Teams haben verschiedene Rollen bei der Verwaltung und Überwachung des Projekts. Alle Rollen nehmen eine entscheidende Bedeutung ein und sind für das effektive Funktionieren des Scrum-Prozesses notwendig. Scrum-Teams sind selbstgesteuert und setzen sich in der Regel aus Personen mit unterschiedlichem beruflichem Hintergrund zusammen. Jedes Team verfügt über das gesamte Wissen, das für die Durchführung des Projekts als notwendig erachtet wird, so dass das Team nicht auf andere Arbeitsleistungen zurückgreifen muss.4
Erfahrene Agile Coaches wissen, dass Scrum auf der Theorie komplexer adaptiver Systeme basiert. Es ist keine Methodik, kein Prozess und auch kein Verfahren. Es ist ein Rahmenwerk, dass auf der Durchsetzung einfacher Beschränkungen basiert, die ein durchschnittliches Team dazu bringen, sich selbst in einen hyperproduktiven Zustand zu organisieren. Einfache Regeln können die Selbstorganisation auf allen Ebenen einer Organisation vorantreiben.5
2.1.1 Product Owner
Die Rolle des PO ist eine der wichtigsten Rollen in Scrum und oft auch die schwierigste. Er ist für die Finanzierung des Projekts während seines kompletten Lebenszyklus verantwortlich und gibt die Anforderungen und Ziele des Projekts vor. Seine wichtigste Aufgabe ist die Maximierung des Outputs des Teams und des Outputs für jede Aufgabe, basierend auf dem Return on Investment.6
Der PO ist für die Pflege und Priorisierung des sogenannten Product Backlog für das zu entwickelnde Produkt verantwortlich. Das Product Backlog muss ständig gepflegt und überprüft werden und ist das Rückgrat der Aktivitäten des Product Owner in Zusammenarbeit mit dem Scrum Master, dem Team und den Stakeholdern. Gemeinsam definieren sie die Funktion des Produkts. Die Forschung hat gezeigt, wie wichtig es ist, dass Stakeholder und Kunden sich verpflichten, an dem Projekt teilzunehmen. Durch eine enge Zusammenarbeit kann eine Reihe von Problemen vermieden werden, zum Beispiel durch das Sammeln von Informationen, dem Austausch und das Führen einer klaren und priorisierten Liste von Anforderungen an den Product Owner.7
2.1.2 Entwickler
Entwickler sind die Personen in einem Scrum-Team, die in jedem Sprint an allen Aspekten der Erstellung brauchbarer Inkremente arbeiten. Die spezifischen Fähigkeiten, die von Entwicklern verlangt werden, sind oft breit gefächert und variieren je nach dem Kontext, in dem sie arbeiten. Die Entwickler sind jedoch immer für die Ergebnisse verantwortlich.8
- einen Plan für den Sprint zu erstellen, dass Sprint Backlog,
- Qualität durch die Einhaltung einer Definition of Done einzubringen,
- täglich ihren Plan zur Erreichung des Sprint-Ziels anzupassen,
- sich wechselseitig als Experten zur Verantwortung zu ziehen.
2.1.3 Stakeholder
Stakeholder sind diejenigen, die sich im Umfeld oder innerhalb der Organisation befinden. Im engeren Sinne zählen zu den Stakeholdern alle Personen und Gruppen, deren Unterstützung für das langfristige Überleben einer Organisation entscheidend ist. Dazu gehören Mitarbeiter, Kunden, Lieferanten und Geldgeber. Im weitesten Sinne sind Stakeholder alle Einzelpersonen und Gruppen, die das Erreichen der Ziele einer Organisation beeinflussen können oder selbst von der Verfolgung der Ziele der Organisation beeinflusst werden. Bei diesem Ansatz kann jeder Akteur innerhalb oder außerhalb der Organisation ein Stakeholder sein. Wettbewerber, Gewerkschaften, Protestgruppen usw. werden außerhalb der eng definierten Stakeholder einbezogen.9
2.1.4 Scrum-Master
Die Aufgabe des SM ist es, dafür zu sorgen, dass der Scrum-Prozess angewendet wird, und ein dienender Leiter des Teams zu sein. Er überwacht die Kommunikation innerhalb des Teams und stellt sicher, dass alle Hindernisse beseitigt werden, damit das Team die Ziele eines Sprints oder des gesamten Projekts erreichen kann.10
Darüber hinaus löst er Meinungsverschiedenheiten innerhalb des Teams oder zwischen dem Team und dem PO. Er ebnet den Weg für das Projekt innerhalb der Organisation, indem er sicherstellt, dass die Regeln und die Strategie der Methoden befolgt und eingehalten werden. Er stellt auch sicher, dass jegliche Politik innerhalb der Organisation die Produktivität des Teams beeinträchtigen kann. Er unterstützt das Team dabei, sich auf die Projektziele zu konzentrieren.11
2.2 MEHRWERT UND AGILES REPORTING
Zusätzlich gehören Metriken oder auch Key Performance-Indikatoren zum Projektmanagementtechnik, um zu einem bestimmten Zeitpunkt den Fortschritt und die Leistung eines Projekts im Vergleich zum Plan zu messen und die zukünftige Leistung abzuschätzen. Earned Value berücksichtigt 3 Dimensionen:12
- geplante Ausgaben,
- tatsächliche Ausgaben und
- budgetierte Ausgaben für tatsächlich geleistete Arbeit. Dies bietet einen besseren Einblick in den Projektstatus als die Betrachtung nur der ersten beiden Dimensionen.
Um die 3 zuvor beschriebenen Dimensionen des Projektmanagement zu messen und auf ein Projekt anzuwenden, sind die folgenden Schlüsselwerte erforderlich:13
- Geplanter Wert: Die budgetierten Kosten für die Arbeit, die bis zu einem bestimmten Zeitpunkt abgeschlossen werden soll.
- Erreichter Wert: Der budgetierte Betrag für die in einem bestimmten Zeitraum tatsächlich geleistete Arbeit.
- Tatsächliche Kosten: Die gesamten tatsächlichen Kosten, die bei der Ausführung der Arbeit in einem bestimmten Zeitraum entstanden sind.
Diese Werte werden auf verschiedene Weise kombiniert, um Projektleistungskennzahlen zu erhalten.
Auch sind diese Werte gut mit Scrum-Metriken nachvollziehbar und geben damit einen Mehrwert auch außerhalb des Scrum-Teams.
2.3 SCRUM-METRIKEN
Trotz aller Bemühungen um die Verbesserung des Softwareprozesses durch die Einführung von Strenge und Disziplin, wie sie von Softwarequalitätsmodellen befürwortet werden, sind wir immer noch mit einer Vielzahl gescheiterter Projekte konfrontiert. Die meisten Projektmisserfolge sind auf Probleme mit den Beteiligten zurückzuführen, so dass Projekte eher aufgrund von Problemen mit den Menschen und dem Projektmanagement als aufgrund technischer Probleme scheitern. Aus diesem Grund sind in den letzten zehn Jahren zahlreiche agile Methoden aufgetaucht, die - im Gegensatz zum disziplinierten Ansatz, der von den Qualitätsmodellen befürwortet wird - Menschen und Interaktionen über Prozesse und Werkzeuge, funktionierende Software über umfassende Dokumentation, Zusammenarbeit mit dem Kunden über Vertragsverhandlungen und Reaktion auf Veränderungen über das Befolgen eines Plans stellen. Nach dem Prinzip "Maximierung der Menge an Arbeit, die nicht erledigt werden muss" verzichten diese Methoden weitgehend auf viele Praktiken, die von Software-Qualitätsmodellen vorgeschrieben werden, einschließlich der Notwendigkeit umfassender Metrikpläne. Scrum ist eine der an den weitesten verbreiteten agilen Methoden, die sich hauptsächlich auf das Management von Softwareprojekten konzentriert. Die Erfahrung hat gezeigt, dass die Einführung agiler Methoden das Management des Entwicklungsprozesses und der Kundenbeziehungen verbessert, die Zahl der Überstunden verringert und die Kundenzufriedenheit erhöht. Im Rahmen von Scrum wird nur eine Metrik für die Softwareentwicklung verwendet: Die Schätzung des verbleibenden Arbeitsaufwands, der für die Fertigstellung eines Product Backlog-Elements oder einer Aufgabe in einem Sprint Backlog erforderlich ist. Anhand dieser Metrik können Burndown-Diagramme entwickelt werden, die die verbleibende Arbeit über die Zeit darstellen. In den Scrum- Büchern wird ein Sprint-Burndown-Diagramm als ein Ort definiert, an dem der tägliche Fortschritt angezeigt wird, und ein Produkt-Burndown-Diagramm als ein Ort, an dem der monatliche (pro Sprint) Fortschritt angezeigt wird. In den letzten Jahren haben Forscher und Praktiker jedoch erkannt, dass Scrum ausgefeiltere
Metriken benötigt, die einen besseren Einblick in den Softwareentwicklungsprozess geben würden.14
2.3.1 Metriken
Häufig wird die Zeit der geleisteten Arbeit oder der abgeschlossenen Aufgaben gemessen, ohne dass die Fortschritte bei der Roadmap des Produkteigentümers oder bei den Prozessverbesserungen, die einen zusätzlichen Wertbeitrag leisten, eindeutig nachgewiesen werden können. Das Management kann die Leistung von agilen Teams nicht direkt vergleichen. Produktivität und Qualität liegen bei weniger als 25 % dessen, was sie bei normaler Arbeitsweise des Teams erreichen würden. Es gibt jedoch Teams, die die Grenzen des Mittelmaßes durchbrochen haben.15
Um ein Projekt erfolgreich und rechtzeitig abschließen zu können, muss sichergestellt werden, dass zu Beginn des Projekts genaue Schätzungen vorliegen. Die schwierigste Aufgabe zu Beginn eines Scrum -Projekts ist es, eine grobe Schätzung zu erstellen. In der ersten kleinen Iteration klafft eine Lücke zwischen der tatsächlichen Arbeit und der Schätzung, weil die Schätztechniken nicht klar sind. In Scrum verwandelt die Schätzung einzelne Aktivitäten in Gruppenaktivitäten, und die Diskussion wird zu einem integralen Bestandteil der Schätzung. In Scrum werden die Schätzungen von dem Team erstellt, das tatsächlich an dem Projekt arbeitet. Schätzungen sind genau, wenn sie aus dem Fachwissen des Teams und früheren Erfahrungen mit ähnlichen Aufgaben abgeleitet sind. Darüber hinaus bietet die Schätzung im Diskussionsmodus einen Gesamtüberblick über die zu erledigende Aufgabe, z. B. über die Komplexität der Aufgabe, so dass eine bessere Schätzung erzielt werden kann. In Scrum wird der Aufwand zur Erstellung eines Produkts durch die Schätzung der User Stories des Produkts erreicht. Es gibt verschiedene Techniken, die Teammitglieder anwenden können, um User Stories zu schätzen.16
Softwaremetriken spielen eine wichtige Rolle bei der Messung aller Attribute der Softwareentwicklung und des Projekterfolgs. Die Qualität und Produktivität eines Teams sollten genau gemessen werden. Es werden qualitative und quantitative Messungen vorgeschlagen, um die verschiedenen Entwicklungsprozesse zu klären und zu analysieren, die zur Verbesserung der Qualität und Produktivität des Teams durchgeführt werden. Die Verwendung von Kennzahlen wird das Verhalten des Teams dahingehend ändern, dass es die vom Unternehmen festgelegten Regeln befolgt. Softwaremetriken können den Entwicklungsprozess verbessern, die Qualität von Projekten und Kontrollen erhöhen und den Schätzungsprozess verbessern. Softwaremetriken können verwendet werden, um einen objektiven Überblick zu erhalten und die verschiedenen Auswirkungen von Änderungen im Softwareentwicklungsprozess zu bewerten. Darüber hinaus bieten Softwaremetriken Vorteile bei der Überprüfung von Projektzeitplänen, der Überwachung der Produktqualität und der Vorhersage des Projekt- und Programmmanagements.17
Bei der Planung eines Projekts muss auch die Datenerfassung geplant werden, um festzulegen, was gemessen werden soll, wie es gemessen werden soll, welche Metriken verwendet werden sollen und welche Daten wann erhoben werden sollen. Der Zweck von Softwaremetriken ist die Verbesserung der Softwareentwicklung und die Aufrechterhaltung des Softwareentwicklungsprozesses. Sie umfassen in der Regel auch ein Benchmarking. Softwaremetriken messen die Effektivität der Werkzeuge, Methoden und Techniken, die zur Entwicklung von Software eingesetzt werden. So hilft Metriken den Teams, den Fortschritt der Entwicklung zu erkennen und unbemerkte Bereiche zu identifizieren, die verbessert werden müssen.18
Agile Methoden der Softwareentwicklung werden seit etwa 10 Jahren eingesetzt. Der Begriff agil wird meist mit der schnellen, kostengünstigen und qualitativ hochwertigen Implementierung von Software in Verbindung gebracht.
In diesem Zusammenhang hört man oft Diskussionen über die Entbürokratisierung der Softwareentwicklung und die Abkehr von dokumentenbasierten Ansätzen. Allen agilen Methoden gemeinsam ist die Anwendung der folgenden Praktiken:19
- Iterativer oder zyklischer Ansatz, bei dem sich kurzfristige Planungs- und Entwicklungsphasen abwechseln.
- Berücksichtigen Sie rechtzeitige und nach Möglichkeit sofortige Rückmeldungen durch eine frühzeitige Systemeinführung.
2.3.1.1 Velocity
Die Baseline Velocity (100%) wird für ein Team während des ersten Sprints festgelegt. Der Product Owner stellt das priorisierte Product Backlog im Sprint Planning Meeting vor. Dieses wird mithilfe von Planning Poker und Story Points geschätzt. Das Team wählt aus, was während des Sprints erledigt werden kann, und der Product Owner legt fest, was genau am Ende des Sprints "erledigt" ist. Die Summe der ursprünglichen Schätzungen für die genehmigte Arbeit ist die Baseline Velocity.20
Velocity ist definiert als: V = £ der ursprünglichen Schätzungen aller angenommenen Arbeiten.
In Scrum erkennen wir die Wertschöpfung erst dann an, wenn die Arbeit vom Product Owner als "erledigt" akzeptiert wird. Daher fühlen sich Teammitglieder, die Zeit in eine Initiative investieren, die am Ende des Sprints nicht abgeschlossen ist, zunächst gekränkt, wenn für ihre Arbeit keine Punkte vergeben werden.[20]
Scrum Master, die danach streben, Bewegung zu belohnen, wenn sie nicht abgeschlossen wird, erweisen ihrem Team einen schlechten Dienst, da dieses
Delta dazu dient, das Ausmaß der Suboptimierung zu verdeutlichen, dass bei erfolgreicher Anwendung des Scrum-Frameworks überwunden wird. [20]
2.3.1.2 Sprint Goal Success
Ein sogenanntes Sprint Goal ist das Ziel, dass nach Abschluss eines jeden Sprints erreicht werden soll. Sprint Goals werden zwischen dem Product Owner und dem Scrum Team besprochen. Das Sprint Goal muss spezifiziert und messbar sein. Zum Beispiel die Bereitstellung eines X-Features, die Überprüfung, ob die Architektur die gewünschte Leistung ermöglicht (Adressierung eines Risikos), und der Test, ob ein Benutzer bereit ist, sich zu registrieren, bevor er die Produktfunktionen nutzt (Testen einer Annahme). Die Auswahl eines Sprint-Ziels kann sein, wenn das Team die folgenden drei Fragen beantwortet:21
- Wofür findet der Sprint statt?
- Wie wird das Sprint-Ziel erreicht?
- Wie weiß man, ob das Ziel erreicht wurde?
2.3.1.3 Entgangene Fehler und Fehlerdichte
Es ist die Gesamtzahl der Fehler, mit denen die Benutzer konfrontiert werden. Ein Scrum-Team versucht, entgangene Fehler durch vollständige Testfälle zu vermeiden. Aber ein Trend zu entgangenen Fehlern deutet auf eine gute Produktqualität hin.22
[...]
1 Vgl. Sutherland (2011), S. 7
2 Vgl. Schwaber et al. (2020), S. 1
3 Vgl. Hundermark (2009) , S. 6
4 Vgl. Sif Sverrisdottira, et al. (2014) ,S. 260
5 Vgl. Downey, et al. (2013), S. 4871
6 Vgl. Sif Sverrisdottira, et al., (2014), S. 260
7 Vgl. Sif Sverrisdottira, et al. (2014), S. 261
8 Vgl. Schwaber, et al. (2020), S. 6
9 Vgl. Theuvsen (2001), S. 2
10 Vgl. Sif Sverrisdottira, et al. (2014), S. 259
11 Vgl. Sif Sverrisdottira, et al. (2014) ,S. 260
12 Vgl. Cabri, et al. (2006), S. 1
13 Vgl. Cabri, et al. (2006), S. 1-2
14 Vgl. Viljan, et al. (2007), S. 242
15 Vgl. Downey, et al. (2013), S. 4871
16 Vgl. Agarwal, et al. (2012), S. 97
17 Vgl. Kurnia, et al. (2019), S. 175
18 Vgl. Ashraf, et al. (2017), S. 28
19 Vgl. Schmietendorf (2012), S. 62-63
20 Vgl. Downey, et al. (2013), S. 4872
21 Vgl. Dixit, et al. (2019), S. 81
22 Vgl. Dixit, et al. (2019), S. 82