Qualitätsmanagement in agilen Projekten


Bachelorarbeit, 2017
60 Seiten, Note: 1,3

Leseprobe

Inhaltsverzeichnis

Abkurzungsverzeichnis

Abbildungsverzeichnis

Glossar

1. Einleitung
1.1 „Agile Qualität“ - ein vermeintliches Paradoxon?
1.2 Abgrenzung des Untersuchungsgegenstandes
1.3 Ziel und Vorgehensweise der Untersuchung

2. Agiles Projektmanagement
2.1 Grundsätze und Prinzipien
2.2 Die agile Methode Scrum

3. Einfuhrung in das Qualitatsmanagement
3.1 Einführung in das Qualitätsmanagement
3.2 Grundsätze des Qualitätsmanagements
3.3 Qualitätsmethoden und Werkzeuge

4. Qualitatsmanagement in Scrum
4.1 Schnittmenge des Qualitätsmanagements und der agilen Methode Scrum ..
4.1.1 Kundenorientierung
4.1.2 Führung
4.1.3 Einbeziehung von Personen
4.1.4 Prozessorientierter Ansatz
4.1.5 Verbesserung
4.1.6 Faktengestützte Entscheidungsfindung
4.1.7 Beziehungsmanagement
4.2 Integrierte Qualitätselemente in Scrum
4.2.1 Definiton of Done
4.2.2 Testkonzept
4.3 Ergänzende Vorschläge
4.3.1 Hardening Sprints
4.3.2 Fehlermanagement

5. Entwicklung eines qualitatsorientierten, agilen Prozessmodells
5.1 Prozessablauf
5.2 Rollenmodell
5.3 Aufgaben des QMB
5.4 Neue Ereignisse und Artefakte
5.4.1 Backlog Refinement
5.4.2 Erweiterte Story Cards
5.4.3 Erweitertes Burn-Up Chart
5.5 Chancen und Risiken

6 Gesamtbewertung und Ausblick

Anhang 1: llberblick Schnittmenge QM und Scrum

Anhang 2: Beispiel Backlog Refinement

Anhang 3: Erweitertes Burn-Up-Chart

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Prinzipien des agilen Manifest

Abbildung 2: Grafischer Ablauf von Scrum

Abbildung 3: Die Qualität als Ausmaß der Anpassung

Abbildung 4: PDCA-Zyklus mit den Komponenten des QM

Abbildung 5: Die Rolle des Kunden in Scrum

Abbildung 6: Der Sprint im PDCA-Zyklus

Abbildung 7: Agile Test- und Qualitätsmanagement-Praktiken

Abbildung 8: Qualitätsorientier Prozessablauf auf der Basis von Scrum

Abbildung 9: Rollen, Beziehungen und Verantwortlichkeiten im qualitätsorientierten Modell

Abbildung 10: Schrittweises Umsetzen von Kundenanforderungen im QFD

Abbildung 11: Konsequenzen des Backlog Refinements

Abbildung 12: Design einer Story Card

Abbildung 13: Beispiel eines Burn-up-Charts mit erweiterten KPIs

Glossar

- Daily Scrum (Ereignis): Hat eine feste Länge von 15 Minuten und findet täglich zur gleichen Uhrzeit statt. Dabei synchronisiert sich das Team und bespricht die Planung bis zum nächsten Tag. Die Fragen „Was habe ich gestern erreicht?“, „Was werde ich heute erledigen?“ und „Sehe ich dabei Hindernisse?“ werden von jedem Teammitglied beantwortet. Das Team überprüft so den Fortschritt hinsichtlich der Zielerreichung und kann einen gewissen Trend bei der Bearbeitung der Backlog Einträge feststellen.1
- Entwicklungsteam (Rolle): Ist selbstorganisiert, funktionsübergreifend besetzt und hat volle Autorität in allen Entscheidungen, die bezüglich der Zielerreichung getroffen werden. Das Team sollte zwischen drei und sechs Personen enthalten, aber nicht hierarchisch strukturiert sein. Seine Hauptaufgabe ist die Entwicklung des Produktes in Scrum, wobei das Team selbst für den Erfolg der einzelnen Sprints verantwortlich ist.2
- Product Backlog (Artefakt): Stellt eine vom Product Owner verwaltete Liste dar, die alle Anforderungen an das Produkt in Form von User Stories darstellt. Die einzelnen Anforderungen, sog. Product Backlog Items, sind priorisiert und zeitlich geschätzt. Das Backlog verändert sich im Laufe der Zeit mit dem Produkt weiter.3 Die Product Vision und der Product Backlog sind nach Schwaber die notwendigen Voraussetzungen, die für den Start eines Scrum Projektes mindestens gegeben sein müssen.4
- Product Owner (Rolle): Er ist die Schnittstelle zu sämtlichen Stakeholdern, die Einfluss auf die Anforderungen am Projekt haben und vertritt dabei insbesondere die Interessen des Kunden.5 Er ist für die Erstellung eines erfolgreichen Produktes und somit den wirtschaftlichen Erfolg des Projektes verantwortlich. Zudem fällt die Pflege und Priorisierung des Product Backlog unter sein Aufgabengebiet.6
- Product Vision (inoffizielles Artefakt): Ist die Idee und der Grund für die Durchführung des Projektes, die der Product Owner in Zusammenarbeit mit dem Kunden entwirft. Sie ist jedoch kein offizielles Artefakt von Scrum.7
- Scrum Master (Rolle): Sorgt dafür, dass das Team unter optimalen Bedingungen effizient arbeiten kann. Er beseitigt alle Hindernisse8, z.B. in Form störender Außeneinflüsse, die dem Team begegnen. Zudem sorgt er für die Einhaltung der Scrum-Prinzipien und -Regeln, ist also für die Prozesse innerhalb des Projektes verantwortlich. Die Rolle des Scrum Masters stellt eine Führungsrolle ohne Weisungsbefugnis dar. So leitet er z.B. das Daily Scrum Meeting, darf aber gegenüber dem Entwicklungsteam keine Forderungen aussprechen.9
- Sprint (Ereignis): Ein Sprint umschreibt einen kompletten Scrum-Zyklus und dauert maximal einen Monat. Er umfasst das Sprint Planning, die Daily Scrums, die Entwicklungsarbeit, das Sprint Review und die Sprint Retrospective. Für jeden Sprint gibt es einen definierten Leistungsumfang und einen flexiblen Plan, der im Sprint Backlog festgelegt ist. Am Ende jeden Sprints muss ein potenziell auslieferbares Teilprodukt fertiggestellt sein.10
- Sprint Backlog (Artefakt): Besteht aus einer Auswahl bestimmter Product Backlog Einträge, auch bekannt als User Stories oder Kundenanforderungen, die das Team im nächsten Sprint abarbeiten muss. Zudem liefert es Informationen über geplante Funktionalitäten und Arbeiten im folgenden Sprint.11 Das Sprint Backlog wird im Sprint Planning Meeting erstellt und dient dem Team zur besseren Organisation während des Sprints.12
- Sprint Planning (Ereignis): Im Sprint Planning wird der kommende Sprint zusammen mit dem Product Owner und dem Scrum Master geplant und vorbereitet. Dazu wird im ersten Teil des Meetings das Ziel des Sprints definiert. Es wird eine Abschätzung vom Entwicklungsteam vorgenommen, wie viele der vom Product Owner priorisierten User Stories, es im kommenden Sprint abarbeiten kann. Nur das Entwicklungsteam selbst darf den Umfang dieser Anforderungen für den nächsten Sprint festlegen, verpflichtet sich damit aber auch dazu, diesen zu erreichen.13 Im zweiten Teil wird jede Anforderung in ihre einzelnen Teile zerlegt und deren genaue Umsetzung geplant. Die daraus entstehenden konkreten Aufgaben sind im Sprint Backlog niedergeschrieben.14
- Sprint Retrospective (Ereignis): Findet am Ende des Sprints statt und gibt dem Entwicklungsteam die Möglichkeit über dessen Zusammenarbeit im Entwicklungsprozess zu sprechen. Das Meeting bietet die Gelegenheit, die eigenen Verhaltensweisen des vergangenen Sprints zu reflektieren und zu analysieren, um anhand dieser Erkenntnisse Verbesserungsvorschläge für den nächsten Sprint zu definieren.15
- Sprint Review (Ereignis): Am Ende eines Sprints wird das entstandene Teilprodukt, bzw. Produktinkrement, präsentiert. Obwohl das Ergebnis vom Kunden und vom Product Owner begutachtet und kontrolliert wird, handelt es sich mehr um ein informelles Meeting, als um einen Statusbericht.16 Soll eine Kursänderung vorgenommen werden, kann der Product Backlog entsprechend angepasst werden.

Einleitung

1.1 „Agile Qualität“ - ein vermeintliches Paradoxon?

„Agilität heißt Beweglichkeit. Beweglichkeit setzt Freiräume und Freiheiten voraus, das heißt Abweichung von Standards oder vorgegebenen vielleicht starren, aber möglicherweise auch bewährten Regelwerken.“17

Durch das steigende Anspruchsniveau der Kunden, die zunehmende Komplexität im Projekt und den verstärkten Wettbewerbsdruck der Globalisierung, werden kürzere Innovationszyklen und permanente Verbesserungsmaßnahmen im Unternehmen unabdingbar.18 Viele Firmen reagieren auf den schnellen Wandel in der heutigen Zeit mit dem Umstieg von herkömmlichen Organisationsstrukturen auf Projektarbeit. Einer empirischen Studie zu Folge, verbrachten Mitarbeiter 2015 im Schnitt 35% ihrer Arbeitszeit in Projekten - und damit 60% mehr, als noch vor 3 Jahren.19 Dabei sticht vor allem das agile Projektmanagement hervor. Es erlebt seit einigen Jahren einen Höhenflug und verbreitet sich inzwischen auch außerhalb der IT-Branche.20 Die agilen Werte, wie etwa Kundenorientierung, Flexibilität und Selbstorganisation, sind gefragter denn je. Um eine flexible Reaktion auf Anforderungsänderungen oder die Entwicklung des höchstmöglichen Kundennutzens in kürzester Zeit zu ermöglichen,21 werden verglichen zum konventionellen Projektmanagement, grundlegende Änderungen gelebt. Was auf der einen Seite große Vorteile bietet, besitzt allerdings auch eine Kehrseite. Übliche Standardelemente zur Qualitätssicherung, wie ausführliche Dokumentationen, Standardisierungen, umfangreiche Projektpläne oder feste Vereinbarungen mit Projektpartnern, gehören im agilen Projekt der Vergangenheit an. Sie gelten zwar als unflexibel und stark reglementiert, stellen aber gleichwohl eine bewährte Basis für Qualitätssicherstellung und -steigerung in Projekten dar. Im agilen Projektmanagement scheint es, als ob all diese qualitätssichernden Methoden und Werkzeuge keine Verwendung finden. Tatsächlich zeigt der World Quality Report auf, dass ein Großteil der agilen Verwender keinen spezifischen Ansatz zur Qualitätssicherung verwendet.22

Und dennoch sprechen die Zahlen für sich: Die Erfolgsquote und Ergebnisqualität agiler Methoden wird höher bewertet als die des konventionellen Projektmanagements: Während fast ein Viertel der agilen Anwender eine Erfolgsquote über 90% erzielt, erreichen klassische Anwender diese in nur etwa 5% der Projekte, beweist eine Studie des BPM-Labors Koblenz.23 Das wirft die Frage auf, wie Qualität in agilen Projekten, ohne die explizite Verwendung klassischer Ansätze des Qualitätsmanagement, gewährleistet werden kann. Dabei sind insbesondere die Fragen interessant, welche Elemente als charakterisierend für das Qualitätsmanagement gelten und inwiefern diese bereits in den Grundzügen des agilen Projektmanagements verankert sind. Eine Kombination des Qualitätsmanagements mit dem agilen Projektmanagement erscheint zunächst kontrovers. Im Hinblick auf die hohe Erfolgsquote durch die „Freiräume und Freiheiten“ des agilen Projektmanagements, sollte die Möglichkeit einer Synthese mit den „bewährten Regelwerken“ des Qualitätsmanagements dennoch geprüft werden. Kann die Verschmelzung aus Stabilität und Dynamik gelingen?

1.2 Abgrenzung des Untersuchungsgegenstandes

In dieser Arbeit wird der Fokus auf die Betrachtung des Qualitätsmanagements in agilen Projekten gelegt. Ein sonst in Themen der IT-Branche üblicher, technischer Schwerpunkt, wird dabei wissentlich umgangen. Auch das im Zusammenhang mit Qualität gängige, konventionelle Projektmanagement wird bewusst nicht berücksichtigt, zumal diesbezüglich bereits entsprechende Literatur vorliegt. Bei der Suche nach einer geeigneten agilen Methode, die stellvertretend für das agile Projektmanagement steht, kristallisierte sich Scrum heraus. Scrum erhielt 2014 laut der internationalen BPM-Studie die besten Bewertungen in allen untersuchten Teilkriterien und ist mit 86% das meistgenutzte agile Prozessmodell.24 Zudem setzt Scrum Organisation und Ablauf in den Mittelpunkt des Projektes und fokussiert sich nicht auf technische Aspekte, wie es bei vielen anderen agilen Methoden der Fall ist.25 Das Einsatzgebiet erstreckt sich damit über das der Softwareentwicklung hinaus. Somit eignet es sich als Repräsentant des agilen Projektmanagements und wird in dieser Arbeit als Synonym für agile Methoden verwendet.

Eine Schwierigkeit liegt in der Vermittlung der Werte des Qualitätsmanagements. Hierzu wurden die sieben Grundsätze des Qualitätsmanagements aus der ISO 9000 gewählt, da sie in Kürze die wesentliche Charakteristik des Qualitätsmanagements beschreiben. Sie machen den komplexen Inhalt greifbar und stellen die Basis für einen skalierbaren Abgleich mit den Werten des agilen Projektmanagements dar. Eine Ergänzung dieser recht allgemeinen Norm findet durch die ISO 10006 statt. Sie entstammt ebenso der DIN 9000-Reihe und schafft die notwendige Spezifizierung des Qualitätsmanagements auf das Projekt26. Einerseits werden darin einheitliche Begrifflichkeiten und Handlungsempfehlungen in Bezug auf das Qualitätsmanagement generiert. Andererseits wird auf Besonderheiten bei der Anwendung von Qualitätsmanagement in Projekten hingewiesen. Die Norm gilt als Leitfaden für alle Arten von Projekten, egal welcher Größe oder Komplexität diese entsprechen.27 Zudem enthält sie neue Textabschnitte hinsichtlich der Grundsätze des Qualitätsmanagements und erweist sich deshalb als sinnvolle Ergänzung.

1.3 Ziel und Vorgehensweise der Untersuchung

Ziel der Arbeit ist es zu erörtern, ob die konventionell geprägten Grundwerte des Qualitätsmanagements auch im widersprüchlich scheinenden, agilen Projekt wiederzufinden sind. Darüber hinaus soll geklärt werden, ob qualitätsbezogene Ergänzungen im agilen Modell möglich sind und an welcher Stelle diese sinnvoll einzubinden wären. Anhand dieser Erkenntnisse soll fortschreitend ein agil fokussiertes, theoretisches Projektmodell entworfen werden, das durch Methoden des Qualitätsmanagements ergänzt wird.

Von der beschriebenen Zielsetzung abgeleitet, zeichnet sich der Gang der Untersuchung ab: In Kapitel 2 werden zunächst die Grundsätze und Prinzipien des agilen Projektmanagements dargelegt, bevor dessen meistverwendeter Vertreter, die agile Methode Scrum, genauer beschrieben wird. In Kapitel 3 erfolgt eine Einführung in das Qualitätsmanagement. Dabei werden ausgehend von allgemeinen Definitionen und wesentlichen Komponenten, die sieben Grundsätze des Qualitätsmanagements der ISO 9000 definiert. Sie stellen eine wesentliche Grundlage für die Bearbeitung des nachfolgenden Kapitels dar. Darüber hinaus werden Methoden und Werkzeuge des Qualitätsmanagements erläutert und mit einem Beispiel belegt. Mit Hilfe der Grundsätze des Qualitätsmanagements wird in Kapitel 4 getestet, inwieweit diese im agilen Modell Scrum bereits Anwendung finden. Zusätzlich dazu werden weitere, qualitätssichernde Elemente aus Scrum erarbeitet und durch zwei theoretische Vorschläge ergänzt. Für die Bereiche von Scrum, die eine mangelnde Übereinstimmung mit den Grundsätzen der ISO 9000 aufweisen, werden Möglichkeiten der Verbesserung entwickelt. Diese werden bei der Entwicklung eines qualitätsorientierten, agilen Prozessmodells implementiert, welches in Kapitel 5 beschrieben wird. Abschließend fasst Kapitel 6 die wesentlichen Ergebnisse der Arbeit zusammen und gibt einen Ausblick auf den zukünftigen Gang der Thematik.

2. Agiles Projektmanagement

2.1 Grundsätze und Prinzipien

„Kleine Taten, die man ausführt, sind besser als große, die man plant.“28

Agiles Projektmanagement, auch bezeichnet als agile Softwareentwicklung, entstand Ende der 1990er Jahre als Gegenbewegung zu den zuvor starren und von hoher Standardisierung geprägten traditionellen Projektmanagementansätzen.29 Vor allem im Bereich der IT-Projekte wurden die klassischen Ansätze unzweckmäßig, da sich die Projektziele hier schneller veränderten. Aufgrund dieser „beweglichen Ziele“ war es kaum möglich und vor allem nicht sinnvoll, die ursprünglichen Anforderungen des Auftraggebers unverändert zu belassen. Auch die Risiken der technischen Umsetzung konnten in den neuartigen Softwareprojekten vom Start weg nicht konkret eingeschätzt werden.30 Somit war es nicht länger möglich, einen von Beginn an abgesteckten Projektrahmen einzuhalten und ein detailliert geplantes Endziel genau nach Vorgaben zu erreichen. Vielmehr konnte erst während der Arbeit im Projekt ausgemacht werden, welche Teilziele überhaupt erarbeitet werden sollen. Gemäß dem eben genannten Zitat von George Marshall, wurden die Projekte in vielen kleinen Einzelschritten ausgeführt, anstatt zu Beginn den gesamten Ablauf zu planen, zumal das eigentliche Ziel erst im fortschreitenden Projektverlauf klarer erkennbar wurde. So entwickelte sich die flexible Projektsteuerung, die sich aufgrund einer schnelleren und zunehmend komplexen Arbeitswelt behaupten konnte.31 Ihre Grundsätze und Werte wurden 2001 von zahlreichen Projektmanagementexperten im „Agilen Manifest“ formuliert:

- „Individuen und Interaktionen über Prozessen und Werkzeugen“
- „Funktionierende Software über umfassender Dokumentation“
- „Zusammenarbeit mit dem Kunden über Vertragsverhandlung“
- „Reagieren auf Veränderung über dem Befolgen eines Plans“32

Hierbei darf nicht fehlinterpretiert werden, dass die Themen rechts, also beispielsweise die Prozesse und Werkzeuge, vernachlässigbar oder unwichtig wären. Auch sie sind bedeutende Teile des agilen Manifests. Im Zweifelsfall jedoch, haben die Themen links Priorität.33

Individuen und Interaktionen über Prozessen und Werkzeugen

Die Leichtgewichtigkeit eines agilen Projekts wird vor allem durch die darin involvierten Personen und ihre Zusammenarbeit sowie Kommunikation untereinander erzeugt.34 Grundsätzlich besteht die Gefahr, dass der Mitarbeiter durch starr reglementierte Prozesse aus der Verantwortung genommen wird und die Prozesse auch dann noch umsetzt, wenn es nach seiner Einschätzung nach sinnvoller wäre, davon abzuweichen. Standardisierungen werden deshalb soweit begrenzt, dass genug Freiraum für individuelle, menschliche Entscheidungen bestehen bleibt, eine gewisse Absicherung aber dennoch vorhanden ist.35

Funktionierende Software über umfassender Dokumentation

An oberster Stelle steht die Funktionalität und Qualität der Software. Sie wird in kurzen zeitlichen Abständen an den Kunden ausgeliefert, wodurch das Projekt direktes Feedback erhält und die Möglichkeit hat, Änderungen schnell vorzunehmen. Der Aufwand an Anforderungsdokumentationen wird somit reduziert. Zudem kann eine gute Kommunikation der am Projekt beteiligten Personen die Notwendigkeit der ausführlichen Dokumentation vermindern.36

Das bedeutet jedoch nicht, dass Dokumentationen zu vernachlässigen sind. Sie sollten stattdessen dem agilen Modell angepasst und somit leicht veränderbar sein.37

Zusammenarbeit mit dem Kunden über Vertragsverhandlung

Eine enge Zusammenarbeit und ein gutes Vertrauensverhältnis mit dem Kunden sind für agile Ansätze wichtig. Da der Kunde kontinuierlich Feedback zum ausgelieferten Produktinkrement geben kann, ist er direkt am Entwicklungsprozess beteiligt. Das minimiert das Risiko, für den Kunden unbrauchbare Produkte zu entwickeln und demzufolge wird auch die Bedeutung detaillierter Verträge verringert.38

Reagieren auf Veränderung über dem Befolgen eines Plans

Da sich während eines Projekts die Anforderungen häufig verändern, verzichten agile Methoden anfangs auf eine ausführliche Gesamtplanung. Die Planung wird stattdessen schrittweise detailliert. Aus diesem Grund kann auf Änderungswünsche flexibel reagiert werden.39 Planung ist in jedem Fall weiterhin ein wichtiger Bestandteil des Projekts, dient nach Meyerbröker aber „vorrangig dem Zweck, sich gedanklich mit der Zukunft auseinanderzusetzen, um in der komplexen Projektrealität besser handlungsfähig zu sein“40, als stur die vorgesehenen Schritte zu befolgen.

Aufbauend auf den eben beschriebenen agilen Grundhaltungen, verdeutlichen die 12 Prinzipien des agilen Manifests (Abbildung 1) die agile Denkweise noch expliziter:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Prinzipien des agilen Manifests41

Wie bereits in den agilen Werten betont, steht die Zufriedenstellung des Kunden an erster Stelle (1). Deshalb werden Anforderungsveränderungen des Kunden zu jedem Zeitpunkt des Projektes umgesetzt (2) und Ergebnisse, meist in Form funktionierender Produktinkremente, schnellstmöglich bereitgestellt (3). Diese Teilprodukte werden regelmäßig vom Kunden überprüft und dienen als wichtigster Fortschrittsnachweis des Projektes (4). Das Team sollte bereichsübergreifend besetzt sein, sodass Fachexperten und Entwickler täglich zusammenarbeiten (5). Dabei steht die eben erwähnte, intensive und direkte Kommunikation von Angesicht zu Angesicht im Vordergrund (6). Sie ist nötig, da sich das Team selbst organisieren muss und ihm alle Freiheiten über Entscheidungen in der Produktentwicklung zugesprochen werden (7). Die dadurch erhöhte Verantwortlichkeit und Autorität des Teams steigert auch die persönliche Beteiligung und Einbeziehung in das Projekt.42 Durch die erhöhte Motivation der Individuen wird das richtige Arbeitsumfeld geschaffen. Das Team erledigt seine Aufgaben selbstständig, bekommt aber Hilfe, falls diese benötigt wird (8). Eine nachhaltige Arbeitsweise durch gleichmäßiges Tempo wird angestrebt (9), bei der die Effektivität durch regelmäßige Reflektion im Team gesteigert werden soll (10). Zuletzt wird sowohl auf technische Exzellenz (11), als auch auf Einfachheit (12) geachtet werden. Letzteres wird als „die Kunst, die Menge nicht getaner Arbeit zu maximieren“43 beschrieben und kann durch simple, aber effektive Prozesswerkzeuge wie beispielsweiße Haftnotizen oder Tafelbilder, erzeugt werden.44

2.2 Die agile Methode Scrum

Die beschriebenen Prinzipien stellen eine bewährte Handlungsweise zur Unterstützung des agilen Vorgehens dar. Agile Methoden beschreiben hingegen eine konkrete Konstellation aus mehreren dieser agilen Prinzipien.45 Die meistgenutzten Vertreter agiler Methoden sind Scrum, Kanban, Extreme Programming oder Feature Driven Development.46 Aus den in Kapitel 1.2 dargestellten Gründen, wird Scrum in dieser Arbeit stellvertretend für agile Methoden verwendet.

Scrum stellt ein Rahmenwerk zur Entwicklung komplexer Produkte dar, das die darin enthaltenen Rollen, Artefakte und Regeln klar absteckt.47 Diese werden im Glossar zum besseren Verständnis knapp erläutert. In Scrum wird ein iterativer, inkrementeller Ansatz benutzt.48 Das heißt, das Produkt wird in vielen einzelnen, sich wiederholenden Arbeitsschritten stufenweise entwickelt. Die Länge dieser Arbeitsschritte, sogenannte Sprints, ist im Voraus festgelegt und wird nicht nach der Dauer festgelegt, die für die Erstellung einer bestimmten Leistung notwendig ist. Vielmehr wird das zu liefernde Ergebnis in so viele Einzelteile heruntergebrochen, dass ein Fragment davon innerhalb eines Sprints fertiggestellt werden kann.

Scrum unterscheidet grundsätzlich drei verschiedene Hauptrollen: Den Product Owner, den Scrum Master und das Entwicklungsteam. Sie bilden zusammen das ScrumTeam.49 Innerhalb des Scrum-Teams darf keine Rolle einer anderen vorschreiben, wie deren Arbeit zu erledigen ist. Jede Rolle hat einen festgelegten Aufgabenbereich, für den sie ausschließlich selbst verantwortlich ist.50 Zu den Ereignissen in Scrum gehören der Sprint, das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospective. Alle Ereignisse sind zeitlich beschränkt, d.h. die Dauer steht von Beginn an fest, ist immer gleichlang und darf nicht verändert werden. Der Ablauf eines Sprint Zyklus wird nachfolgend in Abbildung 2 dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Grafischer Ablauf von Scrum51

Der Sprint-Zyklus startet mit der Produktvision des Kunden. Im Scrum Guide findet diese Product Vision zwar keine Erwähnung, dennoch stellt sie in der Praxis häufig die Basis für das Scrum-Projekt dar.52 Auf dieser Grundlage findet das Sprint Planning Meeting statt, das vor jedem Sprint durchgeführt wird. Das gesamte Scrum-Team plant darin die Arbeit für das kommende Zeitintervall, bevor schließlich die tatsächliche Produktentwicklung im Sprint, dem Herzstück von Scrum, beginnt. Am Ende eines solchen Sprints muss ein fertiges, also potentiell auslieferbares, Teilprodukt vom Team erstellt worden sein. Im darauffolgenden Sprint Review wird dieses sogenannte Inkrement dem Kunden und dem Product Owner vorgestellt, von ihnen überprüft und daran das Ergebnis des Sprints gemessen. Abschließend erfolgt die Sprint Retrospective, ein Meeting, bei dem das Team die eigene Arbeitsweise kritisch hinterfragt und Verbesserungen für den kommenden Sprint festlegt. Die hier festgelegten Veränderungen werden dann im Sprint Planning aufgegriffen, wodurch der Sprint-Zyklus mit verbesserten Prozessen erneut durchlaufen wird.

[...]


1 Vgl. Schwaber, K., Sutherland, J., Scrum Guide, 2013, S.10f.

2 Vgl. Wirdemann, R., Scrum mit User Stories, 2011, S.37f.

3 Vgl. Schwaber, K., Sutherland, J., Scrum Guide, 2013, S.13.

4 Vgl. Ebd., S.68.

5 Vgl. Wirdemann, R., Scrum mit User Stories, 2011, S.43.

6 Vgl. Goll, J., Hommel, D., Scrum System, 2015, S.89f.

7 Vgl. Wirdemann, R., Scrum mit User Stories, 2011, S.29.

8 Sog. Impediments

9 Vgl. Goll, J., Hommel, D., Scrum System, 2015, S.91.

10 Vgl. Schwaber, K., Sutherland, J., Scrum Guide, 2013, S.8f.

11 Vgl. Ebd., S.15.

12 Vgl. Hanser, E., Agile Prozesse, 2010, S.75.

13 Vgl. Goll, J., Hommel, D., Scrum System, 2015, S.94.

14 Vgl. Schwaber, K., Sutherland, J., Scrum Guide, 2013, S.10.

15 Vgl. Wirdemann, R., Scrum mit User Stories, 2011, S.31.

16 Vgl. Schwaber, K., Sutherland, J., Scrum Guide, 2013, S.11.

17 Oesterreich, B., Weiss, C., Agiles PM, 2008, S.19.

18 Vgl. Litke, H., Projektmanagement, 2005, S.4f.

19 Vgl. Hays, empirische Studie agile Projekte, 2015, S.3.

20 Vgl. Conforto, E., et al., APM in other industries, 2014, S.27ff.

21 Vgl. Goll,J., Hommel, D., Scrum System, 2015, S.82.

22 Vgl. World Quality Report, 2015, S.32ff.

23 Vgl. BPM-Labor Koblenz, Studie Status Quo Agile, 2014, S.3; S.25.

24 Vgl. BPM-Labor Koblenz, Studie Status Quo Agile, 2014, S.4.

25 Vgl. Steyer, M., Agile Muster und Methoden, 2010, S.22.

26 Vgl. Preißner, A., Projekterfolg durch QM, 2006, S.79.

27 Vgl. Deutsches Institut für Normung, ISO 10006, 2004, S.6.

28 Marshall, G., 1880-1959

29 Vgl. Oesterreich, B., Weiss, C., Agiles PM, 2008, S.14.

30 Vgl. Meyerbröker, P., Agiles Projektmanagement, 2011, S.6.

31 Vgl. Ebd., S.4.

32 http://agilemanifesto.org/, abgerufen am 24.11.2016

33 Vgl. http://agilemanifesto.org/, abgerufen am 24.11.2016

34 Vgl. Oesterreich, B., Weiss, C., Agiles PM, 2008, S.16

35 Vgl. Meyerbröker, P., Agiles Projektmanagement, 2011, S.5.

36 Vgl. Oesterreich, B., Weiss, C., Agiles PM, 2008, S.16.

37 Vgl. Hanser, E., Agile Prozesse, 2010, S.10.

38 Vgl. Oesterreich, B., Weiss, C., Agiles PM, 2008, S.16.

39 Vgl. Oesterreich, B., Weiss, C., Agiles PM, 2008, S.17.

40 Meyerbröker, P., Agiles Projektmanagement, 2011, S.8.

41 Eigene Darstellung, vgl. hierzu http://agilemanifesto.org/iso/de/principles.html, abgerufen am 24.11.2017 7

42 Vgl. Conforto, E., et al., APM in other industries, 2014, S.24.

43 http://agilemanifesto.org/iso/de/principles.html, abgerufen am 24.11.2017

44 Vgl. Conforto, E., et al., APM in other industries, 2014, S.24.

45 Vgl. Steyer, M., Agile Muster und Methoden, 2010, S.31.

46 Vgl. BPM-Labor Koblenz, Studie Status Quo Agile, 2014, S.4.

47 Vgl. Schwaber, K., Sutherland, J., Scrum Guide, 2013, S.3.

48 Vgl. Ebd., S.3.

49 Wirdemann, R., Scrum mit User Stories, 2011, S.36.

50 Vgl. Goll, J., Hommel, D., Scrum System, 2015, S.88f.

51 Eigene Darstellung, modifiziert nach Wirdemann R., Scrum mit User Stories, 2011, S.29.

52 Vgl. Goll, J., Hommel, D., Scrum System, 2015, S.99.

Ende der Leseprobe aus 60 Seiten

Details

Titel
Qualitätsmanagement in agilen Projekten
Hochschule
Ostbayerische Technische Hochschule Regensburg
Note
1,3
Autor
Jahr
2017
Seiten
60
Katalognummer
V377496
ISBN (eBook)
9783668549036
ISBN (Buch)
9783668549043
Dateigröße
1826 KB
Sprache
Deutsch
Schlagworte
Agiles Projektmanagement, Qualitätsmanagement, agil, scrum, agile qualiät
Arbeit zitieren
Lukas Braun (Autor), 2017, Qualitätsmanagement in agilen Projekten, München, GRIN Verlag, https://www.grin.com/document/377496

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Qualitätsmanagement in agilen Projekten


Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden