In der letzten Zeit hab ich mich eingehend mit agiler Software-Entwicklung beschäftigt. Das hatte ich schon eine ganze Zeit lang vor, aber praktischerweise hatte ich von der Uni aus die Aufgabe mit ein paar Kommilitonen mir Scrum anzusehen und darüber zu referieren. Außerdem habe ich gerade an der Summerschool „Agile Software-Entwicklung“ teilgenommen. Das hab ich dann mal zum Anlass genommen, mich etwas intensiver mit der Thematik zu beschäftigen.
Bei Agiler Softwareentwicklung gehen die Meinungen typischerweise stark auseinander. Je nachdem wem man zuhört, ist man geneigt entweder den einen oder den anderen recht zu geben. Beide Argumentationsweisen, beide Softwareentwicklungsphilosophien hören sich, für sich alleine betrachtet, vollkommen vernünftig an. Das hilft natürlich nicht sonderlich weiter, wenn man sich eine eigene Meinung bilden will und so schreibe ich das hier hauptsächlich, um mir selbst hier einigermaßen Klarheit zu verschaffen.
Ursprünglich hatte ich einen vergleichsweise langen Artikel geplant. Ich denke aber, dass mehrere kleinere Artikel eher gelesen werden als ein großer. Außerdem dauert ein großer Artikel immer so lange zu schreiben. Nachdem ich jetzt schon über zwei Monate immer mal wieder an dem Text sitze und immer noch erst etwa ein Drittel steht, habe ich mich nun entschlossen, eine Artikelserie daraus zu machen.
Die Artikelserie spiegelt meine momentanen Gedanken zu dem Thema wider. Ich kann nicht sagen, ob ich bei dieser Meinung, die ich hier mal herausarbeite, bleiben werde. Ich bin einfach selbst mal gespannt, wie ich zur Thematik stehen werde, wenn ich mit der Zeit mehr Einsicht gewinne. Nun gut. Ich hab jedenfalls einiges gelesen und mir meine Gedanken dazu gemacht. Los geht es mit einem geschichtlichen Überblick über die Thematik.
Als man mit dem Programmieren Mitte des letzten Jahrhunderts anfing, machte man sich über solche Dinge keine Gedanken. Man programmierte einfach. Und das auf einem Niveau, das man sich heute gar nicht mehr vorstellen kann. Erkenntnisse wie Kapselung, Abstrakte Datentypen, Strukturierte Programmierung, „goto statement considered harmful“ und all das Zeug, das heute so selbstverständlich ist, dass sich keiner mehr darüber Gedanken macht, waren noch nicht bekannt bzw. noch umstrittener Forschungskram.
Nichtsdestotrotz wurden die Programme komplexer und größer. Und weil Murphys Gesetz auch damals schon gegolten hat, endete das Ganze in einer ziemlichen Katastrophe. Genaugenommen in dem, was man die Softwarekrise nennt.
Als Antwort auf die Softwarekrise entstanden Softwaretechnik und Software-Engineering. Auf der einen — technischen — Seite entwickelten sich Programmiersprachen und Tools weiter und die oben genannten Erkenntnisse setzten sich langsam durch. Auf der anderen — organisatorischen — Seite gelangte man zu der Erkenntnis, dass man Software, wie andere komplexe Systeme auch, mit Ingenieursmethoden entwickeln sollte.
Statt dem einfachen „Code and Fix“ ging man nun also die Sache systematisch an. Wir spezifizieren unser System zu Tode, bis es sich nicht mehr rühren kann; produzieren Berge von Dokumentation; versuchen jeden Schritt voraus zu planen; und überlegen uns zudem diverse Mechanismen zur Qualitätssicherung. Das funktioniert. Manchmal. Unter gewissen Umständen. Teilweise ziemlich gut sogar. Manchmal funktioniert es auch nicht, aber in jedem Fall ist es enorm aufwändig.
Die Softwarekrise war also immer noch nicht überwunden und es scheiterten immer noch reihenweise große Softwareprojekte — teilweise allerdings aus anderen Gründen. Das Problem war jetzt weniger mangelnde Planung, sondern vielmehr zu viel Planung bzw. die daraus erwachsende Schwerfälligkeit. Typischerweise versuchte man Anforderungen ein für allemal am Anfang eines Projekts aufzunehmen und dann jegliche Änderung an diesen zu minimieren.
Was aber, wenn man die Anforderungen nicht so recht versteht? Oder der Kunde noch gar nicht so genau weiß, was er möchte? Oder sich seine Wünsche mit der Zeit ändern, weil sich die Situation geändert hat? Und diese Bedingungen sind eben keine Einzelfälle.
Softwareentwicklung ist wohl manchmal wirklich etwas anderes, als „andere“ Ingenieurswissenschaften. Die Informatik sitzt eh zwischen allen Stühlen. Softwareentwicklung ist kreative Arbeit mit besonderen Anforderungen. Folgendes bringt es eigentlich auf den Punkt:
„When was the last time someone asked the designers of the Empire State building to add ten new floors at the bottom, put a pool on the top, and have all of this done before Monday morning?“ (original; via)
Und wegen diesen anderen Voraussetzungen, den sich ändernden, unklaren Anforderungen und weiteren Unterschieden zu traditioneller Ingenieursarbeit, funktionieren plangetriebene Ansätze bei der Softwareentwicklung doch nicht immer so gut, wie erhofft.
Jedenfalls waren einige mit der Situation ziemlich unzufrieden und so entstanden in den 90er Jahren diverse Softwareentwicklungsmethoden, die sich als leichtgewichtige Alternativen zu den schwerfälligen traditionellen Prozessen verstanden. Eine neue Herangehensweise entstand. Im Februar 2001 setzten sich dann 17 Verfechter dieser Ansätze zusammen, um heraus zu finden, ob sie etwas gemeinsam hätten. Und das hatten sie. So entstand der Begriff „Agile Softwareentwicklung“ und das Manifesto for Agile Software Development („Agile Manifesto“).
Im Kern geht es darum, Personen, Kommunikation und Kundenorientierung über Dokumentation und Pläne zu stellen. Das heißt nicht, dass man in der agilen Softwareentwicklung nicht mehr dokumentiert oder plant. Man versucht es nur, auf ein sinnvolles Minimum zu reduzieren.
Es gab jetzt also eine Community mit ähnlichen Ideen, Werten und Prinzipien, sowie eine Hand voll unterschiedlicher aber im Kern ähnlicher Methoden bzw. Prozesse. Von diesen war Extreme Programming (XP) zuerst am erfolgreichsten. Mittlerweile setzt sich aber Scrum immer weiter durch und immer öfter hört man auch von Kanban. Daneben existieren noch weitere wie Crystal, FDD, DSDM und andere. Eine besondere Verbreitung dieser Methoden ist mir bisher aber noch nicht aufgefallen.