Prof. Dr. Detlef Kreuz

Projektstudie Softwareentwicklung WS 2010/11: Lessons Learned

Auch dieses Semester haben alle, die Teilnehmer und ich als Veranstalter, viel gelernt. Wir haben zwei Retrospektiven durchgeführt: eine zur Halbzeit, die andere zum Abschluss. Das war angemessen, konnte insbesondere ich auf die Erkenntnisse zur Halbzeit in Teilen reagieren. Ich denke, die Teilnehmer konnten dadurch Ihre Arbeiten vertiefen.

Ich möchte allen danken, die sich für die Projektstudie engagiert haben. Wir haben zu einem guten Miteinander gefunden. Es hat mich gefreut, dass wir offen miteinander reden und diskutieren konnten, so gut es in einer vermeintlich permanenten Prüfungssituation möglich ist. Dazu ist eine gehörige Portion Vertrauen nötig. Ich hoffe es nicht enttäuscht zu haben.

Danke schön!

Was hatten wir uns aufgeschrieben (meine Anmerkungen in kursiv)?

Halbzeitretrospektive

Was war aus Ihrer Sicht gut?

  • Projekte mit externen Firmen
    • Ein Projektteam hat für SAP Consulting die im Wintersemester 2009/10 weiterentwickelte Anwendung um Workflow-Aspekte erweitert. Eigentlich erst ein Thema für das 4./6. Semester.
  • Coaching bei Projektbeginn
    • Wir hatten das Glück, rechtzeitig einen sehr engagierten Coach zu finden. Ich halte diese Art des studentischen Engagements für alle sehr hilfreich.
  • Aufwand ist mit "realen" Projekten vergleichbar
    • So soll es sein: eine gute Simulation der Praxis.
  • Erlangen von praktischem Wissen & Erfahrungen
    • Dito
  • Vergleich mit vorherigen Semestern ist nützlich
    • Das ist das Prinzip: keine Geheimnisse.
  • Gelerntes konnte ins Projekt eingebracht werden
    • Für einen Erfolg in der Projektstudie benötigen Sie die Kenntnisse aller Informatikfächer des Grundstudiums. Schön, wenn Sie das eher theoretische Wissen endlich vertiefen konnten.
  • Die Projektstudie findet zu gutem Zeitpunkt statt (im 3. Semester)
  • Umgang mit Trac, Liferay und Maven gelernt
    • Alles für die Softwareentwicklung wichtige Werkzeuge. Nicht zu vergessen: Mercurial und Hudson ;-)
  • Selbstständige Themenwahl
    • Das war dieses Semester ein Experiment. Sie haben sich schöne Aufgaben gestellt, um das Studiengangsportal aufzubauen.

Was war auch Ihrer Sicht verbesserungswürdig?

  • Teamzusammenstellung nach Stärken / Schwächen
    • Einige Teams waren in der Tat, was entwicklungsstarke Teilnehmer angeht, eher schwach besetzt. Manchmal stellt sich das auch erst im Verlauf des Semesters heraus. Die zufällige Zusammensetzung soll Sie zum einen im Grundstudium ermuntern, sich mit Programmierung zu beschäftigen. Zum anderen ist auch in der beruflichen Praxis die Teamzusammensetzung immer wieder "verbesserungswürdig".
  • Zu wenig Räume (vor allem Dienstags)
    • Die Anzahl der Studierenden wächst leider schneller, als Gebäude gebaut werden können. Ich denke trotzdem, dass wir mit der Aufteilung in Montag (viele freie Räume) und Dienstag (eher gemeinsame Termine) das gut hinbekommen haben.
  • Mehr Projekte mit externen Firmen
    • Ich versuche gerne Ihre Interessen mit denen der Unternehmen in Einklang zu bringen.
  • "Test-Projekte" schon vorher? (z.B. im 2. Semester?)
    • Das ist ein Punkt der sog. "Studien- und Prüfungsordnung", den ich selbst nicht alleine beeinflussen kann. In der nächsten Ordnung wird es aber schon im 1. und 2. Semester Freiräume für Projekte geben. Lassen Sie sich überraschen. Wir als Studiengang haben dies im Blick.
  • Teamgröße sollte bei allen gleich sein
    • Das lässt sich nicht immer einhalten. Noch problematischer wird es, wenn mehrere Teilnehmer aus einem Team die Projektstudie vorzeitig beenden wollen. Aber ich probiere es immer.
  • Zeitplanung
    • Ja, ein wichtiger Punkt. Fangen Sie von Beginn an mit einer angemessenen Planung an. Lassen Sie gerade am Anfang die Zügel nicht schleifen. Einmal im Rückstand lassen sich die zu erledigenden Aufgaben sehr schwer nachholen.
  • Mehr Hilfestellungen bei Liferay
    • Stimmt, da habe ich Sie ins kalte Wasser geworfen. Ab kommenden Semester sollten alle Teilnehmer schon im 2. Semester eine erste Einführung durch einen Kollegen (in Web Engineering 2) erhalten haben. Siehe auch den nächsten Punkt.
  • Ggf. Coach für Entwickler
    • Eine gute Idee. Bisher rekrutierte sich der Coach eher aus der Reihe der früheren Projektleiter und konnte daher weniger bei der eigentlichen Entwicklungsarbeit helfen. Im kommenden Semester wird es einen Coach für Entwickler geben.
  • Detaillierte Aufforderungen vielleicht später formulieren
    • Eine gute Taktik, sich nicht zu früh zu verzetteln. Passt auch zu dem meist iterativ, inkrementell ausgestalteten Vorgehensmodell.
  • Unstimmigkeiten zwischen Professor und Coach
    • Das kann passieren, wenn zwei Menschen nicht identisch sind. Durch mehr Kommunikation mit den Coaches werde ich versuchen, widersprüchliche Aussagen zu vermeiden.
  • Projekttools sollten vorgestellt werden
    • Wurden sie doch. Aber ich gebe zu: das eine oder andere Werkzeug könnte eher vorgestellt werden.

Was gab es für Ideen?

  • Teameinteilung über "Gruppenköpfe"
    • Hier ist die Idee, ähnlich wie bei der Fußball-WM/-EM, sicherzustellen, dass entwicklungsstärkere Teilnehmer in allen Teams vorkommen. Offen ist aber, wie gute Entwickler zu Beginn des Semesters verlässlich erkannt werden können. Es gab immer wieder Fälle, bei denen jemand sich gesteigert hat oder sich dann doch als schwächer herausstellte. Ich werde diesen Punkt im nächsten Semester einmal ausprobieren.
  • zusätzlicher Coach für Entwicklung / QS / Dok.
    • Siehe oben
  • Ab nächstem Semester sind alle Entwickler
    • Die feste Rolleneinteilung mag zum einen eine gewisse Sicherheit geben. Zum anderen fördert sie aber das Scheuklappendenken. Ein geschätztes Viertel macht den Eindruck, als müssten sie nur die eigenen Aufgaben erfüllen, ohne auf das Gesamtergebnis zu schauen. Wenn jeder für das gesamte Projekt verantwortlich ist, so ist meine Hoffnung, erhöht sich die Teamleistung. Probieren wir es aus.
  • möglichst 6-7 Mitglieder pro Team, eher nicht 5
    • Ja, sehe ich auch so.
  • "Projektmanagement 2"-Skripte erweitern mit Beispielen
    • Siehe oben ("Projekttools")
  • Bessere Einleitung von Tutorials
    • Siehe oben ("Projekttools")
  • Teilnehmer schon im 2. Semester Trac arbeiten lassen ("Software Engineering 1", "Projektmanagement 1")
    • Guter Punkt. Habe ich für SE1 eingerichtet.

Abschlussretrospektive

Viele Punkte aus der Halbzeitretrospektive fanden sich in der sehr gut moderierten Abschlussretrospektive wieder. Eine Punkte wurden relativiert, einiger verstärkt.

Rechtzeitig anfangen

Das Semester ist mit 15 Wochen eher kurz. Der erste Monat wird für die Teamfindungsprozesse und die Ermittlung der Anforderungen benötigt. Die letzten drei Wochen sind für den Test und den Projektabschluss nötig. Dazwischen bleibt nicht viel Zeit. Für einige Teams war es sehr hilfreich, dass einige Teilnehmer sehr früh mit der (persönlichen) Codepräsentation begonnen haben. Dabei gab es wichtiges Feedback.

Kann ich nur bestätigen. Ich weiß, gerade in der ersten Zeit ist es schwierig von dem eher passiven Konsum der Vorlesungen auf die Aktivität der Projektstudie umzuschalten. Es ist schwierig, sich die Finger im Projekt "schmutzig" zu machen, aktiv zu werden. Üben Sie das. Im Berufsleben kommt man mit Passivität nicht weiter. Passiv wird nicht gelernt. Ich kann Sie nicht lernen.

Auslosen der Teilnehmer

Dies wurde rückblickend nicht mehr so sehr kritisch gesehen, wie noch zur Halbzeit.

Ich probiere es trotzdem einmal mit den "Gruppenköpfen" ;-)

Eigene Rollenverteilung

Sie sahen es als gut an, dass Sie selbst Ihre Rollen bestimmen konnten. Natürlich innerhalb der von mir gezogenen Grenzen: 1 Projektleiter, maximal 1 Dokumentator, maximal 1 Teilnehmer für Qualitätsmanagement, Rest Entwickler.

Im nächsten Semester soll es, wie oben angesprochen, diese starren Rollen nicht mehr geben. Jeder Teilnehmer soll Software entwickeln, jeder leitet über einen kurzen Zeitraum das Projekt, jeder schreibt ein Besprechungsprotokoll, jeder macht Qualitätssicherung, ... Lediglich für den ersten Monat wird es einen fest bestimmten Projektleiter geben.

Erfahrungen

Wie von mir zu Beginn versprochen ("Die Projektstudie ist auf eine gewisse Art und Weise ein Selbsterfahrungstrip") erkannten Sie, wie viel Sie in diesem Semester gelernt haben. Eine Teilnehmerin meinte letztens zu mir: "Zuerst glaubte ich dem Coach nicht, was man alles lernt. Aber gegen Ende hat sich alles zusammengefügt". Die Einführungen und Tutorials in "Projektmanagement 2" fanden Sie ebenfalls gut, wie auch die nun vertieften Kenntnisse in den Werkzeugen.

Es freut mich, dass meine Anstrengungen fruchtbar waren ;-). Ich nehme das fürs nächste Semester mit und versuche die Teilnehmer eher zu Erfolgserlebnissen zu bringen.

Literatur

Das in der parallel stattfindenden Veranstaltung "Software Engineering 2" verwendete Buch war für einige Teilnehmer gut geeignet, um z.B. das Wissen zu Softwaretests zu vertiefen.

So soll es sein.

Studentischer Coach

Der studentische Coach hat mit seiner Coachingarbeit allen Teams sehr geholfen.

Ich finde es gut, dass sich immer ein guter Coach findet und wir die Mittel haben, ihn zu finanzieren.

Vorgehen nach PMI

Die Kenntnis der 9 Wissensgebiete nach PMI, die im 2. Semester in "Projektmanagement 1" behandelt werden, hat vielen sehr in ihrer Projektarbeit geholfen.

Eher Schluss

Die Deadline für die Projektstudie sollte nicht ans Ende des Semesters gelegt werden, sondern eine Woche früher. So ist es für alle Teilnehmer einfacher, sich auf die anschließende Prüfungszeit vorzubereiten.

Für die nächste Projektstudie plane ich dies so ein.


Falls ich etwas vergessen oder ungeschickt dargestellt habe, einfach eine E-Mail an mich. Oder hinterlassen Sie einen Kommentar zu diesem Blogeintrag.