Zum Hauptinhalt springen

Agiles Projektmanagement

Handlungsziel​

  1. Erfasst und verwaltet die Anforderungen und Umsetzungsschritte nachvollziehbar fĂŒr die Entwicklung im Team.
    1. Kennt den Nutzen bezĂŒglich kontinuierlicher toolunterstĂŒtzter Entwicklung und Wartung (z.B. MVP, Kundenfeedback, Kosten/Nutzen, QualitĂ€t, -Risikoreduktion).
    2. Kennt Vorgehensweisen zur Verwaltung von Anforderungen (z.B. Storys, Issues, Akzeptanzkriterien etc.).
    3. Kennt Vorgehensweisen zur nachvollziehbaren Entwicklung im Team (z.B. VerknĂŒpfung Commit mit Story, Pull Request/Peer-Review).

Projektdefinition​

Vorhaben, das im Wesentlichen durch die Einmaligkeit aber auch Konstante der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z.B. Zielvorgabe, zeitliche, finanzielle, personelle und andere Begrenzungen; Abgrenzung gegenĂŒber anderen Vorhaben; projektspezifische Organisation.

-- DIN 69901

Agiles Manifest​

Wir erschliessen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese TÀtigkeit haben wir diese Werte zu schÀtzen gelernt:

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge.
  • Funktionierende Software mehr als umfassende Dokumentation.
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung.
  • Reagieren auf VerĂ€nderung mehr als das Befolgen eines Plans.

Das heisst, obwohl wir die Werte auf der rechten Seite wichtig finden, schÀtzen wir die Werte auf der linken Seite höher ein.

-- agilemanifesto

Das Vorgehensmodell Kanban​

Im agilen Projektmanagement haben sich die Vorgehensmodelle SCRUM und Kanban durchgesetzt. Beiden Modelle verwenden eine iterative Vorgehensweise. Anders als in klassischen Vorgehensmodelle wie dem Wasserfall-Model werden die Arbeitspakete fortwÀhrend erstellt und angepasst.

Wo SCRUM einer klar definiertem Struktur mit vordefinierten Zeremonien folgt (Daily, Refinement, Review, Retrospektive) ist Kanban einfacher/flexibler gehalten.

In Kanban werden die Arbeitspakete in verschiedene Status eingeteilt. StandardmÀssig heissen diese:

  • To do: Arbeitspakete, welche bereits definiert wurden, jedoch noch nicht bearbeitet werden
  • In Process: Arbeitspakete, welche momentan gerade bearbeitet werden
    • immer nur 1 Arbeitspaket pro Person
  • Done: Arbeitspakete welche erfolgreich umgesetzt wurden
  • Waiting: FĂŒr Arbeitspakete, welche "In Process" sind, jedoch auf externe EinflĂŒsse gewartet wird darf ein optionaler Status Waiting eingefĂŒhrt werden. (z.B. Warten auf eine Unterschrift, Infrastruktur usw.)

Da das Modul 324 nicht Projektmanagement im Fokus hat, werden wir fĂŒr das Projekt Kanban verwenden.

Protip

Kanban eignet sich auch fĂŒr kleine Privatprojekte, oder sogar zum Planen vom eigenen Tagesablauf.

Einfaches GitHub Kanban Board​

Kanban-Board

  1. Mit Add item können direkt neue Arbeitspakete (Issues) erstellt werden.
  2. Mit dem rechten + können neue Status hinzugefĂŒgt werden (z.B. Waiting).
  3. Die Arbeitspakete 3 und 4 wurden noch nicht begonnen.
  4. Das Arbeitspaket 2 ist begonnen und es wurde eine Person zugeteilt.
  5. Das Arbeitspaket 1 wurde bereits fertiggestellt.

Arbeitspakete (GitHub Issues)​

Die Arbeitspakete beschreiben die Aufgaben, welche erledigt werden mĂŒssen, um das Projekt erfolgreich umzusetzen.

Sie werden je nach Software und Vorgehensmodell auch Issues, Stories, Cards, Tickets usw. genannt und:

  • mĂŒssen eine klare "Definition of Done" (Akzeptanzkriterien) besitzen.
  • dĂŒrfen nur eine Aufgabe beschreiben.
    • Ein "und" im Titel ist ein Hinweis darauf, dass ein Arbeitspaket aufgesplittet werden sollte.
  • mĂŒssen auf den Code verweisen (Branch, Pull-Request), welcher die Beschreibung implementiert.
    • NatĂŒrlich geht dies erst wenn das Paket "In Progress" ist und es sich durch Code lösen lĂ€sst.
  • mĂŒssen vorhandene AbhĂ€ngigkeiten aufzeigen.
    • Es gibt auch Arbeitspakete die isoliert, also unabhĂ€ngig implementiert werden können.

Definition of Done (Akzeptanzkriterien)​

Die Akzeptanzkriterien geben vor, wie geprĂŒft werden kann, ob das Arbeitspaket korrekt umgesetzt wurde. GrundsĂ€tzlich kann zwischen zwei Arbeitspaket-Typen unterschieden werden, formelle TĂ€tigkeiten und programmierbare FunktionalitĂ€ten.

1. Administrativen TĂ€tigkeiten​

Definieren der erwarteten Artefakte** (z.B. GUI Skizzen, Dokumente usw.) und wo diese gefunden werden können:

  • Beschaffung von Infrastruktur
  • Beschaffung von Lizenzen
  • Meetings mit Kunden
  • Ausarbeiten der Arbeitspakete
  • ...

2. Programmierbare FunktionalitĂ€ten​

Definieren der erwarteten FunktionalitÀt, wo sie gefunden und getestet werden kann:

  • Jegliche Software FunktionalitĂ€t die umgesetzt werden soll
  • DevOps Automatisierungen
  • Infrastruktur as Code
  • Alles was in Code resultiert
  • ...
wichtig

Ein Arbeitspaket ist erst dann "Done" wenn die Akzeptanzkriterien auf dem Testsystem erfolgreich durchgefĂŒhrt wurden.

Schnelles Kundenfeedback

Wenn das Projekt im DevOps Model mit einer CI/CD Pipeline umgesetzt wird, können die abgeschlossenen Arbeitspakete direkt im Testsystem ĂŒberprĂŒft werden, da neue Funktionen (Features) automatisiert online gestellt (deployed) werden.

  • Optimalerweise kann dies direkt vom Kunde ĂŒbernommen werden.
Automatisierte Integrations-Tests

Automatisierter Integrations Test durch ein Testing Framework wie Puperteer, Playwright, Selenium spart Zeit und garantiert das Funktionieren auf Zeit

  • Geht nur fĂŒr Web-Applikationen
  • Vergleichbar mit einem Suchmaschinen-Bot

Eine klare Aufgabe pro Arbeitspaket​

Jede komplexe Aufgabe besteht aus vielen einfacheren Unteraufgaben. Dabei gibt es hÀufig Unteraufgaben, die schneller und solche die weniger schnell gelöst werden können.

Wenn nun eine komplexe Aufgabe in einem Arbeitspaket beschreiben wird, werden diese meistens sowieso im Arbeitspaket nacheinander gelöst. Dies fĂŒhrt dazu, dass Teilbereiche der Aufgabe bereits fertiggestellt sind, jedoch noch nicht abgeschlossen werden können, da sie von der komplexeren Aufgabe blockiert werden.

Vorteil von kleinen Arbeitspakete​

  • Sie sind schneller gelöst
  • Es gibt ein ErfolgsgefĂŒhl ein Arbeitspaket abschiessen zu können
  • Die Motivation steigt das Arbeitspaket ĂŒberhaupt anzufangen
  • Es verhindert Knotenrisiko ("Eigentlich sind wir ja fertig, wenn nur XY funktionieren wĂŒrde")
  • Garantiert schnelles Feedback vom Kunden
    • erhöht die Kundenzufriedenheit
    • vermeidet, löst MissverstĂ€ndnisse frĂŒhzeitig
  • Macht die Gedanken frei um sich auf etwas zu konzentrieren
  • Wenn bereits beim Erstellen der Arbeitspakete ĂŒberlegt wird, ob man dieses noch mehr unterteilen kann, setzt man sich schon frĂŒh mit der FunktionalitĂ€t auseinander. Dies fĂŒhrt dazu, dass eventuelle Probleme schon frĂŒher erkennbar werden.
important
  • NatĂŒrlich darf man im agilen Projektmanagement ein Arbeitspaket auch noch im Nachhinein splitten! 😅

Verweist auf den Code​

Handelt es sich bei einem Arbeitspaket um eine programmierbare FunktionalitÀt, muss das Arbeitspaket auf den Code verweisen, welches es umsetzt.

Dies wird in diesem Modul durch die Versionskontrolle Git in Kombination mit der Plattform GitHub ermöglicht.

NatĂŒrlich muss die Verweisung erst angefĂŒgt werden, sobald das Arbeitspaket umgesetzt wird und in den Status "In Progress" gesetzt wurde.

Verweist auf AbhĂ€ngigkeiten​

Ist ein Arbeitspaket abhĂ€ngig von anderen Arbeitspaketen, muss diese AbhĂ€ngigkeit klar ersichtlich sein. DafĂŒr wird am Anfang der Beschreibung eine Liste erstellt, welche auf Arbeitspakete verweist, welche davor gemacht werden mĂŒssen.

In GitHub Markdown sieht eine Liste folgendermassen aus:

# AbhÀngigkeiten

- [x] #1
- [ ] #2

# Beschreibung

Die genaue Beschreibung...
  • #1 ist die Nummer des GitHub Issues und wird automatisch von GitHub aufgelöst

GitHub Issues: Verweisung auf Code und AbhĂ€ngigkeiten in​

Referenzen

  1. Das Arbeitspaket 2 ist "In Progress"
  2. Es hat AbhÀngigkeiten, wobei eine noch aussteht
  3. Es zeigt auf den "Pull Request", also den Code welche zur Implementation benötigt wird.

Kosten / Nutzen der agilen Vorgehensweise​

Bei der agilen Vorgehensweise mit dem DevOps Model, entstehen traditionellerweise am Anfang höhere Kosten, da alle Entwicklungsumgebungen, das Testsystem, die CI/CD Pipelines usw. aufgebaut werden mĂŒssen. WĂ€hrend des Projektes sinken die Kosten fĂŒr gewöhnlich.

Vorteile der Agilen Vorgehensweise​

  • MissverstĂ€ndnisse werden frĂŒh gefunden durch schnelles Kundenfeedback
  • Es existiert von Anfang an ein FunktionsfĂ€higes System
  • FĂŒr alle klarer Entwicklungsstand (Keine Katze im Sack, works-on-my-machine wird ausgehebelt)
  • Das Risiko wird minimiert, da der Kunde frĂŒhzeitig einschreiten kann, wenn was nicht stimmt.
  • Teure Nachbesserungsarbeiten, werden vermieden
  • Die administrativen TĂ€tigkeiten werden gesenkt, da weniger ĂŒber das Einhalten von VertrĂ€gen (Pflichtenheft) verhandelt werden muss
  • Eine FunktionalitĂ€t wird meistens erst klar, wenn man sie umsetzt. Die "hands-on" MentalitĂ€t fĂŒhrt dazu, dass schnell umgesetzt wird und somit schneller klar ist, was der Kunde genau will und wie es am besten umsetzbar ist.

Kundenfeedback​

🧰 Tools​