Projektentwicklung

Dummerweise stellt sich heraus, dass diese – auf den ersten Blick sehr einleuchtende – Herangehensweise an die Projektentwicklung speziell bei komplexeren Vorhaben (und ein Programm zu entwickeln ist einigermassen komplex) oft nicht gut funktioniert. Dafür gibt es verschiedene Gründe:

1. Häufig ist es nicht möglich, die Ziele des Projekts zu Beginn genau genug festzulegen – beispielsweise weil es an Vorwissen fehlt, weil ein Teilziel von der (ungewissen) Umsetzung eines anderen Teilziels abhängt, weil man erst durch praktische Versuche herausfinden muss, ob ein Teilziel im Bereich des Möglichen liegt, usw.
2. Auch die Planung der eigentlichen Umsetzung krankt daran, dass es schwer oder unmöglich ist, das ganze Projekt im Vorhinein genau genug durchzuplanen. Gerade wie lange einzelne Schritte brauchen, ist oft im Voraus kaum abzuschätzen.
3. Erschwerend kommt dazu, dass sich Teilziele häufig im Verlauf des Projekts noch ändern, z.B. weil sich erst in der Praxis herausstellt, was einfach und was schwer umzusetzen ist, oder weil einem erst im konkreten Umgang mit der Problemstellung die zündende Idee kommt.
4. Das wohl schwerwiegendste Problem ist aber dieses: Häufig stellt man erst gegen Ende fest, dass man etwas Grundlegendes nicht zum Funktionieren bringt, und dann ist die Deadline da und das Projekt auf ganzer Linie gescheitert.

Iterative Planung

In Anerkennung dieser Probleme hat sich insbesondere im Softwarebereich eine alternative Art der Projektentwicklung durchgesetzt: die iterative Planung.

Das Besondere an der Iterativen Planung ist also, dass man die grosse Aufgabe in kleinere Verbesserungsschritte aufteilt (Stichwort: Algorithmisches Denken!) und die konkrete Planung, Umsetzung und Evaluierung immer auf das jeweils aktuelle Zwischenziel bezieht. Auf diese Weise arbeitet man dauernd an Teilzielen, die in greifbarer Nähe sind (siehe Gründe 1 & 2), man bleibt flexibel bei der Wahl des jeweils nächsten umzusetzenden Teilziels (siehe Grund 3), und man hat eigentlich immer eine funktionierende – und zunehmend bessere – Version (siehe Grund 4). Selbst wenn die Zeit letztendlich nicht für ganz alles reicht, was man sich vorgestellt hatte, hat man also zumindest einen Teil des Wegs geschafft und steht zum Abgabetermin nicht mit leeren Händen da. Aber umgekehrt könnte es ja auch besser laufen als ursprünglich angenommen, und man kann die Flexibilität der Iterativen Planung nutzen, um sogar noch mehr tolle Erweiterungen einzubauen.

Bei-Spiel LittleFishBigFish

Das Prinzip der Iterativen Planung besagt nicht, dass man auf die (schriftliche!) Planung verzichten kann, nur greifen Planung und Umsetzung der einzelnen Schritte enger ineinander. Um das selber zu erfahren, sollen Sie sich an der Umsetzung eines kleinen Spiels in Greenfoot versuchen.
Die Spielidee ist simpel: Ein Aquarium voller Raubfische und sonstiger Kreaturen, eine davon steuert der Spieler mit den Pfeiltasten. Wann immer zwei Kreaturen aufeinandertreffen, wird die kleinere gefressen und die grössere wächst ein bisschen – es geht also darum, den grossen Gegnern auszuweichen und gleichzeitig die kleineren zu verspeisen. Der Spieler gewinnt, wenn er das gesamte Aquarium leer gefressen hat.
Für dieses Beispielprojekt sind die ersten Schritte bereits erledigt:

In einer ersten Arbeitsphase geht es darum, den existierenden Code zu verstehen und ein paar kleine, konkrete Verbesserungen umzusetzen (eine Anleitung dazu finden Sie in der Projektskizze, Abschnitte 1-3).
Danach gehen Sie über zu weiteren Iterationen durch den design cycle, indem sie jeweils eine neue Erweiterung (= Teilziel) in Angriff nehmen, sich die genauen Umsetzungsschritte überlegen (in der Projektskizze notieren) und sie dann konkret im Szenario umsetzen – bis sie bei einer neuen, verbesserten Version angelangt sind und sich das nächste Teilziel vornehmen können.

Projektskizze

Für grössere und komplexere Vorhaben gibt es verschiedene Arten von Hilfsmitteln, die bei der Projektsteuerung (=Planung, Organisation, Dokumentation, usw.) eingesetzt werden. Für unseren Bedarf soll dafür ein einziges Dokument genügen – Sie haben diese sogenannte Projektskizze bei der Arbeit mit dem obigen Beispielprojekt bereits kennen gelernt. Wie Ihnen hoffentlich klar geworden sein sollte, dient die Projektskizze verschiedenen Zwecken, z.B. der Definition der Ziele des Gesamtprojekts sowie jeweiliger Teilziele, der detaillierteren Planung der Umsetzung sowie (rückblickend) der Dokumentation des Projektverlaufs. Wichtig ist, dass die Skizze projektbegleitend genutzt wird, also immer den gegenwärtigen Stand ihrer Bemühungen reflektieren sollte. Nur wenn sie durchgehend mit diesem Dokument arbeiten, kann es Ihnen tatsächlich dabei helfen, die nötigen Planungsschritte zum richtigen Zeitpunkt zu erledigen, nicht den Überblick zu verlieren und ggf. rechtzeitig zu bemerken, wenn/wo das Projekt aus dem Ruder läuft.
Je nach Art und Umfang eines Projekts kann es übrigens sinnvoll sein, noch weitere Dinge in eine solche Projektskizze einzubauen, z.B. eine genauere Zeitplanung, Aufgabenverteilung über Teammitglieder, oder eine rückblickende Reflexion über den Verlauf des Projekts.

Weitere Spielprojekte

Wer sich traut, kann auch eine eigene Spielidee ohne Programmvorlage umsetzen.
Benutzen Sie dafür das Template Projektskizze_Vorlage.docx (pdf) für die Formulierung eigener Projektideen (inkl. Basisversion) – und natürlich für die Projektsteuerung während der Umsetzungsphase.