Was ist Feature-based Programming (FBP)?

FBP ist eine agile Methodologie zur Entwicklung von Software. Mit der Gründung einer eigenen Firma im Jahre 1998 war ich - mehr als in irgendeinem meiner vorherigen Jobs als Programmierer und Projektleiter - gezwungen, selbst einen effizienten Entwicklungsprozess zu definieren. Da ich bereits einige Jahre in verschiedenen Positionen in der Entwicklung gearbeitet hatte, hatte ich natürlich alle Vor- und Nachteile schwerer, bürokratischer Entwicklungsprozesse am eigenen Leib erfahren. 1983 hatte ich mein erstes Programm auf einem Apple II geschrieben und seitdem die verschiedensten Methodologien und Modellierungsnotationen von SA, SADT, HIPO (!), OMT etc. selbst ausprobiert. Ich kannte die relevante Literatur über Software-Engineering und verfüge als Dipl-Ing. und Dipl.-Inf. über die notwendigen theoretischen Grundlagen. Meine Leidenschaft gilt jedoch der Programmierung und somit war von Beginn an klar, das die Software-Entwicklung in meiner Firma vor allem für die Selbstorganisation von Programmierern geeignet sein sollte.

Das Problem ist jedoch: Programmierer organisieren eigentlich nicht gerne. Das galt im wesentlichen auch für mich selbst, wenn man aber selbst die Verantwortung in einer Firma für Projekte und Mitarbeiter hat, sieht man vieles anders…

Aus meiner eigenen Sicht wollte ich natürlich möglichst wenig Zeit für das Projektmanagement und die Erstellung von Planungs- und Umsetzungsunterlagen aufwenden (und somit die Zeit für die Programmierung maximieren). Gleichzeitig wollte ich aber auch, das der Kunde sehr professionelle Projektunterlagen erhält, die für ihn verständlich, nachvollziehbar und die immer aktuell sind.

Diese Unterlagen sollten zudem auch direkt als Plan von den Programmierern genutzt werden können.

In den letzten 5 Jahren haben wir dann in einer langen Reihe von Projekten den Prozess extrem ausgefeilt, d.h. wir haben uns bemüht den Prozess immer schlanker zu machen. Ein wichtiges Lern-Projekt war zudem die Entwicklung des erfolgreichen Online-Reisebüros Travelchannel.de, den wir jetzt seit 4 Jahren betreuen. Wir haben damals die Software von Grund auf neu entwickelt. Durch die extrem kurzen Releasezyklen und die hohen Anforderungen im Internet (Wenn man etwas ausliefert muss das pünktlich fertig sein und stabil funktionieren. Es gibt keine Pilottests oder „Friendly Customer“!) haben wir zudem gelernt, welche Mechanismen auf die Pünktlichkeit eines Projektes einwirken. Heute können wir dem Travelchannel für jedes Weiterentwicklungsprojekt den Auslieferungszeitpunkt und die Kosten garantieren!

Das klingt natürlich immer zu schön um wahr zu sein und natürlich ist auch FBP keine „Silver Bullet“. Es ist aber auch kein Baukasten (so wie andere Agile Ecosystems) sondern ist einen minimale, optimale Lösung für das Problem „Software-Entwicklung“. Ich kann mich bis heute nicht mit der Ansicht anfreunden, das jeder Anwender seinen Entwicklungsprozess weitreichend selbst anpassen kann/muss (dazu gehört nämlich sehr viel Erfahrung) und das Software-Entwicklung immer situativ und nicht wiederholbar ist. Letzteres ist übrigens wichtig, wenn man eine Firma besitzt. Wir haben heute 26 Entwickler und alle arbeiten (wiederholbar) nach den gleichen Prinzipien des Feature-based Programmings.

Sie sehen also, ich vertrete ein Reihe kontroverser, gegensätzlicher Ansichten gegenüber den anderen agilen Ansätzen. Wenn Sie die folgende Zusammenfassung lesen, dann vergessen sie dabei bitte nicht, das ich mit meinen Kollegen seit fast 5 Jahren sehr erfolgreich Projekte nach den FBP-Prinzipien realisere. FBP ist also praktisch erprobt, über einen längeren Zeitraum optimiert, wiederholbar und inhaltlich sehr stabil. Zugleich muss ich aber auch ChristianMann recht geben, dass es übereinstimmende Prinzipien gibt, die sich immer mehr herauskristallisieren und in fast allen Prozessen erfolgreich angewendet werden. Das Wichtigste aus meiner Sicht: Sehr kurze Releasezyklen mit stabilen, produktionsfähigen Auslieferungen.

Ich habe jetzt so lange an meinem Buch geschrieben und versuche jetzt neue Worte zu finden - was nicht leicht ist - um den Besuchern des AgileWiki einen Einblick in das Feature-based Programming zu geben. (Das Buch erscheint übrigens am 27. Mai bei Addison-Wesley. Man kann es im Internet schon vorbestellen. Wenn Sie Interesse daran haben, dann würde ich mich freuen, wenn Sie es bei http://www.libri.de kaufen würden: Wir haben das eCommerce-System von Libri.de nach den FBP-Prinzipien entwickelt und pünktlich zum 11. April - wie geplant - fertiggestellt. Zudem hält libri.de keine Trivialpatente, mit denen Wettbewerber ausgeschaltet werden, wie das heute bei anderen, amerikanischen Unternehmen offensichtlich so Sitte ist…)

Feature-based Programming

  • Nur drei standardisierte Kerndokumente: Featureliste, Releaseplan, Massnahmenplan
  • Nur ein Dokument, in dem die Anforderungen und Change-Requests gesammelt werden: Die Featureliste
  • Die Featureliste muss vor Beginn der Programmierung „nach bestem Wissen und Gewissen“ vollständig sein

(Darauf gehe ich im Buch natürlich näher ein, auch auf die Frage, was eigentlich ein Feature ist…Es bewegt sich aber natürlich irgendwo zwischen einer User-Story und einem Use-Case)

  • Jedes Feature erhält eine Min-Max Schätzung
  • Ein Feature darf nicht mehr Aufwand als 5 Manntage erfordern.
  • Selbstbindung des Programmierers: Features, Aufwandschätzung und Releaseplan werden von den Entwicklern selbst geschrieben und geplant
  • Es gibt keinen Fulltime-Projektleiter. Der Projektleiter (der bei uns Programm-Manager heißt), programmiert immer mit. Er ist nicht auf diese Position befördert worden, sondern ist in der Tat der erfahrenste Entwickler im Team, sozusagen ein Primus Inter Pares.
  • Gezieltes Coaching der Programmierer auf Basis sogenannter Erfahrungsstufen, die die praktische Projekterfahrung mit FBP widerspiegeln und die Entwickler in die Lage versetzen, sich über die Jahre auf immer größer werdende Aufgaben und Verantwortungen vorzubereiten.

Es gibt viele Menschen, die behaupten, das es der größte Fehler ist, wenn man als Projektleiter auch in das Programmieren eingebunden ist. Ich sehe das genau anders: Ich finde es viel schlimmer, wenn ein Projektleiter gar keine Ahnung davon hat, was die Programmierer tun. Und das ist nicht selten! Wichtig ist jedoch, die Bürokratie möglichst klein zu halten, damit man auch Zeit hat zu programmieren, bzw. damit man auch wirklich die Projektmanagement-Aufgaben ausfüllen kann…

  • Zerlegung der Entwicklung in 2-3 Wochen Releases (Extremfälle: 1 Woche oder 4 Wochen, nie länger)
  • Aufteilung der Feature auf die einzelnen Releases nach technischen, personellen und inhaltlichen Prioritäten
  • Planung bis zum Ende des Projektes!!!!
  • Garantierte Releasetermine!!!! (sogar mit Uhrzeit: Morgens 09.00, Beginn der Auslieferung…)

Die beiden letzten Punkte und das mit der „vollständigen Featureliste“ sind sicherlich für Agilisten am schwierigsten zu verdauen…

  • Kundenfeedback nach jedem Release bis zu einem definierten Termin (meist drei Tage nach Auslieferung)
  • Einarbeitung des Feedbacks in das laufende Release. (Größere Sachen werden neu geplant und priorisiert…)
  • Alle anderen Todos, die für die pünktliche Auslieferung erforderlich sind (z.B. Kleinigkeiten wie „Firewall freischalten“) werden in einem weiteren Dokument geführt, das immer als erstes in einem Projekmeeting auf den Tisch gelegt wird: Der Massnahmenplan
  • Formales Projektchecking mit dem Controlling nach jedem Release (wie das Release selbst, ist das ebenfalls ein fixer Termin)
  • Tagesgenaue Zeiterfassung und tranparente Übersicht über den Zeitverbrauch zur gezielten Steuerung

Planung bedeutet nicht „Vorhersagen“, sondern sich etwas auf Basis von Annahmen (z.B. Aufwandsschätzung) vorzunehmen und ständig diese Annahmen und die Zielerreichung zu hinterfragen und zu optimieren.

  • Meetings mit dem Controlling immer genau einen Tag nach dem Release. (Nicht öfter, dafür aber garantiert und gut vorbereitet)
  • Kein Upfront-Design, sondern iteratives Design („Continuous Care“). Wir nennen die Design-Meetings „Chinese Parliament“…
  • Starker Fokus auf gutes Package-Design (wenn man darauf achtet, dann muss man fast automatisch Design-Patterns anwenden…)
  • Fokussierung auf das eigentliche Handwerk: Die Programmierung (keine Toolhörigkeit)
  • Tools werden vor allem für die Automatisierung von bürokratischen Vorgängen erstellt. Ein Beispiel ist „Captain Feature“, unser internes Feature-Management System, das mittlerweile alle Dokumente erstellen und managen kann.

Das sind die wichtigsten Punkte. Bleibt noch zu sagen, das FBP nichts mit Orange/Web im Detail gemein hat (ausser die 2-Wochen Zyklen und die ungefähre Größe eines Feature: Cockburn geht von maximal drei Tagen pro Feature aus). Generell hat FBP nichts mit den amerikanischen Ansätzen zu tun. Es ist völlig unabhängig entstanden.

Auf Basis dieser Aufzählung bekommt man natürlich noch kein Gefühl dafür, wie sich der Prozess „anfühlt“. Ich hoffe aber, das das genug Material ist, um Ihr Interesse zu wecken. Ich würde mich über Fragen oder Anmerkungen sehr freuen und meine Antworten gerne in diesen Text weiter einarbeiten.

— Stefan Richter


Der Vortrag von Stefan Richter auf der OOP 2003 hat auf jeden Fall einen ganz interessanten Prozess vorgestellt, der (als „heimisches Pflänzchen“) einige Unterschiede zu den bekannten Prozessen aufweist. Kern waren die Konzepte

  • Feature (= eher unzeremonieller Use Case)
  • Time Boxing in Zyklen von 2 - 4 Wochen
  • Kundentests am Ende eines jeden Zyklus
  • Feste Zeitpläne zur Organisation der Zyklen!
  • Standard-Meilensteine für nebenläufige Infrastruktur-Maßnahmen (Hardwarebeschaffung etc…)

Der ganze Prozess sah für mich doch recht nach einer maßgeschneiderten Version von Crystal Orange/Web aus – was nichts schlechtes sagen soll (im Gegenteil). Die Tatsache, dass er aber (so Stefan Richter – m.E. glaubhaft) unabhängig von den bekannten Agilen Prozessen entstanden ist, bestätigt mich in der Auffassung, dass das Konzept der Best Practices doch recht ansprechend ist: Offenbar läßt sich Agilität auf einen recht kleinen Kern von Praktiken zusammenfassen, die in der einen oder anderen Form immer wieder auftreten!

Allerdings mag man darüber streiten, ob es sinnvoll ist, einen – auch im gegebenen Kontext Agiler Prozesse – bereits eingeführten Begriff (“Feature“) „umzudefinieren“, und das auch noch zu der Bedeutung eines anderen bereits eingeführten Begriffes (“Use Case“, den im Vortrag gezeigten Beispielen nach zu urteilen; ein weiterer Kandidat könnte auch die aus eXtreme Programming her bekannte “User Story“ sein, da der Bezug auf den – vollständigen – Anwendungsfall nicht so eindeutig war…)

Ich habe da so meine Zweifel!

Christian Mann 2010/10/24 12:37


Nur mal so in's „Unreine“ gedacht:

Könnte man für Feature-Based Programming eigentlich auch so etwas wie einen „Kompress-Workshop“ nach Art der Extreme Hour aufsetzen – wenn auch wohl mit etwas längerem Zeitrahmen – um ein „Gefühl“ für den Prozess zu bekommen?

Christian Mann 2010/10/24 12:43

 
feature_based_programming.txt · Zuletzt geändert: 2010/10/24 12:50 von Christian Mann
 
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht:GNU Free Documentation License 1.2
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki