FlePA erlaubt die Arbeit flexibel zu organisieren; bei einem Ansatz, wie ich es mit TST verfolge, würde eine andere (von den bekannten) Möglichkeit nicht funktionieren.
Klassisch:Bei klassischen Modellen ist die Anwesenheit eines Managers viel zu unentbehrlich, dass macht eine Entwicklung aus der Ferne beinahe unmöglich bzw mit so viel Überarbeit, dass es schlichtweg irre wäre, eine klassische Methode zu verwenden.
Agil:Agil ist zu überladen mit Prozessen aller Art, Pair Programming geht gar nicht, denn die Entwickler sollen alleine aus der Ferne arbeiten können.
Meetings bringen nichts, wenn man weiß, was man tut, und das soll man schon wissen.
Das sich ein Team selbst organisiert ist schön in der Theorie, doch in der harten Praxis der Entwicklung von neuer SW bedarf auch wieder viel zu viel Organisations- und Abstimmungsarbeit mitten in der Entwicklung. Das können wir uns nicht leisten; wir wollen doch unser Einkommen maximieren :-)
Dagegen sind die Vorteile von FlePA für eine solche Entwicklung nicht zu unterschätzen:
- Verantwortungsprinzip: Unentbehrlich bei einer Entwicklung aus der Ferne (im Gegenzug zu der Verantwortungslosigkeit bei dem Gedanken des "Team-Ownerships")
- Anwendbar auf Teams jeglicher Größe, damit flexibler und benutzbar für verschiedene Projekte ohne in Schwierigkeiten zu laufen (nicht begrenzt auf Teams von 5..9 Personen). Dazu: der Administrationsaufwand wird hiermit auch minimiert
- Einfachheit und Verzicht auf fixe Prozesse und Zeremonien (Das Modell ist so einfach wie möglich und schreibt keine zwingenden Maßnahmen vor)
- Optimieren als Ziel (Lean Entwicklung Ansätze: keine Verschwendung -u.a.-)
- Umfang und Qualität des Ergebnisses sind nicht "verhandelbar" (Projektmäßig halt; wie es sein soll, m.E.n.)
- Betonung der Sicherheit bei den Entwicklung und bei der fertigen SW (eine der wunden Punkte sowohl bei den klassischen als auch bei den agilen Methoden)
Ohne FlePA waere einen solchen Ansatz nicht möglich...
