Arbeit an Informatikprojekten
Informatikprojekte planen, umsetzen und dokumentieren
Anforderungen erheben, Aufwand schätzen, Risiken benennen: die Arbeitsweise, mit der ein Projekt auch ohne Anleitung gelingt.
Benötigte Grundlagen
Dieses Vorwissen brauchst du für das Kapitel. Schau kurz nach, wenn dir etwas davon nicht mehr präsent ist, sonst leg direkt los.
Einführung
„Baut eine App, die der Schule hilft.“ Mehr steht nicht in der Aufgabe. Kein Auftraggeber, der nachfragt, keine Liste mit Anforderungen, kein Zeitplan.
In Klasse 10 war das anders: Dort gab es eine klare Aufgabe, und es ging darum, sie in Phasen zu bearbeiten. Jetzt fehlt der Anfang. Bevor man planen kann, muss man erst herausfinden, was überhaupt gebaut werden soll, und das steht nirgends geschrieben.
Genau das ist die Arbeitsweise, die in der Einführungsphase dazukommt: nicht ein vorgegebenes Ziel abarbeiten, sondern das Ziel selbst erarbeiten, den Aufwand einschätzen, die Risiken benennen und am Ende belegen, dass man geliefert hat, was man versprochen hat.
Das kannst du nach diesem Kapitel
Anforderungen erheben und in prüfbare Sätze fassen.
Anforderungen nach Muss, Soll und Kann ordnen und begründen.
den Aufwand eines Teilziels schätzen und die eigene Schätzung überprüfen.
Risiken benennen und ihnen Gegenmaßnahmen zuordnen.
Arbeitsstände sichern und ein Ergebnis nach vorher festgelegten Kriterien bewerten.
Kurz aufgefrischt
Vorausgesetzt werden die vier Phasen Planen, Entwerfen, Umsetzen sowie Prüfen und Präsentieren, dazu die Regeln „immer etwas Lauffähiges haben“ und „früh und oft zusammenführen“. Falls nötig, lies zuerst Arbeit an Informatikprojekten.
Hier geht es um das, was vor diesen Phasen liegt und was sie zusammenhält.
Anforderungen erheben
Eine Anforderung ist ein prüfbarer Satz darüber, was das Ergebnis leisten soll. Sie steht selten fertig irgendwo; man muss sie erarbeiten, indem man fragt.
Drei Fragen führen zuverlässig zu brauchbaren Anforderungen:
Wer wird das benutzen? Schüler, Lehrkräfte, das Sekretariat? Verschiedene Gruppen wollen Verschiedenes, und wer alle gleichzeitig bedienen will, bedient am Ende niemanden.
Was tut diese Person heute, und was stört sie daran? Diese Frage liefert die eigentlichen Anforderungen. „Ich muss dreimal am Tag den Aushang prüfen, ob sich etwas geändert hat“ ist eine bessere Grundlage als jede Ideensammlung.
Woran würde sie merken, dass es funktioniert? Das ist die Abnahmefrage, und sie macht aus einem Wunsch eine prüfbare Anforderung.
Der Unterschied ist deutlich:
| Wunsch | prüfbare Anforderung |
|---|---|
| „Die App soll übersichtlich sein.“ | „Der Vertretungsplan der eigenen Klasse ist nach höchstens zwei Klicks sichtbar.“ |
| „Sie soll schnell sein.“ | „Der Plan erscheint auf einem üblichen Schulhandy in unter drei Sekunden.“ |
| „Sie soll gut aussehen.“ | „Auf einem 5-Zoll-Bildschirm ist die Tabelle ohne waagerechtes Scrollen lesbar.“ |
🔴 Die rechte Spalte lässt sich am Ende überprüfen, die linke nicht. Eine Anforderung, über deren Erfüllung man streiten kann, ist keine Anforderung, sondern ein Gefühl.
Drei Fragen, die zu Anforderungen führen
Anforderungen stehen selten fertig irgendwo; man erarbeitet sie mit diesen drei Fragen, und wieder zählt die Reihenfolge. Die zweite liefert die eigentliche Ausbeute: „Ich muss dreimal am Tag den Aushang prüfen, ob sich etwas geändert hat“ ist eine bessere Grundlage als jede Ideensammlung, weil sie ein echtes Problem beschreibt statt einer Lösung. Die dritte ist die entscheidende, sie verwandelt einen Wunsch in etwas Überprüfbares. Aus „die App soll übersichtlich sein“ wird „der Vertretungsplan der eigenen Klasse ist nach höchstens zwei Klicks sichtbar“. Über den ersten Satz kann man am Ende streiten, über den zweiten nicht: Eine Anforderung, über deren Erfüllung man streiten kann, ist keine Anforderung, sondern ein Gefühl.
Muss, Soll, Kann
Nicht alle Anforderungen sind gleich wichtig, und die Zeit reicht selten für alle. Deshalb ordnet man sie in drei Gruppen:
- Muss: Ohne das ist das Ergebnis wertlos. Fällt es weg, ist das Projekt gescheitert.
- Soll: Wichtig, aber verzichtbar. Das Ergebnis wäre schlechter, aber brauchbar.
- Kann: Nett. Wird gebaut, wenn Zeit übrig ist, und sonst nicht.
Diese Einordnung trifft man vor Beginn der Arbeit, nicht am Ende unter Zeitdruck. Der Grund ist psychologisch und praktisch zugleich: Unter Druck erscheint das zuletzt Begonnene am wichtigsten, und man streicht dann das Falsche.
Als Faustregel gilt: Höchstens die Hälfte der Anforderungen darf „Muss“ sein. Ist alles ein Muss, hat man nicht priorisiert, sondern die Frage umgangen.
Drei Stufen, vor Beginn festgelegt
Die erste Zeile ist der Prüfstein: Frage bei jeder Anforderung, was passiert, wenn sie fehlt und trage sie danach ein. Entscheidend ist der Zeitpunkt: Diese Einordnung gehört vor den Beginn der Arbeit, nicht ans Ende unter Zeitdruck. Der Grund ist gut belegt: Unter Druck erscheint das zuletzt Begonnene am wichtigsten, und man streicht dann genau das Falsche, nämlich das Langweilige, das aber niemand vermissen dürfte. Und die Faustregel unten ist eine echte Prüfung: Wer alles als „Muss“ einträgt, hat nicht priorisiert, sondern sich vor der Entscheidung gedrückt, und merkt das erst, wenn die Zeit knapp wird.
Aufwand schätzen
Schätzen ist erlernbar, und der wichtigste Schritt ist, überhaupt zu schätzen und die Schätzung später zu überprüfen.
Ein brauchbares Vorgehen:
- Zerlegen, bis jedes Stück höchstens einen halben Tag dauert. Große Brocken schätzt niemand richtig; kleine schon.
- Für jedes Stück eine Zahl aufschreiben, in Stunden.
- Aufsummieren und mit Faktor 1,5 multiplizieren. Dieser Zuschlag deckt das ab, woran beim Schätzen niemand denkt: Einarbeitung, Fehlersuche, Absprachen, Unterbrechungen.
- Nach der Arbeit die tatsächliche Zeit danebenschreiben. Nur so lernt man, wie die eigene Schätzung systematisch abweicht.
Punkt 4 ist der, den fast alle weglassen und der als Einziger die Schätzung beim nächsten Mal besser macht. Wer feststellt, dass er regelmäßig um das Doppelte danebenliegt, kann das einrechnen.
Warum unterschätzt man fast immer? Weil man beim Schätzen den glatten Verlauf vor Augen hat: Man stellt sich vor, wie es funktioniert, nicht, wie man drei Stunden einen Fehler sucht. Das ist keine Charakterschwäche, sondern eine bekannte und gut belegte Regelmäßigkeit.
Schätzung, Wirklichkeit und der Zuschlag
Der obere Balken jeder Zeile ist die Schätzung, der untere die tatsächliche Zeit. Die Zahl hinter einem Balken zählt Achsenabschnitte, nicht Stunden, ein Abschnitt sind zwei Stunden, „+1“ heißt also zwei Stunden später fertig als geplant. Beachte, wie sich der Verzug fortpflanzt: „Einlesen“ brauchte zwei Stunden mehr, also konnte „Rechnen“ erst später beginnen, und „Ausgabe“ ist am Ende vier Stunden zu spät fertig, obwohl sie selbst genau so lange dauerte wie geplant. Rechne die Summen nach: geschätzt Stunden, gebraucht . Und nun der Punkt des Abschnitts: Mit dem Zuschlag von 1,5 hätte man Stunden eingeplant, und der Plan wäre aufgegangen. Der Zuschlag deckt genau das ab, woran beim Schätzen niemand denkt, Einarbeitung, Fehlersuche, Absprachen, Unterbrechungen, weil man sich beim Schätzen den glatten Verlauf vorstellt.
Risiken benennen
Ein Risiko ist etwas, das schiefgehen kann und das Projekt gefährden würde. Es zu benennen ist keine Schwarzmalerei, sondern die Voraussetzung dafür, etwas dagegen zu tun.
Man notiert zu jedem Risiko drei Dinge: was passieren könnte, wie schlimm es wäre und was man dagegen tut.
| Risiko | Auswirkung | Gegenmaßnahme |
|---|---|---|
| Wir kennen die Technik nicht | hoch | in Woche 1 einen kleinen Testaufbau machen, bevor geplant wird |
| Ein Teammitglied fällt aus | mittel | Aufgaben so schneiden, dass niemand allein zuständig ist; Stände täglich sichern |
| Die Schule liefert keine | hoch | mit erfundenen Beispieldaten arbeiten, Schnittstelle festlegen |
| Wir schaffen nicht alles | hoch | Muss-Anforderungen zuerst bauen |
🔴 Beachte die letzte Zeile: „Wir schaffen nicht alles“ ist kein Risiko, das man abwenden kann, sondern eines, das man einplanen muss. Die Gegenmaßnahme ist genau die Priorisierung von oben. Deshalb hängen beide zusammen.
Arbeitsstände sichern
Wer über Wochen an einem Ergebnis arbeitet, braucht eine Antwort auf zwei Fragen: „Was war der letzte Stand, der lief?“ und „Was habe ich seitdem geändert?“
Auch ohne Werkzeug lässt sich das ordentlich lösen, und das Prinzip ist wichtiger als das Werkzeug:
- Nach jedem funktionierenden Zwischenstand eine Kopie mit Datum ablegen. Nicht „endgültig_final_2“, sondern eine Bezeichnung, die den Stand beschreibt.
- In einer mitschreiben, was seit dem letzten Stand geändert wurde. Ein Satz je Änderung genügt.
- Nie den letzten laufenden Stand überschreiben, solange der neue nicht geprüft ist.
Der Nutzen zeigt sich in genau einem Moment: Wenn etwas kaputtgeht und man nicht weiß, wodurch. Dann vergleicht man mit dem letzten laufenden Stand und weiß, wo zu suchen ist. Ohne Sicherung bleibt nur, sich zu erinnern, und das funktioniert nicht.
In der Berufspraxis übernehmen das Versionsverwaltungen. Sie tun im Kern dasselbe, nur automatisch und für mehrere Personen gleichzeitig.
Diese drei Regeln beantworten zwei Fragen, die nach Wochen Arbeit unweigerlich kommen: „Was war der letzte Stand, der lief?“ und „Was habe ich seitdem geändert?“ Ihr Nutzen zeigt sich in genau einem Moment, wenn etwas kaputtgeht und niemand weiß, wodurch. Dann vergleicht man mit dem letzten laufenden Stand und weiß, wo zu suchen ist. Ohne Sicherung bleibt nur die Erinnerung, und die funktioniert nachweislich nicht. Achte auf die Bezeichnung: „endgültig_final_2“ beschreibt nichts; ein Datum und ein Stichwort schon. In der Berufspraxis übernimmt eine Versionsverwaltung genau diese drei Regeln, nur automatisch und für mehrere Personen gleichzeitig, das Prinzip ist wichtiger als das Werkzeug.
Nach Kriterien bewerten
Am Ende steht die Frage, ob das Projekt gelungen ist. Sie ist nur dann beantwortbar, wenn man die Maßstäbe vorher aufgeschrieben hat.
Sinnvolle Kriterien für ein Informatikprojekt:
| Kriterium | Prüffrage |
|---|---|
| Funktionsumfang | Sind alle Muss-Anforderungen erfüllt und belegt? |
| Zuverlässigkeit | Läuft es auch bei Randfällen und falschen Eingaben? |
| Verständlichkeit | Kann ein Fremder den Quelltext lesen und ändern? |
| Dokumentation | Sind Entscheidungen und Probleme nachvollziehbar festgehalten? |
| Prozess | Wurde geplant, gemessen und nachgesteuert? |
Bewertet wird also nicht nur das Produkt. Eine Gruppe, die ihre Schätzung um das Dreifache verfehlt, das aber bemerkt, dokumentiert und den Umfang rechtzeitig angepasst hat, hat besser gearbeitet als eine, die zufällig fertig wurde.
Die Selbsteinschätzung
Zum Schluss gehört eine ehrliche Reflexion, und sie ist mehr als ein Rückblick. Drei Fragen genügen:
Was hat funktioniert, und warum? Damit man es wieder tut. Was nicht, und woran lag es? Nicht „wir hatten zu wenig Zeit“, sondern „wir haben die Einarbeitung nicht eingeplant“. Was machen wir beim nächsten Mal anders? Ein konkreter Satz, kein Vorsatz.
Wer das schriftlich festhält, hat beim nächsten Projekt einen Vorsprung. Wer es im Kopf behält, fängt wieder von vorn an.
Aus einer vagen Idee prüfbare Anforderungen machen
Die Idee lautet: „Eine App, die der Schule hilft.“ Erarbeite daraus Anforderungen.
- 1
Frage 1, wer? Wir entscheiden uns für Schüler der Klassen 5 bis 10. Lehrkräfte und Sekretariat werden ausdrücklich nicht bedient; das ist die erste und wichtigste Eingrenzung.
- 2
Frage 2, was stört heute? Antworten aus Gesprächen: „Ich muss dreimal täglich den Aushang prüfen.“ „Ich erfahre erst in der Schule, dass die erste Stunde ausfällt.“ „Der Aushang hängt im Erdgeschoss, ich bin im dritten Stock.“
- 3
Frage 3, woran merkt man den Erfolg? „Ich sehe morgens vor dem Losgehen, ob sich für meine Klasse etwas geändert hat.“
- 4
Daraus die Anforderungen, prüfbar formuliert und priorisiert:
MUSS A1 Der Nutzer wählt einmalig seine Klasse; die Auswahl bleibt gespeichert. MUSS A2 Die Vertretungen der gewählten Klasse für heute und morgen sind nach dem Öffnen ohne weiteren Klick sichtbar. MUSS A3 Auf einem 5-Zoll-Bildschirm ist die Tabelle ohne waagerechtes Scrollen lesbar. SOLL A4 Der Zeitpunkt der letzten Aktualisierung wird angezeigt. SOLL A5 Bei fehlender Verbindung erscheint der zuletzt geladene Stand mit deutlichem Hinweis. KANN A6 Eine Benachrichtigung bei Änderungen für die eigene Klasse. - 5
Warum ist A6 ein Kann? Benachrichtigungen erfordern zusätzliche Technik, eine Genehmigung der Schule und Serverbetrieb rund um die Uhr. Der Nutzen ist hoch, der Aufwand aber um ein Vielfaches größer als bei A1 bis A5. Als Muss würde es das ganze Projekt gefährden.
- 6
Probe: Jede Anforderung lässt sich am Ende mit „ja“ oder „nein“ beantworten. Keine enthält „übersichtlich“, „schnell“ oder „schön“.
Aus einem Satz werden sechs prüfbare Anforderungen mit Priorität. Die Eingrenzung der Nutzergruppe war der erste und wichtigste Schritt.
Aufwand schätzen und die Schätzung prüfen
Schätze den Aufwand für die Anforderungen A1 bis A3 und vergleiche mit dem tatsächlichen Verlauf.
- 1
Zerlegen und schätzen, jedes Stück höchstens ein halber Tag:
Teilstück Schätzung Klassenauswahl anzeigen 2 h Auswahl dauerhaft speichern 2 h einlesen und aufbereiten 4 h Tabelle darstellen 3 h Darstellung für schmale Bildschirme 3 h Summe 14 h - 2
Zuschlag: Stunden. Das ist die Zahl, mit der geplant wird, nicht die 14.
- 3
Tatsächlich gebraucht: 4 h, 3 h, 9 h, 4 h, 6 h, also 26 Stunden.
- 4
Auswertung: Die reine Summe war um 86 Prozent zu niedrig, die Schätzung mit Zuschlag noch um 24 Prozent. Der Zuschlag hat also den größten Teil der Abweichung aufgefangen.
- 5
Wo lag die größte Abweichung? Beim Einlesen der Daten: 4 h geschätzt, 9 h gebraucht. Grund war das Datenformat, das anders aussah als angenommen. Lehre für das nächste Mal: Aufgaben, bei denen man von fremden Daten oder fremder Technik abhängt, bekommen einen höheren Zuschlag, weil man dort am wenigsten weiß.
Zuschlag 1,5 fing den Großteil auf. Die größte Abweichung lag dort, wo Fremdes im Spiel war, und genau das ist die Lehre für die nächste Schätzung.
Typischer Fehler
„Alle unsere Anforderungen sind Muss-Anforderungen. Sonst wäre die App ja unvollständig.“
Wer alles zum Muss erklärt, hat nicht priorisiert, sondern die Entscheidung nur verschoben. Getroffen wird sie trotzdem, nämlich später und unter Zeitdruck.
Der Unterschied liegt darin, wann und wie entschieden wird:
Vorher priorisiert: Man überlegt in Ruhe, was den Kern ausmacht, baut das zuerst und hat zu jedem Zeitpunkt ein brauchbares Ergebnis. Wird die Zeit knapp, fällt Vorbereitetes weg.
Nicht priorisiert: In der letzten Woche ist alles halb fertig. Gestrichen wird, was gerade am wenigsten weit gediehen ist, und das ist selten das Unwichtigste. Oft trifft es gerade das, woran noch niemand angefangen hat, weil es schwierig aussah, und schwierig heißt hier häufig zentral.
Es gibt außerdem einen einfachen Test für eine ehrliche Priorisierung. Frage zu jeder Muss-Anforderung: „Würden wir das Ergebnis ohne diese Anforderung wegwerfen?“ Bei einer Vertretungsplan-App ohne Anzeige des Plans: ja. Ohne Anzeige des Aktualisierungszeitpunkts: nein, es wäre schlechter, aber weiterhin nützlich. Also ist die zweite kein Muss.
Bleiben nach diesem Test mehr als die Hälfte aller Anforderungen im Muss, ist entweder das Projekt zu groß geschnitten oder die Frage wurde nicht ehrlich beantwortet.
Übung 1
leicht
Welche dieser Sätze sind prüfbare Anforderungen, welche nicht? Verbessere die untauglichen.
a) „Die Seite lädt in unter zwei Sekunden.“ b) „Die Bedienung ist intuitiv.“ c) „Nach dem Anmelden erscheint der eigene Stundenplan ohne weiteren Klick.“ d) „Die App ist modern gestaltet.“
Tipp anzeigen
Frage: Könnten zwei Personen darüber streiten, ob es erfüllt ist?
Lösung anzeigen
a) Prüfbar. Man kann die Zeit messen.
b) Nicht prüfbar. „Intuitiv“ ist ein Gefühl. Besser: „Fünf von fünf Testpersonen finden den Stundenplan ohne Erklärung in unter 30 Sekunden.“
c) Prüfbar. Man zählt die Klicks.
d) Nicht prüfbar. Besser wäre eine Anforderung, die eine überprüfbare Eigenschaft nennt, etwa: „Die Darstellung ist auf Bildschirmen ab 320 Pixel Breite ohne waagerechtes Scrollen lesbar“ oder „Schrift und Hintergrund erfüllen ein Kontrastverhältnis von mindestens 4,5 zu 1.“
Detaillierte Schritterklärung anzeigen
Hier wird jeder Schritt einzeln erklärt, vor allem, warum er gemacht wird.
✦ Empfohlen: Standard – Die normale Erklärungstiefe passt zum Einstieg.
- 1
Der Prüfstein: Könnten zwei Personen darüber streiten?
Eine Anforderung ist prüfbar, wenn ein Messverfahren angebbar ist, das ohne Meinungsstreit entscheidet. Die Prüffrage lautet: Könnten zwei Personen mit gutem Willen zu verschiedenen Urteilen kommen? Wenn ja, ist die Anforderung untauglich.
- 2
a) und c): die prüfbaren Anforderungen
„Die Seite lädt in unter zwei Sekunden“ ist prüfbar. Man misst die Zeit. „Nach dem Anmelden erscheint der eigene Stundenplan ohne weiteren Klick“ ist ebenfalls prüfbar. Man zählt die Klicks.
- 3
b) „Intuitiv“ ist ein Gefühl und lässt sich trotzdem messbar machen
Nicht prüfbar. „Intuitiv“ beschreibt ein Gefühl, kein beobachtbares Ereignis. Besser: „Fünf von fünf Testpersonen finden den Stundenplan ohne Erklärung in unter 30 Sekunden.“
- 4
d) „Modern gestaltet“: von der Geschmacksfrage zur Eigenschaft
Nicht prüfbar, „modern“ ist Geschmack und veraltet zudem. Besser wären Anforderungen mit überprüfbaren Eigenschaften: „Die Darstellung ist auf Bildschirmen ab 320 Pixel Breite ohne waagerechtes Scrollen lesbar“ oder „Schrift und Hintergrund erfüllen ein Kontrastverhältnis von mindestens 4,5 zu 1“.
Übung 2
mittelEine Gruppe soll in fünf Wochen ein Programm zur Verwaltung der Schulbücherei bauen. Es gibt keinen weiteren Auftrag.
a) Formuliere drei Fragen, die du der Bibliotheksbetreuung stellen würdest. b) Erstelle fünf prüfbare Anforderungen mit Priorität. c) Schätze den Aufwand für die Muss-Anforderungen. d) Benenne drei Risiken mit Auswirkung und Gegenmaßnahme.
Tipp anzeigen
Zu a): Frage nach dem heutigen Ablauf, nicht nach Wunschfunktionen.
Lösung anzeigen
a) Frage 1: „Wie läuft eine Ausleihe heute genau ab, vom Regal bis zum Eintrag?“ Frage 2: „Was dauert dabei am längsten oder geht am häufigsten schief?“ Frage 3: „Woran würden Sie in einem halben Jahr merken, dass sich etwas verbessert hat?“
Alle drei fragen nach dem heutigen Ablauf und seinen Problemen, nicht nach gewünschten Funktionen. Fragt man nach Wünschen, bekommt man eine Ideensammlung; fragt man nach Problemen, bekommt man Anforderungen.
b) Anforderungen:
MUSS A1 Ein Buch kann über Titel oder ISBN in unter 5 Sekunden gefunden werden. MUSS A2 Eine Ausleihe wird mit Schüler, Buch und Datum in höchstens drei Eingaben erfasst. MUSS A3 Zu jedem Buch ist sichtbar, ob es verliehen ist und an wen. SOLL A4 Eine Liste aller überfälligen Ausleihen ist auf Knopfdruck abrufbar. KANN A5 Ausleihstatistik je Monat.
c) Schätzung der Muss-Anforderungen:
| Teilstück | Schätzung |
|---|---|
| Datenstruktur festlegen und Beispieldaten anlegen | 3 h |
| Bücher erfassen und speichern | 4 h |
| Suche über Titel und ISBN | 4 h |
| Ausleihe erfassen | 4 h |
| Verleihstatus anzeigen | 3 h |
| Summe | 18 h |
| mit Faktor 1,5 | 27 h |
Bei fünf Wochen und drei Personen ist das machbar, lässt aber weniger Luft, als es scheint: Die letzte Woche gehört dem Testen und Dokumentieren.
d) Risiken:
| Risiko | Auswirkung | Gegenmaßnahme |
|---|---|---|
| Der Altbestand liegt nur auf Karteikarten vor | hoch, ohne kein Betrieb | Nur mit Beispieldaten arbeiten; Erfassung des Altbestands ist ausdrücklich nicht Teil des Projekts |
| Wir kennen die verwendete Technik noch nicht | mittel | In Woche 1 einen kleinen Testaufbau bauen, bevor der Zeitplan festgeschrieben wird |
| Anforderungen ändern sich während der Arbeit | mittel | Änderungen sammeln und nur gegen Streichung anderer Anforderungen aufnehmen |
Detaillierte Schritterklärung anzeigen
Hier wird jeder Schritt einzeln erklärt, vor allem, warum er gemacht wird.
✦ Empfohlen: Standard – Die normale Erklärungstiefe passt zum Einstieg.
- 1
Teil a): Nach Problemen fragen, nicht nach Wünschen
Wer nach Wunschfunktionen fragt, bekommt eine Liste von Ideen, die niemand priorisieren kann. Wer nach dem heutigen Ablauf und seinen Störungen fragt, bekommt Anforderungen, die sich begründen und ordnen lassen.
Zwischenergebnis
Drei Fragen zu Ablauf, Problemen und Erfolgskriterium.
Die dritte Frage ist die wichtigste: Sie liefert das Abnahmekriterium und verhindert, dass am Ende Streit darüber entsteht, ob das Projekt gelungen ist.
- 2
Teil b): Aus Problemen prüfbare Sätze machen
Jedes genannte Problem wird in einen Satz übersetzt, dessen Erfüllung sich messen oder zählen lässt. Zahlen sind dabei das beste Mittel: Sekunden, Klicks, Eingaben.
Zwischenergebnis
„in unter 5 Sekunden“, „höchstens drei Eingaben“: beides überprüfbar.
- 3
Teil c): Zerlegen, summieren, Zuschlag
Geschätzt wird nicht die Anforderung als Ganzes, sondern jedes Teilstück einzeln. Danach summiert man und multipliziert mit 1,5.
18\ \text{h} \times 1{,}5 = 27\ \text{h}
Zwischenergebnis
27 Stunden für die Muss-Anforderungen.
- 4
Teil d): Risiken mit Gegenmaßnahme, nicht ohne
Ein Risiko ohne Gegenmaßnahme ist nur eine Sorge. Zu jeder Zeile gehört deshalb eine Handlung, die entweder das Eintreten unwahrscheinlicher macht oder den Schaden begrenzt.
Zwischenergebnis
Drei Risiken, jedes mit Auswirkung und konkreter Maßnahme.
Beachte die erste Zeile: Die Gegenmaßnahme ist eine Abgrenzung. Manches Risiko beseitigt man am besten, indem man den betroffenen Teil ausdrücklich aus dem Projekt herausnimmt.
Übung 3
schwerNach drei von fünf Wochen stellt eine Gruppe fest: Von 18 geschätzten Stunden für die Muss-Anforderungen sind 26 verbraucht, und zwei der fünf Anforderungen sind noch offen.
a) Was ist zu tun, und in welcher Reihenfolge? b) Berechne, wie viel Zeit realistisch noch zur Verfügung steht, und was daraus folgt. c) Die Gruppe überlegt, die Dokumentation wegzulassen, um die Anforderungen zu schaffen. Bewerte das mit den Bewertungskriterien. d) Formuliere drei Sätze für die Reflexion, die beim nächsten Projekt tatsächlich helfen.
Tipp anzeigen
Zu b): Rechne aus, wie viel Zeit die verbleibenden Anforderungen nach bisheriger Erfahrung brauchen.
Lösung anzeigen
a) In dieser Reihenfolge: Erstens messen statt schätzen: Wie viel Zeit ist tatsächlich noch da, und wie viel haben die bisherigen Anforderungen wirklich gekostet? Zweitens neu schätzen auf Basis der eigenen Erfahrung, nicht der alten Zahlen. Drittens Umfang anpassen: Soll- und Kann-Anforderungen streichen, notfalls auch eine Muss-Anforderung, dann aber ausdrücklich und dokumentiert. Viertens die Betreuung informieren, bevor die Zeit abgelaufen ist. Erst danach weiterbauen.
b) Bisher: 3 von 5 Anforderungen in 26 Stunden, also rund 8,7 Stunden je Anforderung statt der geschätzten 3,6. Für die zwei offenen sind demnach rund 17 Stunden realistisch. Zur Verfügung stehen zwei Wochen, davon gehört die letzte dem Testen und Dokumentieren, also bleibt etwa eine Woche Bauzeit. Ob 17 Stunden hineinpassen, hängt von der Gruppengröße ab; bei drei Personen mit je zwei Stunden an fünf Tagen wären es 30 Stunden, es ginge also knapp. Daraus folgt: Soll und Kann werden gestrichen, und es wird nichts Neues mehr begonnen.
c) Schlechte Entscheidung, und zwar messbar. Von den fünf Kriterien betrifft der Verzicht gleich drei negativ: Dokumentation fällt vollständig weg, Prozess wird nicht belegbar, und Verständlichkeit leidet, weil Entscheidungen nirgends festgehalten sind. Verbessert würde allein der Funktionsumfang, und auch das nur vielleicht. Hinzu kommt: Gerade eine Gruppe, deren Schätzung um 140 Prozent danebenlag, hat etwas Wertvolles zu dokumentieren. Richtig ist der umgekehrte Weg: Funktionen streichen, Qualitätssicherung behalten.
d) Brauchbare Reflexionssätze nennen Ursache und Konsequenz:
„Wir haben die Einarbeitung in die Datenbankschnittstelle nicht eingeplant; sie hat allein sechs Stunden gekostet. Beim nächsten Mal machen wir in Woche 1 einen Testaufbau, bevor wir schätzen.“
„Unsere Schätzungen lagen im Schnitt um den Faktor 2,4 zu niedrig. Beim nächsten Projekt rechnen wir mit unserem eigenen Faktor statt mit 1,5.“
„Wir haben erst in Woche 3 gemerkt, dass wir hinterherliegen, weil niemand die verbrauchte Zeit mitgeschrieben hat. Künftig notieren wir sie nach jeder Sitzung.“
Unbrauchbar wären dagegen Sätze wie „Wir hatten zu wenig Zeit“ oder „Wir müssen das nächste Mal besser planen“: Sie nennen weder eine Ursache noch eine Handlung.
Detaillierte Schritterklärung anzeigen
Hier wird jeder Schritt einzeln erklärt, vor allem, warum er gemacht wird.
✦ Empfohlen: Standard – Die normale Erklärungstiefe passt zum Einstieg.
- 1
a) Die Reihenfolge der Rettungsschritte
Erstens messen statt schätzen: Wie viel Zeit ist tatsächlich noch da, und was haben die bisherigen Anforderungen wirklich gekostet? Zweitens neu schätzen auf Basis der eigenen Erfahrung, nicht der alten Zahlen. Drittens den Umfang anpassen. Viertens die Betreuung informieren, bevor die Zeit abgelaufen ist. Erst danach weiterbauen.
- 2
b) Aus der eigenen Erfahrung neu rechnen
Bisher: 3 von 5 Anforderungen in 26 Stunden, also rund 8,7 Stunden je Anforderung statt der geschätzten 3,6. Für die zwei offenen sind demnach rund 17 Stunden realistisch. Zur Verfügung stehen zwei Wochen, davon gehört die letzte dem Testen und Dokumentieren. Es bleibt etwa eine Woche Bauzeit.
h je Anforderung; h
Zwischenergebnis
Rund 17 Stunden nötig, rund eine Woche Bauzeit verfügbar.
- 3
c) Die Dokumentation wegzulassen ist messbar die falsche Entscheidung
Schlechte Entscheidung, und zwar messbar: Von den fünf Bewertungskriterien betrifft der Verzicht drei negativ: Dokumentation fällt vollständig weg, Prozess wird nicht belegbar, Verständlichkeit leidet. Verbessert würde allein der Funktionsumfang, und auch das nur vielleicht.
- 4
d) Brauchbare Reflexionssätze nennen Ursache und Konsequenz
Ein brauchbarer Reflexionssatz nennt eine konkrete Ursache und eine konkrete Handlung für das nächste Mal. Zum Beispiel: „Wir haben die Einarbeitung in die Datenbankschnittstelle nicht eingeplant; sie hat allein sechs Stunden gekostet. Beim nächsten Mal machen wir in Woche 1 einen Testaufbau, bevor wir schätzen.“
Zusammenfassung
In der Einführungsphase kommt zur Projektarbeit hinzu, das Ziel selbst zu erarbeiten. Anforderungen werden erhoben, indem man nach der Nutzergruppe, den heutigen Problemen und dem Erfolgskriterium fragt, und sie sind erst dann brauchbar, wenn ihre Erfüllung ohne Streit entscheidbar ist. Vor Beginn der Arbeit werden sie in Muss, Soll und Kann geordnet, denn unter Zeitdruck streicht man sonst das Falsche. Aufwand schätzt man, indem man in halbtägige Stücke zerlegt, summiert, einen Zuschlag von etwa der Hälfte einrechnet und hinterher die tatsächliche Zeit danebenschreibt; nur dieser Vergleich verbessert künftige Schätzungen. Zu jedem Risiko gehören seine Auswirkung und eine Gegenmaßnahme, und manches Risiko beseitigt man am besten durch eine Abgrenzung. Arbeitsstände werden gesichert, bevor geändert wird. Bewertet wird am Ende nach vorher festgelegten Kriterien, und dazu gehört ausdrücklich das Vorgehen und nicht nur das Produkt.