„Unterhalb von 20 Entwicklern machen große Projekte keinen Sinn“

Click here for the English version

Auch in Zeiten der Agilität ist kann auf Projektmanagement nicht verzichtet werden. Obwohl -oder gerade weil – ich immer wieder mit so bescheuerten Kommentare konfrontiert werde, wie z.B:

„Wieso gibt es hier einen Projektleiter? Ich dacht Sie machen SCRUM.“

– Kandidat für eine Entwicklerposition –

„Warum können Sie die gewünschte Änderung nicht noch in Release XY einfließen lassen – mir wurde erzählt, wir wären agil.“

– Manager –

Trotz aller falsch verstandener Agilität sollte man sich klarmachen, ob und wie das angestrebte Software-Entwicklungs-Projekt überhaupt Sinn macht. Meine steile These ist, dass die wenigsten Organisationen dies tun, sondern Projekte lediglich „politisch“ absegnen und ein Budget definieren.

Bevor die eigentliche -agile oder nicht-agile- Entwicklung gestartet werden kann, muss im Rahmen des Anforderungsmanagements zunächst das minimal funktionsfähiges Produkt (English: MVP, „Minimum Viable Product“) werden. Dieses umfasst die unbedingt erforderlichen Basisfunktionen eines Produkts, ohne die ein Go Live „vor Kunde“ keinen Sinn macht.

Weiterhin erfüllt das MVP noch zwei weitere Anforderung, denen nicht immer die notwendige Aufmerksamkeit gewidmet wird:

  1. Das MVP muss sich innerhalb eines Zeitfensters realisieren lassen, in dem zu erwarten ist, dass sich die Anforderungen an das MVP nicht in dem Maße ändern, dass sie durch die agile Vorgehensweise nicht mehr abgefangen werden können. Dieses Zeitfenster bezeichne ich als die MVP -Durability (MVPD)
  2. Das MVP muss alle Technologie- und Architekturkritischen Fragen positiv beantworten. Auch die Fragen, die mit Funktionalität verbunden sind, die nicht Bestandteil des MVP, aber bereits jetzt absehbar sind. Mit anderen Worten: Das MVP enthält auch einen Proof-of-Concept für den Einsatz der gewählten Technologie oder Architektur.

Das o.g. MVPD ist natürlich abhängig von externen Faktoren, die z.B. das sog. Markteinführungsfenster“ („Launch Window“) Das MVPD ist kleiner oder höchstens gleich dem Markteinführungsfenster.

MVPD und Launch Window werden durch eine Vielzahl von Einflussfaktoren bestimmt, die spezifisch für die jeweilige Organisation und ihr Marktumfeld sind.

Sind MVP, MVPD und Launch-Window definiert, muss „nur“ noch ermittelt werden, ob sich das MVP in Abhängigkeit der folgenden Faktoren in dem angepeilten MVPD realisieren lässt:

  1. Software und Hardware Technologien: Welche Technologien stehen mir zur Erestellung dfes MVP zur Verfügung?
  2. Vorgehensweisen bei der Entwicklung: Nach welcher Methodik soll entwickelt werden?
  3. Parallelisierbarkeit: Auf wieviele Entwickler kann ich die Implementierung aufteilen, um das MVP innerhalb des MVPD zu erstellen?
  4. Skills: Stehen mir entsprechend viele Mitarbeiter mit den erforderlichen Skills zur Verfügung?

Wenn alle vier o.g. Fragen mit „Ja“ beantwortet werden können, existiert eine Möglichkeit das das MVP und zukünftige Releases on time and in Budget durchgeführt werden können.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.