Software mit agilen Methoden entwickeln

Bei vielen Softwareprojekten weiss am Anfang niemand genau, wie das Endprodukt aussehen soll. Agile Methoden wie Scrum und Kanban gehen damit um, indem sie in kurzen Zyklen kleine, nutzbare Teile liefern und daraus lernen. In diesem Modul arbeitest du in einem Team nach Scrum: Du schreibst User Stories mit Akzeptanzkriterien, schätzt und planst Sprints, visualisierst die Arbeit auf einem Board in Jira oder Azure Boards und sicherst die Qualität mit einer Definition of Done und Code Reviews. In Reviews und Retrospektiven verbesserst du Produkt und Zusammenarbeit Schritt für Schritt.

Das sind die Fähigkeiten, die am Ende des Moduls sitzen sollten. Jedes Ziel mit einem Beispiel aus dem Lehrbetrieb.

1. 1

   Agile Werte erklären und begründen, wann ein agiles Vorgehen passt

   Kompetenz A

   Du kennst die Grundgedanken des Agilen Manifests und verstehst den Unterschied zu einem phasenorientierten Vorgehen. Du kannst an einem konkreten Vorhaben begründen, ob agil, klassisch oder eine Mischung sinnvoller ist.

   Situation

   Ein Ostschweizer Sportverein will eine App für Trainingsanmeldungen. Der Vorstand hat nur vage Vorstellungen und ändert seine Meinung oft. Gleichzeitig steht im Lehrbetrieb ein Austausch der Server-Hardware an.

   Deine Aufgabe

   Empfiehl für beide Vorhaben ein Vorgehen.

   Gutes Ergebnis

   Für die App ein agiles Vorgehen mit zweiwöchigen Sprints, weil Anforderungen unklar sind und früh Feedback der Trainer:innen nötig ist. Für den Hardwaretausch ein phasenorientiertes Vorgehen, weil Umfang und Ablauf bekannt sind und ein fixer Termin gilt.

   Agiles Manifestiterativ und inkrementellWasserfallFeedbackzyklushybride Vorgehen
2. 2

   Scrum mit Rollen, Events und Artefakten im Team umsetzen

   Kompetenz B

   Du weisst, was Product Owner, Scrum Master und Developers tun, und führst den Sprint mit den Events Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive in der richtigen Form durch. Product Backlog, Sprint Backlog und Inkrement nutzt du bewusst.

   Situation

   Dein Klassenteam von vier Personen soll in sechs Wochen eine Webapp für die Mensa-Menüplanung bauen. Bisher arbeitet jede Person für sich.

   Deine Aufgabe

   Organisiere das Team nach Scrum.

   Gutes Ergebnis

   Rollen verteilt: Lehrperson als Product Owner, eine Mitschülerin als Scrum Master. Drei Sprints zu zwei Wochen. Daily Scrum jeden Unterrichtstag 10 Minuten vor dem Board. Am Sprintende Review mit der Lehrperson, die das Inkrement im Browser testet, danach Retro.

   Product OwnerScrum MasterDevelopersSprintDaily ScrumInkrement
3. 3

   User Stories mit überprüfbaren Akzeptanzkriterien schreiben und das Backlog priorisieren

   Kompetenz C

   Du formulierst Anforderungen aus Sicht der Nutzer:innen, schneidest sie so klein, dass sie in einen Sprint passen, und ergänzt Akzeptanzkriterien im Format Given-When-Then. Das Backlog ordnest du nach Nutzen und Risiko.

   Situation

   Die Mensa-Leitung sagt: 'Die Lernenden sollen sehen, was es gibt, und sich für das Mittagessen anmelden können.'

   Deine Aufgabe

   Schreibe daraus User Stories für das Backlog.

   Gutes Ergebnis

   Story: 'Als Lernende möchte ich das Menü der aktuellen Woche sehen, damit ich planen kann, ob ich in der Mensa esse.' Kriterium: 'Gegeben es ist Montag, wenn ich die Startseite öffne, dann sehe ich die Menüs von Montag bis Freitag mit Preis in CHF.' Die Anmeldung kommt als eigene Story, die Abmeldung bis 9 Uhr als dritte.

   User StoryAkzeptanzkriteriumGiven-When-ThenINVESTProduct BacklogMoSCoW
4. 4

   Aufwand mit Story Points schätzen und einen Sprint realistisch planen

   Kompetenz D

   Du schätzt Stories relativ zueinander mit Planning Poker und der Fibonacci-Reihe. Mit der Velocity vergangener Sprints planst du, wie viel das Team im nächsten Sprint schaffen kann, und zerlegst die Stories in technische Aufgaben.

   Situation

   Das Mensa-Team hat im ersten Sprint 13 Story Points erledigt. Im Backlog stehen Stories mit 8, 5, 5, 3 und 2 Punkten.

   Deine Aufgabe

   Plane den zweiten Sprint.

   Gutes Ergebnis

   Das Team nimmt die Stories mit 8 und 5 Punkten, total 13. Die 8er-Story 'Anmeldung zum Mittagessen' wird in Aufgaben zerlegt: Datenbanktabelle, API-Endpunkt, Formular, Validierung, Test. Bei Planning Poker lagen die Schätzungen zuerst zwischen 3 und 13, nach Diskussion über die Abmeldefrist einigte man sich auf 8.

   Story PointsPlanning PokerVelocitySprint GoalAufgabenzerlegung
5. 5

   Arbeit mit einem Board in Jira oder Azure Boards sichtbar machen und mit WIP-Limits steuern

   Kompetenz D

   Du richtest ein Board mit sinnvollen Spalten ein, verknüpfst Tickets mit Branches und Pull Requests und erkennst Engpässe. Mit Kanban begrenzt du die Anzahl paralleler Aufgaben, damit Arbeit fertig wird, statt liegen zu bleiben.

   Situation

   Das Entwicklungsteam einer Versicherung hat zwölf Tickets 'In Arbeit', aber kaum etwas wird fertig. Reviews bleiben tagelang liegen.

   Deine Aufgabe

   Gestalte das Board so um, dass der Fluss besser wird.

   Gutes Ergebnis

   Spalten 'Bereit', 'In Arbeit (max. 4)', 'Review (max. 3)', 'Test', 'Erledigt'. Ist die Review-Spalte voll, hilft das Team zuerst beim Review, bevor es Neues beginnt. Branch-Namen enthalten die Ticketnummer, z.B. 'feature/VERS-142-praemienrechner', und der Pull Request erscheint automatisch im Ticket.

   KanbanWIP-LimitPull-PrinzipDurchlaufzeitEngpassTicket-Verknüpfung
6. 6

   Mit einer Definition of Done und Code Reviews die Qualität jedes Inkrements sichern

   Kompetenz E

   Das Team legt gemeinsam fest, wann eine Story wirklich fertig ist, z.B. Tests vorhanden, Review erfolgt, Pipeline grün, Doku nachgeführt. Du führst Code Reviews über Pull Requests durch und gibst konstruktives Feedback.

   Situation

   Im Sprint Review stürzt die Mensa-App ab, weil eine 'fertige' Story nie auf dem Testserver ausprobiert wurde.

   Deine Aufgabe

   Erarbeite mit dem Team eine Definition of Done.

   Gutes Ergebnis

   DoD mit sechs Punkten: Akzeptanzkriterien erfüllt, Unit-Tests für die Logik, Pull Request von mindestens einer Person freigegeben, GitHub-Actions-Pipeline grün, auf dem Testserver geprüft, README aktualisiert. Die DoD hängt als Checkliste in jedem Ticket.

   Definition of DoneDefinition of ReadyPull RequestCode ReviewContinuous Integration
7. 7

   Fortschritt mit Burndown-Chart verfolgen und Retrospektiven wirksam durchführen

   Kompetenz F

   Du liest Burndown- oder Burnup-Charts und erkennst früh, ob ein Sprint gefährdet ist. In der Retrospektive sammelst du mit einer Methode wie 'Start, Stop, Continue' Beobachtungen und vereinbarst wenige, konkrete Verbesserungen.

   Situation

   Das Burndown-Chart des Mensa-Teams bleibt bis Tag 7 von 10 fast flach und fällt dann steil ab. Zwei Stories bleiben unfertig.

   Deine Aufgabe

   Analysiere den Verlauf und leite die Retrospektive.

   Gutes Ergebnis

   Der flache Verlauf zeigt, dass Stories lange offen blieben und erst spät abgeschlossen wurden. In der Retro mit 'Start, Stop, Continue' kommt heraus, dass Stories zu gross waren. Massnahme für den nächsten Sprint: keine Story über 5 Punkte, grössere werden vorher aufgeteilt. Verantwortlich: Product Owner mit einer Entwicklerin.

   Burndown-ChartBurnup-ChartSprint ReviewRetrospektiveStart-Stop-Continuekontinuierliche Verbesserung

Die Kompetenzmatrix zerlegt das Modul in Themenstränge und drei Stufen. Für den Kompetenznachweis solltest du überall mindestens Stufe 2 erreichen. Dein Stand bleibt in diesem Browser gespeichert und färbt Lernweg und Übungen ein.

Ilaria ist im 2. Lehrjahr als Informatikerin Applikationsentwicklung bei der Codewerk Hug AG in St. Gallen, einem Softwarehaus mit 35 Mitarbeitenden. Ein Team aus vier Lernenden soll für eine regionale Musikschule ein Portal bauen, über das Eltern ihre Kinder für Instrumentalunterricht anmelden. Bis zum Semesterstart bleiben zehn Wochen, und die Musikschule weiss noch nicht genau, was sie alles braucht.

1. Kapitel 1

   Warum nicht einfach ein Pflichtenheft?

   Der Teamleiter möchte zuerst ein vollständiges Pflichtenheft. Ilaria hält dagegen: Die Sekretärin der Musikschule kann ihre Wünsche erst konkret sagen, wenn sie etwas sieht, und der Semesterstart ist fix. Man einigt sich auf Scrum mit Sprints von zwei Wochen, festem Termin und flexiblem Umfang. Zuerst kommt, was für die Anmeldung zwingend nötig ist.

   Ziel 1

2. Kapitel 2

   Rollen verteilen

   Der Berufsbildner übernimmt die Rolle des Product Owners und hält engen Kontakt zur Sekretärin. Ilaria ist im ersten Sprint Scrum Master, die Rolle wechselt jeden Sprint. Das erste Daily um 08:30 Uhr dauert 40 Minuten, weil zwei Lernende über das Datenbankschema diskutieren. Ilaria verschiebt solche Details ab dem nächsten Tag in ein separates Gespräch direkt nach dem Daily.

   Ziel 2

3. Kapitel 3

   Von Wünschen zu Stories

   Im Workshop mit der Sekretärin entstehen 23 User Stories, etwa «Als Elternteil möchte ich mein Kind für ein Instrument anmelden, damit es ab Semesterstart Unterricht hat». Jede Story erhält Akzeptanzkriterien im Format Given, When, Then. Die Anmeldestory wird beim Planning Poker auf 13 Punkte geschätzt und deshalb in drei kleinere Stories aufgeteilt. Ohne Erfahrungswerte nimmt das Team 15 Punkte in den ersten Sprint und schafft 11.

   Ziel 3Ziel 4

4. Kapitel 4

   Zu viel gleichzeitig

   Auf dem Jira-Board hat jede Person zwei bis drei Tickets in Arbeit, aber fast nichts ist fertig. Das Team führt ein WIP-Limit von 3 für die Spalten In Arbeit und Review ein. Im ersten Review stürzt eine angeblich fertige Story auf dem Testserver ab, weil eine Datenbankmigration fehlt. Die Definition of Done wird ergänzt: Code Review durch eine zweite Person, grüne Tests in GitHub Actions, Deployment auf den Testserver und Abnahme durch den Product Owner.

   Ziel 5Ziel 6

5. Kapitel 5

   Burndown und Retro

   Im zweiten Sprint bleibt das Burndown-Chart bis Tag 6 fast flach, weil Stories im Review warten. Im Sprint Review zeigt das Team das Anmeldeformular, und die Sekretärin wünscht sich eine Warteliste, die als neue Story ins Backlog kommt. In der Retro mit Start, Stop, Continue beschliesst das Team, Review-Anfragen jeden Morgen im Teams-Kanal zu verteilen, und Ilaria übernimmt die Verantwortung dafür. Im dritten Sprint schafft das Team 16 Punkte, und das Chart sinkt gleichmässig.

   Ziel 7

1. 1

   Warum agil?

   ca. 2 Std.

   Du lernst die Grundideen agiler Entwicklung kennen und vergleichst sie mit klassischen Vorgehen.

   • Die vier Werte des Agilen Manifests lesen und je ein Beispiel aus deinem Betrieb dazu finden
   • Das Ballpoint-Game oder ein ähnliches Spiel im Team durchführen und die Erkenntnisse festhalten
   • Für drei Vorhaben begründen, ob agil oder klassisch besser passt

   Trainiert Kompetenz A1A2

   Lernziel1

2. 2

   Scrum-Rahmenwerk verstehen

   ca. 3 Std.

   Du lernst Rollen, Events und Artefakte von Scrum und wie sie zusammenspielen.

   • Den Scrum Guide lesen und den Ablauf eines Sprints als eigene Skizze darstellen
   • Ein Rollenspiel: Product Owner lehnt eine Zusatzforderung mitten im Sprint ab
   • Einen Daily Scrum beobachten, z.B. im eigenen Lehrbetrieb, und notieren, was gut lief

   Trainiert Kompetenz B1

   Lernziel2

3. 3

   Anforderungen als User Stories

   ca. 4 Std.

   Du schreibst Stories, schneidest sie klein und ordnest das Backlog.

   • Aus einer Kundenbeschreibung zehn User Stories mit Akzeptanzkriterien ableiten
   • Zwei zu grosse Stories nach Workflow-Schritten oder Datenvarianten aufteilen
   • Das Backlog mit MoSCoW priorisieren und die Reihenfolge begründen

   Trainiert Kompetenz C1C2

   Lernziel3

4. 4

   Schätzen, planen und das Board aufsetzen

   ca. 4 Std.

   Du schätzt im Team, planst einen Sprint und richtest das Board in Jira oder Azure Boards ein.

   • Planning Poker mit zehn Stories durchführen und grosse Abweichungen diskutieren
   • Ein Scrum- oder Kanban-Board in Jira oder Azure Boards mit eigenen Spalten und WIP-Limits einrichten
   • Git-Branches und Pull Requests mit Tickets verknüpfen

   Trainiert Kompetenz D1D2

   Lernziel45

5. 5

   Qualität im Sprint sichern

   ca. 3 Std.

   Du erarbeitest eine Definition of Done und übst Code Reviews.

   • Mit dem Team eine Definition of Done mit fünf bis sieben Punkten formulieren
   • Zwei Pull Requests von Mitlernenden reviewen und konstruktive Kommentare schreiben
   • Eine einfache CI-Pipeline mit GitHub Actions einrichten, die bei jedem Push die Tests ausführt

   Trainiert Kompetenz E1E2

   Lernziel6

6. 6

   Mini-Projekt mit zwei Sprints

   ca. 6 Std.

   Du durchläufst im Team zwei kurze Sprints von je einer Woche, inklusive Review und Retro.

   • Sprint Planning mit Sprint Goal durchführen und das Burndown-Chart täglich verfolgen
   • Im Sprint Review das Inkrement live vorführen und Feedback ins Backlog aufnehmen
   • Eine Retrospektive moderieren und zwei Massnahmen im nächsten Sprint umsetzen

   Trainiert Kompetenz B2D3E2F2

   Lernziel2746

Scrum

Rahmenwerk für agile Produktentwicklung mit festen Rollen, Events und Artefakten in Sprints.

Sprint

Fester Zeitraum von meist ein bis vier Wochen, in dem das Team ein nutzbares Inkrement erstellt.

Product Backlog

Geordnete Liste aller bekannten Anforderungen an das Produkt, gepflegt vom Product Owner.

User Story

Kurze Beschreibung einer Anforderung aus Sicht einer Nutzerin: Rolle, Wunsch, Nutzen.

Story Point

Relative Schätzeinheit für Umfang, Komplexität und Unsicherheit einer Story.

Velocity

Anzahl Story Points, die ein Team in einem Sprint durchschnittlich abschliesst.

Definition of Done

Gemeinsame Checkliste, wann eine Story als vollständig fertig gilt.

Kanban

Methode zur Steuerung von Arbeit über ein visuelles Board mit begrenzter paralleler Arbeit (WIP-Limits).

Passende Module