Projektmanagement - Handout 1 0

Handout Projektmanagement Stephan Strittmatter, Sybit GmbH Eine Einführung ins Projektmanagement bei IT-Projekten Mit Fokus auf die Projektarbeiten am Technischen Gymnasium (Informationstechnik) in Singen werden die Eckpunkte des Projektmanagements vorgestellt und abschließend konkrete Anforderungen an die Projektarbeiten dargestellt.

Kapitel 1 Grundlagen Zum Projektmanagement in IT-Projekten Projektmanagement ist nicht eindeutig zu definieren. Jeder Bereich, sei es Soft- wareentwicklung oder der Bau einer Brücke, hat andere Schwerpunkte, was das Organisieren von Projekten angeht. Eine allgemein gültige Definition versucht die DIN-Norm zu liefern. Durch die allgemein gehaltene Beschreibung kann man daraus jedoch keine weiteren Hilfen ableiten: „Projektmanagement ist die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projektes.“ (DIN 69901) 1 Im Folgenden gehen wir nun auf das Managen von Projekten im Bereich der IT ein. Einige Techniken sind jedoch allgemein gültig und werden auch in Projekten aus anderen Bereichen angewandt. 1 http://de.wikipedia.org/wiki/Projektmanagement 3

Definition Ein Projekt hat einen Anfang und ein Ende. Es geht also darum, in einem begrenzten Zeitraum, mit begrenzten Mitteln und bestimmten Personen geeignete Aktivitäten und Maßnahmen durchzuführen, um ein bestimmtes Ziel zu erreichen. Damit Projekte nicht aus dem Ruder laufen, muss sich eine Projektgruppe ständig über wichtige Fragen verständigen: Sind unsere Ziele realistisch? Stehen uns genügend Ressourcen (Geld, Material, Personal) zu Verfügung? Liegen wir im Zeitplan? Nehmen alle im Team ihre Verantwortung wahr? Nur durch Planung, Organisation, Kontrolle und Kommunikation kann ein Projekt zum Erfolg geführt werden. Dies sind die wichtigsten Elemente des Projektmanagements. Methoden des Projektmanagements helfen, die richtigen Fragen zu stellen, die notwendigen Schritte gemeinsam in der Gruppe zu planen und durch Erfolgserlebnisse motiviert bei der Sache zu bleiben. Projektzyklen Der Ablauf eines Projektes lässt sich in Zyklen beschreiben. Je nach Prozessmodell über- schneiden sich diese Zyklen, sie sollten jedoch in jedem Projekt zu finden sein. Abbildung 1: Projektzyklus (Gray & Larson, 2006) 4

Defining Die Ziele des Projektes müssen zunächst definiert werden. Was will der Kunde mit dem Resultat anfangen? Aus diesen Zielen können dann Anforderungen, Spezifikationen und Verantwortlichkeiten abgeleitet werden. Planning Der Ablauf des Projektes muss geplant werden. Dabei ist nicht nur der Zeitplan von Interesse, es geht hierbei auch um Ressourcen, wie z.B. Mitarbeiter oder auch Hardware oder Know-how. Weiterhin muss das zur Verfügung stehende Budget eingeteilt werden. Executing Geht es an die Umsetzung, so muss immer wieder überprüft werden, ob die geplanten Ziele erreicht worden sind oder ob eventuelle Probleme aufgetreten sind. Unter Umständen muss auch auf Veränderungen in den Anforderungen eingegangen und mit dem Kunden verhandelt werden. Delivering Am Ende eines Projektes steht – hoffentlich – die Lieferung. Dazu muss das System dem Kunden übergeben werden, sei es als Installations-Datei oder als umfangreiches System, das vor Ort in Berieb genommen wird. Entsprechende Dokumente, wie Systemdokumentation oder Anwenderhandbuch müssen erstellt werden. 5

Methoden und Prozesse Im Projektmanagement gibt es unterschiedliche Methoden, um ans Ziel zu gelangen. Die 2 Wikipedia (de) listet derzeit alleine über 25 Prozesse und Vorgehensmodelle auf: Hier nun einige der bekannteren kurz vorgestellt. Capability Maturity Model Integration 3 Das Capability Maturity Model Integration (kurz CMMI) ist eine Familie von Referenzmodellen für unterschiedliche Anwendungsgebiete - derzeit für die Produktentwicklung, den Produkteinkauf und die Serviceerbringung. Ein CMMI-Modell ist eine systematische Aufbereitung bewährter Praktiken, um die Verbesserung einer Organisation zu unterstützen. Ein CMMI-Modell kann genutzt werden, um einen Überblick über bewährte Praktiken (z.B. bei der Projektplanung) zu bekommen, die Stärken und Schwächen einer Organisation objektiv zu analysieren oder Verbesserungsmaßnahmen zu bestimmen und in eine sinnvolle Reihenfolge zu bringen. Primär sind die CMMI-Modelle ein Mittel, um die Arbeit einer Organisation zu verbessern. Sekundär ist es eine offizielle Überprüfung eines Reifegrades (siehe Appraisal) eine in der Industrie de facto anerkannte Auszeichnung. CMMI wird deshalb auch häufig auch als Reifegradmodell bezeichnet, obwohl die Reifegrade nur ein Aspekt unter vielen von CMMI sind. Einordnung der CMMI-Modelle Die CMMI-Modelle sind Referenzmodelle, die bewährte Praktiken zusammenfassen. Im Gegensatz zu einem konkreten Vorgehensmodell definiert ein CMMI-Modell grundsätzliche Praktiken z. B. einer guten Produktentwicklung (das „Was“), aber keine konkreten Schritte (das „Wie“). Das primäre Ziel der CMMI-Modelle ist es, eine kontinuierliche Prozessverbesserung zu unterstützen, indem Praktiken bzw. Kriterien von einer professionellen Organisation definiert werden. Die konkrete und adäquate Ausgestaltung der Arbeit bzw. Arbeitsweise obliegt der Organisation und ist eine wichtige Teilaufgabe der Prozessverbesserung. Da CMMI keine konkrete Vorgehensweise definiert, kann CMMI auf sehr unterschiedliche Organisationen und Organisationsgrößen angewendet werden. So kann z. B. die Forderung von CMMI, dass bei der Projektplanung eine Zustimmung der Projektbeteiligten (Stakeholder) zum Projektplan eingeholt werden muss, auf sehr unterschiedliche Art und Weise konkret in einer Organisation umgesetzt werden. Es gibt daher nicht „die eine“ richtige CMMI-Umsetzung. Eine besondere Eigenschaft der CMMI-Modelle ist, dass sie nicht nur auf die fachlichen Praktiken eingehen, sondern auch auf die unterstützenden Aufgaben der Organisation, wie z. B. Ressourcen-Bereitstellung oder Durchführung von Trainingsmaßnahmen. Ein weiteres besonderes Merkmal ist, dass CMMI sehr viel Wert auf den gelebten Prozess legt und so im Gegensatz zu häufig als „Schrankware“ bezeichneten Prozessen steht, die dokumentiert, aber nicht gelebt werden. 2 http://de.wikipedia.org/wiki/Liste_von_Softwareentwicklungsprozessen 3 http://de.wikipedia.org/wiki/CMMI 6

Reifegrade Neben den Fähigkeitsgraden eines einzelnen Prozessgebiets definiert CMMI „Reifegrade“ (maturity levels). Ein Reifegrad umfasst eine Menge von Prozessgebieten, die mit dem zum Reifegrad korrespondierenden Fähigkeitsgrad etabliert sein müssen. Jeder Reifegrad ist ein Entwicklungsplateau in der Prozessverbesserung der Organisation. CMMI bietet damit eine Hilfe für die Verbesserung, indem es die Prozessgebiete bezüglich der Verbesserung priorisiert. Die Reifegrade sind: 1 - Initial : Keine Anforderungen. Diesen Reifegrad hat jede Organisation automatisch. 2 – Managed: Die Projekte werden geführt. Ein ähnliches Projekt kann erfolgreich wiederholt werden. 3 – Defined: Die Projekte werden nach einem angepassten Standardprozess durchgeführt, und es gibt eine organisationsweite kontinuierliche Prozessverbesserung. 4 - Quantitatively Managed: Es wird eine statistische Prozesskontrolle durchgeführt. 5 – Optimizing: Die Arbeit und Arbeitsweise werden mit Hilfe einer statistischen Prozesskontrolle verbessert. Rational Unified Process Zu den klassischen Methoden gehören der „Rational Unified Process“. Der Rational Unified 4 Process (RUP ) ist ein objektorientiertes Vorgehensmodell zur Softwareentwicklung und ein kommerzielles Produkt der Firma Rational Software, die seit 2002 Teil des IBM Konzerns ist. IBM entwickelt den RUP und die zugehörige Software weiter. Die 9. Version ist die derzeit (2006) aktuelle Version. Der RUP benutzt die Unified Modeling Language (UML) als Notationssprache. V-Modell 5 Das V-Modell ist eine abstrakte, umfassende, ursprünglich aus der IT kommende Projekt- management-Methode für Entwicklungsprojekte. Der Begriff resultiert einerseits aus dem ersten Buchstaben des Vorgehensmodells und andererseits aus der V-förmigen Darstellung der Projektelemente aus Spezifikation und Zerlegung (im absteigenden Ast) und Realisierung und Integration im aufsteigenden Ast(siehe Abbildung). 4 http://de.wikipedia.org/wiki/Rational_Unified_Process 5 http://de.wikipedia.org/wiki/V-Modell 7

Abbildung 2 Phasen des V-Modells über Zeit und Detaillierung Die Idee zum V-förmigen Vorgehen kam von Barry Boehm 1979. Das erste V-Modell wurde 1986 in Deutschland entwickelt. Zunächst war es für IT-Projekte der öffentlichen Hand vorge- sehen, inzwischen wird es aber auch in der Privatwirtschaft eingesetzt. Scrum 6 Scrum (engl. das Gedränge) ist ein Vorgehensmodell mit Meetings, Artefakten, Rollen, Werten und Grundüberzeugungen, das beim Entwickeln von Produkten im Rahmen agiler Softwareentwicklung hilfreich ist. Das Angeordnete Gedränge (englisch scrum) ist in verschiedenen Varianten des Rugbysports die Standardsituation, um das Spiel nach kleineren Regelverstößen, einem unerlaubten Vorwärtsspielen des Balles oder nach einem Aus (nur im Rugby League) neu zu starten. Einwurf erhält die Mannschaft, die den Regelverstoß nicht begangen hat. 7 Scrum kennt drei Rollen für direkt am Prozess Beteiligte: Product Owner (stellt fachliche Anforderungen und priorisiert sie), ScrumMaster (managt den Prozess und beseitigt Hinder- nisse) und Team (entwickelt das Produkt). Daneben gibt es als Beobachter und Ratgeber noch die Stakeholders (die Interessenvertreter). Die Anforderungen (Requirements) werden in einer Liste (Product Backlog) gepflegt, erweitert und priorisiert. Das Product Backlog ist ständig im Fluß. Um ein sinnvolles Arbeiten zu ermöglichen, wird monatlich vom Team in Kooperation mit dem Product Owner ein definiertes Arbeitspaket dem oberen, höher priorisierten Ende des Product Backlogs entnommen und komplett in Funktionalität umgesetzt (inkl. Test und notwendiger Dokumentation). Dieses Arbeitspaket, das Increment, wird während der laufenden Iteration, des sog. Sprints, nicht durch Zusatzanforderungen modifiziert, um seine Fertigstellung nicht zu gefährden. Alle 6 http://de.wikipedia.org/wiki/Scrum 7 http://de.wikipedia.org/wiki/Gedr%C3%A4nge_%28Rugby%29 8

anderen Teile des Product Backlogs können vom Product Owner in Vorbereitung für den nachfolgenden Sprint verändert bzw. neu priorisiert werden. Das Arbeitspaket wird in kleinere Arbeitspakete (Tasks) heruntergebrochen und mit jeweils zu- ständigem Bearbeiter und täglich aktualisiertem Restaufwand in einer weiteren Liste, dem Sprint Backlog, festgehalten. Während des Sprints arbeitet das Team konzentriert und ohne Störungen von außen daran, die Tasks aus dem Sprint Backlog in ein Increment of Potentially Shippable Functionality, also einen vollständig fertigen und potentiell produktiv einsetzbaren Anwendungsteil, umzusetzen. Das Team gleicht sich in einem täglichen, streng auf 15 Minuten begrenzten Informations-Meeting, dem Daily Scrum Meeting, ab, damit jeder weiß, woran der andere zuletzt gearbeitet hat, was er als nächstes vor hat und welche Probleme es evtl. gibt. Am Ende des Sprints präsentiert das Team dem Product Owner, den Stakeholders u.a. interessierten Teilnehmern in einem sog. Sprint Review Meeting live am System die implementierte Funktionalität. Halbfertiges oder gar Powerpoint-Folien sind während des Reviews verboten. Das Feedback der Zuseher und die neuen Anforderungen des Product Owners für den kommenden Sprint fließen dann wieder in das nächste Sprint Planning Meeting ein, und der Prozess beginnt von neuem. Sprint 2-4 Wochen Sprint Ziel Rücksendung Sprint Backlog Potentiell auslieferbares Teilprodukt Rücksendung Stornieren Gutscheine Geschenkpapier Stornieren Geschenkpapier Product-Backlog Abbildung 3 Scrum Entwicklungsprozess Der ScrumMaster sorgt während des gesamten Prozesses dafür, dass Regeln eingehalten werden und der Status aller Tasks im Sprint Backlog von den jeweils zuständigen Team- Mitgliedern täglich aktualisiert wird. Er macht den Projektfortschritt transparent durch einen geeigneten Reporting-Mechanismus: die Veröffentlichung sog. Burndown Charts, welche den Fortschritt für den aktuellen Sprint bzw. für das gesamte Projekt jeweils in Form einer Kurve visualisieren. Eingezeichnete Trendlinien erlauben es, mögliche Probleme und Verzögerungen einfach (und rechtzeitig!) zu erkennen. Im Kern basiert Scrum also auf einer inkrementellen Vorgehensweise, der Organisation von Entwicklungsabschnitten und Meetings in vordefinierten Zeitabschnitten (Time-Boxes) und der Erkenntnis, dass ein funktionierendes Produkt wichtiger ist als eine dreihundertseitige Spezifikation. Elemente aus Scrum werden konkret in die Projektarbeit einfließen und werden im Folgenden noch näher betrachtet. 9

Klassifizierung Es gibt unterschiedliche Möglichkeiten die Prozesse und Modelle einzustufen. Wir beschränken uns hier auf die beiden teilweise gegensätzlichen Modelltypen „Wasserfall“ und „Agil“. Wasserfallmodell Das Wasserfallmodell gehört zu einem der klassischen linearen Vorgehensmodelle in der IT. Man spricht vom Wasserfall, da die einzelnen Phasen klar voneinander abgetrennt sind. Dabei gehen die Phasenergebnisse wie bei einem Wasserfall immer als bindende Vorgaben für die nächst tiefere Phase ein. Im Wasserfallmodell hat jede Phase vordefinierte Start- und Endpunkte mit eindeutig definierten Ergebnissen. In Meilensteinsitzungen am jeweiligen Phasenende werden die Ergebnisdokumente verabschiedet. Zu den wichtigsten Dokumenten zählen dabei das Lastenheft sowie das Pflichtenheft. In der betrieblichen Praxis gibt es viele Varianten des reinen Modells. Es ist aber das traditionell am weitesten verbreitete Vorgehensmodell. Der Name „Wasserfall“ kommt von der häufig gewählten grafischen Darstellung der fünf bis sechs als Kaskade angeordneten Phasen. Abbildung 4 Ein erweitertes Wasserfallmodell mit Rücksprungmöglichkeiten (gestrichelt) 10

Erweiterungen des einfachen Modells (Wasserfallmodell mit Rücksprung) führen iterative Aspekte ein und erlauben ein schrittweises „Aufwärtslaufen“ der Kaskade, sofern in der aktuellen Phase etwas schief laufen sollte, um den Fehler auf der nächst höheren Stufe beheben zu können. Das Wasserfallmodell wird allgemein dort vorteilhaft angewendet, wo sich Anforderungen, Leistungen und Abläufe in der Planungsphase relativ präzise beschreiben lassen. Winston Royce beschreibt das Wasserfallmodell in seiner Publikation Managing the Development of Large Software Systems aus dem Jahr 1970 als fehlerträchtiges und kosten- risikobehaftetes Modell der Softwareentwicklung; dabei bezieht er sich sowohl auf die einfache Variante als auch auf die erweiterte mit schrittweise erfolgenden Rücksprungmöglichkeiten. Stattdessen schlägt Royce in dieser Publikation ein wesentlich um iterative Elemente erweitertes Modell vor. Agile Softwareentwicklung Agile Softwareentwicklung ist der Oberbegriff für den Einsatz von Agilität (lat.agilis 'flink, beweglich') in der Softwareentwicklung. Je nach Kontext bezieht sich der Begriff auf Teil- bereiche der Softwareentwicklung – wie im Fall von Agile Modeling – oder auf den gesamten Softwareentwicklungsprozess – exemplarisch sei Extreme Programming angeführt. Agile Softwareentwicklung versucht mit geringem bürokratischen Aufwand und wenigen Regeln auszukommen. Das Ziel „Agiler Softwareentwicklung“ ist es, den Softwareentwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist. Man möchte sich mehr auf die zu erreichenden Ziele fokussieren und auf technische und soziale Probleme bei der Softwareentwicklung eingehen. Die Agile Softwareentwicklung (z. B. Scrum) ist eine Gegenbewegung zu den oft als schwergewichtig und bürokratisch angesehenen traditionellen Softwareentwicklungsprozessen wie dem Rational Unified Process oder dem V- Modell. 11

Kapitel 2 Anforderungen Für ein Projekt aufnehmen Basis eines jeden Projektes sind die Anforderungen des Kunden. Diese Anforderungen müssen für alle Projektbeteiligten verständlich festgehalten werden. Die Anforderungen, die an das Ergebnis eines Projektes – in unserem Fall die Software – gestellt werden, müssen schriftlich festgehalten werden. In vielen Fällen erstellt der Kunde, der die Anwendung haben möchte ein Lastenheft (teils auch Anforderungsspezifikation, Kunden- spezifikation oder Requirements Specification genannt), wo die Gesamtheit der Anforderungen an die Lieferungen und Leistungen des Auftragnehmers zusammengefasst werden. 13

Pflichtenheft Das Pflichtenheft beschreibt in konkreterer Form, wie der Auftragnehmer die Anforderungen im Lastenheft zu lösen gedenkt. Ein wesentlicher Unterschied zu einem Lastenheft besteht darin, dass das Pflichtenheft dem Auftragnehmer gehört. Ein Lastenheft beschreibt die Gesamtheit der Forderungen des Auftraggebers, im Pflichtenheft ist in konkreterer Form beschrieben, wie der Auftragnehmer die Anforderungen im Lastenheft zu lösen gedenkt. Die Kombination aus Lastenheft und Pflichtenheft wird meist in der klassischen Vorgehens- weise, wie bei RUP und V-Modell verwendet. User Stories Eine User Story („Benutzergeschichte“) ist dagegen eine in Alltagssprache formulierte Software-Anforderung. Sie ist bewusst kurz gehalten und umfasst in der Regel nicht mehr als zwei Sätze. Diese Art der Anforderungsbeschreibung stammt aus Scrum. User Stories werden in der agilen Softwareentwicklung zusammen mit Akzeptanztests zur Spezifikation von Anforderungen eingesetzt. Die Anwendungsfälle sind so zu beschreiben, dass sie in sich abgeschlossen sind und auch vom Endanwender verstanden werden. INVEST : Independent – Negotiable – Valuable – Estimatable – Small – Testable Das Akronym INVEST wird in diesem Zusammenhang oft angeführt und hilft bei der Erstellung der Stories. Independent – Unabhängig Jede User Story soll möglichst unabhängig und für sich abgeschlossen sein. Negotiable – Verhandelbar Der Inhalt der Story ist immer verhandelbar. Ist eine Story zum Beispiel zu groß, muss modifiziert werden können. Valuable – Nützlich Das Ergebnis ist für den immer etwas von sichtbarem Wert. Selbst Backlog-Einträge, wie das einrichten einer Testumgebung müssen einen erkennbaren Nutzen haben. Estimatable – Schätzbar Der Inhalt der Story muss vom Aufwand schätzbar sein. Dies bedeutet somit, dass das Team auch verstanden hat, was die Anforderungen sind. Diese müssen also klar und verständlich formuliert werden. Small – Klein Eine Story soll überschaubar und kurz gehalten werden. Auch komplexe Anforderungen werden nur skizzenhaft notiert. 14

Testable – Testbar Das Ergebnis muss testbar sein. Dazu müssen entsprechende Abnahmekriterien festgelegt werden. Eine einfache Vorlage hat sich für das erstellen der User Stories bewährt: Story: Der <user> möchte <Aktion>, um <Begründung>. ABNAHMEKRITERIEN: Verifiziere, dass - <Kriterium 1> - <Kriterium 2> - … Abbildung 5 Vorlage User Story Story: Der Handy-Benutzer wählt einen Telefonkontakt aus dem Adressbuch aus, um ihn anrufen zu können. Abnahmekriterien: Verifiziere, dass - das Adressbuch alphabetisch geordnet ist. - die Telefonnummer des ausgewählten Teilnehmers für den Anruf benutzt wird. Abbildung 6 Beispiel einer User Story Häufig werden die User Stories in einer Excel-Tabelle verwaltet. Diese Liste wird auch Product Backlog genannt. Auf den Product Backlog wird im folgenden Kapitel näher eingegangen. 15

Kapitel 3 Projektplanung Nur geplant kommt man erfolgreich ans Ziel Ohne Planung herrscht Chaos. Manche Menschen beherrschen das Chaos, wenn man jedoch im Team arbeitet, wird das ganze im wahrsten Sinne des Wortes planlos. quot;Der Gebildete treibt die Genauigkeit nicht weiter, als es der Natur der Sache entspricht.quot; - Aristoteles 17

Projektziele In einem Projekt gibt es mehrere Beteiligte, die Stakeholder. Jeder dieser Stakeholder vertritt andere Interessen. Der Kunde will möglichst viele seiner Ideen und Anforderungen so schnell wie möglich zu einem günstigen Preis umgesetzt haben. Der Projektleiter dagegen versucht möglichst alle seine Mitarbeiter auszulasten und ein System zu entwickeln, das im Budget liegt aber möglichst wenige Fehler hat und für die Zukunft gut dokumentiert ist. Der Entwickler wiederum möchte ein möglichst elegant programmiertes System liefern, das möglichst auch eine neue interessante Technologie nutzt. Man kann sicher auch noch Argumente für das Marketing und den Vertrieb oder auch den Betreiber finden. Jeder dieser Stakeholder zerrt an einem anderen Eck des Projektes. Abbildung 7 Stakeholdererwartungen (Schwalbe8) Im Wesentlichen kann man diese Ecken auf drei reduzieren. Es ist die Aufgabe des Projekt- managers diese Erwartungen auszubalancieren. 8 http://faculty.ksu.edu.sa/ghazy/CSC548%20PM/RC2_Triple_Constraint.pdf 18

Anforderungen – Welche Arbeit soll getan werden? Welche Anforderungen werden an das Produkt gestellt: Welche Features werden eingebaut? Wie viele Anwender benutzen die Anwendung gleichzeitig? Wie erhalten diese Anwender die Applikation auf ihrem Desktop (Rollout)? Wie werden Updates verteilt? Reaktionszeit der Anwendung. Zeit – Wie lange soll es gehen? Bei der Zeit sieht man vordergründig zunächst nur die Zeit, bis das Projekt fertig gestellt ist, doch Wann muss die Anwendung fertig gestellt sein? Wie groß ist das Team, das an dem Projekt arbeitet? Wann kann der Kunde die Anwendung testen und freigeben? Kosten – Was soll es kosten? Die Ressourcen (Mitarbeiter, Hardware, Lizenzen,…) resultieren in Kosten. Die Kosten sind einer der schwerwiegendsten Faktoren im Projektmanagement. Abgesehen von Open Source Projekten oder der anstehenden Projektarbeit müssen die Projekte durch einen sogenannten Sponsor (Kunde) finanziert werden. Da die Budgets aber fast immer limitiert sind, setzen die Kosten immer eine ziemlich harte Grenze. Projekt-Backlog Die User Stories werden im Product-Backlog gesammelt. Die Abnahmekriterien werden am Projektende für den Abnahmetest herangezogen. Abbildung 8: Beispiel eines Product Backlog 19

Priorisierung Die Reihenfolge der Stories gibt die Priorität vor. Die obersten Stories müssen zuerst umgesetzt werden. Je weiter man in der Liste nach unten kommt desto unwichtiger wird die Anforderung. Im Laufe des Projektes kann es dabei vorkommen, dass der Kunde erkennt, dass sich seine Prioritäten verschoben haben. Darüber muss dann verhandelt werden und die Reihenfolge gegebenenfalls im Product Backlog angepasst werden. Verändern sich Stories im Laufe des Projektes oder ergeben sich neue Erkenntnisse, so fließen diese auch immer wieder in den Product Backlog ein. Bei Projekten, die zum Festpreis angeboten werden, muss dann gegebenenfalls verhandelt werden, wie man mit den Mehraufwänden umgeht. Werden diese zusätzlich bezahlt, oder lässt man dafür eine andere Story weg? Status Der Status wird regelmäßig aktualisiert und die Restaufwände festgehalten. Alle 14 Tage schaut sich dazu das Projektteam den Product Backlog gemeinsam an und aktualisiert die Stati und den Restaufwand. Es gibt dabei die hart erscheinende Regel „done-DONE!“, die besagt, dass eine Story wirklich erst dann fertig ist, wenn sie durch den Kunden abgenommen wurde. Es gibt also im Status- bericht keine Arbeiten, die „zu 80% fertig“ sind! done DONE! Eine Story ist nur dann fertig, wenn wirklich alles erledigt ist: implementiert • dokumentiert • getestet • abgenommen • Abbildung 9 done-DONE! Regel 20

Kapitel 4 Projektsteuerung Ohne Steuerung kein erfolgreiches Ende Während des Verlaufes des Projektes muss immer wieder steuernd eingegriffen werden. Ähnlich wie bei einem Schiff, das eigentlich schnurgerade über das Meer fahren soll, muss man auch bei einem Projekt bei äußeren Einflüssen Korrekturen vornehmen. Fährt so z.B. das Schiff in eine Meeresströmung, muss der Kapitän gegensteuern, um auf Kurs zu bleiben. So muss auch im Projekt immer wieder auf unerwartete Einflüsse reagiert werden, um nicht vom Ziel abzukommen. 21

Projekt-Status In regelmäßigen Abständen wird der Projektstatus geprüft. So wird der Product Backlog in regelmäßigen Abständen im Team durchgegangen und die Stati werden aktualisiert. Burndown Diagramm Anhand des Aufwandes und des Zeitraums in dem dieser erledigt worden ist, ergibt sich eine „Velocity“, die in einer Zahl ausdrückt, wie viel das Team in dem Zeitraum geschafft hat. Velocity = Gesamtaufwand vor dem Zeitraum – Aktueller Restaufwand Diesen Wert kann man nun in ein Burndown-Diagramm eintragen und darauf basierend wiederum planen, was man im folgenden Zeitraum umsetzen möchte. Legt man nun noch eine Mittelwertskurve über die Werte, kann man relativ einfach erkennen, ob man in der Zeit liegt oder nicht. 1.000 800 600 400 200 00 29.4 13.5 Abbildung 10 Burndown Diagramm 22

Qualität Unter Qualität werden unterschiedliche Aspekte verstanden. Fragt man in der Software- entwicklung zum Beispiel einen Entwickler, versteht er unter Qualität Dinge, wie etwa über- sichtlichen und gut dokumentierten Quellcode. Der Architekt sieht in der Wiederverwendbarkeit der erstellten Module eine besondere Qualität und der Projektleiter sieht in möglichst schnell und günstig erstellten Systemen eine besondere Qualität. Wenn wir den Anwender des Systems fragen, so wird er sicherlich in der Stabilität, der Fehler- toleranz und der Bedienbarkeit seine Qualitätsansprüche messen. Der Sponsor, also der Auftraggeber des Systems, denkt dagegen eher an die Wartung und die Erweiterbarkeit der Anwendung. Man erkennt also, dass die Qualität ein breites Spektrum umfassen kann. Prinzipiell lässt sich das Spektrum in zwei Bereiche aufteilen. Der äußeren und der inneren Qualität. Abbildung 11 Quadrupel der Projektziele Die Qualität ist das vierte Ziel, um das man das Tripel der Projektziele erweitern kann. Durch die breiten Spektren, wie Qualität gesehen werden kann, beeinflusst sie auch die drei Grund- ziele Zeit, Anforderungen und Kosten. Äußere Qualität Die Äußere Qualität ist direkt oder indirekt nach außen sichtbar. Sie beinhaltet Aspekte, wie: Stabilität der Anwendung Stürzt die Anwendung immer wieder ab oder reagiert nicht mehr? Benutzerführung Verliert man sich in den Menüs oder wird der Anwender „an die Hand“ genommen? 23

Gibt es eine Onlinehilfe? Ist die Bedienung konsistent? Fehlertoleranz Werden Fehleingaben abgefangen bzw. durch klare Fehlermeldungen zurückgewiesen? Reaktionszeit Oftmals wird eine maximale Reaktionszeit vertraglich festgelegt. Ergonomie & Accessability Können auch Behinderte Anwender das System bedienen? Werden die Standards des Zielsystems (z.B. Shortcuts, Menüstrukturierung, etc.) beachtet? Innere Qualität Die innere Qualität bezieht sich auf die Architektur und die Programmierung der Anwendung. Dokumentation Metriken für Klassengrößen, Methodengrößen Testabdeckung Erweiterbarkeit Wartbarkeit Testen Um zu Prüfen, ob die Anforderungen korrekt umgesetzt wurden, muss getestet werden. Dies sichert die Qualität. Um nicht immer das gesamte Produkt testen zu müssen, werden Unit-Tests, die einzelne Module für sich testen definiert. In der Softwareentwicklung gibt es hierfür auch Bibliotheken, 9 die das Unit-Testen unterstützen. Zum Beispiel für Java JUnit . Damit kann man Tests programmieren, die man dann auch immer wieder während der Entwicklung ablaufen lassen kann, um zu prüfen, ob die Änderungen nichts kaputt gemacht haben. Das fertige Projekt wird aber auch immer über sogenannte System-Tests als ganzes noch einmal getestet. Häufig auch auf einem Referenz-System, das dem Zielsystem möglichst ähnlich oder sogar gleich ist. 9 http://junit.org 24

Kapitel 5 Projektarbeit konkret Konkrete Vorgaben zur Projektarbeit Die im Folgenden beschriebenen Artefakte werden im Zuge der Projektarbeit für den Projektmanagementanteil erwartet und fließt somit in die Bewertung der Arbeiten ein. 25

Dokumente Pflichtenheft Das Pflichtenheft wird in Form einer Excel-Tabelle als Product Backlog erstellt und aktualisiert. Eine entsprechende Vorlage wird dafür zur Verfügung gestellt. Eine Vorlage für das Burndown-Diagramm wird mit dem Product Backlog mitgeliefert. Dieser Product Backlog muss bis zum ersten Projektbericht erstellt und mit geliefert werden. Testprotokoll Im Product Backlog werden auch die Abnahmekriterien hinterlegt. Diese können somit einfach in ein Testprotokoll extrahiert werden. Ein Testprotokoll beinhaltet die Version die getestet wurde (Datum oder Build-Nummer), den verantwortlichen Tester und die Ergebnisse des Tests. Für jeden Test wird ein eigenes Protokoll angefertigt. Diese Tests müssen nach erreichen von wichtigen Projektmeilensteinen durchgeführt werden. Systemdokumentation Die Systemdokumentation beschreibt die Anwendung aus technischer Sicht. Hier fließen UML-Diagramme ein, die komplexere Zusammenhänge beschreiben. Zur System- dokumentation kann auch eine Beschreibung zur Installation der Anwendung gehören. Bei Hardware-Projekten werden hier auch die Schaltpläne und Bauteile beschrieben. Die Systemdokumentation wird am Projektende mit abgegeben. Anwenderdokumentation Die Anwenderdokumentation ist im Gegensatz dazu ein Handbuch für den Benutzer des Systems, das beschreibt, wie die Anwendung zu verwenden ist. Dazu werden die einzelnen Funktionen aufgeführt und beschreiben. Die Systemdokumentation wird am Projektende mit abgegeben. Quellcode-Dokumentation Für die innere Qualität ist es wichtig, dass auch die Klassen und Methoden des Projektes dokumentiert werden. Nur so kann im Team an einem Projekt effektiv gearbeitet werden. Es macht jedoch keinen Sinn diese Dokumentation auszudrucken. Sie bleibt im Quellcode und kann mit Tools gegebenenfalls extrahiert werden (JavaDoc). Diese Dokumentation wird bei den Projektreviews immer wieder geprüft. 26

Projektberichte Im Turnus von 14 Tagen werden die Projekt-Coaches der Sybit die Teams zu den Projektreviews besuchen. Dazu müssen die Projektteams jeweils bis zum vorangehenden Donnerstag um 17.00 Uhr ihre Projektberichte liefern. Dieser wird per Email an den zuständigen Lehrer und den Sybit- Projektcoach gesendet. Folgende Inhalte werden in diesen Berichten erwartet: Was haben wir seit dem letzten Bericht gemacht? Was haben wir vor nun zu machen? Wo haben wir Probleme? Product Backlog mit akualisierten Stati und Burndown-Diagramm als Attachment (Done- DONE!-Regel!) So können sich die Coaches auf das Treffen vorbereiten und das Projektteam erkennt selbst den Stand ihrer Projektarbeit Projekt-Coachs Software-Projekte Dorothea Singler, Dorothea.Singler@sybit.de Stephan Strittmatter, Stephan.Strittmatter@sybit.de Hardware-Projekte Manuel Veysseyre, Manuel.Veysseyre@sybit.de 27

Kapitel 6 Appendix Zum Projektmanagement in Softwareprojekten Im Folgenden sind weiterführende Informationen zum Thema Projektmanagement aufgeführt. Dieses Handout basiert teilweise auf diesen Quellen. 29

Bücher Endlich im grünen Bereich Autor: Roman Heimbold Verlag: mitp ISBN: 3-8266-1547-6 eBook: http://www.mitp.de/imperia/md/content/vmi/1547/1547-forfree.pdf Introduction to Project Management Autor: Kathy Schwalbe Verlag: Course Technology ISBN-13: 978-1423902201 Project Management. The Complete Guide for Every Manager Autor: Clifford F. Gray, Erik W. Larson Verlag: Mcgraw-Hill Professional ISBN-13: 978-0071376013 Scrum - Agiles Projektmanagement erfolgreich einsetzen Autor: Roman Pichler Verlag: dpunkt.verlag ISBN-13: 978-3898644785 Internet Wikipedia http://de.wikipedia.org Scrum Master http://Scrum-master.de/ Scrum Alliance http://www.Scrumalliance.org/ The Triple Constraint of Project http://faculty.ksu.edu.sa/ghazy/CSC548%20PM/RC2_Triple_Constraint.pdf JUnit http://junit.org JUnit 4 Tutorial (deutsch) http://www.mm.informatik.tu-darmstadt.de/courses/helpdesk/junit4.pdf 30

Sponsor Sybit GmbH Die Firma Sybit in Radolfzell ist ein Softwarehaus, das sich mit den rund 90 Mitarbeitern auf drei Geschäftsbereiche fokussiert hat: SAP Customer Relation Management Contentmanagement Systeme und Medienportale Industrielle Lösungen und Dienstleistungen Die Sybit GmbH unterstützt die Projektarbeiten des TGI Singen durch eine Projektmanagement Schulung. Hierfür wurde neben einer Präsentation auch dieses Handout erstellt. Weiterhin werden erfahrene Projektleiter die Projektarbeiten während ihrer Laufzeit begleiten und lassen ihre Erfahrungen einfließen. Die Schüler bekommen so durch mehr Nähe zur Praxis einen tiefer gehenden Einblick in die Entstehung und Abwicklung von IT-Projekten. Sybit bildet aus Derzeit bildet Sybit 9 Auszubildende und einige Diplomanten und Bachalors aus. Zusätzlich werden auch Praktikanten Plätze für ihre Praxissemester geboten. Folgende Ausbildungsmöglichkeiten werden derzeit geboten: Fachinformatiker(in) Industriekauffrau/-mann Kauffrau/-mann für Marketingkommunikation BA-Studium für Informationstechnik und Wirtschaftsinformatik Weitere Informationen Webseite http://www.sybit.de Anfragen und Bewerbungen: jobs@sybit.de 31

Projektmanagement - Handout 1 0

by Sybit GmbH

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

Projektmanagement - Handout 1 0 Document Transcript