Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Panel
titleColorwhite
titleBGColor#205081
titleInhalt

Table of Contents



Panel
titleColorwhite
titleBGColor#205081
titleVerweise


Status
colourRed
titleStatus


Ein Plädoyer für Kanban

Bei einem Softwareprojekt spielen die folgenden Aktivitäten eine große Rolle:

  • Ressourcen: Wie viele Entwicklerinnen und Entwickler stelle ich dem Projekt zu Verfügung. Das ist zugleich der größte Kostenfaktor.
  • Zeit: Wie lange gibt der Kunde uns Zeit die Software auszuliefern.
  • Funktionsumfang: Wie viel User-Stories sollten umgesetzt werden.
  • Qualität. Welche Qualitätsansprüche habe wir - oder
das
  • der Kunde - an die Software.

Die meisten dieser Aktivitäten sind durch die Prüfungsordnung vorgegeben (siehe Verordnung über die Berufsausbildung im Bereich der Informations- und Telekommunikationstechnik. Ein Service des Bundesministeriums der Justiz und für Verbraucherschutz in Zusammenarbeit mit der juris GmbH: www.juris.de auf die sich auch Seitenangaben beziehen):

  • Das Projekt darf in der Fachrichtung Anwendungsentwicklung höchstens 70 Stunden betragen (Seite 10). Also fester Zeitaufwand.
  • Dem Prüfungsausschuss ist vor der Durchführung der Projektarbeit das zu realisierende Konzept einschließlich der Zeitplanung sowie der Hilfsmittel zur Präsentation zur Genehmigung vorzulegen. (Seite 10ff). Aus einem "zu realisierenden Konzept" ergibt sich nicht zwingend der gesamte Funktionsumfang, jedoch die Richtung des Projektes.

  • Durch die eidesstattlicher Erklärung gibt der Prüfling an das Projekt alleine bearbeitet zu haben. Also feste Ressourcen.

Aus der gängigen Software-Praxis wissen wir, dass selbst ein erfahrenes Software-Team einen Task, der 8 Stunden benötigt nicht genau schätzen kann. 

Behauptung 1: Eine 70 Stunden Projektarbeit ist nicht schätzbar. Die Praxis zeigt, dass mit hoher Wahrscheinlichkeit eher 140 - 280 Stunden für die Arbeit benötigt werden. Gerade bei kleinen Projekten hat eine Verzögerung dramatische Auswirkungen.

Behauptung 2: Qualität darf nicht verhandelbar sein.

Wenn jedoch die Schätzung immer falsch ist, muss doch die Frage erlaubt sein, wo genau man variabel sein darf:

  • Zusätzliche Ressourcen dürfen nicht hinzugezogen werden.
  • Zusätzliche Zeit darf auch nicht in Anspruch genommen werden.
Damit kommen wir zu einem Axiom: Der einzige Faktor, der bei einer Abschlussprüfung variabel ist, ist der Funktionsumfang.

Das Wasserfallmodell - selbst mit Rücksprung - erlaubt nicht während der Implementierung-Phase und der Testphase den Funktionsumfang zu verkleinern. Ist das Lastenheft geschrieben, kann nur noch während der Pflichtenheft-Phase der Funktionsumfang geändert werden, rück gesprungen werden. Mit Beginn der Implementierung ist der Funktionsumfang fest. Das Wasserfallmodell ist fast das einzige Vorgehensmodell, welches es verbietet. Deshalb muss der Prüfling zwingend ein Vorgehensmodell wählen. bei der der Funktionsumfang während des Projektes änderbar ist. Dieses ist nach heutigem Kenntnisstand bedingt im Spiral-Modell möglich, oder eben in einem agilen Vorgehensmodell.

Tatsächlich ist der Funktionsumfang auch fast das einzige, was nach der Prüfungsordnung variabel ist: "Durch die Projektarbeit und deren Dokumentation soll der Prüfling belegen, dass er Arbeitsabläufe und Teilaufgaben zielorientiert unter Beachtung wirtschaftlicher, technischer, organisatorischer und zeitlicher Vorgaben selbständig planen und kundengerecht umsetzen sowie Dokumentationen kundengerecht anfertigen, zusammenstellen und modifizieren kann." (Seite 10)

Streng genommen kann eine Prüfung nicht mehr mit sehr gut bewertet werden, wenn das falsche Vorgehensmodell gewählt wird. Und wie oben gesehen ist das Wasserfallmodell eins der wenigen Modelle, bei der der Funktionsumfang nicht mehr gekürzt werden kann und damit vollständig unbrauchbar für eine Projektarbeit ist, im Rahmen der Abschlussprüfung.

Die Frage ist nun: Was ist denn ein geeignetes Modell? Von den verschiedenen agilen Modellen erscheint mir Kanban das geeignete.

  • Kanban arbeitet in Iterationen.
  • Jede Iteration arbeitet ein Feature ab inkl. Tests
  • Im PAO kann man die "must haves " Userstories beschreiben.
  • Außerdem kann es noch "nice to haves" haben.
  • Ich kann während des Projekts Stories umpriorisieren
  • Ich habe nach jeder Iteration ein "fertiges" Stück Software
  • Kanban ist nahe an der Softwarerealität.