Softwareentwicklung und Lernen

Ich habe einigen Entwicklern in einem Web-CMS-Projekt neulich einmal die absurde Frage gestellt, wie lange sie brauchen würden, um die ganze Software am Ende  noch einmal unverändert einzutippen. Das ganze Projekt ist etwa 6 Monate lang gelaufen. Die mehr oder weniger einhellige Antwort war so etwas wie zwei Wochen, also grob 8%.

Immer wenn nicht getippt wurde, musste einer reden, lesen oder nachdenken. Es ging also zum Teil um geistige Erfindungen (Architekturen, Ideen im Code etc.). Ein sehr großer Bestandteil war aber das Lernen. Zum Schluss war das Wissen um das System vollständig aufgebaut. Es dann neu zu tippen wäre kurz gewesen.

Etwas konkreter – Was wurde gelernt?

Ich gebe hier vier Bereiche an, aus denen sich jeweils etwas ableiten lässt. Es gab natürlich noch viel mehr im Projekt, was gelernt werden musste.

1. Die Entwickler des Kunden mussten java lernen, da es sich um ein java-CMS handelte und die hausinternen Entwickler bisher nur PHP entwickelt hatten.
2. Alle Entwickler mussten Details über die geplanten User Stories lernen, die von Details in der Organisation abhingen. Der Product Owner, der diese Details erklären sollte, musste gleichzeitig die Paradigmen und Möglichkeiten des CMS Systems kennen lernen.
3. Abhängig von den Details der Stories haben manche Entwickler architektonische Strukturen im Code erfunden. Diese Muster und Paradigmen mussten von allen anderen im Team gelernt werden.
4. Die Stakeholder und Benutzer in der Organisation mussten Stück für Stück die Funktionalität des neu entstehenden Kernsystems verstehen. Dabei mussten die Entwickler oft lernen, wie sie einzelne Features implementieren mussten, damit die Nutzer damit glücklich wurden.

Nach meinen Ausführungen zu meinem Projekt könnten sie mal eines ihrer Projekte einordnen: Bitte, stimmen sie ab!

Vermeidbares und Unvermeidbares Lernen

Schauen wir uns die obigen Lernbereiche einmal genauer an. Musste dieses Lernen in dem Projekt denn sein?

Der erste Punkt:  Einige der Entwickler mussten die Programmiersprache lernen. Das was hier gelernt werden musste, hätte ohne Abhängigkeit zu anderen Dingen im Projekt vorher gelernt werden können. Dieses Lernen diente der Innovation, war aber wenigstens grundsätzlich vermeidbar.

Der zweite Punkt: Hätten aber die Entwickler vorher die Details der Userstories lernen können? Nein. Der PO hätte sie nicht vorher aufschreiben können, denn er musste ja gleichzeitig von den Technikern über die Plattform lernen und die Details der Funktionalität hängen von den Details der Plattform ab. Es liegt also eine zykliche Abhängigkeit vor, die das Lernen im Projekt unvermeidbar macht.

Der dritte Punkt: Hätte die Architektur nicht vorher festgelegt werden können? Nein. Denn gute Architektur löst vorliegende Probleme. Die Architektur kann also erst gelernt werden, wenn die Funktionalität gelernt wird. Dieses Lernen ist auch ans Projekt gekoppelt.

Der vierte Punkt: Nachdem die Funktionalität einmal vom PO beschrieben war, musste dennoch aus den Reaktionen der Nutzer gelernt werden. Hätte der PO nicht vorher wissen können, wie die Funktionalität sein muss, dass die Benutzer sie annehmen? Nein. Denn oft hängt die Akzeptanz eben nicht nur von der Funktionalität sondern von der konkreten Implementierung ab. Ein Beispiel nicht aus diesem Projekt ist hier die Spracherkennung. Bevor Siri das Feature so herausragend implementiert hat, fand es kaum Akzeptanz.

Schlussfolgerungen und Thesen

Lernen ist in der Softwareentwicklung sehr wichtig – bei manchen Projekten die überragende Hauptsache.

Bei vielen, wenn nicht gar allen Softwareprojekten ist ein großer Teil dieses Lernens den zyklischen Abhängigkeiten geschuldet und ist somit nicht sinnvoll vermeidbar.

Den vermeidbaren Anteil zu vermindern ist sinnvoll. Dennoch kann es schlicht die Innovation sein (z.B. eine neue Programmiersprache), die projektunabhängiges Lernen ins Projekt holt.

In diesem Licht ist klar: Um in der Softwareentwicklung erfolgreich zu werden, muss man ziemlich konsequent alles auf’s Lernen ausrichten. Die Auswahl der Entwickler, den Entwicklungsprozess, die Tools und die gesamte Atmosphäre.

Was noch von mir kommt

In diesem Artikel über Scrum als Framework für optimale Lernbedingungen geht es darum, wie wir alles auf’s Lernen ausrichten, wenn ein Team einmal besteht.

In einem folgenden Artikel möchte ich noch darauf eingehen, wie man das zusammenstellen eines Teams voll auf’s Lernen ausrichtet.

Außerdem habe ich noch vor, ein Sammelsurium aus agilen Praktiken aus der Perspektive des Lernens zu beleuchten.