AALM

- flexiblerer und kreativerer

- Teams können den agilen Ansatz an die Bedürfnisse anpassen

- überlicherweise iterative Vorgehensweise

- Individuen und Interaktionen über Prozessen und Tools

- Funktionierende Software über Dokumentation

- Kundenzusammenarbeit über Vertragsverfüllung

- auf Veränderung reagieren über einen Plan verfolgen.

Development (Funktionalität hinzufügen) und Operations (Software verfügbar machen, Verantwortlich für Verfügbarkeit).

Dev (Plan, Create, Verify, Package)

Ops (Release, Configure, Monitor, Release)

Schritte: Analyse, Design, Code, Test

Wasserfall: Analyse wird für jedes Feature vor der ersten Designarbeit gmacht.

Iterativ: Alle Schritte für ein Feature, bevor das nächste Bearbeitet wird.

• Schnell Funktionalität entwickeln, welche allen Stakeholdern gezeigt werden kann
• Entwickler können neue Technologien oft beim Einsatz erlernen
• Iterative Ansätze erlauben dies bei gleichzeitiger Entwicklung von Funktionalität
• Reduziert Time-to-Market
• Rapid Prototyping verbessert Qualität/Produktivität und senkt Kosten/Zeitbedarf

Prädiktiv (vorausschauend), da die frühen Phasen stabil sein müssen.

Prediktiv (wenn die Features während der initialen Planung fixiert werden)

Adaptiv (wenn neue Features hinzugefügt oder bestehende verschoben werden können)

Der agile Prozess benötigt zwingend eine adaptive Planung

Projektmanagementframework basierend auf Werten, Prinzipien und Praktiken. Aus Erfahrungen lernen, selbst-organisiert und priorisiert. Reflektion für die ständige Verbesserung.

Hinweis: Agilität ist ein Mindset und keine Methode

Product Backlog, Sprint Planning, Sprint Backlog, Daily Scrum, Inkrement, Sprint Review, Sprint Retro

Liste mit Anforderungen des Kunden. Liste aller Features, die der Kunde in sein Projekt integriert haben möchte. Beinhaltet Features, Bugs und technische Verpflichtungen.

Legt Arbeitsvorgänge fest, welche im Sprint erledigt werden. Ursprung im Product Backlog.

Festlegen des Arbeitspensums, Auswählen und schätzen der Product Backlog Items, Arbeit planen (erstellen der Tasks).

Festgelegter Zeitraum in welcher die Arbeit erledigt wird (zwischen 1 und 4 Wochen, meist 2)

Update der Arbeit, was habe ich gestern erledigt, was mache ich heute, blockiert mich etwas?

Review: Präsentation und Abnahme der Arbeitsergebnisse.

Retrospective: Review des Sprints, Fokus auf Zusammenarbeit.

Potentiell auslieferbares Produkt. Definition of Done legt fest, wann Inkrement Fertig ist. Trägt zum Projektergebnis bei.

Product owner: Für Wertsteigerung des Produkts im Entwicklungsprozess zuständig. Verantwortet das Product Backlog und das Projektziel.

Scrum master: Verantwortlich für die Zusammenarbeit und das beseitigen von Blockaden. Orientierung an den Scrum Mehtoden und Praktiken.

Development team: Erstellen während dem Sprint die Inkremente. Selbständiges Planen und Organisieren der Arbeiten.

Project Management: Definition, Planung und Priorisierung des Workflows

Document Management: Zentralisiertes Ablegen und Verwalten der Dokumente. Erstellen, Versionieren und Validieren wie z.B. Wiki-Seiten usw.

Requirement Management: Analyse, Definition und Validierung der Anforderungen; anschließend deren potenzielle Änderungen und die Überwachung der Einhaltung.

Configuration Management & DevOps: Bieter Funktionen für die Integration, Code Review, Testing und Validieren des Codes.

Quality & Test Management: Ermöglicht Echtzeiteinblicke in den Softwareentwicklungslebenszyklus, was ein Schlüsselelement für die Qualitätssicherung ist.

Change & Defect Management: Trackt Tasks, bugs, Anfragen und User-Stories. Eine Plattform ermöglicht vollständige Nachvollziehbarkeit,

Release Management: Technik zur Verwaltung, Planung und Überwachung einer Softwareaktualisierung in ihren verschiedenen Phasen.

Boards: Ermöglicht Zusammenarbeit im Team, stellt Tools wie Kanban- oder Scrum Bords zur Verfügung.

Pipelines: Builden, Testen, Realisieren im CI/CD Prozess. In allen Sprachen möglich, kann z.B. mit GitHub verbunden werden.

Repos: Cloudbasierte Git Repos. Unterstützt Pull Requests und Datenmanagement

GitHub Advanced Security: Sicherheitsfunktionen. Überprüft Code auf Verwundbarkeiten

Test Plans: Unterstützt geplantes und exploratives Testen, bietet End-zu-End Nachvollziehbarkeit.

Artifacts: Erstellen, Hosten und Freigeben von Paketen.

Epic: Dauer über 6 Monate. Grössere Einheit, welche unterteilt werden kann. Über mehrere Releasezyklen (z.B. 4 Sprints).

Feature: Weniger als 3 Monate. Definiert Service oder Funktion eines Produktes. Z.B. Benutzer-Registrierung. Über mehrere Sprints aber nicht Releases (z.B. 2 Sprints)

Capability: Höhere Abstraktionsebene als Features. Unterstützen Definition und Entwicklung von grösseren Lösungen.

User Story: Beschreibt Teilfunktionen der Features. Z.B. «Als Benutzer muss ich mich als neuer Benutzer registrieren können, damit ich mehr Zugang zur Website habe.». Ist in einem Sprint zu erledigen.

Task: Konkrete Aufgabe. Z.B. Erstellen eines Registrierungsformulars.

Bausteine, die einem agilen Team helfen, effektiver zu arbeiten, indem sie technische Probleme und Ineffizienzen beheben, die den Entwicklungsprozess andernfalls belasten würden.

Formale Kriterien, welche festlegen, wann eine Story erledigt ist. Z.B. Alle Tests durchgeführt, Code-Review durchgeführt, Sicherheitsanforderungen erfüllt.

• Rückverfolgbarkeit von Anforderungen als Teil des Anforderungsmanagement
• Beinhaltet die Dokumentation des Lebenszyklus von Anforderungen
• Quelle sowie Änderungen sind chronologisch zu dokumentieren
• Auch nach der Implementierung des Features sollen Anforderungen nachvollziehbar sein.

• Einzelner Server, welcher alle versionierten Dateien enthält.
• Clients checken die Dateien aus dem zentralisierten Speicher aus.

• Clients checken nicht nur letzten Snapshot aus, sondern ganzes Repo inklusive History
• Falls Server ausfällt, kann Code von Client zurückgespielt werden.
• Jeder Klon ist somit ein vollwertiges Backup
• Fast jede Operation ist lokal
• Integrität durch Prüfsumme gewährleistet (keine Änderung ohne Erkennung durch Git)
• Fügt Daten hinzu. Löschen oder Rückgängigmachung ist praktisch unmöglich.

Bei jedem Commit wir der Status des Projekts hinterlegt. Git macht “Foto” dieses Zustands. Wenn keine Änderungen vorgenommen wurden, bleibt die ursprüngliche Variante bestehen.

• 1 Repository für gesamten Code
• Kann z.B. ein Verzeichnis für Web App Projekt, Mobile App Projekt und Server App Projekt beinhalten
• Whiteboxtesting

• Mehrere Repos für Code
• Ein Repo pro Projekt (Web App, Mobile App, Server App)
• Blackboxtesting (jedes Projekt kann einzeln getestet werden).

Alle Changes auf Main, keine anderen Branches.

Jede Funktion in separater Branch, ermöglicht die Arbeit von mehreren Entwicklern. In Main wird nur korrekter Code hinterlegt, da kein Merge mit fehlerhaftem Code.

Jeder Entwickler hat serverseitiges Repo. 1x Serverseitig öffentlich, 1x privat und Lokal. Oft für Open Source Projekte. Kein Push zu zentralem Repo nötig. Integration in Hauptrepo nur durch verantwortliche Person.

Kleine, regelmässige Updates in Main/Trunk, benötigte Technik für CI/CD. Erstellen von schnelllebigen Branches mit kleinen Commits. Ermöglicht kontinuierliche Integration, Codereview und aufeinanderfolgende Releases. 

• Alternatives Branching Model – Verwendet mehrere Hauptbranches (Main, Release, Development) und Feature Branches
• Mehrere langlebige Branches mit grösseren Commits
• Pro Funktion eine Feature Branch, welche nach Abschluss gemergt wird.
• Erfordern mehr Zusammenarbeit, können von Main abweichen und zu widersprüchlichen Updates führen.

Ausgangslage: Änderung an Main wird vorgenommen. Diese Änderung ist für Feature relevant.

Merge: Main in Feature. Übernimmt Main in Feature und lässt Main bestehen. Wenn Main sehr aktiv ist, kann Historie unübersichtlich werden.

Rebase: Feature wird an Spitze der Main gesetzt. Projekthistorie wird neu geschrieben. Rebasen kann für den Workflow negative Auswirkungen haben.