LF06 on FISI Lernzettel

Agile Methoden

Mon, 01 Jan 0001 00:00:00 +0000

Agile Methoden#

Agile Methoden sind iterative, flexible Vorgehensmodelle für die Projektdurchführung — im Gegensatz zum klassischen Wasserfallmodell, bei dem alles vorab geplant wird.

1. Agiles Manifest (4 Werte)#

Das Agile Manifest (2001) formuliert vier Kernwerte:

Agile bevorzugt…	…statt…
Individuen und Interaktionen	Prozesse und Werkzeuge
Funktionierende Software	Umfassende Dokumentation
Zusammenarbeit mit dem Kunden	Vertragsverhandlungen
Reagieren auf Veränderung	Befolgen eines Plans

Beide Seiten haben Wert — aber die linke Seite wird höher bewertet.

Ishikawa-Diagramm & 5-Why

Mon, 01 Jan 0001 00:00:00 +0000

Ishikawa-Diagramm & 5-Why#

Zwei Methoden zur systematischen Ursachenanalyse bei Fehlern und Problemen.

Ishikawa-Diagramm (Fischgräten-Diagramm)#

Visualisiert mögliche Ursachen eines Problems in Kategorien. Die Form ähnelt einem Fischskelett.

 Mensch Methode
 │ │
 ────────┼───────────────────┼────────
 fehlendes│ falsches │
 Training │ Vorgehen │
 │ │
 ═══════════════════╪════════════════════════╪══════► PROBLEM:
 │ │ "Drucker druckt
 defektes │ falscher │ nicht"
 Kabel │ Treiber │
 ─────────┼───────────────────────┼────────
 │ │
 Maschine Material

Die 6M-Kategorien (klassisch, Industrie)#

Kategorie	Beschreibung	IT-Beispiel
Mensch	Fehler durch Personen	Falsche Bedienung, fehlendes Training
Maschine	Technische Defekte	Defekte Netzwerkkarte, überhitzter Server
Methode	Prozess- oder Vorgehenfehler	Falsches Backup-Konzept, kein Ticketsystem
Material	Probleme mit Ressourcen	Falsches Kabel, schlechte Hardware-Qualität
Milieu	Umgebungsfaktoren	Überhitzung durch schlechte Belüftung
Messung	Fehler bei Kontrolle/Monitoring	Kein Monitoring, fehlerhafte Logs

Vorgehen#

Problem klar definieren (rechte Seite des Fischkopfs)
Hauptkategorien (6M) als Gräten einzeichnen
Mögliche Ursachen brainstormen und den Kategorien zuordnen
Wahrscheinlichste Ursachen priorisieren

5-Why-Methode#

Durch wiederholtes Fragen „Warum?" (mind. 5×) wird die Grundursache eines Problems gefunden.

ITIL: Incident / Problem / Change

Mon, 01 Jan 0001 00:00:00 +0000

ITIL: Incident / Problem / Change#

ITIL (Information Technology Infrastructure Library) ist ein Rahmenwerk für IT-Servicemanagement. Drei zentrale Begriffe sind prüfungsrelevant.

Übersicht#

Begriff	Definition	Ziel	Beispiel
Incident	Ungeplante Unterbrechung oder Qualitätsminderung eines IT-Services	Schnellstmögliche Wiederherstellung des Betriebs	Drucker druckt nicht, Netzwerk ausgefallen
Problem	Ursache eines oder mehrerer Incidents (oft unbekannt)	Dauerhafte Beseitigung der Ursache	Warum fällt der Drucker immer wieder aus?
Change	Geplante Änderung an IT-Infrastruktur oder Services	Kontrollierten Wandel ermöglichen, Risiken minimieren	Neue Firmware, Server-Umzug, Software-Update

Abgrenzung im Detail#

flowchart TD
 A["Incident: 'Der Server ist down!'<br/>sofort beheben → Service läuft wieder"]
 B["Problem: 'Warum fällt der Server immer aus?'<br/>Ursachenanalyse → dauerhafte Lösung"]
 C["Change: 'Wir tauschen die Festplatten aus'<br/>geplant, genehmigt, dokumentiert"]
 A -->|wiederholt sich| B
 B -->|Lösung erfordert Umbau| C

Incident-Bearbeitung#

Schritt	Beschreibung
1. Erkennung & Erfassung	Ticket erstellen, Datum/Uhrzeit, betroffene Systeme
2. Klassifizierung	Priorität bestimmen: Dringlichkeit × Auswirkung
3. Erstdiagnose	1st-Level-Support versucht Sofortlösung
4. Eskalation	Bei Bedarf → 2nd Level (technisch) → 3rd Level (Hersteller/Spezialist)
5. Lösung & Wiederherstellung	Service wieder verfügbar machen
6. Abschluss	Ticket schließen, Lösung dokumentieren, Nutzer informieren

Prioritätsmatrix (Dringlichkeit × Auswirkung)#

	Hohe Auswirkung	Niedrige Auswirkung
Hohe Dringlichkeit	Kritisch (sofort)	Hoch
Niedrige Dringlichkeit	Mittel	Niedrig

Change-Typen#

Typ	Beschreibung	Genehmigung
Standard Change	Routineänderung, vorab genehmigt	Vorab (Blanko)
Normal Change	Geplante Änderung mit Genehmigungsprozess	CAB (Change Advisory Board)
Emergency Change	Notfalländerung zur Schadensbegrenzung	Vereinfacht, nachträglich dokumentiert

SLA – Service Level Agreement#

Ein SLA legt vertraglich fest, welche Servicequalität garantiert wird:

Klassisches Projektmanagement (Wasserfall)

Mon, 01 Jan 0001 00:00:00 +0000

Klassisches Projektmanagement (Wasserfall)#

Im Gegensatz zu agilen Methoden plant das klassische (plangetriebene) Projektmanagement ein Projekt vollständig im Voraus und arbeitet die Phasen sequentiell ab.

Das Wasserfallmodell#

flowchart TD
 A[Anforderungsanalyse] --> B[Planung/Design]
 B --> C[Umsetzung]
 C --> D[Test]
 D --> E[Abnahme/Einführung]
 E --> F[Wartung]

Jede Phase wird vollständig abgeschlossen, bevor die nächste beginnt — ein Rücksprung in eine vorherige Phase ist im klassischen Modell nicht vorgesehen (im Gegensatz zu iterativen/agilen Modellen).

Merkmale#

Merkmal	Beschreibung
Planung im Voraus	Anforderungen werden zu Beginn vollständig erhoben und fixiert
Sequentieller Ablauf	Phasen werden nacheinander, nicht parallel/iterativ durchlaufen
Klare Meilensteine	Jede Phase endet mit einem definierten, abnehmbaren Ergebnis
Umfangreiche Dokumentation	Lasten-/Pflichtenheft, Spezifikationen vor Projektstart

Wasserfall vs. Agil#

Kriterium	Klassisch (Wasserfall)	Agil (Scrum/Kanban)
Anforderungen	Zu Beginn fixiert	Können sich während des Projekts ändern
Kundenfeedback	Erst am Ende (Abnahme)	Fortlaufend, nach jedem Sprint
Änderungen	Aufwendig, da spätere Phasen betroffen sind	Eingeplant, Teil des Prozesses
Eignung	Klar definierte, stabile Anforderungen (z. B. Bauprojekte, gesetzlich vorgeschriebene Systeme)	Unklare/sich ändernde Anforderungen, Softwareentwicklung
Dokumentation	Umfangreich, vorab	Schlanker, “working software over documentation”

Wasserfall eignet sich, wenn Anforderungen von Anfang an klar und stabil sind (z. B. Behörden-Projekte mit festen gesetzlichen Vorgaben). Bei unsicheren/sich ändernden Anforderungen ist ein agiles Vorgehen geeigneter.

Kommunikationsmodelle

Mon, 01 Jan 0001 00:00:00 +0000

Kommunikationsmodelle#

Kommunikationsmodelle helfen, Missverständnisse und Konflikte im Kundengespräch zu verstehen und professionell damit umzugehen.

Das 4-Ohren-Modell (Schulz von Thun)#

Das 4-Ohren-Modell (auch: Vier-Seiten-Modell) von Friedemann Schulz von Thun beschreibt, dass jede Nachricht vier Botschaften gleichzeitig enthält – und der Empfänger mit jedem seiner vier „Ohren" eine andere wahrnehmen kann.

Die vier Seiten einer Nachricht#

 SENDER
 │
 ┌───────────┼───────────┐
 │ │ │
 ┌─────▼─────┐ ┌───▼───┐ ┌───▼─────┐
 │ Sachinhalt│ │Selbst-│ │Beziehung│
 │ │ │offen- │ │ │
 │Was ist der │ │barung │ │Wie stehe│
 │Sachverhalt?│ │ │ │ich zum │
 │ │ │Was sagt│ │Empfänger│
 └─────┬─────┘ │ich über│ └───┬─────┘
 │ │mich? │ │
 │ └───┬───┘ │
 │ │ │
 └───────────┼─────────┘
 │
 ┌────▼────┐
 │ Appell │
 │ │
 │Was soll │
 │der Emp- │
 │fänger │
 │tun? │
 └─────────┘
 EMPFÄNGER

Die vier Ebenen erklärt#

Ebene	Frage	Beispiel: „Kannst du das nicht schneller machen?"
Sachinhalt	Was ist der objektive Inhalt?	Die Arbeit geht langsam voran
Selbstoffenbarung	Was sagt der Sender über sich?	Ich bin ungeduldig / unter Druck
Beziehung	Was denkt der Sender über den Empfänger?	Ich halte dich für langsam / inkompetent
Appell	Was soll der Empfänger tun?	Beeil dich!

Anwendung im IT-Support#

Kunde: „Das haben Sie mir aber anders erklärt!"

Magisches Dreieck & Risikomanagement

Mon, 01 Jan 0001 00:00:00 +0000

Magisches Dreieck & Risikomanagement#

Jedes Projekt bewegt sich im Spannungsfeld dreier miteinander konkurrierender Ziele — und muss zugleich mit Unsicherheiten und Risiken umgehen.

Das Magische Dreieck#

flowchart TD
 Q["Qualität /<br/>Leistungsumfang"]
 Z["Zeit"]
 K["Kosten"]
 Q --- Z
 Z --- K
 K --- Q

Die drei Zieldimensionen stehen in einem Zielkonflikt: Wird eine Dimension verändert, wirkt sich das zwangsläufig auf mindestens eine der anderen aus.

Dimension	Beispiel für Verschlechterung, wenn…
Zeit	… das Projekt schneller fertig sein soll → mehr Personal (Kosten↑) oder weniger Funktionsumfang (Qualität↓)
Kosten	… das Budget gekürzt wird → weniger Zeit für Tests (Qualität↓) oder längere Laufzeit (Zeit↑)
Qualität	… mehr Funktionen gefordert werden → mehr Zeit und/oder mehr Kosten nötig

Merksatz: “Schnell, billig, gut — wählen Sie zwei.” Alle drei Ziele gleichzeitig zu optimieren ist praktisch unmöglich; gutes Projektmanagement bedeutet, diesen Zielkonflikt bewusst zu steuern und mit dem Auftraggeber zu priorisieren.

Netzplantechnik & Gantt-Diagramm

Mon, 01 Jan 0001 00:00:00 +0000

Netzplantechnik & Gantt-Diagramm#

Beide Werkzeuge visualisieren den zeitlichen Ablauf eines Projekts — die Netzplantechnik zeigt Abhängigkeiten zwischen Vorgängen, das Gantt-Diagramm den zeitlichen Verlauf als Balkenplan.

Gantt-Diagramm#

Ein Gantt-Diagramm stellt Projektvorgänge als horizontale Balken auf einer Zeitachse dar.

gantt
 dateFormat YYYY-MM-DD
 title Projektplan (Beispiel)
 section Planung
 Anforderungsanalyse :a1, 2026-01-01, 5d
 Konzept :a2, after a1, 4d
 section Umsetzung
 Entwicklung :a3, after a2, 10d
 Test :a4, after a3, 5d
 section Abschluss
 Abnahme :a5, after a4, 2d

Vorteile	Nachteile
Übersichtlich, leicht verständlich	Komplexe Abhängigkeiten schwer darstellbar
Zeigt Zeitverlauf und Parallelität	Kritischer Pfad nicht direkt ersichtlich
Gut für Statusberichte/Kommunikation	Änderungen bei vielen Abhängigkeiten aufwendig zu pflegen

Netzplantechnik#

Ein Netzplan stellt Vorgänge als Knoten dar und verbindet sie mit Pfeilen, die Abhängigkeiten (welcher Vorgang muss vor welchem abgeschlossen sein) zeigen.

Projektorganisationsformen

Mon, 01 Jan 0001 00:00:00 +0000

Projektorganisationsformen#

Ein Projekt muss organisatorisch in die bestehende Unternehmensstruktur eingebettet werden — dafür gibt es drei klassische Formen, die sich im Grad der Weisungsbefugnis des Projektleiters unterscheiden.

1. Reine Projektorganisation#

Projektmitarbeiter werden vollständig aus ihren Fachabteilungen herausgelöst und arbeiten nur noch im Projekt, dem Projektleiter direkt unterstellt.

Geschäftsleitung
 │
 Projektleiter ← volle Weisungsbefugnis
 │
 ┌─────┼─────┐
 MA1 MA2 MA3

Vorteile	Nachteile
Klare Verantwortlichkeiten, volle Entscheidungsgewalt des PL	Mitarbeiter nach Projektende ggf. schwer wieder einzugliedern
Hohe Identifikation mit dem Projekt	Doppelte Ressourcenvorhaltung (Fachabteilung + Projekt)
Schnelle Entscheidungswege	Teuer bei kurzen/kleinen Projekten

2. Matrix-Projektorganisation#

Mitarbeiter bleiben in ihrer Fachabteilung und arbeiten zusätzlich im Projekt — sie haben zwei Vorgesetzte: den Fachvorgesetzten und den Projektleiter.

Projektphasenmodelle

Mon, 01 Jan 0001 00:00:00 +0000

Projektphasenmodelle#

Unabhängig davon, ob klassisch oder agil gearbeitet wird, durchläuft praktisch jedes Projekt dieselben vier grundlegenden Phasen.

Die vier Grundphasen#

flowchart LR
 A[1. Initiierung] --> B[2. Planung]
 B --> C[3. Durchführung /<br/>Steuerung]
 C --> D[4. Abschluss]

1. Initiierung (Projektstart)#

Projektidee wird geprüft und grob bewertet (Machbarkeit, Nutzen)
Projektauftrag wird formuliert: Ziele, Rahmenbedingungen, grober Umfang
Projektleiter wird benannt, erste Stakeholder identifiziert

2. Planung#

Detaillierte Ziel-, Termin-, Kosten- und Ressourcenplanung
Erstellung von Netzplan/Gantt
Risikoanalyse (siehe magisches Dreieck & Risiko)
Ergebnis: Projektplan, der als Referenz für die Durchführung dient

3. Durchführung & Steuerung#

Eigentliche Umsetzung der geplanten Arbeitspakete
Laufende Soll-Ist-Vergleiche (Termine, Kosten, Qualität)
Bei Abweichungen: Steuerungsmaßnahmen (Nachsteuern, Eskalation, Änderungsantrag)
Läuft parallel zur Durchführung, nicht danach

4. Abschluss#

Formale Abnahme des Projektergebnisses durch den Auftraggeber
Projektdokumentation wird vervollständigt
Lessons Learned: Was lief gut, was kann beim nächsten Projekt verbessert werden?
Freigabe der Projektressourcen (Mitarbeiter, Budget)

“Durchführung” und “Steuerung” laufen gleichzeitig, nicht nacheinander — Steuerung ist die begleitende Kontrolle während der gesamten Durchführungsphase.

Qualitätsmanagement: PDCA-Zyklus & Kano-Modell

Mon, 01 Jan 0001 00:00:00 +0000

Qualitätsmanagement: PDCA-Zyklus & Kano-Modell#

Qualitätsmanagement stellt sicher, dass Produkte/Dienstleistungen kontinuierlich verbessert und an Kundenerwartungen ausgerichtet werden.

PDCA-Zyklus (Plan-Do-Check-Act)#

Der PDCA-Zyklus (auch Deming-Kreis) ist das zentrale Modell der kontinuierlichen Verbesserung (KVP) — er wird immer wieder durchlaufen.

flowchart LR
 P[Plan<br/>Planen] --> D[Do<br/>Umsetzen]
 D --> C[Check<br/>Überprüfen]
 C --> A[Act<br/>Handeln/Anpassen]
 A --> P

Phase	Bedeutung
Plan	Problem analysieren, Ziel festlegen, Maßnahme planen
Do	Maßnahme im kleinen Rahmen (Testweise) umsetzen
Check	Ergebnis mit dem geplanten Ziel vergleichen — hat es funktioniert?
Act	Bei Erfolg: Maßnahme standardisieren/ausrollen. Bei Misserfolg: anpassen und erneut planen

Wichtig: Der Zyklus ist nie abgeschlossen — nach “Act” beginnt “Plan” erneut, mit dem Ziel der stetigen Verbesserung (daher auch: kontinuierlicher Verbesserungsprozess, KVP).