Agiles Projektmanagement mit Projektron BCS

Größe: px
Ab Seite anzeigen:

Download "Agiles Projektmanagement mit Projektron BCS"

Transkript

1 Agiles Projektmanagement mit Projektron BCS Diplomarbeit im Fachbereich Informatik und Medien vorgelegt von: Robert Kalweit Matrikelnummer: Studiengang: Praxispartner: Betreuer: Gutachter: Medieninformatik Projektron GmbH Prof. Dr. Roland Petrasch Prof. Dr.-Ing. Dieter Pumpe

2 Copyright 2008 Version vom 5. August 2008 Agiles Projektmanagement mit Projektron BCS Vorgelegt im Sommersemester 2008 Autor: Robert Kalweit Matrikelnummer: Adresse: Mollstr. 33, Berlin Telefon: 030/ Hochschule: Technische Fachhochschule Berlin Studiengang: Medieninformatik Diplom Schwerpunkt: Medien Betreuender Hochschullehrer: Prof. Dr. Roland Petrasch Zweitgutachter: Prof. Dr.-Ing. Dieter Pumpe Satz: L A TEX 2ε Lektorat: Stefan Lützkendorf Oliver Heinze Claudia Deckert Kay Schönemann Jens Volckmann Dieses Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtgesetzes ist ohne Zustimmung des Autors unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, 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.

3 Zusammenfassung Die vorliegende Arbeit verdeutlicht die zunehmende Bedeutung agiler Prozesse zur Softwareentwicklung und zum Projektmanagement (PM). Motiviert durch diesen Trend wird untersucht, inwiefern die Anwendung agiler Vorgehensweisen mit Projektron BCS, einer PM-Software, möglich ist. Ein Überblick über PM im Allgemeinen, agiles Projektmanagement und Scrum im Speziellen schafft die Grundlage für weitere Betrachtungen. Projektron BCS wird vorgestellt und seine Anwendung in einem agilen Umfeld analysiert. Aus den daraus resultierenden Anforderungen wird ein Konzept erarbeitet, das darauf abzielt, agile Vorgehensweisen 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 development and project management (PM) processes. Motivated by this tendency it is being examined how far it is possible to apply these agile processes with the PM-software Projektron BCS. An overview of project management in general, agile PM and Scrum in particular establishes the basis for further research. After Projektron BCS is being introduced, its application to an agile environment is analyzed. Based upon the resulting requirements a concept is developed. The aim of this concept is strengthening the support of Projektron BCS for agile processes. Keywords agile, processes, software development, project management, Projektron BCS, Scrum, requirements Diplomarbeit Robert Kalweit

4 Diplomarbeit Robert Kalweit

5 Vorwort Die vorliegende Diplomarbeit entstand während meiner Tätigkeit bei der Projektron GmbH als Student der Medieninformatik im Fachbereich Informatik und Medien der Technischen Fachhochschule Berlin. Mein ganz besonderer Dank gilt meinem Betreuer Herrn Prof. Dr. Roland Petrasch für seine engagierte Vermittlung mit der Projektron GmbH und seine stets konstruktive Kritik. Darüber hinaus danke ich besonders den Geschäftsführern der Projektron GmbH Herrn Maik Dorl und Herrn Dr. Marten Huisinga, die viel Vertrauen in mich setzten und sich überaus kurzfristig bereit erklärten, dieses Thema bei Projektron umsetzen zu lassen. Weiterhin danke ich ich allen Kollegen bei Projektron, die mich freundlich aufgenommen und stets unterstützt haben. Dabei hebe ich besonders Herrn Stefan Lü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 besonders für Scrum geweckt und gefördert hat. Nicht zuletzt aufgrund dieser Begeisterung habe ich ein Thema mit Bezug zu Projektmanagement gewählt. Im Bereich der Informatik und damit auch in der vorliegenden Arbeit werden viele englische Begriffe verwendet. Wörtliche Übersetzungen ins Deutsche sind nicht immer passend. Daher wurde darauf geachtet, für englische Begriffe treffende oder allgemein anerkannte Übersetzungen zu verwenden und eingangs zu verdeutlichen. In der Folge werden der englische und deutsche Begriff synonym verwendet. Diplomarbeit Robert Kalweit

6 Diplomarbeit Robert Kalweit

7 Inhaltsverzeichnis Inhaltsverzeichnis Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Verzeichnis der Listings VII IX XI XIII XV 1 Einleitung 1 2 Projektmanagement Grundlagen Projektmanagement Agiles Projektmanagement Projektmanagementsysteme Scrum Rollen Artefakte Prozess Projektron BCS Funktionen Architektur Flexibilität Scrum bei der Hypoport AG Prozess und Software-Anforderungen Vergleich der Anforderungen mit Projektron BCS Vorgaben Diplomarbeit Robert Kalweit VII

8 6 Anpassungen Vorbetrachtungen Umsetzung und Konfigurierbarkeit Integration Fazit und kritische Bewertung 83 Anhang i A Technische Details iii A.1 Datenstruktur von Projektron BCS iii A.2 Konfiguration eines Ticket-Lebenszyklus vii B Interviews mit Mitarbeitern der Hypoport AG ix B.1 Zusammenfassung des Gesprächs mit Herrn Heide ix B.2 Zusammenfassung des Gesprächs mit Herrn Gimbel xii C Diagramme xv D Konzeptgraphiken xix E Beilage CD-ROM und Online-Testsystem xxvii Literaturverzeichnis Eidesstattliche Erklärung XVII XXIII VIII Diplomarbeit Robert Kalweit

9 Abkürzungsverzeichnis API APM BCS CSS CSV DoD DOM EPF FDD GUI HTML I18n INVEST IT J2SE JDBC JSP OID PDCA PM PMI PMS WebDAV XML XP Application Programming Interface Agiles Projektmanagement Business Coordination Software Cascading Style Sheets Comma-Separated Values Definition of Done Document Object Model Eclipse Process Framework Feature Driven Development Graphical User Interface Hypertext Markup Language Internationalization independent, negotiable, valuable, estimable, small, testable Informationstechnik / information technology Java 2 Platform, Standard Edition Java Database Connectivity JavaServer Pages Objekt-ID / Objekt-Identifikation Plan-Do-Check-Act Projektmanagement / project management Project Management Institue Projektmanagementsystem Web-based Distributed Authoring and Versioning Extensible Markup Language Extreme Programming Diplomarbeit Robert Kalweit IX

10 X Diplomarbeit Robert Kalweit

11 Abbildungsverzeichnis 1.1 Verbreitung agiler Softwareentwicklung Anzahl eingesetzter PM-Tools Systemanalyse im Unternehmen Magisches Dreieck des Projektmanagements PDCA-Zyklus in Verbindung mit PM-Prozessgruppen Geschichte von Vorgehensmodellen Anwendung agiler Vorgehensweisen Scrum Aktivitätsdiagramm des Scrum Prozesses Aktivitätsdiagramm des Sprint Planning Meetings Aktivitätsdiagramm des Daily Scrum Meetings Aktivitätsdiagramm des Sprint Review Meetings Aktivitätsdiagramm des Sprint Retrospective Meetings Release Burndown Chart Arbeitsbereiche in Projektron BCS Projektron BCS Projektassistent Aufbau einer Projektron BCS Installation Webseitenstruktur von Projektron BCS WebConfig-Editor zum Bearbeiten der GUI Zusätzliche Attribute eines Projekts Acht Elemente der Europace Plattform Anforderungserhebung eines Projekts der Hypoport AG Projektron BCS Strukturplan eines Hypoport-Projekts Lebenszyklen von user stories und Akzeptanztests Definition der Grundlast und Ressourcenauslastung Einer Organisation zugeordnete Projekte Diplomarbeit Robert Kalweit XI

12 5.7 Product Backlog in Projektron BCS Schematische Datenstruktur von Aufgaben und Anmerkungen Auszug aus der Datenstrukturinfo einer Aufgabe und Statusanzeige Änderungshistorie im Projektron BCS Ticketsystem Hierarchische Anordnung von Tickets im Strukturplan Umwandlung von Tickets Lebenszyklus eines Bugs Verbindliche und nicht verbindliche Lebenszyklen Erfolgsmeldung und Warnung nach Umwandlung Burndown Chart in Projektron BCS Integration der Anzeige von Tickets im Strukturplan Integration der untergeordneten Tickets und Arbeitsabläufe Kompatibilität zur gegenwärtigen Teamplanung Aufwandsplanung auf Sprintebene B.1 JIRA Tickettypen und -status xiv C.1 Aktivitätsdiagramm des Scrum Prozesses xvi C.2 Detailliertes Aktivitätsdiagramm des Scrum Prozesses xvii C.3 Aktivitätsdiagramm des Scrum Prozesses der Hypoport AG... xviii D.1 Strukturplan eines Scrum Projekts im Anzeigenmodus xx D.2 Strukturplan eines Scrum Projekts im Bearbeitungsmodus.... xxi D.3 Mittels Lebenszyklus eingeschränkte Arbeitsabläufe eines Bugs.. xxii D.4 Uneingeschränkte Arbeitsabläufe eines ChangeRequests xxiii D.5 Ticketansicht mit Aufwänden, Arbeitsabläufen und Beziehungen. xxiv D.6 Integration des Burndown Charts xxv XII Diplomarbeit Robert Kalweit

13 Tabellenverzeichnis 3.1 Tabellarisches Product Backlog Projektron BCS Konfigurationsdateien JIRA Tickethierarchie der Hypoport AG Anforderungen an die Softwareunterstützung Erfüllung der Anforderungen durch die Software Attribute eines ChangeState-Elements A.1 Subtypen des Objekts Organisation iii A.2 Subtypen des Objekts Person iv A.3 Subtypen des Objekts Projekt v A.4 Subtypen des Objekts Aufgabe v A.5 Subtypen des Objekts Anmerkung vi A.6 Subtypen des Objekts Aufwand vi Diplomarbeit Robert Kalweit XIII

14 XIV Diplomarbeit Robert Kalweit

15 Verzeichnis der Listings 4.1 Beispieleintrag in einer ServerConfig*.properties-Datei Minimalkonfiguration von Ticketarten Einschränkung möglicher Kindelemente Definition des Lebenszyklus eines Bugs Berücksichtigung von Status im Burndown Chart A.1 Konfiguration des Lebenszyklus der Projektron Support Tickets. vii Diplomarbeit Robert Kalweit XV

16 XVI Diplomarbeit Robert Kalweit

17 1 Einleitung Management is nothing more than motivating other people. (Lee Iacocca) Ein nicht unerheblicher Teil des Entwicklungsprozesses eines Softwareprojekts ist seine Planung. Die Qualität dieser Planung ist essentiell für den Erfolg des Projekts - so ist schlechte Planung und Schätzung einer der häufigsten Gründe des Scheiterns von Projekten. Zu den gravierendsten Risikofaktoren zählen weiterhin unvollständige und wechselnde Anforderungen, sowie mangelnde Einbeziehung der Anwender. Wird Projekterfolg an einer termin- und budgetgerechten Umsetzung gemessen, waren 1994 nur etwa 16% aller IT-Projekte erfolgreich. Wenngleich dieser Anteil bis 2004 auf 29% gestiegen ist, bedeutet dies doch, dass immer noch mehr als zwei Drittel aller Projekte nicht erfolgreich sind. (Vgl. [Standish 1994], [Gaulke 2004, S.42ff.]) Um Projekte erfolgreicher, also schneller, kosteneffizienter und qualitativ hochwertiger abzuschließen und zusätzlich den Menschen wieder in den Mittelpunkt der Softwareentwicklung zu rücken und für hohe Arbeitsmoral und gutes Betriebsklima zu sorgen, tendieren viele Unternehmen zum Einsatz agilen Projektmanagements. Laut der Business Technographics September 2006 North American And European Enterprise Software Survey verwendeten bereits 17% der nordamerikanischen und europäischen Unternehmen agile Entwicklungsprozesse. Hält der in Abbildung 1.1 dargestellte Trend an, wird dieser Anteil 2008 auf fast ein Viertel steigen. (Vgl. [Schwaber 2007b], [Wolf und Roock 2008]) Die Agile Project Management Tooling Survey belegt, dass Unternehmen aller Größenordnungen zunehmend die Möglichkeiten agiler Projektsteuerung wahrnehmen. In jeweils über 30% aller Unternehmen arbeiten entweder mehr als drei Diplomarbeit Robert Kalweit 1

18 1 Einleitung Abbildung 1.1: Verbreitung agiler Softwareentwicklung, Quelle: [Schwaber 2007b] Viertel oder nur bis zu einem Viertel aller Softwareentwickler nach agilen Vorgehensweisen. Agilität polarisiert also: Sie wird entweder umfassend, fast unternehmensweit oder nur sehr vereinzelt eingesetzt. Unternehmen mit weniger als 100 Mitarbeitern im Bereich Softwareentwicklung stellen dabei bezüglich des weitreichenden Einsatzes den größten Anteil. (Vgl. [Behrens 2006]) Vierundvierzig Prozent aller Unternehmen werten über 90% ihrer agil durchgeführten Projekte als Erfolg. Weitere dreiunddreißig Prozent bescheinigen ihren Projekten eine Erfolgsquote von 75-90%. Agile Projekte sind also überaus erfolgreich. (Vgl. [Ambler 2007]) Mehr als die Hälfte der Unternehmen, deren Entwicklungsprozess agil ist, verwendet drei bis vier Softwaretools für das Management seiner Projekte (vgl. Abbildung 1.2). Weit verbreitet sind dabei z. B. VersionOne oder ScrumWorks, die sich ausschließ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 Bereiche eines Unternehmens und beschränkt sich nicht allein auf Projektmanagement (PM). Der Fokus dieser Arbeit liegt jedoch auf der Verbesserung genau dieses Bereichs. Motiviert durch die Diskrepanz zwischen der zunehmenden Verbreitung agilen Projektmanagements und den Berichten über häufiges Scheitern von IT-Projekten wird untersucht, inwiefern die Anwendung agiler Vorgehensweisen mit Projektron BCS möglich ist. (Vgl. [Projektron], [Behrens 2006]) 2 Diplomarbeit Robert Kalweit

19 Abbildung 1.2: Anzahl eingesetzter PM-Tools, Quelle: [Behrens 2006] Daher analysiert die vorliegende Arbeit den agilen Entwicklungsprozess und den Einsatz von Projektron BCS bei der Hypoport AG, einem Kunden der Projektron GmbH. Gründe für den Einsatz weiterer Softwaretools werden untersucht. Ziel der Arbeit ist, aufzuzeigen, ob und wo Verbesserungsbedarf besteht, um agile Vorgehensweisen in Projektron BCS stärker aktiv zu unterstützen. Darauf aufbauend wird ein Konzept entwickelt, das den alleinigen Einsatz von Projektron BCS in agilen Projektmanagementumgebungen forcieren soll. Der Aufbau der Arbeit orientiert sich am Vorgehensmodell der Systemanalyse im Unternehmen. Abbildung 1.3 veranschaulicht dies. (Vgl. [Krallmann u. a. 2002]) Abbildung 1.3: Vorgehensmodell der Systemanalyse im Unternehmen und Anwendung des Modells, Quelle: [Krallmann u. a. 2002] Diplomarbeit Robert Kalweit 3

20 1 Einleitung Kapitel 1 beinhaltet die Projektbegründung. Das Problem zahlreicher nicht vollständig erfolgreicher Projekte wird beschrieben, um die Motivation der Arbeit darzulegen. Ferner wird die Zielstellung formuliert und der Aufbau der Arbeit geschildert. (Vgl. [Krallmann u. a. 2002, S.47ff.]) Kapitel 2 erläutert die Grundlagen klassischen und agilen Projektmanagements und definiert die Begriffe Vorgehensmodell und Projektmanagementsystem. Anschließend wird in Kapitel 3 das Projektmanagementsystem Scrum erklärt. In Kapitel 4 beginnt die Ist-Analyse. Die Funktionalitäten von Projektron BCS werden beschrieben und es wird aufgezeigt, wie Projektron BCS individuell angepasst werden kann. (Vgl. [Krallmann u. a. 2002, S.58ff.]) Als weiterer Teil der Ist-Analyse wird in Kapitel 5 die Anwendung des Scrum Prozesses innerhalb der Hypoport AG analysiert. Es wird als Teil des Soll-Konzepts dargelegt, welche Anpassungen an Projektron BCS notwendig sind, um die Unterstützung des Scrum Prozesses zu forcieren. Dieses Konzept wird in Kapitel 6 detailliert 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 Fazit zusammengefasst und bewertet. 4 Diplomarbeit Robert Kalweit

21 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 Begriffe Projekt und Management erklären. Grundlagen des Projektmanagements werden dargelegt. Einer kurzen Beschreibung der Wissensgebiete im PM folgt ein Überblick über die Prinzipien agilen Projektmanagements. Am Ende des Kapitels werden Vorgehensmodelle zur Softwareentwicklung und Projektmanagementsysteme 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: ein Vorhaben. Laut DIN ist ein Projekt ein Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist... ([DIN 1987], zit. n. [Angermeier 2005, S.296]) Die Zielvorgabe und zeitliche, finanzielle, personelle und andere Begrenzungen führen dabei zur Einmaligkeit der gesamten Bedingungen. (Vgl. [Angermeier 2005, S.296f.]) Das Project Management Institute (PMI) beschreibt ein Projekt als zeitlich begrenztes Vorhaben, zur Schaffung eines einmaligen Produktes, einer Dienstleistung oder eines Ergebnisses. ([PMBoK 2004, S.5]) Diplomarbeit Robert Kalweit 5

22 2 Projektmanagement Grundlagen Während die verfügbaren finanziellen und personellen Mittel sowie die verfügbare Zeit zur Erreichung der Projektziele begrenzt und damit in ihrem Umfang definiert sind, ist der genaue Lösungsweg nicht vorgegeben. Die Umsetzung des Projekts erfolgt daher schrittweise. Ein Projekt endet, wenn entweder seine Ziele erreicht 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 in manus, Hand. Beide bezeichnen Handlungen, die, so Greenleaf, das Schicksal von Menschen beeinflussen. Der Begriff des Managements beschreibt einerseits Tätigkeiten und Prozesse zur Leitung eines Unternehmens, andererseits die jeweils handelnde Personengruppe oder Institution. Im Gegensatz zur Manipulation, 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 zur Leitung im Wesentlichen einmaliger Vorhaben zur Erreichung einmaliger Ziele. Das PMI definiert Projektmanagement als die Anwendung von Wissen, Fertigkeiten, Werkzeugen und Methoden auf Projektvorgänge, um die Projektanforderungen zu erfüllen. ([PMBoK 2004, S.8]) Diese Projektanforderungen beinhalten die Ziele und Ergebnisse des Projekts, die mit entsprechendem Inhalt und Umfang erreicht werden sollen, sowie die Aufwände in Form von Zeit und Kosten. Die Konkurrenz zwischen Zeit, Kosten und Inhalt und Umfang wird durch das magische Dreieck (Abbildung 2.1) dargestellt. Ziel des Projektmanagements ist es, die drei genannten Faktoren auszugleichen und ein Projekt mit hoher Qualitä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 angewandt. Dies verdeutlicht der Zyklus Planen-Ausführen-Prüfen-Handeln (Plan- Do-Check-Act, PDCA). Das Ergebnis eines Teils des Zyklus ist dabei Grundlage für den folgenden Teil: Der Projektplan (Plan) liegt der Ausführung (Do) zu Grunde. Der Fortschritt der Ausführung wird wiederum auf Abweichungen vom 1 Im Gegensatz zum Betrieb, dessen Arbeit stets andauert, und dessen Ziel die Aufrechterhaltung des Geschäfts ist. ([PMBoK 2004, S.7]) 6 Diplomarbeit Robert Kalweit

23 2.1 Projektmanagement Abbildung 2.1: Magisches Dreieck des Projektmanagements Plan geprüft (Check). Gegebenenfalls werden Maßnahmen ergriffen, um die Projektziele 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ässt sich 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-Zyklus mit 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 die weitere Planung und Ausführung des Projekts. Initiierung- und Abschlussprozesse werden ebenfalls überwacht und gesteuert. Dies ist in Abbildung 2.2 nicht dargestellt, um die Ähnlichkeit zum PDCA-Zyklus hervorzuheben. Eine klare Trennung zwischen Prozessgruppen ist aufgrund ihrer Wechselwirkungen nicht Diplomarbeit Robert Kalweit 7

24 2 Projektmanagement Grundlagen möglich. Ihre Überschneidungen im zeitlichen Ablauf eines Projekts schließen eine Einteilung in gleichnamige Phasen aus. (Vgl. [PMBoK 2004, S.8, S.39ff.]) Neben der Zuordnung zu Prozessgruppen erfolgt eine Einteilung sämtlicher Prozesse in neun Wissensgebiete: Integrationsmanagement beinhaltet die Koordinierung aller Prozesse. Auftragsentwicklung, Änderungssteuerung und Abschluss des Projekts fallen in diesen Bereich. Das Inhalts- und Umfangsmanagement umfasst Definition, Planung, Steuerung des Inhalts und Umfangs eines Projekts, sowie die Abnahme fertig gestellter Teile eines Projekts. Prozesse, die die zeitliche Abfolge von Vorgängen beeinflussen, Terminplanung und Schätzungen der Dauer von Vorgängen werden unter dem Begriff des Terminmanagements zusammengefasst. Prozesse des Kostenmanagements dienen dem budgetgerechten Abschluss des Projekts. Qualitätsmanagement beinhaltet Vorgänge, die der Prozessverbesserung und der Sicherung von Qualitätsstandards in Bezug auf Projektanforderungen dienen. Personalmanagement umfasst die Teamplanung und -leitung sowie die Verteilung der Rollen und Verantwortlichkeiten. Das Risikomanagement identifiziert, überwacht und analysiert Ereignisse, deren Eintreten positive oder negative Auswirkungen auf die Projektziele oder ihre Erreichung haben. Die Reaktionen auf Risiken und ihre Bewältigung gehören ebenfalls zum Risikomanagement. Prozesse in deren Rahmen Produkte oder Leistungen von außerhalb des Teams erworben oder in Anspruch genommen werden, gehören zum Beschaffungsmanagement. Das Management von Verträgen und bezüglich Lieferanten zählt ebenso dazu. Aufgabe des Kommunikationsmanagements ist die Sicherstellung der Verfügbarkeit von Informationen innerhalb des Projekts, das Fortschrittsberichtswesen und das Stakeholdermanagement. Als Stakeholder (engl. für Teilhaber, Interessenvertreter) werden Personen und Organisationen bezeichnet, die am Projekt teilhaben und die Durchführung beeinflussen können. Stakeholdermanagement versucht, durch Kommunikation mit den Stakeholdern deren Projektanforderungen zu erfüllen sowie Probleme zu lösen. (Vgl. [PMBoK 2004, S.337ff.]) 8 Diplomarbeit Robert Kalweit

25 2.2 Agiles Projektmanagement 2.2 Agiles Projektmanagement Zu Beginn der Entwicklung agilen Projektmanagements stand die Einbeziehung des Kunden in die Softwareentwicklung. Einer der Risikofaktoren für das Scheitern von Projekten wird dadurch gemildert. Agilität bedeutet Beweglichkeit und siehe 1 Flexibilität. Agile Vorgehensweisen ermöglichen schnelle Reaktionen auf sich ändernde Projektanforderungen und schwächen so einen weiteren Risikofaktor ab. Zumeist Ende der 1990er-Jahre entwickelt, wurden diese flexiblen Vorgehensweisen erst 2001, nach der Formulierung des Agilen Manifests, unter dem Begriff der Agilitä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 inkrementelle Entwicklung in kurzen Iterationszyklen, was zeitnahe Reaktionen auf Änderungen ermöglicht. Ein Inkrement ist dabei der Teil des Projektziels, der in einer Iteration fertig gestellt wurde. Inkremente werden in verschiedenen agilen Methoden auch als Features oder Funktionalitäten bezeichnet. Iterationen sind zumeist gleich lange Zeitabschnitte innerhalb der Entwicklungsdauer eines Projekts. In den Iterationen, je nach agiler Methode auch Timeboxes oder Sprints genannt, werden die gleichen elementaren Aktivitäten zur Entwicklung von Inkrementen angewandt. Um iterativ, inkrementelle Entwicklung agil nennen zu können, bedarf es einer weiteren Bedingung: Jedes Inkrement muss erfolgreich getestet sein und den Stakeholdern demonstriert werden können. Darüber hinaus verhindern agile Prozesse Verschwendung, wie z. B. teilweise fertig gestellte Arbeitsergebnisse, das Verrichten unnötiger Arbeit oder Erstellung von Dokumenten, die lediglich dazu dient, den Prozess einzuhalten. Dies ist die direkte Umsetzung des zweiten Prinzips des Agilen Manifests. Agile Teams managen sich selbst. Daher bedingt agiles Projektmanagement eher eine Bottom-up- statt eine Top-Down-Planung. Bei ersterer werden Planwerte in den unteren Elementen Diplomarbeit Robert Kalweit 9

26 2 Projektmanagement Grundlagen der Projektplanung erfasst und zu einem Gesamtbudget summiert. Top-Down- Planung gibt hingegen erst das Gesamtbudget vor und verteilt dies anschließend von oben nach unten auf Unterprojekte, Aufgaben, oder andere Strukturelemente. (Vgl. [Oestereich und Weiss 2008], [Schwaber 2007b]) siehe 1 Der zuvor beschriebene Trend zur Agilität hat dazu geführt, dass weitere Bereiche klassischen Projektmanagements in agile Vorgehensweisen integriert wurden. Zusätzlich haben klassische Vorgehensmodelle ebenfalls agile Ansätze einbezogen. Das erschwert zunehmend die Abgrenzung zwischen traditionellem und agilem Projektmanagement. (Vgl. [Angermeier 2005, S.33]) 2.3 Projektmanagementsysteme Eine Möglichkeit, der Komplexität der Softwareentwicklung zu begegnen sind Vorgehensmodelle. 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.3 geboten. Dient ein solches Vorgehensmodell der erfolgreichen Umsetzung von Projekten, ist es ebenfalls ein Projektmanagementsystem (PMS). Das Deutsche Institut für Normung definiert ein PMS als Organisatorisch abgegrenztes Ganzes, das durch das Zusammenwirken seiner Elemente in der Lage ist, Projekte vorzubereiten und abzuwickeln ([DIN 1987], zit. n. [Angermeier 2005, S.339]). Dies gilt für sämtliche der in Abbildung 2.3 dargestellten Vorgehensmodelle. Ein PMS ist jedoch nicht das in einer Organisation verordnete theoretische Vorgehen, sondern das tatsächlich gelebte Handlungsmodell. Ein Unternehmen kann zwar formal ein agiles PMS verwenden, wenn jedoch Führungskräfte die agilen Prinzipien des jeweiligen Prozesses untergraben, indem sie bspw. das Selbstmanagement des Teams behindern, ist das gelebte Vorgehen nicht mehr agil. Der Umkehrschluss gilt ebenfalls. Inwiefern jedoch die agile Auslegung eines formal nicht agilen PMS zu dessen Standard konform ist, zeigt sich erst im Einzelfall. (Vgl. [Angermeier 2005, S.339]) 10 Diplomarbeit Robert Kalweit

27 2.3 Projektmanagementsysteme Abbildung 2.3: Geschichte von Vorgehensmodellen, nach [Oestereich und Weiss 2008], [Pichler 2007] Nicht agile Projektmanagementsysteme definieren umfangreiche Prozesse: Das PMI erläutert mit dem PMBoK Guide 2 auf nahezu 400 Seiten ein PMS. Die Dokumentationen der Projektmanagementsysteme V-Modell XT und PRINCE2 sind jeweils noch umfangreicher. Da Agilität jedoch Beweglichkeit und Flexibilität bedeutet, beschreiben agile Vorgehensweisen einen meist kleinen methodischen Kern und liefern anhand bewährter Praktiken (best practices) Vorschläge, die den erfolgreichen Einsatz der jeweiligen Vorgehensweise unterstützen. (Vgl. [Oestereich und Weiss 2008, S.v], [Pichler 2007, Kap.1], [Angermeier 2005, S.296]) Agile Vorgehensweisen sind vielfach miteinander kombinierbar. Hauptvorgehensweise ist jedoch in nahezu 60% aller Unternehmen Scrum (vgl. Abbildung 2.4). 2 Die geläufige Abkürzung für A Guide to the Project Management Body of Knowledge. Diplomarbeit Robert Kalweit 11

28 2 Projektmanagement Grundlagen Abbildung 2.4: Anwendung agiler Vorgehensweisen, Quelle: [Behrens 2006] Als zentraler Aspekt der vorliegenden Arbeit wird Scrum daher im folgenden Kapitel eingehend erläutert. 12 Diplomarbeit Robert Kalweit

29 3 Scrum Liberty means responsibility. That is why most men dread it. (George Bernard Shaw) Dieses Kapitel wird Scrum, eine agile Projektmanagementmethodik, und seine klar definierten Regeln unterteilt nach Rollen, Artefakten und Prozess beschreiben und Empfehlungen bewährter Praktiken darlegen. Der Begriff Scrum bedeutet Gedränge und entstammt dem Rugby. Ein Gedränge beschreibt dort einen komplizierten Spielzug, bei dem sich die Spieler beider Mannschaften eng umschlungen gegenüber stehen und versuchen, den Ball zu erobern, in dem sie ihn mit den Füßen nach hinten schieben. Sowohl der Begriff Gedrä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 Rollen und Artefakte 3. Als Artefakte werden in der Softwareentwicklung Zwischenoder Endprodukte des Entwicklungsprozesses bezeichnet. Der Scrum Prozess sieht weiterhin vier Meetings vor. Das verdeutlicht bereits, wie stark Scrum das Agile Manifest widerspiegelt. Drei Rollen und vier Meetings (Individuen und Interak- siehe 2.2 tionen) stehen lediglich drei Artefakten (Prozesse und Werkzeuge) gegenüber. ([Pichler 2007, S.9]) 3 Das V-Modell XT beispielsweise definiert 31 Rollen und weit mehr Produkte. ([VMXT 2007, S.233ff., S.500ff.]) Diplomarbeit Robert Kalweit 13

30 3 Scrum 3.1 Rollen ScrumMaster siehe 2.1 Traditionelles Projektmanagement steht zwischen Auftraggeber und Projektteam, um die aus den Anforderungen resultierende Arbeit zu planen. Um Assoziationen zur direkten Autorität eines klassischen Projektmanagers zu vermeiden, verwendet Schwaber einen neuen Titel: den ScrumMaster. Aufgabe des ScrumMasters ist es, für die Einhaltung und den möglichst reibungslosen Ablauf des Scrum Prozesses zu sorgen. Er steht daher neben dem Product Owner und dem Team und unterstützt sie bei der Erfüllung Ihrer Verantwortlichkeiten, hilft ihnen also sich selbst zu managen. Diese Hilfe ist notwendig, da der ScrumMaster Verantwortung für den Scrum Prozess trägt, ohne formelle Macht zu haben. Dieser Verantwortung wird der ScrumMaster durch die Moderation der vier im Prozess vorgesehenen Meetings gerecht. (Vgl. [Pichler 2007, S.20ff.], [Schwaber 2004, S.25]) Empfehlungen Neben der Bereitschaft Verantwortung zu übernehmen, muss ein guter ScrumMaster über die Tugenden der Hingabe und Bescheidenheit verfügen, aber auch über das politische Gespür, seinen Einfluss im Team und in der Organisation geltend zu machen. ([Cohn 2007]) In jeder Organisation, unwichtig ob es sich um Linien- oder projektbasierte Organisationen (vgl. [PMBoK 2004, S.28ff.]) handelt, existieren Hierarchien. Im Rahmen dieser Hierarchien haben Menschen ein natürliches Bedürfnis zu gefallen, auch aus Angst vor Sanktionen bei Nichtgefallen. Aus diesem Grunde tendieren sie dazu, erreichte Ergebnisse oder zu planende Aufwände zu beschönigen. Dies hat weitreichende Auswirkungen auf das Projekt. Der ScrumMaster steht zumindest 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 gegenüber weisungsbefugt ist, kommt ihm im Projekt eine gewisse Führungsrolle zuteil. 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 14 Diplomarbeit Robert Kalweit

31 3.1 Rollen ehesten jemanden als Anführer akzeptieren würde, wenn dieser der Gruppe bereits ausgesprochen gut gedient und ihr Vertrauen erworben hat. Der ScrumMaster dient dem Team, indem er jederzeit im Rahmen des Scrum Prozesses Hindernisse beseitigt, zur Konfliktbewältigung beiträgt und eine gemeinschaftliche Entscheidungsfindung fördert. So gewinnt er an Einfluss. Mit Scrum halten so Greenleafs mittlerweile fast 40 Jahre alten Ideen Einzug ins Software-Projektmanagement. (Vgl. [Greenleaf 2002]) Product Owner Der Product Owner vertritt die Endkunden und Interessenvertreter im Projekt und verantwortet ihnen gegenüber den Projekterfolg. Meist gibt es in Projekten mehrere Interessenvertreter (Stakeholder) deren vielfältige Anforderungen sich im siehe 2.1 Endprodukt wiederfinden sollen. Schwaber behauptet, 35 Prozent der Anforderungen würden sich ändern und 65 Prozent seien von so geringem Wert, dass ihre Lieferung fraglich sei ([Schwaber 2007a]). In Scrum kommt daher der Anforderungserhebung kein hoher Stellenwert zu. Sie erfolgt vielmehr evolutionär. Der Product Owner steuert diese Evolution der Anforderungen mit dem einzigen Artefakt, das im Scrum Prozess in seine Verantwortung fällt: dem Product Backlog. Hier werden Anforderungen ergänzt oder entfernt, verfeinert und priorisiert. Um dabei stets im Interesse der Auftraggeberseite zu handeln, ist intensive regelmäßige Abstimmung notwendig. ([Pichler 2007, S.10]) Da der Product Owner das Releasemanagement nicht an Projektmanager oder Teamleiter delegiert, obliegt ihm selbst die Verantwortung über die termingerechte Auslieferung, Umfang und Kosten des Produkts. Um dieser Verantwortung gerecht werden zu können, muss dem Product Owner diesbezüglich Entscheidungsgewalt gegeben sein. Empfehlungen Durch regelmäßige direkte Zusammenarbeit mit dem Team, idealerweise direkt nach dem Daily Scrum, können aufkommende Fragen sofort geklärt werden. Je öfter der Product Owner mit dem Team arbeitet, desto unwahrscheinlicher kommt Diplomarbeit Robert Kalweit 15

32 3 Scrum es zu Verzögerungen durch offene Fragen. Seine Verfügbarkeit ist also Erfolgsfaktor für die Ausübung seiner Rolle und damit für das Projekt. Die enge Zusammenarbeit mit dem Team überbrückt die über Jahrzehnte entstandene Kluft zwischen 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 mindestens eine Anforderung. Wie viele Anforderungen während der nächsten Iteration umgesetzt werden, entscheidet das Team im Sprint Planning Meeting selbst. Es ist ermächtigt (empowered). Die Einführung von Scrum in einer Organisation erfordert und fördert den Übergang von einem Team, das gemanagt wird, zu einem Team, das sich selbst managt. Diese Freiheit setzt Kreativität frei, führt aber auch zu Verantwortung. Jeder im Team geht sich selbst und dem ganzen Team gegenüber eine Verpflichtung ein, das gesetzte Ziel zu erreichen. Dies steigert erst langsam, dann in zunehmendem Maße die Produktivität. ([Schwaber 2004, S.42, S.116]) Scrum Teams sind echte Teams. Im Gegensatz zu Teams, die nur in der Projektplanung existieren und in der Realität nur eine lose Ansammlung von Individuen sind, unterstützen sich Mitglieder echter Teams gegenseitig, was häufig zu Synergieeffekten führt. Diese treten jedoch nur bei einer Teamgröße von ungefähr fünf bis neun Personen auf. In größeren Teams wird es schwerer, gemeinsame Normen zu finden. Die Kommunikation wird zunehmend aufwendiger. Die Zusammenarbeit 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 Mitgliedern des Teams erfüllt werden können. Natürlich ist es erlaubt, von außerhalb des Teams Informationen und Ratschläge einzuholen. Abhängigkeiten dürfen daraus jedoch nicht erwachsen. Ein Scrum Team ist interdisziplinär besetzt. Obwohl etliche Rollen, wie z. B. Architekten und Entwickler, im Team vertreten sind, fordert Scrum, sich über ein kompromissloses Verständnis dieser Rollen hinwegzuset- 16 Diplomarbeit Robert Kalweit

33 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 be a tester to test, or a designer to design. ([Schwaber 2004, S.104], vgl. [Pichler 2007, S.14f.]) Anmerkungen Die zu Beginn des Kapitels gelobte Spezifikation lediglich dreier Rollen in Scrum scheint widersprüchlich zur Erläuterung des Teams. Scrum kann eine gewisse Scheinheiligkeit vorgeworfen werden, da in einem interdisziplinär besetzten Team weitere Rollen enthalten sind. Das V-Modell XT fordert schließlich ebenfalls, ein Projektteam zusammenzustellen. Es fordert jedoch darüber hinaus, die Rollen der Mitarbeiter festzulegen ([VMXT 2007, S.236]). Letzteres ist, auf das Team bezogen, der grundlegende Unterschied zu Scrum: Eine Festlegung erfolgt bei Scrum nicht. Dem Team ist sowohl die Arbeitsorganisation als auch die Rollenzuweisung selbst ü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 Projektmanagers fast sämtliche Aufgaben traditionellen Projektmanagements erfüllt. siehe 2.1 Für Inhalts-, Zeit- und Kommunikationsmanagement ist das Team auf Sprintebene, der Product Owner auf Releaseebene zuständig. Dem Product Owner obliegt das Kostenmanagement, sowie dank Input vom Team das Risikomanagement. Alle drei Rollen beteiligen sich am Qualitätsmanagement: Der Product Owner bezogen auf die Leistungsmerkmale des Produkts, das Team bezüglich der qualitativ hochwertigen Umsetzung und schließlich der ScrumMaster bezogen auf die Prozessqualität. Lieferantenmanagement ist gemeinsame Aufgabe von Team und Product Owner. Das Team selbst übernimmt das Personalmanagement, indem es für die Steigerung der eigenen Produktivität sorgt. Auch die Daueraufgabe, Kompetenz und Professionalität zu verbessern obliegt dem Team. Lediglich für die Bereitstellung der Mitarbeiter selbst ist ein übergeordnetes Management zuständig. ([Pichler 2007, S.24], vgl. [Schwaber 2004, S.101, S.107]) Diplomarbeit Robert Kalweit 17

34 3 Scrum 3.2 Artefakte Zwei der drei Artefakte im Scrum Prozess enthalten den Begriff backlog. Dabei handelt es sich um eine Liste von Dingen, die getan werden müssen, eine Zuerledigen-Liste. Das erste dieser Artefakte, das Product Backlog bezieht sich auf das komplette Projekt. Die zweite Listenart, das Sprint Backlog, gilt für je einen Sprint. Product Backlog Anforderungserhebung und -management werden in Scrum mit dem Product Backlog realisiert. Alle bekannten funktionalen und nicht funktionalen Anforderungen sind hier aufgelistet. Es enthält das Was, nicht das Wie: Arbeitsergebnisse können Teil des Product Backlogs sein, Aktivitäten, die zu deren Erreichen nötig sind jedoch nicht. ([Pichler 2007, S.27f.]) Zum Zeitpunkt des Projektstarts beinhaltet das Product Backlog zumindest wesentliche Anforderungen (Erfolgsfaktoren für Vertrieb und Einsatz des Produkts). Um dem Team Selbstmanagement durch Auswahl der Anforderungen zu ermöglichen, muss deren Anzahl für wenigstens zwei bis drei Sprints ausreichend sein. Der Product Owner priorisiert sämtliche Anforderungen und steuert so die Reihenfolge der Umsetzung. Die wichtigsten Anforderungen werden als Erstes umgesetzt und sind daher am detailliertesten. Analyse und Verfeinerung der niedriger priorisierten Anforderungen erfolgen iterativ. (Vgl. [Pichler 2007, Kap.4.2]) Ein Beispiel für ein Product Backlog der vorliegenden Arbeit mit ersten, grob formulierten Anforderungen, Priorität, thematischer Einordnung und Aufwandsschätzung zeigt Tabelle 3.1. Der Product Owner kann jederzeit Anforderungen aus dem Product Backlog strei- chen. Wurden diese unnötigerweise bereits detailliert beschrieben, resultiert das in Verschwendung. Diese wird durch die iterative Verfeinerung verringert. Im Projektverlauf wird das Product Backlog ständig detaillierter, bis zum Ende des Projekts alle entwickelten Anforderungen in hohem Detailgrad festgehalten sind. (Vgl. [Pichler 2007, Kap.5.7.3]) siehe Diplomarbeit Robert Kalweit

35 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 wird und wie die Umsetzung in Projektron BCS integriert wird. 2 Theorie Die Schilderung des Scrum Prozesses muss die Grundlage für weitere Betrachtungen bilden und sämtliche relevanten Begriffe erläutern. 2 Theorie Die Einleitung muss Motivation, Ziel und Aufbau der Arbeit darlegen Tabelle 3.1: Tabellarisches Product Backlog Empfehlungen Gute Anforderungen sind nach [Wake 2003] durch INVEST-Merkmale gekennzeichnet. Das Akronym INVEST steht dabei für independent, negotiable, valuable, estimable, small, testable. Die Einträge mit der höchsten Priorität sollten diesen Merkmalen entsprechend unabhängig, verhandelbar, nützlich, schätzbar, klein und testbar sein. Pichler empfiehlt die Verwendung von user stories nach [Cohn 2004]: User stories oder Benutzergeschichten sind in allgemeiner Sprache verfasste Beschreibungen von Funktionalitäten. Die Formulierung von Akzeptanzkriterien stellt sicher, dass die erfolgreiche Umsetzung einer user story bewertet werden kann. Um in Besprechungen nicht nur mit virtuellen Artefakten zu arbeiten, werden user stories traditionell auf Karteikarten geschrieben. Diese Vorgehensweise erfüllt die 3C-Kriterien card, conversation, confirmation (vgl. [Cohn 2004]) und impliziert gleichzeitig bereits die Erfüllung von drei der sechs INVEST-Merkmale: Klein, verhandelbar, testbar. Da der Platz auf Karteikarten begrenzt ist, müssen user stories kurz sein (card und klein). Details werden im Gespräch zwischen Kunde und Entwicklern, in Scrum zwischen Product Owner und Team, erarbeitet (conversation und verhandelbar). Die Einigung auf Akzeptanzkriterien bestätigt das gemeinsame Verständnis einer user story (confirmation und testbar). Das Merkmal nützlich bezieht sich auf den Endverbraucher. Ein schlechtes Beispiel hierfür ist: Der Streamingserver muss eine Bandbreite von 5 Mbit/s liefern. Diplomarbeit Robert Kalweit 19

36 3 Scrum Da diese story in technischer Sprache verfasst ist, hat sie für den Endverbraucher keinen Nutzen. Dieser wird erst ersichtlich, wenn die user story aus Anwendersicht formuliert wird: Zehn Benutzer sollen die Videos gleichzeitig in guter Qualität und ohne Wartezeit empfangen können. Wenngleich noch ein gemeinsames Verständnis von guter Qualität geschaffen werden muss, ist der Nutzen für den Kunden bei dieser user story bereits offensichtlich. Um Abhängigkeiten zwischen user stories aufzulösen, können entweder abhängige stories zu einer größeren, aber unabhängigen story zusammengefasst oder eine andere Unterteilung gewählt werden. User stories sind nicht oder nur schlecht schätzbar, wenn sie zu groß sind oder dem Team zur Umsetzung notwendiges Wissen fehlt. Auch hier kann Unterteilung Schätzbarkeit (das letzte verbliebene INVEST-Merkmal) gewährleisten. Eine zu große user story, ein epic, setzt sich aus mehreren kleineren stories zusammen. Vor ihrer Schätzung und Umsetzung muss diese Unterteilung gefunden und vorgenommen werden. Eine komplexe Benutzergeschichte kann in eine Erkundungs- oder Recherchegeschichte 4 und eine Umsetzungsgeschichte geteilt werden. Sprint Backlog Das Team wählt selbstständig diejenigen Anforderungen aus dem Product Backlog, die es innerhalb des nächsten Sprints umsetzen wird. Grundlage dieser Auswahl ist die Menge der Anforderungen, die der Product Owner am höchsten priorisiert hat. Das auf diese Weise definierte Sprint-Ziel darf während des Sprints nicht geändert werden. Das schafft Sicherheit für das Team. Aktivitäten, die zum Erreichen der Zielsetzung notwendig sind, werden im Sprint Backlog festgehalten. Es enthält Aufgaben, die detaillierter sind als deren Ziele im Product Backlog und unterliegt der alleinigen Verantwortung des Teams. Daher verändert es sich täglich: Beginnt ein Teammitglied eine Aufgabe, wird dies an der Aufgabe vermerkt. Ist die Aufgabe abgeschlossen, wird sie als erledigt markiert. Endet ein Arbeitstag, werden spätestens dann die Restaufwände der Aufgaben, die noch in 4 Nach Cohn ein spike, für den begrenzte Zeit zur Verfügung steht. 20 Diplomarbeit Robert Kalweit

37 3.2 Artefakte Arbeit sind, aktualisiert. Wie umfangreich die Aufgaben tatsächlich sind, obliegt ebenfalls dem Team. Es bestimmt den Detailgrad der Aufgaben und damit ihre Dauer. Empfehlungen Als maximale Dauer einer Aufgabe empfiehlt Pichler einen Nettoarbeitstag, um täglich den Projektfortschritt zu verfolgen. Das deckt sich nur bedingt mit Schwaber, der vier bis sechzehn Stunden pro Aktivität vorsieht. Die Beschränkung auf einen Nettoarbeitstag ist mit dem Ziel, den Fortschritt täglich zu beobachten, nicht zu begründen. Schließlich werden bei Aktivitäten, die über den Arbeitstag hinausgehen, Restaufwände täglich erfasst, was die geforderte Beobachtung gewährleistet. Für einzelne Teammitglieder mag die Erfüllung einer Aufgabe am Ende des Arbeitstages eine zusätzliche Motivation darstellen. Da in der Literatur auf diesen Aspekt jedoch nicht eingegangen wird, bleibt dies Spekulation. (Vgl. [Pichler 2007, S.102f.], [Schwaber 2004, S.12]) Statt nur ein virtuelles Sprint Backlog in einer Software zu verwalten, empfiehlt sich die Visualisierung mit Karteikarten an einer Stellwand. Diese in der Nähe des Teams aufgehängte Planungswand bietet jederzeit einen Überblick über den Status des Sprints. ([Oestereich und Weiss 2008, S.272], [Pichler 2007]) Potenziell lieferbares Produktinkrement Das potenziell lieferbare Produktinkrement 5 ist das Produkt eines jeden Sprints. Dieses Artefakt ohne Anmerkung mit Produktinkrement abzukürzen, verstößt gegen seine Definition im Sinne von Scrum. Jede umgesetzte Anforderung aus dem Product Backlog ist ein Produktinkrement. Ist im Folgenden die Rede von einem Produktinkrement, so ist stets ein potenziell lieferbares gemeint ([Schwaber 2004, S.12]). Erst dieses Attribut verdeutlicht, wie flexibel der Product Owner in Scrum auf Veränderungen reagieren kann: Kündigt beispielsweise ein Wettbewerber ein ähnliches Produkt an, oder wird das Release eines direkten Konkurrenzprodukts vorgezogen, kann der Product Owner 5 Schwaber verwendet potentially shippable product increment oder increment of potentially shippable product functionality synonym. Diplomarbeit Robert Kalweit 21

38 3 Scrum darauf angemessen reagieren: Da jederzeit potenziell lieferbare Software das kumulierte Ergebnis aller vergangenen Sprints vorliegt, kann eine erste Version des Produkts jederzeit veröffentlicht werden. Sind dafür noch Deploymenttätigkeiten notwendig, können Wettbewerbsnachteile gemildert oder -vorteile geschaffen werden, indem ein Release-Sprint verwendet wird. (Vgl. [Pichler 2007, Kap.5.4]) Die Entwicklung eines Produktinkrements erfordert eine gemeinsame Definition der Worte potenziell lieferbar oder fertig, eine sog. Definition of Done, kurz DoD. In Bezug auf ein Produktinkrement, also zusätzliche Funktionalität, bedeutet fertig, dass dieses lauffähig, getestet und dokumentiert sein muss ([Pichler 2007, S.83]). Bezogen auf Programmcode bedeutet es allerdings nicht nur, dass er frei von Bugs ist, wie ein Entwickler es verstehen könnte, sondern auch gut strukturiert und lesbar ist, sich an Programmierstandards hält und keine doppelten Passagen enthält. Erst eine gemeinsame DoD zwischen Product Owner und Entwicklungsteam erzeugt die für Scrum notwendige Transparenz der Ergebnisse. Existiert diese Übereinkunft nicht, geht der Überblick über den Projektfortschritt verloren. Damit verschlechtern sich die Chancen aller Beteiligten, angemessen auf Veränderungen zu reagieren. (Vgl. [Kniberg 2006, S.32], [Schwaber 2004, S.71f.]) Anmerkung Auf den ersten Blick scheint das Attribut potenziell lieferbar eine Dopplung zu sein. Etwas, das lieferbar ist, wird noch nicht geliefert, kann aber jederzeit geliefert werden. Das potenziell bezieht sich auf den Mehrwert, den eine Anforderung für den Endanwender hat. Ein lieferbares Produktinkrement hat einen solchen. Ein potenziell lieferbares Produktinkrement kann jedoch auch Funktionalität enthalten, die zwar vollständig umgesetzt ist, aber alleine stehend (standalone) keinen Mehrwert hat. (Vgl. [Pichler 2007, S.84f.]) 3.3 Prozess Ein definierter Prozess liefert aus festgelegten Eingängen (input) durch die gleichen Leistungen stets die gleichen Ergebnisse (output). Wenn die Komplexität der Aktivitäten in einem Prozess zu groß wird, stößt defined process control an 22 Diplomarbeit Robert Kalweit

39 3.3 Prozess ihre Grenzen. Um diese Komplexität zu handhaben, muss der Prozess schrittweise, also iterativ, verbessert werden. Diese auf gezielten Beobachtungen basierende Prozessverbesserung nennt sich empirical process control. Scrum ist ein empirischer Prozess und erfordert daher empirische Prozesskontrolle. Erst die Transparenz (visibility) aller Vorgänge im Projekt ermöglicht gezielte Beobachtungen (inspection). Aus diesen Untersuchungen die richtigen Schlüsse zu ziehen und entsprechende Anpassungen (adaptation) vorzunehmen führt zu Prozessverbesserung. (Vgl. [Schwaber 2004, S.2ff.]) Abbildung 3.1: Scrum, Quelle: [MGS 2005] Einige Beispiele von visibility, inspection und adaptation wurden in den Erläuterungen der Rollen und Artefakte bereits sichtbar. Abbildung 3.1 zeigt nun den iterativen, inkrementellen Ablauf des Scrum Prozesses. Nach jeder Iteration, jedem Sprint, sowie täglich während des Sprints sind Beobachtungen und Anpassungen vorgesehen. Abbildung 3.2 zeigt den Scrum Prozess in Form eines Aktivitätsdiagramms. Detailliert dargestellt sind die Vorbereitung eines Scrum Projekts und relevante Entscheidungen nach Abschluss eines Sprints. Die innerhalb der Meetings des Scrum Prozesses auszuführenden Aktivitäten werden separat abgebildet. Die Zusammenführung des Aktivitätsdiagramms in Abbildung 3.2 mit den folgenden Diagrammen befindet sich in Anhang C. Dass Scrum die Aspekte empirischer Prozesskontrolle auf jede Aktivität innerhalb des Prozesses überträgt, wird bei der Betrachtung der Meetings innerhalb des Diplomarbeit Robert Kalweit 23

40 3 Scrum Abbildung 3.2: Aktivitätsdiagramm des Scrum Prozesses Scrum Prozesses deutlich. Die Scrum-Definition des EPF Composer 6 bezeichnet diese Meetings als collaboration points, also sinngemäß Punkte der Zusammenarbeit. Diese Bezeichnung ist äußerst treffend. Die Meetings im Scrum Prozess unterscheiden sich von herkömmlichen Besprechungen. DeMarco schildert ein Negativerlebnis: Eine Besprechung ohne feste Tagesordnung, mit zu vielen Anwesenden. Beide Tatsachen führen zu Frustration und Desinteresse ([DeMarco 1998, S.228f]). Im Gegensatz dazu sind die im Scrum Prozess vorgesehenen collaboration points zeitlich begrenzte Besprechungen mit festgelegten Inhalten und Teilnehmern. 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 Regeln betrifft die Kommunikation: Sie muss offen und ehrlich sein. Dabei muss stets zwischen der Sache und der Person getrennt werden. Alles andere ist kon- 6 Der EPF Composer ist ein Tool zur Prozessdefinition. Eine mit diesem freien Werkzeug erstellte Definition des Scrum Prozesses ist ([Eclipse]). 24 Diplomarbeit Robert Kalweit

41 3.3 Prozess traproduktiv. Gegenseitiger Respekt ist Voraussetzung für eine erfolgreiche Zusammenarbeit. (Vgl. [Pichler 2007, S.113ff.]) Sprint Planning Meeting Das Sprint Planning Meeting bzw. die Sprint-Planungssitzung dient der Vorbereitung des kommenden Sprints und ist der größte collaboration point. Schwaber begrenzt die Dauer des Sprint Planning Meetings auf acht Stunden. Er geht dabei stets von einer Sprintdauer von 30 Tagen, also ungefähr 20 Arbeitstagen aus. Pichler selbst arbeitet mit kürzeren, meist zweiwöchigen Sprints und plant für die Sprint-Planungssitzung fünf Prozent der Bruttoarbeitszeit ein, bei zehn Arbeitstagen also ungefähr vier Stunden. Am Sprint Planning Meeting nehmen ausschließlich der Product Owner, der ScrumMaster und das Team teil. Werden Informationen oder Ratschläge von Personen außerhalb des Projekts benötigt, ist deren Anwesenheit gestattet. Sie müssen die Sitzung jedoch verlassen, sobald sie diese Aufgabe erfüllt haben. Um die Menge der Anforderungen zu bestimmen, die zeitlich umgesetzt werden kann, muss zu Beginn der Besprechung bereits bekannt 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 Gesamtkapazität. (Vgl. [Schwaber 2004, S.133f.], [Pichler 2007, Kap.6.4]) Zu Beginn des Meetings muss das priorisierte Product Backlog vorliegen. Die hoch priorisierten Anforderungen sind eine Vorauswahl dessen, was im zu planenden Sprint entwickelt wird. Das Team beginnt mit der Analyse der Anforderungen und bestimmt die Aktivitäten, die zu deren Erfüllung ausgeführt werden müssen. Dabei werden sämtliche Aufwände geschätzt. Anschließend wählt das Team Elemente aus, die es glaubt, in seiner verfügbaren Nettoarbeitszeit umsetzen zu können. Dabei erfolgt keine Pufferung. Ergebnis der Sitzung ist das Sprint Backlog. Der ScrumMaster moderiert das Sprint Planning Meeting. Weder er noch der Product Owner planen selbst. Sie unterstützen das Team bei der Planung. Das Augenmerk des ScrumMasters muss darauf liegen, stillere Teammitglieder einzubeziehen und Dominanz vorzubeugen. Da das Team als Ganzes für das Sprint Diplomarbeit Robert Kalweit 25

42 3 Scrum Abbildung 3.3: Aktivitätsdiagramm des Sprint Planning Meetings Backlog verantwortlich ist, muss vermieden werden, dass Teammitglieder Aktivitäten sofort auswählen, was Zusammenarbeit und Wissensverteilung verhindern würde. Für den Product Owner wird die Aufwandsschätzung sichtbar. Können Aufwände nicht geschätzt werden, ist eine Überarbeitung (adaptation) der Anforderungen notwendig. (Vgl. [Pichler 2007, S.93, S.99ff.]) Empfehlungen Schwaber beschreibt eine Halbierung der Sprint-Planungssitzung: In der ersten Hä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 Bestimmung der Aktivitäten und der Aufwandsschätzung. Diese strikte Teilung ist nicht optimal, da besagte Schätzung die Grundlage für die Auswahl der Anforderungen darstellt. Einen effektiveren, iterativen Ansatz beschreibt Pichler: Dabei iteriert das Team, bei der wichtigsten Anforderung beginnend, durch das Product Backlog und bewertet das Element. Dieses wird, solange Kapazität verfügbar ist, in das Sprint Backlog aufgenommen. (Vgl. [Schwaber 2004, S.133f.], [Pichler 2007, Kap.6.4]) Der ScrumMaster unterstützt das Team bei der Anwendung kollaborativer Entscheidungsverfahren. Dabei soll jeder in dem Maße Mitspracherecht haben, wie er von den Auswirkungen der Entscheidung betroffen ist. Ein solches Verfahren zur 26 Diplomarbeit Robert Kalweit

43 3.3 Prozess realistischen Schätzung von Aufwänden ist Planning Poker. Hierbei erhält jedes Teammitglied in der Sprint-Planungssitzung einen Stapel Karten, auf denen meist die Zahlen der Fibonacci-Folge 7 dargestellt sind. Pichler empfiehlt dieses Verfahren ausdrücklich und schlägt vor, aus Karteikarten Stapel von Planning Poker Karten selbst anzufertigen. Nachdem das Team die Anforderung und die Aktivitäten analysiert hat, legt jeder eine Karte entsprechend dem von ihm veranschlagten Aufwand verdeckt auf den Tisch. Diese Karten werden gleichzeitig aufgedeckt. Dieses Verfahren hat den Vorteil, dass Abweichungen sichtbar werden. Bei einer Diskussion, in der reihum jeder einen Aufwand schätzt, werden Teammitglieder von Vorrednern in ihren Entscheidungen beeinflusst (beispielsweise vom Senior Developer, der erläutert, wie einfach eine Aufgabe sei). Planning Poker hingegen offenbart die unvoreingenommene Schätzung eines jeden. Große Abweichungen, nach oben wie nach unten, werden im Anschluss diskutiert. Der Schätzwert ist dann ein Konsens aller Teammitglieder. (Vgl. [Pichler 2007, S.58ff]) Daily Scrum Meeting Das Daily Scrum Meeting ist mit einer strikt begrenzten Dauer von fünfzehn Minuten das kürzeste Meeting im Scrum Prozess. Gleichwohl ist es in zweierlei Hinsicht das wichtigste: Es dient, wie kein zweiter der in Scrum beschriebenen collaboration points, der Sozialisation und der Synchronisation des Teams. Aufgrund der hohen Frequenz dieser Treffen lernt sich ein neu zusammengestelltes Team schneller kennen. Das Daily Scrum dient als Forum, in dem das Team Entwicklungsschritte abgleicht ([Schwaber 2004, S.26]). Die Daily-Scrum-Besprechung wird täglich zur selben Zeit und am selben Ort durchgeführt. Teilnehmer sind der ScrumMaster, wie in der Sprint-Planungssitzung als Moderator, und alle Teammitglieder. Die Anwesenheit des Product Owners ist optional, dient aber dem Product Owner selbst am meisten, da er aus erster Hand vom Status des Sprints erfährt. Die Teammitglieder sind selbst verantwortlich und berichten daher nicht dem ScrumMaster oder dem Product Owner. Jedes Teammitglied beantwortet drei Fragen: 7 Fibonacci-Folge: 0, 1, 1, 2, 3, 5, 8, Eine Zahl der Folge ist stets die Summe beider unmittelbarer Vorgänger. Diplomarbeit Robert Kalweit 27

44 3 Scrum Abbildung 3.4: Aktivitätsdiagramm des Daily Scrum Meetings und 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 Aufgaben und bestehender oder aufkommender Hindernisse. Der ScrumMaster muss jederzeit für die Beseitigung dieser Hindernisse einstehen. Das Daily Scrum erfüllt also in 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 angebrochenen Tages abzustimmen. (Vgl. [Schwaber 2004, S.135], [Pichler 2007, S.104]) Die Formulierung der Fragestellungen variiert bei Pichler. Die erste Frage bezieht sich bei ihm auf abgeschlossene Aktivitäten, resultierend aus seiner Begrenzung einer Aufgabe auf einen Nettoarbeitstag. Die dritte Frage lautet: Werde ich in irgendeiner Form an der Ausführung einer Aktivität behindert? Dies bezieht sich auf die generelle Ausführung der Aktivität. Schwaber hingegen versucht mit der Formulierung jedwede Verbesserungsmöglichkeit aufzudecken. ([Schwaber 2004, S.135], vgl. [Pichler 2007, Kap.6.6]) Ein simples Beispiel soll die Relevanz dieser Nuance aufzeigen: Ein Entwickler muss Module, die für seine Aufgabe wichtig sind, aus einem Remote Repository 28 Diplomarbeit Robert Kalweit

45 3.3 Prozess auschecken. Zeitgleich laufen an anderer Stelle Downloads, die zu Lasten der Bandbreite gehen. Der Checkout der Module funktioniert zwar und behindert den Entwickler nicht an der Ausführung seiner Aktivität. Allerdings könnte der Checkout ohne die parallelen Downloads wesentlich schneller gehen, hindert also den Entwickler daran, so effektiv wie möglich zu arbeiten. Trotz seiner Bedeutsamkeit ist das Daily Scrum Meeting eine der Schwächen des Scrum Prozesses, sobald Teammitglieder nicht Vollzeit für das Projekt arbeiten. Fehlende Synchronisation mit einem Teilzeit-Teammitglied beeinträchtigt die Transparenz des Projektfortschritts. Werden Mitarbeiter in mehreren Teams benötigt, haben sie mehrere Daily Scrum Meetings täglich, was ihre effektive Arbeitszeit je nach Anzahl der Projektbeteiligungen stark einschränkt. Um die visibility dennoch zu gewährleisten, empfiehlt es sich, Paararbeiten mit einem Vollzeit-Mitarbeiter zu organisieren. Dieser kann das Ergebnis der Paararbeit im Daily Scrum kundtun, so dass die Teilzeitkraft nicht mehr in jedem Meeting anwesend sein muss. Wo Paararbeit nicht möglich ist, werden andere Möglichkeiten der Synchronisation, wie z. B. Dokumentation benötigt, die aber in Einarbeitungsaufwänden resultieren. Der Vorteil des Scrum Prozesses, Verschwendung zu reduzieren, ist also in vollem Umfang nur bei Vollzeitarbeit der Projektbeteiligten gegeben. (vgl. [Pichler 2007, S.16f.]) Sprint Review Meeting Am Ende eines jeden Sprints findet das Sprint Review Meeting statt. Es darf nicht länger als vier Stunden dauern. Die Teilnahme des Teams, des Product Owners und des ScrumMasters ist verbindlich. Zweck des Sprint Reviews ist, dem Product Owner und eventuell anwesenden Interessenvertretern fertige, also potenziell 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. Die Elemente des Product Backlogs, zu deren Umsetzung sich das Team verpflichtet hatte, werden aufgeführt. Im Anschluss daran führt das Team die Anforderungen vor, die umgesetzt wurden. Dabei ist es Stakeholdern jederzeit gestattet, Kommentare oder Kritik bezüglich des gelieferten Produktinkrements zu äußern. Ge- Diplomarbeit Robert Kalweit 29

46 3 Scrum Abbildung 3.5: Aktivitätsdiagramm des Sprint Review Meetings meinsam mit dem Product Owner identifizieren sie Funktionalität die nicht, oder nicht wie gewünscht geliefert wurde. Für den Inhalt der Demonstration gelten zwei Regeln: Nicht funktionelle Arbeitsergebnisse dürfen nicht gezeigt werden, wenn sie nicht zum Verständnis der Funktionalität notwendig sind. Anforderungen, die nicht zu 100% fertig gestellt und frei von Bugs sind, gelten als nicht erledigt. Die Demonstration muss darüber hinaus auf einer Umgebung, die dem vorgesehenen Umfeld der Software am nächsten kommt, vorgenommen werden. Das Sprint Review Meeting macht den Fortschritt auf Projektebene sichtbar. Das vorliegende Produktinkrement wird geprüft. Neben diesem manuellen Test kann der Product Owner im Sprint Review auch die Ergebnisse automatischer Tests einsehen. Im Sprint Review erfolgt also auch Teil des Qualitätsmanagements im Scrum Prozess. Änderungswünsche von Stakeholdern oder nicht erfüllte Anforderungen resultieren in Anpassungen des kommenden Sprint-Ziels. (Vgl. [Schwaber 2004, S.137f.], [Pichler 2007, Kap.6.7]) Anmerkungen Da das Sprint Review ein collaboration point ist, gilt es darauf zu achten, dass es sich nicht zu einer Präsentation entwickelt. Alle Beteiligten sind gefordert. Wenn das Team zu Hilfsmitteln wie Powerpoint-Präsentationen greift oder Product Owner und Stakeholder einem Publikum gleich schweigend der Vorführung des 30 Diplomarbeit Robert Kalweit

47 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. Das Team arbeitet als Einheit und soll als solche angesehen werden. Einen Mitarbeiter durch Lob oder Kritik herauszustellen ist nicht zielführend. Hat das Team Anforderungen nicht erfüllt, beispielsweise aufgrund von ungenauen Schätzungen, ist dies kein Grund für Verurteilungen. Das Wort Schätzung entschuldigt das Team bereits. Eine Schätzung ist nie hundertprozentig genau. Applaus ist ebenso unangebracht wie Verurteilungen, da er in der Regel vom Team persönlich aufgenommen wird. Es wird also künftig wiederum nach Applaus streben und sein Ausbleiben als Kritik empfinden. Das menschliche Streben zu gefallen beeinflusst Schätzungen genauso wie die Angst, nicht zu gefallen. Inhaltliche Konsequenzen treten dabei angesichts persönlicher Interessen oder Ängste in den Hintergrund. Daher erreicht ein Team nach einer Verurteilung im Sprint Review im Extremfall Schätzgenauigkeit durch nachlassende Qualität. Abschließende Tests wegzulassen, spart beispielsweise die Zeit ein, die andernfalls über die geschätzte Zeit hinausgehen 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 Planning und am Sprint Review Meeting teilnehmen. So können sie die Planung eines Sprints beeinflussen und erleben die Prüfung des Produktinkrements durch den Product Owner ([Pichler 2007, S.17]). Arbeiten diese Mitarbeiter jedoch in mehreren Teams, ist dies nicht immer möglich, da sich die Meetings verschiedener Projekte überschneiden können. Darüber hinaus ist es aus Gründen der Effizienz nicht sinnvoll, die Anwesenheit eines Teilzeit-Teammitglieds in den genannten Meetings mehrerer Projekte vorauszusetzen: Im Falle zweiwöchiger Sprints dauern beide Meetings zusammen einen Arbeitstag (von maximal zehn). Die Meetings jedes weiteren Projekts reduzieren also die effektive Arbeitszeit des Mitarbeiters um je zehn Prozent. Scrum schreibt nicht explizit vor, nur Vollzeit-Mitarbeiter am Projekt arbeiten zu lassen. Die gleichzeitige Beteiligung einzelner Teammitglieder an mehreren Projekten ist jedoch nicht vorgesehen. Ob sich dies in der Praxis tatsächlich immer durchsetzen lässt, ist fraglich. Für Teilzeit-Arbeit liefert Scrum grundsätzlich keine zufriedenstellende Lösung. Diplomarbeit Robert Kalweit 31

48 3 Scrum Sprint Retrospective Meeting Dem Sprint Retrospective Meeting kommt bezogen auf den Prozess, den Arbeitsablauf, ähnliche Bedeutung zu wie dem Sprint Review für die Arbeitsergebnisse. Es findet ebenfalls am Sprint-Ende statt und dient der Untersuchung des Scrum Prozesses im vergangenen Sprint mit dem Ziel, selbigen im kommenden Sprint anzupassen und zu verbessern. Abbildung 3.6: Aktivitätsdiagramm des Sprint Retrospective Meetings An der Sprint-Retrospektive nehmen der ScrumMaster und das Team teil. Der ScrumMaster hat wie in den zuvor geschilderten collaboration points die Aufgabe eines Moderators. Er verantwortet die Effektivität der Sitzung und sorgt für die Einhaltung der Regeln des Miteinanders. Die Sprint-Retrospektive ist auf maximal 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 bekommt nun ein Gefühl davon, wie es den anderen gerade geht. Erst nach einem guten Einstieg in die Retrospektive wird begonnen, positive und negative Erlebnisse des vergangen Sprints zusammen zu tragen. Diese sollten priorisiert werden, 32 Diplomarbeit Robert Kalweit

49 3.3 Prozess da eventuell nicht alle Probleme intensiv diskutiert werden können. In diesem Fall wird nach Dringlichkeit vorgegangen.(vgl. [Pichler 2007, Kap.6.8]) Die Anwesenheit des Product Owners ist optional, aber empfehlenswert, damit er die Notwendigkeit der erarbeiteten Verbesserungsmöglichkeiten besser versteht. Um nicht in etlichen Retrospektiven lediglich Symptome eines Problems zu bekämpfen, analysiert Pichler die Ursachen mittels der Five Whys nach [Derby und Larsen 2006]. Dabei wird rekursiv nach dem Warum eines Problems gefragt, bis seine Grundursache (root cause) gefunden ist. Hier setzen dann gemeinsam erarbeitete Verbesserungsmaßnahmen an. (Vgl. [Pichler 2007, Kap.6.8], [Schwaber 2004, S.138f.]) Aufwandsschätzungen und Releaseplanung Wenngleich der Scrum Prozess weder abstrakte Aufwandsschätzungen noch eine Releaseplanung durch Ermittlung der Entwicklungsgeschwindigkeit vorschreibt, ist das Verständnis dieser Praktiken relevant für die folgenden Kapitel dieser Arbeit. 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 Beziehung zu setzen. Dafür bieten sich Zahlen der Fibonacci-Folge an. Ein Aufwand lässt sich dabei immer als die Summe der beiden nächstkleineren Aufwände darstellen. Das Team kann so zuerst einige kleine Anforderungen schätzen, um im Anschluss weitere Elemente in Relation zu diesen zu beurteilen. Im Gegensatz zu absoluten Schätzungen in Zeiteinheiten ist dieses Verfahren eine relative (oder abstrakte) Schätzung. Es toleriert Ungenauigkeiten in der Schätzung, indem es die Teammitglieder von dem Zwang befreit, sich bspw. zwischen einem Aufwand von 8 und 9 zu entscheiden. (Vgl. [Pichler 2007, S.58f.]) Ein weiterer Vorteil ist, dass die Komplexität einer Anforderung vom zeitlichen Aufwand ihrer Umsetzung entkoppelt wird. Es wird also nicht mehr die verbleibende Zeit, die sich ändern kann, sondern der konstante, verbleibende Weg geschätzt. (Vgl. [Pichler 2007, S.58], [Cohn 2004, S.87ff.]) Diplomarbeit Robert Kalweit 33

50 3 Scrum Auf der den Sprints übergeordneten Ebene, der Releaseebene, bietet Scrum Transparenz und permanenten Überblick über den Projektfortschritt. Bereits nach dem ersten Sprint basieren die Entscheidungen des Product Owners nicht mehr auf den Schätzungen des Teams sondern auf dem, was dieses tatsächlich erreicht hat ([Schwaber 2004, S.112f.]). Der Product Owner kann empirisch die Entwicklungsgeschwindigkeit (velocity), also die Anzahl an story points, die in einem Sprint umgesetzt wurden, bestimmen: velocity = story points sprints Pichler legt nahe, die Durchschnittsgeschwindigkeit der ersten zwei bis drei Sprints zu ermitteln. 8 Werden nun in Zusammenarbeit mit dem Team die Aufwände aller Einträge im Product Backlog geschätzt, kann nach derselben Formel die Zeit bis zur Fertigstellung des gesamten Product Backlogs ermittelt werden: sprints = story points velocity Den Zusammenhang zwischen offenen und fertig gestellten Anforderungen und der Entwicklungsgeschwindigkeit visualisiert ein Burndown Chart. Nach [Scr 2008] gilt dieses in Scrum als weiteres Artefakt. Es ist jedoch vielmehr eine andere Sicht auf das jeweils aktuelle Product- und Sprint Backlog und wird daher in der vorliegenden Arbeit gesondert erläutert. Schwaber nennt das Burndown Chart im Zusammenhang mit dem Product Backlog die collision of reality [...] with what is planned. Ein Burndown Chart veranschaulicht den Projektfortschritt, indem der Verlauf der Restaufwände an einer Zeitachse abgebildet wird. Dies kann entweder für ein ganzes Release geschehen wie in Abbildung 3.7 oder in Form eines Sprint Burndown Charts, das für genau einen Sprint gilt. Im ersten Fall empfiehlt sich die Einteilung der Zeitachse in Sprints. Soll nur ein Sprint betrachtet werden, 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 Projekts beträgt konstant 20 story points pro Sprint. Nach dem dritten Sprint fügt der Pro- 8 Alternativ zur empirischen Ermittlung der velocity kann sie historisch (mit Daten von abgeschlossenen Projekten desselben Teams) oder spekulativ (risikoreiche Schätzung) ermittelt werden. 34 Diplomarbeit Robert Kalweit

51 3.3 Prozess Abbildung 3.7: Release Burndown Chart nach [MGS 2008] duct Owner Anforderungen im Umfang von 30 story points hinzu. Um zwischen dem ursprünglichen Planaufwand und den Änderungen unterscheiden zu können, werden letztere unter der X-Achse dargestellt. Im vierten Sprint schafft das Team wiederum Anforderungen mit Aufwänden von 20 story points. Der Product Owner verzichtet auf Anforderungen, die auf fünf story points geschätzt wurden. So bleiben zu Beginn des fünften Sprints 40 story points aus ursprünglichen, sowie fünf aus zusätzlichen Anforderungen. (Vgl. [MGS 2008]) Hier wird ein weiterer Vorteil abstrakter Schätzungen offenbar: Die für eine Aufgabe aufgewandte Zeit sagt nichts über den Fertigstellungsgrad der Aufgabe aus, da sich die verbleibende Zeit bis zur Fertigstellung stets verändern kann. Diesem als Problem 9 bekannten Phänomen können absolute Schätzungen mit zeitlichen Puffern begegnen. Solange diese Puffer sich jedoch nicht aus den Erfahrungen der vergangenen Sprints errechnen, lässt die Planung mittels Entwicklungsgeschwindigkeit genauere Schlüsse auf den potenziellen Fertigstellungstermin zu. (Vgl. [Pichler 2007, Kap.5.5]) Eine Fortschrittslinie der ideale Burndown verdeutlicht Verzögerungen oder schnelleren Fortschritt. Dazu wird eine Linie von der Summe der Aufwände am Sprint- oder Releasebeginn bis zu deren Ende auf der X-Achse gezogen. Der Verlauf des idealen Burndowns entspricht exakt der geplanten Entwicklungsgeschwin- 9 Auch Pareto-Prinzip genannt: Demnach lösen Aufgaben mit einem Aufwand von 20% bereits 80% der Probleme, was im Umkehrschluss bedeutet, dass die restlichen 20% der Probleme 80% der Arbeit verursachen. (Vgl. [Oestereich und Weiss 2008, S.423]) Diplomarbeit Robert Kalweit 35

52 3 Scrum digkeit, also der Summe der Aufwände, die im aktuellen Sprint oder Projekt fertig gestellt werden sollen. (Vgl. [Pichler 2007, S.70f.]) Ein Sprint Burndown Bericht ist analog aufgebaut, basiert jedoch auf den Restaufwänden der Aktivitäten im Sprint Backlog. Das Sprint Burndown Chart offenbart dem Team jederzeit, ob der Sprint-Fortschritt schneller (Restaufwände unter dem idealen Burndown) oder langsamer ist, als vorgesehen. (Vgl. [Pichler 2007, S.117f.]) 36 Diplomarbeit Robert Kalweit

53 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. Dazu wird die Inventurmethode, die im Wesentlichen Dokumente analysiert, verwendet ([Krallmann u. a. 2002, S.65f.]). Die Funktionen der Software werden in Bezug auf die Wissensgebiete des Projektmanagements erläutert. Die Architektur der siehe 2.1 Software wird beschrieben und die hohe Anpassbarkeit wird an einem Beispiel geschildert. Informationen über die Projektron GmbH und die von ihr entwickelte Software Projektron BCS stammen von der Internetpräsenz des Unternehmens [Projektron]. Die Projektron GmbH wurde 2001 gegründet. Neben der kontinuierlichen Weiterentwicklung der Projektmanagement-Software Projektron BCS bietet die Projektron GmbH Dienstleistungen rund um die Einführung, Integration und Erweiterung ihres Softwareprodukts. Im Hauptsitz Berlin und weiteren Büros in München, Hamburg, Bonn, Leipzig und Karlsruhe beschäftigt die Projektron GmbH insgesamt mehr als 40 Mitarbeiter. Über 200 Kunden aus Deutschland, Italien, Luxemburg, Holland, Österreich und der Schweiz, darunter IT-Unternehmen, Beratungs- und Forschungseinrichtungen, Entwicklungsabteilungen der Industrie sowie öffentliche Einrichtungen, setzen Projektron BCS ein. Diplomarbeit Robert Kalweit 37

54 4 Projektron BCS 4.1 Funktionen In der Standardkonfiguration gibt es die Arbeitsbereiche Mein BCS, Zeiterfassung, Projekte, Intern, Extern und Administration (Abbildung 4.1). Sämtliche Funktionen der Software sind einem dieser Arbeitsbereiche zugeordnet. Der Bereich Mein BCS dient der persönlichen Arbeitsorganisation. Hier werden Termine, Notizen und Lesezeichen aufgeführt. Möglichkeiten zur Erfassung der eigenen Arbeitszeit sowie Übersichten der eigenen Aufgaben und verschiedene Auswertungen sind dem Arbeitsbereich Zeiterfassung zugeordnet. Die Bereiche Intern und Extern dienen dem Personal- und Kontaktmanagement. Unter Administration werden Nutzer und Lizenzen, sowie Zugriffsrechte verwaltet. Projekte werden im gleichnamigen Bereich geplant, überwacht und gesteuert. Abbildung 4.1: Arbeitsbereiche in Projektron BCS Projektplanung: Sowohl beim Erstellen als auch beim Bearbeiten eines Projekts bietet Projektron BCS Unterstützung durch einen Assistenten. Dessen Schritte sind in Abbildung 4.2 hervorgehoben. Für das Verständnis dieser Arbeit nicht relevante Schritte des Assistenten werden nicht näher erläutert. Abbildung 4.2: Projektron BCS Projektassistent 38 Diplomarbeit Robert Kalweit

55 4.1 Funktionen Im ersten Schritt werden Name, Beschreibung und Projektlaufzeit, die Stammdaten eines Projekts erfasst. Hier erfolgt weiterhin die Entscheidung für ein Projektplanungsmodell. Zur Auswahl stehen Bottom-up-Planung und Top-Down- siehe 2.2 Planung, sowie ein Modell Großes Projekt, das beide Planungsmodelle kombiniert. Die Anzahl der weiteren Schritte des Assistenten sind vom Planungsmodell abhängig. Durch die Verwendung von Projektvorlagen kann in Schritt Drei eine durch komplexe Zeit-, Kosten- und Aufwandspläne möglicherweise sehr umfangreiche Projektplanung beschleunigt werden. Der Strukturplan (Schritt Vier), in dem Projekte in Unterprojekte, Arbeitspakete und Aufgaben unterteilt werden, wird in Abbildung 4.2 gezeigt. Es ist möglich, beliebig tief verzweigte Projektstrukturen anzulegen. Inhalts- und Umfangsmanagement wird dadurch auf mehreren Hierarchieebenen unterstützt. Eine zeitliche Terminierung der genannten Strukturelemente kann im fünften Schritt, der Zeitplanung vorgenommen werden. Ressourcenmanagement: Aufteilung und optimale Auslastung sämtlicher für die Projektarbeit benötigter Ressourcen (z. B. Arbeitskräfte, Werkzeuge) sind Aufgabe und Ziel des Ressourcenmanagements ([Angermeier 2005]). Mitarbeiter haben ein bestimmtes Arbeitszeitmodell und individuelle Fähigkeiten (skills). Beides muss in der Projektplanung berücksichtigt werden. Projektron BCS ermöglicht Skillmanagement (als Teil des Ressourcenmanagements), indem an Mitarbeitern ein Qualifikationsprofil mit diversen Informationen hinterlegt werden kann. In Schritt Sechs des Assistenten, der Teamplanung, werden den Strukturelementen des Projekts Mitarbeiter zugewiesen. Dabei kann unter anderem nach skills gefiltert werden. Die geplanten Aufwände je Strukturelement können im siebten Schritt, dem Aufwandsplan, erfasst werden. Die Verwaltung der Urlaubs- und Arbeitszeit von Mitarbeitern beeinflusst ebenfalls die Projektplanung. Im Schritt Acht, der Ressourcenauslastung, wird die aktuelle Auslastung der Mitarbeiter ermittelt. Ein Projektleiter sieht die verfügbare Kapazität der Projektbeteiligten und kann so rechtzeitig Ressourcenengpässe erkennen. Dies ist auch im Projektverlauf möglich. Ressourcenknappheit durch gestiegene Restaufwände ist jederzeit ersichtlich. Diplomarbeit Robert Kalweit 39

56 4 Projektron BCS Projektron BCS bietet ressourcentreue Terminplanung, die es ermöglicht, ein Projekt oder seine Strukturelemente zeitlich an der Verfügbarkeit der Mitarbeiter auszurichten. Qualitätsmanagement: Projektspezifische Dokumente werden in einer Dateiablage direkt an Projekten oder deren Teilen abgelegt. Dateiablagen können im zehnten Schritt des Assistenten oder auch im Projektverlauf angelegt werden. Die zentrale Definition der Verzeichnisse mittels Vorlagen führt zu einer einheitlichen projektübergreifenden Verzeichnisstruktur und unterstützt auf diese Weise das Dokumentenmanagement. Die Erstellung von Dokumentenvorlagen dient dem Qualitätsmanagement durch prozesskonforme Dokumentation. Über Verlaufsprotokolle und Prozess-Workflows können Entscheidungsprozesse, Genehmigungsverfahren und Vorgänge zur Qualitätssicherung abgebildet werden. Zeiterfassung: Die Arbeitszeiten und damit die Aufwände der Projektmitarbeiter für eine Aufgabe werden direkt auf Aufgaben gebucht. Durch die Erfassung von Restaufwandschätzungen wird Projektleitern jederzeit ermöglicht, sowohl den Fortschritt von Aufgaben einzusehen als auch festzustellen, ob die potenziell benötigte Zeit über die vorgesehene Zeit hinausgeht. Je nach Genauigkeit der Schätzungen ist so ein optimales Terminmanagement gewährleistet. Projektcontrolling: Durch die Möglichkeit, auf jeder Ebene der Projektstruktur verschiedene Auswertungen durchzuführen, wird umfangreiches Projektcontrolling unterstützt. Eine Ampelfunktion ermöglicht dabei eine schnelle Identifizierung zeitlicher und finanzieller Budgetüberschreitungen und beugt so Projektrisiken vor. Dabei wird im Rahmen des Kostenmanagements zwischen Personalund Sachkosten unterschieden. Ticketsystem: Das Ticketsystem verwaltet an Projekten und Aufgaben Tickets. Dabei handelt es sich um Anmerkungen, die von Teammitgliedern oder externen Projektbeteiligten erstellt werden können. Es wird zwischen verschiedenen 40 Diplomarbeit Robert Kalweit

57 4.2 Architektur Ticketarten, z. B. Fehlermeldungen (bug-reports) oder Änderungswünschen (changerequests), unterschieden. Tickets haben im Unterschied zu Strukturelementen keinen Zeitbezug, also kein Start- und Enddatum. Rechteverwaltung: Aus der Struktur eines Unternehmens resultieren firmenspezifische Rollen und Funktionen, die mit der Rechteverwaltung abgebildet werden können. Auf diese Weise werden Mitarbeitern Rollen zugeordnet, deren Zugriffsrechte auf Daten oder Aktionen entsprechend verfügbar oder eingeschränkt sind. Im Rahmen des Projektron BCS Lizenzmodells sind die Rollen und Funktionen dabei frei konfigurierbar. So können Projektleiter eine grobe Projektstruktur vorgeben und die Detailplanung der Unterprojekte den jeweiligen Unterprojektleitern überlassen. Weitere Funktionen: Der Auftragsplan dient der Budgetierung des Projekts. Über die dort definierten Auftragspositionen können durch das Fakturamodul Rechnungen erstellt werden. Vertrags- und Kontaktmanagement gewährleisten Beschaffungs- und Kommunikationsmanagement. Die Angebotserstellung rundet den Funktionsumfang von Projektron BCS ab. 4.2 Architektur Die in Abbildung 4.3 dargestellte Architektur von Projektron BCS entspricht einem Client-Server-Modell. Als Benutzeroberfläche dient ein Webbrowser, der mit einer Servlet-Engine kommuniziert. Die dort laufende BCS Webapplikation kommuniziert wiederum mit dem BCS Server, der die Eingaben des Benutzers verarbeitet. Der BCS Server ist für die Anbindung der Datenbanken zuständig. Der Clientbetrieb einer browserbasierten Software wie Projektron BCS ist in nahezu jeder Umgebung möglich. Der Serverbetrieb erfordert die Unterstützung der offenen Standards Sun Java J2SE 5.0, Servlet API 2.4, JSP 2.0, SQL-92, HTML 4.01, CSS 2.0 und JavaScript 1.5/DOM 1.0 und ist unter dieser Bedingung ebenfalls 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 Diplomarbeit Robert Kalweit 41

58 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 Exportmöglichkeiten unter anderem per CSV und XML. Der Aufbau der Benutzeroberfläche von Projektron BCS ist in Abbildung 4.4 dargestellt. Jeder Arbeitsbereich hat eine eigene Seite. Diese Seiten enthalten verschiedene Ansichten, im Beispiel die Stammdaten eines Projekts, die wiederum in zwei Modi (display und edit) aufgerufen werden können. Die Abbildung zeigt den Bearbeitungsmodus, daher ist das aktuelle Element ein Formular. Weitere Elemente sind Detail-, Listen- und Baumansichten. siehe A.1 Projektron BCS verwaltet Daten mit Objekten wie z. B. Projekten, Aufgaben, Organisationen und Personen. Attribute bestimmen die Eigenschaften dieser Objekte. Weiterhin können Objekte Subtypen haben, die die Sichtbarkeit von Attributen einschränken und so das Objekt genauer definieren. So hat das Objekt Projekt unter anderem die Subtypen Unterprojekt und Vorlage. Die komplette Datenstruktur kann im Arbeitsbereich Administration eingesehen werden, ein Auszug ist in Anhang A.1 aufgeführt. Welche Daten in einem Attribut gespeichert werden können und wie diese in der Benutzeroberfläche dargestellt werden, ist vom Datentyp des Attributs abhängig. Projektron BCS verwendet unter anderem die Datentypen Int für numerische Werte 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 42 Diplomarbeit Robert Kalweit

59 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 in Projektron BCS eindeutig identifiziert. An einem Objekt wird die eigene Identifikationsnummer textuell dargestellt (z. B _JUser). Enthält ein Attribut die OID 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 zwischen 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 Diplomarbeit Robert Kalweit 43

60 4 Projektron BCS kann die Benutzeroberfläche an das Corporate Design eines Kunden angepasst werden. Alle in der Benutzeroberfläche gezeigten Texte (Label, Tooltips, Fehlermeldungen) können umbenannt werden. Auch die vollständige Internationalisierung (internationalization, I18n 10 ) von Projektron BCS ist auf diese Weise möglich. Die zeitliche Steuerung, das Scheduling, regelmäßig auszuführender Aufgaben, Jobs, erfolgt ebenfalls per Konfiguration. Ein Überblick der Konfigurationsdateien wird in Tabelle 4.1 geboten. Bereich Dateiname(n) BCS Server BCS Webapplikation Label Dateiablage Serverconfig*.properties WebConfig.properties WebConfigEdit.xml i18n*.properties WebPath.properties Jobs CronTools.properties SchedulerConfig.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 die Oberfläche von Projektron BCS und verdeutlicht so die Flexibilität der Software. Dem Subtyp project des BCS-Objekttyps JProject werden drei weitere Attribute hinzugefügt. Listing 4.1: Beispieleintrag in einer ServerConfig*.properties-Datei 1 Project.CustomAttributes=\ 2 Hochschule=String Fachbereich=Int Studiengang=String 3 JProject.subtyp. attribs. project=\ 4 Hochschule Fachbereich Studiengang 5 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, dass gerade die Seite projectdetail im Modus edit der Ansicht main bearbeitet 10 Die 18 steht dabei für die Anzahl der gekürzten Buchstaben der englischen Schreibweise. 44 Diplomarbeit Robert Kalweit

61 4.3 Flexibilität wird. Das Element ist das Formular default. Diesem Element werden die drei Attribute Hochschule, Fachbereich und Studiengang hinzugefügt. Die gleiche Anpassung 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 Attribute werden mit den in Listing 4.1 definierten Optionen angezeigt. Zum Vergleich ist die komplette Ansicht ohne die Anpassungen in Abbildung 4.4 dargestellt. Die Unterstriche in den Attributnamen können anschließend durch Einträge in der i18n*.properties entfernt werden. Abbildung 4.6: Zusätzliche Attribute eines Projekts Neue Termintypen und Feiertage im Projektron BCS Kalender können auf ähnliche Weise definiert werden. Über die Benutzeroberfläche werden Rollen und Rechte, sowie Relationen konfiguriert. Diplomarbeit Robert Kalweit 45

62 4 Projektron BCS 46 Diplomarbeit Robert Kalweit

63 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 Hypoport AG und der Darlegung des Softwareentwicklungs- und des Scrum Prozesses innerhalb der Hypoport AG. Für die Ist-Aufnahme wurde in diesem Fall die Interviewmethode gewählt. Die Erfassung des gegenwärtigen Zustands basiert daher auf offenen, nicht standardisierten Interviews mit Herrn Sebastian Heide, ScrumMaster, und Herrn Robert Gimbel, Projektmanager bei Hypoport. Während dieser Interviews verfasste Notizen, sowie die als Abschluss der Ist-Aufnahme erstellte Zusammenfassung und deren Korrektur durch die Interviewpartner sind in Anhang B aufgeführt. (vgl. [Krallmann u. a. 2002, S.66ff., S.80]) Die Hypoport AG 11, mit Hauptsitz in Berlin ist ein Finanzdienstleister, der selbst Finanzprodukte vertreibt und darüber hinaus mit EUROPACE die größte deutsche Internetplattform zum Abschluss von Finanzprodukten bereitstellt. Kunden 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, so wirkt dies unmittelbar auf Vertriebspartner. Diese sehen sofort die eventuell besseren Konditionen des Kreditgebers und fällen Entscheidungen aufgrund stets aktueller Informationen. Das Projektmanagement bei Hypoport erfolgt sowohl mit Projektron BCS als auch mit JIRA 12. Dabei hat sich die bug tracking-, issue tracking- und PM- Software der Firma Atlassian weitgehend durchgesetzt Diplomarbeit Robert Kalweit 47

64 5 Scrum bei der Hypoport AG Abbildung 5.1: Acht Elemente der Europace Plattform, Quelle: 5.1 Prozess und Software-Anforderungen Im Folgenden werden der Scrum Prozess der Hypoport AG geschildert und die Anforderungen der einzelnen Schritte an die Softwareunterstützung hervorgehoben. Dabei wird der Begriff Strukturelement sowohl für JIRA-Tickets als auch für Projektron BCS Strukturelemente und Tickets verwendet, also sämtliche Ele- mente, die ein Projekt strukturieren. siehe 4.1 Die Auftragsstruktur der Hypoport AG erfordert Anpassungen des Scrum Prozesses. Hypoport liefert nicht ein Softwareprodukt nach dem anderen, sondern Releases der Elemente des EUROPACE Produkts. Daher gibt es nicht ein einziges Product Backlog, sondern eines je EUROPACE Element. Im Folgenden werden diese Elemente Produkt und deren Releases Projekte genannt. Aufgrund der durch externe Berater geförderten und bescheinigten guten Adaption des Scrum Prozesses besteht keine Notwendigkeit eines Vollzeit-ScrumMasters für jedes Projekt. Momentan betreuen daher zwei ScrumMaster sämtliche Projekte der Hypoport AG. Dies hat jedoch zwei offensichtliche Nachteile: Fällt einer der beiden ScrumMaster aus, kann es vorkommen, dass der zweite bis zu sieben Daily Scrum Meetings täglich hat. Darüber hinaus gerät ein ScrumMaster bei der Beseitigung von Hindernissen in Entscheidungskonflikte, wenn seine Projekte oder deren Teams konkurrieren. 48 Diplomarbeit Robert Kalweit

65 5.1 Prozess und Software-Anforderungen Die Hypoport AG arbeitet mit Releasezyklen von drei Monaten und einer Sprintdauer von vier Wochen. Ein Projekt umfasst daher in der Regel drei Sprints. Refactoringprojekte, also Projekte, die keine neue Funktionalität liefern, sondern die bestehende Struktur der Software umgestalten und verbessern, sind weitgehend unabhängig von Kundenanforderungen. Daher kann die Dauer eines solchen Projekts über den normalen Releasezyklus hinausgehen. In einem Team arbeiten fünf bis acht Mitarbeiter, die mit Projektron BCS ihre Arbeitszeit erfassen. Überlastungen werden vermieden, indem in JIRA nur sechs Stunden pro Tag für Projektaufgaben eingeplant werden. So wird gewährleistet, dass genug Zeit für Team-internen Wissensaustausch bleibt. Software-Anforderungen: 1 Erfassung allgemeiner/projektbezogenener Aufwände 2 Definition einer Grundlast Da jedes Produkt bei etlichen Kunden im Einsatz ist, ergeben sich an ein Projekt 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 verwaltet deren Anforderungen. Diese werden grob als Features 13 formuliert und je Feature wird ein Konzept erstellt. Die Projektmanager eines Produkts stellen dann gemeinsam aus der Menge der Anforderungen aller Kunden das Product Backlog zusammen. In die Priorisierung der Anforderungen fließen dabei auch Ansprüche des übergeordneten Managements ein: Anforderungen mit hohem Nutzen für die Hypoport AG (Business Value) werden höher priorisiert. Im weiteren Verlauf werden Anforderungen in epics und user stories unterteilt und auf diese Weise siehe 3.2 verfeinert. Die Aufgaben des im Scrum Prozess vorgesehenen Product Owners werden bei Hypoport von mehreren Projektmanagern erfüllt. Die softwaregestützte Erfassung der Anforderungen erfolgt in beiden genannten Tools: In Projektron BCS werden die Features eines Projekts hierarchisch nach Kunden geordnet. Abbildung 5.3 zeigt auszugsweise, wie der Strukturplan eines Projekts 13 Die Hypoport AG praktiziert kein Feature Driven Development (FDD). Der Begriff Feature wird in seiner allgemeinen Bedeutung Funktion verwendet. Diplomarbeit Robert Kalweit 49

66 5 Scrum bei der Hypoport AG Abbildung 5.2: Aktivitätsdiagramm der Anforderungserhebung eines Projekts der Hypoport AG der Hypoport AG aussehen könnte. Den Unterprojekten, die besagte Features repräsentieren, werden dabei die entsprechenden Ticketnummern in JIRA vorangestellt. Um Zeiterfassung und Abrechenbarkeit zu gewährleisten, werden pro Feature je eine Entwicklungs-, Test- und Projektmanagementaufgabe erstellt. Eine detaillierte Projektplanung mit genauer festgelegten Vorgängen oder gar Meilensteinen erfolgt nicht. Stattdessen wird durch die direkte Zuordnung der Features zu Kunden eine übergeordnete Managementsicht dargestellt, die die Rechnungsstellung der Features ermöglicht. Abbildung 5.3: Projektron BCS Strukturplan eines Hypoport-Projekts Software-Anforderungen: 3 Zuordnung von Kunden zu Strukturelementen 4 Product Backlog als priorisierte Strukturelement-Liste 50 Diplomarbeit Robert Kalweit

67 5.1 Prozess und Software-Anforderungen In JIRA hingegen wird das Product Backlog eines Projekts produkt- und funktionsbezogen 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 story Tabelle 5.1: JIRA Tickethierarchie der Hypoport AG Während der JIRA Standard vier Ticketarten definiert, verwendet Hypoport mehr als dreißig Ticketarten, um Anforderungen zu klassifizieren. User stories werden unter anderem in verbindliche (mandatory) und optionale Anforderungen, die den Kunden begeistern (exciter), unterteilt. Darüber hinaus gibt es mehrere Arten von Akzeptanztests, die durchgeführt werden, sobald eine user story umgesetzt wurde. Verschiedene Tests haben jeweils einen eigenen Lebenszyklus, also spezifische Status mit vorgegebenen Statusübergängen. Zwei dieser Lebenszyklen sind in Abbildung 5.4 dargestellt. siehe B.2 Software-Anforderungen: 5 Definition eigener Strukturelemente 6 Definition diverser Lebenszyklen für Strukturelemente Um die iterative Verfeinerung von Anforderungen zu ermöglichen, können Tickets in andere Ticketarten umgewandelt werden. Epics, die im Projektverlauf als detailliert genug erachtet werden, können so beispielsweise in user stories konvertiert werden. JIRA protokolliert dabei jedwede Änderung und auch, wann und durch wen diese vorgenommen wurde. Software-Anforderungen: 7 Umwandlungen zwischen Strukturelementen 8 Protokollierung der Änderungen an Strukturelementen Im Sprint Planning Meeting bestimmt das Team diejenigen der hoch priorisierten Anforderungen, die im kommenden Sprint umgesetzt werden. Der Status der entsprechenden Unterprojekte wird in Projektron BCS von Geplant auf Offen gesetzt, damit die Aufgaben für Teammitglieder in der Zeiterfassung angezeigt Diplomarbeit Robert Kalweit 51

68 5 Scrum bei der Hypoport AG Abbildung 5.4: Lebenszyklen als Zustandsdiagramme nach [oose 2008] links: user stories, rechts: Akzeptanztests werden. Das Sprint Backlog unterscheidet sich für Projektmanager in Projektron BCS vom Product Backlog nur durch die Status der Strukturelemente. Die Elemente, die den Status Offen haben, bilden das aktuelle Sprint Backlog. Die Erfassung von Aufwänden ist ausschließlich auf der Ebene von Unterprojekten, also Features, relevant. Daher spielt es keine Rolle, wie detailliert die Aufgaben geplant sind - Teammitglieder buchen dann Aufwände auf die Entwicklungs-, Test- und Projektmanagementaufgabe des Unterprojekts. siehe 3.3 In JIRA ist jedes Ticket, dessen Umsetzung beschlossen wurde, also jeder Eintrag des Sprint Backlogs, einem Mitarbeiter zugewiesen. Diese Zuweisung erfolgt beim Anlegen des Tickets. Teammitglieder können jedoch Tickets jederzeit anderen Kollegen zuweisen. Auf diese Weise erfolgt die Aufgabenverteilung innerhalb des Teams durch das Team. Weiterhin werden an jedem Ticket abstrakte Aufwandsschätzungen mit story points verwaltet. 52 Diplomarbeit Robert Kalweit

69 5.1 Prozess und Software-Anforderungen Software-Anforderungen: 9 Teaminterne Aufgabenzuweisung 10 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 Tickets vorziehen. ScrumMaster und Teams nutzen Projektron BCS ausschließlich zur Zeiterfassung. Die Aussagekraft aufgabenspezifischer Auswertungen ist aufgrund der Verwendung von je einer Entwicklungs-, PM- und Testaufgabe nur gering. Daher nutzen selbst Projektleiter von den zahlreichen Auswertungen, die Projektron BCS bietet, lediglich die Auswertung Aufwände/Projekt. Bei Hypoport werden die im Scrum Prozess vorgesehenen Meetings wie beschrieben praktiziert. Aufgrund nur minimaler Abwandlungen der bereits aufgeführten Aktivitätsdiagramme dieser Meetings befindet sich die detaillierte Abbildung des Scrum Prozesses der Hypoport AG in Anhang C. Im Sprint Review Meeting demonstriert das Team den Projektleitern, sowie eventuell anwesenden Kunden fertige Funktionalität, also solche, die sämtliche Akzeptanzkriterien in entsprechenden Tests erfüllt hat. Effektive Sprint Retrospective Meetings liefern produktive Vorschläge zur Verbesserung der Prozesse. In Daily Scrum Meetings stimmt das Team die tägliche Arbeit aufeinander ab. Eine Anforderung, die nicht explizit von der Hypoport AG gefordert wird, aber als best practice bei der Anwendung von Scrum gilt, ist die Ermittlung der Entwicklungsgeschwindigkeit, der velocity, basierend auf der Verwendung abstrakter Aufwandsschätzungen. Auf diese Weise kann prognostiziert werden, wie viel Zeit zur Umsetzung der verbleibenden Funktionalität benötigt wird. Als zweite zusätzliche Anforderung wird die Visualisierung des Projekt- oder Sprintfortschritts in einem Burndown Chart aufgenommen. Durch das Diagramm wird sofort ersichtlich, ob die Entwicklungsgeschwindigkeit des Teams höher oder niedriger ist, als geplant und ob das Projekt- oder Sprintziel in der vorgesehenen Zeit erreicht werden kann. Ein ScrumMaster erkennt an einer niedrigeren velocity, dass eventuell Hindernisse existieren. Diplomarbeit Robert Kalweit 53

70 5 Scrum bei der Hypoport AG 5.2 Vergleich der Anforderungen mit Projektron BCS siehe 4.2 Bei der Einführung der Software wurden sowohl die Projektplanung als auch das Ticketsystem in Projektron BCS evaluiert, konnten sich jedoch gegen den Einsatz von JIRA nicht behaupten. Inwiefern der Grund in der unzureichenden Erfüllung der Anforderungen durch eine frühere Version von Projektron BCS lag, kann nicht mehr nachvollzogen werden. Als zum Teil immer noch aktueller Grund für die mangelnde Akzeptanz von Projektron BCS wurden Aspekte der Benutzerfreundlichkeit, wie die höhere Klick-Häufigkeit durch den Wechsel in den Bearbeitungsmodus genannt. Im Folgenden werden die erfassten Anforderungen des Scrum Prozesses bei der Hypoport AG an die Softwareunterstützung, aufgeführt in Tabelle 5.2, analysiert. Dabei wird nachgewiesen, ob und wie diese Anforderungen durch Projektron BCS in der Version beta erfüllt werden. Der gegenwärtige Ist-Zustand bei der Hypoport AG ist gleichzeitig der angestrebte Soll-Zustand für den Einsatz von Projektron BCS. Kernanforderungen 1 Erfassung allgemeiner/projektbezogenener Aufwände 2 Definition einer Grundlast 3 Zuordnung von Kunden zu Strukturelementen 4 Product Backlog als priorisierte Strukturelement-Liste 5 Definition eigener Strukturelemente 6 Definition diverser Lebenszyklen für Strukturelemente 7 Umwandlungen zwischen Strukturelementen 8 Protokollierung der Änderungen an Strukturelementen 9 Teaminterne Aufgabenzuweisung 10 Abstrakte Aufwandsschätzungen Zusätzliche Anforderungen ❶ Bestimmen der velocity ❷ Visualisierung des Projekt- oder Sprintfortschritts in einem Burndown Chart Tabelle 5.2: Anforderungen an die Softwareunterstützung 54 Diplomarbeit Robert Kalweit

71 5.2 Vergleich der Anforderungen mit Projektron BCS Die Erfüllung sämtlicher Kernanforderungen außer der Zuordnung von Projekten zu Kunden (3) und der vollständigen Aufwandserfassung (1) durch JIRA sei durch die Beschreibung des Prozesses belegt. Der folgende Soll-Ist-Vergleich bezieht sich daher auf die Funktionen von Projektron BCS. 1 Erfassung allgemeiner und projektbezogenener Aufwände: Die Funktion der Zeiterfassung war der Hauptgrund für die Einführung von Projektron BCS bei der Hypoport AG und ist Kernfunktion von Projektron BCS. Die Protokollierung aufgewandter Projektarbeitszeit ist auch in JIRA möglich. Um die Abrechnung der aufgewandten Arbeitszeit so effektiv wie möglich zu gewährleisten, erfolgt die Zeiterfassung sowohl allgemeiner als auch projektbezogener Aufwände ausschließlich in Projektron BCS. Diese Anforderung wird daher als erfüllt erachtet. Wichtig ist, dass die Zeiterfassung bei Erfüllung weiterer Anforderungen, z. B. der Definition eigener Strukturelemente und deren Umwandlung gewährleistet bleibt. Abbildung 5.5: Definition der Grundlast und Ressourcenauslastung 2 Definition einer Grundlast: Durch die Definition einer Grundlast, also einer bestimmten Anzahl an Stunden pro Tag, die nicht für Projektarbeit aufgewandt werden können, ist es möglich Überlastungen durch Wissensaustausch zu vermeiden. Das Konzept von Grundlasten ist in Projektron BCS bereits umgesetzt. Diplomarbeit Robert Kalweit 55

72 5 Scrum bei der Hypoport AG Abbildung 5.5 zeigt die Definition von Grundlasten im Arbeitsbereich Projekte und deren Repräsentation in der Ressourcenauslastung eines Mitarbeiters. 3 Zuordnung von Kunden zu Strukturelementen: Bei Hypoport werden zwar die Strukturelemente der Projekte hierarchisch nach Kunden geordnet, doch müsste dies geändert werden, sobald eine detaillierte Projektplanung in Projektron BCS erfolgt. Die Erstellung eines Strukturelements, das die Kundenzuordnung repräsentiert (z. B. ein Unterprojekt mit dem Namen des Kunden, wie in Abbildung 5.3), widerspricht dem Ziel einer produktbezogenen Abbildung, wie sie momentan in JIRA umgesetzt ist. Abbildung 5.6: Einer Organisation zugeordnete Projekte Gegenwärtig ist es in der Teamplanung eines Projektron BCS Strukturelements bereits möglich, externe Mitarbeiter oder sogar ganze Organisationen zuzuordnen. Dadurch sind, wie Abbildung 5.6 veranschaulicht, sämtliche einem Kunden zugeordnete Projekte (oder deren Elemente) auf einen Blick am Kunden ersichtlich. Eine solche Zuordnung ist auch an Projektron BCS Tickets möglich. Diese Anforderung ist damit in der Standardkonfiguration erfüllt. 4 Product Backlog als priorisierte Liste von Strukturelementen: Sämtliche Strukturelemente eines Projekts haben in Projektron BCS eine Priorität. Der Strukturplan eines Projekts stellt das Product Backlog dar, vorausgesetzt, die Spalte Priorität (hervorgehoben in Abbildung 5.7) ist eingeblendet. Obwohl es sich beim Strukturplan statt einer Listen- um eine Baumansicht handelt, sind alle relevanten Informationen enthalten. Damit ist die Erfüllung dieser Anforderung belegt. 56 Diplomarbeit Robert Kalweit

73 5.2 Vergleich der Anforderungen mit Projektron BCS Abbildung 5.7: Product Backlog in Projektron BCS 5 Definition eigener Strukturelemente: Die Definition eigener Strukturelemente ist Voraussetzung für die Verknüpfung mit verschiedenen Lebenszyklen. Gegenwärtig können mit dem beschriebenen WebConfigEditor bereits eigene Struk- siehe 4.3 turelemente 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 Ticket Art = 1 Art = 2 Art = 3 Ticket Ticketart 1 Ticketart 2 Ticketart 3 Abbildung 5.8: Schematische Datenstruktur links: Aufgabe mit Subtypen, Mitte: Anmerkung mit Subtyp Ticket und dessen Attribut Art, rechts: Idealzustand mit Ticketarten als Subtypen von Ticket Für Tickets in Projektron BCS ist dies nicht möglich, da diese keine eigenständigen Objekte, sondern bereits ein Subtyp des Objekts Anmerkung sind. Im Ticketsystem erfolgt daher die Definition eigener Ticketarten ausschließlich über das Attribut Art. Abbildung 5.8 veranschaulicht dies (Mitte). Es gibt Verknüpfungen zwischen Tickets in Form von Zuordnungen, welche die Namen Verwandte Tickets und Duplikate tragen. Damit ist es jedoch nicht möglich, Tickets wie im Strukturplan hierarchisch anzuordnen. Es fehlen Vorgänger-Nachfolger- und siehe 4.1 Eltern-Kind-Beziehungen, um eine Struktur abzubilden. Um dies zu ermöglichen, Diplomarbeit Robert Kalweit 57

74 5 Scrum bei der Hypoport AG muss die Datenstruktur an die der Aufgaben und Projekte angepasst werden (Abbildung 5.8, rechts). Diese Anforderung gilt daher nur als teilweise erfüllt. 6 Definition diverser Lebenszyklen für Strukturelemente: Verschiedene Anforderungen werden auf unterschiedliche Art und Weise bearbeitet. Diese verschiedenen Abläufe zu repräsentieren, ist nur möglich, indem für verschiedene Strukturelemente 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 Aufgaben und Projekten möglich. Mit dem Attribut state können dort verschiedene Status verwaltet werden. In der Standardkonfiguration füllt die Menge der Status-Attribute eine Dropdown-Liste im Bearbeitungsmodus des jeweiligen Subtyps (Abbildung 5.9). Abbildung 5.9: Auszug aus der Datenstrukturinfo einer Aufgabe und Statusanzeige Lebenszyklen können mit XML-Konfigurationsdateien verwaltet werden. Aufgrund der zuvor geschilderten Datenstruktur ist aber die Definition unterschiedlicher Lebenszyklen für verschiedene Ticketarten nicht möglich. Ein Beispiel für die Konfiguration 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. 7 Umwandlungen zwischen Strukturelementen: Um die durch den Scrum Prozess vorgegebene und bei Hypoport praktizierte iterative Verfeinerung der Anforderungen zu erreichen, müssen Strukturelemente eines Projekts ineinander 58 Diplomarbeit Robert Kalweit

75 5.2 Vergleich der Anforderungen mit Projektron BCS umgewandelt werden können. Dies ist gegenwärtig in Projektron BCS nicht möglich. Wird eine Anforderung als Aufgabe geplant, kann dies nicht mehr verändert werden. Ein Anwendungsfall dafür ergibt sich aus dem Zusammenhang zwischen epics und user stories: Eine Aufgabe eine user story wird zu Beginn des Projekts angelegt, stellt sich aber im weiteren Verlauf als zu groß als epic heraus. Diese Feststellung wurde von einem Entwickler getroffen, nachdem dieser mehrere Stunden mit der Aufgabe zugebracht und auch die entsprechende Zeit gebucht hat. Ein Arbeitspaket, das mehrere 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 auf Arbeitspakete ist jedoch nicht möglich. Präventiv gröbere Strukturelemente, in diesem Fall Arbeitspakete, anzulegen ist ebenfalls nicht zielführend. Zwar kann, wenn eine Verfeinerung nicht mehr notwendig ist, darunter eine einzige Aufgabe erstellt werden, um Aufwände zu erfassen, doch ist dies aus zwei Gründen nicht optimal. Die unnötige Erstellung eines weiteren Elements ist erstens Verschwendung (die Scrum zu Vermeiden versucht) siehe 2.2 und widerspricht zweitens dem Konzept von epics und user stories. Ein epic, das nicht 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 Anforderung nach Umwandlungen zwischen Strukturelementen als nicht erfüllt. 8 Protokollierung der Änderungen an Strukturelementen: Die Protokollierung von Änderungen erfolgt an jedem Strukturelement in Projektron BCS, ersichtlich über das Menu Eigenschaften und den Menueintrag Log. Auch im Ticketsystem werden die Änderung, der Bearbeiter und der Zeitpunkt der Änderung erfasst. Das Kommentieren von Tickets ist ebenfalls möglich. Abbildung 5.10 zeigt die Änderungshistorie eines Tickets. 9 Teaminterne Aufgabenzuweisung: Im Rahmen der Anwendung von Scrum entscheidet das Team, wer welche Aufgaben übernimmt. Die Aufgabenzuweisung (Teamplanung) ist in Projektron BCS an die Projektleiterlizenz gebunden. Daher siehe 4.1 Diplomarbeit Robert Kalweit 59

76 5 Scrum bei der Hypoport AG Abbildung 5.10: Änderungshistorie im Projektron BCS Ticketsystem gibt es drei Möglichkeiten das Selbstmanagement des Teams zu unterstützen. Das Team kann im Sprint Planning Meeting dem Projektleiter mitteilen, wie die Aufgaben verteilt werden. Bei einer Veränderung muss jedoch der Projektleiter erneut eingreifen. Eine zweite Möglichkeit ist die Zuweisung des ganzen Teams jedes Teammitglieds zu allen Aufgaben. In diesem Fall ist für einen Projektmanager nicht ersichtlich, wie die Aufgaben tatsächlich verteilt sind. Die dritte Variante ist die Vergabe einer Projektleiterlizenz für jedes Teammitglied. Mit dieser Lizenz sind jedoch etliche weitere Funktionen verfügbar, was sich im Preis widerspiegelt. Die letzten beiden Möglichkeiten unterstützen das Selbstmanagement des Teams aktiv. Im Ticketsystem ist die teaminterne Aufgabenzuweisung durch das Attribut Bearbeiter gegeben. Dies kann durch jeden Mitarbeiter geändert werden, was, verantwortungsbewussten Umgang vorausgesetzt, dem Team die Arbeitsorganisation erheblich erleichtert. Damit ist die Erfüllung dieser Anforderung belegt. siehe Abstrakte Aufwandsschätzungen: Restaufwände werden in Projektron BCS in Zeiteinheiten geschätzt. Die Vorteile abstrakter Aufwandsschätzungen wurden bereits geschildert. Es ist per Konfiguration möglich, ein zusätzliches Attribut zu definieren, das den abstrakten Aufwand eines Strukturelements enthält. Ziel ist, aus der Fertigstellung untergeordneter Elemente direkt (abhängig von der Qualität der Schätzung und Unterteilung) auf den Fertigstellungsgrad des übergeordneten Elements zu schließen. Dazu müssen Aufwände größerer Strukturelemente als Summen der Aufwände ihrer Teile dargestellt werden. Ein entsprechender Automatismus kann nicht konfiguriert werden. Dies jedoch mit der zuvor beschrie- 60 Diplomarbeit Robert Kalweit

77 5.3 Vorgaben benen Konfiguration über alle Hierarchieebenen manuell vorzunehmen, wird für die Erfüllung dieser Anforderung als nicht ausreichend erachtet. ❶ Velocity und ❷ Burndown Chart: Die beiden zusätzlichen Anforderungen werden gegenwärtig weder von Projektron BCS noch von JIRA erfüllt. Anforderung Projektron BCS JIRA Kernanforderungen 1 Erfassung allgemeiner/projektbezogenener Aufwände 2 Definition einer Grundlast 3 Zuordnung von Kunden zu Strukturelementen 4 Product Backlog als priorisierte Strukturelement-Liste 5 Definition eigener Strukturelemente 6 Definition diverser Lebenszyklen für Strukturelemente 7 Umwandlungen zwischen Strukturelementen 8 Protokollierung der Änderungen an Strukturelementen 9 Teaminterne Aufgabenzuweisung 10 Abstrakte Aufwandsschätzungen Zusätzliche Anforderungen ❶ Bestimmen der velocity ❷ Visualisierung des Projekt- oder Sprintfortschritts in einem Burndown Chart Legende Anforderung erfüllt zum Teil erfüllt nicht erfüllt Tabelle 5.3: Erfüllung der Anforderungen durch die Software Die Erfüllung der Anforderungen durch beide Softwaretools ist in Tabelle 5.3 gegenübergestellt. 5.3 Vorgaben Um die Möglichkeit zu schaffen, auf JIRA zu verzichten und auch die detaillierte Projektplanung in Projektron BCS abzubilden, müssen diejenigen Anforderungen Diplomarbeit Robert Kalweit 61

78 5 Scrum bei der Hypoport AG umgesetzt werden, die gegenwärtig von JIRA vollständig, von Projektron BCS jedoch nur teilweise bis gar nicht erfüllt werden. Basierend auf der Beschreibung eines Pflichtenhefts nach Balzert werden die Vorgaben für die Anpassungen und Konzeption dargestellt, darunter auch die Vorgaben der Projektron GmbH (Vgl. [Balzert 2000]). Auf eine Schilderung der Produktfunktionen wird dabei verzichtet, da diese im Rahmen des Soll-Ist-Vergleichs bereits verdeutlicht wurden. Zielbestimmung Wenngleich der Fokus der Arbeit darauf liegt, das PM mit Projektron BCS in Hinblick auf Scrum bei der Hypoport AG zu verbessern, besteht der Anspruch darin, ein standardwürdiges Konzept und ebensolche Anpassungen zu erstellen. Die Anforderungen werden soweit spezifiziert, dass ein Abgleich der Anpassungen und 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 werden können. siehe 4.1 Die Abbildung komplexer Hierarchien und Beziehungen soll ähnlich wie im Strukturplan möglich sein. Es muss möglich sein, verschiedene Lebenszyklen zu definieren. Lebenszyklen sind vorgeschriebene Möglichkeiten der Statusänderungen. Es muss die Möglichkeit bestehen, die Einhaltung des Lebenszyklus als verbindlich zu definieren. Dies muss sich in der Benutzeroberfläche widerspiegeln. Mögliche Umwandlungen zwischen Strukturelementen müssen bestimmt werden können. Auf unterschiedliche Lebenszyklen muss trotz Freiheit in der Konfiguration fehlerfrei reagiert werden. 62 Diplomarbeit Robert Kalweit

79 5.3 Vorgaben Die Verwendung abstrakter Aufwandsschätzungen muss möglich sein. Dabei muss frei wählbar sein, ob diese zusätzlich zur gegenwärtigen Schätzung oder stattdessen verwendet werden sollen. Abstrakte Aufwände müssen bottom-up zu übergeordneten Elementen kumuliert werden können. Kann-Kriterien: Aus den in einem bestimmten Zeitraum fertig gestellten Strukturelementen und deren abstrakten Aufwänden soll die velocity ermittelt werden können. Die Entwicklungsgeschwindigkeit abgeschlossener Projekte soll gespeichert werden. Der Projekt- oder Sprintfortschritt soll in einem Burndown Chart visualisiert werden können. Dabei soll die Möglichkeit bestehen, eine velocity anzugeben. Alternativ kann die durchschnittliche velocity aus wählbaren Projekten verwendet werden. Abgrenzungskriterien: Die Erfassung der velocity eines Mitarbeiters ist im Sinne des Scrum Prozesses, der die Einheit des Teams unterstützen soll, nicht vorgesehen. Die Umsetzung von Anpassungen die nicht per Konfiguration vorgenommen werden können, sondern Programmieraufwand an Projektron BCS erfordern, ist nicht als Teil der Arbeit vorgesehen. Für Anpassungen dieser Art ist ein detailliertes Konzept zu erarbeiteten. Produkteinsatz Anwendungsbereiche: Die Anpassungen ermöglichen viel Freiheit in der Konfiguration und damit die Abbildung beliebiger Prozesse und unterstützen so den umfangreicheren Einsatz von Projektron BCS sowohl innerhalb der Hypoport AG als auch in weiteren Unternehmen, die agile Projektmanagementsysteme anwenden. Diplomarbeit Robert Kalweit 63

80 5 Scrum bei der Hypoport AG Zielgruppe: Die Anpassungen richten sich in erster Linie an Entwicklerteams, deren Selbstmanagement durch die Anpassungen forciert wird. ScrumMaster und Projektmanager können den Prozess jederzeit veränderten Bedingungen anpassen. 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 festgelegt 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-Wert gespeichert. Menge: 1 (es wird genau ein Wert gespeichert) Vorgänger-Nachfolger-Beziehungen und untergeordnete Strukturelemente (Kinder) werden in Form von OIDs gespeichert. Menge: je 0-n (es können beliebig viele dieser Beziehungen gespeichert werden) Ü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 nicht erfü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 fertig dargestellt werden. Diese werden als String erfasst. Menge: 1-n (es wird mindestens ein Wert gespeichert) 64 Diplomarbeit Robert Kalweit

81 5.3 Vorgaben Qualitätsanforderungen Die folgenden Qualitätsanforderungen beziehen sich nicht auf die bestehenden Qualitätsmerkmale von Projektron BCS, sondern ausschließlich auf die im Rahmen dieser Arbeit zu erarbeitenden Anpassungen. Darüber hinaus sollen bestehende Qualitätsmerkmale von Projektron BCS nicht beeinträchtigt werden. Aufmerksamkeit: Die Aufmerksamkeit des Anwenders muss in kürzester Zeit auf die wichtigsten Bereiche gelenkt werden. Änderbarkeit: Der Aufwand, Änderungen vorzunehmen muss so gering wie möglich sein. Änderungen dürfen keine unerwarteten Wirkungen nach sich ziehen. Effizienz: Der Aufwand, bestimmte Ziele mit dem Produkt zu erreichen, soll stets der geringstmögliche sein. Erwartungskonformität: Informationen müssen innerhalb des Produkts einheitlich dargestellt werden. Funktionen müssen derart bezeichnet sein, dass sie der Erwartungshaltung des Benutzers entsprechen. Verständlichkeit: Die Anpassungen und ihre Konfigurationsmöglichkeiten werden nach Möglichkeit selbsterklärend gehalten. Bezeichner werden derart gewählt, dass ihr Zweck intuitiv ersichtlich ist. Wo dies zusätzlich notwendig ist, wird eine angemessene Dokumentation erstellt. Benutzeroberfläche Die Anpassungen müssen sich nahtlos in das Erscheinungsbild der Projektron BCS GUI einfügen. Sofern dies nicht durch Qualitätsanforderungen bedingt wird, soll die Dialogstruktur nicht verändert werden. Sämtliche Seiten der Projektron BCS Benutzeroberfläche dienen der Erfüllung bestimmter Aufgaben. Die am Diplomarbeit Robert Kalweit 65

82 5 Scrum bei der Hypoport AG Scrum Prozess bei der Hypoport AG beteiligten Rollen Projektmanager, Scrum- Master und Teammitglieder müssen zum Zugriff auf die jeweils benötigten Seiten berechtigt sein. Nichtfunktionale Anforderungen Die Projektron GmbH steht der Einführung spezieller Scrum Lizenzen aufgeschlossen gegenüber. Veränderungen am Lizenzmodell von Projektron BCS müssen detailliert geschildert und begründet werden. Die zahlreichen Auswertungen, die das Projektcontrolling bietet, dürfen nicht 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 Webbrowser Internet Explorer (6.0), Firefox (1.5), Netscape (7.0), Opera (9.21) und Safari (2.0). In Klammern steht die mindestens vorausgesetzte Version. ([Projektron]) Hardware: Für den Betrieb des Projektron BCS Servers werden mindestens 1 GB RAM, ca. 150 MB Festplattenspeicher sowie mindestens 1,8 GHz CPU- Leistung vorausgesetzt. Die Netzwerkverbindung muss eine Datenübertragungsrate von 100 Mbit/s unterstützen. Dateiablage und Datenbank benötigen anforderungsabhängig mindestens 1 GB weiteren freien Festplattenspeicher. ([Projektron]) Schnittstellen: Weitere Softwareschnittstellen sind nicht vorgesehen. Projektron BCS als technische Schnittstelle ersetzt auch mit den geforderten Anpassungen nicht die soziologischen Schnittstellen zwischen den Projektbeteiligten. 66 Diplomarbeit Robert Kalweit

83 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.3 tailliertes Konzept zu erstellen, müssen Screenshots von Projektron BCS gemacht werden. Die Systemvoraussetzungen für den Betrieb von Projektron BCS wurden bereits beschrieben. Zusätzlich ist ein Bildbearbeitungsprogramm erforderlich. Diplomarbeit Robert Kalweit 67

84 5 Scrum bei der Hypoport AG 68 Diplomarbeit Robert Kalweit

85 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 Anpassungen erläutert, sowie die Anpassungen an Projektron BCS und deren Integration in Form eines Soll-Konzepts geschildert. Aufgabe eines solchen Konzepts ist es, ein System vorzuschlagen, das die im Rahmen der Ist-Analyse aufgezeigten Schwachstellen 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 im Rahmen 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, Arbeitspakete und Aufgaben nicht verändert werden, wird das Projektcontrolling nicht beeinflusst. 3. Der gleiche Grund gewährleistet die Aufnahme der Anpassungen in den Projektron BCS Standard, da die Umsetzung innerhalb des Ticketsystems die Kunden der Projektron GmbH nicht in ihrer Projektarbeit beeinträchtigt. Diplomarbeit Robert Kalweit 69

86 6 Anpassungen 4. Es gibt seit längerem Überlegungen, die zuvor beschriebene Datenstruktur von Anmerkungen und Tickets zu überarbeiten und Tickets als eigenstän- digen Objekttyp zu etablieren. Dies begünstigt die zeitnahe Umsetzung des vorgestellten Konzepts. siehe Tickets selbst haben in Projektron BCS keinen Zeitbezug, wohl aber eine Zuordnung zu Objekten, die ein Start- und Enddatum haben. Dies kommt der Anwendung von user stories bei der Hypoport AG bereits sehr nahe: Die Bearbeitungsreihenfolge der user stories eines Sprints ergibt sich aus der Priorisierung und wird nicht vom Management vorgeschrieben. Ein Sprint ist im Gegensatz zu einer user story zeitlich fixiert. Auswirkungen Voraussetzung für das vorliegende Konzept ist, wie bereits erläutert, die Umwandlung der Tickets von Subtypen des Objekts Anmerkung in eigenständige Objekttypen. Weitere Anpassungen können daher nicht administrativ per Konfiguration erfolgen. 6.2 Umsetzung und Konfigurierbarkeit Es wird ein Subtyp des Projektron BCS-Objekts Aufgabe definiert. Dieser Sub- typ trägt den Namen Sprint. Wie bisher erfolgt damit die zeitliche Einteilung des Projekts. Die inhaltliche Einteilung wird durch Tickets vorgenommen. Im Folgenden wird auf diese Sprint-Aufgabe Bezug genommen. siehe 4.2 Definition eigener Strukturelemente siehe 4.3 Die Minimalkonfiguration von fünf Ticketarten in Listing 6.1 bildet die Grundlage für die folgenden Ausführungen. In Zeile 1 wird die Menge der Ticketarten beschrieben. Anschließend werden für jede Ticketart die Status definiert, sowie die Verwendung abstrakter Aufwände aktiviert oder verhindert. Die Definition verschiedener weiterer Attribute für die unterschiedlichen Ticketarten (z. B. Reproduzierbarkeit für Tickets der Art Bug ) ist ebenfalls möglich. 70 Diplomarbeit Robert Kalweit

87 6.2 Umsetzung und Konfigurierbarkeit Listing 6.1: Minimalkonfiguration von Ticketarten 1 JTicket.subtypes=Epic,Userstory,Akzeptanztest,ChangeRequest,Bug 2 3 JTicket.subtyp.Epic.states=Neu,Spezifiziert, Geschlossen 4 JTicket.subtyp.Epic. abstractefforts=true 5 6 JTicket.subtyp.Userstory.states=\ 7 Neu, Priorisiert, Umsetzung bestätigt,bearbeitung,umgesetzt,geschlossen 8 JTicket.subtyp.Userstory. abstractefforts =true 9 10 JTicket.subtyp.Akzeptanztest.states=Erstellt,Testen,Akzeptiert, Integrativ getestet 11 JTicket.subtyp.Akzeptanztest.abstractEfforts=false JTicket.subtyp.ChangeRequest.states=Neu,Gesichtet,Klärung,Absprache,Angeboten, 14 Aufgenommen,Eingeplant,Bearbeitung,Abnahme,Geschlossen 15 JTicket.subtyp.ChangeRequest.abstractEfforts=false JTicket.subtyp.Bug.states=Neu,Klärung,Aufgenommen,Bearbeitung,Abnahme,Geschlossen 18 JTicket.subtyp.Bug.abstractEfforts=false Um mit Tickets in Projektron BCS nicht nur Aufgaben zu verfeinern, sondern Strukturen abzubilden, ist es nun möglich, Eltern-Kind-Beziehungen zu definieren. In der Baumansicht des Strukturplans werden Tickets hierarchisch dargestellt. Diese Darstellung macht Abhängigkeiten zwischen den Tickets deutlich sichtbar und erleichtert die Navigation. In Abbildung 6.1 ist dem Sprint ein epic zugewiesen, das wiederum zwei user stories enthält. Einrückungen verdeutlichen 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 Strukturplan links: Anzeigenmodus, rechts: Bearbeitungsmodus Diplomarbeit Robert Kalweit 71

88 6 Anpassungen Sofern keine Einschränkungen vorgenommen werden, ist es möglich, jede definierte Ticketart als Kindelement jeder anderen Art anzuordnen. So kann in diesem Fall beispielsweise ein Akzeptanztest epics und user stories enthalten. Dies wird durch eine Konfiguration wie in Listing 6.2 verhindert. Es wird festgelegt, dass ein epic sämtliche anderen Ticketarten als Kindelemente haben kann, während einem Akzeptanztest keine Elemente untergeordnet werden können. User stories, ChangeRequests und Bugs können selbst Akzeptanztests enthalten. Listing 6.2: Einschränkung möglicher Kindelemente 1 JTicket.subtyp.Epic.possibleChildElements=Userstory,Akzeptanztest,ChangeRequest,Bug 2 JTicket.subtyp.Userstory.possibleChildElements=Akzeptanztest 3 JTicket.subtyp.Akzeptanztest.possibleChildElements= 4 JTicket.subtyp.ChangeRequest.possibleChildElements=Akzeptanztest 5 JTicket.subtyp.Bug.possibleChildElements=Akzeptanztest Abstrakte Aufwandsschätzungen Die Verwendung abstrakter Aufwandsschätzungen kann, wie in Listing 6.1 bereits beschrieben, über das Attribut abstractefforts aktiviert oder verhindert werden. Die Aktivierung wirkt sich sowohl auf den Anzeigen- als auch auf den Bearbeitungsmodus eines Tickets aus. Im Anzeigenmodus wird das Feld Abstrakter Aufwand, das den Aufwand des aktuellen Tickets selbst enthält, gezeigt. Direkt darunter befindet sich das Feld Abstrakter Aufwand (rekursiv), das die Summe der Aufwände sämtlicher untergeordneter Elemente enthält. Im Bearbeitungsmodus kann ausschließlich der Wert des ersten Feldes geändert werden. Das Feld Abstrakter Aufwand (rekursiv) wird im entsprechenden Formular nicht angezeigt. Abstrakte Aufwände werden im Strukturplan dargestellt. Im Anzeigenmodus wird dabei die Summe aller Aufwände untergeordneter Elemente und des entsprechenden Tickets dargestellt. Die Forumularfelder des Bearbeitungsmodus hingegen enthalten die Aufwände jedes Tickets. Abbildung 6.1 veranschaulicht dies: Epic02 hat selbst keinen abstrakten Aufwand. Im Anzeigenmodus wird ein Aufwand von 13 aufgeführt die Summe der beiden untergeordneten user stories. Da für Akzeptanztest die Verwendung abstrakter Aufwände deaktiviert ist, wird 72 Diplomarbeit Robert Kalweit

89 6.2 Umsetzung und Konfigurierbarkeit im Bearbeitungsmodus in der Zeile des Akzeptanztests kein Formularfeld angezeigt. Umwandlungen zwischen Strukturelementen Die Umwandlung zwischen Tickets ist abhängig von den möglichen Kindelementen. Dabei wird geprüft, welche Kindelemente ein Ticket gegenwärtig enthält und welchen Typ das aktuelle Elternelement hat. Für die Umwandlung gelten zwei 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 Handhabung von Strukturelementen und den zur Fehlervermeidung notwendigen Einschränkungen zu verstehen. Abbildung 6.2 zeigt mögliche Umwandlungen einer user story. Die betreffende user story ist gegenwärtig kein Kindelement eines epics. In diesem Fall wäre die Umwandlung in ein solches nicht mehr möglich, da epics selbst keine epics enthalten dürfen. Im Umkehrschluss kann ein epic, das bereits durch user stories als Kindelemente spezifiziert ist, nicht mehr in eine user story konvertiert werden. Abbildung 6.2: Umwandlung von Tickets links: Anzeigenmodus, rechts: Bearbeitungsmodus Ein Ticket, das direkt der Sprint-Aufgabe untergeordnet ist und selbst noch keine Kindelemente hat, ist bezüglich der Umwandlung keinen Restriktionen unterworfen. Die Verwendung abstrakter Aufwandsschätzungen beeinflusst mögliche Umwandlungen nicht. Es wird davon ausgegangen, dass ein Ticket, das bereits geschätzt wurde, nicht mehr in eine Ticketart umgewandelt werden muss, bei der abstrakte Diplomarbeit Robert Kalweit 73

90 6 Anpassungen Aufwände deaktiviert sind. Ausgeschlossen wird diese Möglichkeit jedoch nicht. Im Falle einer solchen Umwandlung wird eine Warnung gezeigt. Die Schätzung ist anschließend nur aus der Historie, dem Änderungsprotokoll, des Tickets ersichtlich. Definition diverser Lebenszyklen für Strukturelemente Die Definition von Lebenszyklen erfolgt per XML-Datei. Da user stories und Akzeptanztests pro Status nur maximal zwei Übergänge haben, bezieht sich das fol- 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. siehe Abb. 5.4 Abbildung 6.3: Lebenszyklus eines Bugs als Zustandsdiagramm nach [oose 2008] Listing 6.3: Definition des Lebenszyklus eines Bugs 1 <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> 74 Diplomarbeit Robert Kalweit

91 6.2 Umsetzung und Konfigurierbarkeit 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 Lebenszyklus konfiguriert und angepasst werden kann. Diese Attribute sind in Tabelle 6.1 gegenüber gestellt. Attribut Definition Funktion Name verbindlich Bestimmt den Ziel-Status Icon optional Name einer Bilddatei, die dem Statusübergang vorangestellt wird ShowWorkflow optional Bestimmt, ob der Übergang unter Arbeitsabläufe dargestellt wird Transition optional Verändert den Text, mit dem der Übergang unter Arbeitsabläufe verlinkt ist Tabelle 6.1: Attribute eines ChangeState-Elements Abbildung 6.4 zeigt die durch die zuvor dargelegte Konfiguration eines Bugs definierten Statusübergänge (links). Der Fehler hat den Status Aufgenommen und kann durch Klick auf die direkt verlinkten Icons und Texte in die Status Bearbeitung, Abnahme und Geschlossen übergehen. Die Übergänge zum Status Klärung werden im Anzeigenmodus nicht aufgeführt, da das Attribut ShowWorkflow den Wert false hat (Listing 6.3, Zeile 14 ). Dieser Status kann weiterhin im Bearbeitungsmodus gesetzt werden. In diesem Modus werden wie bisher Status, zu denen der Übergang möglich ist, in einer Dropdown-Liste angezeigt. Diplomarbeit Robert Kalweit 75

92 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 angepasst, daher stehen sämtliche Statusübergänge in der Benutzeroberfläche Arbeitsabläufe genannt zur Verfügung (Abbildung 6.4, rechts). Auf diese Weise wird die Definition unterschiedlicher Lebenszyklen für verschiedene Ticketarten gewährleistet. Darüber hinaus ist es möglich, für verschiedene Tickets gleichnamige Status zu verwenden, deren Übergänge jedoch anders zu benennen. So kann trotz diverser Arbeitsabläufe nach bestimmten Status über alle Tickets gesucht, gefiltert und sortiert werden. Dies ist ebenfalls für die Umwandlung zwischen Ticketarten mit unterschiedlichen Lebenszyklen relevant. Sofern der gegenwärtige Status für die Ziel-Ticketart definiert ist, wird dieser beibehalten. Ist dies nicht der Fall, wird der erste Status der Ziel-Ticketart gesetzt und eine entsprechende Warnung ausgegeben (Abbildung 6.5). Abbildung 6.5: Erfolgsmeldung und Warnung nach Umwandlung Die geforderten Qualitätsanforderungen werden durch intuitiv verständliche Be- zeichnungen erfüllt. Die Konfiguration ist leicht änderbar und erwartungskonform: Werden für verschiedene Ticketarten die gleichen Status definiert, kann der Lebenszyklus 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 siehe Diplomarbeit Robert Kalweit

93 6.2 Umsetzung und Konfigurierbarkeit eine andere Ticketart übernommen werden. Anschließend muss der Name der anderen 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 eingegeben werden. Die geplante Entwicklungsgeschwindigkeit ist die Grundlage des idealen Burndown Graphen im gleichnamigen Diagramm. Die Summe aller abstrakten Aufwände innerhalb eines Sprints, also der Tickets unterhalb der Sprint- Aufgabe, soll gleich der geplanten velocity sein. Diese Summe wird zwar im Anzeigenmodus der Sprint-Aufgabe dargestellt, aber nicht automatisch als geplante velocity übernommen, da Änderungen der Schätzungen im Projektverlauf sonst das Diagramm verfälschen. Nach Abschluss eines Sprints wird die Summe der Aufwände sämtlicher als abgeschlossen geltender Tickets erfasst. Diese Zahl wird anschließend als Entwicklungsgeschwindigkeit (nach Abschluss) gespeichert. Dies geschieht automatisch um 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 Tag des Sprints bis zum aktuellen Datum wird im Burndown Chart als Säule dargestellt. Mit der geplanten velocity, den abstrakten Aufwänden und der zeitlichen Begrenzung der Sprint-Aufgabe (Start- und Enddatum) liegen nun sämtliche zur Darstellung eines Burndown Charts erforderlichen Daten vor. Wie per Konfiguration die Status der Tickets, deren Aufwände im Burndown Chart abgebildet werden, verändert werden können, ist in Listing 6.4 aufgezeigt. Listing 6.4: Berücksichtigung von Status im Burndown Chart 1 JTicket.subtyp.Userstory.burndownTodo=Neu,Priorisiert,Umsetzung bestätigt,bearbeitung 2 JTicket.subtyp.Userstory.burndownReady=Umgesetzt,Geschlossen Diplomarbeit Robert Kalweit 77

94 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 Menge aller Status, erfolgt die Darstellung des Burndown Charts mit zwei Säulen: Pro Datum je eine für die Aufwände fertiger und eine für die Aufwände unfertiger Tickets. Dies ist in Abbildung 6.6 dargestellt. Abbildung 6.6: Burndown Chart in Projektron BCS siehe 5.3 Beide Säulen sind zusammen nicht so hoch, wie die Säule abstrakter Aufwände am ersten Tag des Sprints. Diese Differenz entspricht den Aufwänden der Tickets, deren gegenwärtiger Status weder als fertig, noch als unfertig definiert wurde. Im Sinne der Transparenz des Sprintfortschritts sollte die Konfiguration jedoch derart vorgenommen werden, dass jeder Status entweder fertig oder unfertig ist. Eine Festlegung erfolgt hier nicht. Dies gewährt der Zielgruppe weitgehende Freiheit in der Anpassung an den eigenen Prozess. 6.3 Integration Da die beschriebenen Anpassungen größtenteils innerhalb des Ticketsystems vorgenommen werden, beeinträchtigt ihre Integration die weiteren Bereiche von Projektron BCS nicht. 78 Diplomarbeit Robert Kalweit

95 6.3 Integration Abbildung 6.7 zeigt das Anpassen-Menu des Strukturplans. Hier kann die Anzeige von Tickets ermöglicht oder verhindert werden. Für Sprint-Aufgaben ist diese 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 sich dieses Element befindet (vgl. Abbildung D.5). Als wichtige Orientierungshilfe ist diese Hierarchie auf den jeweiligen Seiten ganz oben angeordnet. Um auch bei den vorgestellten Anpassungen die Aufmerksamkeit des Benutzers sofort auf siehe 5.3 die wichtigsten Elemente zu lenken, werden Arbeitsabläufe und untergeordnete Elemente direkt unter dem Betreff eines Tickets aufgeführt. Abbildung 6.8 zeigt darüber hinaus, wie effizient an einem Ticket ein Kindelement erstellt werden kann: Direkt unter der Liste der Kindelemente befindet sich ein Link Ticket hinzufügen. Dieser öffnet die Seite zum Eintragen eines neuen Tickets, das automatisch 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 deren Start- und Enddaten festzulegen, gegeben. Um Anforderungen in einem Product Backlog zusammen zu stellen, wird ein gleichnamiges Unterprojekt angelegt. An diesem werden Tickets verwaltet, die noch keinem Sprint zugeordnet sind. Entschließt sich das Team in der Sprint-Planungssitzung zur Umsetzung von Anfor- Diplomarbeit Robert Kalweit 79

96 6 Anpassungen derungen aus dem Product Backlog, werden die entsprechenden Tickets aus dem Unterprojekt in die jeweilige Sprint-Aufgabe verschoben. Dieses Vorgehen ist sowohl konform zu Scrum als auch zur gegenwärtigen Teamplanung. Letzteres zeigt Abbildung 6.9. Die Leiter des Scrum Projekts werden dem Projekt, der Sprint-Aufgabe und dem Product Backlog zugeordnet. Sie können so Sprint-Aufgaben planen, Anforderungen im Product Backlog erfassen und diese, sofern inhaltlich möglich, bereits priorisieren und verfeinern. Bei der Hypoport AG übernehmen mehrere Projektmanager diese Aufgabe. Sie alle müssen dem Unterprojekt zugewiesen werden. Dem Sprint selbst wird anschließend das Team zugeordnet. Teammitglieder können dann innerhalb des Sprints Tickets bearbeiten, umwandeln und zuweisen. Abbildung 6.9: Kompatibilität zur gegenwärtigen Teamplanung Da auf Tickets Arbeitszeiten gebucht werden können, bleibt die Zeiterfassung gewährleistet. Buchungen innerhalb eines Sprints (der Aufgabe) können nach Tickets sortiert werden. Ein Filter nach Ticketarten ermöglicht hier, zwischen Test- und Entwicklungsaufgaben zu unterscheiden. Da bei der Hypoport AG auch die für Projektmanagement, also unter anderem für die Meetings im Scrum Prozess aufgebrachte Zeit erfasst wird, kann die Erstellung einer entsprechenden Aufgabe nicht umgangen werden. Der Aufwandsplan wird nicht beeinflusst. Wie Abbildung 6.10 veranschaulicht, steht die Planung der zeitlichen Aufwände sämtlicher Teammitglieder nicht im Widerspruch zu den vorgestellten Anpassungen. Der Unterschied besteht in der Planung der Aufwände für einen gesamten Sprint eine detailliertere Planung ist im Scrum Prozess nicht vorgesehen. 80 Diplomarbeit Robert Kalweit

97 6.3 Integration Abbildung 6.10: Aufwandsplanung auf Sprintebene Das vorgestellte Konzept ermöglicht es, Scrum Projekte in Projektron BCS abzubilden und den zu Grunde liegenden Prozess zu verfolgen. Darüber hinaus ist es denkbar, nur einen Teil eines Projekts mit Scrum durchzuführen. Das Scrum- Unterprojekt gliedert sich in diesem Fall nahtlos in die Struktur des Gesamtprojekts ein. Diplomarbeit Robert Kalweit 81

98 6 Anpassungen 82 Diplomarbeit Robert Kalweit

99 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 Interaktion höher bewertet als Prozesse und Werkzeuge, mit einem solchen Werkzeug abzubilden. Da Agilität jedoch in erster Linie Beweglichkeit bedeutet und diese wiederum Freiheit verlangt, hat sich die Zielstellung im Laufe der Erstellung dieser Diplomarbeit ein wenig gewandelt: Genau einen agilen Prozess abzubilden wäre wenig sinnvoll, da dieser eben auf Grund seiner Agilität einem ständigen Wandel unterworfen ist. Stattdessen galt es, die Freiräume zu schaffen, in denen sich ein solcher Prozess bewegen und entwickeln kann. Die Freiheiten und die Flexibilität, die das vorgestellte Konzept ermöglicht, wurden eingehend dargelegt. Die aufgezeigten Konfigurationsmöglichkeiten über die Benutzeroberfläche vorzunehmen würde den Komfort, mit dem besagte Freiräume in Zukunft ausgeschöpft werden können, noch verbessern. Die vorliegende Arbeit hat aufgezeigt, welche Bereiche von Projektron BCS verbessert werden müssen, um agile Vorgehensweisen abbilden zu können. Ob die dargelegten Anpassungen geeignet sind, innerhalb eines agilen Prozesses auf weitere Softwaretools zum Projektmanagement zu verzichten, wird erst der praktische Einsatz zeigen. Das vorgestellte Konzept wurde von den Verantwortlichen der Projektron GmbH als überaus nützlich bewertet und hat bereits erste Interessenten überzeugt. Kriterium für den Erfolg der Anpassungen in der Praxis ist aber, nach Ansicht des Verfassers, auch die Einstellung der jeweiligen Entscheidungsträger dem Entwick- Diplomarbeit Robert Kalweit 83

100 7 Fazit und kritische Bewertung lungsprozess gegenüber. Diesen Prozess derart detailliert abzubilden, dass Projektron BCS als technische Schnittstelle die Notwendigkeit soziologischer Schnittstellen in Form persönlicher Kontakte minimiert, ist nicht Ziel dieser Arbeit und widerspricht den agilen Werten. Bei der Erstellung der vorliegenden Arbeit wurde größte Sorgfalt auf Verständlichkeit gelegt. Trotz Kritik seitens einiger Lektoren wurde an den Bezeichnungen, die in der Scrum-Fachliteratur verwendet werden, festgehalten. Unberechtigt ist diese Kritik dennoch nicht: Beispielsweise könnten Begriffe wie Product Backlog und Sprint Backlog durch Anforderungsliste und Aufgabenliste ersetzt werden. Eventuell rührt die weite Verbreitung von Scrum aber auch von der Verwendung neuer, unverbrauchter Begriffe. Bleibt also abzuwarten, welche weiteren neuen Bezeichnungen für altbekannte Elemente die Entwicklung agiler Vorgehensweisen hervorbringt. 84 Diplomarbeit Robert Kalweit

101 Anhang Diplomarbeit Robert Kalweit i

102 ii Diplomarbeit Robert Kalweit

103 A Technische Details A.1 Datenstruktur von Projektron BCS Organisationen dienen der Abbildung des eigenen und bekannter Unternehmen. Personen und Ressourcen werden Subtypen dieses Objekts zugeordnet. Interne und externe Unternehmen und deren Abteilungen werden dabei dem entsprechenden Arbeitsbereich zugeordnet. Objekt- und Subtyp Objektname Beschreibung Organisation JOU Externe Abteilung extsub Externe Organisation ext Zulieferer, Kunden, Investoren, Behörden etc. Interne Abteilung intsub Interne Organisation int das eigene Unternehmen, Tochtergesellschaften etc. Organisationsgruppe intgroup bspw. der eigene Konzern mit mehreren internen Organisationen Organisationsgruppe group gruppiert externe Organisationen (z. B. in Zulieferer, Kunden etc.) Tabelle A.1: Subtypen des Objekts Organisation Diplomarbeit Robert Kalweit iii

104 A Technische Details Personen ermöglichen durch die Verwaltung ihrer Kontaktdaten, Verfügbarkeiten, Arbeitszeitmodelle etc. das Personal- und Kontaktmanagement. Die Subtypen des Objekts Person werden entweder internen oder externen Organisationen zugeordnet. Objekt- und Subtyp Objektname Beschreibung Person JUser Freier Mitarbeiter contractor ein Mitarbeiter, der selbstständig im Dienst des eigenen Unternehmens steht Login login ein Zugang zum eigenen Projektron BCS System, der keinem Menschen direkt zugeordnet ist Mitarbeiter (ehemalig) formeremployee aus einer externen Organisation ausgeschiedener Kontakt Mitarbeiter employee Mitarbeiter einer externen Organisation Person (ehemalig) formerperson aus dem eigenen Unternehmen ausgeschiedener Kontakt Person person Mitarbeiter des eigenen Unternehmens Ressource resource eine interne Ressource die verplant werden kann (Räume, Beamer, Autos, Maschinen etc.) Selbständige Person ouperson eine externe Person, die keinem Unternehmen zugeordnet ist Tabelle A.2: Subtypen des Objekts Person iv Diplomarbeit Robert Kalweit

105 A.1 Datenstruktur von Projektron BCS Projekte sind der Mittelpunkt der Aufmerksamkeit von Projektron BCS. Die Projektplanung auf oberster Hierarchieebene erfolgt mit Subtypen dieses Objekts. Auf dieser Ebene sind zahlreiche Auswertungen möglich. Objekt- und Subtyp Objektname Beschreibung Projekt JProject Arbeitspaket workpackage strukturiert ein Projekt oder Unterprojekt 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- und Enddatum. Objekt- und Subtyp Objektname Beschreibung Aufgabe JTask Allgemeines miscellaneous nicht auf konkrete Aufgaben verbuchte Zeiten werden einer allgemeinen Aufgabe zugeschrieben Aufgabe task eine Aufgabe im Projekt Daueraufgabe everlasting eine zeitlich nicht begrenzte Aufgabe Krankheit sickness Meilenstein milestone ein Meilenstein terminiert auf genau einen Tag Urlaub vacation Tabelle A.4: Subtypen des Objekts Aufgabe Diplomarbeit Robert Kalweit v

106 A Technische Details Anmerkungen erfüllen vielfältige Zwecke. Subtypen dieses Objekts protokollieren die Kommunikation mit Kontakten und verwalten zusätzliche Daten an verschiedenen anderen Objekten. Objekt- und Subtyp Objektname Beschreibung Anmerkung JAnnotation Anruf (abgehend) PhoneOut Protokoll eines abgehenden Telefonats Anwesenheit/Pause AttendanceList speichert Arbeits- und Pausenzeiten Kommentar Comment Prozess-Workflow ProcessWorkflow ermöglicht die Definition mehrerer Schritte zur Bearbeitung einer Aufgabe Rundschreiben / 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 Projektauftrags eingeplant bzw. aufgewandt werden. Objekt- und Subtyp Objektname Beschreibung Aufwand JEffort Buchung Personal Personalkosten als Produkt der aufgewandten Arbeitszeit und des Stundensatzes eines Mitarbeiters Plan Forecast im Aufwandsplan eines Projekts veranschlagte Arbeitszeit Sachkosten Fixed Kosten von Arbeitsmaterial und Dienstleistungen dritter Unternehmen Tabelle A.6: Subtypen des Objekts Aufwand vi Diplomarbeit Robert Kalweit

107 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übergä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 sind entsprechend gekennzeichnet. Listing A.1: Konfiguration des Lebenszyklus der Projektron Support Tickets 1 <?xml version="1.0" encoding="iso "?> 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

108 A Technische Details 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> </BCS Configuration> viii Diplomarbeit Robert Kalweit

109 B Interviews mit Mitarbeitern der Hypoport AG B.1 Zusammenfassung des Gesprächs mit Herrn Heide Im Folgenden sind die Gesprächsnotizen aus dem Interview mit Herrn Sebastian Heide, ScrumMaster bei der Hypoport AG, zusammengefasst (normaler Text). Diese wurden Herrn Heide per übermittelt und um Kommentare bzw. Korrekturen ergänzt (kursiver Text). Das Gespräch fand am statt. Product Owner: je 1 Projektleiter fungiert als PO für einen Kunden und stellt das jeweilige Product Backlog zusammen Ganz so ist es nicht, da wir ja pro Produkt oft mehrere Kunden haben. Für jedes Produkt gibt es ein Backlog, das jedoch von mehreren Projektmanagern gepflegt wird, 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 Entwicklerteams nicht ausreichen. Es wird demnach wahrscheinlich bald eine Vollzeitstelle plus weitere Ressourcen geben. daher betreut 1 ScrumMaster mehrere Projekte/Teams Kommt es vor, dass diese Projekte oder ihre Teams konkurrieren und der (für beide zuständige) ScrumMaster so evtl. bei der Beseitigung von impediments in Entscheidungskonflikte gerät? Ja Diplomarbeit Robert Kalweit ix

110 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 Wissensaustausch ohne 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 letztendlich eine priorisierte Liste der User Stories dar. komplette Repräsentation sowohl in JIRA als auch dreifach in BCS (je eine Entwicklungs-, Test- und PM-Aufgabe) Während Jira echte Product Backlogs - gemäß Scrum - enthält (also produktbezogen), 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 ausreicht egal ist, wie die Tasks geplant sind Sprint Backlog Items (Aufgaben) werden den Mitarbeitern eines Teams dann trotzdem vom PL Top-Down zugewiesen (in JIRA für den Workflow, in BCS lediglich 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 Bearbeitungsreihenfolge ihm soweit nicht anders abgesprochen/vorgeschrieben freisteht Dementsprechend hat jedes Team ein Sprint-Backlog. Die Bearbeitungsreihenfolge ist implizit durch die Priorisierung der Themen bereits gegeben. Das Team kann jedoch - sofern es für die Bearbeitung sinnvoller ist - auch einzelne Thmen in der Bearbeitung vorziehen. Product Increment: feste, produktabhängige Releasezyklen (Hauptprodukt EUROPACE: 1 Release = 3 Sprints) Normalerweise Ja, doch: Je nach Sachlage können Releasezyklen auch verlänx Diplomarbeit Robert Kalweit

111 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 (Product Owner) festgelegten Priorität, die UserStories aus, die umgesetzt werden Sprint Retrospective Meeting: zur internen Verbesserung der Prozesse, nach anfänglichen Schwierigkeiten vor 1,5 Jahren ( Jeder sagt nur, was ihn nervt. ) mittlerweile tatsächlich produktive Vorschläge und deren Umsetzung Sprint Review Meeting: hatten wir nicht erwähnt: Vermutlich aber ebenfalls konform zum Scrum Prozess - das Team präsentiert dem Projektleiter (eventuell auch anwesenden Kunden als Stakeholdern) fertige und getestete Funktionalität Korrekt Daily Scrum: hatte ich leider auch nicht erwähnt: Daher vermute ich, es findet tatsächlich wie vorgesehen täglich und im entsprechenden Rahmen statt (pro Team also ca. 15 Minuten, da ein ScrumMaster ja mehrere Teams hat, hat dieser also auch mehrere Daily Scrums täglich?) Richtig: Im Schlimmsten Fall (Urlaub des anderen ScrumMasters) hat ein ScrumMaster bis zu 7 Daily Scrum Meetings am Morgen. Wenn ich mir JIRA so anschaue und ich Sie richtig verstanden habe, dann erfolgt 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 dem Projektron Repertoire nutzen Sie oder die jeweiligen Projektleiter? Schritte des Projekt-Assistenten: Stamm (obligatorisch), Kostenrechnung, Vorlagen, Strukturplan, Zeitplanung, Teamplanung, Aufwandsplan, Ressourcenauslastung, Auftragsplan, Dateiablage Durchführung: Prozess-Workflows, Checklisten, Wiedervorlagen Auswertungen: Gesamtkosten/Projekt, Gesamtkostendiagramm, Aufwände/Projekt, Aufwände/Projekt intern, Aufwandsliste/Aufgabe, Aufwände/Mitarbeiter, Diplomarbeit Robert Kalweit xi

112 B Interviews mit Mitarbeitern der Hypoport AG Aufwandsliste/Mitarbeiter, Aufwandsdiagramm, Personalkosten/Projekt, Personalkosten/Mitarbeiter, Personalkostendiagramm, Personalkostenliste/Aufgabe, Sachkosten/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 bereits Versuche, die Prozesse, die momentan in JIRA abgebildet und gelebt werden, auf Projektron BCS zu übertragen? Wenn ja, woran lag es, dass diese Übertragung gescheitert ist? Bei der Einführung von BCS wurde dies Option kurz überprüft, jedoch schnell verworfen. 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, Projektmanager bei der Hypoport AG, besprochen. Das Gespräch fand am statt. 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 mit mehreren unterschiedlichen lifecycles enthalten Bsp. user story: priorisiert Umsetzung bestätigt in Umsetzung umgesetzt Bsp. Akteptanztest: erstellt/angelegt zu testen getestet integrativ getestet xii Diplomarbeit Robert Kalweit

113 B.2 Zusammenfassung des Gesprächs mit Herrn Gimbel Einblick in JIRA: Bessere Nutzbarkeit durch geringere Klick-Häufigkeit beim Ausfü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 übergeordneter Stelle aus oder wird das ganze Team allen Aufgaben zugewiesen, und organisiert sich dann selbst? (In JIRA/in Projektron) Aufgabenverteilung an das Team als ganzes - wer was umsetzt ist mir letztendlich egal. Welche der folgenden Funktionen aus dem Projektron Repertoire nutzen Sie? Auswertungen: Gesamtkosten/Projekt, Gesamtkostendiagramm, Aufwände/Projekt, Aufwände/Projekt intern, Aufwandsliste/Aufgabe, Aufwände/Mitarbeiter, Aufwandsliste/Mitarbeiter, Aufwandsdiagramm, Personalkosten/Projekt, Personalkosten/Mitarbeiter, Personalkostendiagramm, Personalkostenliste/Aufgabe, Sachkosten/Projekt, Sachkostendiagramm, Historie, Berichtserstellung, Berichte Ich nutze nur Auswertung Aufwände pro Projekt. Auf Nachfrage am hat sich gezeigt, dass die Lebenszyklen verschiedener Tickettypen angepasst wurden. Abbildung B.1 veranschaulicht die Status von vier Tickettypen (epics und user stories werden gleich behandelt). Zusätzlich enthält das Diagramm Akteure, die für die Tickettypen verantwortlich sind. Darüber hinaus ist integrativ getestet kein Status eines Akzeptanztests, sondern bedeutet, dass eine user story auf einem Integrationssystem erfolgreich getestet wurde und veröffentlicht werden kann (Release). Diplomarbeit Robert Kalweit xiii

114 B Interviews mit Mitarbeitern der Hypoport AG Abbildung B.1: JIRA Tickettypen und -status xiv Diplomarbeit Robert Kalweit

115 C Diagramme Diplomarbeit Robert Kalweit xv

116 C Diagramme Abbildung C.1: Aktivitätsdiagramm des Scrum Prozesses, Quelle: [Eclipse] xvi Diplomarbeit Robert Kalweit

117 Abbildung C.2: Detailliertes Aktivitätsdiagramm des Scrum Prozesses Diplomarbeit Robert Kalweit xvii

118 C Diagramme Abbildung C.3: Aktivitätsdiagramm des Scrum Prozesses der Hypoport AG xviii Diplomarbeit Robert Kalweit

119 D Konzeptgraphiken Diplomarbeit Robert Kalweit xix

120 D Konzeptgraphiken Abbildung D.1: Strukturplan eines Scrum Projekts im Anzeigenmodus xx Diplomarbeit Robert Kalweit

121 Abbildung D.2: Strukturplan eines Scrum Projekts im Bearbeitungsmodus Diplomarbeit Robert Kalweit xxi

122 D Konzeptgraphiken Abbildung D.3: Mittels Lebenszyklus eingeschränkte Arbeitsabläufe eines Bugs xxii Diplomarbeit Robert Kalweit

123 Abbildung D.4: Uneingeschränkte Arbeitsabläufe eines ChangeRequests Diplomarbeit Robert Kalweit xxiii

124 D Konzeptgraphiken Abbildung D.5: Ticketansicht mit abstrakten Aufwänden (und Aufwänden untergeordneter Tickets), Arbeitsabläufen und Beziehungen (Untergeordnet, Duplikat, Verwandt, Vorgänger, Nachfolger) xxiv Diplomarbeit Robert Kalweit

125 Abbildung D.6: Integration des Burndown Charts in die auf Aufgabenebene verfügbaren Auswertungen Diplomarbeit Robert Kalweit xxv

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

Einführung in SCRUM. Helge Baier 21.01.2010

Einführung in SCRUM. Helge Baier 21.01.2010 Einführung in SCRUM Helge Baier 21.01.2010 Helge Baier Master of Computer Science (Software Engineering) über 10 Jahre Erfahrung in der Software Entwicklung Zertifizierung zum Scrum Master (2009) praktische

Mehr

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de SCRUM Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter Dirk.Prueter@gmx.de Überblick Was ist SCRUM Wie funktioniert SCRUM Warum lohnt es sich, SCRUM anzuwenden

Mehr

Scrum E I N F Ü H R U N G

Scrum E I N F Ü H R U N G Scrum EINFÜHRUNG Was ist Scrum? Agiles Vorgehensmodell Grundüberzeugungen Erste Tendenzen Mitte der 80er Jahre Grundidee: Entwickeln in Inkrementen Parallelen zur Lean Production Agiles Manifest Jeff Sutherland

Mehr

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl SCRUM Scrum in der Software Entwicklung von Ernst Fastl Agenda 1. Die Entstehung von Scrum 2. Überblick über den Prozess 3. Rollen 4. Meetings 5. Artefakte 6. Fragen & Antworten Agenda 1. Die Entstehung

Mehr

Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare

Praktische Erfahrungen beim Einsatz des Vorgehensmodells SCRUM bei AGFA HealthCare Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare SCRUM Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" eines Entwicklerteams von AGFA HealthCare 2 Praktische

Mehr

Wahlpflichtmodul Projekt I Softwareprojekt I

Wahlpflichtmodul Projekt I Softwareprojekt I Wahlpflichtmodul Projekt I Softwareprojekt I Dipl. Inf. Andrea Meyer SCRUM in Detail Dipl. Inf. Andrea Meyer WIEDERHOLUNG 4 Prinzipien von SCRUM Zerlegung Transparenz Anpassung Überprüfung WIEDERHOLUNG

Mehr

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch -

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch - Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch - Prof. Dr. Roland Petrasch, Beuth Hochschule für Technik prof.beuth-hochschule.de/petrasch Stefan Lützkendorf Projektron GmbH

Mehr

Scrum. Eine Einführung

Scrum. Eine Einführung Scrum Eine Einführung Scrum-Charakteristika einfache Regeln wenige Rollen Pragmatismus statt Dogmatik iteratives Vorgehen Scrum auf einer Seite erklärt 3 Rollen für direkt am Prozeß beteiligte 1) Product

Mehr

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012 Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel Verglühte die Raumfähre Columbia durch einen unflexiblen Projektmanagementprozess? Rückblick: 2003 verglühte

Mehr

Agile Softwareentwicklung mit Scrum

Agile Softwareentwicklung mit Scrum Agile Softwareentwicklung mit Scrum Einführung und Überblick zum agilen Softwareentwicklungsprozess Scrum März 2006 Robert Schmelzer, DI(FH) E-Mail: robert@schmelzer.cc Web: http://www.schmelzer.cc Einführung

Mehr

Compact Scrum Guide. Agile Coach / Business Consultant @ Prowareness Contact: o.mann@prowareness.de, 0176-52845680

Compact Scrum Guide. Agile Coach / Business Consultant @ Prowareness Contact: o.mann@prowareness.de, 0176-52845680 Compact Scrum Guide Author: Oliver Mann, Role: Agile Coach / Business Consultant @ Prowareness Contact: o.mann@prowareness.de, 0176-52845680 Compact Scrum Guide Inhalt 1. Was ist Scrum und wofür wird es

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Der Business Analyst in der Rolle des agilen Product Owners

Der Business Analyst in der Rolle des agilen Product Owners Der Business Analyst in der Rolle des agilen Owners HOOD GmbH Susanne Mühlbauer Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Inhalte Agile Software

Mehr

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen Scrum technische Umsetzung und kaufmännische 9. Darmstädter Informationsrechtstag 2013 Darmstadt, 15. November 2013 Franziska Bierer 2 andrena ojects ag Gründung 1995 Standorte in Karlsruhe und Frankfurt

Mehr

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-42660-3. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-42660-3. Weitere Informationen oder Bestellungen unter Ralf Wirdemann Scrum mit User Stories ISBN: 978-3-446-42660-3 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42660-3 sowie im Buchhandel. Carl Hanser Verlag, München 1 Einführung.....................................

Mehr

Agile Entwicklung nach Scrum

Agile Entwicklung nach Scrum comsolit AG Hauptstrasse 78 CH-8280 Kreuzlingen Tel. +41 71 222 17 06 Fax +41 71 222 17 80 info@comsolit.com www.comsolit.com Agile Entwicklung nach Scrum Seite 1 / 6 Scrum V 1.0 1. Wieso Scrum Die Entwicklung

Mehr

Scrum mit User Stories

Scrum mit User Stories Ralf Wirdemann Scrum mit User Stories HANSER Inhaltsverzeichnis 1 Einführung 1 1.1 Warum dieses Buch? 2 1.2 Struktur und Aufbau 3 1.3 Dankeschön 5 1.4 Feedback 5 2 Beispiel: Scrumcoaches.com 7 2.1 Das

Mehr

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer Agiles Projektmanagement erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011 Thomas Hemmer Chief Technology Officer thomas.hemmer@conplement.de conplement AG, Nürnberg 2 conplement

Mehr

Scrum. Max Jäger. Frankfurt, den 07. Juli 2012

Scrum. Max Jäger. Frankfurt, den 07. Juli 2012 Max Jäger Frankfurt, den 07. Juli 2012 I Inhalt Inhalt Abkürzungen Abbildungen III IV 1 Scrum 1 1.1 Einführung............................. 1 1.2 Überblick über Scrum....................... 1 1.3 Rollen................................

Mehr

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-41656-7. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-41656-7. Weitere Informationen oder Bestellungen unter Ralf Wirdemann Scrum mit User Stories ISBN: 978-3-446-41656-7 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41656-7 sowie im Buchhandel. Carl Hanser Verlag, München 1 Einführung.....................................

Mehr

SCRUM. Software Development Process

SCRUM. Software Development Process SCRUM Software Development Process WPW 07.08.2012 SCRUM Poster www.scrum-poster.de Was ist Scrum? Extrem Schlanker Prozess 3 Rollen 4 Artefakte Wenige Regeln Die Rollen Product Owner Der Product Owner

Mehr

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen Bernhard Fischer Fischer Consulting GmbH MedConf 2009 Folie 1 Wie soll Software entwickelt werden? MedConf 2009 Folie

Mehr

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft.

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft. Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle Folie 2 Agenda Projektmanagement: Ziele und Methoden Agile Methoden: Scrum Agile Methoden im BI Umfeld PM

Mehr

Agiles Projektmanagement mit Scrum. Name: Eric Dreyer

Agiles Projektmanagement mit Scrum. Name: Eric Dreyer Definition 2 Was ist Scrum? Scrum ist ein schlanker, agiler Prozess für Projektmanagement u. a. in der Softwareentwicklung. Woraus besteht Scrum? Einfache Regeln Wenige Rollen Mehrere Meetings Einige Artefakte

Mehr

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski 1. Was heißt Agil 2. Scrum? Grundbegriffe 3. Wer benutzt Scrum 4. Vorteile & Nachteile von

Mehr

Projektmanagement durch Scrum-Proxies

Projektmanagement durch Scrum-Proxies Cologne Intelligence GmbH Projektmanagement durch Scrum-Proxies Integration von Vorgehensmodellen und Projektmanagement 17. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik e.v. Stuttgart,

Mehr

Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen

Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen Wer bin ich Kurse und Vorträge mit Jeff Sutherland und Ken Schwaber Verschiedene Kurse der Scrum.org Professional

Mehr

Agilität: Scrum. Eine Kurzübersicht zum schnellen Einstieg. AG Scrum Kurzübersicht

Agilität: Scrum. Eine Kurzübersicht zum schnellen Einstieg. AG Scrum Kurzübersicht Agilität: Scrum Eine zum schnellen Einstieg Sie finden diese und weitere Präsentationen unter (-> Klick): http://www.peterjohannconsulting.de/index.php?menuid=downloads Für (agile) Entwickler und (traditionelle)

Mehr

Train. Scrum Kompakt. Angelika Drach, Christoph Mathis

Train. Scrum Kompakt. Angelika Drach, Christoph Mathis Train Scrum Kompakt Angelika Drach, Christoph Mathis !! Inhalt! Inhalt' Inhalt!!1! 1! Agile!Grundlagen!..!3! 1.1! Das!Agile!Manifest!..!3! 1.2! Softwareentwicklung!ist!empirisch!.!4! 2! ScrumGKonzepte!!6!

Mehr

Scrum undprojektmanagement à la GPM. Markus Schramm compeople AG Frankfurt

Scrum undprojektmanagement à la GPM. Markus Schramm compeople AG Frankfurt Scrum undprojektmanagement à la GPM Markus Schramm compeople AG Frankfurt GPM scrum ed GPM, Scrum, warum? Projektablauf koordinieren Einheitliches Vorgehen Gemeinsames Verständnis Gemeinsame Sprache Freestyle

Mehr

Extreme Programming: Überblick

Extreme Programming: Überblick Extreme Programming: Überblick Stefan Diener / Apr 18, 2007 / Page 1 Prinzipien Rollen Planung Implementierung Praktiken weitere Vorgehensweisen Grenzen Inhalt Stefan Diener / Apr 18, 2007 / Page 2 Prinzipien

Mehr

ralf WIRDEMANN SCRUM MIT USER STORIES 2. Auflage

ralf WIRDEMANN SCRUM MIT USER STORIES 2. Auflage ralf WIRDEMANN SCRUM MIT USER STORIES 2. Auflage Wirdemann Scrum mit User Stories vbleiben Sie einfach auf dem Laufenden: www.hanser.de/newsletter Sofort anmelden und Monat für Monat die neuesten Infos

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

Navigator Scrum 1.0. IT-Projektmanagement bei Symposionline

Navigator Scrum 1.0. IT-Projektmanagement bei Symposionline Navigator Scrum 1.0 IT-Projektmanagement bei Symposionline Was ist scrum? Scrum (engl. für Gedränge) ist ein Vorgehensmodell mit Meetings, Artefakten, Rollen, Werten und Grundüberzeugungen, das beim Entwickeln

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat

Mehr

Agile Softwareentwicklung mit SCRUM

Agile Softwareentwicklung mit SCRUM Agile Softwareentwicklung mit SCRUM PMI MUC 01. März 2010 Referent: Gerhard Held mehr als 35 Berufsjahre in der Softwareentwicklung im Projektmanagement und verwandten Themen... Gründe für das Scheitern

Mehr

Lean, Agile & Scrum. Josef Scherer. Sponsoren. Agilität Scrum Grundlagen Erfahrungsaustausch. 10:30 12:00, ETH Zürich, E6

Lean, Agile & Scrum. Josef Scherer. Sponsoren. Agilität Scrum Grundlagen Erfahrungsaustausch. 10:30 12:00, ETH Zürich, E6 Lean, Agile & Scrum Conference Sponsoren Josef Scherer Scrum für Einsteiger Agilität Scrum Grundlagen Erfahrungsaustausch 10:30 12:00, ETH Zürich, E6 Vorstellung Erfahrung fh mit Scrum? Agile Kultur Agiles

Mehr

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Übersicht Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall V-Modell

Mehr

Requirements Engineering für die agile Softwareentwicklung

Requirements Engineering für die agile Softwareentwicklung Johannes Bergsmann Requirements Engineering für die agile Softwareentwicklung Methoden, Techniken und Strategien Unter Mitwirkung von Markus Unterauer dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1

Mehr

1 Einleitung 1. 1.4 Mehr Informationen zu Scrum... 6. 1.5 Danke... 6. 3 Die Rollen 9

1 Einleitung 1. 1.4 Mehr Informationen zu Scrum... 6. 1.5 Danke... 6. 3 Die Rollen 9 ix 1 Einleitung 1 1.1 Was ist Scrum?......................................... 1 1.1.1 Agiles Managementframework....................... 1 1.1.2 Empirischer Prozess................................ 2 1.1.3

Mehr

Agiles + traditionelles PM - ein unschlagbares Team?! www.pmcc-consulting.com

Agiles + traditionelles PM - ein unschlagbares Team?! www.pmcc-consulting.com Agiles + traditionelles PM - ein unschlagbares Team?! www.pmcc-consulting.com Vortrag PMI Chapter Frankfurt, Eschborn am 7. April 2015 00. Agenda Agenda 1. Projektmanagement 2. Probleme und Erkenntnisse

Mehr

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management

Mehr

Agile Methoden bei der Entwicklung medizinischer Software

Agile Methoden bei der Entwicklung medizinischer Software Agile Methoden bei der Entwicklung medizinischer Software Bernhard Fischer Fischer Consulting GmbH Fischer Consulting GmbH Technologie-Forum 2008 Folie 1 Wie soll Software entwickelt werden? Fischer Consulting

Mehr

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher Projektorganisation und Vorgehen in agilen Projekten Noser Technologieimpulse München 2013 - Matthias Neubacher Ein wenig Theorie Agile Methoden Warum? hohe Anpassbarkeit schnellere Ergebnisse günstigere

Mehr

Agile Softwareentwicklung

Agile Softwareentwicklung Agile Softwareentwicklung Werte, Konzepte und Methoden von Wolf-Gideon Bleek, Henning Wolf 2., aktualisierte und erweiterte Auflage Agile Softwareentwicklung Bleek / Wolf schnell und portofrei erhältlich

Mehr

Werte und Prinzipien der agilen Softwareentwicklung

Werte und Prinzipien der agilen Softwareentwicklung 1 Was ist Scrum? Scrum ist ein einfaches Projektmanagement-Framework, in das Entwicklungsteams selbstbestimmt erprobte Praktiken einbetten. Der Rahmen sieht einen empirisch, iterativen Prozess vor, bei

Mehr

Agile Embedded Projekte mit Scrum & Kanban. Embedded Computing Conference 2012 Urs Böhm

Agile Embedded Projekte mit Scrum & Kanban. Embedded Computing Conference 2012 Urs Böhm Agile Embedded Projekte mit Scrum & Kanban Embedded Computing Conference 2012 Urs Böhm Der Ingenieur Urs Böhm Dipl.-Ingenieur Elektrotechnik Projektingenieur VDI Certified ScrumMaster urs.boehm@noser.com

Mehr

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Wasserfall vs. Agile: Eine Erfolgsstory 2 Umsetzung agiler Prinzipien Entwicklungsprozess 2009 30.6% 13.4% 20.6% 35.4% Agil Iterativ

Mehr

Wasserfall, «Death March», Scrum und agile Methoden. 30.August 2011 Embedded Computing Conference 2011 Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 30.August 2011 Embedded Computing Conference 2011 Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 30.August 2011 Embedded Computing Conference 2011 Urs Böhm Übersicht Entwicklungsprozess Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall

Mehr

14.01.2010 Jürgen Primbs Informationsmanagement MIT 1

14.01.2010 Jürgen Primbs Informationsmanagement MIT 1 14.01.2010 Jürgen Primbs Informationsmanagement MIT 1 Vorgehen Entwicklung - Agenda Methodisches Vorgehen in Software-Entwicklungsprojekten SCRUM Ein Überblick Anforderungen Release-Management Sprints

Mehr

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten Projektmanagement Agile Methoden: Extreme Programming / Scrum Dokument V 1.2 Probleme bei Projekten Viel Arbeit, die an den Zielen vorbeigeht Viel Dokumentation für f r unbenutzte Bestandteile Fehlende

Mehr

Leuchtfeuer. Hinter den Kulissen der Scrum Transformierung der Allianz Deutschland

Leuchtfeuer. Hinter den Kulissen der Scrum Transformierung der Allianz Deutschland Leuchtfeuer Hinter den Kulissen der Scrum Transformierung der Allianz Deutschland Gliederung Über die Allianz Wie führen wir Scrum ein? Wie haben wir begonnen? Techniken und Praktiken Change-Management

Mehr

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt Überblick Agilität und Scrum Grundlagen der agilen Softwareentwicklung Rahmenbedingungen bei der Einführung eines agilen Projektvorgehens

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

Software Engineering (SE) 2) Phasenübergreifende Verfahren Software Engineering (SE) 2) Phasenübergreifende Verfahren Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang IBac 1 (Stand: 01.10.2014),

Mehr

RE-Metriken in SCRUM. Michael Mainik

RE-Metriken in SCRUM. Michael Mainik RE-Metriken in SCRUM Michael Mainik Inhalt Agile Methoden Was ist SCRUM? Eine kurze Wiederholung Metriken Burn Down Graph Richtig schätzen Running Tested Features WBS/ Earned Business Value Business Value

Mehr

2 Agile und klassische Vorgehensmodelle

2 Agile und klassische Vorgehensmodelle 9 2 Agile und klassische Vorgehensmodelle Dieses Kapitel gibt eine knappe Charakteristik des agilen Projektmanagementframeworks Scrum und der inzwischen auch populären, aus dem Lean Product Development

Mehr

Scrum - Von Schweinchen und Hühnchen

Scrum - Von Schweinchen und Hühnchen 4. November 2009 - Actinet IT-Services 1986 erster Computer 1990 Erstes Programm (Kleinster Gemeinsamer Teiler - Basic) 2000 Informatik Studium + Firmengründung 2007 Umorientierung - Software Development

Mehr

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming /

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming / Software- Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.2-2010 Projektmodelle im Vergleich Klassisch Wasserfall -Modell Spezifikation/Pflichtenheft

Mehr

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch Agiles Testmanagment Hugo Beerli bbv Software Services AG Luzern, September 2011 Product Backlog (Agenda) 1) Warum System Tests 2) Agile Arbeitsmethode Stand up Meeting 3) Vorteile der agilen Methode 4)

Mehr

Einflussfaktoren und Standards für den Weg zum Champion

Einflussfaktoren und Standards für den Weg zum Champion Einflussfaktoren und Standards für den Weg zum Champion 1 Herbert G. Gonder, PMP Bosshard & Partner Unternehmensberatung AG, Keynote Anlass, 10. April 2013 Agenda Ausgangslage Einflussfaktoren für den

Mehr

Agile Entwicklung in IT-Projekten - Anforderungen an Systemintegratoren

Agile Entwicklung in IT-Projekten - Anforderungen an Systemintegratoren Agile Entwicklung in IT-Projekten - Anforderungen an Systemintegratoren Unternehmensberatung H&D GmbH AFCEA Mittagsforum M. Sc. Dipl. Ing. (FH) Matthias Brechmann Agenda Unternehmensberatung H&D GmbH Anforderungen

Mehr

Basiswissen Software- Projektmanagement

Basiswissen Software- Projektmanagement Bernd Hindel. Klaus Hörmann. Markus Müller. Jürgen Schmied Basiswissen Software- Projektmanagement Aus- und Weiterbildung zum Certified Professional for Project Management nach isqi-standard 2., überarbeitete

Mehr

READY-STEADY-DONE! Der Product Owner are you READY for agile?!

READY-STEADY-DONE! Der Product Owner are you READY for agile?! READY-STEADY-DONE! Der Product Owner are you READY for agile?! Susanne Mühlbauer HOOD GmbH Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Neue Ideen sind

Mehr

Seminar Softwareentwicklung in der Wissenschaft

Seminar Softwareentwicklung in der Wissenschaft Seminar Softwareentwicklung in der Wissenschaft Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Betreuer: Christian

Mehr

Checkliste für Scrum-Meetings

Checkliste für Scrum-Meetings Checkliste für Scrum-Meetings Gesamtdarstellung 2 Produktvision teilen 3 Estimating 4 Planning 1 - Das WAS 5 Planning 2 - Das WIE 6 Daily Scrum 7 Das Review 8 Die Retrospektive 9 Artefakte 10 GOagile!

Mehr

Agile Management Einführung in agiles Management

Agile Management Einführung in agiles Management Agile Management Einführung in agiles Management Agile Management Agile Management-Methoden Einführung Agile Management PQRST e.u. - Ing. Erich Freitag Version 25.06.2013 Lernziele Den Unterschied zwischen

Mehr

Klassisches Projektmanagement und agil

Klassisches Projektmanagement und agil Klassisches Projektmanagement und agil (K)ein Widerspruch!? OPITZ CONSULTING GmbH 2011 Seite 1 Klassisches Projektmanagement und agil (K)ein Widerspruch!? Dr. Andreas Wagener, Project Manager OPITZ CONSULTING

Mehr

It s all about shipping software!

It s all about shipping software! 1 Shipping Software Raiffeisen Bausparkasse V-ARC, 21.12.2011 Gerhard H. Leonhartsberger It s all about shipping software! Seite 2 2 How fast do you ship quality software? Seite 3 Software Entwicklung

Mehr

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 Agiles Vorgehen 2 Agiles Vorgehen 3 WAS BEDEUTET AGIL Abstimmung über Ziel (nicht konkretes Entwicklungsergebnis)

Mehr

1. Methoden, Techniken und Tools: die harte Seite des Projektmanagements

1. Methoden, Techniken und Tools: die harte Seite des Projektmanagements 1 1. Methoden, Techniken und Tools: die harte Seite des Projektmanagements Herr Maier wurde von einem Tag auf den anderen Projektleiter: Übernehmen Sie das Projekt Orion, sagte sein Chef. Ohne zu wissen,

Mehr

Wie funktioniert agile Software-

Wie funktioniert agile Software- Wie funktioniert agile Software- Entwicklung mit SCRUM Zürich, 8. Mai 008 Jean-Pierre König, namics ag Software Engineer Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich www.namics.com Agenda»

Mehr

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden vs. Agile Methoden Christoph.Kluck@Student.Reutlingen University.de Medien und Kommunikationsinformatik Agenda Einführung Vorgehensmodelle Herkömmlich agil Resümee Klassische Probleme Nachgereichte Anforderungen

Mehr

Einführung in Scrum. Agiles Projektmanagement. Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen

Einführung in Scrum. Agiles Projektmanagement. Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen Einführung in Scrum Agiles Projektmanagement Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen Warum Agiles Projektmanagement? Scrum Empfehlungen Das Seminar Planbarkeit Warum Agiles Projektmanagement?

Mehr

Scrum Team Diagnose. Gibt es sonst noch etwas, was du zur Rolle des Product Owners sagen möchtest?

Scrum Team Diagnose. Gibt es sonst noch etwas, was du zur Rolle des Product Owners sagen möchtest? Scrum Rollen Product Owner (PO) Der PO ist klar definiert Der PO übersetzt Anforderungen in klare Backlog Items Der PO ist ermächtigt, Backlog Items zu priorisieren Der PO verfügt über das Fachwissen,

Mehr

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04 Empirische Evidenz von agilen Methoden Seminar in Software Engineering Wintersemester 03/04 Agenda Einleitung Bedeutung von agil Kurzübesicht agiler Methoden Überprüfung des (agilen) Erfolges Ausgewählte

Mehr

SCRUM - Trend oder Alternative zum traditionellen Projektmanagement

SCRUM - Trend oder Alternative zum traditionellen Projektmanagement SCRUM - Trend oder Alternative zum traditionellen Projektmanagement www.pmcc-consulting.com Manfred Brandstätter, MBA 12.07.2012 Agenda > 01 - Traditionelles Projekt Management > 02 - Probleme + Erkenntnisse

Mehr

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Di 7.2 January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Sprinten mit dem V-Modell XT Olaf Lewitz Sprinten mit dem V-Modell XT Olaf Lewitz microtool GmbH, Berlin Konkurrenz

Mehr

Agiles Projektmanagement SCRUM

Agiles Projektmanagement SCRUM Agiles Projektmanagement SCRUM www.pmcc-consulting.com club pm, 17.10.2013 Manfred Brandstätter, MBA Agenda 1 2 3 4 5 6 Traditionelles Projekt Management Probleme & Erkenntnisse Agiles Projektmanagement

Mehr

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird.

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. AGILO HOWTO Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. ROLLEN IM TEAM In Scrum hat jedes Teammitglied eine

Mehr

2 Management von Speicherprojekten

2 Management von Speicherprojekten 7 2 Management von Speicherprojekten 2.1 Einleitung Das Kapitel»Management von Speicherprojekten«steht am Anfang des Praxishandbuches, um die Bedeutung eines auf Standards und Best Practices beruhenden

Mehr

Jira im PM. Ticketing System im IT-Projekt Management Do s & Don ts

Jira im PM. Ticketing System im IT-Projekt Management Do s & Don ts Jira im PM Ticketing System im IT-Projekt Management Do s & Don ts Jira im Projektmanagement Profession Circle PMI Chapter Berlin/Brandenburg Live Demo Heiko Lübbe Berlin, 19. April 2012 2 Agenda Jira-Live-Demo

Mehr

Mobile Technologien in der Assekuranz: Wie sie effektiv genutzt und im Rahmen einer Mobile- Strategie umgesetzt werden können.

Mobile Technologien in der Assekuranz: Wie sie effektiv genutzt und im Rahmen einer Mobile- Strategie umgesetzt werden können. Studienabschlussarbeit / Bachelor Thesis Marcel Altendeitering Manuskript Mobile Technologien in der Assekuranz: Wie sie effektiv genutzt und im Rahmen einer Mobile- Strategie umgesetzt werden können.

Mehr

Diskussion eines hybriden Projektmanagements im Vergleich zu klassischem und agilem Projektmanagement. Bachelorarbeit

Diskussion eines hybriden Projektmanagements im Vergleich zu klassischem und agilem Projektmanagement. Bachelorarbeit Diskussion eines hybriden Projektmanagements im Vergleich zu klassischem und agilem Projektmanagement Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches Dieses Buch beschreibt das Wesen von Scrum die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen

Mehr

Abgrenzung bzw. Kombination traditionelles und agiles Projektmanagement

Abgrenzung bzw. Kombination traditionelles und agiles Projektmanagement Abgrenzung bzw. Kombination traditionelles und agiles Projektmanagement Vortrag im Rahmen des IKT-Forums 2015 Salzburg-Urstein am 21. Mai 2015 www.organisationsgesta 00. Agenda Agenda 1. Projektmanagement

Mehr

können Risiken und Fehlentwicklungen sehr früh erkannt und vermieden werden.

können Risiken und Fehlentwicklungen sehr früh erkannt und vermieden werden. r a i t da - können Risiken und Fehlentwicklungen sehr früh erkannt und vermieden werden. - Iteration sorgen zudem dafür, dass die Vorgehensweise und Zusammenarbeit im Projekt kontinuierlich verbessert

Mehr

Inhaltsverzeichnis. Abbildungsverzeichnis. Tabellenverzeichnis. Abkürzungsverzeichnis. 1 Überblick und Grundlagen 1

Inhaltsverzeichnis. Abbildungsverzeichnis. Tabellenverzeichnis. Abkürzungsverzeichnis. 1 Überblick und Grundlagen 1 Inhaltsverzeichnis Vorwort Abbildungsverzeichnis Tabellenverzeichnis Abkürzungsverzeichnis VII XV XXI XXIII 1 Überblick und Grundlagen 1 1.1 IT-Projekte 3 1.1.1 Probleme bei IT-Projekten 3 1.1.2 Risiken

Mehr

Produktphilosophie erstellen

Produktphilosophie erstellen User Experience Produktphilosophie erstellen Bereich Anforderungen Aktivität Ziele Erleichterte Kommunikation zwischen Stakeholdern Designentscheidungen erleichtern/rechtfertigen schnell durchführbar einfach

Mehr

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering 4. Methodologien Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering: 4. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

Bekannte Tools in einem agilen Ansatz. Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013

Bekannte Tools in einem agilen Ansatz. Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013 Bekannte Tools in einem agilen Ansatz Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013 Vorher Lange Planungszeiten und Releasezyklen Manche Features brauchten lange und wurden nicht gebraucht

Mehr

Agile Software Development with Scrum

Agile Software Development with Scrum Agile Software Development with Scrum (Schwaber/Beedle, Prentice Hall, 2002) Ein Lesebericht von Robert Hagedorn und Dr. Juho Mäkiö Was ist eigentlich Scrum und wie kann es erfolgreich in der Systementwicklung

Mehr

Software-Dokumentation im agilen Umfeld. Marion Bröer, parson communication

Software-Dokumentation im agilen Umfeld. Marion Bröer, parson communication Software-Dokumentation im agilen Umfeld Marion Bröer, parson communication parson communication Software- und Prozessdokumentation Wissensmanagement Wikis und XML-basierte Dokumentation Schulungen und

Mehr

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Die Bearbeitungszeit der Klausur beträgt 90 Minuten. Es sind alle

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

- Agile Programmierung -

- Agile Programmierung - Fachhochschule Dortmund Fachbereich Informatik SS 2004 Seminar: Komponentenbasierte Softwareentwicklung und Hypermedia Thema: - - Vortrag von Michael Pols Betreut durch: Prof. Dr. Frank Thiesing Übersicht

Mehr

Eliminating waste in software projects: Effective knowledge management by using web based collaboration technology Diplom.de

Eliminating waste in software projects: Effective knowledge management by using web based collaboration technology Diplom.de Frederik Dahlke Eliminating waste in software projects: Effective knowledge management by using web based collaboration technology The enterprise 2.0 concept applied to lean software development Diplom.de

Mehr

Integration von unterschiedlichen Vorgehensmodellen durch ein Project Management Office auf Basis des PMBoK. Werner Achtert

Integration von unterschiedlichen Vorgehensmodellen durch ein Project Management Office auf Basis des PMBoK. Werner Achtert Integration von unterschiedlichen Vorgehensmodellen durch ein Project Management Office auf Basis des PMBoK Werner Achtert Agenda Projektmanagement in IT-Projekten Einrichtung eines PMO in der BVBS PMBoK

Mehr