Konferenzbeitrag
Agile Vorgehensweisen in Ausbildungsprojekten
Vorschaubild nicht verfügbar
Volltext URI
Dokumententyp
Text/Conference Paper
Dateien
Zusatzinformation
Datum
2013
Autor:innen
Zeitschriftentitel
ISSN der Zeitschrift
Bandtitel
Verlag
Gesellschaft für Informatik e.V.
Zusammenfassung
Als agile Vorgehensweisen noch ziemlich neu und besonders spannend waren, haben wir damit auch in der Ausbildung experimentiert. Aus meinen Beobachtungen und dem Erfahrungsaustausch mit agil arbeitenden EntwicklerInnenn schließe ich, dass ein agiler Entwicklungsprozess für ein Ausbildungsprojekt mit Anfängern ungeeignet ist. Meine Gründe dafür möchte ich gerne darlegen. Unsere Studienordnung sieht im 3. Semester die Lehrveranstaltung Software-Praktikum vor, in der die Informatik-Studierenden in Teams zu Acht erste Software-Entwicklungs- projekte durchführen. Die Studierenden verfügen dann schon über erste Programmier- und UML-Kenntnisse aus vorangehenden Veranstaltungen. Das Hauptziel des Software- Praktikums ist die Vermittlung von erfahrungsbasiertem Wissen über Vorgehensweisen in Projekten. Obwohl Ausbildungsprojekte die Realität simulieren, sollte allen Beteiligten immer klar sein, dass nicht das Produkt sondern das Lernen von Methoden und Verfahren im Vordergrund steht. Nach meiner Beobachtung sind die Studierenden im Projekt hoch motiviert, vergessen aber manchmal, dass es nicht wirklich um das Produkt geht. Die Lehrenden sollten außerhalb des Entwicklungsprozesses stehen. Da sie die Verantwortung für die Lernprozesse der studentischen Projektmitglieder tragen, müssen sie beobachten und die Fortschritte der Lernenden begleiten, nur dann in Projektentscheidungen des Teams eingreifen, wenn diese den Lernzielen entgegenstehen, z.B. wenn ein Teammitglied sich nur damit beschäftigt, bunte Bildchen zum Schmücken des Produkts zu gestalten. Jedes Teammitglied muss sich m.E. aus Ausbildungszwecken an allen anfallenden Tätigkeiten beteiligen. Effizienz sollte nur eine untergeordnete Rolle spielen. Wenn ein Ausbildungsprojekt auf die Vermittlung von Methodenwissen ausgerichtet ist, muss sein Ergebnis nicht die Qualität eines an Kunden auslieferbaren Produkts haben. Hiermit meine ich nicht unzureichende Tests sondern Details in der Aufgabenstellung, die in der Realität wichtig sind, für die Ausbildung aber keinen zusätzlichen Nutzen bringen. Studentische Projekte dürfen auch mal scheitern, wenn in der anschließenden Reflexion die Gründe für alle deutlich herausgearbeitet werden. Agile Vorgehensweisen sind iterativ und inkrementell. Der Kunde und seine Bedürfnisse sind Teil des Prozesses. Die Anforderungen werden als Stories skizziert und ihr Aufwand geschätzt. Die Vorgehensweise ist produktgetrieben, effizient und gekennzeichnet von einer hohen Dynamik. Lange Meetings und umfangreiche Dokumentation werden vermieden. Unsere Studierenden haben wenig Erfahrung in der Programmierung und normalerweise keine in Ablauf, Organisation und Zusammenarbeit in Software-Entwicklungsprojekten. Das macht für sie das Schätzen ihrer eigenen Effizienz und des Aufwands für eine Story sehr schwierig. Erfahrung brauchen sie auch zur Festlegung der Anforderungen, die den funktionalen Kern des Produkts ausmachen und deshalb zuerst entwickelt werden sollen. Ein Scrum-Prozess mit den Rollen Product Owner, Scrum-Master, Kunde, Benutzer, Management und Entwicklungsteam lässt sich nur schwer in ein Ausbildungsprojekt transferieren. Wenn die Studierenden das Entwicklungsteam bilden, sollen dann die Lehrenden die restlichen Rollen ausfüllen? Diese Rollen wurden in den Prozess integriert, weil sie Ziele wirtschaftlicher Art oder produktorientierte Ziele verfolgen. Diese Ziele sind nicht unbedingt mit den Ausbildungszielen vereinbar. Der Scrum-Prozess setzt sich aus Sprints von 2-4 Wochen zusammen. Ein realitätsnahes Ausbildungsprojekt sollte schon mehrere Sprints umfassen, damit Sprint Review und Retrospektive ihren Sinn machen und das Schätzen geübt wird. In den Semesterablauf mit konkurrierenden Lehrveranstaltungen lässt sich m.E. ein Scrum-Projekt nur schwer integrieren. Auch wenn ein agiles Projekt in den Ferien als Blockveranstaltung (bei uns 6 Wochen) machbar wäre, bleibt das Problem, dass es dann relativ klein sein muss. Da ein agiler Prozess auf Effizienz ausgerichtet ist, werden Meetings und Dokumentation möglichst kurz gehalten. Für ein Unterrichtsgespräch sollten sich alle Beteiligten ausreichend Zeit nehmen, um bei Entscheidungen das Für-und-Wider ausgiebig zu diskutieren und um Wissenslücken zu schließen. Ausführliche Dokumentation hilft Lehrenden bei der Kontrolle des Lernfortschritts. Zusammenfassend stelle ich fest, dass agile Prozesse nur von erfahrenen Entwicklern beherrschbar sind, da sie durch ihre starke Produktgetriebenheit leicht ins Chaos abdriften können. Deshalb sind sie bestenfalls für fortgeschrittene Studierende geeignet. Die Abbildung von agilen Entwicklungsprozessen auf Ausbildungsprojekte ist wegen unter- schiedlicher Rollen und Ziele schwierig. Agile Methoden wie Retrospektive, Paararbeit und Unit-Tests lassen sich aber durchaus auch sinnvoll in nicht agile Ausbildungsprojekte integrieren.