Über den Hype hinaus, der um agile Softwareentwicklung entstanden ist, zeigen verschiedene Umfragen, dass dieses Vorgehen in der Praxis in verschiedener Hinsicht tatsächlich zu Verbesserungen in der Durchführung von Software-Projekten führt. Firmen, die agile Methoden einsetzen, geben an, dass sie seither zufriedener mit ihrem Entwicklungsprozess sind und insbesondere der Umgang mit Anforderungsänderungen sich wesentlich verbessert hat. Andererseits sind entsprechend ausgebildete Fachleute jedoch Mangelware. In der Praxis sind deshalb Software Ingenieure mit Kompetenzen in agilen Methoden sehr gefragt. Was bedeutet dies für die Software-Technik Ausbildung an Hochschulen? Was sind die speziellen Herausforderungen? Wie kann agile Software Entwicklung, die neben konkreten Techniken und Praktiken auf der individuellen Ebene, auch auf Team-Ebene und Werte-Ebene spezielle Anforderungen stellt, überhaupt vermittelt werden? Wie kann die Ausbildung von agiler Softwareentwicklung in die Ingenieur-Ausbildung integriert werden?
In diesem Artikel stellen wir unser Konzept zur Ausbildung von agilen Methoden an Hochschulen vor und berichten über unsere Erfahrungen als Dozierende.
Jüngste Umfragen zeigen, dass agile Software
Entwicklungsmethoden in verschiedener Hinsicht zu
wesentlichen Verbesserungen in der Durchführung
von Software-Projekten führt [
In der von den Autoren durchgeführten Studie
(Swiss Agile Study) über den Einsatz von Software
Entwicklungsmethoden in der Schweizer
ITIndustrie [
Um die Relevanz der agilen Methoden für die Ausbildung zu ermitteln, war für uns unter anderem die Beantwortung folgender Fragen wichtig: 1.
Wie verbreitet ist agile Softwareentwicklung in der Praxis? 2. Haben agile Methoden wirklich Vorteile gegenüber den traditionellen, plan-getriebenen Methoden? 3.
Was sind die entscheidenden Erfolgsfaktoren bei der agilen Softwareentwicklung? Im nächsten Abschnitt werden wir die aus unserer Sicht für die Ausbildung wichtigsten Resultate der Studie vorstellen und danach einige Überlegungen und Konsequenzen für die Ausbildung an (Fach-) Hochschulen näher ausführen.
Nach einer Übersicht über die wesentlichen Elemente der agilen Methoden werden wir im Anschluss unsere Konzepte vorstellen. Wir zeigen auf, wie die erforderlichen Kompetenzen vermittelt bzw. von den Studierenden erlernt werden können. Anschliessend berichten wir über den konkreten Umsetzungsstand und unsere Erfahrungen, die wir gemacht haben.
Den Abschluss bildet ein Ausblick über die Weiterentwicklung der Konzepte und deren Umsetzung.
In der Swiss Agile Study wurden mehr als 1500 ITFirmenmitglieder der teilnehmenden ICTVerbände SwissICT, ICTnet und SWEN befragt, die Rücklaufquote betrug knapp 10%. Dabei wurden sowohl agil als auch nicht-agil arbeitende Unternehmen einbezogen. Von den teilnehmenden Unternehmen gaben 57% an, dass sie mit agilen Methoden entwickeln.
Auf die Frage, wie die agilen Methoden die Entwicklung beeinflusst hat, gaben die Unternehmen zu allen befragten Aspekten an, dass sich diese verbessert (+) oder sogar sehr stark verbessert (++) haben (siehe Tabelle 1). Dabei sind insbesondere die Aspekte „Ability to manage changing Requirements“ (89%), „Development Process“ (80%) und „Time To Market“ (76%) zu nennen.
Aspect Time to market 1 Die Bewertungskriterien gehen von „Stark verschlechtert (--) bis „stark verbessert“(++) 2 Sämtliche Angaben in Prozent; die fehlenden Prozent auf 100 gaben an “Weiss nicht”. 3 Die Umfrage wurde auf Englisch durchgeführt, um alle Sprachregionen der Schweiz abdecken zu können, daher sind sowohl die Fragen als auch die Antwort-Optionen auf Englisch.
Kanban Pull System/Limited WIP Tabelle 3. How important were the following agile management and planning practices for your successful agile projects? Ein wichtiger Aspekt ist, dass die Zufriedenheit der Unternehmen mit den agilen Methoden insgesamt Aspect Behavior Driven Development (BDD) Acceptance Test Driven Development (ATDD) Test Driven Development (TDD) Coding standards Collective code ownership Pair programming Unit testing Refactoring Automated builds Continuous integration Automated acceptance testing Continuous delivery Aspect Release planning Story mapping On-site customer Iteration planning User stories Daily standup Taskboard Burndown charts Retrospective Open work area Tabelle 2. How important were the following agile engineering practices for your successful agile projects?3 Bei der Interpretation der Daten ist zu beachten, dass gewisse agile Praktiken wie z.B. TDD, BDD, ATDD auch bei agilen Unternehmen noch relativ wenig im Einsatz sind, wie sich bei der Umfrage gezeigt hat.
Bei den Management Practices wurden als wichtigste Aspekte Iterationsplanung (89%), User Stories (83%) und Release-Planung (77%) genannt, dicht gefolgt vom Einsatz eines Task Boards (74%). -+ ++ werden dabei insbesondere Kodierrichtlinien (82%), Unit Testing (76%) und Continuous Integration (70%) genannt. -+
++ 24 22 16 9 12 32 17 25 14 16 26 23 18 26 27 7 10 25 20 38 28 25 23 17 20 29 40 33 25 25 35 26 32 28 38 37 41 33 36 40 32 45 22 34 40 13 21 18 10 4 12 20 2 3 8 4 20 12 11 3 4 0 0 4 2 5 11 12 27 8 17 30 42 30 18 51 28 40 38 14 17 40 21 24 53 43 33 29 24 30 11 4 deutlich höher ist als mit traditionellen plangetriebenen Vorgehen (84% vs. 62%).
Im Rahmen der Studie haben wir auch erhoben, ob agile Methoden überhaupt auf universitärer Stufe unterrichtet werden sollten, und wie die Kenntnisse der Bachelor- und Master-Absolventen von der Industrie beurteilt werden. Dazu hatten die Firmenvertreter der teilnehmenden IT-Firmen folgende Aussage zu bewerten: „Agile development should be an integral part of the Computer Science curriculum“.
Zur Auswahl standen folgende Antwort-Optionen von “Stimme vollständig zu” bis “Stimme gar nicht zu”. 95% der teilnehmenden Firmen stimmen der Aussage zu („Stimme zu“: 49%, „Stimme vollständig zu“: 46%).
Andererseits geben die Unternehmen auf die Frage, ob die Studienabgänger auf Bachelor- bzw. Masterstufe genügend Kenntnisse in agilen Methoden mitbringen mit klarer Mehrheit an, dass dies nicht der Fall ist (Master-Stufe: 58%, Bachelor-Stufe: 68%).
Somit sollte der Anspruch der Praxis an die Hochschulen ernst genommen werden und die Ausbildung an die neuen Anforderungen angepasst werden. Dabei stellt sich die Frage, was die Hochschulen in der Ausbildung ändern müssen, um den neuen Anforderungen gerecht zu werden. Dazu betrachten wir Anforderungen, die agile Methoden an den einzelnen aber auch an das Team und die Organisation stellt, auf drei verschiedenen Ebenen: 1. Individuelle Ebene: Hier geht es vornehmlich darum, welche agilen Engineering Practices ein Software Ingenieur beherrschen sollte: Clean Code, Test Driven Development, Automation, Craftsmanship, um nur einige Beispiele zu nennen. 2. Team Ebene: Die Team Ebene stellt vor allem Anforderungen im Bereich Management Practices: Selbstorganisierende Teams, Schätzen und Planen, Continuous Integration und Continuous Deployment, oder Pair Programming. Selbstorganisierende Teams wiederum verlangen eine hohe soziale Kompetenz der Teammitglieder, wie zum Beispiel hohe Kommunikationsfähigkeit. 3. Werte Ebene: Auf dieser Ebene wird implizit das Wertesystem der agilen Softwareentwicklung betrachtet; wie die agilen Werte wie Respekt, Offenheit, Ehrlichkeit, etc. vermittelt werden können, so dass die Absolventen „in der Wolle gefärbte“ Software Ingenieure sind.
Bei der Vermittlung der Anforderungen beziehen
wir uns schwerpunktmässig auf Scrum [
Zum Thema der Integration von agilen Methoden
in den Unterricht liegen verschiedene
Erfahrungsberichte vor [
Wir haben festgestellt, dass die Studierenden noch relativ wenig Wissen über agile Softwareentwicklungsmethoden mitbringen, wobei sich der Wissenstand in den letzten Jahren leicht verbessert hat, aber je nach Fachhochschule sehr unterschiedlich ist. Dafür beobachten wir jedoch, dass das Interesse der Studierenden an dem Thema umso grösser ist.
In unserer gemeinsamen Vorlesung haben wir den Fokus ganz gezielt auf agile Softwareentwicklung gelegt. Unter anderem unterrichten wir agile Software Entwicklungsmethoden wie Scrum, eXtreme Programming oder Kanban. Dabei haben wir die Erfahrung gemacht, dass viele Studierende das „Programmier-Handwerk“, welches eine der Voraussetzungen für die erfolgreiche Durchführung agiler Projekte darstellt, nicht beherrschen resp. nie im Bachelor-Studiengang gelernt hatten. Unter „Programmier-Handwerk“ verstehen wir das Beherrschen von agilen Praktiken wie zum Beispiel Clean Code, Refactoring, Test-Driven Development oder Continuous Integration.
Weiter halten die Autoren jeweils an ihrer
Fachhochschule [
Für ein besseres Verständnis der im Folgenden vorgestellten Studienkonzepte und Lehr- und Lernmethoden fassen wir hier die aus unserer Sicht wichtigsten Eigenschaften der agilen Softwareentwicklung zusammen.
In erster Linie sind dabei natürlich die Werte und
Prinzipien des Agile Manifesto [
Aus diesen Prinzipien hat insbesondere extreme Programming (XP) eine Anzahl ganz konkreter Programmierpraktiken abgeleitet, ohne die aus unserer Sicht eine agile Softwareentwicklung nicht möglich ist.
Auf Managementsicht gehört wohl Scrum zu den Vorreitern der agilen Methoden. Scrum definiert klare Regeln bzgl. Projekt- und Teamorganisation sowie dem Requirements-Management.
Neuere Ansätze wie Lean Software Development
[
Die folgenden Tabellen fassen die aus unserer Sicht wichtigsten Engineering und Management Practices zusammen. Diese Einteilung wurde von uns für die Studie entwickelt, um die Verbreitung der genannten Praktiken in der Praxis zu ermitteln und hat sich dabei als sehr zweckmässig erwiesen; wir verwenden sie daher auch in diesem Artikel als Grundlage für die folgende Diskussion über die agile Ausbildung.
Tabelle 4 gibt die Verbreitung der, vor allem von XP definierten, konkreten Programmierpraktiken in den befragten agilen Unternehmen wieder, während Tabelle 5 die Verbreitung der Management Praktiken aufzeigt. Besonders erwähnenswert dabei ist, dass diese entsprechenden Werte bei plangetrieben arbeitenden Unternehmen zwischen 10%-30% tiefer liegen. Dies ist doch umso bemerkenswerter, als es sich bei vielen Engineering Practices eigentlich nicht um spezielle agile Praktiken, sondern um allgemeine Best Practices handelt. Es lässt sich also sagen, dass die Anwendung von agilen Methoden auch zur verstärkten Anwendung von allgemeingültigen Best Practices führt. Tabelle 4. Engineering Practices in der Praxis4 Management Practices Verbreitung
Kanban Pull System/Limited WIP Tabelle 5. Management Practices in der Praxis5. Die Werte zeigen deutlich, dass auch bei agil entwickelnden Unternehmen erst relativ wenige der erforderlichen bzw. empfohlenen Praktiken eine breite Anwendung finden.
Die Eigenschaften bzw. Anforderungen an eine agile Software Entwicklung lassen sich nicht alle auf die gleiche Art unterrichten, da sie unterschiedliche Kompetenzen ansprechen. Für die Entwicklung eines geeigneten Studienkonzeptes orientieren wir uns daher an den zuvor eingeführten drei Kompetenzebenen. 4 Den Firmen, die agile Methoden anwenden, wurde folgende Frage gestellt: „Which of the following engineering practices could be observed by someone visiting your company in the next month“? 5 Den Firmen, die agile Methoden anwenden wurde folgende Frage gestellt: „Which of the following management and planning practices could be observed by someone visiting your company in the next month“?
Auf der individuellen Ebene werden insbesondere die handwerklichen Grundlagen vermittelt. Ohne das Beherrschen dieser fundamentalen Techniken ist eine agile Entwicklung aus unserer Sicht nicht möglich. Aus unserer Erfahrung sind die agilen Techniken der individuellen Ebene am einfachsten zu vermitteln. Dies liegt unserem Ermessen nach daran, dass jeder Studierende einzeln daran arbeiten kann.
Darauf aufbauend können dann die Techniken der agilen Entwicklung auf der Team-Ebene vermittelt und erworben werden, die sich vor allem aus den Management Praktiken zusammensetzen. Diese Aspekte lassen sich aus unserer Erfahrung heraus sehr gut in Gruppen- und Projektarbeiten vermitteln. Die Konzeption, Organisation und Durchführung solcher Arbeiten ist aufwendig.
Sozusagen die Spitze der Kompetenzen der Agilen
Entwicklung bildet die Werte-Ebene. Diese agilen
Wertehaltungen wie sie im Agile Manifesto [
Aufgrund der sich schon früh abzeichnenden
zunehmenden Bedeutung der agilen
Entwicklungsmethoden haben wir begonnen die grundlegenden
Methoden und Techniken der agilen Software
Entwicklung in Form der genannten Management und
Engineering Praktiken in das Bachelor-Programm
zu integrieren [
Auf Master-Stufe behandeln wir in unserem gemeinsamen Kurs „Software Engineering and Architecture“ fortgeschrittene Themen der agilen Software Entwicklung wie Lean Development und Kanban, Incremental Software Design und Software Evolution.
Neben konventionellen Vorlesungen und Programmierübungen verwenden wir als weitere Unterrichtmethoden:
Gastreferate mit Referenten aus der Software-Industrie
Wichtig ist die Repetition auf allen Ebenen, d.h. regelmässiges Üben in verschiedenen Kontexten. Deshalb kommen die verschiedenen Praktiken und Techniken immer wieder in den verschiedenen Vorlesungen vor. Nicht isoliertes Unterrichten der einzelnen Praktiken steht im Vordergrund, sondern die Verankerung an mehreren Stellen in der Ausbildung. Das unterstützt insbesondere auch die Werte Ebene, in dem die Dozierenden selbst im Rahmen ihrer Möglichkeiten diese agilen Werte vorleben.
Obwohl an den beiden Fachhochschulen, auch was das Themengebiet Software Engineering angeht, unterschiedliche Studienpläne existieren, haben sich, unterstützt durch den intensiven Austausch, viele Gemeinsamkeiten in der Vermittlung der agilen Methoden ergeben.
Abbildung 1 zeigt als ein mögliches Beispiel einen Abbildung 1. Grundstudium Informatik Ausschnitt des Informatik Bachelor-Programms der Fachhochschule Nordwestschweiz.
Das fachliche Grundstudium im Bachelorstudiengang ist aufgeteilt in die vier Themenbereiche, Modulgruppen genannt, Programmierung, Software Engineering, sowie ICT Systeme und Mathematik. Jede Modulgruppe besteht aus je 8 Modulen, die spezielle Themen aus der jeweiligen Modulgruppe abdecken. Jedes Modul hat einen Umfang von 3 ECTS Punkten.
Begleitet wird die theoretische Ausbildung in den Modulen durch eine vom ersten Semester an beginnende Projektschiene, die sich bis in das 6. Semester fortsetzt. In dieser setzen die Studierenden in grossen Teams (7 bis 8 Studierende) und an realen, d.h. von externen Kunden in Auftrag gegebenen Projekten, die Theorie in die Praxis um. Dabei werden in den beiden Jahresprojekten der ersten 4 Semester unterschiedliche Schwerpunkte gesetzt. Die explizite Ausbildung in agilen Methoden wird insbesondere in den Modulen Software Konstruktion im 2. Semester und Software Projekt Management im 3. Semester der Modulgruppe Software Engineering vorgenommen. In den Projekten und den sonstigen „programmierlastigen“ Modulen wird darauf geachtet, dass auch hier die vermittelten agilen Praktiken zum Einsatz kommen. In den folgenden Kapiteln beschreiben wir, wie wir an beiden Fachhochschulen die verschiedenen Praktiken und Techniken im Unterricht vermitteln.
Bei der Besprechung der Practices orientieren wir uns an der Liste aus Tabelle 4.
Bereits im ersten Semester führen wir Coding
Standards in der Einführungsvorlesung ins
Programmieren ein. Wir kombinieren Coding Standards mit
Clean Code [
Das Feedbackgeben durch den Dozierenden ist zwar mit einen grossem Aufwand verbunden, ist aus unserer Erfahrung aber entscheidend für den Lernerfolg.
Coding Standards müssen natürlich durch die
verwendete integrierte Entwicklungsumgebung
(IDE) unterstützt werden. Minimal sollte die IDE
auch Unterstützung für einfache Refactorings wie
Rename Method oder Rename Variable bieten.
Ebenfalls gute Erfahrungen haben wir mit
Werkzeugen wie Checkstyle [
Sehr positive Erfahrungen haben wir mit dem frühzeitigen Einsatz dieser Konzepte und Werkzeuge (z.B. im 2. Semester im Rahmen des Modul Software Konstruktion) zusammen mit Continuous Integration Umgebungen gemacht. Durch eine frühe Einführung werden die Studierenden animiert, diese Praktiken auch in ihren Projekten einzusetzen, was auch sehr häufig auf freiwilliger Basis geschieht, da sie die Vorteile solcher Umgebungen schon früh erkennen.
Unit Testing wird im ersten Semester eingeführt. Dabei ist besonders wichtig, dass diese Praktik nicht nur in speziellen Modulen unterrichtet wird, sondern, dass auch sonstige programmierlastige Module Unit Tests einfordern oder vorgeben, um so z.B. die erfolgreiche Implementierung einer Programmieraufgabe zu überprüfen.
So können zum Beispiel im ersten Semester während der Einführung ins Programmieren Unit Tests bei Übungen vorgegeben werden. Die Aufgabe gilt als erfüllt, wenn das zu entwickelnde Programm alle Unit Test besteht. Die Studierenden lernen so spielend die Nützlichkeit von automatischen Tests kennen und erleben nebenbei, wie wertvoll Tests als Dokumentation sind.
Anschliessend wird das automatische Testen mit White-Box/Black-Box Tests und Äquivalenzklassen formal eingeführt. Die Studierenden sind dann in der Lage, einfache Testfälle selbstständig zu schreiben. In den höheren Semestern werden mit zunehmendem Know-how anspruchsvollere Testfälle mit Mock-Objekten entwickelt und verschiedene Testmuster eingeführt. Das automatische Testen sollte sich durch möglichst alle programmier-nahen Vorlesungen durchziehen.
Ein anderer erprobter Weg ist, dass die Studierenden schon vom ersten Semester an in den Programmier-Modulen das Schreiben von einfachen Unit-Tests mittels Unit Testing Frameworks kennenlernen und in den Projekten anwenden. Anschliessend erhalten sie im zweiten Semester im Modul Software Konstruktion eine vertiefte Einführung in das systematische Testen und fortgeschrittene Themen wie Mock Testing kennen, die sie dann wiederum in den Projektarbeiten für das fortgeschrittene Testen einsetzen können.
Test Driven Development (TDD) baut auf automatischen Unit Tests auf. Neben Kenntnissen in Unit Testing brauchen die Studierenden auch Kenntnisse in Refactoring. Mit anderen Worten sind gute Kenntnisse in Refactoring eine Voraussetzung für TDD.
Die einfachsten Code-Refactorings werden bereits am Anfang des Studiums zusammen mit den Coding Standards und der IDE Unterstützung eingeführt. Komplexere Design-Refactorings werden in den folgenden Semestern eingeführt. Dazu wird ein Katalog der verschiedenen Refactorings abgegeben und mit den Studierenden durchgearbeitet. Ergänzt wird dieses Thema durch die Anwendung von komplexeren Refactorings wie Extract Class, Extract Method, Move Method anhand von Case Studies z.B. bei Überschreitungen von Schwellwerten bei Qualitätsmetriken.
TDD ist eine anspruchsvolle Engineering Practice. Um TDD wirklich zu beherrschen, wäre es am Besten, wenn die Studierenden einen erfahrenen Software-Entwickler als Coach zur Seite hätten. Da dies im Rahmen einer Vorlesung oder Übungsstunde nicht wirklich realisierbar ist, sind alternative Vorgehensweisen nötig: Bewährt haben sich folgende Alternativen: Case Studies Programming Katas Experten Videos Bücher und Fachartikel Während den Studierenden mittels Experten Videos und Fachliteratur die konzeptionellen Aspekte des TDD vermittelt werden können, sollen Case Studies und Programming Katas den Studierenden dazu dienen, den TDD Ansatz praktisch zu üben und insbesondere dessen Einfluss auf Testbarkeit und Software Design selbst zu erfahren.
Automated Builds werden mit Hilfe von AntSkripts und einem Code Versioning System (CVS) wie zum Beispiel SVN oder GIT eingeführt. Um den vollen Nutzen der Build-Automatisierung zu erfahren, bauen die Studierenden anhand einer konkreten Case Study über ein ganzes Semester ein Automatisierungsskript kontinuierlich aus, so dass das Kompilieren, Testen, Code Analysieren, als auch das Packaging der Software vollständig automatisiert durchgeführt werden kann.
Automated Builds sind eine Voraussetzung für Continuous Integration und werden im nächsten Kapitel genauer angeschaut.
Automated Builds und Continuous Integration werden mittels einer konkreten Fallstudie in einer Gruppenarbeit vermittelt und ebenfalls schon frühzeitig im Studium eingeführt (z.B. im Rahmen des Moduls Software Konstruktion im 2. Semester). In einem ersten Schritt wird das Beispielprojekt in ein Code Versioning System importiert. Im zweiten Schritt werden die Build-Skripts entwickelt, damit das Beispielprojekt automatisiert gebaut werden kann. Im dritten Schritt Konfigurieren die Studierenden den CI-Server (Jenkins). Im vierten Schritt werden verschiedene Jenkins-Erweiterungen besprochen und ausprobiert. Dabei werden verschiedene Metriken wie Code Coverage, Bindungsstärke von Klassen, Code Complexity, aber auch Lines of Code (LOC) behandelt.
Fortgeschrittene Metriken werden in höheren
Semestern (Bewertung einer Software Architektur im
4. Semester Software Entwurf [
Der nachhaltige Erfolg der frühzeitigen Einführung dieser Praktiken zeigt sich unter anderem daran, dass Studierende selbstständig eine solche Infrastruktur für ihre Projektarbeiten anfordern und einsetzen.
Pair Programming üben wir nicht speziell. Es wird zusammen mit den anderen Engineering Practices eingeführt und die Studierenden werden ermuntert, Pair Programming bei Gelegenheit gezielt einzusetzen und für sich zu entscheiden, ob es für sie eine Option darstellt oder nicht.
Wir haben die Beobachtung gemacht, dass die meisten Studierenden ganz automatisch eine Form von Pair Programming einsetzten. Sehr oft setzten sich zwei Studierende zusammen an einen Computer und lösen eine Programmieraufgabe gemeinsam. Es scheint also so etwas wie eine natürliche Vorgehensweise beim Programmieren zu sein.
Auf Automated Acceptance Testing gehen wir
ebenfalls im Rahmen der Vorlesung Software
Konstruktion ein. Es wird ein Überblick über das
Konzept anhand des Test Frameworks Fit [
Ebenso wie Pair Programming wird auch das Thema der Collective Code Ownership nicht explizit unterrichtet. Die Studierenden werden jedoch durch Verwendung von Versionskontrollsystemen, Anwendung von Coding Standards und Wechseln der Verantwortlichkeiten in den Projekten dazu ermuntert, diese Praktik auszuprobieren.
Die weiteren Engineering Practices wie Continuous delivery, Acceptance Test Driven Development (ATDD) oder Behavior Driven Development (BDD) sprengen unserer Ansicht nach den Rahmen eines Bachelor Studiums. Denkbar, und aus unserer Sicht auch sinnvoll, wäre es, diese weiteren Engineering Practices zukünftig im Master Studium zu behandeln, da wir davon ausgehen, dass diese Praktiken in Zukunft an Bedeutung gewinnen werden.
Wie aus Tabelle 5 zu entnehmen ist, sind bei den Management Practices diejenigen am weitesten verbreitet, welche sich direkt mit der Projektplanung befassen. Nicht unerwartet wird die Planung vorwiegend unter Verwendung von User Stories gemacht. Überraschenderweise sind Retrospektiven in der Praxis, trotz deren unbestritten hohem Nutzen, nicht sehr weit verbreitet.
Die Management Practices betreffen vorwiegend die
Team Ebene. Teamarbeiten sind im Gegensatz zu
den Engineering Practices, welche vorwiegend die
Individuelle Ebene betreffen, nicht einfach in den
Unterricht zu integrieren. Die meisten Management
Practices können nur sinnvoll in einem grösseren
Team im Rahmen eines „richtigen“ Projekts
sinnvoll geübt werden. Oft ist es aber nicht
zweckmässig oder aus zeitlichen Gründen unmöglich, ein
solches Projekt durchzuführen. In diesem Fall kann
die Situation mit einem der agilen Games wie zum
Beispiel dem XP-Game [
Als agile Projektmethode verwenden wir Scrum. Die verschiedenen Studien zeigen, dass Scrum am weitesten verbreitet ist. Scrum bietet auch den Vorteil, dass die Anzahl der roles, events und artifacts klein ist.
Wir haben die Erfahrung gemacht, dass die Funktionsweise von Scrum schnell im Unterricht erklärt werden kann. Der schwierige Teil kommt bei der Einführung. Wenn die Studierenden Scrum (oder eine andere Projektmethode) wirklich anwenden sollen. Wie kann im Unterricht ein Klima geschaffen werden, so dass die Studierenden sich wie in einem „echten“ Projekt fühlen? Wenn sie das Gefühl haben, dass es sich um ein „Alibi“-Projekt handelt, setzten sie sich nicht ein und profitieren entsprechend wenig.
Das XP-Game [
Das XP-Game wurde bis jetzt vier Mal mit je ca. 25
Studierende im Master-Studiengang im Rahmen
des Moduls „Software Engineering and
Architecture“ (3 ECTS) [
Interessant sind dabei folgende Beobachtungen: Die erste Iteration ist typischerweise sehr chaotisch. Die Schätzungen sind schlecht und die Selbstorganisation der Teams funktioniert nicht.
Nach der Retrospektive am Anschluss an die erste Iteration nimmt die Selbstorganisation der Teams merklich zu. Ab der zweiten Iteration funktionieren die Teams, die Schätzungen werden viel besser.
Die Velocity wird erstaunlich konstant.
Der Lerneffekt in dieser kurzen Zeit ist sehr gross. Die Studierenden sind aktiv am arbeiten.
Das Feedback der Studierenden ist durchwegs positiv. Die Studierenden schätzen es insbesondere auf eine spielerische Art einen grossen Lerneffekt zu erzielen.
Ein alternativer Ansatz um agile Management
Praktiken zu vermitteln und, insbesondere, zu
erfahren, ist das Scrum Lego City Game [
Wir führen das Scrum Lego City Game in Gruppen von 6 bis 7 Studierenden in leicht abgewandelter Form über mehrere Wochen durch:
An Stelle von (teuren) Lego-Bausätzen wird die Stadt aus Karton und Papier mit Farbstiften Scheren und Klebstoff gebaut.
Das Schreiben der User Stories ist Teil der Aufgabenstellung. Um zu verhindern, dass die Entwickler ihre eigenen Anforderungen schreiben, bekommt der Product Owner (PO) eines Teams die Entwickler eines anderen Teams als Benutzer zugewiesen und definiert mit diesen die Anforderungen für „sein“ Team.
Auch die Priorisierung der User Stories durch den PO und das Schätzen durch das Entwicklerteam gehören zur Aufgabe.
Danach werden in insgesamt 3-4 Sprints die Aktivitäten wie Sprint-Planung, Task Breakdown, Sprint Review, Retrospektive, Arbeiten am Scrum Board in Mini-Sprints von 10 Minuten Dauer durchlaufen. Aufgrund der kurzen Sprints entfällt der Daily Scrum.
Die dabei gemachten Erfahrungen decken sich durchwegs mit jenen des XP Games. Ein weiterer wichtiger Aspekt ist die Einprägsamkeit der verschiedenen Konzepte durch das konkrete Anwenden in dieser Spielform.
In einem neuen Software Engineering Modul im 5. Semester wird ein anderer Weg beschritten. Die Studierenden sollen die Individuelle-, Team- und Werte-Ebenen während einem Semester möglichst intensiv erfahren und verinnerlichen. Die Vorlesung ist als eigentlicher „Crash“-Kurs für „agile Software Engineering“ konzipiert.
In der ersten Hälfte des Semesters liegt der Fokus auf der Individuellen Ebene. Es gibt eine ausführliche Einführung in die Engineering Practices von eXtreme Programming: Coding Standards, Unit Testing, Continuous Integration (CI), etc. Die Studierenden werden mit dem automatischen Build Process bekannt gemacht und nach der Hälfte des Semesters haben sie bereits einen kompletten CIServer in Betrieb genommen.
In der zweiten Hälfte liegt der Fokus auf der Team Ebene. Die Studierenden sollen in Gruppen von sechs bis acht Mitgliedern während den restlichen sieben Wochen ein eigenes 2D-Computerspiel entwickeln. Dazu bekommen sie eine ausführliche Einführung in Scrum sowie in agiler Schätzung und Planung.
Die Studierenden schreiben die User Stories, schätzen die Tasks und planen die Iterationen. Eine Iteration dauert nur eine Woche und der Umfang ist dementsprechend klein. Längere Iterationen sind nicht zweckmässig, da das Projekt mit nur sieben Wochen extrem kurz ist.
Die Dozierenden nehmen bei jeder Gruppe am wöchentlichen Sprint-Meeting teil und unterstützen die einzelnen Teams. Es wird grosser Wert auf die Planung und Retrospektive gelegt.
Die Dozierenden coachen die einzelnen Teams und geben Unterstützung bei auftretenden Schwierigkeiten. Sie versuchen auch, den Teams einen „Spiegel“ vorzuhalten, damit sie ihre Entscheidungen reflektieren und dadurch die Konsequenzen der getroffenen (und natürlich auch der nicht getroffenen) Entscheidungen besser verstehen.
Der Wert dieses Scrum-Projekts besteht in der Kombination der Engineering Practices mit den Management Practices in einer realistischen Projektsituation. Während des Projekts gibt es auch oft Gelegenheit für den Coach, die Werte der agilen Softwareentwicklung einfliessen zu lassen.
In den Projekt- und Bachelorarbeiten ist es den einzelnen Dozierenden überlassen, ob sie die Aufgabe mit einer agilen Projektmethode lösen lassen oder nicht.
Vor allem in der sogenannten „Projektwoche“, in der die Projektteams einmal pro Semester eine ganze Woche am Stück an ihren Projekten arbeiten können, wird insbesondere das Taskboard für die intensive Teamarbeit genutzt.
Bei externen Projekten ist es eine Herausforderung auch die externen Auftraggeber für das agile Vorgehen zu überzeugen, da dies ein grösseres Engagement des Kunden erfordert. Die Erfahrungen mit solchen Projekten sind jedoch mehrheitlich positiv. Eine Schwierigkeit, Projektarbeiten nach agilem Vorgehen zu organisieren, ist, dass in diesen Arbeiten die Teams aus Zeitgründen in der Regel nur einmal pro Woche gemeinsam am Projekt arbeiten können, sonst eher getrennt (z.B. Zuhause). Ein „Daily Standup“ ist daher in der Regel nicht möglich. Die Studierenden machen daher eher ein Meeting, in dem sie sich gegenseitig auf den neuesten Stand bringen. Statt einer Pinnwand als Scrum Board, werden häufig digitale Boards eingesetzt, die jedoch nicht so einfach zu bedienen sind wie Pinnwände und nicht die gleiche Flexibilität aufweisen. Daher werden diese oft nicht mit der notwendigen Sorgfalt verwaltet.
Welche Erfahrungen haben wir nun mit dem Unterrichten von agilen Methoden gemacht, und wie wird dieses Vorgehen von den Studierenden aufgenommen? Unsere Erfahrungen sind durchwegs positiv, auch wenn noch einige Herausforderungen bestehen. Die Studierenden sind sehr offen gegenüber den agilen Methoden, da sie den Fokus stärker auf die eigentlichen Interessen der Studierenden, die Konstruktion der Software durch Design und Programmierung, legen. Das Feedback der Studierenden ist entsprechend ermutigend.
Gerade auch der Nutzen von Test-getriebener Entwicklung und der Automatisierung mittels CI Umgebungen wird für die Studierenden sehr schnell ersichtlich und, erfreulicherweise, von diesen dann selbst in Projektarbeiten eingesetzt.
Unterschätzt wird häufig das disziplinierte Vorgehen, welches agile Methoden vom gesamten Projektteam z.B. bei der iterativen Planung und der Software Qualität, einfordern. Hier gilt es sicherlich von der Ausbildungsseite her, ein Augenmerk darauf zu haben.
Die Simulationen von agilem Vorgehen mittels Games (XP, Scrum) hat sich sehr bewährt. In den Games „erfahren“ die Studierenden wichtige agile Konzepte wie selbst-organisierte Teams und häufige Auslieferungen in sehr intensiven MiniProjekten, die sich entsprechend einprägen. Im Hinblick darauf, dass vor allem die agilen Werte, aber auch deren Praktiken nicht durch einmaliges Vermitteln sondern durch Vorleben und ständige Anwendung erlernt werden müssen, ist es wichtig, dass diese Praktiken auch in den sonstigen Programmiermodulen zum Einsatz kommen. Die neuen zusätzlichen Anforderungen an die Dozierenden sind dabei nicht zu unterschätzen. Die Dozierenden der entsprechenden Module müssen sich die notwendigen Grundlagen aneignen. Die Vorlesungen müssen entsprechend angepasst, und die agilen Praktiken in die eigenen Module intergiert werden. Der höhere Aufwand der Dozierenden ist sicher eine Herausforderung, welcher aber aus unserer Sicht durch das gute Resultat mehr als gerechtfertigt ist.
Ein weiterer wichtiger Vorteil der Vermittlung der agilen Methoden ist, dass die vor allem von XP propagierten allgemeinen Best Practices viel stärker ins Bewusstsein der Studierenden rücken und auch eine stärkere Akzeptanz erfahren, da mit jeder Iteration eine Qualitätskontrolle stattfindet.
Wie unsere und auch internationale Studien zeigen, sind agile Software Entwicklungsmethoden in der Praxis sehr stark im Kommen. In der IngenieurAusbildung müssen wir uns den geänderten Kompetenzanforderungen stellen und unsere Ausbildungskonzepte entsprechend anpassen und erweitern.
Im vorliegenden Artikel haben wir beschrieben, wie wir die Vermittlung von agilen Softwareentwicklungsmethoden an unseren Fachhochschulen integriert haben. Die Erfahrungen damit sind sehr positiv und die erzielten Erfolge stimmen zuversichtlich. Erste Feedbacks aus der Praxis über die Kompetenzen der Abgänger bestätigen unseren eingeschlagenen Weg.
Eine generelle Herausforderung bleibt, die agilen Konzepte nicht nur in einzelnen Modulen zu unterrichten, sondern diese in möglichst vielen programmier-nahen Modulen anzuwenden und zu vermitteln, was generell ein Wechsel des Unterrichtskonzept der isolierten Fachmodule hin zu einem integrativem Gesamtstudienkonzept bedeutet.
Auf Master-Stufe wollen wir die Vermittlung fortgeschrittenen Engineering und Management Practices weiter ausbauen, da diese in Zukunft eine zunehmende Bedeutung erlangen werden.
Zum Schluss sei angemerkt, dass auch die agilen Softwareentwicklungsmethoden nicht das Ende der Entwicklung der Softwareprozesse darstellen. Die Informatik ist immer noch eine sehr junge Disziplin, deren Entwicklungsprozessmodelle sich stetig weiterentwickeln werden. Aus Sicht der IngenieurAusbildung ist es daher zentral, sich abzeichnende Entwicklungen in der Ausbildung vorwegzunehmen und damit einen Beitrag dazu zu leisten, dass moderne Entwicklungsmethoden ihren Einzug in die Praxis halten.