Leseprobe
Inhaltsverzeichnis
Abkürzungsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Verzeichnis der Listings
1 Einleitung
2 Projektmanagement Grundlagen
2.1 Projektmanagement
2.2 Agiles Projektmanagement
2.3 Projektmanagementsysteme
3 Serum
3.1 Rollen
3.2 Artefakte
3.3 Prozess
4 Projektron BCS
4.1 Funktionen
4.2 Architektur
4.3 Flexibilität
5 Serum bei der Hypoport AG
5.1 Prozess und Software-Anforderungen
5.2 Vergleich der Anforderungen mit Projektron BCS
5.3 Vorgaben
6 Anpassungen
6.1 Vorbetrachtungen
6.2 Umsetzung und Konfigurier bar keit
6.3 Integration
7 Fazit und kritische Bewertung
Anhang
A Technische Details
A. l Datenstruktur von Projektron BCS
A. 2 Konfiguration eines Ticket-Lebenszyklus
В Interviews mit Mitarbeitern der Hypoport AG
B. l Zusammenfassung des Gesprächs mit Herrn Heide
B. 2 Zusammenfassung des Gesprächs mit Herrn Gimbel
C Diagramme
D Konzeptgraphiken
E Beilage CD-ROM und Online-Testsystem
Literaturverzeichnis
Eidesstattliche Erklärung
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Abbildungsverzeichnis
1.1 Verbreitung agiler Softwareentwicklung
1.2 Anzahl eingesetzter PM-Tools
1.3 Systemanalyse im Unternehmen
2.1 Magisches Dreieck des Projektmanagements
2.2 PDCA-Zyklus in Verbindung mit PM-Prozessgruppen
2.3 Geschichte von Vorgehensmodellen
2.4 Anwendung agiler Vorgehensweisen
3.1 Serum
3.2 Aktivitätsdiagramm des Serum Prozesses
3.3 Aktivitätsdiagramm des Sprint Planning Meetings
3.4 Aktivitätsdiagramm des Daily Serum Meetings
3.5 Aktivitätsdiagramm des Sprint Review Meetings
3.6 Aktivitätsdiagramm des Sprint Retrospective Meetings
3.7 Release Burndown Chart
4.1 Arbeitsbereiche in Projektron BCS
4.2 Projektron BCS Projektassistent
4.3 Aufbau einer Projektron BCS Installation
4.4 Webseitenstruktur von Projektron BCS
4.5 WebConfig-Editor zum Bearbeiten der GUI
4.6 Zusätzliche Attribute eines Projekts
5.1 Acht Elemente der Europace Plattform
5.2 Anforderungserhebung eines Projekts der Hypoport AG
5.3 Projektron BCS Strukturplan eines Hypoport-Projekts
5.4 Lebenszyklen von user stories und Akzeptanztests
5.5 Definition der Grundlast und Ressourcenauslastung
5.6 Einer Organisation zugeordnete Projekte
5.7 Product Backlog in Projektron BCS
5.8 Schematische Datenstruktur von Aufgaben und Anmerkungen . .
5.9 Auszug aus der Datenstrukturinfo einer Aufgabe und Statusanzeige
5.10 Änderungshistorie im Projektron BCS Ticketsystem
6.1 Hierarchische Anordnung von Tickets im Strukturplan
6.2 Umwandlung von Tickets
6.3 Lebenszyklus eines Bugs
6.4 Verbindliche und nicht verbindliche Lebenszyklen
6.5 Erfolgsmeldung und Warnung nach Umwandlung
6.6 Burndown Chart in Projektron BCS
6.7 Integration der Anzeige von Tickets im Strukturplan
6.8 Integration der untergeordneten Tickets und Arbeitsabläufe
6.9 Kompatibilität zur gegenwärtigen Teamplanung
6.10 Aufwandsplanung auf Sprintebene
B. l JIRA Tickettypen und -status
c.l Aktivitätsdiagramm des Serum Prozesses
C. 2 Detailliertes Aktivitätsdiagramm des Serum Prozesses
C. 3 Aktivitätsdiagramm des Serum Prozesses der Hypoport AG
D. l Strukturplan eines Serum Projekts im Anzeigenmodus
D. 2 Strukturplan eines Serum Projekts im Bearbeitungsmodus
D.3 Mittels Lebenszyklus eingeschränkte Arbeitsabläufe eines Bugs
D.4 Uneingeschränkte Arbeitsabläufe eines ChangeRecļuests
D.5 Ticketansicht mit Aufwänden, Arbeitsabläufen und Beziehungen
D.6 Integration des Burndown Charts
Tabellenverzeichnis
3.1 Tabellarisches Product Backlog
4.1 Projektron BCS Konfigurationsdateien
5.1 JIRA Tickethierarchie der Hypoport AG
5.2 Anforderungen an die Softwareunterstützung
5.3 Erfüllung der Anforderungen durch die Software
6.1 Attribute eines ChangeState-Elements
A.l Subtypen des Objekts Organisation
A.2 Subtypen des Objekts Person
A.3 Subtypen des Objekts Projekt
A.4 Subtypen des Objekts Aufgabe
A.5 Subtypen des Objekts Anmerkung
A.6 Subtypen des Objekts Aufwand
Verzeichnis der Listings
4.1 Beispieleintrag in einer ServerConf ig* .properties-Datei
6.1 Minimalkonfiguration von Ticketarten
6.2 Einschränkung möglicher Kindelemente
6.3 Definition des Lebenszyklus eines Bugs
6.4 Berücksichtigung von Status im Burndown Chart
A.l Konfiguration des Lebenszyklus der Projektron Support Tickets
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 Serum 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, Serum, 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
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 Dori 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 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 Hein- ze, der bei Projektron als Berater tätig ist, hervor.
Schließlich gilt mein besonderer Dank Frau Claudia Deckert, inzwischen als SerumMaster zertifiziert, die meine Begeisterung für Projektmanagement und besonders für Serum 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
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 Schlitzung“ 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. [Standisti 1994], [Gaulke 2004, s.42ff.])
Um Projekte erfolgreicher, also schneller, kosteneffizienter und Cļualitativ 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 Arne- rican 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 Viertel oder nur bis zu einem Viertel aller Softwareentwickler nach agilen Vorgehensweisen. Agilität polarisiert also: Sie wird entweder umfassend, fast úntemeh- mensweit oder nur sehr vereinzelt eingesetzt. Unternehmen mit weniger als 100 Mitarbeitern im Bereich Softwareentwicklung stellen dabei bezüglich des weitrei- eilenden Einsatzes den größten Anteil. (Vgl. [Behrens 2006])
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1.1: Verbreitung agiler Softwareentwicklung, Quelle: [Schwaber 2007b]
Vierundvierzig Prozent aller Unternehmen werten über 90% ihrer agil durchgeführten Projekte als Erfolg. Weitere dreiunddreißig Prozent bescheinigen ihren Projekten eine Erfolgscļuote von 75-90%. Agile Projekte sind also überaus erfolgreich. (Vgl. [Ambier 2007])
Mehr als die Hälfte der Unternehmen, deren Entwicklungsprozess agil ist, verweil- det 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 hegt 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])
Abbildung in dieser Leseprobe nicht enthalten
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 in dieser Leseprobe nicht enthalten
Abbildung 1.3: Vorgehensmodell der Systemanalyse im Unternehmen und AnWendung des Modells, Quelle: [Krallmann u. a. 2002]
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 Serum 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 Serum Prozesses innerhalb der Hypoport AG analysiert. Es wird als Teil des Soll-Konzepts dargelegt, welche Anpassungen an Projektron BCS notwendig sind, um die Uli- terstützung des Serum 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 zusammen ge fasst und bewertet.
2 Projektmanagement Grundlagen
Don’t undertake a project unless it is manifestly important and nearly impossible.
(Edwin Land)
Um Projektmanagement zu definieren, wird das folgende Kapitel die 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 vor gestellt.
2.1 Projektmanagement
Der Ursprung des Wortes Projekt hegt in dem lateinischen Verb proiacere (pro = vor, für, lacere = werfen). Ein Projekt ist also in die Zukunft gerichtet: ein Vorhaben.
Laut DIN 69901 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, be- gren,zt.es Vorhaben, zur Schaffung eines einmaligen Produktes, einer Dienstleistung oder eines Ergebnisses.“ ([PMBoK 2004, S.5])
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, Fertigkelten, Werkzeugen und Methoden auf Projektvorgänge, um die Projektan forderungen 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) hegt der Ausführung (Do) zu Grunde. Der Fortschritt der Ausführung wird wiederum auf Abweichungen vom
Abbildung in dieser Leseprobe nicht enthalten
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 in dieser Leseprobe nicht enthalten
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 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:
Integrationsm.anagem.ent, beinhaltet die Koordinierung aller Prozesse. Auftragsentwicklung, Änderungssteuerung und Abschluss des Projekts fallen in diesen Bereich. Das Inhalts- und Um.fangsm.anagem.ent 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 beeinflusseil, Terminplanung und Schätzungen der Dauer von Vorgängen werden unter dem Begriff des Term.inm.anagem.ents zusammengefasst. Prozesse des Kost.enm.a- падет.en.t.s dienen dem budgetgerechten Abschluss des Projekts. Qualität.sm.a- падет,ent, beinhaltet Vorgänge, die der Prozessverbesserung und der Sicherung von Qualitätsstandards in Bezug auf Projektanforderungen dienen. Person,aim,a- n,agem,en,t umfasst die Teamplanung und -leitung sowie die Verteilung der Rollen und Verantwortlichkeiten. Das Risikom.anagem.ent, 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 Besch.affungsm.anagem.ent. Das Management von Verträgen und bezüglich Lieferanten zählt ebenso dazu. Aufgabe des Kom.m.unikationsm.anagem.ents ist die Sicherstellung der Verfügbarkeit von Informationen innerhalb des Projekts, das Fortschrittsberichtswesen und das Sta- keholderm.anagem.ent. Als Stakeholder (engl, für Teilhaber, Interessenvertreter) werden Personen und Organisationen bezeichnet, die am Projekt teilhaben und die Durchführung beeinflussen können. Stake holdermanagement versucht, durch Kommunikation mit den Stakeholdern deren Projektanforderungen zu erfüllen sowie Probleme zu lösen. (Vgl. [PMBoK 2004, s.337ff.])
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 än- eiernde Projektanforderungen und schwächen so einen weiteren Risikofaktor ab.
Zumeist Ende der 1990er-Jahre entwickelt, wurden diese flexiblen Vorgehenswei- seil erst 2001, nach der Formulierung des Agilen Manifests, unter dem Begriff der Agilität zusammen ge fasst. (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 Bot,tom.-up- statt eine Top-Down-Planung. Bei ersterer werden Planwerte in den unteren Elementen der Projektplanung erfasst und zu einem Gesamtbudget summiert. Top-Down- Planung gibt hingegen erst das Gesamtbudget vor und verteilt dies anschließend von oben nach unten auf Unterprojekte, Aufgaben, oder andere Strukturelemente. (Vgl. [Oestereich und Weiss 2008], [Schwaber 2007b])
Der zuvor beschriebene Trend zur Agilität hat dazu geführt, dass weitere 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])
Abbildung in dieser Leseprobe nicht enthalten
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 Dokument at ionen 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.l], [Angermeier 2005, S.296])
Agile Vorgehensweisen sind vielfach miteinander kombinierbar. Hauptvorgehensweise ist jedoch in nahezu 60% aller Unternehmen Serum (vgl. Abbildung 2.4).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.4: Anwendung agiler Vorgehensweisen,
Quelle: [Behrens 2006]
Als zentraler Aspekt der vorliegenden Arbeit wird Serum daher im folgenden Kapitel eingehend erläutert.
3 Scrum
Liberty means responsibility. That is why most men dread it.
(George Bernard Shaw)
Dieses Kapitel wird Scrum, eine agile Projektmanagementmethodik, und seine klar definierten Regeln unterteilt nach Rollen, Artefakten und Prozess beschreiben und Empfehlungen bewährter Praktiken darlegen.
Der Begriff Serum 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])
Serum 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 Serum Prozess sieht weiterhin vier Meetings vor. Das verdeutlicht bereits, wie stark Serum das Agile Manifest wider spiegelt. 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.1 Rollen
ScrumMaster
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, verweil- det Schwaber einen neuen Titel: den ScrumMaster. Aufgabe des ScrumMasters ist es, für die Einhaltung und den möglichst reibungslosen Ablauf des Serum 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 Serum 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 ScrumMa- ster ü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 Nicht gefallen. 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 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 Serum Prozesses Hindernisse beseitigt, zur Konfliktbewältigung beiträgt und eine gemeinschaftliche Entscheidungsfindung fördert. So gewinnt er an Einfluss. Mit Serum 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 Anforderangen würden sich ändern und 65 Prozent seien von so geringem Wert, dass ihre Lieferung fraglich sei ([Schwaber 2007a]). In Serum 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 Serum Prozess in seine Verantwortung fällt: dem Product Backlog. Hier werden Anforderungen ergänzt oder entfernt, verfeinert und priori- siert. Um dabei stets im Interesse der Auftraggeberseite zu handeln, ist intensive regelmäßige Abstimmung notwendig. ([Pichler 2007, S.10])
Da der Product Owner das Releasern,anagem,ent 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 Serum, können aufkommende Fragen sofort geklärt werden. Je öfter der Product Owner mit dem Team arbeitet, desto unwahrscheinlicher kommt 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.ll])
Team
In der Verantwortung des Teams hegt 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 Serum in einer Organisati- Oll 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])
Serum 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- 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 Serum scheint widersprüchlich zur Erläuterung des Teams. Serum 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 Serum: Eine Festlegung erfolgt bei Serum 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 Serum Prozess werden trotz der Abschaffung der Rolle des klassischen Projektmanagers fast sämtliche Aufgaben traditionellen Projektmanagements erfüllt. 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 Quahtätsmanagement: Der Product Owner bezogen auf die Leistungsmerkmale des Produkts, das Team bezüglich der Cļuali- tat iv hochwertigen Umsetzung und schließlich der ScrumMaster bezogen auf die Prozesscļualitā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])
3.2 Artefakte
Zwei der drei Artefakte im Serum Prozess enthalten den Begriff backlog. Dabei handelt es sich um eine Liste von Dingen, die getan werden müssen, eine ״Zu- erledigen-Liste“. Das erste dieser Artefakte, das Product Backlog bezieht sich auf das komplette Projekt. Die zweite Listenart, das Sprint Backlog, gilt für je einen Sprint.
Product Backlog
Anforderungserhebung und -management werden in Serum mit dem Product Backlog realisiert. Alle bekannten funktionalen und nicht funktionalen Anforderungei! 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 we- seilt liehe Anforderungen (Erfolgsfaktoren für Vertrieb und Einsatz des Produkts). Um dem Team Selbstmanagement durch Auswahl der Anforderungen zu ermög- liehen, 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- cheli. 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])
Abbildung in dieser Leseprobe nicht enthalten
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 steht 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, confirm.ation (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 Serum zwischen Product Owner und Team, erarbeitet (conversation und verhandelbar). Die Einigung auf Akzeptanzkriterien bestätigt das gemeinsame Verständnis einer user story (confirm.ation 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.
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ätzbar keit (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 Auswähl ist die Menge der Anforderungen, die der Product Owner am höchsten prio- risiert hat. Das auf diese Weise definierte Sprint-Ziel darf während des 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 fest geliai- ten. 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
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 Serum. 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 Serum 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
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 doppelteil Passagen enthält. Erst eine gemeinsame DoD zwischen Product Owner und Entwicklungsteam erzeugt die für Serum 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 ent halten, 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
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 in dieser Leseprobe nicht enthalten
Copyright © 25םם, Mountain Boat Software
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 Serum Prozesses. Nach jeder Iteration, jedem Sprint, sowie täglich während des Sprints sind Beobachtungen und Anpassungen vorgesehen. Abbildung 3.2 zeigt den Serum Prozess in Form eines Aktivitätsdiagramms. Detailliert dargestellt sind die Vorbereitung eines Serum Projekts und relevante Entscheidungen nach Abschluss eines Sprints. Die innerhalb der Meetings des Serum 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 Serum die Aspekte empirischer Prozesskontrolle auf jede Aktivität innerhalb des Prozesses überträgt, wird bei der Betrachtung der Meetings innerhalb des
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.2: Aktivitätsdiagramm des Serum Prozesses
Serum Prozesses deutlich. Die Serum-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 Serum 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 Serum Prozess vorgesehenen collaboration points zeitlich begrenzte Besprechungen mit festgelegten Inhalten und Teilnehmern. Für die Einhaltung der Regeln und die Moderation ist der SerumMaster verantwortlich.
Die erste und, da sie für den gesamten Serum 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. Ahes andere ist kon-
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. Schwa- BER 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 vorhegen. 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üsseil. 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.
[...]
[1] Im Gegensatz zum Betrieb, dessen Arbeit stets andauert, und dessen Ziel die Aufrechterhai- tung des Geschäfts ist. ([PMBoK 2004, s.7])
[2] Die geläufige Abkürzung für A Guide to the Project Management Body of Knowledge.
[3] Das V-Modell XT beispielsweise definiert 31 Rollen und weit mehr Produkte. ([VMXT 2007,
S.233ff., s.500ff.])
[4] Nach Cohn ein spike, für den begrenzte Zeit zur Verfügung steht.
[5] Schwaber verwendet potentially skippable product increment oder increment of potentially skippable product functionality synonym.
[6] Der EPF Composer ist ein Tool zur Prozessdefinition. Eine mit diesem freien Werkzeug erstellte Definition des Serum Prozesses ist ([Eclipse]).