Erfahrungsbericht Agiles Studieren im Fach Praxis der betrieblichen Informationssysteme

Nachdem ich nun schon einige Erfahrungen mit der Methodik Agiles Studieren sammeln konnte, ist es nun an der Zeit, einen weiteren Erfahrungsbericht zu schreiben. Erfahrung konnte ich mit der Methode nun in zwei Fächern, Programmieren und Praxis der betrieblichen Informationssysteme (PBI), sammeln.

Beide Veranstaltungen unterscheiden sich auf Grund ihrer Inhalte stark. Während Programmierung ein Fach mit hoher Methodenvermittlung ist, ist PBI eher ein Fach, bei dem vorhandenes Wissen übergreifend verknüpft werden muss. Durch die Änderung unserer Studienordnung wurde PBI als neues Fach aufgenommen. Dies ermöglichte mir, die Veranstaltung komplett neu zu konzipieren und gleich auf Agiles Studieren auszurichten. Bei der Planung der Veranstaltung habe ich mich entschlossen, die grundsätzlich in Programmierung angewandte Methode leicht abzuändern und diese in PBI anzuwenden.

Folgende Änderungen wurden im Vergleich zu Programmieren vorgenommen:

  • Reduktion der durchzuführenden Lernthemen (Lernstories), aber damit auch Erhöhung des Umfangs pro Lernstorie.
  • Keine Bereitstellung von Unterlagen in Form von PowerPoint Slides oder ähnlichem.
  • Änderung des Reviews von abfrageorientierter Überprüfung hin zu gemeinsamen Lösen von Problemfällen.
  • Ausrichtung der Klausur auf den Stil des Reviews.

Die Reduktion der Lernthemen konnte vorgenommen werden, da bei PBI im Vordergrund weniger die Vermittlung von neuen Wissen stand, sondern vielmehr das Fach dazu verwendet werden sollte, das monolithische Wissen aus Veranstaltungen der vorangegangenen Semester in diesem Fach miteinander zu kombinieren. Damit dienen die Lernthemen dazu, das individuelle Wissen einzelner Personen in der Gruppe aufzubereiten und miteinander ein übergreifendes Verständnis über betriebswirtschaftliche Informationssysteme zu schaffen. Ziel der Reduktion der Lernthemen war den Studenten, durch eine geringere Anzahl unterschiedlicher, kleinteiliger Lernstories mehr Freiraum für Gruppendiskussionen zu schaffen.

Die Entscheidung, keine Unterlagen, ja sogar keine Literaturangaben, für die einzelnen Lernstories bereitzustellen, basierte ebenfalls auf der Überlegung, dass bereits vorhandenes Wissen verknüpft werden sollte. Während der praktischen Arbeit zeigte sich aber, dass häufig Wissen nachgeholt werden musste, da der Lehrstoff aus vorangegangenen Veranstaltungen nur noch teilweise vorhanden war. Dadurch waren die Studenten bei einzelnen Lernthemen etwas verunsichert, da sie sich nicht sicher waren, ob Sie „die richtigen“ Informationen erarbeitet hatten. Eine Verbesserung wäre sicherlich, die Lernstories um mehrere Literaturangaben anzureichern.

Eine wesentliche Änderung für diese Veranstaltung war die Art wie der Review abgehalten wurde. Der Review in Programmierung glich einer Abfragerunde. Zufällig wurden aus den einzelnen Teams einzelne Personen ausgewählt und auf die Bearbeitung der Tickets geprüft. Diese Vorgehensweise diente vor allem dazu, den Studierenden einen Spiegel über den aktuellen Wissensstand zu zeigen. Leider hatte diese Vorgehensweise auch einen massiven Nachteil: Wurden die Themen schwieriger, nahm auch die Anzahl der Studierenden im Review ab.
Dementsprechend war ich der Meinung, man müsste den Review von einem negative behafteten Format, wie einer Abfrage, in ein Format bringen, dass der Klausur und der Gruppenarbeit ähnelt. Dementsprechend entschloss ich mich, den Review in Form einer virtuellen Unternehmensberatung aufzubauen. Zu jedem Review habe ich passend zu den bearbeiteten Lernstories der Teams einen vage formulierten Problemfall erstellt. Dieser Fall war immer in der Form „ein Mandant kommt zu Ihnen und hat folgendes Anliegen – Helfen Sie dem Mandanten!“ aufgebaut. Das eigentliche Problem war nicht wirklich benannt nur Hinweise auf mögliche Problemgebiete wurden in dem Fall angedeutet. Ziel des Reviews war es nun, mit den Studenten anhand eines Beratungsansatz eine Problemlösung herauszuarbeiten. Dabei wurde immer nach dem gleichen Schema vorgegangen:

  • Problemidentifizierung
  • Abholung des Mandanten über die Themen durch Definition der verwendeten Themen und Begriffe
  • Herausarbeiten eines Lösungsansatzes
  • Ausblick und Zusammenführung

Durch diese Gruppenarbeit hatte ich die Chance, alle Studierenden durch direkte Aufrufe mit einzubinden. Ergänzend konnte ich noch fehlendes Wissen platzieren, falls ich merkte, dass Wissenslücken vorhanden sind und förderte durch die offene Fragestellung die Anwendung von unterschiedlichem Domänenwissen und Erfahrungen der einzelnen Studierenden. Einen Anreiz an den Diskussionen teilzunehmen, versuchte ich dadurch zu setzen, dass die Klausur in dem gleichen Stil durchgeführt wurde und somit den Review auch als Klausurtraining diente. Diese Vorgehensweise führte dazu, dass in dem jeweiligem Review (alle zwei Wochen) eine große Anzahl Studierender anwesend war, auch die, die die Bearbeitung der Lernstories nur bedingt vornahmen.

Aus meiner Sicht ist es wichtig, in den Bachelor Studiengängen, nach einer gewissen Anzahl an Semestern, ein übergreifendes Fach in der Studienordnung zu etablieren, das das vermittelte Wissen aus vorangegangenen Veranstaltungen zusammenzieht und so ein übergreifendes, vernetztes Wissen bei den Studierenden schafft.

Diese Veranstaltungen sollten mit relativ wenig vordefinierten Lehrpfaden aufgebaut werden, da unterschiedlichstes Wissen der Studenten vorhanden ist und so die Lehr-/Lerngeschwindigkeit individuell angepasst werden muss.

Aus meiner Erfahrung bietet sich hier Agiles Studieren in der hier dargestellten Form an. Lassen die Studenten sich auf die Vorgehensweise ein, zeigt die Erfahrung aus den vergangenen Semestern, dass hiermit solides Transferwissen aufgebaut und geschaffen werden kann. Ob dies nachhaltig ist, muss sich noch zeigen.

Leider zeigen aber auch die durchgeführten Veranstaltungen, dass Studierende sich immer wieder nicht auf das Konzept einlassen.
Ich nehme an, dass dies dann vor allem daran liegt, dass eventuell zu wenig Vorwissen aus den vorangegangenen Veranstaltungen vorhanden ist und somit die Arbeitsbelastung enorm steigt. Ein weiterer Hinderungsgrund kann natürlich auch eine mangelnde Teamfähigkeit sowie ein mangelndes Verantwortungsbewusst sein.

Betrachtet man Agiles Studieren allgemein, bin ich auf Basis meiner Erfahrungen von drei Semester mittlerweile der Meinung, dass dies sehr gut bei Fächern mit hohem praktischen Übungsanteil, wie Programmieren oder bei Fächern bei denen übergreifendes Wissen in Form eines Austausches generiert werden muss, wie PBI, angewandt werden kann.

Studienphase

Der Begriff „agil“ bietet sich als Projektionsfläche für viele Hoffnungen an. Es gibt keine allgemein anerkannte Definition, nur ein umschreibendes „agiles Manifest„. So kann sich jeder heraussuchen, was für einen selbst „agil“ sein soll.

Für uns ist die Idee der schnellen Rückmeldung besonders wichtig. Studierende sollen nicht erst am Ende des Semesters in Form einer Prüfung erfahren, wie weit sie die Lernziele erreicht haben. Uns ist wichtig, diese Rückmeldungen schneller zu geben.

Wenn Studierende in Gruppen Studienthemen bearbeiten sollen, wie schnell können wir Professoren eine Rückmeldung über den Lernerfolg geben?

Im Idealfall könnten die Studierenden sofort nach Bearbeitung eines Themas eine Bestätigung, eine Begutachtung, eine Ablehnung ihrer Arbeitsergebnisse erhalten. Das wäre weder praktikabel noch wünschenswert.

Eine sofortige Rückmeldung müsste automatisiert erfolgen, wir können (und wollen!) nicht unsere Zeit mit Warten auf Bearbeitungsergebnisse verbringen. Es ist nicht einfach, automatisierte Rückmeldungen so geben zu lassen, dass sie auf die Bedürfnisse der Gruppe eingeht.

Weiterhin bedeutet die Bearbeitung eines Themas nicht, dass es fertig bearbeitet wurde. Eine Nacht über ein Problem zu schlafen kann Wunder wirken. Die Lösung einer Aufgabe sollte in der Gruppe besprochen werden. Die Studierenden einer Gruppe müssen sich immer wieder neu organisieren. Mehrere Lösungen können miteinander verglichen werden. Themen stehen miteinander in Beziehung. Lernen braucht Rhythmus.

Dieses vertiefende Lernen ist unser Ziel.

Ein Semester dauert 14-15 Wochen. Wenn wir es schaffen, alle zwei Wochen einer Gruppe von Studierenden Rückmeldung über die bearbeiteten Themen zu geben, können wir dies 6-7 Mal tun. Schaffen wir es nur alle drei Wochen, sind nur 4 Rückmeldungen möglich. Also organisieren wir das Lernen in einen 2-Wochen-Rhythmus und nennen diese 2 Wochen „Studienphase“.

Jede Studienphase besteht aus mindestens zwei Präsenzterminen, pro Woche ein Termin. Dieser entspricht den früheren Vorlesungsterminen.

In der ersten Woche bespricht jede Gruppe die Rückmeldungen zu letzten Studienphase. Hierbei können studentische Coaches / Tutoren oder wir selbst helfen. Zum Beispiel, wenn die Rückmeldung inhaltlich nicht verstanden wurde oder die Gruppe anderer Meinung ist. Eine gut organisierte Gruppe wird versuchen, diese Besprechung vor dem Präsenztermin durchzuführen, aber nicht immer gelingt dies.

Wenn die Gruppen in der vorherigen Phase ähnliche Inhalte bearbeiteten, können Ergebnisse im Plenum vorgestellt und besprochen werden. Dies hängt aber auch von Themen, Gruppenanwesenheiten oder -befindlichkeiten ab.

Danach sollte sich die Gruppe kurz innehalten und gemeinsam besprechen, was in der vergangenen Studienphase gut gelaufen ist, was verbesserungswürdig wäre und was bemerkenswert war.

Diese drei Punkte können erst ab der dritten Woche durchgeführt werden. Inhaltlich gehören diese zur vorherigen Studienphase.

Die Studienphase beginnt mit einer Planung der Themen, die in dieser Studienphase bearbeitet werden sollen. Hierbei ist jede Gruppe frei in der Auswahl. Für jedes Fach gibt es eine bestimmte Anzahl an Themen, die im Semester bearbeitet werden sollen. Daher ist die Wahl der Themen nicht ganz frei. Jede Gruppe kann aber selbst entscheiden, in welcher Phase wie viele Themen bearbeitet werden sollen.

Unsere Aufgabe ist die Beratung zur Themenauswahl. Dies erfolgt entweder individuell für jede Gruppe oder gemeinsam für alle Gruppen. Je nach Stand der Gruppen kann dies auch bedeuten, dass wir einen kurzen Impulsvortrag halten. Ziel ist es, dass jede Gruppe für sich sinnvolle Themen auswählt.

Besitzt zum Beispiel ein Gruppenmitglied Vorkenntnisse zu einem Thema, so kann dieses Thema wahrscheinlich schneller bearbeitet werden. Das Gruppenmitglied unterstützt die Gruppe beim Lernen. Erscheinen die Themen überwiegend schwer, so sollten weniger Themen für die Studienphase ausgewählt werden. Alternativ kann der Kontakt zu anderen Gruppen gewählt werden.

Nach der Auswahl beginnt das Bearbeiten der Studienthemen, noch während des Präsenztermins. Hierbei entscheidet jede Gruppe, ob das Thema nur zeitgleich bearbeitet werden kann, oder, ob einzelne Gruppenmitglieder das Thema für sich bearbeiten und die Ergebnisse später den anderen vorstellen.

Während der ersten Woche sollten alle Gruppenmitglieder die Themen wie abgesprochen bearbeiten. Sinnvoll ist sicher, sich auch einmal außerhalb der Präsenzzeiten zu treffen.

Der Präsenztermin in der zweiten Woche wird genutzt, um den bisherigen Arbeitsstand abzugleichen und offene Fragen zu beantworten. Ziel ist es, in der zweiten Woche die Bearbeitung aller geplanten Studienthemen abzuschließen.

Was bedeutet „Bearbeitung abschließen“? Die Mehrzahl der Gruppenmitglieder muss explizit dokumentieren, dass sie meinen, dass Thema inhaltlich verstanden zu haben.

Damit wir den Gruppen Rückmeldung geben können, muss die Bearbeitung spätestens 24 Stunden vor dem Präsenztermin abgeschlossen sein. Bei vielen Gruppen, vielen Themen oder vollem Terminkalender möglicherweise auch 48 Stunden vorher.

Mit unseren Rückmeldungen schließt sich der Kreis.

Spätestens jetzt sollte einsichtig sein, weshalb Studienphase mindestens zwei Wochen dauern müssen.

Wer sich mit agilen Vorgehensmodellen etwas auskennt, wird die Ähnlichkeit zu einem „Sprint“ bei Scrum, inkl. Retrospektive sicher erkennen.

Zusammengefasst:

  • Lernen braucht Rhythmus und zügige Rückmeldung.
  • Eine Studienphase ist der von uns vorgegebene Lernrhythmus und dauert zwei Wochen.
  • Zu Beginn plant die Gruppe eigenverantwortlich die Studienthemen, die sie in der kommenden Phase bearbeiten möchte.
  • Wir unterstützen diese Planung durch Beratung und ggf. Impulsvorträge.
  • Jede Gruppe entscheidet, in welcher Organisationsform sie die Themen bearbeiten möchte.
  • In der zweiten Woche ist Zeit für Rückfragen und zum Abgleich.
  • 1-2 Tage vor Ende der Studienphase müssen bearbeitete Themen uns vorliegen, damit wir Rückmeldung geben können.
  • Die Rückmeldung wird besprochen und fließt in die nächste Studienphase ein.

Studienthema

In der Idee zum agilen Studieren hatte ich angedeutet, dass der gesamte Stoff in Studienthemen aufgeteilt wird. Was ist denn so ein Studienthema genau, wie groß ist es, wie wird es formuliert?

Menschen mit Erfahrung in agilen Vorgehensmodellen werden sicher ahnen, was ein Studienthema ist: eine User Story, abgewandelt für zu lernende Inhalte.

In der Softwareentwicklung sind User Stories eine Möglichkeit, um Anforderungen aus Sicht des Anwenders kurz aber präzise zu beschreiben. Die Zusammenfassung einer User Story erfolgt mit Hilfe einer Satzschablone:

Als <ROLLE> will ich <ZIEL>, um <NUTZEN>.

Dabei ist <ROLLE> die Rolle des jeweiligen Anwenders, <ZIEL> der Wunsch oder das Ziel dieses Anwenders und <NUTZEN> eine Begründung für diesen Wunsch. Zum Beispiel:

Als Autor will ich weitere Autoren eintragen, um nicht alles alleine schreiben zu müssen.

Zu einer User Story müssen darüber hinaus Kriterien aus Sicht des Anwenders angegeben werden, nach denen bestimmt wird, ob eine User Story vollständig umgesetzt wird (Akzeptanzkriterien). In einer allgemeinen Beschreibung einer User Story werden ggf. weitere Details angegeben, z.B. Prioritäten, Zeitverhalten, Designvorschläge. Manchmal wird der Nutzen nicht in der Zusammenfassung definiert, sondern erst in der Beschreibung.

Auf Basis dieser Informationen lässt sich das Schema für ein Studienthema ableiten: es gibt eine Zusammenfassung auf Basis einer Satzschablone, Kriterien, wann das Thema als bearbeitet gelten kann und eine Beschreibung mit zusätzlichen Informationen.

Das Satzschema für ein Studienthema ist etwas komplizierter. Die Rollenangabe kann entfallen, es lernt der Studierende, daher wird immer ein „Ich“ angegeben. Zur Angabe des Ziels greifen wir aus Vereinfachungsgründen auf die Einordnung von kognitiven Lernzielen nach Bloom zurück. Jedes Lernziel, das wir zugleich als Ziel eines Studienthemas auffassen, kann einer von 6 Kategorien zugeordnet werden. Die Kategorien bauen aufeinander auf. Jeder Kategorie sind Verben zugeordnet, die das Studienthema charakterisieren:

  1. Wissen: benennen, definieren, zeichnen, …
  2. Verstehen: begründen, erklären, erläutern, …
  3. Anwenden: auswählen, modellieren, ändern, …
  4. Analysieren: klassifizieren, unterscheiden, unterteilen, …
  5. Zusammenfügen: formulieren, implementieren, konstruieren, …
  6. Bewerten: beurteilen, in Beziehung setzen, zusammenfassen, …

Die Zuordnung der Verben zu den Kategorien ist nicht trennscharf, aber es ist meistens aus dem Zusammenhang klar, was gemeint ist. Natürlich gibt es ein Studienthema auf einer Meta-Ebene:

Ich verstehe die Bedeutung der Verben zum Thema "Studieren"

Als Akzeptanzkriterien geben wir meist Tätigkeiten an, welche die Studierenden durchführen und dokumentieren sollen. Die Beschreibung enthält Verweise auf Quellen, die von den Studierenden studiert (!) werden sollen. Das können auch Verweise auf unsere früheren Präsentationsunterlagen sein.

Studienthemen können darüber hinaus gruppiert werden, damit die Studierenden bei der Auswahl der Themen eine orientierende Struktur vorfinden. Bei den Themen zur Veranstaltung „Projektmanagement 1“ nutze ich z.B. eine Gruppierung auf Basis der 9 Wissensgebiete nach PMI.

Eine Dokumentation eines Studienthemas sieht dann so aus:

Ich kann den Prozess der integrierten Änderungssteuerung erläutern.

Kategorie: Integrationsmanagement

Quelle: Präsentation PM1-01, Seite 35-39
Erläutern Sie den Prozess mit eigenen Worten auf der Wiki-Seite "ÄnderungsSteuerung".

Es bleibt der Studiengruppe freigestellt, ob jedes Gruppenmitglied das Thema für sich bearbeitet, oder ob ein Mitglied das Thema bearbeitet und es anschließend den anderen Gruppenmitgliedern vorstellt.

Der Umfang eines Studienthemas variiert relativ stark. Für die Fächern „Programmierung 2“ und „Statistik“, beides Fächer mit 5 Credit-Points nach ECTS (entspricht 150 Stunden pro Semester), haben meine Kollegen etwas mehr als 50 Studienthemen formuliert. Einige davon sind optional. In „Projektmanagement 1“ habe ich dagegen etwas mehr als 100 Studienthemen angegeben, und das bei 2 Credit-Points (entspricht 60 Stunden pro Semester).

Diese Unterschiede spiegeln m.E. die fachlichen Anforderungen wieder. „Programmierung 2“ und „Statistik“ orientieren sich eher an den letzteren Kategorien der Taxonomie von Bloom. Selbst wenn ein Studierender z.B. die diversen Befehle einer Programmersprache kennt, kann sie/er noch lange nicht selbst Programme erstellen. Dadurch ist für einen Anfänger das Erstellen einfacher Programme eher zeitaufwendig. Das Fach „Projektmanagement 1“ soll dagegen den Studierenden einen Überblock über die zahlreichen Facetten des Projektmanagements geben. Für jede, aus meiner Sicht, relevante Facette habe ich ein Studienthema formuliert.

Die Idee

daskleineagilebuchEines schönen Tages las ich an einem Samstagnachmittag im Juni ein interessantes kleines Büchlein: „Das kleine Agile-Buch“ von Sander Hoogendoorn. In dem Buch geht um die Anwendung von agilen Methoden, nicht nur für Softwareentwicklungsprojekte.

Was sind agile Methoden? Da gehen die Definitionsversuche auseinander. Das „Manifest für agile Softwareentwicklung“ spricht von einer Bevorzugung von Individuen und Interaktionen gegenüber Prozessen und Werkzeugen. Andere definieren als eine Kombination von inkrementeller Entwicklung, Lernen und unmittelbarer Kommunikation.

Agile Methoden können für viele Bereiche eingesetzt werden, nicht nur für die Entwicklung von Software. Auf openPM wird zum Beispiel beschrieben, wie man das Familienleben mit agilen Methoden vereinfachen kann. Dotmocracy ist ein Versuch, mit agilen Methoden die Entscheidungen in großen Gruppen u.a. zur politischen Beteiligung durchzuführen.

Ich hatte nicht nur eduScrum im Hinterkopf, als ich twitterte: „Was wäre, wenn man Vorlesungen mit Hilfe von Scrum organisieren würde?“. Scrum ist eine der häufiger verwendeten agilen Methoden. Es entspann sich ein kleiner Dialog mit einem meiner Kollegen.

20130622_as0

Wir beide waren uns bei dem Mittagessen schnell einig, dass die üblichen „seminaristischen Vorlesungen“ für einige unser Fächer nicht adäquat sind. Im Gegenteil, wir hatten (und haben) das Gefühl, dass mit solchen Lehrformen nur relativ wenige Studierende erreicht werden. Von 45 Teilnehmern an einer solchen Vorlesung beteiligen sich vielleicht 5 Studierende intensiver. Der Rest hört entweder mehr oder minder aufmerksam zu oder nutzt den Zugang zum Internet für eigene Zwecke. Es soll sogar Studierende geben, die nur deshalb in die Hochschule kommen, um bei den eigenen Verwandten nicht als faul dazustehen.

Umgekehrt nehmen wir für uns nicht in Anspruch, die Vorlesungen optimal auf die Bedürfnisse für die Teilnehmer zuzuschneiden zu können. In vielen Fällen sind uns die Teilnehmer erst nach einigen Wochen etwas bekannter. In den bisherigen Jahren meiner Lehrtätigkeit habe ich immer wieder mit einzelnen Techniken experimentiert. Mal „funktionierte“ eine Technik in einem Semester für eine Vorlesung, im nächsten Semester wiederum nicht.

Die Qualität einer Lehrveranstaltung, definiert über das Lernen der Studierenden, ist abhängig von den Lehrenden und den Lernenden.

In diesem Sinne fragten wir uns, warum die Studierenden nicht selbst über ihren eigenen Lernfortschritt entscheiden sollten. In einer Vorlesung entscheidet der Lehrende mit Hilfe seiner Erfahrung und der (teilweise spärlichen) Rückmeldung der Studierenden über den Lernfortschritt.

Das individuelle Begleiten eines Studierenden beim Lernen ist für uns nicht möglich, wohl aber das Begleiten einer Gruppe von 5 bis 8 Studierenden. Für viele Lernende ist das Arbeiten in einer Gruppe von Gleichgesinnten einfacher als das einsame Lernen.

Die Idee nahm konkrete Formen an:

  • Auf Basis der Veranstaltungsbeschreibung erstellen wir für jedes Fach eine gewisse Anzahl von Studienthemen. Pro Vorlesungstermin ergeben sich 5 bis 10 solcher Studienthemen.
  • Jede Gruppe von Studierenden (Studiengruppe) wählt für eine Studienphase von 2 Wochen die Studienthemen aus, die sie bearbeiten möchte. Jedes Gruppenmitglied übernimmt die Verantwortung über einige dieser Studienthemen.
  • Wir beraten die Gruppen in der Auswahl der Themen. Je nach Bedarf erfolgt die Beratung gruppenindividuell oder für mehrere (bis: alle) Gruppen.
  • Auf Wunsch der Gruppen stellen wir die Themen detaillierter vor. Dies kann in Form einer Vorlesung erfolgen, oder auch auf eine gruppenindividuelle Art und Weise.
  • Nach den 2 Wochen stellen die Gruppen ihre Ergebnisse den anderen Gruppen vor.
  • Die nächste Studienphase beginnt.

Damit wandelt sich unsere Rolle von der eines „vorlesenden Edutainers“ in die eines Themenstrukturgebers und Lernbegleiters.

Diese Idee stellten wir unseren Kollegen im Studiengang vor. Alle waren interessiert, hatten aber schon teilweise eigene Planungen für das nächste Semester. Ein Kollege wollte (und konnte) das Konzept gleich mit ausprobieren.

Im Wintersemester 2013/14 begannen wir die Idee in den doch relativ unterschiedlichen Veranstaltungen „Statistik“, „Programmierung 2“ und „Projektmanagement 1“ umzusetzen.