Arbeit an Informatikprojekten
Arbeit an Informatikprojekten: von der Idee zum Produkt
Warum Projekte fast nie an der Technik scheitern, und welche vier Schritte das verhindern.
Benötigte Grundlagen
Diese Themen kommen in diesem Kapitel vor und wurden vorher schon erklärt. Wenn dir eines davon unsicher vorkommt, frisch es kurz auf, sonst leg direkt los.
Einführung
Vier Schüler wollen eine App für den Vertretungsplan bauen. Sie legen sofort los. Nach drei Wochen hat einer eine Oberfläche gebaut, die zu den des anderen nicht passt, der dritte hat sein Stück fertig, aber niemand weiß, wie man es einbindet, und der vierte hat auf eine Antwort gewartet, die nie kam.
Kein einziger technischer Fehler, und das Projekt steckt fest.
Genau das ist der Normalfall. Projekte scheitern selten an schwieriger Technik, sondern fast immer daran, dass niemand aufgeschrieben hat, was eigentlich gebaut werden soll, wer was macht und wann etwas fertig ist. Dagegen hilft ein Vorgehen, das man lernen kann.
Das kannst du nach diesem Kapitel
ein Projektthema abgrenzen und Teilziele formulieren.
die vier Phasen Planen, Entwerfen, Umsetzen, Prüfen und Präsentieren anwenden.
Aufgaben so aufteilen, dass parallel gearbeitet werden kann.
den Aufbau einer Projektdokumentation beschreiben.
ein Ergebnis nach vorher festgelegten Kriterien bewerten.
Phase 1: Planen
Am Anfang steht nicht das Programmieren, sondern die Abgrenzung. Ein Projektthema muss beantworten, was dazugehört und was ausdrücklich nicht.
Aus „eine App für die Schule“ wird dadurch:
Ziel: Eine Webseite, die den Vertretungsplan der Klassen 5 bis 12 anzeigt und nach Klasse filtern lässt. Nicht dazu gehört: Anmeldung, Push-Nachrichten, Stundenplan, Noten.
Der zweite Satz ist der wichtigere. Ohne ihn wächst der Umfang während der Arbeit immer weiter, weil jeder eine gute Zusatzidee hat, und am Ende ist nichts fertig.
Danach wird das Ziel in Teilziele zerlegt. Ein gutes Teilziel erfüllt drei Bedingungen:
- Es ist in wenigen Tagen erreichbar.
- Man kann eindeutig sagen, ob es erreicht ist.
- Es lässt sich möglichst unabhängig von den anderen bearbeiten.
Die dritte Bedingung ist die, an der Gruppenarbeit meistens scheitert. Teilt man „einer macht die Oberfläche, einer die “, muss der Erste warten, bis der Zweite fertig ist. Besser ist es, sich zuerst auf die Schnittstelle zu einigen: Welche Angaben liefert der Datenteil, in welcher Form? Danach können beide gleichzeitig arbeiten, weil jeder weiß, womit er rechnen kann.
Warum die Schnittstelle zuerst kommt
Beide Teams brauchen für ihre Arbeit gleich lang, je zwei Wochen, sieh dir die Balkenlängen an, sie sind gleich. Verschieden ist nur, wann sie anfangen können. Bei A muss die Oberfläche warten, weil noch niemand weiß, welche Angaben der Datenteil überhaupt liefert; das Projekt dauert vier Wochen. Bei B hat man sich zuerst auf die Schnittstelle geeinigt, welche Angaben, in welcher Form, und danach kann jeder loslegen, weil jeder weiß, womit er rechnen kann; zwei Wochen. Die gesparte Zeit kommt also nicht von schnellerer Arbeit, sondern allein aus der Reihenfolge.
Phase 2: Entwerfen
Jetzt wird festgelegt, wie es gebaut wird, immer noch ohne zu programmieren:
- Welche werden gebraucht, in welcher Struktur? (Kapitel Datenmodellierung)
- Welche Abläufe gibt es? (, )
- Wie sieht die Oberfläche aus? (Skizze auf Papier genügt)
- Wer macht was bis wann?
Der Aufwand lohnt sich aus einem nüchternen Grund: Ein Fehler im Entwurf kostet Minuten, derselbe Fehler nach zweihundert Zeilen Quelltext kostet einen Nachmittag. Es ist dieselbe Rechnung wie bei den drei Phasen des Problemlösens aus Klasse 9, nur auf ein ganzes Team bezogen.
Phase 3: Umsetzen
Erst hier wird gebaut, und zwar in kleinen, lauffähigen Schritten.
🔴 Die wichtigste Regel dabei: Immer etwas Lauffähiges haben. Lieber eine Version, die nur den Plan der 10a anzeigt und funktioniert, als eine, die alles kann und nirgends läuft. Der Grund ist praktisch: Wenn drei Tage vor der Abgabe etwas schiefgeht, hat man im ersten Fall ein vorzeigbares Ergebnis, im zweiten gar nichts.
Dazu gehören zwei Gewohnheiten:
Regelmäßig zusammenführen. Wer zwei Wochen allein arbeitet und dann zusammenlegt, findet zwei Wochen Missverständnisse auf einmal. Wer täglich zusammenführt, findet sie einzeln.
Fortschritt sichtbar machen. Eine einfache Liste mit „offen, in Arbeit, fertig“ genügt. Sie verhindert, dass zwei dasselbe bauen und niemand das Dritte.
Phase 4: Prüfen und Präsentieren
Geprüft wird gegen die vorher festgelegten Teilziele, nicht gegen den Eindruck „läuft ganz gut“. Dazu gehören auch die Randfälle aus dem Testkapitel: leere , sehr viele Daten, falsche Eingaben.
Zur Präsentation gehört mehr als „hier ist unser Programm“:
- Welches Problem sollte gelöst werden?
- Wie sind wir vorgegangen?
- Was funktioniert, und wie zeigen wir das?
- Was funktioniert nicht, und warum?
- Was würden wir beim nächsten Mal anders machen?
Punkt 4 ist kein Eingeständnis von Schwäche, sondern ein Qualitätsmerkmal. Eine Gruppe, die ihre Grenzen kennt und benennt, hat ihr Produkt geprüft. Eine, die behauptet, alles funktioniere, hat meist nur nicht genau hingesehen.
In jeder Phase steht eine Regel, die man erfahrungsgemäß gern überspringt. Die zweite kostet am wenigsten und spart am meisten: Ein Fehler im Entwurf kostet Minuten, derselbe Fehler nach zweihundert Zeilen Quelltext kostet einen Nachmittag. Und die dritte ist die, an der ganze Gruppen scheitern, lieber eine Fassung, die nur den Plan der 10a anzeigt und läuft, als eine, die alles kann und nirgends startet. Wenn drei Tage vor der Abgabe etwas schiefgeht, hat man im ersten Fall ein vorzeigbares Ergebnis und im zweiten gar nichts.
Die Projektdokumentation
Sie hält fest, was gemacht wurde und warum, und folgt üblicherweise diesem Aufbau:
| Teil | Inhalt |
|---|---|
| Thema und Ziel | Was sollte entstehen, was ausdrücklich nicht |
| Planung | Teilziele, Aufgabenverteilung, Zeitplan |
| Entwurf | Datenstruktur, Abläufe, Oberflächenskizze |
| Umsetzung | Was wurde gebaut, welche Entscheidungen wurden getroffen |
| Probleme und Lösungen | Was ging schief, wie wurde es gelöst |
| Ergebnis | Was funktioniert, was nicht |
| Reflexion | Was war gut, was würden wir ändern |
🔴 Der Teil „Probleme und Lösungen“ ist der wertvollste und wird am häufigsten weggelassen. Er beweist, dass wirklich gearbeitet wurde, und er ist beim nächsten Projekt der einzige Teil, den man tatsächlich noch einmal liest.
Wichtig ist außerdem: Die Dokumentation entsteht während des Projekts, nicht danach. Wer sie am Ende schreibt, erinnert sich an die Hälfte der Entscheidungen nicht mehr und erfindet den Rest.
Die Dokumentation läuft mit, sie folgt nicht
Vergleiche den untersten Balken mit den vier darüber: Er hat keinen eigenen Abschnitt, sondern reicht von der ersten bis zur letzten Woche. Genau das ist die Aussage. Wer die Dokumentation erst in Woche 8 schreibt, erinnert sich an die Hälfte der Entscheidungen nicht mehr und erfindet den Rest und zwar ausgerechnet beim Teil „Probleme und Lösungen“, der der wertvollste ist und beim nächsten Projekt der einzige, den man wirklich noch einmal liest. Die Entscheidungen aus Woche 3 lassen sich nur in Woche 3 aufschreiben.
Warum Projekte scheitern
Die häufigsten Ursachen sind bemerkenswert unspektakulär, und alle vier lassen sich vermeiden:
- Zu großes Ziel. Man wollte alles und hat nichts fertig. Gegenmittel: harte Abgrenzung in Phase 1.
- Kein gemeinsames Verständnis. Jeder baute etwas anderes. Gegenmittel: Entwurf auf Papier, den alle unterschreiben.
- Zu spätes Zusammenführen. Am Ende passte nichts zusammen. Gegenmittel: früh und oft zusammenlegen.
- Keine Puffer. Der Zeitplan ging von störungsfreier Arbeit aus. Gegenmittel: das letzte Viertel der Zeit für Unvorhergesehenes reservieren, nicht für neue Funktionen.
Auffällig ist, dass keine dieser Ursachen technischer Natur ist. Genau deshalb ist Projektarbeit ein eigener Lernbereich und kein Anhängsel des Programmierens.
Die vier häufigsten Ursachen und was hilft
Lies die rechte Spalte zuerst: Drei der vier Gegenmittel liegen in Phase 1 oder 2, also bevor irgendjemand programmiert. Das ist kein Zufall, sondern die Pointe des ganzen Kapitels. Ein Projekt scheitert selten daran, dass niemand eine schreiben konnte; es scheitert daran, dass der Umfang nie abgegrenzt wurde oder dass vier Leute vier verschiedene Vorstellungen vom selben Programm hatten. Genau deshalb ist Projektarbeit ein eigener Lernbereich und kein Anhängsel des Programmierens.
Ein Thema abgrenzen und zerlegen
Aus der Idee „Wir machen eine Schul-App“ soll ein bearbeitbares Projekt für vier Personen in sechs Wochen werden.
- 1
Einengen: „Eine Webseite, die den Vertretungsplan anzeigt und nach Klasse filtern lässt.“ Aus einer Wolke wird ein Satz, den man prüfen kann.
- 2
Ausschließen: Nicht dazu gehören Anmeldung, Benachrichtigungen, Stundenplan, Noten, App-Store-Veröffentlichung. Dieser Satz spart später die meisten Diskussionen.
- 3
Teilziele bilden: Vier Stücke, die nach der Schnittstellen-Vereinbarung nebeneinander laufen können.
T1 Datenformat festlegen und Beispieldaten anlegen (alle gemeinsam, Tag 1) T2 Daten einlesen und bereitstellen (Person A) T3 Anzeige der Tabelle (Person B) T4 Filter nach Klasse (Person C) T5 Gestaltung und Handybreite (Person D) T6 Zusammenführen, Testen, Dokumentation (alle, letzte Woche) - 4
Warum T1 gemeinsam und zuerst? Weil es die Schnittstelle festlegt. Sobald alle wissen, wie ein Datensatz aussieht, kann B die Anzeige bauen, ohne dass A fertig ist: Er arbeitet mit den Beispieldaten.
- 5
Zeitplan mit Puffer: vier Wochen Arbeit, anderthalb Wochen Zusammenführen und Testen, eine halbe Woche Reserve. Nicht sechs Wochen Bauen und am letzten Tag zusammenlegen.
Ein Satz Ziel, ein Satz Abgrenzung, sechs Teilziele, Schnittstelle zuerst, Puffer am Ende.
Warum die Schnittstelle zuerst kommt
Person A baut den Datenteil, Person B die Anzeige. Vergleiche zwei Vorgehensweisen.
- 1
Ohne Absprache: A entscheidet, Datum und Uhrzeit in einem Feld zu speichern. B erwartet zwei getrennte Felder und baut die Anzeige entsprechend. Beide arbeiten zwei Wochen.
- 2
Beim Zusammenführen passt nichts. Einer von beiden muss umbauen, und beide haben in der Zwischenzeit weitergebaut, sodass die Änderung nicht nur eine Stelle betrifft.
- 3
Mit Absprache an Tag 1: Beide einigen sich auf die Form eines Datensatzes.
{ klasse: "10a", stunde: 3, fach: "Mathe", vertretung: "Frau Weber", raum: "A104", hinweis: "" } - 4
B legt sich fünf solche Beispieldatensätze von Hand an und baut die Anzeige damit. Er braucht A gar nicht. A baut das Einlesen und liefert am Ende dieselbe Form.
- 5
Das Zusammenführen ist danach ein Austausch der Datenquelle und dauert Minuten. Der ganze Unterschied besteht aus einer halben Stunde Absprache am ersten Tag.
Die vereinbarte Schnittstelle macht paralleles Arbeiten möglich und das Zusammenführen zur Nebensache.
Typischer Fehler
„Wir haben nur noch eine Woche, also lassen wir das Testen und die Dokumentation weg und programmieren bis zum Schluss.“
Diese Entscheidung fühlt sich vernünftig an und macht das Ergebnis regelmäßig schlechter.
Ohne Testen weiß niemand, was funktioniert. In der Präsentation fällt dann genau der Fall auf, den niemand geprüft hat, und zwar vor Publikum. Eine Stunde Testen hätte ihn gefunden.
Ohne Dokumentation fehlt der Nachweis der Arbeit. Bewertet wird nicht nur das Produkt, sondern der Prozess, und der ist ohne Aufzeichnungen unsichtbar. Wer drei Wochen an einem Problem gearbeitet und es gelöst hat, kann das am Ende nicht mehr belegen.
Und der letzte Programmiertag ist der gefährlichste. Änderungen ohne anschließenden Test sind Änderungen ohne Sicherheitsnetz: Eine Kleinigkeit, die etwas anderes kaputt macht, fällt niemandem mehr auf.
Die bessere Regel ist deshalb: Das letzte Viertel der Zeit gehört dem Zusammenführen, Testen und Dokumentieren. Wenn die Zeit knapp wird, streicht man Funktionen, nicht die Qualitätssicherung. Ein kleines, geprüftes und dokumentiertes Ergebnis ist in jeder Bewertung besser als ein großes, das im entscheidenden Moment abstürzt.
Übung 1
leicht
Ordne den vier Phasen zu (Planen, Entwerfen, Umsetzen, Prüfen und Präsentieren):
a) Die Datenstruktur wird auf Papier festgelegt. b) Das Programm wird mit einer leeren Eingabe ausprobiert. c) Es wird entschieden, dass es keine Anmeldung geben soll. d) Die Oberfläche wird programmiert. e) Der Zeitplan mit Teilzielen wird aufgestellt.
Tipp anzeigen
Zu c): Was gehört zur Abgrenzung des Themas?
Lösung anzeigen
a) Entwerfen b) Prüfen und Präsentieren c) Planen (Abgrenzung des Themas) d) Umsetzen e) Planen
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
Die vier Phasen an ihrer Leitfrage unterscheiden
Jede Phase beantwortet eine eigene Frage. Planen: Was wollen wir überhaupt, und was ausdrücklich nicht? Entwerfen: Wie soll es aufgebaut sein? Umsetzen: Bauen. Prüfen und Präsentieren: Funktioniert es, und wie zeigen wir es?
- 2
c) und e): Planen: Ziel und Abgrenzung
„Es wird keine Anmeldung geben“ legt fest, was nicht gebaut wird. Das ist die Abgrenzung des Themas und gehört zum Planen. Der Zeitplan mit Teilzielen ebenso: Er verteilt das Ziel auf die verfügbare Zeit, bevor irgendetwas entworfen wird.
- 3
a) Entwerfen, der Aufbau auf Papier
Die Datenstruktur auf Papier festzulegen ist Entwerfen: Es wird noch nichts gebaut, aber entschieden, wie es gebaut werden soll. Diese Entscheidung fällt vor der ersten Zeile .
- 4
d) und b): Umsetzen und Prüfen
Die Oberfläche zu programmieren ist Umsetzen. Hier wird gebaut. Das Programm mit einer leeren Eingabe auszuprobieren gehört zu Prüfen und Präsentieren: Es wird nichts gebaut, sondern festgestellt, ob das Gebaute hält.
Übung 2
mittelEine Gruppe von drei Personen soll in vier Wochen ein Quizprogramm für den Biologieunterricht bauen.
a) Formuliere Ziel und Abgrenzung in je einem Satz. b) Bilde vier bis sechs Teilziele und verteile sie. c) Welche Schnittstelle muss zuerst festgelegt werden und warum? d) Erstelle einen Zeitplan mit Puffer.
Tipp anzeigen
Zu c): Was brauchen sowohl der Fragen-Teil als auch der Anzeige-Teil?
Lösung anzeigen
a) Ziel: Ein Programm, das Fragen mit vier Antwortmöglichkeiten stellt, die Auswahl auswertet und am Ende die Punktzahl anzeigt. Nicht dazu gehört: Benutzerkonten, Bestenliste, Speicherung der Ergebnisse, Fragen mit Bildern, Zeitbegrenzung.
b) Teilziele: T1 Format einer Frage festlegen und zehn Beispielfragen anlegen (alle, Tag 1). T2 Fragen einlesen und in zufälliger Reihenfolge bereitstellen (Person A). T3 Frage anzeigen und Antwort entgegennehmen (Person B). T4 Antwort auswerten und Punkte zählen (Person C). T5 Ergebnisanzeige am Ende (Person B). T6 Zusammenführen, Testen, Dokumentation (alle).
c) Das Format einer Frage. Alle drei Teile arbeiten damit: A liest es ein, B zeigt es an, C wertet es aus. Ohne gemeinsame Festlegung baut jeder auf eine andere Vorstellung, und beim Zusammenführen passt nichts. Mit der Festlegung kann jeder sofort mit Beispieldaten arbeiten, ohne auf die anderen zu warten.
d) Zeitplan: Woche 1: T1 gemeinsam am ersten Tag, danach Beginn von T2, T3, T4. Woche 2: Weiterarbeit, erstes Zusammenführen am Ende der Woche. Woche 3: T5, zweites Zusammenführen, erste Tests. Woche 4: Testen inklusive Randfälle, Fehlerbehebung, Dokumentation, Präsentation vorbereiten. Keine neuen Funktionen mehr.
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): Das Ziel auf einen prüfbaren Satz bringen
Ein Ziel taugt nur, wenn man am Ende eindeutig sagen kann, ob es erreicht ist. „Ein Quizprogramm bauen“ erfüllt das nicht; man muss die sichtbare Leistung beschreiben.
Zwischenergebnis
Fragen stellen, Auswahl auswerten, Punktzahl anzeigen. Drei prüfbare Leistungen.
Ein guter Test: Kann eine außenstehende Person mit dem Satz allein entscheiden, ob das Projekt fertig ist? Wenn nicht, ist er zu vage.
- 2
Teil a): Die Abgrenzung ist der wichtigere Satz
Aufgeschrieben wird, was ausdrücklich nicht gebaut wird. Ohne diesen Satz kommt in Woche zwei jemand mit einer guten Idee, und der Umfang wächst, ohne dass die Zeit wächst.
Zwischenergebnis
Keine Konten, keine Bestenliste, keine Speicherung, keine Bilder, keine Zeitbegrenzung.
- 3
Teil c): Die Schnittstelle finden
Gesucht ist das, was mehrere Teilziele gleichzeitig brauchen. Man geht die Teilziele durch und sucht das gemeinsame Element; hier taucht die Frage in T2, T3 und T4 auf.
Zwischenergebnis
Das Frageformat ist die Schnittstelle und wird zuerst festgelegt.
- 4
Teil d): Puffer einplanen, nicht hoffen
Der Zeitplan wird von hinten gedacht: Zuerst wird die letzte Woche für Zusammenführen, Testen und Dokumentation reserviert, und erst der Rest steht fürs Bauen zur Verfügung.
4\ \text{Wochen} - 1\ \text{Woche Puffer} = 3\ \text{Wochen Bauzeit}
Zwischenergebnis
Drei Wochen Umsetzung, eine Woche Abschluss ohne neue Funktionen.
Wer den Puffer nicht braucht, ist früher fertig. Wer ihn einplant und braucht, hat trotzdem ein Ergebnis.
Übung 3
schwerEine Projektgruppe meldet nach drei von vier Wochen: „Wir sind fast fertig, es fehlt nur noch das Zusammenführen.“
a) Warum ist diese Aussage ein Warnsignal? b) Nenne drei Fragen, die du der Gruppe jetzt stellen würdest. c) Die Gruppe stellt fest, dass die Teile nicht zusammenpassen. Was ist in Phase 1 oder 2 versäumt worden? d) Entwirf ein Vorgehen für die verbleibende Woche, das noch zu einem vorzeigbaren Ergebnis führt.
Tipp anzeigen
Zu a): Wie lange dauert Zusammenführen, wenn es zum ersten Mal passiert?
Lösung anzeigen
a) Weil „nur noch zusammenführen“ den aufwendigsten und unsichersten Schritt als Kleinigkeit darstellt. Solange die Teile nie zusammen liefen, ist unbekannt, ob sie zusammenpassen; die Gruppe kennt ihren eigenen Stand also gar nicht. Erfahrungsgemäß tauchen genau hier die meisten Probleme auf, und dafür bleibt jetzt nur noch eine Woche ohne Puffer.
b) Zum Beispiel: Erstens: Läuft irgendetwas davon schon gemeinsam, und seit wann? Zweitens: Auf welche Schnittstelle habt ihr euch geeinigt, und ist sie aufgeschrieben? Drittens: Was genau kann ein Außenstehender heute vorgeführt bekommen?
c) Versäumt wurde die Vereinbarung der Schnittstelle in Phase 1 und der gemeinsame Entwurf in Phase 2. Zusätzlich fehlte die Gewohnheit, früh und regelmäßig zusammenzuführen; dann wäre die Unverträglichkeit in der ersten Woche aufgefallen statt in der vierten.
d) Vorgehen für die letzte Woche: Tag 1: Nicht weiterbauen, sondern feststellen, was tatsächlich läuft. Danach gemeinsam die Schnittstelle nachträglich festlegen und aufschreiben. Tag 2: Umfang verkleinern. Ein Teil wird zum Hauptweg erklärt, die anderen passen sich daran an. Funktionen, die nicht mehr sicher zusammenzubringen sind, werden gestrichen und als „nicht umgesetzt“ dokumentiert. Tag 3: Zusammenführen und den kleinsten vollständigen Ablauf zum Laufen bringen. Tag 4: Testen, auch Randfälle, und Fehler beheben. Keine neuen Funktionen. Tag 5: Dokumentation fertigstellen, besonders „Probleme und Lösungen“, und die Präsentation vorbereiten, in der auch das Nichtumgesetzte ehrlich benannt wird.
Die Leitidee ist dieselbe wie im Kapitel: Lieber wenig, das läuft, als viel, das nicht läuft.
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) Warum „nur noch zusammenführen“ ein Warnsignal ist
Weil der Satz den aufwendigsten und unsichersten Schritt als Kleinigkeit darstellt. Solange die Teile nie zusammen liefen, ist unbekannt, ob sie zusammenpassen, die Gruppe kennt ihren eigenen Stand also gar nicht. Erfahrungsgemäß tauchen genau hier die meisten Probleme auf, und dafür bleibt nur noch eine Woche ohne Puffer.
- 2
b) Drei Fragen, die den echten Stand sichtbar machen
Erstens: Läuft irgendetwas davon schon gemeinsam, und seit wann? Zweitens: Auf welche Schnittstelle habt ihr euch geeinigt, und ist sie aufgeschrieben? Drittens: Was genau kann ein Außenstehender heute vorgeführt bekommen?
- 3
c) Was in Phase 1 und 2 versäumt wurde
Versäumt wurde die Vereinbarung der Schnittstelle in Phase 1 (Planen) und der gemeinsame Entwurf in Phase 2. Zusätzlich fehlte die Gewohnheit, früh und regelmäßig zusammenzuführen; dann wäre die Unverträglichkeit in der ersten Woche aufgefallen statt in der vierten.
- 4
d) Ein Vorgehen für die letzte Woche, das zu einem Ergebnis führt
Tag 1: Nicht weiterbauen, sondern feststellen, was tatsächlich läuft; danach die Schnittstelle nachträglich festlegen und aufschreiben. Tag 2: Umfang verkleinern, ein Teil wird zum Hauptweg, die anderen passen sich an; Nichtmachbares wird gestrichen und dokumentiert. Tag 3: Zusammenführen und den kleinsten vollständigen Ablauf zum Laufen bringen. Tag 4: Testen, auch Randfälle, keine neuen Funktionen. Tag 5: Dokumentation und Präsentation.
Zusammenfassung
Ein Informatikprojekt durchläuft vier Phasen: Planen, Entwerfen, Umsetzen sowie Prüfen und Präsentieren. Zum Ziel gehört immer die Angabe, was ausdrücklich nicht dazugehört, sonst wächst der Umfang während der Arbeit weiter. Gute Teilziele sind kurz, eindeutig prüfbar und möglichst unabhängig, und unabhängig werden sie erst, wenn die Schnittstelle zwischen ihnen zuerst vereinbart wird. Beim Umsetzen gilt, immer etwas Lauffähiges zu haben und früh und oft zusammenzuführen, damit Missverständnisse einzeln und nicht gesammelt auftreten. Geprüft wird gegen die vorher festgelegten Teilziele einschließlich der Randfälle. Die Dokumentation entsteht währenddessen, und ihr wertvollster Teil sind die aufgetretenen Probleme mit ihren Lösungen. Projekte scheitern selten an der Technik, sondern an zu großen Zielen, fehlendem gemeinsamem Verständnis, spätem Zusammenführen und fehlenden Zeitpuffern.