| Kompetenzband | HZ | Grundlagen | Fortgeschritten | Erweitert |
|---|---|---|---|---|
| A – Agile Methoden kennen | 1 | A1G: 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 | A1F: Ich kann das "Agile Manifesto" und dessen Prinzipien erklären und aufzeigen, was daran gut ist und wo Probleme auftauchen können | A1E: Ich kann die linearen und die zyklischen Vorgehensmodelle erkennen und aufzeigen, wie das Beste von allem kombiniert werden kann |
| 1 | A2G: Ich kann das SCRUM-Modell mit dem zyklischen Ablauf, den Rollen, den Zeremonien (Meetings/Sitzungen) und die Philosophie von SCRUM erklären | A2F: Ich kann aufzeigen, wie ein Vorhaben in eine "Vision", in "Epics" und in "User-Stories" formuliert werden kann | A2E: Ich kann ein Vorhaben mit meinem Team in einen SCRUM-Ablauf einkleiden und die richtigen Schritte planen | |
| 1 | A3G: Ich kann die drei Aspekte erklären, wie man eine Anforderung in einem Satz für eine User-Story formuliert | A3F: 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) | A3E: Ich kann den "guten" Schnitt zwischen User-Story und Aufgaben-Tasks zusammen mit dem Team bestimmen | |
| B – Agile Iteration realisieren | 2 | B1G: Ich kann bestehende Softwaremodule interpretieren und erklären, wo für die Umsetzung einer User Story die Software ergänzt werden muss | B1F: Ich kann die Software für die Umsetzung einer User Story implementieren | B1E: Ich kann bestehende Software für die Umsetzung einer User Story anpassen (Refactoring) |
| 2 | B2G: Ich kann die Bedeutung einer lauffähigen Software im Rahmen der agilen Softwareentwicklung erläutern | B2F: Ich kann die von mir umgesetzte User-Story anhand der lauffähigen Software präsentieren und zeigen, dass die DoD eingehalten sind | B2E: Ich kann eine Sprint-Demo vorbereiten (inkl. Burndown Chart) und durchführen | |
| C – Komponenten wiederverwenden | 3 | C1G: Ich kann das Prinzip von Softwarekomponenten (Wiederverwendbarkeit, Aufgabenaufteilung, Schnittstellen) an einem Beispiel erläutern | C1F: Ich kann für eine Applikation, unter Berücksichtigung der Wiederverwendbarkeit, Softwarekomponenten evaluieren und auswählen | C1E: Ich kann in einem Entwurf Softwarekomponenten identifizieren, deren Wiederverwendbarkeit beurteilen und begründet integrieren |
| D – Vorgehen reflektieren und verbessern | 4 | D1G: Ich kann erklären, wie ich mich auf das Daily Scrum vorbereite | D1F: Ich kann meine Erfahrungen und Erkenntnisse an der Retrospektive einbringen und geeignete Verbesserungsmassnahmen ableiten | D1E: Ich kann eine Retrospektive vorbereiten und anleiten sowie die gewonnenen Erkenntnisse priorisieren und in konkrete Verbesserungsmassnahmen überführen |
| E – Versionsverwaltung anwenden | 5 | E1G: 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) | E1F: Ich kann mit Merge Requests umgehen und Branches gezielt anwenden (z. B. Git-Flow) | E1E: 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 | F1G: Ich kann erklären, was zur guten Lesbarkeit von Code wichtig ist und welche Regeln es zu beachten gibt | F1F: Ich kann einen Code durch die Anwendung der "Clean Code"-Empfehlungen besser lesbar machen und ein Refactoring durchführen | F1E: 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.