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
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.
-- StefanRichter?
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 AgilenProzessen? entstanden ist, bestätigt mich in der Auffassung, dass das Konzept der BestPractices 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 ("UseCase", den im Vortrag gezeigten Beispielen nach zu urteilen; ein weiterer Kandidat könnte auch die aus ExtremeProgramming her bekannte "UserStory" sein, da der Bezug auf den -- vollständigen -- Anwendungsfall nicht so eindeutig war...)
Ich habe da so meine Zweifel!
Könnte man für FeatureBasedProgramming eigentlich auch so etwas wie einen "Kompress-Workshop" nach Art der ExtremeHour aufsetzen -- wenn auch wohl mit etwas längerem Zeitrahmen -- um ein "Gefühl" für den Prozess zu bekommen?
