Add Thesis

Scrum Tools zur Unterstützung agiler Prozesse

Written by M. A. Eckhart

Paper category

Bachelor Thesis

Subject

Computer Science

Year

2015

Abstract

Scrum Dieses Kapitel erklärt das Scrum-Framework. Nach der Themeneinführung werden die in Scrum definierten Rollen, Artefakte und Aktivitäten erläutert. Am Ende dieses Kapitels werden die notwendigen Anpassungen von Scrum an andere Anwendungsbereiche als die Softwareentwicklung beschrieben, um den Gegner wegzudrängen (siehe [3, S. 6]). Scrum wurde von Jeff Sutherland und Ken Schwaber entwickelt und ist ein Prozess, der aus der Softwareentwicklung stammt. Die Leitprinzipien von Scrum sind im 2001 erstellten Agile Manifesto verankert und bestehen aus den folgenden vier Kernprinzipien (siehe [13]): Wir schätzen Individuen und Interaktionen, nicht Prozesse und Werkzeuge, wir legen Wert auf funktionale Software statt Vollständigkeit Wir achten mehr auf die Reaktion des Kunden auf Veränderungen als auf das Aushandeln von Verträgen statt dem Plan.Durch die Kombination dieser agilen Werte mit den Scrum-Regeln können wir Komplexität reduzieren. Allerdings lässt das Agile Manifest Raum für Missverständnisse, denn Leser könnten die Formulierung falsch interpretieren, sodass die rechts beschriebenen Werte komplett ihre Bedeutung verlieren. Das Agile Manifest ist nicht als Empfehlung zu verstehen, zum Beispiel muss Software nicht dokumentiert werden. Es betont nur, dass funktionale Software wertvoller sein sollte als eine umfassende Dokumentation. Der Kern von Scrum basiert auf dem Deming-Kreis, der nach William Edwards Deming benannt ist und aus dem Bereich des Qualitätsmanagements stammt (siehe [3, S. 54]). Der Deming-Kreis definiert Aktivitäten „planen“, „durchführen“, „prüfen“, „Aktion“ (zB „planen“, „umsetzen“, „prüfen“, „Aktion“) und nach der letzten Phase des Zyklus wiederholen. Das Diagramm in Abbildung 2.1 stellt den Ablauf dieses Prozesses dar. [14] Die Essenz von Deming Circle und Scrum ist empirisch, nämlich H. Der Prozess basiert hauptsächlich auf Messungen und anschließenden Verbesserungen. Scrum definiert hierfür das Mantra „Check and Adapt“. Darüber hinaus lassen sich die verschiedenen Stufen des Deming-Kreises auf Scrum-Aktivitäten übertragen. Da technische Anforderungen meist nur zu Beginn des Entwicklungsprozesses bis zu einem gewissen Grad vollständig definiert werden können, halten Befürworter agiler Prozesse das klassische Projektmanagement für überholt und plädieren für eine strikte Funktionstrennung von Scrum hin zu klassischen Managementpraktiken. Durch den iterativen Scrum-Prozess können Anforderungen, die noch nicht bekannt sind oder sich während des Entwicklungsprozesses ändern, in das Gesamtsystem integriert werden. 2. Scrum7Scrum sollte nicht als Ansammlung strenger Prozesse verstanden werden, sondern sollte lediglich ein leichtgewichtiges Framework sein, das Methoden nutzt, um Hindernisse in der Organisation aufzudecken. Da Scrum keine festen Vorgaben oder Prozesse an verwandtes Personal freigibt, sind eine gute Zusammenarbeit und der gesunde Menschenverstand innerhalb des Scrum-Teams besonders wichtig (siehe [3, S. 299]). Gute Kommunikation, Engagement und Transparenz gegenüber dem Projekt förderten die enge Zusammenarbeit der Teammitglieder. Bei einem Großraumbüro können Raumteiler oder Trennwände eine Änderung der Arbeitsplatzgestaltung erforderlich machen (siehe [8, Seite 103]). 2.2 Rollen in Scrum, es sind nur die drei Rollen des Product Owners, des Scrum Masters und des Entwicklungsteams definiert, wie nachfolgend beschrieben 2.2.1 Der Product Owner Der Product Owner ist dafür verantwortlich, dass die Anforderungen und Wünsche der Stakeholder im Unternehmen umgesetzt werden das Produkt. Da die Rolle der Stakeholder in Scrum nicht definiert ist, fungiert der Product Owner als Schnittstelle zu den oben genannten Interessengruppen. Der Product Owner muss nicht zwingend der Repräsentant des Kunden sein, sondern kann auch der Kunde selbst sein. Der Product Owner ermittelt die Bedürfnisse des Kunden und pflegt diese in der Product To-Do-Liste. Um die Realisierung der Funktion sicherzustellen, die für den Kunden den höchsten Geschäftswert darstellt, priorisiert der Product Owner die Bedürfnisse im Product Backlog. Um Missverständnisse in der Reihenfolge der Umsetzung im Vorfeld zu vermeiden, muss jede Priorität eindeutig zugeordnet werden. Die Priorität der Anforderungen erfolgt nicht einmalig, sondern vor jeder Iteration, da sich die Bedeutung der Funktion während des Entwicklungsprozesses ändern kann Eine weitere Aufgabe des Product Owners besteht darin, die Elemente der Produkt-To-Do-Liste anzuzeigen. Der Product Owner zeigte dies dem Entwicklungsteam und erläuterte detailliert die Vorteile, die Kunden durch die Implementierung dieses Features erhalten sollten. Da der Product Owner nicht nur mit dem Kunden, sondern auch mit dem Entwicklungsteam zusammenarbeitet, sind technisches Wissen und ein grundlegendes Verständnis des Kundenfeldes unabdingbar. Die Anforderungen werden in der branchenspezifischen Sprache des Kunden formuliert, sodass der Product Owner dem Entwicklungsteam die Elemente des Product Backlogs erläutern muss. Zum Verantwortungsbereich des Product Owners gehört auch, einen Teil der vom Entwicklungsteam erzielten Ergebnisse im iterativen Prozess zu übernehmen. Grundsätzlich wird die Rolle des Product Owners von einer Person wahrgenommen, bei größeren Projekten können jedoch auch mehrere Personen benötigt werden. Dagegen ist es verboten, die Rollen des Product Owners und des Scrum Supervisors zu verschmelzen, da dieser sonst die Rolle des „klassischen“ Projektleiters übernimmt (siehe [6, S. 233]). Read Less