| Kompetenzband | HZ | Beginner (B) | Intermediate (I) | Advanced (A) |
|---|---|---|---|---|
| A – Agile Methoden kennen | 1 | A1B: Ich kann die linearen Vorgehensmodelle wie das Wasserfall-Modell, das V-Modell und RUP sowie die zyklischen Modelle wie das Spiralmodell und die unterschiedlichen Prototypenverfahren erläutern | A1I: Ich kann das "Agile Manifesto" und dessen Prinzipien erklären und aufzeigen, was daran gut ist und wo Probleme auftauchen können | A1A: Ich kann die linearen und die zyklischen Vorgehensmodelle erkennen und aufzeigen, wie das Beste von allem kombiniert werden kann |
| 1 | A2B: Ich kann das SCRUM-Modell mit dem zyklischen Ablauf, den Rollen, den Zeremonien (Meetings/Sitzungen) und die Philosophie von SCRUM erklären | A2I: Ich kann aufzeigen, wie ein Vorhaben in eine "Vision", in "Epics" und in "User-Stories" formuliert werden kann | A2A: Ich kann ein Vorhaben mit meinem Team in einen SCRUM-Ablauf einkleiden und die richtigen Schritte planen | |
| 1 | A3B: Ich kann die drei Aspekte erklären, wie man eine Anforderung in einem Satz für eine User-Story formuliert | A3I: Ich kann unter Einhaltung der DoR eine User-Story beschreiben, sie gemeinsam mit dem Team einordnen und deren Aufwand mit Story Points bewerten (Planning Poker) sowie Abnahmekriterien dafür bestimmen (DoD) | A3A: Ich kann den "guten" Schnitt zwischen User-Story und Aufgaben-Tasks zusammen mit dem Team bestimmen | |
| B – Agile Iteration realisieren | 2 | B1B: Ich kann bestehende Softwaremodule interpretieren und erklären, wo für die Umsetzung einer User Story die Software ergänzt werden muss | B1I: Ich kann die Software für die Umsetzung einer User Story implementieren | B1A: Ich kann bestehende Software für die Umsetzung einer User Story anpassen (Refactoring) |
| 2 | B2B: Ich kann die Bedeutung einer lauffähigen Software im Rahmen der agilen Softwareentwicklung erläutern | B2I: Ich kann die von mir umgesetzte User-Story anhand der lauffähigen Software präsentieren und zeigen, dass die DoD eingehalten sind | B2A: Ich kann eine Sprint-Demo vorbereiten (inkl. Burndown Chart) und durchführen | |
| C – Komponenten wiederverwenden | 3 | C1B: Ich kann das Prinzip von Softwarekomponenten (Wiederverwendbarkeit, Aufgabenaufteilung, Schnittstellen) an einem Beispiel erläutern | C1I: Ich kann für eine Applikation, unter Berücksichtigung der Wiederverwendbarkeit, Softwarekomponenten evaluieren und auswählen | C1A: Ich kann in einem Entwurf Softwarekomponenten identifizieren, deren Wiederverwendbarkeit beurteilen und begründet integrieren |
| D – Vorgehen reflektieren und verbessern | 4 | D1B: Ich kann erklären, wie ich mich auf das Daily Scrum vorbereite | D1I: Ich kann meine Erfahrungen und Erkenntnisse an der Retrospektive einbringen und geeignete Verbesserungsmassnahmen ableiten | D1A: Ich kann eine Retrospektive vorbereiten und anleiten sowie die gewonnenen Erkenntnisse priorisieren und in konkrete Verbesserungsmassnahmen überführen |
| E – Versionsverwaltung anwenden | 5 | E1B: Ich kann ein Repository klonen, Änderungen committen und pushen sowie Änderungen vom Server übernehmen (fetch, pull) und das Anwenden von Branches erklären (z. B. Git-Flow) | E1I: Ich kann mit Merge Requests umgehen und Branches gezielt anwenden (z. B. Git-Flow) | E1A: Ich kann Merge-Konflikte lösen, den Git-Tree kritisch hinterfragen und Verbesserungen umsetzen (z. B. rebase, cherry-pick) |
| F – Umgang mit Clean Code und Refactorings | 6 | F1B: Ich kann erklären, was zur guten Lesbarkeit von Code wichtig ist und welche Regeln es zu beachten gibt | F1I: Ich kann einen Code durch die Anwendung der "Clean Code"-Empfehlungen besser lesbar machen und ein Refactoring durchführen | F1A: Ich kann Funktionsbereiche zur besseren Verständlichkeit so umschreiben, dass die (zyklomatische) Komplexität entflochten wird |
Eine Softwarekomponente kann auch mit Hilfe eines Entwurfsmusters umgesetzt sein. Darum wird im Handlungsziel das Entwurfsmuster nicht explizit aufgeführt und dem HZ trotzdem Rechnung getragen.