Aufbau der FlePA-Methode im Detail

Es ist das Ergebnis einer (Engineering-)Leistung. Dieses soll so genau wie möglich beschrieben vorliegen, nicht nur aus Sicht der Architektur und des Designs, auch im Hinblick auf Funktionalität und Qualitätsansprüche.

Das zu erstellende Produkt wird sowohl als ein Ganzes als auch in Teilen betrachtet und analysiert, Funktionen und Tests werden definiert, Kosten, Ressourcen und Zeiten geschätzt. Doch soll die Planung modifizierbar sein (klassisches Wunschdenken) oder auch ignoriert werden (agile Leichtfertigkeit).

Für das Team sollte ein Rahmen angewendet werden, der auf dem erweiterten «magischen Dreieck» des Projektmanagements basiert. Dieses Dreieck, bestehend aus den Parametern Funktionalität, Kosten und Zeit, wird durch das Kriterium Qualität zu einem Viereck des Projektmanagements erweitert. Die Interaktionen zwischen den Teammitgliedern werden durch diesen Rahmen definiert. Auch muss der Rahmen an die wirkliche Teamgrösse und das Können und Wissen der Mitglieder adaptiert werden.

Die Teammitglieder besetzen Rollen, etwa die des Projektleiters, und führen Funktionen aus. Dies kann beispielsweise die Schnittstelle zu anderen Teams sein. Es ist Unfug, wenn das ganze Team – am besten noch täglich – mit dem Kunden kommuniziert. Diese Aufgabe wird vom Kundenkommunikator übernommen. Der Funktion können eine oder mehrere Personen zugeordnet sein, wobei es gilt, die Gruppe so klein wie möglich und so gross wie nötig zu halten.

Je nach Grösse des Teams werden einige Rollen und zudem mehrere Funktionen definiert. So kann zum Beispiel ein Team von drei Mitarbeitern vier Rollen und zwölf Funktionen innehaben. Anforderungsmanager- und Projektleiterrollen können in diesem Fall von einer Person ausgeübt werden.

FlePA hat nur zwei Prozessblöcke: Planen und Arbeiten. Ein Projekt braucht Planung, handelt es sich doch um eine neue Entwicklung. Doch gerade weil das Ergebnis neu ist, muss diese Planung mögliche Änderungen mitberücksichtigen, die so gut wie sicher vorkommen werden – deswegen flexibles Planen. Was zu dieser Planung alles gehört, muss von Projekt zu Projekt einzeln festgestellt werden. Für ein Projekt kann das Design des GUI ausreichend sein, für ein anderes Projekt kann von der Architektur bis zur Wartung für zwanzig Jahre geplant werden müssen. Wenn sich etwas ändert, so sind diese Änderungen als Störgrössen in einem Regelkreis zu sehen.

Sie müssen durch eine Rückkopplung wieder einen Planungsprozess anstossen. Genauso ist auch die Arbeit als Teil eines Regelkreises zu betrachten. Beispiele für Störgrössen sind in diesem Fall Mitarbeiter, die das Team verlassen und anschliessend ersetzt werden müssen, oder etwa Arbeitsmittel, die ausfallen.