Ein passendes Vorgehen für ein Softwareprojekt festlegen

Ein fester Termin, aber noch keine feste Lösung

Die Hafenblick Service GmbH wartet technische Anlagen in Bürogebäuden. Bisher notieren Beschäftigte ihre Prüfwerte auf Papier. Nun soll eine mobile Webanwendung die Prüfungen erfassen, Bilder speichern und die Daten an das bestehende Auftragsmanagement übertragen.

Der erste produktive Einsatz ist in vier Monaten geplant. Dieser Termin steht fest, weil dann die neue Wartungssaison beginnt. Einige Anforderungen sind klar: Eine Wartung braucht immer Anlagen-ID, Messwerte und eine Unterschrift. Andere Punkte sind offen. Im Keller ist die Netzverbindung unzuverlässig. Erst ein Versuch mit den Beschäftigten wird zeigen, welche Offline-Funktionen sie wirklich brauchen. Auch die Schnittstelle zum alten Auftragsmanagement wurde noch nicht technisch geprüft.

Die Projektleitung könnte alle Anforderungen zuerst vollständig festschreiben und die Anwendung danach in einem Durchgang entwickeln. Das schafft klare Übergaben. Es birgt hier aber ein Risiko: Das Team könnte erst spät merken, dass der geplante Offline-Ablauf im Gebäude nicht funktioniert. Ein rein spontanes Vorgehen wäre ebenfalls keine gute Antwort. Der Einführungstermin, die Pflichtdaten und die Sicherheitsprüfung brauchen Verbindlichkeit.

Deine Aufgabe ist deshalb nicht, das vermeintlich modernste Modell zu nennen. Du entwirfst ein Vorgehen, das zu den Bedingungen dieses Auftrags passt.

Nach dieser Lektion kannst du:

• stabile und unsichere Teile eines Auftrags unterscheiden,
• ein Vorgehen anhand nachvollziehbarer Kriterien auswählen,
• Rollen und Entscheidungspunkte festlegen,
• Risiken früh sichtbar machen,
• Änderungen aufnehmen, ohne Ziel, Termin und Qualität aus dem Blick zu verlieren.

Du brauchst keine Vorkenntnisse zu Scrum. Die Grundidee eines iterativen Vorgehens wird direkt am Projekt erklärt.

Das Vorgehen beantwortet vier praktische Fragen

Ein Vorgehensmodell gibt einem Projekt einen wiederholbaren Rahmen. Es ordnet Tätigkeiten und Ergebnisse. Für die Auswahl helfen vier Fragen:

1. In welcher Reihenfolge wird analysiert, entworfen, umgesetzt und geprüft?
2. Wann sehen Kundinnen, Nutzer und andere Beteiligte ein überprüfbares Ergebnis?
3. Wer entscheidet über Prioritäten, Qualität und Änderungen?
4. Wie reagiert das Team auf neue Erkenntnisse und Risiken?

Das Modell nimmt dem Team diese Entscheidungen nicht ab. Es macht aber sichtbar, wann und durch wen sie getroffen werden.

Sequenziell bedeutet geordnete Übergaben

Bei einem sequenziellen Vorgehen werden größere Phasen nacheinander bearbeitet. Nach der Analyse folgt zum Beispiel der Entwurf, danach die Umsetzung und anschließend die Prüfung. Ein Phasenergebnis bildet die Grundlage für die nächste Phase.

Das kann tragen, wenn Anforderungen und technische Lösung weitgehend stabil sind. Es passt auch, wenn formale Freigaben oder die Übergabe an getrennte Fachgruppen feste Ergebnisse verlangen. Eine späte Änderung kann allerdings teuer werden, weil sie bereits abgeschlossene Entscheidungen berührt.

Iterativ und inkrementell bedeutet Lernen am Ergebnis

Bei einem iterativen Vorgehen wird eine Lösung wiederholt überprüft und angepasst. Inkrementell bedeutet, dass dabei nutzbare Teile des Produkts entstehen. Das Team baut also nicht vier Monate lang unsichtbar an der gesamten Anwendung. Es liefert zum Beispiel zuerst Anmeldung und Anlagenliste, danach die Messwerterfassung und später den Bild-Upload.

Nach jedem Teil können Beteiligte das Ergebnis prüfen. Neue Erkenntnisse fließen in die weitere Planung ein. Der Scrum Guide beschreibt Scrum als iterativen und inkrementellen Ansatz mit regelmäßiger Überprüfung und Anpassung. Diese Grundidee lässt sich verstehen, ohne jedes Projekt automatisch nach Scrum zu organisieren.

Kriterien führen zu einer begründeten Auswahl

Die Namen der Modelle sind für die Entscheidung weniger wichtig als die Bedingungen des Projekts. Hafenblick bewertet fünf Kriterien:

Für dieses Projekt passt deshalb ein iterativ-inkrementelles Vorgehen mit verbindlichen Freigabepunkten. Das Team arbeitet in zweiwöchigen Abschnitten. Vor dem ersten Abschnitt klärt es Produktziel, Pflichtanforderungen, Datenschutz- und Sicherheitsrahmen sowie die technische Grundrichtung. Nach jedem Abschnitt prüft eine verantwortliche Person ein nutzbares Ergebnis mit den Wartungsbeschäftigten. Vor dem produktiven Einsatz gibt es zusätzlich eine Sicherheits- und Betriebsfreigabe.

Das ist kein vollständiges Scrum. Das Projekt übernimmt bewusst die kurzen Arbeitsabschnitte, die geordnete Aufgabenliste und die regelmäßige Überprüfung. Es ergänzt formale Freigaben, weil der betriebliche Kontext sie verlangt. Wer Scrum verändert, sollte die angepasste Arbeitsweise nicht einfach weiterhin als Scrum bezeichnen. Sonst bleiben Verantwortlichkeiten unklar.

Rollen verbinden Arbeit mit Entscheidungen

Ein Ablauf allein reicht nicht. Wenn niemand für eine Entscheidung zuständig ist, wartet das Team trotz sauberer Termine. Hafenblick vereinbart deshalb vier Rollen. Eine Person kann mehrere Rollen übernehmen, solange Interessenkonflikte und Arbeitslast beherrschbar bleiben.

Die ersten drei Verantwortungsbereiche ähneln Teilen eines Scrum Teams. Der Scrum Guide nennt Product Owner, Developer und Scrum Master. Hafenblick verwendet bewusst eigene Rollennamen, weil das Projekt kein vollständiges Scrum einsetzt. Die zusätzliche Freigaberolle kommt aus dem betrieblichen Rahmen. Sie priorisiert nicht die Produktfunktionen und steuert auch nicht die tägliche Umsetzung.

Zwei Regeln verhindern unnötige Warteschleifen:

• Die Produktverantwortliche entscheidet über Reihenfolge und fachlichen Umfang, nicht über technische Einzelschritte.
• Das Umsetzungsteam entscheidet über das Wie der Umsetzung, solange Qualitätsgrenzen und vereinbarter Umfang eingehalten werden.

Wenn beide Seiten dieselbe Entscheidung beanspruchen, hilft kein weiterer Termin. Dann muss die Verantwortungsgrenze geklärt werden.

Phasen geben Orientierung, Iterationen erzeugen Erkenntnisse

Auch ein iteratives Projekt hat einen Anfang und einen Abschluss. Hafenblick verbindet übergeordnete Phasen mit kurzen Arbeitsabschnitten:

Der erste Arbeitsabschnitt behandelt nicht die optisch auffälligste Funktion, sondern die riskante Offline-Synchronisation. Ein kleiner Versuch speichert drei Messwertarten lokal und überträgt sie später an eine Test-Schnittstelle. Das Ergebnis ist noch kein fertiges Produkt. Es beantwortet aber eine wichtige Frage: Trägt die technische Grundidee unter den Bedingungen im Gebäude?

Danach entstehen nutzbare Teile:

1. Anmeldung und Anlagenliste,
2. Messwerterfassung mit lokaler Speicherung,
3. Synchronisation und Konfliktanzeige,
4. Bilder, Unterschrift und Abschlussprüfung.

Jeder Abschnitt endet mit einem überprüfbaren Ergebnis. “80 Prozent programmiert” ist dafür zu ungenau. Bei einem nutzbaren Teil sind die vereinbarten Funktionen umgesetzt, geprüft und in einer Form bereitgestellt, die Rückmeldung erlaubt.

Risiken bestimmen, was früh gelernt werden muss

Ein Risiko ist ein mögliches Ereignis oder eine unsichere Bedingung, die ein Projektziel beeinflussen kann. Ein bereits aufgetretener Fehler ist kein Risiko mehr, sondern ein zu behandelndes Problem.

Für jedes wichtige Risiko hält Hafenblick fünf Angaben fest:

Die Tabelle ist keine Ablage für alle denkbaren Gefahren. Sie steuert die Arbeit. Ein hohes technisches Risiko wird früher untersucht. Ein Frühindikator macht sichtbar, wann das Team reagieren sollte. Die verantwortliche Rolle sorgt dafür, dass ein Risiko nicht nur bekannt, sondern auch beobachtet wird.

Änderungen werden entschieden, nicht nur angenommen

Nach dem zweiten Arbeitsabschnitt wünschen die Wartungsbeschäftigten eine Kartenansicht. Der Wunsch ist nachvollziehbar. Trotzdem sollte das Team ihn nicht direkt nebenbei umsetzen. Jede Änderung kann Umfang, Termin, Qualität oder andere Funktionen beeinflussen.

Ein einfacher Änderungsweg reicht für das Projekt:

1. Wunsch klären: Welches Problem soll die Kartenansicht lösen?
2. Auswirkung untersuchen: Welche Daten, Berechtigungen, Entwicklungszeit und Tests braucht sie?
3. Optionen benennen: aufnehmen, gegen einen anderen Umfang tauschen, später einplanen oder begründet ablehnen.
4. Entscheiden: Die zuständige Produktrolle entscheidet innerhalb des vereinbarten Rahmens. Änderungen an Termin oder Budget gehen an die dafür befugte Stelle.
5. Plan sichtbar anpassen: Aufgabenliste, Risiken, Abnahmekriterien und betroffene Entscheidungen werden aktualisiert.

Im Gespräch zeigt sich, dass die Beschäftigten nicht die Position aller Anlagen auf einer Karte brauchen. Sie wollen im großen Gebäude schneller den richtigen Raum finden. Eine zusätzliche Anzeige von Gebäudeteil, Etage und Raumnummer löst das Problem mit geringerem Aufwand und ohne Kartendienst. Die Produktverantwortliche priorisiert diese Änderung für den nächsten Abschnitt. Der Kartenwunsch bleibt als verworfene Option mit Begründung nachvollziehbar.

Das Beispiel zeigt zwei Dinge. Rückkopplung darf die Lösung verändern. Das Produktziel und die Projektgrenzen bleiben trotzdem der Maßstab.

Anpassung braucht eine Grenze

Ein Modell wird nicht besser, wenn das Team nur die angenehmen Teile übernimmt. Drei Warnzeichen zeigen, dass eine Anpassung den Rahmen unbrauchbar macht:

• Es gibt regelmäßige Termine, aber niemand darf auf Erkenntnisse reagieren.
• Eine Aufgabenliste existiert, aber Priorität und Verantwortlichkeit bleiben unklar.
• Das Team nennt Ergebnisse “fertig”, obwohl gemeinsame Qualitätskriterien fehlen.

Hafenblick hält deshalb eine kurze Arbeitsvereinbarung fest:

• Arbeitsabschnitte dauern zwei Wochen.
• Jeder Abschnitt verfolgt ein fachlich überprüfbares Ziel.
• Die Produktverantwortliche ordnet den Umfang, das Team plant die Umsetzung.
• Ein Ergebnis gilt erst nach den vereinbarten Funktions-, Sicherheits- und Testkriterien als fertig.
• Rückmeldungen und Risiken werden vor der nächsten Planung eingeordnet.
• Änderungen an Einführungstermin oder Budget brauchen eine Entscheidung der Projektauftraggeberin.

Diese Vereinbarung ist klein genug, um im Alltag benutzt zu werden. Gleichzeitig beantwortet sie die wichtigsten Entscheidungsfragen des Projekts.

Was du aus der Lektion mitnimmst

Ein tragfähiges Vorgehen ist keine Methodenliste. Es verbindet Projektbedingungen mit Arbeitsrhythmus, Ergebnissen und Entscheidungen.

• Stabile Anforderungen und formale Übergaben können für ein stärker sequenzielles Vorgehen sprechen.
• Unsicherheit, technische Risiken und verfügbare Rückkopplung sprechen für frühe, nutzbare Teilergebnisse.
• Rollen klären, wer fachlich priorisiert, technisch entscheidet und eine Freigabe erteilt.
• Risiken beeinflussen die Reihenfolge der Arbeit.
• Änderungen brauchen eine Wirkungsprüfung und eine sichtbare Entscheidung.
• Anpassungen sind sinnvoll, solange der verbleibende Rahmen eindeutig und arbeitsfähig bleibt.

Quellenbasis und Abgrenzung

Der Rahmenlehrplan verankert die vollständige Durchführung und Bewertung eines Kundenauftrags in Lernfeld 12a. Die Ausbildungsordnung verlangt in Abschnitt B die Auswahl und den Einsatz von Vorgehensmodellen und nennt für das betriebliche Projekt eine Projektplanung. Der Prüfungskatalog führt klassische und agile Vorgehensmodelle als möglichen Themenbereich auf. Er garantiert keine bestimmte Aufgabe in einem Prüfungstermin.

Der Scrum Guide dient hier nur für die Grundidee von Scrum und seine definierten Verantwortlichkeiten. Das Vorgehen im Szenario ist bewusst angepasst und wird deshalb nicht als vollständiges Scrum bezeichnet. Die Lektion erklärt weder die vollständige Projektplanung noch Aufbau und Bewertung einer Projektdokumentation. Dafür sind eigene Lerneinheiten vorgesehen.

Belegmatrix