Project Management Foliennotizen

Dies sind die Notizen zu dem Einführungsfoliensatz Projektmanagement. Unstimmigkeiten und Fehler sind möglich.

Project Management

Erinnerung Agile Manifest Tipps für ein erfolgreiches SEP Projekt

Ziel des Project-Management-Kickoffs ist es euch noch einmal an das Agile Manifest zu erinnern & euch Tipps mitzugeben, die euch ermöglichen, euer Projekt im SEP erfolgreich durchzuführen, d.h. euer Projekt zu planen, zu steuern, zu kontrollieren und auch abzuschließen.

Außerdem soll es euch dazu befähigen das PM-Dokument als erstes Artefakt für das SEP zu erstellen, welches ihr auch teilweise beim folgenden Artefakt für das Spezifikationsdokument benutzen werdet.

„Teile deine Erfahrungen“: Ich weiß viel über Project Management Ich habe schon oft in agilen Projekten gearbeitet Ich weiß schon, wie wir das Project Management in unsere SEP-team machen

Wie Wird Gearbeitet?

Ein Projekt zeichnet sich u.a. dadurch aus, dass es die Summe von einzelnen Prozessen auf ein bestimmtes Ziel hin ist. Anders ausgedrückt geht es dabei um die Frage wie genau die Arbeit getan wird. Die genaue Ausgestaltung wird mehr oder weniger konkret in Prozessen definiert und in der Software Entwicklung gibt es dafür verschiedene etablierte Techniken.

Sicherlich habt ihr schon einmal etwas von den traditionellen Modellen, wie dem Wasserfallmodell gehört. In den letzten Jahren sind alternative Modelle, wie agile, immer populärer geworden. Daher befassen sich auch ganze Konferenzen über das Thema und man hört von Firmen, die ihre Prozessmodelle umstellen, um ebenfalls agil zu werden.

Ein wichtiger Aspekt dieser Prozesse ist, dass sie sich nicht nur darauf konzentrieren sollen wie ihr als Team eure Arbeit erledigt, sondern auch den Kunden aktiv beachtet. Dadurch werden auch Fragen geklärt wann und wie arbeitet ihr mit dem Kunden zusammen, weil dieser am Ende entscheidend für euren Projekterfolg ist. Daher sollte er ihm auch früh und regelmäßig die notwendige Beachtung schenken.

Teamleistung

Agile Manifesto

Das agile Manifest wurde 2001 während einem Treffen von Softwareentwicklern erstellt, als sich diese die Frage stellten: Wie können wir verhindern, dass unsere Projekte ins Leere laufen, weil die Zeit zwischen den Kundenwünschen und unserer Bereitstellung zu lange ist? Am Ende des Treffen haben jene Entwickler vier Werte identifiziert, die als das agile Manifest bekannt wurden. Diese vier Werte sollen helfen bessere Software zu entwickeln.

Es sind aber nur Werte, keine strikten Gesetze.

Individuen und Interaktion

Der erste Wert hinterfragt das Team selbst – also die Menschen, die die eigentliche Arbeit durchführen, d.h. euch. Im agilen Manifest ist definiert, dass die einzelnen Personen und ihre Interaktionen höher eingeschätzt werden als Prozesse und Werkzeuge. D.h. es ist wichtiger wie ihr im Team zusammen arbeitet und agiert als das neuste und hippste Projektmanagement-Tool zu benutzen. Es sollte nicht der Sinn sein, dass ihr ohne Prozesse und Werkzeuge arbeitet.

Funktionierende Software

Der zweite Wert spiegelt die Frage ab: Was ist für den Kunden am Ende wertvoller? Eine ausführliche Dokumentation oder funktionsfähige Software?

Am Ende ist eine neue Software auch ein Risiko für den Kunden und daher sollte das Ziel sein die Software möglichst stabil und gut zu entwickeln anstatt im Voraus jede Designentscheidung usw. aufwendig zu dokumentieren. Das bedeutet nicht, dass im agil gar keine Dokumentation vorhanden ist, sondern, dass funktionierende Software wichtiger ist und lediglich die Dokumentation vorhanden sein soll die notwendig ist für die Arbeit. In diesen Punkt fließt bereits das Anforderungsmanagement mit rein, welches wir auch im Spezifikationsdokument-Kick-Off noch genauer anschauen werden.

Da es jedoch schon jetzt von großer Bedeutung für euch ist, vier Fragen auf die ihr bald eine Antwort haben solltet:

Zusammenarbeit mit dem Kunden

Der dritte Wert des agilen Manifests knüpft etwas an die letzte Frage zu den Änderungen an, die ich euch gestellt hat. Es geht darum, dass es für euren Projekterfolg wichtiger ist mit dem Kunden zusammenzuarbeiten, als bei jeder Unstimmigkeit über die Vertragsdetails zu diskutieren. Ein anderer wichtiger Aspekt dieses Wertes ist, dass der Kunde von Beginn des Projektes mit in die Produktentwicklung integriert werden soll. Dadurch sollen auch die Feedbackschleifen zu eurem Produkt verkürzt werden und am Ende die Wahrscheinlichkeit auf einen erfolgreichen Projektabschluss gesteigert werden.

Reagieren auf Veränderungen

Der vierte und letzte Wert ist, dass die Reaktion auf Änderungen wichtiger ist als dem Plan zu folgen. Ihr erarbeitet zwar am Anfang einen Plan mit dem Kunden über das Produkt, aber vor allem bei neuen Entwicklungen und Ideen kann es schnell passieren, dass sich die Anforderungen ändern. Daher ist ein Beharren auf den Plan kontraproduktiv für das erfolgreiche Produkt am Ende. Aus dem Grund sollen Möglichkeiten geschaffen werden flexibel und möglichst schnell auf Änderungen zu reagieren.

Mögliche Änderungen können sein, dass sich die Situation bei euch oder den Kunden durch Urlaub, Klausuren, der Weihnachtspause oder Deadlines ändert und sich dadurch beispielsweise die Verfügbarkeit ändern. Es kann auch sein, dass sich sogar die Vision des Kunden ändert durch neues Wissen, neue Ideen, neue Gesetze, neue Technologien usw. Dies ist im SEP/BP aber eher selten.

Empfehlungen für euer Projekt

Nachdem wir jetzt das Thema agile abgeschlossen habe, möchte ich euch ein paar Vorschläge mit an die Hand geben, damit ihr hoffentlich leichter das Projekt erfolgreich zu Ende bringt.

Analyse und Design

Auch im agilen ist es unvermeidlich, dass ihr das Endprodukt versteht und euch Gedanken über das Design eurer Anwendung macht. Für das Design der Software gibt es standardisierte Modelle und die meisten haben gemein, dass sie die Komplexität grafisch darstellen. Daher traut euch und malt Bilder und teilt sie auch mit dem Kunden. Häufig hilft euch das, weil ihr so a) für euch selbst reflektieren könnt, ob eure Idee sinnvoll ist und b) ein gemeinsames Verständnis mit dem Kunden erleichtert. Nutzt also ein Whiteboard oder auch gerne ein digitales Board.

Konfigurationsmanagement

In einem Projekt fallen viele Daten an und nichts kann nerviger sein, als nicht an die Daten zu gelangen, die ihr benötigt oder über alte Daten zu stolpern. Daher: Managt alle – wirklich alle – eure Daten. Alle Daten bedeutet, dass ihr nicht nur euren Source Code, sondern auch die Dokumente, die ihr vom Kunden erhaltet, mit ihm teilt usw. managt. Genauso wie die Folien die ihr für Präsentation erstellt, die Meeting Minutes eurer Meetings, die Anforderungen, die ihr in eure Software umsetzt usw. Verwendet dafür die Tools, die am Einfachsten für euch und den Kunden funktionieren, sei es ein Git, Gitlab, ein Wiki, Google Docs, Redmine, GitHub Issues oder ein ganz anderes Tool.

Entwicklung

Am Ende des Tages werdet ihr die meiste Zeit mit der Entwicklung verwenden. Es liegt in der Natur der Sache, dass jeder und jede von euch ihren eigenen Erfahrungsschatz hat. Daher nutzt dieses Wissen und die Diversität in eurem Team: Fragt nach Feedback, teilt Wissen oder erarbeitet zusammen neue Funktionalitäten. Ihr könnt sogar probieren, ob das Konzept des Mob Programming für euch funktioniert. Sowohl beim Mob Programming als auch beim Pair Programming ist es nicht das Ziel, dass ihr das für jedes Problem, wie schreibe ein Hello World anwendet, sondern es bei komplexeren Problemen ausprobiert und anschließend auch evaluiert, um es ggf. erneut anzuwenden. Pair Programming kann beispielweise auch gut für Wissensübergabe sein.

Qualitätssicherung

Zur Entwicklung gehört auch die Qualitätssicherung und daher fangt jetzt schon an damit. Macht euch auch jetzt schon Gedanken über eure Qualitätssicherung – auch wenn das entsprechende Kick-Off erst später kommt. Denn am Ende des Tages bringt euch eine qualitativ minderwertige Software für einen erfolgreichen Projektabschluss wenig. Zur Qualitätssicherung gehört beispielsweise, dass euer Programm nicht voll mit Typos ist oder ganz offensichtliche Bugs enthält und auch, dass ihr das dem Kunden liefert, was er wollte. Ein weiterer wichtiger Punkt ist, dass ihr auch pünktlich eure Produkte abliefert. Der Punkt zählt übrigens nicht nur für eure Zusammenarbeit mit dem Kunden, sondern auch für eure Abgaben bei uns. ;) Kommuniziert rechtzeitig, wenn ihr bemerkt, dass es zu Verschiebungen oder Verspätungen kommt!

Code Reviews

In code schleichen sich gerne Flüchtigkeitsfehler ein, die dadurch verhindert werden können, dass eine zweite Person über den Code drüber schaut. Als Teil des Code Review Prozesses ist es erforderlich das sichergestellt wird, dass jeder neue Code von mindestens einer zweiten Person geprüft wird.

Darüber hinaus helfen Code Reviews wissen innerhalb des Teams zu verteilen, indem Verständnisfragen gestellt und beantwortet werden.

Continuos Integration

Nutzt Continuos Integration, um automatisiert eure Codeänderungen zu integrieren und z.B. zu kontrollieren, ob eure Anwendung noch baut und alle Tests noch funktionieren. CI wird als best practice angesehen.

Daher automatisiert euren Build-Prozess, mit Maven, Gradle, usw. Automatisiert eure Tests, mit Testframeworks, wie xUnit, Selenium, jMock usw. Integrate your changes, z.B. mit Jeniks, Bitbucket Pipelines, GitHub actions usw.

Risiko Management

Ein anderer wichtiger Punkt ist, dass ihr eure Risiken kennt und entsprechend für ausgewählte Risiken versuchen könnt diese zu vermeiden. Welche Risiken habt ihr? Braucht ihr beispielsweise bestimmte Hardware? Wie wahrscheinlich ist das Risiko? Wie wahrscheinlich ist es, dass jemand von euch ausfällt? Gering oder hoch? Wie sind die Auswirkungen, wenn das Risiko eintritt? Gering oder hoch? Welche Maßnahmen könnt ihr Treffen, um das Risiko zu umgehen? Was macht ihr, wenn euer Kunde nicht verfügbar ist?

Team Leistung

Wir haben schon mehrfach das Thema gehabt, dass das Ziel ein gutes Produkt für den Kunden ist, dass seiner Vision entspricht. Doch wie stellt ihr sicher, dass ihr das auch schafft? Dafür ist es wichtig den eigenen Fortschritt zu messen. Daher: Findet einen Weg eure Performance zu messen. Sammelt die dafür erforderlichen Daten, seien es Stunden, Story Points oder eine ganz andere Metrik. Vor allem: Evaluiert regelmäßig und nehmt ggf. Anpassungen vor, sowohl im Prozess der Messung und Erfassung als auch bei der Kommunikation über euren Projektfortschritt.

Zeiterfassung ist nicht optional!

Take Home

Nach der kurzen Einführung in agile, sieben Tipps für euer Projektmanagement im SEP, hier noch einmal sechs wichtige Punkte, damit ihr hoffentlich ein erfolgreiches Projekt abschließt und gute Erfahrungen sammelt.