18.1.2009

Netzwerkprodukte (21 / Agile Softwareentwicklung/1)

(Themenanfang)

Wenn eine Firma ihr Geld mit der Entwicklung von Software verdienen will, gibt es eigentlich genau ein zentrales Problem: den Release-Termin. Es ist dabei relativ unwichtig, welche Features implementiert wurden, oder ob die Version stabil läuft: entscheidend ist der Zeitpunkt, an dem das Produkt auf dem Markt erscheint. Nur so lassen sich Geschäftspläne aufstellen, Marketing-Kampagnen planen, die Belieferung der Händler und Vertriebe koordinieren etc.pp.

So sehen das jedenfalls Sales und Marketing - und ich überspitze da nur sehr wenig.

In der Entwicklung hat man mit ganz anderen Problemen zu tun. Das beginnt in der Produktplanung: welche Features müssen implementiert werden und sind unverzichtbar, weil a) man ein Alleinstellungsmerkmal für das Release braucht, b) die Konkurrenz die auch hat, oder c) sie den Kunden längst versprochen waren? Mit den Auflistungen, die aus diesen Fragen resultieren, gerät man unvermeidlich in einen Konflikt mit der Entwicklung. Dort sieht man sich die Anforderungen an - und erstarrt. Eigentlich braucht man die Feature-Listen dort auch gar nicht erst zu analysieren. Es ist von vornherein klar, daß da Sachen draufstehen, die in der vorgegebenen Zeit nicht ansatzweise zu schaffen sind - schon gar nicht, wenn man das „Pflichtenheft” (wie das in Zeiten hieß, in denen man noch von „EDV” sprach) handwerklich sauber, ohne allzu viele Bugs, und mit einer gewissen Tiefe implementieren will.

Es ist fast schon ein eingespieltes Ritual, an dem kaum zu rütteln ist: die Sales-Leute legen einen Abgabetermin fest, die Produktplaner planen das ultimative Release mit Features, auf die die User gleichsam ein Recht zu haben scheinen - und die Entwickler regen sich darüber auf, daß hier Leute am Werk sind, denen sie jeglichen technischen Verstand abzusprechen bereit sind. Die Planung zieht sich schon im Vorfeld endlos hin, weil jedes Detail darauf abgeklappert wird, wie dringend es benötigt wird, und wie viel Zeit seine Implementierung fressen wird, wobei natürlich beide Parteien maßlos übertreiben, und - sofern der Release-Termin noch verhandelbar ist - sogar drei Parteien damit beschäftigt sind, die Brisanz ihrer jeweiligen Nöte zu betonen.

In diesem Spiel kommt man regelmäßig an einen Punkt, wo etwas grundlegend schief geht. Entweder, es wird gnadenlos Geld verbrannt, weil die Marketingmaschine loslief, obwohl man kein Produkt hat, das man verkaufen könnte - oder man wirft ein Produkt auf den Markt, das von den Usern nicht akzeptiert wird und der Firma eine massive Beule im Image verpaßt. Um sich vor Schuldzuweisungen zu schützen, geht man bei den nächsten Releases Schritt für Schritt immer weiter in der Verschriftlichung von Verhandlungsergebnissen - man ist auch firmenintern plötzlich dabei, letztlich Verträge zwischen den Abteilungen auszuhandeln. Richtig schwierig wird das dann, wenn die unterschiedlichen Aspekte - Sales, Produktdesign, Entwicklung - über mehrere Firmen verteilt sind - Steinberg arbeitet streckenweise auch mit Third-Party-Unternehmen zusammen, und ich bin heilfroh, daß ich damit nie zu tun hatte.

Dies ist gewissermaßen die Ausgangslage, auf die „agile” Methoden eine Antwort suchen. Ich beschreibe das so drastisch (obwohl man das noch wesentlich schärfer zuspitzen könnte, und sich haufenweise Geschichten erzählen ließen, die teilweise bizarrer sind, als ein Außenstehender sich das vorstellen kann), weil man öfters der Meinung zu sein scheint, daß „Agile” ein Triumph der Bedürfnisse der Entwickler sei. Das ist eine stark verengte Wahrnehmung (auch wenn die Entwickler tatsächlich produktiver werden können und definitiv mit mehr Spaß an solchen Projekten beteiligt sind), die darüber hinweg sieht, daß man hier versucht, kreative Prozesse steuerbar zu machen - und zwar für eine Kapitalisierung ihrer Ergebnisse.

(Um möglichen beleidigten Reaktionen zuvor zu kommen: ich bin keineswegs der Meinung, daß irgend eine der beteiligten Parteien hier das Recht auf ihrer Seite hätte (ich verweise hier auf meine Notizen über Vernunft und Interesse). Ich habe natürlich weniger Probleme, die Argumente der Entwicklung zu verstehen - insofern sind die hier vielleicht ein wenig pointierter formuliert. Dennoch kann ich nachvollziehen, daß Planbarkeit völlig unverzichtbar ist, wenn man ein Produkt im Markt platzieren will - und vom Verkauf des Endprodukts leben dann alle Beteiligten, auch und gerade die so wenig geschäftstüchtigen Hacker.)

(Kommentarfunktion z.Zt. deaktiviert.)