Sie sind hier
E-Book

Agiles IT-Projektmanagement mit Scrum

AutorJonas Tewolde
VerlagGRIN Verlag
Erscheinungsjahr2011
Seitenanzahl73 Seiten
ISBN9783656086185
FormatPDF/ePUB
Kopierschutzkein Kopierschutz/DRM
GerätePC/MAC/eReader/Tablet
Preis29,99 EUR
Bachelorarbeit aus dem Jahr 2011 im Fachbereich Informatik - Wirtschaftsinformatik, Note: 1,7, Universität Duisburg-Essen, Sprache: Deutsch, Abstract: Projekte gibt es schon seit Jahrtausenden. Bereits vor 4500 Jahren erbauten die Ägypter Pyramiden, Projekte von beachtlicher Größe und enormem Aufwand (Litke 2007, S. 7). Auch heute gibt es Projekte mit enormen Ausmaßen wie z. B. das 2005 in Deutschland eingeführte LKW-Mautsystem. Es gibt aber auch zahlreiche kleinere Projekte, deren Ergebnisse sich z. B. als Software in Motorsteuergeräten moderner Autos, DVD-Player, Handys, Digitalkameras, Kassensysteme im Supermarkt, gmx.de, google.com, facebook.com und vielen weiteren Produkten wiederfinden, die für unser alltägliches Leben von Bedeutung sind. Für die erfolgreiche und effiziente Abwicklung solcher und anderer Projekte bedarf es einer klaren und systematischen Vorgehensweise (Bea et al. 2008, S. 30). In der Literatur und in der Praxis finden sich hierfür eine Reihe von Methodiken und Vorgehensweisen. Eine davon ist Scrum, das als De-Facto-Standard für agiles Projektmanagement gilt (Gloger 2010, S. 195). Aber was genau ist Scrum, wie funktioniert es, worin unterscheidet es sich von anderen Methodiken und macht der Einsatz überhaupt Sinn? Zur Beantwortung dieser Fragen sind eine umfassende Vorstellung und eine Bewertung von Scrum notwendig. Hilfreich ist auch ein Blick über den Tellerrand der wissenschaftlichen Theorie hinaus in die Praxis, was diese Arbeit leisten wird.

Kaufen Sie hier:

Horizontale Tabs

Leseprobe

3. Scrum


 

3.1 Grundlagen und Geschichte


 

Dieses Kapitel führt in die laut Hammerstein (Hammerstein 2009, S. 29) am weitesten verbreitete agile Methodik Scrum ein und beantwortet die Frage nach dessen Herkunft.

 

Der Begriff Scrum ist weder eine Abkürzung, noch ist es ein Akronym, sondern stammt aus dem Sport Rugby und betitelt eine Standardsituation zur Wiederaufnahme des Spiels, in der sich eine bestimmte Anzahl an Mitspielern beider Mannschaften in einer Art Gedränge dicht gegenübersteht, um durch wegschieben der jeweils anderen Mannschaft in den Ballbesitz zu kommen. In dieser Situation kann sich eine Mannschaft nur dann den Ballbesitz erkämpfen, wenn sie erfolgreich zusammenarbeitet. (Mitchell et al. 2006, S. 190; Schwaber und Beedle 2002, S. 121–122)

 

Auch wenn zunächst Extreme Programming ein gewisse Verbreitung fand, sieht Seibert (2007, S. 41–42) Scrum als repräsentatives Beispiel für agile Methodiken. Gloger (2010, S. 195) geht noch einen Schritt weiter und bezeichnet Scrum als De-Facto-Standard der agilen Softwareentwicklung. Den Grund dafür sehen beide darin, dass, während Extreme Programming klare Vorgaben zur Entwicklung macht, Scrum eher auf das Management ausgerichtet ist. Bestätigt wird dies auch durch das Ergebnis einer Studie (Wolf und Roock 2008, S. 10), wonach zwar Extreme Programming unter den Befragten mit 93 Prozent eine höhere Bekanntheit genießt als Scrum mit 74 Prozent, was aber den erfolgreichen Einsatz betrifft mit 14 Prozent deutlich hinter Scrum liegt, das mit 21 Prozent die am häufigsten erfolgreich eingesetzte agile Methodik unter den Befragten ist.

 

Das erste Mal wurde Scrum 1993 unter Anleitung von Ken Schwaber eingesetzt, nachdem dieser den CEO der Easel Corporation von den Vorteilen dieser Methodik überzeugte. Das Resultat war nicht nur ein Produkt mit allen zum Schluss gewollten (und nicht ursprünglich gedachten) Funktionalitäten, sondern auch, dass ein von diesem CEO verantworteten Projekt termingerecht zum erfolgreichen Abschluss gebracht werden konnte. (Sutherland 2004, S. 1–3)

 

 

Bild 4 Grafische Darstellung der Scrum Prozesse

 

Quelle: In Anlehnung an Cohn (2010b, S. 167)

 

In Scrum werden die Anforderungen und Eigenschaften, die für das zu entwickelnde Produkt realisiert werden sollen, vom Product Owner im Product Backlog ( 3.3.1) gesammelt und verwaltet. Die wichtigsten daraus legt er im Sprint Planning Meeting ( 3.5.2) vor, von denen das Team diejenigen auswählt, die es in der nächsten Iteration realisieren kann. Aus diesen leitet sich das Team Aufgaben ab und hält sie im Sprint Backlog ( 3.3.2) fest. Während der Iteration, die in Scrum als Sprint ( 3.4) bezeichnet wird, arbeitet das Team den Sprint Backlog eigenverantwortlich ab und validiert dabei im 24-Stunden- Rhythmus seinen Fortschritt im Daily Scrum ( 3.5.3). Das Ziel jeder Iteration ist es, ein potentiell auslieferbares Produkt fertig zu stellen. Bild 4 veranschaulicht grob diese Vorgänge.

 

Durch das Sprint Planning Meeting, dem Daily Scrum sowie dem Sprint Review ( 3.5.5) und der Retrospektive ( 3.5.6) findet in Scrum eine empirische Prozesssteuerung statt, mit welcher die Produktivität und die Entwicklungsrichtung in Bezug auf das Ziel ständig überwacht und angepasst sowie die gemeinsame Arbeit reflektiert und entsprechend verbessert werden. (Hammerstein 2009, S. 30; Schwaber und Sutherland 2010, S. 4)

 

Scrum gibt, wie bei agilen Methodiken üblich, nicht viele Regeln vor. (Coldeway 2003, S. 52) Um aber die Einhaltung der vorhandenen Regeln und das Funktionieren von Scrum sicherzustellen, gibt es den Scrum Master ( 3.2.2), der neben dem Product Owner und dem Team die dritte Rolle in Scrum darstellt.

 

3.2 Rollen


 

In Scrum gibt es die drei Rollen Scrum Master, Product Owner und Team, die in den nächsten Abschnitten beschrieben und in ihrer Gesamtheit als Scrum-Team bezeichnet werden.

 

3.2.1 Scrum Master


 

Die erste hier vorgestellte Rolle ist der Scrum Master, deren Zweck es ist, das Funktionieren von Scrum sicherzustellen. Welche Aufgaben und Verantwortlichkeiten damit verbunden sind, folgt in diesem Abschnitt.

 

Zunächst sei angemerkt, dass es sich beim Scrum Master nicht um einen Projektleiter oder Teamleiter handelt. Sollte er eine solche Rolle einnehmen, wäre das keine korrekte Umsetzung von Scrum, da z. B. dem Product Owner ( 3.2.2) die Möglichkeit genommen würde, das Team direkt zu steuern. Um ein nachhaltiges Funktionieren von Scrum sicherzustellen, müssen die Inhaber der Rollen diese richtig verstanden haben und sie entsprechend leben. (Pichler 2009, S. 24)

 

Einen wesentlichen Punkt, der einen Scrum Master von einem Projektleiter oder Teamleiter unterscheidet, sehen Wieczorrek und Mertens (2010, S. 127) darin, dass sich der Scrum Master zurücknehmen muss und auf keinen Fall in die Arbeit des Teams eingreifen darf. Tim Lister (2007) veranschaulicht dies mit einem Bild von marschierenden Küken. Der Scrum Master, oder von Lister allgemeiner als agile leader bezeichnet, entspricht in diesem Bild nicht dem vordersten Küken, das den Weg vorgibt. Dieses bezeichnet er lediglich als Scout, während er das hinterste Küken, welches stets das Ziel und die Gruppe im Auge hat, als tatsächlichen Leader betrachtet. Von dieser Position aus, so Eickmann (2009a, S. 122–123), ist es dem Scrum Master möglich, sicherzustellen, dass sich das Team an die Scrum Regeln hält und keine Gefahren die Arbeit des Teams bedrohen.

 

Damit das Team sich an die Regeln hält und mit seiner Arbeit möglichst effizient das Ziel verfolgt, agiert er ähnlich wie ein Coach von Sportteams. Er bereitet das Team vor, erklärt die Regeln und beantwortet aufkommende Fragen. Während das Team dann auf dem Feld eigenverantwortlich agiert, steht er selbst nur am Spielfeldrand, ohne aktiv am Spiel teilzunehmen und beobachtet stattdessen die Spielweise (Arbeitsweise) des Teams, deckt Schwachstellen oder Potentiale auf und gibt dem Team Hinweise, wie es sich verbessern kann.

 

Daneben wacht er über mögliche Gefahren, die auf sehr unterschiedliche Weise in Erscheinung treten können. Beispielsweise können dem Team notwendige Ressourcen fehlen, weil z. B. Testhardware fehlt oder die IT-Abteilung keinen Bugtracker bereit stellt. Dem Team oder einzelnen Teammitgliedern können zusätzliche Aufgaben zugeteilt werden oder Teammitglieder werden ganz abgezogen. Es können durch die Organisation bedingte Probleme auftreten, wie z. B. ungeeignete Arbeitsräume, Besprechungsräume oder fehlende Medien. Ein falsches Rollenverständnis, Interessenskonflikte und Differenzen zwischen den Beteiligten stellen ebenso Gefahren dar wie private und fachliche Probleme der einzelnen Teammitglieder. Nicht alle dieser oder anderer auftretenden Probleme oder Hindernisse können vom Scrum Master selbst beseitigt werden. In solchen Fällen ist er trotzdem für deren Beseitigung verantwortlich, was Eickmann zufolge oft mit einem hohen Aufwand an Zeit und einem guten Durchsetzungsvermögen verbunden ist.

 

Auch wenn der Scrum Master keine Weisungsbefugnisse hat, identifizieren Wirdemann sowie Schwaber und Beedle als weitere Aufgabe des Scrum Master das schnelle Treffen von Entscheidungen, sollte es erforderlich werden. Dies ist dann der Fall, wenn das Team die Entscheidung nicht treffen kann und das Fehlen der Entscheidung die Arbeit des Teams behindert und damit zur Gefahr wird. Der Scrum Master trifft diese Entscheidung möglichst schnell und auch dann, wenn ihm nicht ausreichend Informationen dafür vorliegen, da es besser ist, mit schlechten Entscheidungen weiter zu arbeiten als ohne Entscheidung zu stagnieren. (Schwaber und Beedle 2002, S. 32; Wirdemann 2009, S. 40)

 

Als organisatorisches Hilfsmittel zur Beseitigung von Gefahren für die Arbeit des Teams, die auch als Impediments bezeichnet werden, kann der Scrum Master eine Liste, auch Impediment Backlog genannt, führen, in die er erkannte Gefahren notiert, um sie dann abzuarbeiten. Auf diese Weise wird Transparenz bezüglich vorhandener Probleme und der Bemühung des Scrum Master, diese zu beseitigen, geschaffen. Zusätzlich kann die Entwicklung dieser Liste auch als Indikator für den Erfolg des Scrum Master dienen. Ein ständiges Verschwinden von Einträgen bedingt durch das erfolgreiche Beseitigen von Problemen schafft Vertrauen beim Team, da für dieses die Unterstützung durch den Scrum Master sichtbar wird. Kommen aber immer neue Einträge hinzu, ohne dass bereits bestehende beseitigt werden, indiziert dies entweder eine mangelhafte Unterstützung des Projekts durch die Organisation oder eine schlechte Arbeit des Scrum Master. Langfristig kann dies zu einem Vertrauensverlust des Teams in den Scrum Master führen und den Erfolg Projekts gefährden. (Wirdemann 2009, S. 39–40)

 

Die Sicherstellung, dass die direkte Kommunikation und Zusammenarbeit zwischen dem Team und dem Product Owner funktioniert, ist eine weitere Aufgabe des Scrum Master. Sollte beispielsweise der Product...

Blick ins Buch

Weitere E-Books zum Thema: Informatik - Algorithmen - Softwaresysteme

Softwaretechnik

E-Book Softwaretechnik
Format: PDF

Software-Projekte geraten oft in Schwierigkeiten: Zeit und Budget werden überschritten; das Projekt tritt auf der Stelle; im schlimmsten Fall wird es ohne Ergebnis abgebrochen. Manche…

Softwaretechnik

E-Book Softwaretechnik
Format: PDF

Software-Projekte geraten oft in Schwierigkeiten: Zeit und Budget werden überschritten; das Projekt tritt auf der Stelle; im schlimmsten Fall wird es ohne Ergebnis abgebrochen. Manche…

Softwaretechnik

E-Book Softwaretechnik
Format: PDF

Software-Projekte geraten oft in Schwierigkeiten: Zeit und Budget werden überschritten; das Projekt tritt auf der Stelle; im schlimmsten Fall wird es ohne Ergebnis abgebrochen. Manche…

Software Engineering

E-Book Software Engineering
Architektur-Design und Prozessorientierung Format: PDF

Das Lehrbuch behandelt alle Aspekte der Software-Entwicklung, besonders aber Methoden und Richtlinien zur Herstellung großer und qualitativ hochwertiger Softwareprodukte. Es vermittelt das zur…

Software Engineering

E-Book Software Engineering
Architektur-Design und Prozessorientierung Format: PDF

Das Lehrbuch behandelt alle Aspekte der Software-Entwicklung, besonders aber Methoden und Richtlinien zur Herstellung großer und qualitativ hochwertiger Softwareprodukte. Es vermittelt das zur…

Weitere Zeitschriften

Menschen. Inklusiv leben

Menschen. Inklusiv leben

MENSCHEN. das magazin informiert über Themen, die das Zusammenleben von Menschen in der Gesellschaft bestimmen -und dies konsequent aus Perspektive der Betroffenen. Die Menschen, um die es geht, ...

Burgen und Schlösser

Burgen und Schlösser

aktuelle Berichte zum Thema Burgen, Schlösser, Wehrbauten, Forschungsergebnisse zur Bau- und Kunstgeschichte, Denkmalpflege und Denkmalschutz Seit ihrer Gründung 1899 gibt die Deutsche ...

Computerwoche

Computerwoche

Die COMPUTERWOCHE berichtet schnell und detailliert über alle Belange der Informations- und Kommunikationstechnik in Unternehmen – über Trends, neue Technologien, Produkte und Märkte. IT-Manager ...

Das Grundeigentum

Das Grundeigentum

Das Grundeigentum - Zeitschrift für die gesamte Grundstücks-, Haus- und Wohnungswirtschaft. Für jeden, der sich gründlich und aktuell informieren will. Zu allen Fragen rund um die Immobilie. Mit ...

e-commerce magazin

e-commerce magazin

e-commerce magazin Die Redaktion des e-commerce magazin versteht sich als Mittler zwischen Anbietern und Markt und berichtet unabhängig, kompetent und kritisch über ...

building & automation

building & automation

Das Fachmagazin building & automation bietet dem Elektrohandwerker und Elektroplaner eine umfassende Übersicht über alle Produktneuheiten aus der Gebäudeautomation, der Installationstechnik, dem ...

Evangelische Theologie

Evangelische Theologie

Über »Evangelische Theologie« In interdisziplinären Themenheften gibt die Evangelische Theologie entscheidende Impulse, die komplexe Einheit der Theologie wahrzunehmen. Neben den Themenheften ...