Die kontinuierliche Evolution von smartlearn

Im Schuljahr 2020/21 haben wir nach zwei Jahren Entwicklung smartlearn in der Berufsfachschule Bern gibb in Betrieb genommen. Gemeinsam mit Lehrkräften und Lernenden der Abteilung für Informations- und Energietechnik haben wir die Plattform während zwei Jahren im intensiven Austausch entworfen, entwickelt und getestet. Seither haben wir sie kontinuierlich weiterentwickelt.

Was anfänglich vor allem für Prüfungen gedacht war, haben wir zu einem Lehr- und Lernwerkzeug ausgebaut. Mittlerweile setzen Lehrkräfte in anderen Berufs- und Fachschulen, Berner Gymnasien und der Wirtschafts- und Kaderschule WKS smartlearn im Unterricht und für Prüfungen ein. Auch wenn sich viel verändert hat, ist uns die Zusammenarbeit mit der gibb geblieben. Alles, was wir entwickeln, testet ein Team der Berufsfachschule.

Ich erinnere mich an eine Prüfung während meiner Ausbildung zum Informatiker, in der ich HTML-Code auf Papier niederschreiben musste. Das war sicherlich keine dumme Übung, aber realitätsnah war sie eben auch nicht. Kaum jemand schreibt den Programmcode, egal in welcher Sprache, vollständig auf Papier. Wer Wissen und Kompetenzen im digitalen Bereich lernt, soll das auch digital tun und unter Beweis stellen. Und dazu ist smartlearn da: als zeitgemässes Werkzeug, für eine moderne Infrastruktur im Unterricht.

Schulen, die ihren Schüler:innen und Studierenden digitales Know-how beibringen, können dieses mit smartlearn digital unterrichten und prüfen. Die Lehrkräfte erstellen in smartlearn praxis- und handlungsorientierte Lern- und Prüfungseinheiten – vom Aufsatz und der Multiple-Choice-Prüfung bis hin zu virtualisierten Computerumgebungen für Cybersecurity-Tests oder Netzwerkanalysen. Sie erschaffen so unter anderem Szenarien, mit denen die Lernenden in ihrem Berufsalltag konfrontiert werden.

Wir haben smartlearn ursprünglich auf die Bedürfnisse der IT-Ausbildung ausgerichtet. Inzwischen konnten wir die Plattform ausbauen, sodass wir Berufsausbildungen mit digitalen Komponenten bedienen. Abgesehen von der technischen Umgebung bietet smartlearn Schulen die Gelegenheit, ihre Didaktik zur Vermittlung digitaler Kompetenzen zu überdenken. Hier stelle ich einen Paradigmenwechsel fest, den wir als Software-Anbieter unterstützen können. Aus klassischen Wissensprüfungen entstehen praxisnahe Lern- und Prüfungsszenarien. Lehrkräfte sehen mit smartlearn, ob die Lernenden nicht nur verstanden haben, sondern ebenso fähig sind, das erworbene Wissen anzuwenden. Und weil sich die Schulen didaktisch weiterentwickeln, verändern sich ihre Anforderungen an unsere Plattform.

Mit jedem Release – wenn wir neue Funktionen ausrollen – entwickeln wir smartlearn ein kleines bisschen weiter. Wir machen keine grossen Sprünge oder Umwälzungen, die die Nutzenden überfordern könnten. Damit verhindern wir auch, dass wir die Lehrkräfte und Lernenden ständig neu schulen müssen. Eine anfängliche Schulung der unterschiedlichen User-Gruppen zu den Möglichkeiten und der Bedienung der Plattform reicht aus, um zukünftige Veränderungen zu verstehen. Die Aussage «stetige Evolution statt sprunghafte Revolution» beschreibt deshalb für mich unser Vorgehen am besten.

Wir durchlaufen vier Schritte, um neue Funktionen umzusetzen. Sie benötigen Wochen oder Monate, während der tatsächliche Entwicklungsprozess einzelner Aufgaben vergleichsweise kurz dauert.

In jeder Bildungsinstitution, die smartlearn einsetzt, gibt es ein bis zwei IT-versierte Personen, die wir Power-User nennen. Sie vertreten die Lehrkräfte und Lernenden – unsere Stakeholder. Sie sind es, die uns neue Anforderungen und Wünsche, aber auch Probleme mitteilen. Stört beispielsweise etwas aus Sicht der Lernenden in der Prüfung oder haben Lehrkräfte Schwierigkeiten, wenn sie eine Prüfungsumgebung erstellen, erfahren wir es via Power-User. Dank ihnen sind wir immer auf dem Laufenden, wie die Nutzenden smartlearn erleben und wo sie mit der Plattform anstehen.

Im Gespräch oder einem Workshop erfahren wir, was Probleme verursacht und welche neuen Wünsche die Nutzenden haben. Meine Aufgabe als Product Owner ist es dann, diese Anforderungen so weit auszuarbeiten, dass ich ein Angebot formulieren kann.

Bevor es mit der Entwicklung losgehen kann, beschreibe ich die neuen Anforderungen als Angebot. Das Angebot steckt ab, worum es geht und wie viel Arbeit es braucht, um die Anforderungen umzusetzen. Obschon die Anforderungen vielleicht von nur einer Schule kommen, bin ich bemüht, sie für möglichst viele Nutzenden anderer Schulen zu definieren. Bei der Weiterentwicklung schauen wir, dass smartlearn alle Nutzenden weiterbringt – wir bauen keine Einzellösungen. Neue Anforderungen sollen deshalb immer für alle relevant und nützlich sein. Als Product Owner sorge ich dafür, dass das der Fall ist.

Sobald das Angebot akzeptiert ist, geht es in die eigentliche Entwicklungsphase. Hier definiere ich die Anforderungen an eine neue Funktion noch einmal genauer. Dabei kommt das Ticketing-System GitLab ins Spiel: Ich erfasse Anforderungen und Fehler als Aufgaben, die mehrere Schritte bis zur Fertigstellung durchlaufen. Alle Teammitglieder sehen die einzelnen Tickets, ihre Priorität und ihren Status im Entwicklungsprozess. Um das besser zu verstehen, stelle ich kurz die einzelnen Phasen des Prozesses vor – die sieben Status, die eine Aufgabe nacheinander bekommt.

Die Phasen sind Teil eines Entwicklungszyklus – Sprint genannt –, der jeweils zwei Wochen dauert. So durchlaufen wir als Team immer den gleichen Prozess und widmen uns kontinuierlich neuen Funktionen und beheben auftauchende Fehler. In der Branche sprechen wir von einem iterativen Prozess und der inkrementellen Entwicklung des Produkts – oder einfacher: Wir entwickeln smartlearn mit demselben Vorgehen schrittweise weiter.

Als Erstes definiere ich Teilaufgaben, die zusammen eine Anforderung abdecken. Nach einem technischen Review, in dem die Aufgabe geprüft wird, landet sie im Backlog. Im Backlog sammeln wir die Aufgaben, die bereit zur Umsetzung sind. Weil die Aufgaben priorisiert sind, wissen die Entwickler Nicolo, Thierry und René, welche sie sich als Nächstes zum Entwickeln nehmen sollen. Sobald eine Aufgabe umgesetzt ist, teste ich sie anhand von Abnahmekriterien und gebe sie dann ans Testteam der Berufsfachschule weiter. Sind die Tests erfolgreich, gilt die Aufgabe als «release-ready». Gemeinsam mit anderen Aufgaben wird sie zum passenden Zeitpunkt für die Nutzenden ausgerollt.

Während der Entwicklungszyklus rund zwei Wochen braucht, kann es von der Anforderungsdefinition bis zum Release länger dauern. Anforderungen sind meistens zu gross, als dass wir sie in nur einem Sprint abarbeiten und ausrollen könnten. Ein Ticket braucht oft mehrere Sprints, um all die soeben beschriebenen Stationen zu durchlaufen. Aber dank unseres Sprint-Rhythmus rollen wir dennoch 12- bis 18-mal pro Jahr aus. Für uns ist das der beste Weg, um kontinuierlich unsere Kund:innen mit neuen Funktionen zu beliefern. Sollten gerade wichtige Prüfungen wie die Matura anstehen, warten wir bei der betroffenen Schule mit den Releases. Wir wollen ja nicht, dass die Schüler:innen wegen unserer Änderungen ins Straucheln kommen.

Wenn wir ein neues Paket – wir nennen es auch einen Meilenstein – ausrollen, informieren wir die Nutzenden mehrere Tage vorher. In den Release Notes beschreiben wir, was sich ändert. Wir zeigen (auch mit Screenshots), welche neue Funktionen es gibt, welche wir optimiert und welche Fehler wir behoben haben.

Bislang hat der Kanton Bern die Weiterentwicklung von smartlearn finanziert. Doch wir wären nicht whatwedo, wenn wir bei smartlearn nicht in Richtung Open-Source-Software zielen würden – schliesslich basiert die Plattform auf Open-Source-Technologien. Open Source würde es weiteren Nutzenden erlauben, die Plattform für sich und andere weiterzuentwickeln. Selbstverständlich verbessern und entwickeln wir smartlearn weiterhin für unsere Kund:innen. Open Source ist lediglich der nächste logische Schritt, wie wir unser Produkt weiterbringen.