Agiles Projektmanagement mit Projektron BCS › resources › projects › studies ›...

Agiles Projektmanagement mitProjektron BCS

Anwendung von Scrum in Projekten der Hypoport AG

Diplomarbeit

im Fachbereich Informatik und Medien

vorgelegt von: Robert Kalweit

Matrikelnummer: 726684

Studiengang: Medieninformatik

Praxispartner: Projektron GmbH

Betreuer: Prof. Dr. Roland Petrasch

Gutachter: Prof. Dr.-Ing. Dieter Pumpe

© Copyright 2008

Version vom 5. August 2008

Agiles Projektmanagement mit Projektron BCSAnwendung von Scrum in Projekten der Hypoport AG

Vorgelegt im Sommersemester 2008

Autor: Robert KalweitMatrikelnummer: 726684

Adresse: Mollstr. 33, 10405 BerlinTelefon: 030/80939749E-Mail: [email protected]

Hochschule: Technische Fachhochschule BerlinStudiengang: Medieninformatik DiplomSchwerpunkt: Medien

Betreuender Hochschullehrer: Prof. Dr. Roland PetraschZweitgutachter: Prof. Dr.-Ing. Dieter Pumpe

Satz: LATEX2εLektorat:Stefan LützkendorfOliver HeinzeClaudia DeckertKay SchönemannJens Volckmann

Dieses Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Verwer-

tung außerhalb der engen Grenzen des Urheberrechtgesetzes ist ohne Zustimmung des

Autors unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Überset-

zungen, Mikroverfilmungen sowie die Einspeicherung und Verarbeitung in elektronischen

Systemen.

Es wird darauf hingewiesen, dass die in diesem Werk verwendeten Soft- und Hardware-

Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen

im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

mailto:[email protected]


Zusammenfassung

Die vorliegende Arbeit verdeutlicht die zunehmende Bedeutung agiler Prozessezur Softwareentwicklung und zum Projektmanagement (PM). Motiviert durchdiesen Trend wird untersucht, inwiefern die Anwendung agiler Vorgehensweisenmit Projektron BCS, einer PM-Software, möglich ist. Ein Überblick über PMim Allgemeinen, agiles Projektmanagement und Scrum im Speziellen schafft dieGrundlage für weitere Betrachtungen. Projektron BCS wird vorgestellt und seineAnwendung in einem agilen Umfeld analysiert. Aus den daraus resultierendenAnforderungen wird ein Konzept erarbeitet, das darauf abzielt, agile Vorgehens-weisen in Projektron BCS stärker aktiv zu unterstützen.

Schlagworte

Agilität, Prozesse, Softwareentwicklung, Projektmanagement, Projektron BCS,Scrum, Anforderungen

Abstract

The thesis at hand clarifies the increasing importance of agile software develop-ment and project management (PM) processes. Motivated by this tendency itis being examined how far it is possible to apply these agile processes with thePM-software Projektron BCS. An overview of project management in general,agile PM and Scrum in particular establishes the basis for further research. Af-ter Projektron BCS is being introduced, its application to an agile environmentis analyzed. Based upon the resulting requirements a concept is developed. Theaim of this concept is strengthening the support of Projektron BCS for agileprocesses.

Keywords

agile, processes, software development, project management, Projektron BCS,Scrum, requirements

Diplomarbeit – Robert Kalweit


Vorwort

Die vorliegende Diplomarbeit entstand während meiner Tätigkeit bei der Pro-jektron GmbH als Student der Medieninformatik im Fachbereich Informatik undMedien der Technischen Fachhochschule Berlin.

Mein ganz besonderer Dank gilt meinem Betreuer Herrn Prof. Dr. Roland Pe-trasch für seine engagierte Vermittlung mit der Projektron GmbH und seine stetskonstruktive Kritik.

Darüber hinaus danke ich besonders den Geschäftsführern der Projektron GmbHHerrn Maik Dorl und Herrn Dr. Marten Huisinga, die viel Vertrauen in michsetzten und sich überaus kurzfristig bereit erklärten, dieses Thema bei Projektronumsetzen zu lassen.

Weiterhin danke ich ich allen Kollegen bei Projektron, die mich freundlich auf-genommen und stets unterstützt haben. Dabei hebe ich besonders Herrn StefanLützkendorf, Entwicklungsleiter der Projektron GmbH, und Herrn Oliver Heinze,der bei Projektron als Berater tätig ist, hervor.

Schließlich gilt mein besonderer Dank Frau Claudia Deckert, inzwischen als Scrum-Master zertifiziert, die meine Begeisterung für Projektmanagement und besondersfür Scrum geweckt und gefördert hat. Nicht zuletzt aufgrund dieser Begeisterunghabe ich ein Thema mit Bezug zu Projektmanagement gewählt.

Im Bereich der Informatik und damit auch in der vorliegenden Arbeit werdenviele englische Begriffe verwendet. Wörtliche Übersetzungen ins Deutsche sindnicht immer passend. Daher wurde darauf geachtet, für englische Begriffe tref-fende oder allgemein anerkannte Übersetzungen zu verwenden und eingangs zuverdeutlichen. In der Folge werden der englische und deutsche Begriff synonymverwendet.



Inhaltsverzeichnis

Inhaltsverzeichnis VII

Abkürzungsverzeichnis IX

Abbildungsverzeichnis XI

Tabellenverzeichnis XIII

Verzeichnis der Listings XV

1 Einleitung 1

2 Projektmanagement Grundlagen 52.1 Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Agiles Projektmanagement . . . . . . . . . . . . . . . . . . . . . . 92.3 Projektmanagementsysteme . . . . . . . . . . . . . . . . . . . . . 10

3 Scrum 133.1 Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Artefakte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Projektron BCS 374.1 Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3 Flexibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5 Scrum bei der Hypoport AG 475.1 Prozess und Software-Anforderungen . . . . . . . . . . . . . . . . 485.2 Vergleich der Anforderungen mit Projektron BCS . . . . . . . . . 545.3 Vorgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Diplomarbeit – Robert Kalweit VII


6 Anpassungen 696.1 Vorbetrachtungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.2 Umsetzung und Konfigurierbarkeit . . . . . . . . . . . . . . . . . 706.3 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7 Fazit und kritische Bewertung 83

Anhang i

A Technische Details iiiA.1 Datenstruktur von Projektron BCS . . . . . . . . . . . . . . . . . iiiA.2 Konfiguration eines Ticket-Lebenszyklus . . . . . . . . . . . . . . vii

B Interviews mit Mitarbeitern der Hypoport AG ixB.1 Zusammenfassung des Gesprächs mit Herrn Heide . . . . . . . . . ixB.2 Zusammenfassung des Gesprächs mit Herrn Gimbel . . . . . . . . xii

C Diagramme xv

D Konzeptgraphiken xix

E Beilage CD-ROM und Online-Testsystem xxvii

Literaturverzeichnis XVII

Eidesstattliche Erklärung XXIII

VIII Diplomarbeit – Robert Kalweit


Abkürzungsverzeichnis

API . . . . . . . . . . . . . . . Application Programming Interface

APM . . . . . . . . . . . . . . Agiles Projektmanagement

BCS . . . . . . . . . . . . . . Business Coordination Software

CSS . . . . . . . . . . . . . . . Cascading Style Sheets

CSV . . . . . . . . . . . . . . Comma-Separated Values

DoD . . . . . . . . . . . . . . Definition of Done

DOM . . . . . . . . . . . . . Document Object Model

EPF . . . . . . . . . . . . . . Eclipse Process Framework

FDD . . . . . . . . . . . . . . Feature Driven Development

GUI . . . . . . . . . . . . . . . Graphical User Interface

HTML . . . . . . . . . . . . Hypertext Markup Language

I18n . . . . . . . . . . . . . . . Internationalization

INVEST . . . . . . . . . . independent, negotiable, valuable, estimable, small, testable

IT . . . . . . . . . . . . . . . . . Informationstechnik / information technology

J2SE . . . . . . . . . . . . . . Java 2 Platform, Standard Edition

JDBC . . . . . . . . . . . . . Java Database Connectivity

JSP . . . . . . . . . . . . . . . JavaServer Pages

OID . . . . . . . . . . . . . . . Objekt-ID / Objekt-Identifikation

PDCA . . . . . . . . . . . . Plan-Do-Check-Act

PM . . . . . . . . . . . . . . . Projektmanagement / project management

PMI . . . . . . . . . . . . . . . Project Management Institue

PMS . . . . . . . . . . . . . . Projektmanagementsystem

WebDAV . . . . . . . . . . Web-based Distributed Authoring and Versioning

XML . . . . . . . . . . . . . . Extensible Markup Language

XP . . . . . . . . . . . . . . . . Extreme Programming

Diplomarbeit – Robert Kalweit IX


X Diplomarbeit – Robert Kalweit


Abbildungsverzeichnis

1.1 Verbreitung agiler Softwareentwicklung . . . . . . . . . . . . . . . 21.2 Anzahl eingesetzter PM-Tools . . . . . . . . . . . . . . . . . . . . 31.3 Systemanalyse im Unternehmen . . . . . . . . . . . . . . . . . . . 3

2.1 Magisches Dreieck des Projektmanagements . . . . . . . . . . . . 72.2 PDCA-Zyklus in Verbindung mit PM-Prozessgruppen . . . . . . . 72.3 Geschichte von Vorgehensmodellen . . . . . . . . . . . . . . . . . 112.4 Anwendung agiler Vorgehensweisen . . . . . . . . . . . . . . . . . 12

3.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 Aktivitätsdiagramm des Scrum Prozesses . . . . . . . . . . . . . . 243.3 Aktivitätsdiagramm des Sprint Planning Meetings . . . . . . . . . 263.4 Aktivitätsdiagramm des Daily Scrum Meetings . . . . . . . . . . . 283.5 Aktivitätsdiagramm des Sprint Review Meetings . . . . . . . . . . 303.6 Aktivitätsdiagramm des Sprint Retrospective Meetings . . . . . . 323.7 Release Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . 35

4.1 Arbeitsbereiche in Projektron BCS . . . . . . . . . . . . . . . . . 384.2 Projektron BCS Projektassistent . . . . . . . . . . . . . . . . . . 384.3 Aufbau einer Projektron BCS Installation . . . . . . . . . . . . . 424.4 Webseitenstruktur von Projektron BCS . . . . . . . . . . . . . . . 434.5 WebConfig-Editor zum Bearbeiten der GUI . . . . . . . . . . . . 454.6 Zusätzliche Attribute eines Projekts . . . . . . . . . . . . . . . . . 45

5.1 Acht Elemente der Europace Plattform . . . . . . . . . . . . . . . 485.2 Anforderungserhebung eines Projekts der Hypoport AG . . . . . . 505.3 Projektron BCS Strukturplan eines Hypoport-Projekts . . . . . . 505.4 Lebenszyklen von user stories und Akzeptanztests . . . . . . . . . 525.5 Definition der Grundlast und Ressourcenauslastung . . . . . . . . 555.6 Einer Organisation zugeordnete Projekte . . . . . . . . . . . . . . 56

Diplomarbeit – Robert Kalweit XI


5.7 Product Backlog in Projektron BCS . . . . . . . . . . . . . . . . . 575.8 Schematische Datenstruktur von Aufgaben und Anmerkungen . . 575.9 Auszug aus der Datenstrukturinfo einer Aufgabe und Statusanzeige 585.10 Änderungshistorie im Projektron BCS Ticketsystem . . . . . . . . 60

6.1 Hierarchische Anordnung von Tickets im Strukturplan . . . . . . 716.2 Umwandlung von Tickets . . . . . . . . . . . . . . . . . . . . . . . 736.3 Lebenszyklus eines Bugs . . . . . . . . . . . . . . . . . . . . . . . 746.4 Verbindliche und nicht verbindliche Lebenszyklen . . . . . . . . . 766.5 Erfolgsmeldung und Warnung nach Umwandlung . . . . . . . . . 766.6 Burndown Chart in Projektron BCS . . . . . . . . . . . . . . . . 786.7 Integration der Anzeige von Tickets im Strukturplan . . . . . . . 796.8 Integration der untergeordneten Tickets und Arbeitsabläufe . . . . 796.9 Kompatibilität zur gegenwärtigen Teamplanung . . . . . . . . . . 806.10 Aufwandsplanung auf Sprintebene . . . . . . . . . . . . . . . . . . 81

B.1 JIRA Tickettypen und -status . . . . . . . . . . . . . . . . . . . . xiv

C.1 Aktivitätsdiagramm des Scrum Prozesses . . . . . . . . . . . . . . xviC.2 Detailliertes Aktivitätsdiagramm des Scrum Prozesses . . . . . . . xviiC.3 Aktivitätsdiagramm des Scrum Prozesses der Hypoport AG . . . xviii

D.1 Strukturplan eines Scrum Projekts im Anzeigenmodus . . . . . . xxD.2 Strukturplan eines Scrum Projekts im Bearbeitungsmodus . . . . xxiD.3 Mittels Lebenszyklus eingeschränkte Arbeitsabläufe eines Bugs . . xxiiD.4 Uneingeschränkte Arbeitsabläufe eines ChangeRequests . . . . . . xxiiiD.5 Ticketansicht mit Aufwänden, Arbeitsabläufen und Beziehungen . xxivD.6 Integration des Burndown Charts . . . . . . . . . . . . . . . . . . xxv

XII Diplomarbeit – Robert Kalweit


Tabellenverzeichnis

3.1 Tabellarisches Product Backlog . . . . . . . . . . . . . . . . . . . 19

4.1 Projektron BCS Konfigurationsdateien . . . . . . . . . . . . . . . 44

5.1 JIRA Tickethierarchie der Hypoport AG . . . . . . . . . . . . . . 515.2 Anforderungen an die Softwareunterstützung . . . . . . . . . . . . 545.3 Erfüllung der Anforderungen durch die Software . . . . . . . . . . 61

6.1 Attribute eines ChangeState-Elements . . . . . . . . . . . . . . . 75

A.1 Subtypen des Objekts Organisation . . . . . . . . . . . . . . . . . iiiA.2 Subtypen des Objekts Person . . . . . . . . . . . . . . . . . . . . ivA.3 Subtypen des Objekts Projekt . . . . . . . . . . . . . . . . . . . . vA.4 Subtypen des Objekts Aufgabe . . . . . . . . . . . . . . . . . . . vA.5 Subtypen des Objekts Anmerkung . . . . . . . . . . . . . . . . . . viA.6 Subtypen des Objekts Aufwand . . . . . . . . . . . . . . . . . . . vi

Diplomarbeit – Robert Kalweit XIII


XIV Diplomarbeit – Robert Kalweit


Verzeichnis der Listings

4.1 Beispieleintrag in einer ServerConfig*.properties-Datei . . . . 44

6.1 Minimalkonfiguration von Ticketarten . . . . . . . . . . . . . . . . 716.2 Einschränkung möglicher Kindelemente . . . . . . . . . . . . . . . 726.3 Definition des Lebenszyklus eines Bugs . . . . . . . . . . . . . . . 746.4 Berücksichtigung von Status im Burndown Chart . . . . . . . . . 77

A.1 Konfiguration des Lebenszyklus der Projektron Support Tickets . vii

Diplomarbeit – Robert Kalweit XV


XVI Diplomarbeit – Robert Kalweit


1 Einleitung

Management is nothing more than

motivating other people.

(Lee Iacocca)

Ein nicht unerheblicher Teil des Entwicklungsprozesses eines Softwareprojekts istseine Planung. Die Qualität dieser Planung ist essentiell für den Erfolg des Pro-jekts - so ist „schlechte Planung und Schätzung“ einer der häufigsten Gründe desScheiterns von Projekten. Zu den gravierendsten Risikofaktoren zählen weiterhinunvollständige und wechselnde Anforderungen, sowie mangelnde Einbeziehungder Anwender. Wird Projekterfolg an einer termin- und budgetgerechten Um-setzung gemessen, waren 1994 nur etwa 16% aller IT-Projekte erfolgreich. Wenn-gleich dieser Anteil bis 2004 auf 29% gestiegen ist, bedeutet dies doch, dass immernoch mehr als zwei Drittel aller Projekte nicht erfolgreich sind. (Vgl. [Standish1994], [Gaulke 2004, S.42ff.])

Um Projekte erfolgreicher, also schneller, kosteneffizienter und qualitativ hoch-wertiger abzuschließen und zusätzlich den Menschen wieder in den Mittelpunktder Softwareentwicklung zu rücken und für hohe Arbeitsmoral und gutes Be-triebsklima zu sorgen, tendieren viele Unternehmen zum Einsatz agilen Projekt-managements. Laut der „Business Technographics© September 2006 North Ame-rican And European Enterprise Software Survey“ verwendeten bereits 17% dernordamerikanischen und europäischen Unternehmen agile Entwicklungsprozesse.Hält der in Abbildung 1.1 dargestellte Trend an, wird dieser Anteil 2008 auffast ein Viertel steigen. (Vgl. [Schwaber 2007b], [Wolf und Roock 2008])

Die „Agile Project Management Tooling Survey“ belegt, dass Unternehmen allerGrößenordnungen zunehmend die Möglichkeiten agiler Projektsteuerung wahr-nehmen. In jeweils über 30% aller Unternehmen arbeiten entweder mehr als drei

Diplomarbeit – Robert Kalweit 1


1 Einleitung

Abbildung 1.1: Verbreitung agiler Softwareentwicklung, Quelle: [Schwaber 2007b]

Viertel oder nur bis zu einem Viertel aller Softwareentwickler nach agilen Vorge-hensweisen. Agilität polarisiert also: Sie wird entweder umfassend, fast unterneh-mensweit oder nur sehr vereinzelt eingesetzt. Unternehmen mit weniger als 100Mitarbeitern im Bereich Softwareentwicklung stellen dabei bezüglich des weitrei-chenden Einsatzes den größten Anteil. (Vgl. [Behrens 2006])

Vierundvierzig Prozent aller Unternehmen werten über 90% ihrer agil durchge-führten Projekte als Erfolg. Weitere dreiunddreißig Prozent bescheinigen ihrenProjekten eine Erfolgsquote von 75-90%. Agile Projekte sind also überaus erfolg-reich. (Vgl. [Ambler 2007])

Mehr als die Hälfte der Unternehmen, deren Entwicklungsprozess agil ist, verwen-det drei bis vier Softwaretools für das Management seiner Projekte (vgl. Abbil-dung 1.2). Weit verbreitet sind dabei z. B. VersionOne oder ScrumWorks, die sichausschließlich agilen Entwicklungs- und Planungsprozessen verschrieben haben.Ein vor allem im deutschsprachigen Raum verbreitetes Tool ist Projektron BCS.Die „Business Coordination Software“ der Projektron GmbH bedient viele Berei-che eines Unternehmens und beschränkt sich nicht allein auf Projektmanagement(PM). Der Fokus dieser Arbeit liegt jedoch auf der Verbesserung genau diesesBereichs. Motiviert durch die Diskrepanz zwischen der zunehmenden Verbrei-tung agilen Projektmanagements und den Berichten über häufiges Scheitern vonIT-Projekten wird untersucht, inwiefern die Anwendung agiler Vorgehensweisenmit Projektron BCS möglich ist. (Vgl. [Projektron], [Behrens 2006])

2 Diplomarbeit – Robert Kalweit


Abbildung 1.2: Anzahl eingesetzter PM-Tools, Quelle: [Behrens 2006]

Daher analysiert die vorliegende Arbeit den agilen Entwicklungsprozess und denEinsatz von Projektron BCS bei der Hypoport AG, einem Kunden der ProjektronGmbH. Gründe für den Einsatz weiterer Softwaretools werden untersucht.

Ziel der Arbeit ist, aufzuzeigen, ob und wo Verbesserungsbedarf besteht, umagile Vorgehensweisen in Projektron BCS stärker aktiv zu unterstützen. Daraufaufbauend wird ein Konzept entwickelt, das den alleinigen Einsatz von ProjektronBCS in agilen Projektmanagementumgebungen forcieren soll.

Der Aufbau der Arbeit orientiert sich am Vorgehensmodell der Systemanalyseim Unternehmen. Abbildung 1.3 veranschaulicht dies. (Vgl. [Krallmann u. a.2002])

Abbildung 1.3: Vorgehensmodell der Systemanalyse im Unternehmen und An-wendung des Modells, Quelle: [Krallmann u. a. 2002]



1 Einleitung

Kapitel 1 beinhaltet die Projektbegründung. Das Problem zahlreicher nicht voll-ständig erfolgreicher Projekte wird beschrieben, um die Motivation der Arbeitdarzulegen. Ferner wird die Zielstellung formuliert und der Aufbau der Arbeitgeschildert. (Vgl. [Krallmann u. a. 2002, S.47ff.])

Kapitel 2 erläutert die Grundlagen klassischen und agilen Projektmanagementsund definiert die Begriffe Vorgehensmodell und Projektmanagementsystem. An-schließend wird in Kapitel 3 das Projektmanagementsystem Scrum erklärt.

In Kapitel 4 beginnt die Ist-Analyse. Die Funktionalitäten von Projektron BCSwerden beschrieben und es wird aufgezeigt, wie Projektron BCS individuell an-gepasst werden kann. (Vgl. [Krallmann u. a. 2002, S.58ff.])

Als weiterer Teil der Ist-Analyse wird in Kapitel 5 die Anwendung des Scrum Pro-zesses innerhalb der Hypoport AG analysiert. Es wird als Teil des Soll-Konzeptsdargelegt, welche Anpassungen an Projektron BCS notwendig sind, um die Un-terstützung des Scrum Prozesses zu forcieren. Dieses Konzept wird in Kapitel 6detailliert dargelegt. Die Anpassungen und ihre Integration werden beschrieben.(Vgl. [Krallmann u. a. 2002, S.99f.])

Die gewonnenen Erkenntnisse werden in Kapitel 7 in einem abschließenden Fazitzusammengefasst und bewertet.



2 Projektmanagement Grundlagen

Don’t undertake a project unless it is

manifestly important and nearly impossible.

(Edwin Land)

Um Projektmanagement zu definieren, wird das folgende Kapitel die BegriffeProjekt und Management erklären. Grundlagen des Projektmanagements wer-den dargelegt. Einer kurzen Beschreibung der Wissensgebiete im PM folgt einÜberblick über die Prinzipien agilen Projektmanagements. Am Ende des Kapi-tels werden Vorgehensmodelle zur Softwareentwicklung und Projektmanagement-systeme vorgestellt.

2.1 Projektmanagement

Der Ursprung des Wortes Projekt liegt in dem lateinischen Verb proiacere (pro= vor, für, iacere = werfen). Ein Projekt ist also in die Zukunft gerichtet: einVorhaben.

Laut DIN 69901 ist ein Projekt ein „Vorhaben, das im Wesentlichen durch dieEinmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist ...“ ([DIN1987], zit. n. [Angermeier 2005, S.296]) Die Zielvorgabe und zeitliche, finanzielle,personelle und andere Begrenzungen führen dabei zur Einmaligkeit der gesamtenBedingungen. (Vgl. [Angermeier 2005, S.296f.])

Das Project Management Institute (PMI) beschreibt ein Projekt als „zeitlich be-grenztes Vorhaben, zur Schaffung eines einmaligen Produktes, einer Dienstlei-stung oder eines Ergebnisses.“ ([PMBoK 2004, S.5])




Während die verfügbaren finanziellen und personellen Mittel sowie die verfüg-bare Zeit zur Erreichung der Projektziele begrenzt und damit in ihrem Umfangdefiniert sind, ist der genaue Lösungsweg nicht vorgegeben. Die Umsetzung desProjekts erfolgt daher schrittweise. Ein Projekt endet, wenn entweder seine Zieleerreicht wurden, oder deren Erreichung nicht mehr möglich oder notwendig ist.1

(Vgl. [Angermeier 2005, S.297], [PMBoK 2004, S.5ff.])

Die Worte Management und Manipulation haben eine gemeinsame Herkunft inmanus, Hand. Beide bezeichnen Handlungen, die, so Greenleaf, das Schicksalvon Menschen beeinflussen. Der Begriff des Managements beschreibt einerseitsTätigkeiten und Prozesse zur Leitung eines Unternehmens, andererseits die je-weils handelnde Personengruppe oder Institution. Im Gegensatz zur Manipula-tion, die unwissentlich Einfluss ausübt, ist die wissentliche Beeinflussung durch(das) Management akzeptiert. (Vgl. [Greenleaf 2002, S.149], [Rinza 1998, S.3])

Daraus abgeleitet bezeichnet Projektmanagement Tätigkeiten und Prozesse zurLeitung im Wesentlichen einmaliger Vorhaben zur Erreichung einmaliger Ziele.

Das PMI definiert Projektmanagement als „die Anwendung von Wissen, Fertig-keiten, Werkzeugen und Methoden auf Projektvorgänge, um die Projektanforde-rungen zu erfüllen.“ ([PMBoK 2004, S.8]) Diese Projektanforderungen beinhaltendie Ziele und Ergebnisse des Projekts, die mit entsprechendem Inhalt und Um-fang erreicht werden sollen, sowie die Aufwände in Form von Zeit und Kosten.Die Konkurrenz zwischen Zeit, Kosten und Inhalt und Umfang wird durch dasmagische Dreieck (Abbildung 2.1) dargestellt. Ziel des Projektmanagements istes, die drei genannten Faktoren auszugleichen und ein Projekt mit hoher Qua-lität – termin- und budgetgerecht sowie mit gefordertem Inhalt und Umfang –abzuschließen. (Vgl. [PMBoK 2004, S.8])

Projektmanagementprozesse werden iterativ, also wiederholt auf ein Projekt an-gewandt. Dies verdeutlicht der Zyklus Planen-Ausführen-Prüfen-Handeln (Plan-Do-Check-Act, PDCA). Das Ergebnis eines Teils des Zyklus ist dabei Grundlagefür den folgenden Teil: Der Projektplan (Plan) liegt der Ausführung (Do) zuGrunde. Der Fortschritt der Ausführung wird wiederum auf Abweichungen vom

1Im Gegensatz zum Betrieb, dessen Arbeit stets andauert, und dessen Ziel die Aufrechterhal-tung des Geschäfts ist. ([PMBoK 2004, S.7])



2.1 Projektmanagement

Abbildung 2.1: Magisches Dreieck des Projektmanagements

Plan geprüft (Check). Gegebenenfalls werden Maßnahmen ergriffen, um die Pro-jektziele einzuhalten (Act). Anschließend wird die Planung überarbeitet. (Vgl.[PMBoK 2004, S.39ff.])

Jegliche Handlung, die nach der Definition des PM dem Projektziel dient, lässtsich einer der folgenden fünf Prozessgruppen zuordnen:

â Initiierungâ Planungâ Ausführungâ Überwachung und Steuerungâ Abschluss

Diese Einteilung in Prozessgruppen ist die Zusammenführung des PDCA-Zyklusmit der Voraussetzung der zeitlichen Begrenzung eines Projekts.

Abbildung 2.2: PDCA-Zyklus in Verbindung mit PM-Prozessgruppen

Die Steuerungsprozesse beeinflussen als Ergebnis der Überwachung ständig dieweitere Planung und Ausführung des Projekts. Initiierung- und Abschlussprozes-se werden ebenfalls überwacht und gesteuert. Dies ist in Abbildung 2.2 nichtdargestellt, um die Ähnlichkeit zum PDCA-Zyklus hervorzuheben. Eine klareTrennung zwischen Prozessgruppen ist aufgrund ihrer Wechselwirkungen nicht




möglich. Ihre Überschneidungen im zeitlichen Ablauf eines Projekts schließen ei-ne Einteilung in gleichnamige Phasen aus. (Vgl. [PMBoK 2004, S.8, S.39ff.])

Neben der Zuordnung zu Prozessgruppen erfolgt eine Einteilung sämtlicher Pro-zesse in neun Wissensgebiete:

Integrationsmanagement beinhaltet die Koordinierung aller Prozesse. Auftrags-entwicklung, Änderungssteuerung und Abschluss des Projekts fallen in diesen Be-reich. Das Inhalts- und Umfangsmanagement umfasst Definition, Planung, Steue-rung des Inhalts und Umfangs eines Projekts, sowie die Abnahme fertig gestellterTeile eines Projekts. Prozesse, die die zeitliche Abfolge von Vorgängen beeinflus-sen, Terminplanung und Schätzungen der Dauer von Vorgängen werden unterdem Begriff des Terminmanagements zusammengefasst. Prozesse des Kostenma-nagements dienen dem budgetgerechten Abschluss des Projekts. Qualitätsma-nagement beinhaltet Vorgänge, die der Prozessverbesserung und der Sicherungvon Qualitätsstandards in Bezug auf Projektanforderungen dienen. Personalma-nagement umfasst die Teamplanung und -leitung sowie die Verteilung der Rollenund Verantwortlichkeiten. Das Risikomanagement identifiziert, überwacht undanalysiert Ereignisse, deren Eintreten positive oder negative Auswirkungen aufdie Projektziele oder ihre Erreichung haben. Die Reaktionen auf Risiken undihre Bewältigung gehören ebenfalls zum Risikomanagement. Prozesse in derenRahmen Produkte oder Leistungen von außerhalb des Teams erworben oder inAnspruch genommen werden, gehören zum Beschaffungsmanagement. Das Ma-nagement von Verträgen und bezüglich Lieferanten zählt ebenso dazu. Aufgabedes Kommunikationsmanagements ist die Sicherstellung der Verfügbarkeit von In-formationen innerhalb des Projekts, das Fortschrittsberichtswesen und das Sta-keholdermanagement. Als Stakeholder (engl. für Teilhaber, Interessenvertreter)werden Personen und Organisationen bezeichnet, die am Projekt teilhaben unddie Durchführung beeinflussen können. Stakeholdermanagement versucht, durchKommunikation mit den Stakeholdern deren Projektanforderungen zu erfüllensowie Probleme zu lösen. (Vgl. [PMBoK 2004, S.337ff.])



2.2 Agiles Projektmanagement

2.2 Agiles Projektmanagement

Zu Beginn der Entwicklung agilen Projektmanagements stand die Einbeziehungdes Kunden in die Softwareentwicklung. Einer der Risikofaktoren für das Schei-tern von Projekten wird dadurch gemildert. Agilität bedeutet Beweglichkeit und siehe 1Flexibilität. Agile Vorgehensweisen ermöglichen schnelle Reaktionen auf sich än-dernde Projektanforderungen und schwächen so einen weiteren Risikofaktor ab.Zumeist Ende der 1990er-Jahre entwickelt, wurden diese flexiblen Vorgehenswei-sen erst 2001, nach der Formulierung des Agilen Manifests, unter dem Begriff derAgilität zusammengefasst. (Vgl. [Angermeier 2005, S.32ff.], [Schwaber 2007b])

Das Agile Manifest proklamiert die Grundprinzipien der Agilität:

â Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeugeâ Funktionierende Software ist wichtiger als umfangreiche Dokumentationâ Kooperation mit Projektbetroffenen ist wichtiger als Vertragsverhandlungenâ Reaktion auf Änderungen ist wichtiger als Festhalten an einem starren Plan[Beck u. a. 2001], [Oestereich und Weiss 2008, S.15]

Agilität begegnet der Komplexität eines Softwareentwicklungsprojekts durch in-krementelle Entwicklung in kurzen Iterationszyklen, was zeitnahe Reaktionen aufÄnderungen ermöglicht. Ein Inkrement ist dabei der Teil des Projektziels, der ineiner Iteration fertig gestellt wurde. Inkremente werden in verschiedenen agilenMethoden auch als Features oder Funktionalitäten bezeichnet. Iterationen sindzumeist gleich lange Zeitabschnitte innerhalb der Entwicklungsdauer eines Pro-jekts. In den Iterationen, je nach agiler Methode auch Timeboxes oder Sprintsgenannt, werden die gleichen elementaren Aktivitäten zur Entwicklung von In-krementen angewandt. Um iterativ, inkrementelle Entwicklung agil nennen zukönnen, bedarf es einer weiteren Bedingung: Jedes Inkrement muss erfolgreichgetestet sein und den Stakeholdern demonstriert werden können. Darüber hin-aus verhindern agile Prozesse Verschwendung, wie z. B. teilweise fertig gestellteArbeitsergebnisse, das Verrichten unnötiger Arbeit oder Erstellung von Doku-menten, die lediglich dazu dient, den Prozess einzuhalten. Dies ist die direkteUmsetzung des zweiten Prinzips des Agilen Manifests. Agile Teams managen sichselbst. Daher bedingt agiles Projektmanagement eher eine Bottom-up- statt ei-ne Top-Down-Planung. Bei ersterer werden Planwerte in den unteren Elementen




der Projektplanung erfasst und zu einem Gesamtbudget summiert. Top-Down-Planung gibt hingegen erst das Gesamtbudget vor und verteilt dies anschließendvon oben nach unten auf Unterprojekte, Aufgaben, oder andere Strukturelemente.(Vgl. [Oestereich und Weiss 2008], [Schwaber 2007b])

Der zuvor beschriebene Trend zur Agilität hat dazu geführt, dass weitere Bereichesiehe 1klassischen Projektmanagements in agile Vorgehensweisen integriert wurden. Zu-sätzlich haben klassische Vorgehensmodelle ebenfalls agile Ansätze einbezogen.Das erschwert zunehmend die Abgrenzung zwischen traditionellem und agilemProjektmanagement. (Vgl. [Angermeier 2005, S.33])

2.3 Projektmanagementsysteme

Eine Möglichkeit, der Komplexität der Softwareentwicklung zu begegnen sindVorgehensmodelle. Dabei werden aus den Prozessen der PM-Prozessgruppen und-Wissensgebiete standardisierte Abläufe gebildet (vgl. [Angermeier 2005]). EinÜberblick der Entwicklung einiger Vorgehensmodelle wird in Abbildung 2.3geboten.

Dient ein solches Vorgehensmodell der erfolgreichen Umsetzung von Projekten,ist es ebenfalls ein Projektmanagementsystem (PMS). Das Deutsche Institut fürNormung definiert ein PMS als „Organisatorisch abgegrenztes Ganzes, das durchdas Zusammenwirken seiner Elemente in der Lage ist, Projekte vorzubereiten undabzuwickeln“ ([DIN 1987], zit. n. [Angermeier 2005, S.339]). Dies gilt für sämtlicheder in Abbildung 2.3 dargestellten Vorgehensmodelle.

Ein PMS ist jedoch nicht das in einer Organisation verordnete theoretische Vor-gehen, sondern das tatsächlich gelebte Handlungsmodell. Ein Unternehmen kannzwar formal ein agiles PMS verwenden, wenn jedoch Führungskräfte die agilenPrinzipien des jeweiligen Prozesses untergraben, indem sie bspw. das Selbstma-nagement des Teams behindern, ist das gelebte Vorgehen nicht mehr agil. DerUmkehrschluss gilt ebenfalls. Inwiefern jedoch die agile Auslegung eines formalnicht agilen PMS zu dessen Standard konform ist, zeigt sich erst im Einzelfall.(Vgl. [Angermeier 2005, S.339])



2.3 Projektmanagementsysteme

Abbildung 2.3: Geschichte von Vorgehensmodellen,nach [Oestereich und Weiss 2008], [Pichler 2007]

Nicht agile Projektmanagementsysteme definieren umfangreiche Prozesse: DasPMI erläutert mit dem PMBoK Guide2 auf nahezu 400 Seiten ein PMS. Die Doku-mentationen der Projektmanagementsysteme V-Modell XT und PRINCE2 sindjeweils noch umfangreicher. Da Agilität jedoch Beweglichkeit und Flexibilität be-deutet, beschreiben agile Vorgehensweisen einen meist kleinen methodischen Kernund liefern anhand bewährter Praktiken (best practices) Vorschläge, die den er-folgreichen Einsatz der jeweiligen Vorgehensweise unterstützen. (Vgl. [Oestereichund Weiss 2008, S.v], [Pichler 2007, Kap.1], [Angermeier 2005, S.296])

Agile Vorgehensweisen sind vielfach miteinander kombinierbar. Hauptvorgehens-weise ist jedoch in nahezu 60% aller Unternehmen Scrum (vgl. Abbildung 2.4).

2Die geläufige Abkürzung für A Guide to the Project Management Body of Knowledge.




Abbildung 2.4: Anwendung agiler Vorgehensweisen,Quelle: [Behrens 2006]

Als zentraler Aspekt der vorliegenden Arbeit wird Scrum daher im folgendenKapitel eingehend erläutert.



3 Scrum

Liberty means responsibility.

That is why most men dread it.

(George Bernard Shaw)

Dieses Kapitel wird Scrum, eine agile Projektmanagementmethodik, und seineklar definierten Regeln unterteilt nach Rollen, Artefakten und Prozess beschrei-ben und Empfehlungen bewährter Praktiken darlegen.

Der Begriff Scrum bedeutet Gedränge und entstammt dem Rugby. Ein Gedrän-ge beschreibt dort einen komplizierten Spielzug, bei dem sich die Spieler beiderMannschaften eng umschlungen gegenüber stehen und versuchen, den Ball zu er-obern, in dem sie ihn mit den Füßen nach hinten schieben. Sowohl der BegriffGedränge als auch der Spielzug heben die Bedeutung der Teamarbeit hervor.(Vgl. [Pichler 2007, S.2])

Scrum definiert im Gegensatz zu anderen Managementframeworks nur je drei Rol-len und Artefakte3. Als Artefakte werden in der Softwareentwicklung Zwischen-oder Endprodukte des Entwicklungsprozesses bezeichnet. Der Scrum Prozess siehtweiterhin vier Meetings vor. Das verdeutlicht bereits, wie stark Scrum das AgileManifest widerspiegelt. Drei Rollen und vier Meetings (Individuen und Interak- siehe 2.2tionen) stehen lediglich drei Artefakten (Prozesse und Werkzeuge) gegenüber.([Pichler 2007, S.9])

3Das V-Modell XT beispielsweise definiert 31 Rollen und weit mehr Produkte. ([VMXT 2007,S.233ff., S.500ff.])



3 Scrum

3.1 Rollen

ScrumMaster

Traditionelles Projektmanagement steht zwischen Auftraggeber und Projektteam,um die aus den Anforderungen resultierende Arbeit zu planen. Um Assoziationensiehe 2.1zur direkten Autorität eines klassischen Projektmanagers zu vermeiden, verwen-det Schwaber einen neuen Titel: den ScrumMaster. Aufgabe des ScrumMastersist es, für die Einhaltung und den möglichst reibungslosen Ablauf des Scrum Pro-zesses zu sorgen. Er steht daher neben dem Product Owner und dem Team undunterstützt sie bei der Erfüllung Ihrer Verantwortlichkeiten, hilft ihnen also sichselbst zu managen. Diese Hilfe ist notwendig, da der ScrumMaster Verantwortungfür den Scrum Prozess trägt, ohne formelle Macht zu haben. Dieser Verantwortungwird der ScrumMaster durch die Moderation der vier im Prozess vorgesehenenMeetings gerecht. (Vgl. [Pichler 2007, S.20ff.], [Schwaber 2004, S.25])

Empfehlungen

Neben der Bereitschaft Verantwortung zu übernehmen, muss ein guter ScrumMa-ster über die Tugenden der Hingabe und Bescheidenheit verfügen, aber auch überdas politische Gespür, seinen Einfluss im Team und in der Organisation geltendzu machen. ([Cohn 2007])

In jeder Organisation, unwichtig ob es sich um Linien- oder projektbasierte Orga-nisationen (vgl. [PMBoK 2004, S.28ff.]) handelt, existieren Hierarchien. Im Rah-men dieser Hierarchien haben Menschen ein natürliches Bedürfnis zu gefallen,auch aus Angst vor Sanktionen bei Nichtgefallen. Aus diesem Grunde tendie-ren sie dazu, erreichte Ergebnisse oder zu planende Aufwände zu beschönigen.Dies hat weitreichende Auswirkungen auf das Projekt. Der ScrumMaster stehtzumindest im Kontext des Projekts außerhalb von Hierarchien. ([DeMarco 1998,S.25ff.], vgl. [Schwaber 2004, S.114])

Obwohl der ScrumMaster also weder Teammitgliedern noch Product Owner ge-genüber weisungsbefugt ist, kommt ihm im Projekt eine gewisse Führungsrolle zu-teil. Begründet wird diese Führungsrolle durch das Prinzip der Servant Leadership(Führen durch Dienen) nach Greenleaf. Dieser erklärt, dass eine Gruppe am



3.1 Rollen

ehesten jemanden als Anführer akzeptieren würde, wenn dieser der Gruppe bereitsausgesprochen gut gedient und ihr Vertrauen erworben hat. Der ScrumMasterdient dem Team, indem er jederzeit im Rahmen des Scrum Prozesses Hindernissebeseitigt, zur Konfliktbewältigung beiträgt und eine gemeinschaftliche Entschei-dungsfindung fördert. So gewinnt er an Einfluss. Mit Scrum halten so Greenleafsmittlerweile fast 40 Jahre alten Ideen Einzug ins Software-Projektmanagement.(Vgl. [Greenleaf 2002])

Product Owner

Der Product Owner vertritt die Endkunden und Interessenvertreter im Projektund verantwortet ihnen gegenüber den Projekterfolg. Meist gibt es in Projektenmehrere Interessenvertreter (Stakeholder) deren vielfältige Anforderungen sich im siehe 2.1Endprodukt wiederfinden sollen. Schwaber behauptet, 35 Prozent der Anfor-derungen würden sich ändern und 65 Prozent seien von so geringem Wert, dassihre Lieferung fraglich sei ([Schwaber 2007a]). In Scrum kommt daher der An-forderungserhebung kein hoher Stellenwert zu. Sie erfolgt vielmehr evolutionär.Der Product Owner steuert diese Evolution der Anforderungen mit dem einzi-gen Artefakt, das im Scrum Prozess in seine Verantwortung fällt: dem ProductBacklog. Hier werden Anforderungen ergänzt oder entfernt, verfeinert und priori-siert. Um dabei stets im Interesse der Auftraggeberseite zu handeln, ist intensiveregelmäßige Abstimmung notwendig. ([Pichler 2007, S.10])

Da der Product Owner das Releasemanagement nicht an Projektmanager oderTeamleiter delegiert, obliegt ihm selbst die Verantwortung über die termingerech-te Auslieferung, Umfang und Kosten des Produkts. Um dieser Verantwortunggerecht werden zu können, muss dem Product Owner diesbezüglich Entschei-dungsgewalt gegeben sein.

Empfehlungen

Durch regelmäßige direkte Zusammenarbeit mit dem Team, idealerweise direktnach dem Daily Scrum, können aufkommende Fragen sofort geklärt werden. Je öf-ter der Product Owner mit dem Team arbeitet, desto unwahrscheinlicher kommt



3 Scrum

es zu Verzögerungen durch offene Fragen. Seine Verfügbarkeit ist also Erfolgs-faktor für die Ausübung seiner Rolle und damit für das Projekt. Die enge Zu-sammenarbeit mit dem Team überbrückt die über Jahrzehnte entstandene Kluftzwischen Kundenbedürfnissen und Softwareentwicklung. (Vgl. [Schwaber 2004,S.54], [Pichler 2008, S.11])

Team

In der Verantwortung des Teams liegt das potenziell lieferbare Produktinkrement.Dies ist die Erweiterung des aktuellen Entwicklungsstands des Projekts um min-destens eine Anforderung. Wie viele Anforderungen während der nächsten Itera-tion umgesetzt werden, entscheidet das Team im Sprint Planning Meeting selbst.Es ist ermächtigt (empowered). Die Einführung von Scrum in einer Organisati-on erfordert und fördert den Übergang von einem Team, das gemanagt wird, zueinem Team, das sich selbst managt. Diese Freiheit setzt Kreativität frei, führtaber auch zu Verantwortung. Jeder im Team geht sich selbst und dem ganzenTeam gegenüber eine Verpflichtung ein, das gesetzte Ziel zu erreichen. Dies stei-gert erst langsam, dann in zunehmendem Maße die Produktivität. ([Schwaber2004, S.42, S.116])

Scrum Teams sind „echte Teams“. Im Gegensatz zu Teams, die nur in der Projekt-planung existieren und in der Realität nur eine „lose Ansammlung von Individuen“sind, unterstützen sich Mitglieder echter Teams gegenseitig, was häufig zu Syner-gieeffekten führt. Diese treten jedoch nur bei einer Teamgröße von ungefähr fünfbis neun Personen auf. In größeren Teams wird es schwerer, gemeinsame Normenzu finden. Die Kommunikation wird zunehmend aufwendiger. Die Zusammenar-beit erfordert daher Unterstützung durch Dokumentation. ([Pichler 2007, S.16f.],[Schwaber 2004, S.118])

Damit ein Team diese Verpflichtung eingehen kann, muss es unabhängig sein.Aufgaben, die zum Erreichen des Sprint-Ziels notwendig sind, müssen von Mit-gliedern des Teams erfüllt werden können. Natürlich ist es erlaubt, von außerhalbdes Teams Informationen und Ratschläge einzuholen. Abhängigkeiten dürfen dar-aus jedoch nicht erwachsen. Ein Scrum Team ist interdisziplinär besetzt. Obwohletliche Rollen, wie z. B. Architekten und Entwickler, im Team vertreten sind, for-dert Scrum, sich über ein kompromissloses Verständnis dieser Rollen hinwegzuset-



3.1 Rollen

zen. Was zählt, ist die enge Zusammenarbeit und das Erreichen des Sprint-Ziels.Schwaber nennt Teams cross-functional und fügt hinzu „you don’t have to bea tester to test, or a designer to design“. ([Schwaber 2004, S.104], vgl. [Pichler2007, S.14f.])

Anmerkungen

Die zu Beginn des Kapitels gelobte Spezifikation lediglich dreier Rollen in Scrumscheint widersprüchlich zur Erläuterung des Teams. Scrum kann eine gewisseScheinheiligkeit vorgeworfen werden, da in einem interdisziplinär besetzten Teamweitere Rollen enthalten sind. Das V-Modell XT fordert schließlich ebenfalls, einProjektteam zusammenzustellen. Es fordert jedoch darüber hinaus, die Rollen derMitarbeiter festzulegen ([VMXT 2007, S.236]). Letzteres ist, auf das Team bezo-gen, der grundlegende Unterschied zu Scrum: Eine Festlegung erfolgt bei Scrumnicht. Dem Team ist sowohl die Arbeitsorganisation als auch die Rollenzuweisungselbst überlassen. Im Mittelpunkt steht, laut Schwaber, die Arbeit und nicht,darüber nachzudenken. ([Schwaber 2004, S.9])

Im Scrum Prozess werden trotz der Abschaffung der Rolle des klassischen Pro-jektmanagers fast sämtliche Aufgaben traditionellen Projektmanagements erfüllt. siehe 2.1Für Inhalts-, Zeit- und Kommunikationsmanagement ist das Team auf Sprintebe-ne, der Product Owner auf Releaseebene zuständig. Dem Product Owner obliegtdas Kostenmanagement, sowie dank Input vom Team das Risikomanagement.Alle drei Rollen beteiligen sich am Qualitätsmanagement: Der Product Ownerbezogen auf die Leistungsmerkmale des Produkts, das Team bezüglich der quali-tativ hochwertigen Umsetzung und schließlich der ScrumMaster bezogen auf dieProzessqualität. Lieferantenmanagement ist gemeinsame Aufgabe von Team undProduct Owner. Das Team selbst übernimmt das Personalmanagement, indemes für die Steigerung der eigenen Produktivität sorgt. Auch die Daueraufgabe,Kompetenz und Professionalität zu verbessern obliegt dem Team. Lediglich fürdie Bereitstellung der Mitarbeiter selbst ist ein übergeordnetes Management zu-ständig. ([Pichler 2007, S.24], vgl. [Schwaber 2004, S.101, S.107])



3 Scrum

3.2 Artefakte

Zwei der drei Artefakte im Scrum Prozess enthalten den Begriff backlog. Dabeihandelt es sich um eine Liste von Dingen, die getan werden müssen, eine „Zu-erledigen-Liste“. Das erste dieser Artefakte, das Product Backlog bezieht sich aufdas komplette Projekt. Die zweite Listenart, das Sprint Backlog, gilt für je einenSprint.

Product Backlog

Anforderungserhebung und -management werden in Scrum mit dem ProductBacklog realisiert. Alle bekannten funktionalen und nicht funktionalen Anforde-rungen sind hier aufgelistet. Es enthält das Was, nicht das Wie: Arbeitsergebnissekönnen Teil des Product Backlogs sein, Aktivitäten, die zu deren Erreichen nötigsind jedoch nicht. ([Pichler 2007, S.27f.])

Zum Zeitpunkt des Projektstarts beinhaltet das Product Backlog zumindest we-sentliche Anforderungen (Erfolgsfaktoren für Vertrieb und Einsatz des Produkts).Um dem Team Selbstmanagement durch Auswahl der Anforderungen zu ermög-lichen, muss deren Anzahl für wenigstens zwei bis drei Sprints ausreichend sein.Der Product Owner priorisiert sämtliche Anforderungen und steuert so die Rei-henfolge der Umsetzung. Die wichtigsten Anforderungen werden als Erstes umge-setzt und sind daher am detailliertesten. Analyse und Verfeinerung der niedrigerpriorisierten Anforderungen erfolgen iterativ. (Vgl. [Pichler 2007, Kap.4.2])

Ein Beispiel für ein Product Backlog der vorliegenden Arbeit mit ersten, grobformulierten Anforderungen, Priorität, thematischer Einordnung und Aufwands-schätzung zeigt Tabelle 3.1.

Der Product Owner kann jederzeit Anforderungen aus dem Product Backlog strei-siehe 3.1chen. Wurden diese unnötigerweise bereits detailliert beschrieben, resultiert dasin Verschwendung. Diese wird durch die iterative Verfeinerung verringert. ImProjektverlauf wird das Product Backlog ständig detaillierter, bis zum Ende desProjekts alle entwickelten Anforderungen in hohem Detailgrad festgehalten sind.(Vgl. [Pichler 2007, Kap.5.7.3])



3.2 Artefakte

Pr. Thema Beschreibung Aufw.

1 Praxis Anforderungen an das Konzept müssen erarbeitet werden 8

1 Praxis Das Konzept muss detailliert schildern, was umgesetzt wirdund wie die Umsetzung in Projektron BCS integriert wird.

5

2 Theorie Die Schilderung des Scrum Prozesses muss die Grundlagefür weitere Betrachtungen bilden und sämtliche relevantenBegriffe erläutern.

3

2 Theorie Die Einleitung muss Motivation, Ziel und Aufbau der Arbeitdarlegen

1

Tabelle 3.1: Tabellarisches Product Backlog

Empfehlungen

Gute Anforderungen sind nach [Wake 2003] durch INVEST-Merkmale gekenn-zeichnet. Das Akronym INVEST steht dabei für independent, negotiable, valua-ble, estimable, small, testable. Die Einträge mit der höchsten Priorität solltendiesen Merkmalen entsprechend unabhängig, verhandelbar, nützlich, schätzbar,klein und testbar sein.

Pichler empfiehlt die Verwendung von user stories nach [Cohn 2004]: User sto-ries oder Benutzergeschichten sind in allgemeiner Sprache verfasste Beschreibun-gen von Funktionalitäten. Die Formulierung von Akzeptanzkriterien stellt sicher,dass die erfolgreiche Umsetzung einer user story bewertet werden kann. Um inBesprechungen nicht nur mit virtuellen Artefakten zu arbeiten, werden user sto-ries traditionell auf Karteikarten geschrieben. Diese Vorgehensweise erfüllt die3C-Kriterien card, conversation, confirmation (vgl. [Cohn 2004]) und impliziertgleichzeitig bereits die Erfüllung von drei der sechs INVEST-Merkmale: Klein,verhandelbar, testbar. Da der Platz auf Karteikarten begrenzt ist, müssen userstories kurz sein (card und klein). Details werden im Gespräch zwischen Kundeund Entwicklern, in Scrum zwischen Product Owner und Team, erarbeitet (con-versation und verhandelbar). Die Einigung auf Akzeptanzkriterien bestätigt dasgemeinsame Verständnis einer user story (confirmation und testbar). Das Merk-mal nützlich bezieht sich auf den Endverbraucher. Ein schlechtes Beispiel hierfürist:

Der Streamingserver muss eine Bandbreite von 5 Mbit/s liefern.



3 Scrum

Da diese story in technischer Sprache verfasst ist, hat sie für den Endverbraucherkeinen Nutzen. Dieser wird erst ersichtlich, wenn die user story aus Anwendersichtformuliert wird:

Zehn Benutzer sollen die Videos gleichzeitig in guter Qualität und ohne War-tezeit empfangen können.

Wenngleich noch ein gemeinsames Verständnis von „guter Qualität“ geschaffenwerden muss, ist der Nutzen für den Kunden bei dieser user story bereits offen-sichtlich.

Um Abhängigkeiten zwischen user stories aufzulösen, können entweder abhängi-ge stories zu einer größeren, aber unabhängigen story zusammengefasst oder eineandere Unterteilung gewählt werden. User stories sind nicht oder nur schlechtschätzbar, wenn sie zu groß sind oder dem Team zur Umsetzung notwendigesWissen fehlt. Auch hier kann Unterteilung Schätzbarkeit (das letzte verbliebeneINVEST-Merkmal) gewährleisten. Eine zu große user story, ein epic, setzt sichaus mehreren kleineren stories zusammen. Vor ihrer Schätzung und Umsetzungmuss diese Unterteilung gefunden und vorgenommen werden. Eine komplexe Be-nutzergeschichte kann in eine Erkundungs- oder Recherchegeschichte4 und eineUmsetzungsgeschichte geteilt werden.

Sprint Backlog

Das Team wählt selbstständig diejenigen Anforderungen aus dem Product Back-log, die es innerhalb des nächsten Sprints umsetzen wird. Grundlage dieser Aus-wahl ist die Menge der Anforderungen, die der Product Owner am höchsten prio-risiert hat. Das auf diese Weise definierte Sprint-Ziel darf während des Sprintsnicht geändert werden. Das schafft Sicherheit für das Team. Aktivitäten, die zumErreichen der Zielsetzung notwendig sind, werden im Sprint Backlog festgehal-ten. Es enthält Aufgaben, die detaillierter sind als deren Ziele im Product Backlogund unterliegt der alleinigen Verantwortung des Teams. Daher verändert es sichtäglich: Beginnt ein Teammitglied eine Aufgabe, wird dies an der Aufgabe ver-merkt. Ist die Aufgabe abgeschlossen, wird sie als erledigt markiert. Endet einArbeitstag, werden spätestens dann die Restaufwände der Aufgaben, die noch „in

4Nach Cohn ein spike, für den begrenzte Zeit zur Verfügung steht.



3.2 Artefakte

Arbeit“ sind, aktualisiert. Wie umfangreich die Aufgaben tatsächlich sind, obliegtebenfalls dem Team. Es bestimmt den Detailgrad der Aufgaben und damit ihreDauer.

Empfehlungen

Als maximale Dauer einer Aufgabe empfiehlt Pichler einen Nettoarbeitstag,um täglich den Projektfortschritt zu verfolgen. Das deckt sich nur bedingt mitSchwaber, der vier bis sechzehn Stunden pro Aktivität vorsieht. Die Beschrän-kung auf einen Nettoarbeitstag ist mit dem Ziel, den Fortschritt täglich zu be-obachten, nicht zu begründen. Schließlich werden bei Aktivitäten, die über denArbeitstag hinausgehen, Restaufwände täglich erfasst, was die geforderte Beob-achtung gewährleistet. Für einzelne Teammitglieder mag die Erfüllung einer Auf-gabe am Ende des Arbeitstages eine zusätzliche Motivation darstellen. Da in derLiteratur auf diesen Aspekt jedoch nicht eingegangen wird, bleibt dies Spekula-tion. (Vgl. [Pichler 2007, S.102f.], [Schwaber 2004, S.12])

Statt nur ein virtuelles Sprint Backlog in einer Software zu verwalten, empfiehltsich die Visualisierung mit Karteikarten an einer Stellwand. Diese in der Nähedes Teams aufgehängte Planungswand bietet jederzeit einen Überblick über denStatus des Sprints. ([Oestereich und Weiss 2008, S.272], [Pichler 2007])

Potenziell lieferbares Produktinkrement

Das potenziell lieferbare Produktinkrement5 ist das Produkt eines jeden Sprints.Dieses Artefakt ohne Anmerkung mit Produktinkrement abzukürzen, verstößtgegen seine Definition im Sinne von Scrum. Jede umgesetzte Anforderung ausdem Product Backlog ist ein Produktinkrement. Ist im Folgenden die Rede voneinem Produktinkrement, so ist stets ein potenziell lieferbares gemeint ([Schwaber2004, S.12]). Erst dieses Attribut verdeutlicht, wie flexibel der Product Owner inScrum auf Veränderungen reagieren kann:

Kündigt beispielsweise ein Wettbewerber ein ähnliches Produkt an, oder wird dasRelease eines direkten Konkurrenzprodukts vorgezogen, kann der Product Owner

5Schwaber verwendet potentially shippable product increment oder increment of potentiallyshippable product functionality synonym.



3 Scrum

darauf angemessen reagieren: Da jederzeit potenziell lieferbare Software – das ku-mulierte Ergebnis aller vergangenen Sprints – vorliegt, kann eine erste Version desProdukts jederzeit veröffentlicht werden. Sind dafür noch Deploymenttätigkeitennotwendig, können Wettbewerbsnachteile gemildert oder -vorteile geschaffen wer-den, indem ein Release-Sprint verwendet wird. (Vgl. [Pichler 2007, Kap.5.4])

Die Entwicklung eines Produktinkrements erfordert eine gemeinsame Definitionder Worte „potenziell lieferbar“ oder „fertig“, eine sog. Definition of Done, kurzDoD. In Bezug auf ein Produktinkrement, also zusätzliche Funktionalität, be-deutet fertig, dass dieses lauffähig, getestet und dokumentiert sein muss ([Pichler2007, S.83]). Bezogen auf Programmcode bedeutet es allerdings nicht nur, dasser frei von Bugs ist, wie ein Entwickler es verstehen könnte, sondern auch gutstrukturiert und lesbar ist, sich an Programmierstandards hält und keine doppel-ten Passagen enthält. Erst eine gemeinsame DoD zwischen Product Owner undEntwicklungsteam erzeugt die für Scrum notwendige Transparenz der Ergebnisse.Existiert diese Übereinkunft nicht, geht der Überblick über den Projektfortschrittverloren. Damit verschlechtern sich die Chancen aller Beteiligten, angemessen aufVeränderungen zu reagieren. (Vgl. [Kniberg 2006, S.32], [Schwaber 2004, S.71f.])

Anmerkung

Auf den ersten Blick scheint das Attribut „potenziell lieferbar“ eine Dopplung zusein. Etwas, das lieferbar ist, wird noch nicht geliefert, kann aber jederzeit geliefertwerden. Das „potenziell“ bezieht sich auf den Mehrwert, den eine Anforderung fürden Endanwender hat. Ein lieferbares Produktinkrement hat einen solchen. Einpotenziell lieferbares Produktinkrement kann jedoch auch Funktionalität enthal-ten, die zwar vollständig umgesetzt ist, aber alleine stehend (standalone) keinenMehrwert hat. (Vgl. [Pichler 2007, S.84f.])

3.3 Prozess

Ein definierter Prozess liefert aus festgelegten Eingängen (input) durch die glei-chen Leistungen stets die gleichen Ergebnisse (output). Wenn die Komplexitätder Aktivitäten in einem Prozess zu groß wird, stößt defined process control an



3.3 Prozess

ihre Grenzen. Um diese Komplexität zu handhaben, muss der Prozess schrittwei-se, also iterativ, verbessert werden. Diese auf gezielten Beobachtungen basierendeProzessverbesserung nennt sich empirical process control. Scrum ist ein empiri-scher Prozess und erfordert daher empirische Prozesskontrolle. Erst die Trans-parenz (visibility) aller Vorgänge im Projekt ermöglicht gezielte Beobachtungen(inspection). Aus diesen Untersuchungen die richtigen Schlüsse zu ziehen undentsprechende Anpassungen (adaptation) vorzunehmen führt zu Prozessverbes-serung. (Vgl. [Schwaber 2004, S.2ff.])

Abbildung 3.1: Scrum, Quelle: [MGS 2005]

Einige Beispiele von visibility, inspection und adaptation wurden in den Erläu-terungen der Rollen und Artefakte bereits sichtbar. Abbildung 3.1 zeigt nunden iterativen, inkrementellen Ablauf des Scrum Prozesses. Nach jeder Iteration,jedem Sprint, sowie täglich während des Sprints sind Beobachtungen und Anpas-sungen vorgesehen. Abbildung 3.2 zeigt den Scrum Prozess in Form eines Ak-tivitätsdiagramms. Detailliert dargestellt sind die Vorbereitung eines Scrum Pro-jekts und relevante Entscheidungen nach Abschluss eines Sprints. Die innerhalbder Meetings des Scrum Prozesses auszuführenden Aktivitäten werden separatabgebildet. Die Zusammenführung des Aktivitätsdiagramms in Abbildung 3.2mit den folgenden Diagrammen befindet sich in Anhang C.

Dass Scrum die Aspekte empirischer Prozesskontrolle auf jede Aktivität innerhalbdes Prozesses überträgt, wird bei der Betrachtung der Meetings innerhalb des



3 Scrum

Abbildung 3.2: Aktivitätsdiagramm des Scrum Prozesses

Scrum Prozesses deutlich. Die Scrum-Definition des EPF Composer6 bezeichnetdiese Meetings als collaboration points, also sinngemäß „Punkte der Zusammen-arbeit“. Diese Bezeichnung ist äußerst treffend. Die Meetings im Scrum Prozessunterscheiden sich von herkömmlichen Besprechungen. DeMarco schildert einNegativerlebnis: Eine Besprechung ohne feste Tagesordnung, mit zu vielen An-wesenden. Beide Tatsachen führen zu Frustration und Desinteresse ([DeMarco1998, S.228f]). Im Gegensatz dazu sind die im Scrum Prozess vorgesehenen col-laboration points zeitlich begrenzte Besprechungen mit festgelegten Inhalten undTeilnehmern. Für die Einhaltung der Regeln und die Moderation ist der Scrum-Master verantwortlich.

Die erste und, da sie für den gesamten Scrum Prozess gilt, wichtigste dieser Re-geln betrifft die Kommunikation: Sie muss offen und ehrlich sein. Dabei mussstets zwischen der Sache und der Person getrennt werden. Alles andere ist kon-

6Der EPF Composer ist ein Tool zur Prozessdefinition. Eine mit diesem freien Werkzeugerstellte Definition des Scrum Prozesses ist ([Eclipse]).



3.3 Prozess

traproduktiv. Gegenseitiger Respekt ist Voraussetzung für eine erfolgreiche Zu-sammenarbeit. (Vgl. [Pichler 2007, S.113ff.])

Sprint Planning Meeting

Das Sprint Planning Meeting bzw. die Sprint-Planungssitzung dient der Vorbe-reitung des kommenden Sprints und ist der größte collaboration point. Schwa-

ber begrenzt die Dauer des Sprint Planning Meetings auf acht Stunden. Er gehtdabei stets von einer Sprintdauer von 30 Tagen, also ungefähr 20 Arbeitstagenaus. Pichler selbst arbeitet mit kürzeren, meist zweiwöchigen Sprints und plantfür die Sprint-Planungssitzung fünf Prozent der Bruttoarbeitszeit ein, bei zehnArbeitstagen also ungefähr vier Stunden. Am Sprint Planning Meeting nehmenausschließlich der Product Owner, der ScrumMaster und das Team teil. WerdenInformationen oder Ratschläge von Personen außerhalb des Projekts benötigt, istderen Anwesenheit gestattet. Sie müssen die Sitzung jedoch verlassen, sobald siediese Aufgabe erfüllt haben. Um die Menge der Anforderungen zu bestimmen,die zeitlich umgesetzt werden kann, muss zu Beginn der Besprechung bereits be-kannt sein, wie viel der Arbeitszeit des Teams für das Projekt zur Verfügung steht(Nettoarbeitszeit). Je kürzer der Sprint, desto größer ist der Einfluss von Urlaub,Feiertagen oder Teilzeitverfügbarkeit von Teammitgliedern auf die Gesamtkapa-zität. (Vgl. [Schwaber 2004, S.133f.], [Pichler 2007, Kap.6.4])

Zu Beginn des Meetings muss das priorisierte Product Backlog vorliegen. Die hochpriorisierten Anforderungen sind eine Vorauswahl dessen, was im zu planendenSprint entwickelt wird. Das Team beginnt mit der Analyse der Anforderungenund bestimmt die Aktivitäten, die zu deren Erfüllung ausgeführt werden müs-sen. Dabei werden sämtliche Aufwände geschätzt. Anschließend wählt das TeamElemente aus, die es glaubt, in seiner verfügbaren Nettoarbeitszeit umsetzen zukönnen. Dabei erfolgt keine Pufferung. Ergebnis der Sitzung ist das Sprint Back-log.

Der ScrumMaster moderiert das Sprint Planning Meeting. Weder er noch derProduct Owner planen selbst. Sie unterstützen das Team bei der Planung. DasAugenmerk des ScrumMasters muss darauf liegen, stillere Teammitglieder einzu-beziehen und Dominanz vorzubeugen. Da das Team als Ganzes für das Sprint



3 Scrum

Abbildung 3.3: Aktivitätsdiagramm des Sprint Planning Meetings

Backlog verantwortlich ist, muss vermieden werden, dass Teammitglieder Aktivi-täten sofort auswählen, was Zusammenarbeit und Wissensverteilung verhindernwürde. Für den Product Owner wird die Aufwandsschätzung sichtbar. KönnenAufwände nicht geschätzt werden, ist eine Überarbeitung (adaptation) der An-forderungen notwendig. (Vgl. [Pichler 2007, S.93, S.99ff.])

Empfehlungen

Schwaber beschreibt eine Halbierung der Sprint-Planungssitzung: In der erstenHälfte soll das Team die Elemente des Product Backlogs wählen, die es glaubt,in der verfügbaren Zeit umsetzen zu können. Die zweite Hälfte dient der Bestim-mung der Aktivitäten und der Aufwandsschätzung. Diese strikte Teilung ist nichtoptimal, da besagte Schätzung die Grundlage für die Auswahl der Anforderungendarstellt. Einen effektiveren, iterativen Ansatz beschreibt Pichler: Dabei iteriertdas Team, bei der wichtigsten Anforderung beginnend, durch das Product Back-log und bewertet das Element. Dieses wird, solange Kapazität verfügbar ist, indas Sprint Backlog aufgenommen. (Vgl. [Schwaber 2004, S.133f.], [Pichler 2007,Kap.6.4])

Der ScrumMaster unterstützt das Team bei der Anwendung kollaborativer Ent-scheidungsverfahren. Dabei soll jeder in dem Maße Mitspracherecht haben, wie ervon den Auswirkungen der Entscheidung betroffen ist. Ein solches Verfahren zur



3.3 Prozess

realistischen Schätzung von Aufwänden ist Planning Poker. Hierbei erhält jedesTeammitglied in der Sprint-Planungssitzung einen Stapel Karten, auf denen meistdie Zahlen der Fibonacci-Folge7 dargestellt sind. Pichler empfiehlt dieses Ver-fahren ausdrücklich und schlägt vor, aus Karteikarten Stapel von Planning PokerKarten selbst anzufertigen. Nachdem das Team die Anforderung und die Aktivi-täten analysiert hat, legt jeder eine Karte entsprechend dem von ihm veranschlag-ten Aufwand verdeckt auf den Tisch. Diese Karten werden gleichzeitig aufgedeckt.Dieses Verfahren hat den Vorteil, dass Abweichungen sichtbar werden. Bei einerDiskussion, in der reihum jeder einen Aufwand schätzt, werden Teammitgliedervon Vorrednern in ihren Entscheidungen beeinflusst (beispielsweise vom SeniorDeveloper, der erläutert, wie einfach eine Aufgabe sei). Planning Poker hingegenoffenbart die unvoreingenommene Schätzung eines jeden. Große Abweichungen,nach oben wie nach unten, werden im Anschluss diskutiert. Der Schätzwert istdann ein Konsens aller Teammitglieder. (Vgl. [Pichler 2007, S.58ff])

Daily Scrum Meeting

Das Daily Scrum Meeting ist mit einer strikt begrenzten Dauer von fünfzehnMinuten das kürzeste Meeting im Scrum Prozess. Gleichwohl ist es in zweierleiHinsicht das wichtigste: Es dient, wie kein zweiter der in Scrum beschriebenencollaboration points, der Sozialisation und der Synchronisation des Teams. Auf-grund der hohen Frequenz dieser Treffen lernt sich ein neu zusammengestelltesTeam schneller kennen. Das Daily Scrum dient als Forum, in dem das TeamEntwicklungsschritte abgleicht ([Schwaber 2004, S.26]).

Die Daily-Scrum-Besprechung wird täglich zur selben Zeit und am selben Ortdurchgeführt. Teilnehmer sind der ScrumMaster, wie in der Sprint-Planungssitzungals Moderator, und alle Teammitglieder. Die Anwesenheit des Product Ownersist optional, dient aber dem Product Owner selbst am meisten, da er aus ersterHand vom Status des Sprints erfährt. Die Teammitglieder sind selbst verantwort-lich und berichten daher nicht dem ScrumMaster oder dem Product Owner. JedesTeammitglied beantwortet drei Fragen:

7Fibonacci-Folge: 0, 1, 1, 2, 3, 5, 8, 13 ... Eine Zahl der Folge ist stets die Summe beiderunmittelbarer Vorgänger.



3 Scrum

Abbildung 3.4: Aktivitätsdiagramm des Daily Scrum Meetingsund der täglichen Arbeit

â Was habe ich bezüglich des Projekts seit dem letzten Daily Scrum getan?â Was plane ich bezüglich des Projekts bis zum nächsten Daily Scrum?â Was hindert mich daran, so effektiv wie möglich zu arbeiten?([Schwaber 2004, S.104, S.135f.])

Die Daily-Scrum-Besprechung ermöglicht Transparenz der Status von Aufgabenund bestehender oder aufkommender Hindernisse. Der ScrumMaster muss jeder-zeit für die Beseitigung dieser Hindernisse einstehen. Das Daily Scrum erfüllt alsoin nur fünfzehn Minuten visibility-, inspection- und adaptation-Aspekte.

Anmerkungen

Das Daily Scrum Meeting wird am besten zu Beginn des Arbeitstags gehalten,um die Arbeit des Vortags zu resümieren und die Aufgaben des angebrochenenTages abzustimmen. (Vgl. [Schwaber 2004, S.135], [Pichler 2007, S.104])

Die Formulierung der Fragestellungen variiert bei Pichler. Die erste Frage be-zieht sich bei ihm auf abgeschlossene Aktivitäten, resultierend aus seiner Begren-zung einer Aufgabe auf einen Nettoarbeitstag. Die dritte Frage lautet: „Werde ichin irgendeiner Form an der Ausführung einer Aktivität behindert?“ Dies beziehtsich auf die generelle Ausführung der Aktivität. Schwaber hingegen versuchtmit der Formulierung jedwede Verbesserungsmöglichkeit aufzudecken. ([Schwa-ber 2004, S.135], vgl. [Pichler 2007, Kap.6.6])

Ein simples Beispiel soll die Relevanz dieser Nuance aufzeigen: Ein Entwicklermuss Module, die für seine Aufgabe wichtig sind, aus einem Remote Repository



3.3 Prozess

auschecken. Zeitgleich laufen an anderer Stelle Downloads, die zu Lasten derBandbreite gehen. Der Checkout der Module funktioniert zwar und behindertden Entwickler nicht an der Ausführung seiner Aktivität. Allerdings könnte derCheckout ohne die parallelen Downloads wesentlich schneller gehen, hindert alsoden Entwickler daran, so effektiv wie möglich zu arbeiten.

Trotz seiner Bedeutsamkeit ist das Daily Scrum Meeting eine der Schwächendes Scrum Prozesses, sobald Teammitglieder nicht Vollzeit für das Projekt ar-beiten. Fehlende Synchronisation mit einem Teilzeit-Teammitglied beeinträchtigtdie Transparenz des Projektfortschritts. Werden Mitarbeiter in mehreren Teamsbenötigt, haben sie mehrere Daily Scrum Meetings täglich, was ihre effektive Ar-beitszeit – je nach Anzahl der Projektbeteiligungen – stark einschränkt. Um dievisibility dennoch zu gewährleisten, empfiehlt es sich, Paararbeiten mit einemVollzeit-Mitarbeiter zu organisieren. Dieser kann das Ergebnis der Paararbeit imDaily Scrum kundtun, so dass die Teilzeitkraft nicht mehr in jedem Meetinganwesend sein muss. Wo Paararbeit nicht möglich ist, werden andere Möglichkei-ten der Synchronisation, wie z. B. Dokumentation benötigt, die aber in Einarbei-tungsaufwänden resultieren. Der Vorteil des Scrum Prozesses, Verschwendung zureduzieren, ist also in vollem Umfang nur bei Vollzeitarbeit der Projektbeteiligtengegeben. (vgl. [Pichler 2007, S.16f.])

Sprint Review Meeting

Am Ende eines jeden Sprints findet das Sprint Review Meeting statt. Es darfnicht länger als vier Stunden dauern. Die Teilnahme des Teams, des ProductOwners und des ScrumMasters ist verbindlich. Zweck des Sprint Reviews ist,dem Product Owner und eventuell anwesenden Interessenvertretern fertige, alsopotenziell lieferbare Funktionalität zu demonstrieren. ([Schwaber 2004, S.137], siehe 3.2[Pichler 2007, S.107])

Das Sprint Review Meeting beginnt mit der Erläuterung des Sprint-Ziels. DieElemente des Product Backlogs, zu deren Umsetzung sich das Team verpflichtethatte, werden aufgeführt. Im Anschluss daran führt das Team die Anforderungenvor, die umgesetzt wurden. Dabei ist es Stakeholdern jederzeit gestattet, Kom-mentare oder Kritik bezüglich des gelieferten Produktinkrements zu äußern. Ge-



3 Scrum

Abbildung 3.5: Aktivitätsdiagramm des Sprint Review Meetings

meinsam mit dem Product Owner identifizieren sie Funktionalität die nicht, odernicht wie gewünscht geliefert wurde. Für den Inhalt der Demonstration geltenzwei Regeln:

â Nicht funktionelle Arbeitsergebnisse dürfen nicht gezeigt werden, wenn sienicht zum Verständnis der Funktionalität notwendig sind.â Anforderungen, die nicht zu 100% fertig gestellt und frei von Bugs sind, geltenals nicht erledigt.

Die Demonstration muss darüber hinaus auf einer Umgebung, die dem vorgese-henen Umfeld der Software am nächsten kommt, vorgenommen werden.

Das Sprint Review Meeting macht den Fortschritt auf Projektebene sichtbar. Dasvorliegende Produktinkrement wird geprüft. Neben diesem manuellen Test kannder Product Owner im Sprint Review auch die Ergebnisse automatischer Testseinsehen. Im Sprint Review erfolgt also auch Teil des Qualitätsmanagements imScrum Prozess. Änderungswünsche von Stakeholdern oder nicht erfüllte Anforde-rungen resultieren in Anpassungen des kommenden Sprint-Ziels. (Vgl. [Schwaber2004, S.137f.], [Pichler 2007, Kap.6.7])

Anmerkungen

Da das Sprint Review ein collaboration point ist, gilt es darauf zu achten, dass essich nicht zu einer Präsentation entwickelt. Alle Beteiligten sind gefordert. Wenndas Team zu Hilfsmitteln wie Powerpoint-Präsentationen greift oder Product Ow-ner und Stakeholder – einem Publikum gleich – schweigend der Vorführung des



3.3 Prozess

Teams beiwohnen wird das der Bestimmung des Sprint Reviews nicht gerecht.Es ist eine gemeinsame Beurteilung dessen, was das Team umgesetzt hat. DasTeam arbeitet als Einheit und soll als solche angesehen werden. Einen Mitarbei-ter durch Lob oder Kritik herauszustellen ist nicht zielführend. Hat das TeamAnforderungen nicht erfüllt, beispielsweise aufgrund von ungenauen Schätzun-gen, ist dies kein Grund für Verurteilungen. Das Wort Schätzung entschuldigt dasTeam bereits. Eine Schätzung ist nie hundertprozentig genau. Applaus ist ebensounangebracht wie Verurteilungen, da er in der Regel vom Team persönlich auf-genommen wird. Es wird also künftig wiederum nach Applaus streben und seinAusbleiben als Kritik empfinden. Das menschliche Streben zu gefallen beeinflusstSchätzungen genauso wie die Angst, nicht zu gefallen. Inhaltliche Konsequenzentreten dabei angesichts persönlicher Interessen oder Ängste in den Hintergrund.Daher erreicht ein Team nach einer Verurteilung im Sprint Review im ExtremfallSchätzgenauigkeit durch nachlassende Qualität. Abschließende Tests wegzulas-sen, spart beispielsweise die Zeit ein, die andernfalls über die geschätzte Zeithinausgehen würde. (Vgl. [DeMarco 1998, S.26ff.], [Schwaber 2004, S.73, S.113f.],[Schwaber 2006])

Mitarbeiter, die nur Teilzeit an einem Projekt arbeiten, sollen am Sprint Plan-ning und am Sprint Review Meeting teilnehmen. So können sie die Planung einesSprints beeinflussen und erleben die Prüfung des Produktinkrements durch denProduct Owner ([Pichler 2007, S.17]). Arbeiten diese Mitarbeiter jedoch in meh-reren Teams, ist dies nicht immer möglich, da sich die Meetings verschiedenerProjekte überschneiden können. Darüber hinaus ist es aus Gründen der Effizienznicht sinnvoll, die Anwesenheit eines Teilzeit-Teammitglieds in den genanntenMeetings mehrerer Projekte vorauszusetzen: Im Falle zweiwöchiger Sprints dau-ern beide Meetings zusammen einen Arbeitstag (von maximal zehn). Die Meetingsjedes weiteren Projekts reduzieren also die effektive Arbeitszeit des Mitarbeitersum je zehn Prozent. Scrum schreibt nicht explizit vor, nur Vollzeit-Mitarbeiteram Projekt arbeiten zu lassen. Die gleichzeitige Beteiligung einzelner Teammit-glieder an mehreren Projekten ist jedoch nicht vorgesehen. Ob sich dies in derPraxis tatsächlich immer durchsetzen lässt, ist fraglich. Für Teilzeit-Arbeit liefertScrum grundsätzlich keine zufriedenstellende Lösung.



3 Scrum

Sprint Retrospective Meeting

Dem Sprint Retrospective Meeting kommt bezogen auf den Prozess, den Arbeits-ablauf, ähnliche Bedeutung zu wie dem Sprint Review für die Arbeitsergebnisse.Es findet ebenfalls am Sprint-Ende statt und dient der Untersuchung des ScrumProzesses im vergangenen Sprint mit dem Ziel, selbigen im kommenden Sprintanzupassen und zu verbessern.

Abbildung 3.6: Aktivitätsdiagramm des Sprint Retrospective Meetings

An der Sprint-Retrospektive nehmen der ScrumMaster und das Team teil. DerScrumMaster hat wie in den zuvor geschilderten collaboration points die Auf-gabe eines Moderators. Er verantwortet die Effektivität der Sitzung und sorgtfür die Einhaltung der Regeln des Miteinanders. Die Sprint-Retrospektive ist aufmaximal drei Stunden begrenzt. (Vgl. [Pichler 2007, S.111f.], [Schwaber 2004,S.138f.]))

Jedes Teammitglied beantwortet zu Beginn des Meetings zwei Fragen:

â Was war im letzten Sprint gut?â Was kann im nächsten Sprint verbessert werden?(Vgl. [Schwaber 2004, S.138])

Empfehlungen

Da die Sprint-Retrospektive direkt im Anschluss an das Sprint Review stattfindet,empfiehlt Pichler eine weitere Frage voran zu stellen:

â Wie fühle ich mich gerade?

Die Eindrücke des Sprint Reviews sind noch präsent. Jeder der Anwesenden be-kommt nun ein Gefühl davon, wie es den anderen gerade geht. Erst nach einemguten Einstieg in die Retrospektive wird begonnen, positive und negative Erleb-nisse des vergangen Sprints zusammen zu tragen. Diese sollten priorisiert werden,



3.3 Prozess

da eventuell nicht alle Probleme intensiv diskutiert werden können. In diesem Fallwird nach Dringlichkeit vorgegangen.(Vgl. [Pichler 2007, Kap.6.8])

Die Anwesenheit des Product Owners ist optional, aber empfehlenswert, damit erdie Notwendigkeit der erarbeiteten Verbesserungsmöglichkeiten besser versteht.Um nicht in etlichen Retrospektiven lediglich Symptome eines Problems zu be-kämpfen, analysiert Pichler die Ursachen mittels der Five Whys nach [Derbyund Larsen 2006]. Dabei wird rekursiv nach dem Warum eines Problems gefragt,bis seine Grundursache (root cause) gefunden ist. Hier setzen dann gemeinsam er-arbeitete Verbesserungsmaßnahmen an. (Vgl. [Pichler 2007, Kap.6.8], [Schwaber2004, S.138f.])

Aufwandsschätzungen und Releaseplanung

Wenngleich der Scrum Prozess weder abstrakte Aufwandsschätzungen noch eineReleaseplanung durch Ermittlung der Entwicklungsgeschwindigkeit vorschreibt,ist das Verständnis dieser Praktiken relevant für die folgenden Kapitel dieserArbeit.

Pichler verwendet story points um Aufwände zu schätzen. Dies sind nach Cohn

relative Größen, deren Maß in Zeiteinheiten für jedes Team unterschiedlich ist.Die Verwendung von story points ermöglicht es, Aufwände zueinander in Bezie-hung zu setzen. Dafür bieten sich Zahlen der Fibonacci-Folge an. Ein Aufwandlässt sich dabei immer als die Summe der beiden nächstkleineren Aufwände dar-stellen. Das Team kann so zuerst einige kleine Anforderungen schätzen, um imAnschluss weitere Elemente in Relation zu diesen zu beurteilen. Im Gegensatzzu absoluten Schätzungen in Zeiteinheiten ist dieses Verfahren eine relative (oderabstrakte) Schätzung. Es toleriert Ungenauigkeiten in der Schätzung, indem esdie Teammitglieder von dem Zwang befreit, sich bspw. zwischen einem Aufwandvon 8 und 9 zu entscheiden. (Vgl. [Pichler 2007, S.58f.])

Ein weiterer Vorteil ist, dass die Komplexität einer Anforderung vom zeitlichenAufwand ihrer Umsetzung entkoppelt wird. Es wird also nicht mehr die ver-bleibende Zeit, die sich ändern kann, sondern der konstante, verbleibende Weggeschätzt. (Vgl. [Pichler 2007, S.58], [Cohn 2004, S.87ff.])



3 Scrum

Auf der den Sprints übergeordneten Ebene, der Releaseebene, bietet Scrum Trans-parenz und permanenten Überblick über den Projektfortschritt. Bereits nach demersten Sprint basieren die Entscheidungen des Product Owners nicht mehr aufden Schätzungen des Teams sondern auf dem, was dieses tatsächlich erreicht hat([Schwaber 2004, S.112f.]). Der Product Owner kann empirisch die Entwicklungs-geschwindigkeit (velocity), also die Anzahl an story points, die in einem Sprintumgesetzt wurden, bestimmen:

velocity =story points

sprints

Pichler legt nahe, die Durchschnittsgeschwindigkeit der ersten zwei bis dreiSprints zu ermitteln.8 Werden nun in Zusammenarbeit mit dem Team die Auf-wände aller Einträge im Product Backlog geschätzt, kann nach derselben Formeldie Zeit bis zur Fertigstellung des gesamten Product Backlogs ermittelt werden:

sprints =story points

velocity

Den Zusammenhang zwischen offenen und fertig gestellten Anforderungen undder Entwicklungsgeschwindigkeit visualisiert ein Burndown Chart. Nach [Scr 2008]gilt dieses in Scrum als weiteres Artefakt. Es ist jedoch vielmehr eine andere Sichtauf das jeweils aktuelle Product- und Sprint Backlog und wird daher in der vor-liegenden Arbeit gesondert erläutert. Schwaber nennt das Burndown Chart imZusammenhang mit dem Product Backlog die „collision of reality [...] with whatis planned“. Ein Burndown Chart veranschaulicht den Projektfortschritt, indemder Verlauf der Restaufwände an einer Zeitachse abgebildet wird. Dies kann ent-weder für ein ganzes Release geschehen wie in Abbildung 3.7 oder in Form einesSprint Burndown Charts, das für genau einen Sprint gilt. Im ersten Fall empfiehltsich die Einteilung der Zeitachse in Sprints. Soll nur ein Sprint betrachtet wer-den, stellt die Zeitachse die Arbeitstage dieses Sprints dar. (Vgl. [Pichler 2007,S.63ff., S.117], [Schwaber 2004, S.11])

Die Entwicklungsgeschwindigkeit des in Abbildung 3.7 visualisierten Projektsbeträgt konstant 20 story points pro Sprint. Nach dem dritten Sprint fügt der Pro-

8Alternativ zur empirischen Ermittlung der velocity kann sie historisch (mit Daten von abge-schlossenen Projekten desselben Teams) oder spekulativ (risikoreiche Schätzung) ermitteltwerden.



3.3 Prozess

Abbildung 3.7: Release Burndown Chart nach [MGS 2008]

duct Owner Anforderungen im Umfang von 30 story points hinzu. Um zwischendem ursprünglichen Planaufwand und den Änderungen unterscheiden zu können,werden letztere unter der X-Achse dargestellt. Im vierten Sprint schafft das Teamwiederum Anforderungen mit Aufwänden von 20 story points. Der Product Ow-ner verzichtet auf Anforderungen, die auf fünf story points geschätzt wurden. Sobleiben zu Beginn des fünften Sprints 40 story points aus ursprünglichen, sowiefünf aus zusätzlichen Anforderungen. (Vgl. [MGS 2008])

Hier wird ein weiterer Vorteil abstrakter Schätzungen offenbar: Die für eine Auf-gabe aufgewandte Zeit sagt nichts über den Fertigstellungsgrad der Aufgabe aus,da sich die verbleibende Zeit bis zur Fertigstellung stets verändern kann. Diesemals 80-20-Problem9 bekannten Phänomen können absolute Schätzungen mit zeit-lichen Puffern begegnen. Solange diese Puffer sich jedoch nicht aus den Erfahrun-gen der vergangenen Sprints errechnen, lässt die Planung mittels Entwicklungs-geschwindigkeit genauere Schlüsse auf den potenziellen Fertigstellungstermin zu.(Vgl. [Pichler 2007, Kap.5.5])

Eine Fortschrittslinie – der ideale Burndown – verdeutlicht Verzögerungen oderschnelleren Fortschritt. Dazu wird eine Linie von der Summe der Aufwände amSprint- oder Releasebeginn bis zu deren Ende auf der X-Achse gezogen. Der Ver-lauf des idealen Burndowns entspricht exakt der geplanten Entwicklungsgeschwin-

9Auch Pareto-Prinzip genannt: Demnach lösen Aufgaben mit einem Aufwand von 20% bereits80% der Probleme, was im Umkehrschluss bedeutet, dass die restlichen 20% der Probleme80% der Arbeit verursachen. (Vgl. [Oestereich und Weiss 2008, S.423])



3 Scrum

digkeit, also der Summe der Aufwände, die im aktuellen Sprint oder Projekt fertiggestellt werden sollen. (Vgl. [Pichler 2007, S.70f.])

Ein Sprint Burndown Bericht ist analog aufgebaut, basiert jedoch auf den Rest-aufwänden der Aktivitäten im Sprint Backlog. Das Sprint Burndown Chart of-fenbart dem Team jederzeit, ob der Sprint-Fortschritt schneller (Restaufwändeunter dem idealen Burndown) oder langsamer ist, als vorgesehen. (Vgl. [Pichler2007, S.117f.])



4 Projektron BCS

Die Lösung ist immer einfach,

man muss sie nur finden.

(Alexander Solschenizyn)

Dieses Kapitel wird als Teil der Ist-Analyse Projektron BCS vorstellen. Dazuwird die Inventurmethode, die im Wesentlichen Dokumente analysiert, verwendet([Krallmann u. a. 2002, S.65f.]). Die Funktionen der Software werden in Bezugauf die Wissensgebiete des Projektmanagements erläutert. Die Architektur der siehe 2.1Software wird beschrieben und die hohe Anpassbarkeit wird an einem Beispielgeschildert. Informationen über die Projektron GmbH und die von ihr entwickelteSoftware Projektron BCS stammen von der Internetpräsenz des Unternehmens[Projektron].

Die Projektron GmbH wurde 2001 gegründet. Neben der kontinuierlichen Wei-terentwicklung der Projektmanagement-Software Projektron BCS bietet die Pro-jektron GmbH Dienstleistungen rund um die Einführung, Integration und Erwei-terung ihres Softwareprodukts. Im Hauptsitz Berlin und weiteren Büros in Mün-chen, Hamburg, Bonn, Leipzig und Karlsruhe beschäftigt die Projektron GmbHinsgesamt mehr als 40 Mitarbeiter.

Über 200 Kunden aus Deutschland, Italien, Luxemburg, Holland, Österreich undder Schweiz, darunter IT-Unternehmen, Beratungs- und Forschungseinrichtun-gen, Entwicklungsabteilungen der Industrie sowie öffentliche Einrichtungen, set-zen Projektron BCS ein.



4 Projektron BCS

4.1 Funktionen

In der Standardkonfiguration gibt es die Arbeitsbereiche Mein BCS, Zeiterfas-sung, Projekte, Intern, Extern und Administration (Abbildung 4.1). SämtlicheFunktionen der Software sind einem dieser Arbeitsbereiche zugeordnet. Der Be-reich Mein BCS dient der persönlichen Arbeitsorganisation. Hier werden Termi-ne, Notizen und Lesezeichen aufgeführt. Möglichkeiten zur Erfassung der eigenenArbeitszeit sowie Übersichten der eigenen Aufgaben und verschiedene Auswer-tungen sind dem Arbeitsbereich Zeiterfassung zugeordnet. Die Bereiche Internund Extern dienen dem Personal- und Kontaktmanagement. Unter Administrati-on werden Nutzer und Lizenzen, sowie Zugriffsrechte verwaltet. Projekte werdenim gleichnamigen Bereich geplant, überwacht und gesteuert.

Abbildung 4.1: Arbeitsbereiche in Projektron BCS

Projektplanung: Sowohl beim Erstellen als auch beim Bearbeiten eines Pro-jekts bietet Projektron BCS Unterstützung durch einen Assistenten. Dessen Schrit-te sind in Abbildung 4.2 hervorgehoben. Für das Verständnis dieser Arbeit nichtrelevante Schritte des Assistenten werden nicht näher erläutert.

Abbildung 4.2: Projektron BCS Projektassistent



4.1 Funktionen

Im ersten Schritt werden Name, Beschreibung und Projektlaufzeit, die Stamm-daten eines Projekts erfasst. Hier erfolgt weiterhin die Entscheidung für einProjektplanungsmodell. Zur Auswahl stehen Bottom-up-Planung und Top-Down- siehe 2.2Planung, sowie ein Modell „Großes Projekt“, das beide Planungsmodelle kombi-niert. Die Anzahl der weiteren Schritte des Assistenten sind vom Planungsmodellabhängig. Durch die Verwendung von Projektvorlagen kann in Schritt Drei einedurch komplexe Zeit-, Kosten- und Aufwandspläne möglicherweise sehr umfang-reiche Projektplanung beschleunigt werden.

Der Strukturplan (Schritt Vier), in dem Projekte in Unterprojekte, Arbeitspa-kete und Aufgaben unterteilt werden, wird in Abbildung 4.2 gezeigt. Es istmöglich, beliebig tief verzweigte Projektstrukturen anzulegen. Inhalts- und Um-fangsmanagement wird dadurch auf mehreren Hierarchieebenen unterstützt. Einezeitliche Terminierung der genannten Strukturelemente kann im fünften Schritt,der Zeitplanung vorgenommen werden.

Ressourcenmanagement: Aufteilung und optimale Auslastung sämtlicher fürdie Projektarbeit benötigter Ressourcen (z. B. Arbeitskräfte, Werkzeuge) sindAufgabe und Ziel des Ressourcenmanagements ([Angermeier 2005]).

Mitarbeiter haben ein bestimmtes Arbeitszeitmodell und individuelle Fähigkei-ten (skills). Beides muss in der Projektplanung berücksichtigt werden. ProjektronBCS ermöglicht Skillmanagement (als Teil des Ressourcenmanagements), indeman Mitarbeitern ein Qualifikationsprofil mit diversen Informationen hinterlegtwerden kann. In Schritt Sechs des Assistenten, der Teamplanung, werden denStrukturelementen des Projekts Mitarbeiter zugewiesen. Dabei kann unter ande-rem nach skills gefiltert werden.

Die geplanten Aufwände je Strukturelement können im siebten Schritt, dem Auf-wandsplan, erfasst werden.

Die Verwaltung der Urlaubs- und Arbeitszeit von Mitarbeitern beeinflusst eben-falls die Projektplanung. Im Schritt Acht, der Ressourcenauslastung, wird dieaktuelle Auslastung der Mitarbeiter ermittelt. Ein Projektleiter sieht die verfüg-bare Kapazität der Projektbeteiligten und kann so rechtzeitig Ressourcenengpässeerkennen. Dies ist auch im Projektverlauf möglich. Ressourcenknappheit durchgestiegene Restaufwände ist jederzeit ersichtlich.



4 Projektron BCS

Projektron BCS bietet ressourcentreue Terminplanung, die es ermöglicht, ein Pro-jekt oder seine Strukturelemente zeitlich an der Verfügbarkeit der Mitarbeiterauszurichten.

Qualitätsmanagement: Projektspezifische Dokumente werden in einer Datei-ablage direkt an Projekten oder deren Teilen abgelegt. Dateiablagen können imzehnten Schritt des Assistenten oder auch im Projektverlauf angelegt werden.Die zentrale Definition der Verzeichnisse mittels Vorlagen führt zu einer einheit-lichen projektübergreifenden Verzeichnisstruktur und unterstützt auf diese Weisedas Dokumentenmanagement. Die Erstellung von Dokumentenvorlagen dient demQualitätsmanagement durch prozesskonforme Dokumentation.

Über Verlaufsprotokolle und Prozess-Workflows können Entscheidungsprozesse,Genehmigungsverfahren und Vorgänge zur Qualitätssicherung abgebildet wer-den.

Zeiterfassung: Die Arbeitszeiten und damit die Aufwände der Projektmitar-beiter für eine Aufgabe werden direkt auf Aufgaben gebucht. Durch die Erfassungvon Restaufwandschätzungen wird Projektleitern jederzeit ermöglicht, sowohl denFortschritt von Aufgaben einzusehen als auch festzustellen, ob die potenziell be-nötigte Zeit über die vorgesehene Zeit hinausgeht. Je nach Genauigkeit der Schät-zungen ist so ein optimales Terminmanagement gewährleistet.

Projektcontrolling: Durch die Möglichkeit, auf jeder Ebene der Projektstruk-tur verschiedene Auswertungen durchzuführen, wird umfangreiches Projektcon-trolling unterstützt. Eine Ampelfunktion ermöglicht dabei eine schnelle Identifi-zierung zeitlicher und finanzieller Budgetüberschreitungen und beugt so Projekt-risiken vor. Dabei wird im Rahmen des Kostenmanagements zwischen Personal-und Sachkosten unterschieden.

Ticketsystem: Das Ticketsystem verwaltet an Projekten und Aufgaben Tickets.Dabei handelt es sich um Anmerkungen, die von Teammitgliedern oder exter-nen Projektbeteiligten erstellt werden können. Es wird zwischen verschiedenen



4.2 Architektur

Ticketarten, z. B. Fehlermeldungen (bug-reports) oder Änderungswünschen (change-requests), unterschieden. Tickets haben im Unterschied zu Strukturelementen kei-nen Zeitbezug, also kein Start- und Enddatum.

Rechteverwaltung: Aus der Struktur eines Unternehmens resultieren firmen-spezifische Rollen und Funktionen, die mit der Rechteverwaltung abgebildet wer-den können. Auf diese Weise werden Mitarbeitern Rollen zugeordnet, deren Zu-griffsrechte auf Daten oder Aktionen entsprechend verfügbar oder eingeschränktsind. Im Rahmen des Projektron BCS Lizenzmodells sind die Rollen und Funktio-nen dabei frei konfigurierbar. So können Projektleiter eine grobe Projektstrukturvorgeben und die Detailplanung der Unterprojekte den jeweiligen Unterprojekt-leitern überlassen.

Weitere Funktionen: Der Auftragsplan dient der Budgetierung des Projekts.Über die dort definierten Auftragspositionen können durch das FakturamodulRechnungen erstellt werden. Vertrags- und Kontaktmanagement gewährleistenBeschaffungs- und Kommunikationsmanagement. Die Angebotserstellung rundetden Funktionsumfang von Projektron BCS ab.

4.2 Architektur

Die in Abbildung 4.3 dargestellte Architektur von Projektron BCS entsprichteinem Client-Server-Modell. Als Benutzeroberfläche dient ein Webbrowser, dermit einer Servlet-Engine kommuniziert. Die dort laufende BCS Webapplikationkommuniziert wiederum mit dem BCS Server, der die Eingaben des Benutzersverarbeitet. Der BCS Server ist für die Anbindung der Datenbanken zuständig.

Der Clientbetrieb einer browserbasierten Software wie Projektron BCS ist in na-hezu jeder Umgebung möglich. Der Serverbetrieb erfordert die Unterstützung deroffenen Standards Sun Java J2SE 5.0, Servlet API 2.4, JSP 2.0, SQL-92, HTML4.01, CSS 2.0 und JavaScript 1.5/DOM 1.0 und ist unter dieser Bedingung eben-falls plattformunabhängig.

Ein weiterer Aspekt, der die Integration von Projektron BCS in bestehende IT-Umgebungen begünstigt, ist die Bereitstellung zahlreicher Schnittstellen, z. B. zu



4 Projektron BCS

Abbildung 4.3: Aufbau einer Projektron BCS Installation,Quelle: Projektron BCS 6.4 Installationshandbuch 1.0, S.7

Microsoft Exchange und SAP, sowie individuell konfigurierbarer Import- und Ex-portmöglichkeiten unter anderem per CSV und XML.

Der Aufbau der Benutzeroberfläche von Projektron BCS ist in Abbildung 4.4dargestellt. Jeder Arbeitsbereich hat eine eigene Seite. Diese Seiten enthaltenverschiedene Ansichten, im Beispiel die Stammdaten eines Projekts, die wiederumin zwei Modi (display und edit) aufgerufen werden können. Die Abbildung zeigtden Bearbeitungsmodus, daher ist das aktuelle Element ein Formular. WeitereElemente sind Detail-, Listen- und Baumansichten.

Projektron BCS verwaltet Daten mit Objekten wie z. B. Projekten, Aufgaben,siehe A.1Organisationen und Personen. Attribute bestimmen die Eigenschaften dieser Ob-jekte. Weiterhin können Objekte Subtypen haben, die die Sichtbarkeit von At-tributen einschränken und so das Objekt genauer definieren. So hat das ObjektProjekt unter anderem die Subtypen Unterprojekt und Vorlage. Die komplet-te Datenstruktur kann im Arbeitsbereich Administration eingesehen werden, einAuszug ist in Anhang A.1 aufgeführt.

Welche Daten in einem Attribut gespeichert werden können und wie diese in derBenutzeroberfläche dargestellt werden, ist vom Datentyp des Attributs abhängig.Projektron BCS verwendet unter anderem die Datentypen Int für numerischeWerte und String für Text, der dann in einzeiligen Textfeldern dargestellt wird.Attribute mit dem Datentyp Mail werden in der Oberfläche als mailto-Links



4.3 Flexibilität

Abbildung 4.4: Webseitenstruktur von Projektron BCS,Vgl. Projektron BCS 6.4 Administrationshandbuch 1.0, S.51

dargestellt. Der Datentyp Oid enthält die Objekt-ID (OID), die ein Objekt inProjektron BCS eindeutig identifiziert. An einem Objekt wird die eigene Identifi-kationsnummer textuell dargestellt (z. B. 14555_JUser). Enthält ein Attribut dieOID eines anderen Objekts, wird darauf mit dem Namen des Zielobjekts verlinkt.Ein Icon symbolisiert den Objekttyp.

4.3 Flexibilität

Projektron BCS bietet verschiedene Anpassungsmöglichkeiten. Generell wird zwi-schen zwei Arten von Anpassungen an der Software unterschieden:

â Administrative Änderungen per Konfigurationâ Komplexe Anpassungen, die Entwicklungsarbeit seitens Projektron erfordern

Sowohl die Präsentationslogik, die Webapplikation als auch die Anwendungslogik,der BCS Server, können per Konfiguration angepasst werden. Durch Stylesheets



4 Projektron BCS

kann die Benutzeroberfläche an das Corporate Design eines Kunden angepasstwerden. Alle in der Benutzeroberfläche gezeigten Texte (Label, Tooltips, Feh-lermeldungen) können umbenannt werden. Auch die vollständige Internationa-lisierung (internationalization, I18n10) von Projektron BCS ist auf diese Wei-se möglich. Die zeitliche Steuerung, das Scheduling, regelmäßig auszuführenderAufgaben, Jobs, erfolgt ebenfalls per Konfiguration. Ein Überblick der Konfigu-rationsdateien wird in Tabelle 4.1 geboten.

Bereich Dateiname(n)

BCS Server Serverconfig*.properties

BCS Webapplikation WebConfig.propertiesWebConfigEdit.xml

Label i18n*.properties

Dateiablage WebPath.properties

Jobs CronTools.propertiesSchedulerConfig.xml

Tabelle 4.1: Projektron BCS Konfigurationsdateien,Vgl. Projektron BCS 6.4 Administrationshandbuch 1.0, S.8

Das Beispiel in Listing 4.1 verändert sowohl die Datenstruktur als auch dieOberfläche von Projektron BCS und verdeutlicht so die Flexibilität der Software.Dem Subtyp project des BCS-Objekttyps JProject werden drei weitere Attri-bute hinzugefügt.

Listing 4.1: Beispieleintrag in einer ServerConfig*.properties-Datei1 Project.CustomAttributes=\2 Hochschule=String Fachbereich=Int Studiengang=String3 JProject.subtyp.attribs .project=\4 Hochschule Fachbereich Studiengang5 Project.CustomOptions=\6 Hochschule=Technische_Fachhochschule_Berlin \7 Studiengang=Medieninformatik,Technische_Informatik,Druck−_und_Medientechnik

Um diese Attribute auch in den Ansichten der Benutzeroberfläche anzuzeigen,wird der WebConfig-Editor verwendet. Abbildung 4.5 zeigt oben rechts, dassgerade die Seite „projectdetail“ im Modus „edit“ der Ansicht „main“ bearbeitet10Die 18 steht dabei für die Anzahl der gekürzten Buchstaben der englischen Schreibweise.



4.3 Flexibilität

wird. Das Element ist das Formular „default“. Diesem Element werden die dreiAttribute Hochschule, Fachbereich und Studiengang hinzugefügt. Die gleiche An-passung muss im Modus „display“ vorgenommen werden.

Abbildung 4.5: WebConfig-Editor zum Bearbeiten der GUI

Das Ergebnis dieser Konfiguration zeigt Abbildung 4.6. Die neuen Attributewerden mit den in Listing 4.1 definierten Optionen angezeigt. Zum Vergleich istdie komplette Ansicht ohne die Anpassungen in Abbildung 4.4 dargestellt. DieUnterstriche in den Attributnamen können anschließend durch Einträge in deri18n*.properties entfernt werden.

Abbildung 4.6: Zusätzliche Attribute eines Projekts

Neue Termintypen und Feiertage im Projektron BCS Kalender können auf ähn-liche Weise definiert werden. Über die Benutzeroberfläche werden Rollen undRechte, sowie Relationen konfiguriert.



4 Projektron BCS



5 Scrum bei der Hypoport AG

A good workman is known by his tools.

(Englisches Sprichwort)

Der zweite Teil der Ist-Analyse besteht aus der folgenden Vorstellung der Hy-poport AG und der Darlegung des Softwareentwicklungs- und des Scrum Pro-zesses innerhalb der Hypoport AG. Für die Ist-Aufnahme wurde in diesem Falldie Interviewmethode gewählt. Die Erfassung des gegenwärtigen Zustands basiertdaher auf offenen, nicht standardisierten Interviews mit Herrn Sebastian Heide,ScrumMaster, und Herrn Robert Gimbel, Projektmanager bei Hypoport. Wäh-rend dieser Interviews verfasste Notizen, sowie die als Abschluss der Ist-Aufnahmeerstellte Zusammenfassung und deren Korrektur durch die Interviewpartner sindin Anhang B aufgeführt. (vgl. [Krallmann u. a. 2002, S.66ff., S.80])

Die Hypoport AG11, mit Hauptsitz in Berlin ist ein Finanzdienstleister, der selbstFinanzprodukte vertreibt und darüber hinaus mit EUROPACE die größte deut-sche Internetplattform zum Abschluss von Finanzprodukten bereitstellt. Kun-den verwenden abhängig vom Geschäftsbereich bestimmte EUROPACE Elemente(Abbildung 5.1). Diese werden durch den EUROPACE Integrator verbunden.Verändert z. B. ein Kreditgeber online, also in Echtzeit, seine Konditionen, sowirkt dies unmittelbar auf Vertriebspartner. Diese sehen sofort die eventuell bes-seren Konditionen des Kreditgebers und fällen Entscheidungen aufgrund stetsaktueller Informationen.

Das Projektmanagement bei Hypoport erfolgt sowohl mit Projektron BCS alsauch mit JIRA12. Dabei hat sich die bug tracking-, issue tracking- und PM-Software der Firma Atlassian weitgehend durchgesetzt.11http://www.hypoport.de/12http://www.atlassian.com/software/jira/




Abbildung 5.1: Acht Elemente der Europace Plattform,Quelle: http://www.hypoport.de/

5.1 Prozess und Software-Anforderungen

Im Folgenden werden der Scrum Prozess der Hypoport AG geschildert und dieAnforderungen der einzelnen Schritte an die Softwareunterstützung hervorgeho-ben. Dabei wird der Begriff Strukturelement sowohl für JIRA-Tickets als auchfür Projektron BCS Strukturelemente und Tickets verwendet, also sämtliche Ele-siehe 4.1mente, die ein Projekt strukturieren.

Die Auftragsstruktur der Hypoport AG erfordert Anpassungen des Scrum Pro-zesses. Hypoport liefert nicht ein Softwareprodukt nach dem anderen, sondernReleases der Elemente des EUROPACE Produkts. Daher gibt es nicht ein ein-ziges Product Backlog, sondern eines je EUROPACE Element. Im Folgendenwerden diese Elemente „Produkt“ und deren Releases „Projekte“ genannt.

Aufgrund der durch externe Berater geförderten und bescheinigten guten Adapti-on des Scrum Prozesses besteht keine Notwendigkeit eines Vollzeit-ScrumMastersfür jedes Projekt. Momentan betreuen daher zwei ScrumMaster sämtliche Pro-jekte der Hypoport AG. Dies hat jedoch zwei offensichtliche Nachteile: Fällt einerder beiden ScrumMaster aus, kann es vorkommen, dass der zweite bis zu siebenDaily Scrum Meetings täglich hat. Darüber hinaus gerät ein ScrumMaster beider Beseitigung von Hindernissen in Entscheidungskonflikte, wenn seine Projekteoder deren Teams konkurrieren.




Die Hypoport AG arbeitet mit Releasezyklen von drei Monaten und einer Sprint-dauer von vier Wochen. Ein Projekt umfasst daher in der Regel drei Sprints.Refactoringprojekte, also Projekte, die keine neue Funktionalität liefern, sonderndie bestehende Struktur der Software umgestalten und verbessern, sind weitge-hend unabhängig von Kundenanforderungen. Daher kann die Dauer eines solchenProjekts über den normalen Releasezyklus hinausgehen.

In einem Team arbeiten fünf bis acht Mitarbeiter, die mit Projektron BCS ihreArbeitszeit erfassen. Überlastungen werden vermieden, indem in JIRA nur sechsStunden pro Tag für Projektaufgaben eingeplant werden. So wird gewährleistet,dass genug Zeit für Team-internen Wissensaustausch bleibt.

Software-Anforderungen:¬ Erfassung allgemeiner/projektbezogenener Aufwände Definition einer Grundlast

Da jedes Produkt bei etlichen Kunden im Einsatz ist, ergeben sich an ein Pro-jekt vielfältige, teilweise konträre Anforderungen. Das Anforderungsmanagement,dargestellt in Abbildung 5.2, ist weder komplett statisch noch vollkommen agil.Jeder Projektmanager ist für mehrere Kunden zuständig und erfasst und verwal-tet deren Anforderungen. Diese werden grob als Features13 formuliert und je Fea-ture wird ein Konzept erstellt. Die Projektmanager eines Produkts stellen danngemeinsam aus der Menge der Anforderungen aller Kunden das Product Backlogzusammen. In die Priorisierung der Anforderungen fließen dabei auch Ansprü-che des übergeordneten Managements ein: Anforderungen mit hohem Nutzen fürdie Hypoport AG (Business Value) werden höher priorisiert. Im weiteren Verlaufwerden Anforderungen in epics und user stories unterteilt und auf diese Weise siehe 3.2verfeinert. Die Aufgaben des im Scrum Prozess vorgesehenen Product Ownerswerden bei Hypoport von mehreren Projektmanagern erfüllt.

Die softwaregestützte Erfassung der Anforderungen erfolgt in beiden genanntenTools:

In Projektron BCS werden die Features eines Projekts hierarchisch nach Kundengeordnet. Abbildung 5.3 zeigt auszugsweise, wie der Strukturplan eines Projekts

13Die Hypoport AG praktiziert kein Feature Driven Development (FDD). Der Begriff Featurewird in seiner allgemeinen Bedeutung „Funktion“ verwendet.




Abbildung 5.2: Aktivitätsdiagramm der Anforderungserhebung eines Projektsder Hypoport AG

der Hypoport AG aussehen könnte. Den Unterprojekten, die besagte Features re-präsentieren, werden dabei die entsprechenden Ticketnummern in JIRA vorange-stellt. Um Zeiterfassung und Abrechenbarkeit zu gewährleisten, werden pro Fea-ture je eine Entwicklungs-, Test- und Projektmanagementaufgabe erstellt. Einedetaillierte Projektplanung mit genauer festgelegten Vorgängen oder gar Meilen-steinen erfolgt nicht. Stattdessen wird durch die direkte Zuordnung der Featureszu Kunden eine übergeordnete Managementsicht dargestellt, die die Rechnungs-stellung der Features ermöglicht.

Abbildung 5.3: Projektron BCS Strukturplan eines Hypoport-Projekts

Software-Anforderungen:® Zuordnung von Kunden zu Strukturelementen¯ Product Backlog als priorisierte Strukturelement-Liste




In JIRA hingegen wird das Product Backlog eines Projekts produkt- und funkti-onsbezogen abgebildet. Tabelle 5.1 stellt die Hierarchie der Tickets dar.

feature â Neue oder verbesserte FunktionÕ epic â Noch ungenaue oder zu große Teilfunktion

Õ user story â Detaillierung oder Teil eines epicsÕ Akzeptanztest â Verifizierung der vollständigen und fehlerfreien

Umsetzung einer user storyTabelle 5.1: JIRA Tickethierarchie der Hypoport AG

Während der JIRA Standard vier Ticketarten definiert, verwendet Hypoportmehr als dreißig Ticketarten, um Anforderungen zu klassifizieren. User storieswerden unter anderem in verbindliche (mandatory) und optionale Anforderungen,die den Kunden begeistern (exciter), unterteilt. Darüber hinaus gibt es mehrereArten von Akzeptanztests, die durchgeführt werden, sobald eine user story um-gesetzt wurde. Verschiedene Tests haben jeweils einen eigenen Lebenszyklus, alsospezifische Status mit vorgegebenen Statusübergängen. Zwei dieser Lebenszyklensind in Abbildung 5.4 dargestellt. siehe B.2

Software-Anforderungen:° Definition eigener Strukturelemente± Definition diverser Lebenszyklen für Strukturelemente

Um die iterative Verfeinerung von Anforderungen zu ermöglichen, können Ticketsin andere Ticketarten umgewandelt werden. Epics, die im Projektverlauf als de-tailliert genug erachtet werden, können so beispielsweise in user stories konvertiertwerden. JIRA protokolliert dabei jedwede Änderung und auch, wann und durchwen diese vorgenommen wurde.

Software-Anforderungen:² Umwandlungen zwischen Strukturelementen³ Protokollierung der Änderungen an Strukturelementen

Im Sprint Planning Meeting bestimmt das Team diejenigen der hoch priorisier-ten Anforderungen, die im kommenden Sprint umgesetzt werden. Der Status derentsprechenden Unterprojekte wird in Projektron BCS von „Geplant“ auf „Offen“gesetzt, damit die Aufgaben für Teammitglieder in der Zeiterfassung angezeigt




Abbildung 5.4: Lebenszyklen als Zustandsdiagramme nach [oose 2008]links: user stories, rechts: Akzeptanztests

werden. Das Sprint Backlog unterscheidet sich für Projektmanager in Projekt-ron BCS vom Product Backlog nur durch die Status der Strukturelemente. DieElemente, die den Status „Offen“ haben, bilden das aktuelle Sprint Backlog. DieErfassung von Aufwänden ist ausschließlich auf der Ebene von Unterprojekten,also Features, relevant. Daher spielt es keine Rolle, wie detailliert die Aufgabengeplant sind - Teammitglieder buchen dann Aufwände auf die Entwicklungs-,Test- und Projektmanagementaufgabe des Unterprojekts.

In JIRA ist jedes Ticket, dessen Umsetzung beschlossen wurde, also jeder Ein-trag des Sprint Backlogs, einem Mitarbeiter zugewiesen. Diese Zuweisung erfolgtbeim Anlegen des Tickets. Teammitglieder können jedoch Tickets jederzeit ande-ren Kollegen zuweisen. Auf diese Weise erfolgt die Aufgabenverteilung innerhalbdes Teams durch das Team. Weiterhin werden an jedem Ticket abstrakte Auf-wandsschätzungen mit story points verwaltet.siehe 3.3




Software-Anforderungen:´ Teaminterne Aufgabenzuweisungµ Abstrakte Aufwandsschätzungen

Die Bearbeitungsreihenfolge der Tickets ist durch die Priorisierung vorgegeben.Sofern es für die Bearbeitung sinnvoll ist, kann das Team jedoch einzelne Ticketsvorziehen.

ScrumMaster und Teams nutzen Projektron BCS ausschließlich zur Zeiterfassung.Die Aussagekraft aufgabenspezifischer Auswertungen ist aufgrund der Verwen-dung von je einer Entwicklungs-, PM- und Testaufgabe nur gering. Daher nutzenselbst Projektleiter von den zahlreichen Auswertungen, die Projektron BCS bie-tet, lediglich die Auswertung „Aufwände/Projekt“.

Bei Hypoport werden die im Scrum Prozess vorgesehenen Meetings wie beschrie-ben praktiziert. Aufgrund nur minimaler Abwandlungen der bereits aufgeführtenAktivitätsdiagramme dieser Meetings befindet sich die detaillierte Abbildung desScrum Prozesses der Hypoport AG in Anhang C.

Im Sprint Review Meeting demonstriert das Team den Projektleitern, sowie even-tuell anwesenden Kunden fertige Funktionalität, also solche, die sämtliche Akzep-tanzkriterien in entsprechenden Tests erfüllt hat. Effektive Sprint RetrospectiveMeetings liefern produktive Vorschläge zur Verbesserung der Prozesse. In DailyScrum Meetings stimmt das Team die tägliche Arbeit aufeinander ab.

Eine Anforderung, die nicht explizit von der Hypoport AG gefordert wird, aberals best practice bei der Anwendung von Scrum gilt, ist die Ermittlung der Ent-wicklungsgeschwindigkeit, der velocity, basierend auf der Verwendung abstrakterAufwandsschätzungen. Auf diese Weise kann prognostiziert werden, wie viel Zeitzur Umsetzung der verbleibenden Funktionalität benötigt wird.

Als zweite zusätzliche Anforderung wird die Visualisierung des Projekt- oderSprintfortschritts in einem Burndown Chart aufgenommen. Durch das Diagrammwird sofort ersichtlich, ob die Entwicklungsgeschwindigkeit des Teams höher oderniedriger ist, als geplant und ob das Projekt- oder Sprintziel in der vorgesehenenZeit erreicht werden kann. Ein ScrumMaster erkennt an einer niedrigeren velocity,dass eventuell Hindernisse existieren.




5.2 Vergleich der Anforderungen

mit Projektron BCS

Bei der Einführung der Software wurden sowohl die Projektplanung als auchdas Ticketsystem in Projektron BCS evaluiert, konnten sich jedoch gegen denEinsatz von JIRA nicht behaupten. Inwiefern der Grund in der unzureichendenErfüllung der Anforderungen durch eine frühere Version von Projektron BCSlag, kann nicht mehr nachvollzogen werden. Als zum Teil immer noch aktuellerGrund für die mangelnde Akzeptanz von Projektron BCS wurden Aspekte derBenutzerfreundlichkeit, wie die höhere Klick-Häufigkeit durch den Wechsel in denBearbeitungsmodus genannt.siehe 4.2

Im Folgenden werden die erfassten Anforderungen des Scrum Prozesses bei derHypoport AG an die Softwareunterstützung, aufgeführt in Tabelle 5.2, analy-siert. Dabei wird nachgewiesen, ob und wie diese Anforderungen durch ProjektronBCS in der Version 6.6.2.beta erfüllt werden. Der gegenwärtige Ist-Zustand beider Hypoport AG ist gleichzeitig der angestrebte Soll-Zustand für den Einsatzvon Projektron BCS.

Kernanforderungen

¬ Erfassung allgemeiner/projektbezogenener Aufwände

Definition einer Grundlast

® Zuordnung von Kunden zu Strukturelementen

¯ Product Backlog als priorisierte Strukturelement-Liste

° Definition eigener Strukturelemente

± Definition diverser Lebenszyklen für Strukturelemente

² Umwandlungen zwischen Strukturelementen

³ Protokollierung der Änderungen an Strukturelementen

´ Teaminterne Aufgabenzuweisung

µ Abstrakte Aufwandsschätzungen

Zusätzliche Anforderungen

¶ Bestimmen der velocity

· Visualisierung des Projekt- oder Sprintfortschritts in einem Burndown ChartTabelle 5.2: Anforderungen an die Softwareunterstützung



5.2 Vergleich der Anforderungen mit Projektron BCS

Die Erfüllung sämtlicher Kernanforderungen außer der Zuordnung von Projek-ten zu Kunden (®) und der vollständigen Aufwandserfassung (¬) durch JIRAsei durch die Beschreibung des Prozesses belegt. Der folgende Soll-Ist-Vergleichbezieht sich daher auf die Funktionen von Projektron BCS.

¬ Erfassung allgemeiner und projektbezogenener Aufwände: Die Funktionder Zeiterfassung war der Hauptgrund für die Einführung von Projektron BCS beider Hypoport AG und ist Kernfunktion von Projektron BCS. Die Protokollierungaufgewandter Projektarbeitszeit ist auch in JIRA möglich. Um die Abrechnungder aufgewandten Arbeitszeit so effektiv wie möglich zu gewährleisten, erfolgt dieZeiterfassung sowohl allgemeiner als auch projektbezogener Aufwände ausschließ-lich in Projektron BCS. Diese Anforderung wird daher als erfüllt erachtet. Wichtigist, dass die Zeiterfassung bei Erfüllung weiterer Anforderungen, z. B. der Defini-tion eigener Strukturelemente und deren Umwandlung gewährleistet bleibt.

Abbildung 5.5: Definition der Grundlast und Ressourcenauslastung

Definition einer Grundlast: Durch die Definition einer Grundlast, also einerbestimmten Anzahl an Stunden pro Tag, die nicht für Projektarbeit aufgewandtwerden können, ist es möglich Überlastungen durch Wissensaustausch zu ver-meiden. Das Konzept von Grundlasten ist in Projektron BCS bereits umgesetzt.




Abbildung 5.5 zeigt die Definition von Grundlasten im Arbeitsbereich Projekteund deren Repräsentation in der Ressourcenauslastung eines Mitarbeiters.

® Zuordnung von Kunden zu Strukturelementen: Bei Hypoport werdenzwar die Strukturelemente der Projekte hierarchisch nach Kunden geordnet, dochmüsste dies geändert werden, sobald eine detaillierte Projektplanung in Projekt-ron BCS erfolgt. Die Erstellung eines Strukturelements, das die Kundenzuord-nung repräsentiert (z. B. ein Unterprojekt mit dem Namen des Kunden, wie inAbbildung 5.3), widerspricht dem Ziel einer produktbezogenen Abbildung, wiesie momentan in JIRA umgesetzt ist.

Abbildung 5.6: Einer Organisation zugeordnete Projekte

Gegenwärtig ist es in der Teamplanung eines Projektron BCS Strukturelementsbereits möglich, externe Mitarbeiter oder sogar ganze Organisationen zuzuord-nen. Dadurch sind, wie Abbildung 5.6 veranschaulicht, sämtliche einem Kundenzugeordnete Projekte (oder deren Elemente) auf einen Blick am Kunden ersicht-lich. Eine solche Zuordnung ist auch an Projektron BCS Tickets möglich. DieseAnforderung ist damit in der Standardkonfiguration erfüllt.

¯ Product Backlog als priorisierte Liste von Strukturelementen: SämtlicheStrukturelemente eines Projekts haben in Projektron BCS eine Priorität. DerStrukturplan eines Projekts stellt das Product Backlog dar, vorausgesetzt, dieSpalte Priorität (hervorgehoben in Abbildung 5.7) ist eingeblendet. Obwohl essich beim Strukturplan statt einer Listen- um eine Baumansicht handelt, sind allerelevanten Informationen enthalten. Damit ist die Erfüllung dieser Anforderungbelegt.




Abbildung 5.7: Product Backlog in Projektron BCS

° Definition eigener Strukturelemente: Die Definition eigener Strukturele-mente ist Voraussetzung für die Verknüpfung mit verschiedenen Lebenszyklen.Gegenwärtig können mit dem beschriebenenWebConfigEditor bereits eigene Struk- siehe 4.3turelemente als Subtypen von Projekten und Aufgaben (Abbildung 5.8, links)konfiguriert werden, um spezifische Attribute anzuzeigen oder auszublenden.

Aufgabe

Subtyp 1

Subtyp 2

Subtyp 3

Anmerkung

TicketArt = 1Art = 2Art = 3

Ticket

Ticketart 1

Ticketart 2

Ticketart 3

Abbildung 5.8: Schematische Datenstrukturlinks: Aufgabe mit Subtypen, Mitte: Anmerkung mit Sub-typ Ticket und dessen Attribut „Art“, rechts: Idealzustand mitTicketarten als Subtypen von Ticket

Für Tickets in Projektron BCS ist dies nicht möglich, da diese keine eigenständi-gen Objekte, sondern bereits ein Subtyp des Objekts Anmerkung sind. Im Ticket-system erfolgt daher die Definition eigener Ticketarten ausschließlich über dasAttribut „Art“. Abbildung 5.8 veranschaulicht dies (Mitte). Es gibt Verknüp-fungen zwischen Tickets in Form von Zuordnungen, welche die Namen „VerwandteTickets“ und „Duplikate“ tragen. Damit ist es jedoch nicht möglich, Tickets wieim Strukturplan hierarchisch anzuordnen. Es fehlen Vorgänger-Nachfolger- und siehe 4.1Eltern-Kind-Beziehungen, um eine Struktur abzubilden. Um dies zu ermöglichen,




muss die Datenstruktur an die der Aufgaben und Projekte angepasst werden(Abbildung 5.8, rechts). Diese Anforderung gilt daher nur als teilweise erfüllt.

± Definition diverser Lebenszyklen für Strukturelemente: Verschiedene An-forderungen werden auf unterschiedliche Art undWeise bearbeitet. Diese verschie-denen Abläufe zu repräsentieren, ist nur möglich, indem für verschiedene Struk-turelemente und Tickets unterschiedliche Lebenszyklen, also je Status möglicheÜbergänge in andere Status, definiert werden.

In Projektron BCS ist dies per Konfiguration gegenwärtig für Subtypen von Auf-gaben und Projekten möglich. Mit dem Attribut state können dort verschie-dene Status verwaltet werden. In der Standardkonfiguration füllt die Menge derStatus-Attribute eine Dropdown-Liste im Bearbeitungsmodus des jeweiligen Sub-typs (Abbildung 5.9).

Abbildung 5.9: Auszug aus der Datenstrukturinfo einer Aufgabe und Statusan-zeige

Lebenszyklen können mit XML-Konfigurationsdateien verwaltet werden. Auf-grund der zuvor geschilderten Datenstruktur ist aber die Definition unterschiedli-cher Lebenszyklen für verschiedene Ticketarten nicht möglich. Ein Beispiel für dieKonfiguration eines Lebenszyklus für alle Tickets ist in Anhang A.2 aufgeführt.Eine solche Konfiguration ist weder im Standard enthalten, noch dokumentiert.Diese Anforderung wird daher als teilweise erfüllt aufgenommen.

² Umwandlungen zwischen Strukturelementen: Um die durch den ScrumProzess vorgegebene und bei Hypoport praktizierte iterative Verfeinerung derAnforderungen zu erreichen, müssen Strukturelemente eines Projekts ineinander




umgewandelt werden können. Dies ist gegenwärtig in Projektron BCS nicht mög-lich. Wird eine Anforderung als Aufgabe geplant, kann dies nicht mehr verändertwerden. Ein Anwendungsfall dafür ergibt sich aus dem Zusammenhang zwischenepics und user stories:

Eine Aufgabe – eine user story – wird zu Beginn des Projekts angelegt, stellt sichaber im weiteren Verlauf als zu groß – als epic – heraus. Diese Feststellung wurdevon einem Entwickler getroffen, nachdem dieser mehrere Stunden mit der Aufgabezugebracht und auch die entsprechende Zeit gebucht hat. Ein Arbeitspaket, dasmehrere Aufgaben enthalten kann, ist geeignet, um dieses epic zu repräsentieren.Auf dieses Arbeitspaket würden die Aufwände gebucht werden, die nötig wären,um die sinnvolle Unterteilung in Aufgaben herzustellen. Die Zeiterfassung aufArbeitspakete ist jedoch nicht möglich.

Präventiv gröbere Strukturelemente, in diesem Fall Arbeitspakete, anzulegen istebenfalls nicht zielführend. Zwar kann, wenn eine Verfeinerung nicht mehr not-wendig ist, darunter eine einzige Aufgabe erstellt werden, um Aufwände zu erfas-sen, doch ist dies aus zwei Gründen nicht optimal. Die unnötige Erstellung einesweiteren Elements ist erstens Verschwendung (die Scrum zu Vermeiden versucht) siehe 2.2und widerspricht zweitens dem Konzept von epics und user stories. Ein epic, dasnicht mehr unterteilt wird, ist bereits eine user story. siehe 3.2

Da die Verwendung von Tickets dieser Anforderung aufgrund der beschriebenen,mangelnden Strukturierung ebenfalls nicht gerecht wird, gilt die Anforderungnach Umwandlungen zwischen Strukturelementen als nicht erfüllt.

³ Protokollierung der Änderungen an Strukturelementen: Die Protokol-lierung von Änderungen erfolgt an jedem Strukturelement in Projektron BCS,ersichtlich über das Menu „Eigenschaften“ und den Menueintrag „Log“. Auchim Ticketsystem werden die Änderung, der Bearbeiter und der Zeitpunkt derÄnderung erfasst. Das Kommentieren von Tickets ist ebenfalls möglich. Abbil-dung 5.10 zeigt die Änderungshistorie eines Tickets.

´ Teaminterne Aufgabenzuweisung: Im Rahmen der Anwendung von Scrumentscheidet das Team, wer welche Aufgaben übernimmt. Die Aufgabenzuweisung(Teamplanung) ist in Projektron BCS an die Projektleiterlizenz gebunden. Daher siehe 4.1




Abbildung 5.10: Änderungshistorie im Projektron BCS Ticketsystem

gibt es drei Möglichkeiten das Selbstmanagement des Teams zu unterstützen. DasTeam kann im Sprint Planning Meeting dem Projektleiter mitteilen, wie die Auf-gaben verteilt werden. Bei einer Veränderung muss jedoch der Projektleiter erneuteingreifen. Eine zweite Möglichkeit ist die Zuweisung des ganzen Teams – jedesTeammitglieds – zu allen Aufgaben. In diesem Fall ist für einen Projektmanagernicht ersichtlich, wie die Aufgaben tatsächlich verteilt sind. Die dritte Varianteist die Vergabe einer Projektleiterlizenz für jedes Teammitglied. Mit dieser Lizenzsind jedoch etliche weitere Funktionen verfügbar, was sich im Preis widerspiegelt.Die letzten beiden Möglichkeiten unterstützen das Selbstmanagement des Teamsaktiv.

Im Ticketsystem ist die teaminterne Aufgabenzuweisung durch das Attribut „Be-arbeiter“ gegeben. Dies kann durch jeden Mitarbeiter geändert werden, was, ver-antwortungsbewussten Umgang vorausgesetzt, dem Team die Arbeitsorganisationerheblich erleichtert. Damit ist die Erfüllung dieser Anforderung belegt.

µ Abstrakte Aufwandsschätzungen: Restaufwände werden in Projektron BCSin Zeiteinheiten geschätzt. Die Vorteile abstrakter Aufwandsschätzungen wurdensiehe 3.3bereits geschildert. Es ist per Konfiguration möglich, ein zusätzliches Attribut zudefinieren, das den abstrakten Aufwand eines Strukturelements enthält. Ziel ist,aus der Fertigstellung untergeordneter Elemente direkt (abhängig von der Quali-tät der Schätzung und Unterteilung) auf den Fertigstellungsgrad des übergeord-neten Elements zu schließen. Dazu müssen Aufwände größerer Strukturelementeals Summen der Aufwände ihrer Teile dargestellt werden. Ein entsprechender Au-tomatismus kann nicht konfiguriert werden. Dies jedoch mit der zuvor beschrie-



5.3 Vorgaben

benen Konfiguration über alle Hierarchieebenen manuell vorzunehmen, wird fürdie Erfüllung dieser Anforderung als nicht ausreichend erachtet.

¶ Velocity und · Burndown Chart: Die beiden zusätzlichen Anforderungenwerden gegenwärtig weder von Projektron BCS noch von JIRA erfüllt.

Anforderung Projektron BCS JIRA

Kernanforderungen

¬ Erfassung allgemeiner/projektbezogenener Aufwände l w

Definition einer Grundlast l l

® Zuordnung von Kunden zu Strukturelementen l m

¯ Product Backlog als priorisierte Strukturelement-Liste l l

° Definition eigener Strukturelemente w l

± Definition diverser Lebenszyklen für Strukturelemente w l

² Umwandlungen zwischen Strukturelementen m l

³ Protokollierung der Änderungen an Strukturelementen l l

´ Teaminterne Aufgabenzuweisung l l

µ Abstrakte Aufwandsschätzungen m l

Zusätzliche Anforderungen

¶ Bestimmen der velocity m m

· Visualisierung des Projekt- oder Sprintfortschritts in m m

einem Burndown Chart

Legende

Anforderung l erfüllt w zum Teil erfüllt m nicht erfülltTabelle 5.3: Erfüllung der Anforderungen durch die Software

Die Erfüllung der Anforderungen durch beide Softwaretools ist in Tabelle 5.3gegenübergestellt.

5.3 Vorgaben

Um die Möglichkeit zu schaffen, auf JIRA zu verzichten und auch die detaillierteProjektplanung in Projektron BCS abzubilden, müssen diejenigen Anforderungen




umgesetzt werden, die gegenwärtig von JIRA vollständig, von Projektron BCSjedoch nur teilweise bis gar nicht erfüllt werden.

Basierend auf der Beschreibung eines Pflichtenhefts nach Balzert werden dieVorgaben für die Anpassungen und Konzeption dargestellt, darunter auch die Vor-gaben der Projektron GmbH (Vgl. [Balzert 2000]). Auf eine Schilderung der Pro-duktfunktionen wird dabei verzichtet, da diese im Rahmen des Soll-Ist-Vergleichsbereits verdeutlicht wurden.

Zielbestimmung

Wenngleich der Fokus der Arbeit darauf liegt, das PM mit Projektron BCS inHinblick auf Scrum bei der Hypoport AG zu verbessern, besteht der Anspruchdarin, ein standardwürdiges Konzept und ebensolche Anpassungen zu erstellen.

Die Anforderungen werden soweit spezifiziert, dass ein Abgleich der Anpassungenund des zu erarbeitenden Konzepts mit der Spezifizierung möglich ist.

Muss-Kriterien:

• Bei der Definition von Strukturelementen muss bestimmt werden können,in welcher Beziehung diese zu welchen anderen Elementen stehen dürfen.

• Eltern-Kind- und Vorgänger-Nachfolger-Beziehungen müssen verwaltet wer-den können.

• Die Abbildung komplexer Hierarchien und Beziehungen soll ähnlich wie imStrukturplan möglich sein.siehe 4.1

• Es muss möglich sein, verschiedene Lebenszyklen zu definieren.

• Lebenszyklen sind vorgeschriebene Möglichkeiten der Statusänderungen. Esmuss die Möglichkeit bestehen, die Einhaltung des Lebenszyklus als ver-bindlich zu definieren. Dies muss sich in der Benutzeroberfläche widerspie-geln.

• Mögliche Umwandlungen zwischen Strukturelementen müssen bestimmt wer-den können. Auf unterschiedliche Lebenszyklen muss trotz Freiheit in derKonfiguration fehlerfrei reagiert werden.



5.3 Vorgaben

• Die Verwendung abstrakter Aufwandsschätzungen muss möglich sein. Dabeimuss frei wählbar sein, ob diese zusätzlich zur gegenwärtigen Schätzung oderstattdessen verwendet werden sollen.

• Abstrakte Aufwände müssen bottom-up zu übergeordneten Elementen ku-muliert werden können.

Kann-Kriterien:

• Aus den in einem bestimmten Zeitraum fertig gestellten Strukturelementenund deren abstrakten Aufwänden soll die velocity ermittelt werden können.

• Die Entwicklungsgeschwindigkeit abgeschlossener Projekte soll gespeichertwerden.

• Der Projekt- oder Sprintfortschritt soll in einem Burndown Chart visua-lisiert werden können. Dabei soll die Möglichkeit bestehen, eine velocityanzugeben. Alternativ kann die durchschnittliche velocity aus wählbarenProjekten verwendet werden.

Abgrenzungskriterien:

• Die Erfassung der velocity eines Mitarbeiters ist im Sinne des Scrum Pro-zesses, der die Einheit des Teams unterstützen soll, nicht vorgesehen.

• Die Umsetzung von Anpassungen die nicht per Konfiguration vorgenom-men werden können, sondern Programmieraufwand an Projektron BCS er-fordern, ist nicht als Teil der Arbeit vorgesehen. Für Anpassungen dieserArt ist ein detailliertes Konzept zu erarbeiteten.

Produkteinsatz

Anwendungsbereiche: Die Anpassungen ermöglichen viel Freiheit in der Kon-figuration und damit die Abbildung beliebiger Prozesse und unterstützen so denumfangreicheren Einsatz von Projektron BCS sowohl innerhalb der Hypoport AGals auch in weiteren Unternehmen, die agile Projektmanagementsysteme anwen-den.




Zielgruppe: Die Anpassungen richten sich in erster Linie an Entwicklerteams,deren Selbstmanagement durch die Anpassungen forciert wird. ScrumMaster undProjektmanager können den Prozess jederzeit veränderten Bedingungen anpas-sen.

Betriebsbedingungen: Vorgesehen ist der Dauerbetrieb des BCS Servers.

Produktdaten

Folgende Daten müssen an Strukturelementen langfristig gespeichert werden:

• Der geschätzte Aufwand wird in einer beliebigen abstrakten Einheit festge-legt und als Datentyp Int gespeichert.Menge: 1 (es wird genau ein Wert gespeichert)

• Die geplante velocity wird ebenfalls als Int-Wert erfasst.Menge: 1 (es wird genau ein Wert gespeichert)

• Nach Abschluss eines Sprints wird die tatsächliche velocity als Int-Wertgespeichert.Menge: 1 (es wird genau ein Wert gespeichert)

• Vorgänger-Nachfolger-Beziehungen und untergeordnete Strukturelemente (Kin-der) werden in Form von OIDs gespeichert.Menge: je 0-n (es können beliebig viele dieser Beziehungen gespeichert wer-den)

• Übergeordnete Strukturelemente (Eltern) werden als OIDs gespeichert.Menge: 1 (jedes Strukturelement hat genau ein Eltern-Element)

• Mindestens ein Status des Lebenszyklus muss im Burndown Chart als nichterfüllt dargestellt werden. Diese werden als String gespeichert.Menge: 1-n (es wird mindestens ein Wert gespeichert)

• Mindestens ein Status des Lebenszyklus muss im Burndown Chart als fertigdargestellt werden. Diese werden als String erfasst.Menge: 1-n (es wird mindestens ein Wert gespeichert)



5.3 Vorgaben

Qualitätsanforderungen

Die folgenden Qualitätsanforderungen beziehen sich nicht auf die bestehendenQualitätsmerkmale von Projektron BCS, sondern ausschließlich auf die im Rah-men dieser Arbeit zu erarbeitenden Anpassungen. Darüber hinaus sollen beste-hende Qualitätsmerkmale von Projektron BCS nicht beeinträchtigt werden.

Aufmerksamkeit: Die Aufmerksamkeit des Anwenders muss in kürzester Zeitauf die wichtigsten Bereiche gelenkt werden.

Änderbarkeit: Der Aufwand, Änderungen vorzunehmen muss so gering wiemöglich sein. Änderungen dürfen keine unerwarteten Wirkungen nach sich zie-hen.

Effizienz: Der Aufwand, bestimmte Ziele mit dem Produkt zu erreichen, sollstets der geringstmögliche sein.

Erwartungskonformität: Informationen müssen innerhalb des Produkts ein-heitlich dargestellt werden. Funktionen müssen derart bezeichnet sein, dass sieder Erwartungshaltung des Benutzers entsprechen.

Verständlichkeit: Die Anpassungen und ihre Konfigurationsmöglichkeiten wer-den nach Möglichkeit selbsterklärend gehalten. Bezeichner werden derart gewählt,dass ihr Zweck intuitiv ersichtlich ist. Wo dies zusätzlich notwendig ist, wird eineangemessene Dokumentation erstellt.

Benutzeroberfläche

Die Anpassungen müssen sich nahtlos in das Erscheinungsbild der ProjektronBCS GUI einfügen. Sofern dies nicht durch Qualitätsanforderungen bedingt wird,soll die Dialogstruktur nicht verändert werden. Sämtliche Seiten der Projekt-ron BCS Benutzeroberfläche dienen der Erfüllung bestimmter Aufgaben. Die am




Scrum Prozess bei der Hypoport AG beteiligten Rollen Projektmanager, Scrum-Master und Teammitglieder müssen zum Zugriff auf die jeweils benötigten Seitenberechtigt sein.

Nichtfunktionale Anforderungen

• Die Projektron GmbH steht der Einführung spezieller Scrum Lizenzen auf-geschlossen gegenüber. Veränderungen am Lizenzmodell von ProjektronBCS müssen detailliert geschildert und begründet werden.

• Die zahlreichen Auswertungen, die das Projektcontrolling bietet, dürfennicht beeinträchtigt werden.

Technische Produktumgebung

Software: Projektron BCS setzt Java-Umgebung ab Version 5.0, eine Servlet-Engine sowie eine JDBC-fähige Datenbank voraus. Als Client dienen die Web-browser Internet Explorer (6.0), Firefox (1.5), Netscape (7.0), Opera (9.21) undSafari (2.0). In Klammern steht die mindestens vorausgesetzte Version. ([Projekt-ron])

Hardware: Für den Betrieb des Projektron BCS Servers werden mindestens1 GB RAM, ca. 150 MB Festplattenspeicher sowie mindestens 1,8 GHz CPU-Leistung vorausgesetzt. Die Netzwerkverbindung muss eine Datenübertragungs-rate von 100 Mbit/s unterstützen. Dateiablage und Datenbank benötigen anfor-derungsabhängig mindestens 1 GB weiteren freien Festplattenspeicher. ([Projekt-ron])

Schnittstellen: Weitere Softwareschnittstellen sind nicht vorgesehen. Projekt-ron BCS als technische Schnittstelle ersetzt auch mit den geforderten Anpassun-gen nicht die soziologischen Schnittstellen zwischen den Projektbeteiligten.



5.3 Vorgaben

Anforderungen an die Entwicklungsumgebung

Für administrative Änderungen, die per Konfiguration vorgenommen werden,wird ein Texteditor benötigt. Um für komplexe Anpassungen ein möglichst de- siehe 4.3tailliertes Konzept zu erstellen, müssen Screenshots von Projektron BCS gemachtwerden. Die Systemvoraussetzungen für den Betrieb von Projektron BCS wurdenbereits beschrieben. Zusätzlich ist ein Bildbearbeitungsprogramm erforderlich.



6 Anpassungen

Die Zukunft gehört denen,

die an die Schönheit ihrer Träume glauben.

(Eleanor Roosevelt)

In diesem Kapitel werden relevante Entscheidungen vor der Umsetzung der An-passungen erläutert, sowie die Anpassungen an Projektron BCS und deren Inte-gration in Form eines Soll-Konzepts geschildert. Aufgabe eines solchen Konzeptsist es, ein System vorzuschlagen, das die im Rahmen der Ist-Analyse aufgezeigtenSchwachstellen behebt. ([Krallmann u. a. 2002, S.99])

6.1 Vorbetrachtungen

In enger Zusammenarbeit mit dem Entwicklungsleiter der Projektron GmbH,Herrn Stefan Lützkendorf, wurde entschieden, die Anpassungen größtenteils imRahmen des Projektron BCS Ticketsystems vorzunehmen.

Gründe für diese Entscheidung

1. Eine Veränderung des Projektron BCS Lizenzmodells ist nicht notwendig,um die funktionalen Anforderungen innerhalb des Ticketsystems zu erfüllen.

2. Da Projektron BCS Strukturelemente, wie Projekte, Unterprojekte, Ar-beitspakete und Aufgaben nicht verändert werden, wird das Projektcon-trolling nicht beeinflusst.

3. Der gleiche Grund gewährleistet die Aufnahme der Anpassungen in den Pro-jektron BCS Standard, da die Umsetzung innerhalb des Ticketsystems dieKunden der Projektron GmbH nicht in ihrer Projektarbeit beeinträchtigt.



6 Anpassungen

4. Es gibt seit längerem Überlegungen, die zuvor beschriebene Datenstrukturvon Anmerkungen und Tickets zu überarbeiten und Tickets als eigenstän-siehe 5.2digen Objekttyp zu etablieren. Dies begünstigt die zeitnahe Umsetzung desvorgestellten Konzepts.

5. Tickets selbst haben in Projektron BCS keinen Zeitbezug, wohl aber eineZuordnung zu Objekten, die ein Start- und Enddatum haben. Dies kommtder Anwendung von user stories bei der Hypoport AG bereits sehr nahe:Die Bearbeitungsreihenfolge der user stories eines Sprints ergibt sich aus derPriorisierung und wird nicht vom Management vorgeschrieben. Ein Sprintist im Gegensatz zu einer user story zeitlich fixiert.

Auswirkungen

Voraussetzung für das vorliegende Konzept ist, wie bereits erläutert, die Um-wandlung der Tickets von Subtypen des Objekts Anmerkung in eigenständigeObjekttypen. Weitere Anpassungen können daher nicht administrativ per Konfi-guration erfolgen.

6.2 Umsetzung und Konfigurierbarkeit

Es wird ein Subtyp des Projektron BCS-Objekts Aufgabe definiert. Dieser Sub-siehe 4.2typ trägt den Namen Sprint. Wie bisher erfolgt damit die zeitliche Einteilungdes Projekts. Die inhaltliche Einteilung wird durch Tickets vorgenommen. ImFolgenden wird auf diese Sprint-Aufgabe Bezug genommen.

Definition eigener Strukturelemente

Die Minimalkonfiguration von fünf Ticketarten in Listing 6.1 bildet die Grund-lage für die folgenden Ausführungen. In Zeile 1 wird die Menge der Ticketar-ten beschrieben. Anschließend werden für jede Ticketart die Status definiert,sowie die Verwendung abstrakter Aufwände aktiviert oder verhindert. Die De-finition verschiedener weiterer Attribute für die unterschiedlichen Ticketartensiehe 4.3(z. B. Reproduzierbarkeit für Tickets der Art „Bug“) ist ebenfalls möglich.




Listing 6.1: Minimalkonfiguration von Ticketarten1 JTicket.subtypes=Epic,Userstory,Akzeptanztest,ChangeRequest,Bug2

3 JTicket.subtyp.Epic.states=Neu,Spezifiziert ,Geschlossen4 JTicket.subtyp.Epic.abstractEfforts=true5

6 JTicket.subtyp.Userstory.states=\7 Neu,Priorisiert ,Umsetzung bestätigt,Bearbeitung,Umgesetzt,Geschlossen8 JTicket.subtyp.Userstory.abstractEfforts=true9

10 JTicket.subtyp.Akzeptanztest.states=Erstellt,Testen,Akzeptiert, Integrativ getestet11 JTicket.subtyp.Akzeptanztest.abstractEfforts=false12

13 JTicket.subtyp.ChangeRequest.states=Neu,Gesichtet,Klärung,Absprache,Angeboten,14 Aufgenommen,Eingeplant,Bearbeitung,Abnahme,Geschlossen15 JTicket.subtyp.ChangeRequest.abstractEfforts=false16

17 JTicket.subtyp.Bug.states=Neu,Klärung,Aufgenommen,Bearbeitung,Abnahme,Geschlossen18 JTicket.subtyp.Bug.abstractEfforts=false

Um mit Tickets in Projektron BCS nicht nur Aufgaben zu verfeinern, sondernStrukturen abzubilden, ist es nun möglich, Eltern-Kind-Beziehungen zu definie-ren. In der Baumansicht des Strukturplans werden Tickets hierarchisch darge-stellt. Diese Darstellung macht Abhängigkeiten zwischen den Tickets deutlichsichtbar und erleichtert die Navigation. In Abbildung 6.1 ist dem Sprint einepic zugewiesen, das wiederum zwei user stories enthält. Einrückungen verdeutli-chen die Tiefe der Hierarchie. In der Abbildung befindet sich „Akzeptanztest03“als Kind-Element von „User story03“ auf der untersten Hierarchieebene.

Abbildung 6.1: Hierarchische Anordnung von Tickets im Strukturplanlinks: Anzeigenmodus, rechts: Bearbeitungsmodus



6 Anpassungen

Sofern keine Einschränkungen vorgenommen werden, ist es möglich, jede definier-te Ticketart als Kindelement jeder anderen Art anzuordnen. So kann in diesemFall beispielsweise ein Akzeptanztest epics und user stories enthalten. Dies wirddurch eine Konfiguration wie in Listing 6.2 verhindert. Es wird festgelegt, dassein epic sämtliche anderen Ticketarten als Kindelemente haben kann, währendeinem Akzeptanztest keine Elemente untergeordnet werden können. User stories,ChangeRequests und Bugs können selbst Akzeptanztests enthalten.

Listing 6.2: Einschränkung möglicher Kindelemente1 JTicket.subtyp.Epic.possibleChildElements=Userstory,Akzeptanztest,ChangeRequest,Bug2 JTicket.subtyp.Userstory.possibleChildElements=Akzeptanztest3 JTicket.subtyp.Akzeptanztest.possibleChildElements=4 JTicket.subtyp.ChangeRequest.possibleChildElements=Akzeptanztest5 JTicket.subtyp.Bug.possibleChildElements=Akzeptanztest

Abstrakte Aufwandsschätzungen

Die Verwendung abstrakter Aufwandsschätzungen kann, wie in Listing 6.1 be-reits beschrieben, über das Attribut abstractEfforts aktiviert oder verhindertwerden. Die Aktivierung wirkt sich sowohl auf den Anzeigen- als auch auf den Be-arbeitungsmodus eines Tickets aus. Im Anzeigenmodus wird das Feld „AbstrakterAufwand“, das den Aufwand des aktuellen Tickets selbst enthält, gezeigt. Direktdarunter befindet sich das Feld „Abstrakter Aufwand (rekursiv)“, das die Summeder Aufwände sämtlicher untergeordneter Elemente enthält. Im Bearbeitungsmo-dus kann ausschließlich der Wert des ersten Feldes geändert werden. Das Feld„Abstrakter Aufwand (rekursiv)“ wird im entsprechenden Formular nicht ange-zeigt.

Abstrakte Aufwände werden im Strukturplan dargestellt. Im Anzeigenmoduswird dabei die Summe aller Aufwände untergeordneter Elemente und des entspre-chenden Tickets dargestellt. Die Forumularfelder des Bearbeitungsmodus hinge-gen enthalten die Aufwände jedes Tickets. Abbildung 6.1 veranschaulicht dies:Epic02 hat selbst keinen abstrakten Aufwand. Im Anzeigenmodus wird ein Auf-wand von 13 aufgeführt – die Summe der beiden untergeordneten user stories.Da für Akzeptanztest die Verwendung abstrakter Aufwände deaktiviert ist, wird




im Bearbeitungsmodus in der Zeile des Akzeptanztests kein Formularfeld ange-zeigt.

Umwandlungen zwischen Strukturelementen

Die Umwandlung zwischen Tickets ist abhängig von den möglichen Kindelemen-ten. Dabei wird geprüft, welche Kindelemente ein Ticket gegenwärtig enthältund welchen Typ das aktuelle Elternelement hat. Für die Umwandlung geltenzwei Bedingungen. Die Ziel-Ticketart

â muss ebenfalls die aktuellen Kindelemente enthalten können undâ muss selbst Kindelement des aktuellen Elternelements sein können.

Dies ist als Kompromiss zwischen unbegrenzten Freiräumen in der Handhabungvon Strukturelementen und den zur Fehlervermeidung notwendigen Einschrän-kungen zu verstehen. Abbildung 6.2 zeigt mögliche Umwandlungen einer userstory. Die betreffende user story ist gegenwärtig kein Kindelement eines epics. Indiesem Fall wäre die Umwandlung in ein solches nicht mehr möglich, da epicsselbst keine epics enthalten dürfen. Im Umkehrschluss kann ein epic, das bereitsdurch user stories als Kindelemente spezifiziert ist, nicht mehr in eine user storykonvertiert werden.

Abbildung 6.2: Umwandlung von Ticketslinks: Anzeigenmodus, rechts: Bearbeitungsmodus

Ein Ticket, das direkt der Sprint-Aufgabe untergeordnet ist und selbst noch keineKindelemente hat, ist bezüglich der Umwandlung keinen Restriktionen unterwor-fen.

Die Verwendung abstrakter Aufwandsschätzungen beeinflusst mögliche Umwand-lungen nicht. Es wird davon ausgegangen, dass ein Ticket, das bereits geschätztwurde, nicht mehr in eine Ticketart umgewandelt werden muss, bei der abstrakte



6 Anpassungen

Aufwände deaktiviert sind. Ausgeschlossen wird diese Möglichkeit jedoch nicht.Im Falle einer solchen Umwandlung wird eine Warnung gezeigt. Die Schätzungist anschließend nur aus der Historie, dem Änderungsprotokoll, des Tickets er-sichtlich.

Definition diverser Lebenszyklen für Strukturelemente

Die Definition von Lebenszyklen erfolgt per XML-Datei. Da user stories und Ak-zeptanztests pro Status nur maximal zwei Übergänge haben, bezieht sich das fol-siehe

Abb. 5.4 gende Beispiel auf das in Abbildung 6.3 gezeigte Zustandsdiagramm eines Bugs.Der Aufbau des Schemas der Konfigurationsdatei ist in Listing 6.3 dargelegt.Mögliche Übergänge der Status „Neu“ und „Aufgenommen“ werden festgelegt.

Abbildung 6.3: Lebenszyklus eines Bugs als Zustandsdiagramm nach [oose 2008]

Listing 6.3: Definition des Lebenszyklus eines Bugs1 <TicketStates>2 <Subtyp Name="Bug">3 <State Name="Neu">4 <ChangeStates>5 <ChangeState Name="Aufgenommen" />6 <ChangeState Name="Klärung" ShowWorkflow="false" />7 </ChangeStates>8 </State>




9 <State Name="Aufgenommen">10 <ChangeStates>11 <ChangeState Name="Bearbeitung" Transition="Bearbeitung starten" Icon="work

−in−progress.gif" />12 <ChangeState Name="Abnahme" Transition="Fertig stellen" Icon="check.gif" />13 <ChangeState Name="Geschlossen" Transition="Schließen" Icon="cross.gif" />14 <ChangeState Name="Klärung" ShowWorkflow="false" />15 </ChangeStates>16 </State>17 [...]18 </Subtyp>19 </TicketStates>

ChangeState-Elemente enthalten mehrere Attribute, mit denen ein Lebenszykluskonfiguriert und angepasst werden kann. Diese Attribute sind in Tabelle 6.1gegenüber gestellt.

Attribut Definition Funktion

Name verbindlich Bestimmt den Ziel-StatusIcon optional Name einer Bilddatei, die dem Statusübergang

vorangestellt wirdShowWorkflow optional Bestimmt, ob der Übergang unter Arbeitsabläu-

fe dargestellt wirdTransition optional Verändert den Text, mit dem der Übergang un-

ter Arbeitsabläufe verlinkt istTabelle 6.1: Attribute eines ChangeState-Elements

Abbildung 6.4 zeigt die durch die zuvor dargelegte Konfiguration eines Bugs de-finierten Statusübergänge (links). Der Fehler hat den Status „Aufgenommen“ undkann durch Klick auf die direkt verlinkten Icons und Texte in die Status „Bearbei-tung“, „Abnahme“ und „Geschlossen“ übergehen. Die Übergänge zum Status „Klä-rung“ werden im Anzeigenmodus nicht aufgeführt, da das Attribut ShowWorkflowden Wert false hat (Listing 6.3, Zeile 14 ). Dieser Status kann weiterhin im Be-arbeitungsmodus gesetzt werden. In diesem Modus werden wie bisher Status, zudenen der Übergang möglich ist, in einer Dropdown-Liste angezeigt.



6 Anpassungen

Abbildung 6.4: links: Eingeschränkte Arbeitsabläufe eines Fehlers,rechts: Uneingeschränkte Arbeitsabläufe eines ChangeRequest

Der Lebenszyklus eines ChangeRequests wurde weder eingeschränkt noch ange-passt, daher stehen sämtliche Statusübergänge – in der Benutzeroberfläche Ar-beitsabläufe genannt – zur Verfügung (Abbildung 6.4, rechts).

Auf diese Weise wird die Definition unterschiedlicher Lebenszyklen für verschie-dene Ticketarten gewährleistet. Darüber hinaus ist es möglich, für verschiedeneTickets gleichnamige Status zu verwenden, deren Übergänge jedoch anders zu be-nennen. So kann trotz diverser Arbeitsabläufe nach bestimmten Status über alleTickets gesucht, gefiltert und sortiert werden. Dies ist ebenfalls für die Umwand-lung zwischen Ticketarten mit unterschiedlichen Lebenszyklen relevant. Sofernder gegenwärtige Status für die Ziel-Ticketart definiert ist, wird dieser beibehal-ten. Ist dies nicht der Fall, wird der erste Status der Ziel-Ticketart gesetzt undeine entsprechende Warnung ausgegeben (Abbildung 6.5).

Abbildung 6.5: Erfolgsmeldung und Warnung nach Umwandlung

Die geforderten Qualitätsanforderungen werden durch intuitiv verständliche Be-siehe 5.3zeichnungen erfüllt. Die Konfiguration ist leicht änderbar und erwartungskonform:Werden für verschiedene Ticketarten die gleichen Status definiert, kann der Le-benszyklus einer Art – die Definitionen der Übergänge einschließlich der umschlie-ßenden Subtyp-Tags (Listing 6.3, Zeilen 2,18 ) – per Kopieren und Einfügen für




eine andere Ticketart übernommen werden. Anschließend muss der Name deranderen Ticketart im Subtyp-Tag des eingefügten Blockes angepasst werden.

Entwicklungsgeschwindigkeit und Burndown Chart

Die Sprint-Aufgabe enthält zwei zusätzliche Attribute:

â Entwicklungsgeschwindigkeit (geplant)â Entwicklungsgeschwindigkeit (nach Abschluss)

Nur das erste Attribut kann im Bearbeitungsmodus der Sprint-Aufgabe einge-geben werden. Die geplante Entwicklungsgeschwindigkeit ist die Grundlage desidealen Burndown Graphen im gleichnamigen Diagramm. Die Summe aller ab-strakten Aufwände innerhalb eines Sprints, also der Tickets unterhalb der Sprint-Aufgabe, soll gleich der geplanten velocity sein. Diese Summe wird zwar im An-zeigenmodus der Sprint-Aufgabe dargestellt, aber nicht automatisch als geplantevelocity übernommen, da Änderungen der Schätzungen im Projektverlauf sonstdas Diagramm verfälschen.

Nach Abschluss eines Sprints wird die Summe der Aufwände sämtlicher als ab-geschlossen geltender Tickets erfasst. Diese Zahl wird anschließend als „Entwick-lungsgeschwindigkeit (nach Abschluss)“ gespeichert. Dies geschieht automatischum 0 Uhr am ersten Tag, der nicht Teil des abgeschlossenen Sprints ist.

Standardmäßig gelten alle Status einer Ticketart, mit Ausnahmen des Status„Geschlossen“, als nicht abgeschlossen. Die Summe ihrer Aufwände an jedem Tagdes Sprints bis zum aktuellen Datum wird im Burndown Chart als Säule darge-stellt. Mit der geplanten velocity, den abstrakten Aufwänden und der zeitlichenBegrenzung der Sprint-Aufgabe (Start- und Enddatum) liegen nun sämtliche zurDarstellung eines Burndown Charts erforderlichen Daten vor.

Wie per Konfiguration die Status der Tickets, deren Aufwände im BurndownChart abgebildet werden, verändert werden können, ist in Listing 6.4 aufge-zeigt.

Listing 6.4: Berücksichtigung von Status im Burndown Chart1 JTicket.subtyp.Userstory.burndownTodo=Neu,Priorisiert,Umsetzung bestätigt,Bearbeitung2 JTicket.subtyp.Userstory.burndownReady=Umgesetzt,Geschlossen



6 Anpassungen

Es ist nicht möglich, einen Status als nicht fertig (Zeile 1 ) und als fertig gestellt(Zeile 2 ) zu definieren.

Ist die Menge der als fertig oder unfertig definierten Status nicht gleich der Mengealler Status, erfolgt die Darstellung des Burndown Charts mit zwei Säulen: ProDatum je eine für die Aufwände fertiger und eine für die Aufwände unfertigerTickets. Dies ist in Abbildung 6.6 dargestellt.

Abbildung 6.6: Burndown Chart in Projektron BCS

Beide Säulen sind zusammen nicht so hoch, wie die Säule abstrakter Aufwändeam ersten Tag des Sprints. Diese Differenz entspricht den Aufwänden der Tickets,deren gegenwärtiger Status weder als fertig, noch als unfertig definiert wurde. ImSinne der Transparenz des Sprintfortschritts sollte die Konfiguration jedoch derartvorgenommen werden, dass jeder Status entweder fertig oder unfertig ist. EineFestlegung erfolgt hier nicht. Dies gewährt der Zielgruppe weitgehende Freiheitsiehe 5.3in der Anpassung an den eigenen Prozess.

6.3 Integration

Da die beschriebenen Anpassungen größtenteils innerhalb des Ticketsystems vor-genommen werden, beeinträchtigt ihre Integration die weiteren Bereiche von Pro-jektron BCS nicht.



6.3 Integration

Abbildung 6.7 zeigt das Anpassen-Menu des Strukturplans. Hier kann die An-zeige von Tickets ermöglicht oder verhindert werden. Für Sprint-Aufgaben istdiese Option standardmäßig aktiviert.

Abbildung 6.7: Integration der Anzeige von Tickets im Strukturplan

In der Ansicht eines Elements ist stets ersichtlich, wo in der Baumstruktur sichdieses Element befindet (vgl. Abbildung D.5). Als wichtige Orientierungshilfeist diese Hierarchie auf den jeweiligen Seiten ganz oben angeordnet. Um auchbei den vorgestellten Anpassungen die Aufmerksamkeit des Benutzers sofort auf siehe 5.3die wichtigsten Elemente zu lenken, werden Arbeitsabläufe und untergeordne-te Elemente direkt unter dem Betreff eines Tickets aufgeführt. Abbildung 6.8zeigt darüber hinaus, wie effizient an einem Ticket ein Kindelement erstellt wer-den kann: Direkt unter der Liste der Kindelemente befindet sich ein Link „Tickethinzufügen“. Dieser öffnet die Seite zum Eintragen eines neuen Tickets, das au-tomatisch unterhalb des zuvor geöffneten Tickets erzeugt wird.

Abbildung 6.8: Integration der untergeordneten Tickets und Arbeitsabläufe

Die Planung eines Scrum Projekts erfordert die Einteilung des Projekts in Sprints.Dies ist durch die Möglichkeit, mehrere Sprint-Aufgaben zu erzeugen und derenStart- und Enddaten festzulegen, gegeben. Um Anforderungen in einem ProductBacklog zusammen zu stellen, wird ein gleichnamiges Unterprojekt angelegt. Andiesem werden Tickets verwaltet, die noch keinem Sprint zugeordnet sind. Ent-schließt sich das Team in der Sprint-Planungssitzung zur Umsetzung von Anfor-



6 Anpassungen

derungen aus dem Product Backlog, werden die entsprechenden Tickets aus demUnterprojekt in die jeweilige Sprint-Aufgabe verschoben.

Dieses Vorgehen ist sowohl konform zu Scrum als auch zur gegenwärtigen Team-planung. Letzteres zeigt Abbildung 6.9. Die Leiter des Scrum Projekts werdendem Projekt, der Sprint-Aufgabe und dem Product Backlog zugeordnet. Sie kön-nen so Sprint-Aufgaben planen, Anforderungen im Product Backlog erfassen unddiese, sofern inhaltlich möglich, bereits priorisieren und verfeinern. Bei der Hy-poport AG übernehmen mehrere Projektmanager diese Aufgabe. Sie alle müssendem Unterprojekt zugewiesen werden. Dem Sprint selbst wird anschließend dasTeam zugeordnet. Teammitglieder können dann innerhalb des Sprints Ticketsbearbeiten, umwandeln und zuweisen.

Abbildung 6.9: Kompatibilität zur gegenwärtigen Teamplanung

Da auf Tickets Arbeitszeiten gebucht werden können, bleibt die Zeiterfassunggewährleistet. Buchungen innerhalb eines Sprints (der Aufgabe) können nachTickets sortiert werden. Ein Filter nach Ticketarten ermöglicht hier, zwischenTest- und Entwicklungsaufgaben zu unterscheiden. Da bei der Hypoport AGauch die für Projektmanagement, also unter anderem für die Meetings im ScrumProzess aufgebrachte Zeit erfasst wird, kann die Erstellung einer entsprechendenAufgabe nicht umgangen werden.

Der Aufwandsplan wird nicht beeinflusst. Wie Abbildung 6.10 veranschaulicht,steht die Planung der zeitlichen Aufwände sämtlicher Teammitglieder nicht imWiderspruch zu den vorgestellten Anpassungen. Der Unterschied besteht in derPlanung der Aufwände für einen gesamten Sprint – eine detailliertere Planung istim Scrum Prozess nicht vorgesehen.



6.3 Integration

Abbildung 6.10: Aufwandsplanung auf Sprintebene

Das vorgestellte Konzept ermöglicht es, Scrum Projekte in Projektron BCS ab-zubilden und den zu Grunde liegenden Prozess zu verfolgen. Darüber hinaus istes denkbar, nur einen Teil eines Projekts mit Scrum durchzuführen. Das Scrum-Unterprojekt gliedert sich in diesem Fall nahtlos in die Struktur des Gesamtpro-jekts ein.



6 Anpassungen



7 Fazit und kritische Bewertung

Wer recht erkennen will, muss zuvor

in richtiger Weise gezweifelt haben.

(Aristoteles)

Zweifel an der Zielstellung der vorliegenden Arbeit sind durchaus berechtigt.Schließlich galt es, eine Vorgehensweise, die Individuen und deren Interaktionhöher bewertet als Prozesse und Werkzeuge, mit einem solchen Werkzeug abzu-bilden. Da Agilität jedoch in erster Linie Beweglichkeit bedeutet und diese wie-derum Freiheit verlangt, hat sich die Zielstellung im Laufe der Erstellung dieserDiplomarbeit ein wenig gewandelt: Genau einen agilen Prozess abzubilden wärewenig sinnvoll, da dieser eben auf Grund seiner Agilität einem ständigen Wandelunterworfen ist. Stattdessen galt es, die Freiräume zu schaffen, in denen sich einsolcher Prozess bewegen und entwickeln kann.

Die Freiheiten und die Flexibilität, die das vorgestellte Konzept ermöglicht, wur-den eingehend dargelegt. Die aufgezeigten Konfigurationsmöglichkeiten über dieBenutzeroberfläche vorzunehmen würde den Komfort, mit dem besagte Freiräumein Zukunft ausgeschöpft werden können, noch verbessern.

Die vorliegende Arbeit hat aufgezeigt, welche Bereiche von Projektron BCS ver-bessert werden müssen, um agile Vorgehensweisen abbilden zu können. Ob diedargelegten Anpassungen geeignet sind, innerhalb eines agilen Prozesses auf wei-tere Softwaretools zum Projektmanagement zu verzichten, wird erst der prakti-sche Einsatz zeigen. Das vorgestellte Konzept wurde von den Verantwortlichender Projektron GmbH als überaus nützlich bewertet und hat bereits erste Inter-essenten überzeugt.

Kriterium für den Erfolg der Anpassungen in der Praxis ist aber, nach Ansicht desVerfassers, auch die Einstellung der jeweiligen Entscheidungsträger dem Entwick-



7 Fazit und kritische Bewertung

lungsprozess gegenüber. Diesen Prozess derart detailliert abzubilden, dass Pro-jektron BCS als technische Schnittstelle die Notwendigkeit soziologischer Schnitt-stellen in Form persönlicher Kontakte minimiert, ist nicht Ziel dieser Arbeit undwiderspricht den agilen Werten.

Bei der Erstellung der vorliegenden Arbeit wurde größte Sorgfalt auf Verständ-lichkeit gelegt. Trotz Kritik seitens einiger Lektoren wurde an den Bezeichnungen,die in der Scrum-Fachliteratur verwendet werden, festgehalten. Unberechtigt istdiese Kritik dennoch nicht: Beispielsweise könnten Begriffe wie Product Backlogund Sprint Backlog durch Anforderungsliste und Aufgabenliste ersetzt werden.Eventuell rührt die weite Verbreitung von Scrum aber auch von der Verwendungneuer, unverbrauchter Begriffe. Bleibt also abzuwarten, welche weiteren neuenBezeichnungen für altbekannte Elemente die Entwicklung agiler Vorgehensweisenhervorbringt.



Anhang

Diplomarbeit – Robert Kalweit i


ii Diplomarbeit – Robert Kalweit


A Technische Details

A.1 Datenstruktur von Projektron BCS

Organisationen dienen der Abbildung des eigenen und bekannter Unterneh-men. Personen und Ressourcen werden Subtypen dieses Objekts zugeordnet. In-terne und externe Unternehmen und deren Abteilungen werden dabei dem ent-sprechenden Arbeitsbereich zugeordnet.

Objekt- und Subtyp Objektname Beschreibung

Organisation JOU

– Externe Abteilung extsub

– Externe Organisation ext Zulieferer, Kunden, Investoren, Be-hörden etc.

– Interne Abteilung intsub

– Interne Organisation int das eigene Unternehmen, Tochterge-sellschaften etc.

– Organisationsgruppe intgroup bspw. der eigene Konzern mit mehre-ren internen Organisationen

– Organisationsgruppe group gruppiert externe Organisationen(z. B. in Zulieferer, Kunden etc.)

Tabelle A.1: Subtypen des Objekts Organisation

Diplomarbeit – Robert Kalweit iii



Personen ermöglichen durch die Verwaltung ihrer Kontaktdaten, Verfügbarkei-ten, Arbeitszeitmodelle etc. das Personal- und Kontaktmanagement. Die Subty-pen des Objekts Person werden entweder internen oder externen Organisationenzugeordnet.


Person JUser

– Freier Mitarbeiter contractor ein Mitarbeiter, der selbststän-dig im Dienst des eigenen Un-ternehmens steht

– Login login ein Zugang zum eigenen Pro-jektron BCS System, der keinemMenschen direkt zugeordnet ist

– Mitarbeiter (ehemalig) formeremployee aus einer externen Organisationausgeschiedener Kontakt

– Mitarbeiter employee Mitarbeiter einer externen Or-ganisation

– Person (ehemalig) formerperson aus dem eigenen Unternehmenausgeschiedener Kontakt

– Person person Mitarbeiter des eigenen Unter-nehmens

– Ressource resource eine interne Ressource die ver-plant werden kann (Räume, Be-amer, Autos, Maschinen etc.)

– Selbständige Person ouperson eine externe Person, die keinemUnternehmen zugeordnet ist

Tabelle A.2: Subtypen des Objekts Person

iv Diplomarbeit – Robert Kalweit


A.1 Datenstruktur von Projektron BCS

Projekte sind der Mittelpunkt der Aufmerksamkeit von Projektron BCS. DieProjektplanung auf oberster Hierarchieebene erfolgt mit Subtypen dieses Objekts.Auf dieser Ebene sind zahlreiche Auswertungen möglich.


Projekt JProject

– Arbeitspaket workpackage strukturiert ein Projekt oder Unterpro-jekt

– Betriebstätigkeiten operative enthält Daueraufgaben– Projekt project das eigentliche Projekt– Projektgruppe group fasst mehrere Projekte zusammen– Template template Projektvorlagen– Unterprojekt subproject strukturieren ein Projekt grob

Tabelle A.3: Subtypen des Objekts Projekt

Aufgaben strukturieren ein Projekt im Detail und ermöglichen Zeiterfassung.Mit wenigen Ausnahmen haben Aufgaben einen Zeitbezug, also ein Start- undEnddatum.


Aufgabe JTask

– Allgemeines miscellaneous nicht auf konkrete Aufgaben verbuch-te Zeiten werden einer allgemeinenAufgabe zugeschrieben

– Aufgabe task eine Aufgabe im Projekt– Daueraufgabe everlasting eine zeitlich nicht begrenzte Aufgabe– Krankheit sickness

– Meilenstein milestone ein Meilenstein terminiert auf genaueinen Tag

– Urlaub vacationTabelle A.4: Subtypen des Objekts Aufgabe

Diplomarbeit – Robert Kalweit v



Anmerkungen erfüllen vielfältige Zwecke. Subtypen dieses Objekts protokol-lieren die Kommunikation mit Kontakten und verwalten zusätzliche Daten anverschiedenen anderen Objekten.


Anmerkung JAnnotation

– Anruf (abgehend) PhoneOut Protokoll eines abgehendenTelefonats

– Anwesenheit/Pause AttendanceList speichert Arbeits- und Pau-senzeiten

– Kommentar Comment

– Prozess-Workflow ProcessWorkflow ermöglicht die Definiti-on mehrerer Schritte zurBearbeitung einer Aufgabe

– Rundschreiben / E-Mail JMail Serienbriefe, Newsletter etc.– Ticket Ticket

Tabelle A.5: Subtypen des Objekts Anmerkung

Aufwände erfassen finanzielle und zeitliche Werte, die zur Erfüllung eines Pro-jektauftrags eingeplant bzw. aufgewandt werden.


Aufwand JEffort

– Buchung Personal Personalkosten als Produkt der aufge-wandten Arbeitszeit und des Stundensat-zes eines Mitarbeiters

– Plan Forecast im Aufwandsplan eines Projekts veran-schlagte Arbeitszeit

– Sachkosten Fixed Kosten von Arbeitsmaterial und Dienst-leistungen dritter Unternehmen

Tabelle A.6: Subtypen des Objekts Aufwand

vi Diplomarbeit – Robert Kalweit


A.2 Konfiguration eines Ticket-Lebenszyklus

A.2 Konfiguration eines Ticket-Lebenszyklus

Die Konfiguration des Lebenszyklus sämtlicher Tickets erfolgt über eine XML-Datei, in der nach einem vordefinierten Schema Status und mögliche Statusüber-gänge definiert werden. Dabei wird zwischen internen und externen Akteuren(Actor) unterschieden. Listing A.1 zeigt auszugsweise die möglichen Status-übergänge von Tickets des Projektron BCS Supportsystems. Auslassungen sindentsprechend gekennzeichnet.

Listing A.1: Konfiguration des Lebenszyklus der Projektron Support Tickets1 <?xml version="1.0" encoding="iso−8859−1" ?>2

3 <BCS−Configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema−instance"xsi:noNamespaceSchemaLocation="http://schema.projektron.de/bcs/ServerConfigTickets.xsd">

4

5 <TicketConfiguration>6 <TicketProcessInstructions>7 <StateGuidedTicketProcessInstructions />8 </TicketProcessInstructions>9

10 <TicketStates>11 <State Name="∗">12 <ChangeAttributes>13 <Actor Name="∗">14 <SavePreviousInternalState Name="previousTicketWorkflowState" />15 </Actor>16 </ChangeAttributes>17 </State>18 <State Name="010−eingetragen">19 <ChangeStates>20 <Actor Name="intern" AllowAll="true" />21 <Actor Name="extern">22 <ChangeState Name="035−schliessen" />23 </Actor>24 </ChangeStates>25 </State>26 <State Name="020−offen">27 <ChangeStates>28 <Actor Name="intern" AllowAll="true" />29 <Actor Name="extern">

Diplomarbeit – Robert Kalweit vii



30 <ChangeState Name="031−klaerung−support" />31 <ChangeState Name="035−schliessen" />32 </Actor>33 </ChangeStates>34 </State>35 <State Name="030−klaerung−kunde" StateGroups="Question,Customer">[...]36 <State Name="031−klaerung−support" StateGroups="Question,Support">[...]37 <State Name="035−schliessen">[...]38 <State Name="040−absprache">[...]39 <State Name="048−angebot−erstellen">[...]40 <State Name="050−angeboten">[...]41 <State Name="051−beauftragt">[...]42 <State Name="052−nicht−beauftragt">[...]43 <ChangeAttributes>44 <Actor Name="extern">45 <SetValue Name="changeCustomerState" Value="rejected" />46 </Actor>47 </ChangeAttributes>48 </State>49 <State Name="060−aufgenommen">[...]50 <State Name="070−eingeplant">[...]51 <State Name="080−inarbeit">[...]52 <State Name="081−fertig">[...]53 <State Name="090−abnahme">[...]54 <State Name="091−abgenommen">[...]55 <State Name="100−geschlossen">56 <ChangeStates>57 <Actor Name="intern" AllowAll="true" />58 </ChangeStates>59 </State>60 </TicketStates>61 </TicketConfiguration>62

63 </BCS−Configuration>

viii Diplomarbeit – Robert Kalweit


B Interviews mit Mitarbeitern derHypoport AG

B.1 Zusammenfassung des Gesprächs

mit Herrn Heide

Im Folgenden sind die Gesprächsnotizen aus dem Interview mit Herrn SebastianHeide, ScrumMaster bei der Hypoport AG, zusammengefasst (normaler Text).Diese wurden Herrn Heide per E-Mail übermittelt und um Kommentare bzw.Korrekturen ergänzt (kursiver Text). Das Gespräch fand am 08.05.2008 statt.

Product Owner:â je 1 Projektleiter fungiert als PO für einen Kunden und stellt das jeweiligeProduct Backlog zusammenâ Ganz so ist es nicht, da wir ja pro Produkt oft mehrere Kunden haben. Für jedesProdukt gibt es ein Backlog, das jedoch von mehreren Projektmanagern gepflegtwird, welche Anforderungen von verschiedenen Kunden verwalten.

ScrumMaster:â gute Adaption des Scrum Prozesses, daher keine Notwendigkeit eines Vollzeit-ScrumMasters für jedes Projektâ Wir haben allerdings bereits festgestellt, dass 2 Scrum Master für alle Entwick-lerteams nicht ausreichen. Es wird demnach wahrscheinlich bald eine Vollzeitstelleplus weitere Ressourcen geben.â daher betreut 1 ScrumMaster mehrere Projekte/Teamsâ Kommt es vor, dass diese Projekte oder ihre Teams konkurrieren und der (fürbeide zuständige) ScrumMaster so evtl. bei der Beseitigung von impediments inEntscheidungskonflikte gerät?â Ja

Diplomarbeit – Robert Kalweit ix


B Interviews mit Mitarbeitern der Hypoport AG

Team:â 5-8 Personen, vollkommen Scrum-konformâ Überlastungen vermeiden durch Planung von 6h/Tag für Sprint Aufgabenâ Nebeneffekt: Genug Zeit für permanenten Team-internen Wissensaustauschohne Defizite (gegenüber dem Plan) bzgl. der Aufgabenbearbeitung

Product Backlog:â Hierarchisch nach Kunden und Features geordnetâ Das Product Backlog wird aus verschiedenen Listen gespeist und stellt letzt-endlich eine priorisierte Liste der User Stories dar.â komplette Repräsentation sowohl in JIRA als auch „dreifach“ in BCS (je eineEntwicklungs-, Test- und PM-Aufgabe)â Während Jira echte Product Backlogs - gemäß Scrum - enthält (also produkt-bezogen), wird in BCS die „Kundenhierarchie“ abgebildet. Hier wird eher eineübergeordnete Projektmanagementsicht abgebildet.

Sprint Backlog:â Tasks als User Stories, Planung in JIRAâ keine Notwendigkeit der Repräsentation im BCS, da es für Zeiterfassung aus-reicht egal ist, wie die Tasks geplant sindâ Sprint Backlog Items (Aufgaben) werden den Mitarbeitern eines Teams danntrotzdem vom PL Top-Down zugewiesen (in JIRA für den Workflow, in BCS le-diglich zur Zeiterfassung für die Abrechnung)â Jedes Produkt-Team wählt aus dem jeweiligen Product-Backlog die Themen,die es im nächsten Sprint bearbeiten wird -> Sprint-Backlog.â jeder Mitarbeiter hat also einen Pool an Aufgaben deren Bearbeitungsreihen-folge ihm soweit nicht anders abgesprochen/vorgeschrieben freistehtâ Dementsprechend hat jedes Team ein Sprint-Backlog. Die Bearbeitungsreihen-folge ist implizit durch die Priorisierung der Themen bereits gegeben. Das Teamkann jedoch - sofern es für die Bearbeitung sinnvoller ist - auch einzelne Thmenin der Bearbeitung vorziehen.

Product Increment:â feste, produktabhängige Releasezyklen (Hauptprodukt EUROPACE: 1 Relea-se = 3 Sprints)â Normalerweise Ja, doch: Je nach Sachlage können Releasezyklen auch verlän-

x Diplomarbeit – Robert Kalweit


B.1 Zusammenfassung des Gesprächs mit Herrn Heide

gert werden (z.B.: viele Refactorings, daher wenig Kundenthemen im Release).â Sprint-Dauer von i.d.R. 4 Wochen

Sprint Planning Meeting:â Scrum-konform sucht sich das Team abhängig von der vom Projektleiter (Pro-duct Owner) festgelegten Priorität, die UserStories aus, die umgesetzt werden

Sprint Retrospective Meeting:â zur internen Verbesserung der Prozesse, nach anfänglichen Schwierigkeiten vor1,5 Jahren („Jeder sagt nur, was ihn nervt.“) mittlerweile tatsächlich produktiveVorschläge und deren Umsetzung

Sprint Review Meeting:â hatten wir nicht erwähnt: Vermutlich aber ebenfalls konform zum Scrum Pro-zess - das Team präsentiert dem Projektleiter (eventuell auch anwesenden Kundenals Stakeholdern) fertige und getestete Funktionalitätâ Korrekt

Daily Scrum:â hatte ich leider auch nicht erwähnt: Daher vermute ich, es findet tatsächlichwie vorgesehen täglich und im entsprechenden Rahmen statt (pro Team also ca.15 Minuten, da ein ScrumMaster ja mehrere Teams hat, hat dieser also auchmehrere Daily Scrums täglich?)â Richtig: Im Schlimmsten Fall (Urlaub des anderen ScrumMasters) hat einScrumMaster bis zu 7 Daily Scrum Meetings am Morgen.

â Wenn ich mir JIRA so anschaue und ich Sie richtig verstanden habe, dannerfolgt die feingranulare Projektplanung (Release > Feature > Epic > User Story)ausschließlich dort.â So ist das schon in etwa richtig.

â Daraus folgt die Frage: Wenn nicht, welche der folgenden Funktionen aus demProjektron Repertoire nutzen Sie oder die jeweiligen Projektleiter?â Schritte des Projekt-Assistenten: Stamm (obligatorisch), Kostenrechnung, Vor-lagen, Strukturplan, Zeitplanung, Teamplanung, Aufwandsplan, Ressourcenaus-lastung, Auftragsplan, Dateiablageâ Durchführung: Prozess-Workflows, Checklisten, Wiedervorlagenâ Auswertungen: Gesamtkosten/Projekt, Gesamtkostendiagramm, Aufwände/Pro-jekt, Aufwände/Projekt intern, Aufwandsliste/Aufgabe, Aufwände/Mitarbeiter,

Diplomarbeit – Robert Kalweit xi



Aufwandsliste/Mitarbeiter, Aufwandsdiagramm, Personalkosten/Projekt, Perso-nalkosten/Mitarbeiter, Personalkostendiagramm, Personalkostenliste/Aufgabe, Sach-kosten/Projekt, Sachkostendiagramm, Historie, Berichtserstellung, Berichteâ Dazu kann ich Ihnen leider keine Auskunft geben. BCS benutze ich ausschließ-lich zum Buchen meiner Arbeitszeit.

â Gab es in der Vergangenheit, also nach der Etablierung von JIRA bereitsVersuche, die Prozesse, die momentan in JIRA abgebildet und gelebt werden, aufProjektron BCS zu übertragen? Wenn ja, woran lag es, dass diese Übertragunggescheitert ist?â Bei der Einführung von BCS wurde dies Option kurz überprüft, jedoch schnellverworfen. Seitdem gab es keine Versuche.

B.2 Zusammenfassung des Gesprächs

mit Herrn Gimbel

Noch offene Punkte wurden in einem Interview mit Herrn Robert Gimbel, Pro-jektmanager bei der Hypoport AG, besprochen. Das Gespräch fand am 19.05.2008statt.

â Bank01 Õ Feature01, Feature02â Bank02 Õ Feature03, Feature04

â Release Õ [JIRA Ticketnr.]_UP Õ PM, Dev, Testâ Thema abgeschlossen Õ Aufgabe in BCS geschlossen

â Tickets können Tickets enthalten usw., beliebig tiefe Hierarchieâ epics enthalten user stories, die wiederum verschiedene Akzeptanztests mitmehreren unterschiedlichen lifecycles enthaltenâ Bsp. user story: priorisiert Õ Umsetzung bestätigt Õ in Umsetzung Õ umge-setztâ Bsp. Akteptanztest: erstellt/angelegt Õ zu testen Õ getestet Õ integrativ ge-testet

xii Diplomarbeit – Robert Kalweit


B.2 Zusammenfassung des Gesprächs mit Herrn Gimbel

â Einblick in JIRA: Bessere Nutzbarkeit durch geringere Klick-Häufigkeit beimAusführen von Aktionen.â JIRA nicht perfekt, aber Vorteile gegenüber Projektron BCS

â Was kostet das Release? Õ Was können wir kriegen?

â Erfolgt die Aufgabenverteilung an einzelne Mitarbeiter explizit von überge-ordneter Stelle aus oder wird das ganze Team allen Aufgaben zugewiesen, undorganisiert sich dann selbst? (In JIRA/in Projektron)â Aufgabenverteilung an das Team als ganzes - wer was umsetzt ist mir letztend-lich egal.â Welche der folgenden Funktionen aus dem Projektron Repertoire nutzen Sie?â Auswertungen: Gesamtkosten/Projekt, Gesamtkostendiagramm, Aufwände/Pro-jekt, Aufwände/Projekt intern, Aufwandsliste/Aufgabe, Aufwände/Mitarbeiter,Aufwandsliste/Mitarbeiter, Aufwandsdiagramm, Personalkosten/Projekt, Perso-nalkosten/Mitarbeiter, Personalkostendiagramm, Personalkostenliste/Aufgabe, Sach-kosten/Projekt, Sachkostendiagramm, Historie, Berichtserstellung, Berichteâ Ich nutze nur Auswertung Aufwände pro Projekt.

Auf Nachfrage am 31.07.2008 hat sich gezeigt, dass die Lebenszyklen verschiede-ner Tickettypen angepasst wurden. Abbildung B.1 veranschaulicht die Statusvon vier Tickettypen (epics und user stories werden gleich behandelt). Zusätzlichenthält das Diagramm Akteure, die für die Tickettypen verantwortlich sind.

Darüber hinaus ist „integrativ getestet“ kein Status eines Akzeptanztests, sondernbedeutet, dass eine user story auf einem Integrationssystem erfolgreich getestetwurde und veröffentlicht werden kann (Release).

Diplomarbeit – Robert Kalweit xiii



Abbildung B.1: JIRA Tickettypen und -status

xiv Diplomarbeit – Robert Kalweit


C Diagramme

Diplomarbeit – Robert Kalweit xv


C Diagramme

Abbildung C.1: Aktivitätsdiagramm des Scrum Prozesses, Quelle: [Eclipse]

xvi Diplomarbeit – Robert Kalweit


Abbildung C.2: Detailliertes Aktivitätsdiagramm des Scrum Prozesses

Diplomarbeit – Robert Kalweit xvii


C Diagramme

Abbildung C.3: Aktivitätsdiagramm des Scrum Prozesses der Hypoport AG

xviii Diplomarbeit – Robert Kalweit


D Konzeptgraphiken

Diplomarbeit – Robert Kalweit xix


D Konzeptgraphiken

Abbildung D.1: Strukturplan eines Scrum Projekts im Anzeigenmodus

xx Diplomarbeit – Robert Kalweit


Abbildung D.2: Strukturplan eines Scrum Projekts im Bearbeitungsmodus

Diplomarbeit – Robert Kalweit xxi


D Konzeptgraphiken

Abbildung D.3: Mittels Lebenszyklus eingeschränkte Arbeitsabläufe eines Bugs

xxii Diplomarbeit – Robert Kalweit


Abbildung D.4: Uneingeschränkte Arbeitsabläufe eines ChangeRequests

Diplomarbeit – Robert Kalweit xxiii


D Konzeptgraphiken

Abbildung D.5: Ticketansicht mit abstrakten Aufwänden (und Aufwänden unter-geordneter Tickets), Arbeitsabläufen und Beziehungen (Unterge-ordnet, Duplikat, Verwandt, Vorgänger, Nachfolger)

xxiv Diplomarbeit – Robert Kalweit


Abbildung D.6: Integration des Burndown Charts in die auf Aufgabenebene ver-fügbaren Auswertungen

Diplomarbeit – Robert Kalweit xxv


D Konzeptgraphiken

xxvi Diplomarbeit – Robert Kalweit


E Beilage CD-ROM undOnline-Testsystem

Auf der beiliegenden CD-ROM befinden sich:

â Die schriftliche Ausarbeitung der Diplomarbeit als PDF-Dateiâ Projektron BCS in der Version 6.6.2.betaâ Atlassian JIRA in der Version 3.12.3â Die erstellten UML Diagramme

Online-Testsystem:

Darüber hinaus steht ein Projektron BCS System der entsprechenden Version zuTestzwecken unter folgender Webadresse zur Verfügung:

http://kalweit.demo01.projektron.de

Zugänge zu diesem System werden auf Nachfrage an die zu Beginn dieser Arbeitaufgeführte E-Mail-Adresse erzeugt.

Diplomarbeit – Robert Kalweit xxvii

http://kalweit.demo01.projektron.de


E Beilage CD-ROM und Online-Testsystem

xxviii Diplomarbeit – Robert Kalweit


Literaturverzeichnis

Fachbücher

Angermeier 2005Angermeier, Georg: Projektmanagement-Lexikon. Projekt Maga-zin, 2005 http://www.projektmagazin.de/glossar/index.html. – ISBN3000181148

Balzert 2000Balzert, Helmut: Lehrbuch der Software-Technik. Bd. Band 1: Software-Entwicklung. Spektrum Akademischer Verlag, 2000. – ISBN 3827404800

Cohn 2004Cohn, Mike: User Stories Applied: For Agile Software Development. Addison-Wesley, 2004. – ISBN 0321205685

DeMarco 1998DeMarco, Tom: Der Termin. Ein Roman über Projektmanagement. CarlHanser Verlag München, 1998. – ISBN 3446194320

Derby und Larsen 2006Derby, Esther ; Larsen, Diana: Agile Retrospectives: Making Good TeamsGreat. Pragmatic Programmers, 2006. – ISBN 0977616649

DIN 1987DIN: DIN 69901-69905: Projektwirtschaft. Deutsches Institut für Normung,1987-2000

Gaulke 2004Gaulke, Markus: Risikomanagement in IT-Projekten. Oldenbourg Wissen-schaftsverlag GmbH, 2004. – ISBN 3486275992

Diplomarbeit – Robert Kalweit XVII

http://www.projektmagazin.de/glossar/index.html



Greenleaf 2002Greenleaf, Robert K.: Servant Leadership: A Journey into the Nature ofLegitimate Power and Greatness. 25th anniversary ed. New York : PaulistPress, 2002. – ISBN 0809105543

Krallmann u. a. 2002Krallmann, Hermann ; Frank, Helmut ; Gronau, Norbert: Systemanaly-se im Unternehmen. Bd. 4., vollst. überarb. Aufl. Oldenbourg Wissenschafts-verlag GmbH, 2002. – ISBN 3486272039

Oestereich und Weiss 2008Oestereich, Bernd ; Weiss, Christian: APM - Agiles Projektmanagement.Erfolgreiches Timeboxing für IT-Projekte. Dpunkt Verlag GmbH, 2008. –ISBN 3898643867

Pichler 2007Pichler, Roman: Scrum - Agiles Projektmanagement erfolgreich einsetzen.Dpunkt.Verlag GmbH, 2007. – ISBN 3898644782

PMBoK 2004A Guide to the Project Management Body of Knowledge: Dritte Ausgabe.Project Management Institute (PMI), 2004. – ISBN 1930699727

Rinza 1998Rinza, Peter: Projektmanagement: Planung, Überwachung und Steuerungvon technischen und nichttechnischen Vorhaben. Springer-Verlag, 1998. –ISBN 3540640215

Schwaber 2004Schwaber, Ken: Agile Project Management with Scrum. Microsoft Press,2004. – ISBN 073561993X

Fachzeitschriften

Pichler 2008Pichler, Roman: Erfolgsfaktor Product Owner. In: OBJEKTspektrum(2008), Mai/Juni, Nr. 3, S. 14–15

XVIII Diplomarbeit – Robert Kalweit



Wolf und Roock 2008Wolf, Henning ; Roock, Arne: Agilität wird Mainstream: Ergebnisse derOnline-Umfrage 2008. In: OBJEKTspektrum (2008), Mai/Juni, Nr. 3, S. 10–13

Internetquellen

Ambler 2007Ambler, Scott W.: Agile Adoption Rate Survey: March 2007.Version: 2007. http://www.ambysoft.com/surveys/agileMarch2007.html,Abruf: 28.04.2008. Ambysoft Inc.

Beck u. a. 2001Beck, Kent ; Beedle, Mike ; Bennekum, Arie van ; Cockburn, Alistair ;Cunningham, Ward ; Fowler, Martin ; Grenning, James ; Highsmith,Jim ; Hunt, Andrew ; Jeffries, Ron ; Kern, Jon ; Marick, Brian ; Mar-

tin, Robert C. ; Mellor, Steve ; Schwaber, Ken ; Sutherland, Jeff ;Thomas, Dave: Manifesto for Agile Software Development. Version: 2001.http://www.agilemanifesto.org/, Abruf: 05.05.2008

Behrens 2006Behrens, Pete: 2006 Agile Project Management Tooling Sur-vey. Version: 2006. http://www.trailridgeconsulting.com/

apm-tooling-survey-2006.html, Abruf: 28.04.2008. Trail Ridge Con-sulting

Cohn 2007Cohn, Mike: Leader of the Band: Six Attributes of a Good Scrum-Master. Version: 2007. http://www.scrumalliance.org/articles/

36-leader-of-the-band, Abruf: 07.05.2008. Scrum Alliance Weekly Co-lumn 02-05-2007

EclipseEclipse Foundation, The: Scrum. http://epf.eclipse.org/wikis/

scrum/, Abruf: 17.05.2008

Kniberg 2006Kniberg, Henrik: Scrum and XP from the Trenches. Version: 2006.

Diplomarbeit – Robert Kalweit XIX

http://www.ambysoft.com/surveys/agileMarch2007.html

http://www.agilemanifesto.org/

http://www.trailridgeconsulting.com/apm-tooling-survey-2006.html

http://www.trailridgeconsulting.com/apm-tooling-survey-2006.html

http://www.scrumalliance.org/articles/36-leader-of-the-band

http://www.scrumalliance.org/articles/36-leader-of-the-band

http://epf.eclipse.org/wikis/scrum/

http://epf.eclipse.org/wikis/scrum/



http://www.infoq.com/minibooks/scrum-xp-from-the-trenches, Ab-ruf: 12.05.2008

MGS 2005The Scrum Development Process. Version: 2005. http://www.

mountaingoatsoftware.com/scrum_figures, Abruf: 10.05.2008. MountainGoat Software

MGS 2008An Alternative Release Burndown Chart. http://www.

mountaingoatsoftware.com/alt_releaseburndown, Abruf: 21.05.2008.Mountain Goat Software

oose 2008UML 2.0 Notationsübersicht. http://www.oose.de/downloads/

uml-2-Notationsuebersicht-oose.de.pdf, Abruf: 01.08.2008. ooseInnovative Informatik GmbH

ProjektronProjektron: Projektmanagement-Software Projektron BCS. http://www.projektron.de/

Schwaber 2006Schwaber, Ken: No Applause, Please. Version: 2006. http:

//www.scrumalliance.org/articles/31-no-applause-please, Abruf:19.05.2008. Scrum Alliance Weekly Column 12-04-2006

Schwaber 2007aSchwaber, Ken: Scrum’s Neat, But I Have a Schedule toMeet. Version: 2007. http://www.scrumalliance.org/articles/

56-scrums-neat-but-i-have-a-schedule-to-meet, Abruf: 09.05.2008.Scrum Alliance Weekly Column 07-09-2007

Schwaber 2007bSchwaber, Carey: The Truth About Agile Processes. Frank Answers ToFrequently Asked Questions. Version: 2007. http://www.forrester.com/

Research/Document/0,7211,41836,00.html, Abruf: 28.04.2008. ForresterResearch, Inc.

XX Diplomarbeit – Robert Kalweit

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

http://www.mountaingoatsoftware.com/scrum_figures

http://www.mountaingoatsoftware.com/scrum_figures

http://www.mountaingoatsoftware.com/alt_releaseburndown

http://www.mountaingoatsoftware.com/alt_releaseburndown

http://www.oose.de/downloads/uml-2-Notationsuebersicht-oose.de.pdf

http://www.oose.de/downloads/uml-2-Notationsuebersicht-oose.de.pdf

http://www.projektron.de/

http://www.projektron.de/

http://www.scrumalliance.org/articles/31-no-applause-please

http://www.scrumalliance.org/articles/31-no-applause-please

http://www.scrumalliance.org/articles/56-scrums-neat-but-i-have-a-schedule-to-meet

http://www.scrumalliance.org/articles/56-scrums-neat-but-i-have-a-schedule-to-meet

http://www.forrester.com/Research/Document/0,7211,41836,00.html

http://www.forrester.com/Research/Document/0,7211,41836,00.html



Scr 2008Scrum Artifacts. http://www.scrumalliance.org/view/scrum_artifacts,Abruf: 21.05.2008. The Scrum Alliance, Inc.

Standish 1994Standish Group, The: The CHAOS Report. Version: 1994-2004. http:

//net.educause.edu/ir/library/pdf/NCP08083B.pdf, Abruf: 02.06.2008

VMXT 2007Dokumentation des V-Modell XT. Version: 2007. http://www.v-modell-xt.de/, Abruf: 17.05.2008

Wake 2003Wake, William C.: INVEST in Good Stories, and SMART Tasks.Version:August 2003. http://www.xp123.com/xplor/xp0308/index.

shtml, Abruf: 11.05.2008

Eingangszitate der Kapitel

Brooks 1995Brooks, Frederick P.: The Mythical Man-month. Essays on Software Engi-neering. Addison-Wesley, 1995. – ISBN 0201835959

Drosdek 2005Drosdek, Andreas: Die wichtigsten Philosophen für Manager. CampusVerlag, 2005. – ISBN 3593378221

Gabler 2000Zitate für Manager. Gabler Verlag, 2000. – ISBN 3409116079

Iacocca 1993Iacocca, Lee: Iacocca: An Autobiography. Reissue. Bantam USA, 1993. –ISBN 0553251473

Müller 2006Müller, Sandra: Methodisches Erfinden im Personalmanagement. Deut-scher Universitäts-Verlag, 2006. – ISBN 3835005197

Diplomarbeit – Robert Kalweit XXI

http://www.scrumalliance.org/view/scrum_artifacts

http://net.educause.edu/ir/library/pdf/NCP08083B.pdf

http://net.educause.edu/ir/library/pdf/NCP08083B.pdf

http://www.v-modell-xt.de/

http://www.v-modell-xt.de/

http://www.xp123.com/xplor/xp0308/index.shtml

http://www.xp123.com/xplor/xp0308/index.shtml



Shavinina 2003Shavinina, Larisa V.: The International Handbook on Innovation. AcademicPress Inc., 2003. – ISBN 008044198X

Shaw 1903Shaw, George B.: Man and Superman. New Ed (28. September 2000). Pen-guin Classics, 1903. – 288 S. – ISBN 0140437886

XXII Diplomarbeit – Robert Kalweit


Eidesstattliche Erklärung

Ich versichere hiermit, dass ich meine Diplomarbeit mit dem Thema


selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfs-mittel benutzt habe. Die Arbeit wurde bisher keiner anderen Prüfungsbehördevorgelegt und auch nicht veröffentlicht.

Wörtlich oder dem Sinn nach aus anderen Werken entnommene Stellen sind unterAngabe der Quellen kenntlich gemacht.

Berlin, den 5. August 2008

Robert Kalweit

Diplomarbeit – Robert Kalweit XXIII

Agiles Projektmanagement mit Projektron BCS › resources › projects › studies ›...

Documents

Transcript of Agiles Projektmanagement mit Projektron BCS › resources › projects › studies ›...