Implizite Informationen

Die Projektstudie verlief in diesem Semester leicht anders. Während sich die Auswahl der Werkzeuge stabilisiert hat, rückten Aspekte, wie die von mir geforderte Aufgabenrotation in den Vordergrund. Nichts ist so beständig wie die Änderung.

Aufgabenrotation

Nach den Erfahrungen der letzten Semester hatte ich entschieden, dass alle Teilnehmer jede Rolle wenigstens einmal ausüben sollte. Nach meiner Beobachtung "versteckten" sich früher immer wieder Teilnehmer hinter ihren Rollen bzw. wurden auf diese abgeschoben. Auch stellten einige Studierenden vor der Projektstudie die Frage, ob es wahr sei, dass ein Projektleiter eine bessere Note erhält, als ein Entwickler.

(Die Projektleiter bekamen in der Vergangenheit tendenziell bessere Noten, weil sie sich mehr engagiert hatten und bessere Ergebnisse erzielten. Teilweise zwingt sie ihre Rolle dazu.)

In der Projektstudie gibt es die Rollen "Projektleiter", "Entwickler", "Dokumentar", "Qualitätsmanager". Jeder Teilnehmer soll jede Rolle wenigstens ein. zwei Wochen ausüben. So meine Entscheidung. Wann ein Rollenwechsel stattfindet, überließ ich den Projektteams. Zusätzlich soll jeder Teilnehmer mindestens zwei der wöchentlichen Statusreports verfassen.

In der Realität verursachte meine Entscheidung Probleme. Einige Teams hatten die Zeitpunkte und die Verteilung der Rollen nicht gut durchdacht. So war zum Beispiel ein Teammitglied zu Beginn Projektleiter und wechselte mit Beginn der Entwicklungsarbeiten in die Entwicklerrolle. Ein anderes Teammitglied machte es umgekehrt. Der Effekt: das erste Teammitglied hatte zu Beginn wegen der Planungstätigkeiten viel Arbeit, ebenso später als Entwickler. Das andere Teammitglied hatte zu Beginn als Entwickler wenig zu tun, ebenso nach Beginn der Entwicklungsarbeiten als Projektleiter.

In der Halbzeitretrospektive äußerten sich die Teilnehmer:

• Einarbeitung zu aufwendig
• Aufgabenrotation ist nicht notwendig, da Stellvertreterregelung gelebt wird
• Ungeplante Aufgaben durch zusätzliche Kommunikation / Übergabe
• Ungleiche Arbeitsverteilung

Aber auch:

• Aufgabenrotation fördert Kommunikation
• Rotation ideal nach einer Iteration

Nach der Halbzeitretrospektive entschied ich, dass es nur noch eine Aufgabenrotation geben soll. Jeder Entwickler soll mindestens 3 Wochen in einer anderen Rolle arbeiten und umgekehrt. Jeder Teilnehmer erstellt mindestens zwei der wöchentlichen Statusreports.

Die Abschlussretrospektive bestätigte diese Entscheidung, die im kommenden Semester Bestand haben wird.

Aufgabenverteilung

In der Halbzeitretrospektive deutete es sich an, dass viele Teilnehmer zu sehr in ihren jeweiligen Rollen lebten, ohne das gesamte Projekt im Blick zu haben. Daher kam die Anregung, dass die Teams zukünftig die Planung gemeinsam durchführen (bis auf ein, zwei Mitglieder, die sich hauptsächlich um die Entwicklungsumgebung kümmern) und dies nicht nur dem Projektleiter überlassen. Während der eigentlichen Entwicklungsphase übernehmen dann alle Teilnehmer Entwicklungsaufgaben, mit unterschiedlichen Schwerpunkten. Ein, zwei Teammitglieder kümmern sich auch um das Qualitätsmanagement, ein Teammitglied erstellt auch die nötige Dokumentation. Protokolle, o.ä. werden reihum erstellt. Der Projektleiter koordiniert ggf. die Aktivitäten, entwickelt aber auch.

Ich selbst halte dieses Modell für angemessen. Es bedeutet ein gehöriges Maß an Teamgeist von Anfang an. Deshalb werde ich es in Zukunft fördern, nicht erzwingen.

Lernziele

Schön fand ich es, dass die Teilnehmer zur Halbzeit- und zur Abschlussretrospektive viele der Lernziele für sich erfüllt sahen:

• Kennenlernen der Kommilitonen
• Kommunikationsfähigkeiten ausbauen
• Arbeiten im Team
• Zusammenhalt, gegenseitige Hilfe
• Fehlerbehebung, Arbeiten unter Stress
• Terminmanagement ist wichtig, sowohl das persönliche als auch für das Team
• Verantwortung übernehmen
• Anwendung der Programmierkenntnisse
• Kennenlernen praxisnaher Werkzeuge (Trac, Mercurial, Maven, Jenkins, Liferay, ...)

Einige Teilnehmer meinten, dass die Erfahrung in der Projektarbeit nützlich für jede Bewerung sein wird. Ich hoffe das.

Coaches

In diesem Semester gab es zwei Coaches: ein Coach für das Projektmanagement und ein Coach für technische Fragen. Liferay und die Entwicklung von Portlets war für viele etwas ungewohnt.

Die Entscheidung für zwei Coaches wurde von allen positiv aufgenommen. Sie waren gute Ansprechpartner und haben mit Rat (und nicht mit Tat, so soll es sein) den Teams weitergeholfen.

Auch von mir ein "Dankeschön" an E.K. und M.A.!

Frag-würdiges

Zwei Punkte sind für die Teilnehmer fragwürdig gewesen. Zuerst den der Teamzusammensetzung.

Ich setze die Teams nach dem Zufallsprinzip zusammen. Entweder mit einem Würfel oder mit einer kleinen Session in Python. Zur Halbzeitretrospektive wurde diese Entscheidung hinterfragt.

Nach Meinung der meisten Teilnehmer sollte in jedem Team mindestens ein "guter" Entwickler sein, der zugleich Ansprechpartner für "schwache" Entwickler ist. Zugleich soll er die Rolle eines "Chef-Entwicklers" ausüben und für die Architektur verantwortlich sein, sowie den Quellcode der anderen überprüfen. Alle Teams sollten in etwa gleich stark sein.

Gut fand ich den Gedanken eines Teilnehmers, ob alles auf die Entwickler "geschoben" werden soll. Zur Abschlussretrospektive kamen Fragen auf, wie man erkennen kann, dass jemand "gut" ist. Gute Noten in den Programmierveranstaltungen lassen nicht unbedingt auf gute Fähigkeiten schließen. Rückblickend war es für alle schwierig zu entscheiden, was die einzelnen Teammitglieder wirklich können. Das hat sich erst während der Projektarbeit herauskristallisiert.

Abschließend haben sich alle mit der zufälligen Verteilung auf die Teams anfreunden können, zumal sie so ihre "Soft Skills" verbessern konnten. Manche kannten sich vorher nicht so gut, wie zum Ende hin.

Den anderen "frag-würdigen" Punkt finde ich ebenfalls bemerkenswert: ein Team überlegte, welchen (wirtschaftlichen) Wert ihre Arbeit besitzt. Dieses Team führte eine Kostenanalyse durch. Schön, wenn die Teilnehmer so Kenntnisse aus den BWL-Fächern vertiefen.

Tipps

Zum Abschluss noch Tipps der Teilnehmer, meine Anmerkungen sind kursiv:

• Klare Zielsetzung schaffen, zur Not mehrfach nachfragen.
  • Oh, ja!
• Beim Aufbau des Wikis nicht unbedingt auf die Vorgänger vertrauen.
  • Kann ich nur unterstützen. Die Vorgänger könnten das eine oder andere falsch gemacht haben. Also trotz Kopieren das Nachdenken nicht vergessen.
• Einarbeitung in vorhandenen Programmcode ist schwieriger als ein komplett neues Projekt zu beginnen.
  • Kommt auf den Programmcode an...
• Codepräsentation frühzeitig durchführen.
  • Ich kann verstehen, dass man Unangenehmes vor sich herschiebt. Bei der Codepräsentation, das de facto ein (bewertetes) Review ist, erhalten Sie Hinweise zur Verbesserung. Das hilft Ihnen und Ihrem Projekt.
• Einarbeitung in Liferay ist nicht einfach.
  • Hmm, das sollte durch frühere Veranstaltungen abgedeckt sein. Laut Dozent wurde es auch behandelt. Haben Sie das Thema übersprungen / nicht näher studiert?
• Schon in den ersten Semestern kleinere Entwicklungsprojekte durchführen.
  • Wird von einigen Dozenten verstärkt durchgeführt. Evtl. hilft auch die geplante neue Version der SPO.

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

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.
• PM2-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.

Gestern durfte ich an einer sehr interessanten und teilweise emotionalen Diskussion teilnehmen. Es war der Abschlusstermin der diessemestrigen Projektstudie Softwareentwicklung, von mir großspurig Retrospektive getauft. Ob es wirklich eine Retrospektive war sei einmal dahin gestellt. Auf jeden Fall haben wir uns über Bewahrenswertes, Verbesserungswürdiges und Bemerkenswertes unterhalten.

Ich möchte hier einmal die Ergebnisse zusammenstellen und ggf. kommentieren.

Auf jeden Fall möchte ich allen danken, die dafür gesorgt haben, dass eine Diskussion zu Stande gekommen ist. Da kann ich noch so "nett" sein. Letzten Endes ist es meine Aufgabe, die Arbeiten zu bewerten. Um so schöner finde ich es, dass wir es in diesem Semester zu einer offenen Diskussionskultur geschafft haben.

Danke schön!

So, nun die Punkte, die wir angesprochen haben. Meine Bemerkungen sind kursiv gekennzeichnet.

Bewahrenswertes

Teambildung

Die Zusammenstellung der Teams nach dem Zufallsprinzip wurde von allen positiv gesehen. Dadurch haben sich neue Bekanntschaften gebildet, insgesamt haben sich alle näher kennen gelernt.

Das Vorgeben (und Annehmen) von projektspezifischen Rollen führte nach Meinung der Teilnehmer zu einer professionellen Arbeitsweise, die sich von der üblichen Gruppenarbeit erheblich unterscheidet.

In diesem Semester kam es zum ersten Mal zu einer umfangreicheren Zusammenarbeit zwischen den Projektteams. Fehlten in einem Team bestimmte Kompetenzen, so halfen Mitglieder eines anderen Teams aus.

Das sehe ich auch so positiv. Das liegt aber nur zum Teil an der Umgebung, die ich bereit gestellt habe. Zum größten Teil ist das das Werk der Teilnehmer. BTW, heute habe ich einen interessanten Artikel über Gruppen- vs. Teamarbeit gelesen, der passt gut zur Situation der Projektstudie ;-)

Regularien

In der Projektstudie wurde nicht nur die Art und Weise vorgegeben, wie sich die Teams zusammensetzen. Neben der Festlegung auf bestimmte Werkzeuge (Trac, Mercurial) wurden weitere "Spielregeln" von mir definiert. Dazu gehörten wöchentliche Statusreports, Protokollierung aller Besprechungen, Verwendung des Ticketsystems, u.s.w.

Diese Vorgaben sollen beibehalten werden, evtl. sogar ausgebaut werden, um einen der verbesserungswürdigen Punkte, die Arbeitsbelastung, abzumildern.

Ich bin immer wieder erstaunt, wie gut feste Regeln ankommen. Zuerst denke ich, dass diese als Einschränkung empfunden werden. Im Laufe des Semesters stellt sich heraus, dass diese Regeln eher helfen. Daher werde ich in Zukunft die Regularien im Sinne von Hilfestellungen weiter ausbauen. Angedacht (und von Ihnen bestätigt) sind: definiertes "Standardteam" (1 Projektleiter, 1 Dokumentator, 1 Qualitätsmanager, Rest Entwickler), definierte Entwicklungsumgebung (Maven, Hudson, Mercurial, Trac), definierte Ablaufumgebung (Portal Server), weitere Vorlagen.

Organisatorisches

Die regelmäßigen Präsenztermine wurden positiv aufgenommen. Wir haben uns zu den festen Terminen in der großen Gruppe getroffen, offene Punkte gemeinsam besprochen, ggf. haben einige ihre Arbeitsergebnisse präsentiert und anschließen haben die Projektteams separat gearbeitet.

Dadurch wurde erreicht, dass sich jedes Projektteam regelmäßig getroffen hat, offene Punkte schneller erkannt und behoben wurden. In normaler Gruppenarbeit passiert es oft, dass man sich zu selten trifft und erst gegen Ende entdeckt: die Einzelteile passen nicht zusammen.

Ebenfalls wurde positiv angesprochen, dass ich während der Präsenztermine (und darüber hinaus) ansprechbar war. Mein Management by walking around hat vielen Teams weitergeholfen. Das sollte nach Ansicht der Teilnehmer ebenso bewahrt werden, wie der Einsatz eines studentischen Coaches.

Dieser Coach hatte angeregt, dass sich alle Projektleiter gerade in der ersten Zeit zu einem Erfahrungsaustausch treffen. Auch dieses Vorgehen hat vielen geholfen. Solche teamübergreifenden Treffen sollen zukünftig auch für andere Rollen (Entwickler, Qualitätsmanager, ...) stattfinden.

Es freut mich, dass mein Herumlaufen nicht als Spitzelversuch gewertet wurde, sondern eine Hilfe war. Auch in Zukunft werde ich versuchen, einen studentischen Coach zu finden, der den Teilnehmern die Hemmschwelle mindert, zu fragen und ggf. zu eskalieren. Die übergreifenden Besprechungen halte ich für eine sehr gute Idee.

Inhaltliches

Ingesamt wurde der Lerneffekt der Projektstudie als groß eingestuft. Im Grundstudium wurden eher theoretische Inhalte gelernt, die nun angewendet werden konnten. Trotzdem wurden auch die eher theoretischen Inhalte dieses Semesters als nützlich für die Projektstudie anerkannt. Die Teilnehmer äußerten, dass sie sich selbst besser kennengelernt haben, insbesondere auch was ihre eigene fachlichen Ziele betreffen.

Seufz, das ist das Ziel der Projektstudie. Und wenn das erreicht ist, bin auch ich zufrieden ;-).

Verbesserungswürdiges

Arbeitsbelastung

Die Arbeitsbelastung wurde von sehr vielen als zu hoch angesehen. Einige meinten sogar, dass man sich in diesem Semester zwischen der Projektstudie und sonstigen Prüfungen entscheiden müsste. Es gab aber auch Stimmen, die meinten, die Belastung sei hoch, aber nicht zu hoch gewesen.

Sicher ist die Arbeitsbelastung bei einer Projektstudie nicht unerheblich. Die Projektstudie ist mit 6 Credits bewertet, dass sind 180 Stunden. De facto kommen noch die 2 Credits von Projektmanagement 2 hinzu, dass man auf eine Nettoarbeitszeit von einem Monat kommen kann.

Ich denke, die Gründe für die als hoch empfundene Arbeitsbelastung sind vielfältiger Natur. Zunächst einmal ist es die erste Projektstudie im Studium. Vorher wurden Vorlesungen und Übungen besucht, bei denen man selbst nicht zu sehr aktiv sein musste. Das ist in der Projektstudie definitiv anders. Zum anderen haben fast alle Projektteams ihr Arbeitspensum selbst bestimmt und sich dabei überschätzt. Möglicherweise aus Gründen des Nichtversagenwollens unterblieben korrigierende Maßnahmen. Sicher auch aus Angst um eine schlechte Note. Es gab zu viele Details bei der Entwicklung zu beachten, mit denen sich die Teilnehmer bisher so nicht beschäftigt haben. Die Rollenaufteilung war in einigen Teams nicht optimal.

Viele dieser Punkte lassen sich durch Hinweise, durch Coaching und durch Regelungen (siehe oben) verbessern. Auch sollte die Einstufung und der Arbeitsaufwand für die Projektstudie überdacht werden. Daran bin auch ich interessiert.

Hinweise

Die Teilnehmer wünschten sich weitere Hinweise zu einzelnen Regelungen, wie z.B. zur Möglichkeit einer fließenden Rollenverteilung in Form der Definition einer Kernrolle und möglichen Varianten. Auch einige Werkzeuge, wie z.B. Mercurial und Ant bedürfen einer weitergehenden Erklärung. Einer der Teilnehmer meinte:

Mercurial ist bestimmt ein tolles Werkzeug. Wenn es näher erklärt würde, brächte es für alle einen riesigen, umfassenderen Nutzen.

Die weiteren Hinweise werde ich ab nächstem Semester gerne geben.

Transparenz bei der Benotung

Viele Teilnehmer wünschten sich eine größere Transparenz bei der Notengebung, nach dem Motto: "Wenn ich folgendes mache (unterlasse), bekomme ich eine um X% höhere (niedrigerere) Note".

Ich fand die Diskussion über den Sinn und Unsinn von Noten spannend. Lernt man für eine gute Note oder um etwas besser zu können? Das ist natürlich eine Frage, die jede(r) für sich selbst beantworten muss. Genauso wie die der Relevanz guter Noten im Zeugnis.

Die Zusammensetzung der Note ergibt sich aus den gewichteten Teilnoten "Codepräsentation", "Individuelle Leistung gemäß eigener Rolle", "Teamleistung" und "Leistung für das Team". Ich selbst (und die meisten Führungskräfte wohl auch) wäre froh, wenn man projekt- und teamunabhängig über einen festen Katalog z.B. die Leistung für das Team messen könnte. So müssen wir uns mit Heuristiken behelfen und alle das Gehirn eingeschaltet lassen ;-)

Bemerkenswertes

Ich fand die sehr intensive Nutzung des Wikis besonders bemerkenswert. Ich habe zwar noch keine Statistik erstellt, aber in diesem Semester wurde mehr mit dem Wiki (Trac) gearbeitet, als in den Semestern vorher zusammengenommen (damals: DokuWiki und Mantis). Möglicherweise hängt dies auch mit der zunehmenden Nutzung der Wiki-Technologie im Grundstudium zusammen.

Die Teilnehmer bemerkten die sehr intensive Kommunikation, sowohl innerhalb der Teams als auch zwischen den Teams. Das hätten sie sich nicht so (positiv) vorgestellt. Die darüber hinaus persönlichen Erfahrungen waren für die meisten ein Highlight.

Jetzt beim Schreiben fällt mir ein weiterer Punkt ein: viele Teilnehmer haben sich mit dem “warum” beschäftigt. Das finde ich toll. Und noch besser ist es, wenn sich alle die Frage stellen: Warum?

Bemerkenswert fanden viele (inkl. mir) die gute Moderation der Retrospektive durch zwei der Teilnehmer. Und das schöne Protokoll ;-)

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

Das Semester ist noch nicht zu Ende, aber trotzdem wird es langsam Zeit, dass ich über die Erfahrungen der Projektstudie Softwareentwicklung berichte. In der letzten Veranstaltung hatten wir uns in einem großen Kreis zusammen gesetzt, um über die Projektstudie zu reflektieren.

Zunächst möchte ich mich auf diesem Wege noch einmal bei allen Beteiligten bedanken. Es ist schwer, Feedback zu geben, wenn Noten noch nicht vergeben sind. Ich danke für Ihr Vertrauen, so offen für Sie relevante Punkte anzusprechen. Und noch dazu bei jemanden, den Sie erst vor einem Semester grob kennen gelernt haben.

Danke schön!

So, was hatte ich auf unserer Sammeltafel notiert (meine Anmerkungen in kursiv)?

Zunächst das, was als positiv empfunden wurde.

Firmenprojekte

Auch dieses Semester wurden zwei der fünf Themen von externen Firmen gestellt. Diesmal war sogar SAP Consulting mit dabei. Die andere Firma war (leider) nicht ganz so präsent. Trotzdem ist es gut, praxisnahe und -relevante Projekte durchzuführen, besonders wenn die Ergebnisse später auch produktiv eingesetzt werden.

Dies sehe ich auch so. Ich freue mich, dass wir die Strukturen haben, relativ unkompliziert Projektstudien mit externen Firmen zu planen und umzusetzen. Für das nächste Semester ist wieder etwas in Planung. :-)

Räumlichkeiten und Werkzeuge

Der reservierte Gruppenarbeitsraum Y002 wurde als sehr hilfreich empfunden. Genügend Platz, mehrere Weißwandtafeln, Steckdosen für die eigenen Notebooks unterstützten die Arbeit. Auch wenn es ruhig mehr Steckdosen sein dürften ;-)

Als Werkzeug war besonders Dropbox hilfreich. Es bietet sehr gute Möglichkeiten für den Austausch von Dateien, auch mit externen Kunden. Den einen oder anderen hat die Backup-Funktionalität sehr geholfen.

Das Wiki hat Ihnen als Wissensbasis geholfen, da auch frühere Semester hier ihre Erfahrungen dokumentiert hatten.

Die Verfügbarkeit des Gruppenarbeitsraum wird auf jeden Fall beibehalten. Ich versuche im nächsten Semester mögliche Störungen durch andere Veranstaltungen weiter zu verringern.

Den Einsatz von Dropbox sehe ich mit gemischten Gefühlen. Es hat Sie auch dazu verführt, das Werkzeug zur Versionsverwaltung (Subversion) eher zu wenig einzusetzen. Ich nehme mit, expliziter festzulegen, was in die Dropbox gehört, was in das Werkzeug zur Versionsverwaltung und was in das Wiki.

Siehe auch Punkt "Technische Hilfen" aus dem letzten Semester.

Statusberichte

Der Zwang zu wöchentlichen Statusberichten hat Ihnen geholfen, das Ziel nicht aus dem Auge zu verlieren.

Und ich hatte zunächst gedacht, Sie würden den Zwang als zu restriktiv ansehen. So kann man sich täuschen.

Jetzt zu den Punkten, die Sie als verbesserungswürdig ansehen.

Teambuilding

Sie haben einen Workshop zur Verbesserung der Teamfähigkeit angeregt. Die Teams waren ja, bis auf eine Ausnahme, im wahrsten Sinne des Wortes, zusammengewürfelt (auch wenn es kein realer Würfel war, sondern nur ein Zufallszahlengenerator). Viele Teammitglieder kannten sich vorher höchstens vom Sehen, die Gruppe musste sich zum Team zusammenraufen.

Ich gebe zu, so richtig habe ich darüber noch nicht nachgedacht. Zum einen sollen Sie genau diese Erfahrung machen: mit relativ Fremden zusammen arbeiten und nicht nur eine Gruppe, sondern ein Team sein. Ein Workshop könnte möglicherweise das Bewusstsein für "Gruppe vs. Team" schärfen, aber ob ein "Teamunfähiger" dadurch "teamfähig" wird bezweifle ich.

Der Studiengang hat in diesem Semester einen ähnlich gelagerten Workshop für die Erstsemester durchgeführt. Ich bin gespannt, welche längerfristigen Ergebnisse hier zu erwarten sind.

Mehr Retrosprektiven

Es wurde von Ihnen als gut angesehen, dass wir die Feedbackrunde zum Ende der Veranstaltung durchgeführt haben. Diese sollte aus Ihrer Sicht häufiger durchgeführt werden. Als Anregung an zukünftige Projektteams sollten Retrospektiven auch teamintern durchgeführt werden.

Die Anregung nehme ich gerne mit. Ich werde im nächsten Semester eine weitere Feedbackrunde für die Mitte des Semesters einplanen. Teaminterne Retrospektiven sollte m.E. moderiert werden. Vielleicht kann dies der studentische Coach übernehmen.

Als weder rein positiv, noch rein verbesserungswürdig haben Sie folgende Punkte angesprochen:

Pair Programming

Pair programming hat vielen geholfen, sich tiefer in das jeweilige Gebiet einzuarbeiten. Problematisch wird gesehen, dass im Werkzeug zur Versionsverwaltung nur ein Benutzer als Bearbeiter gespeichert wird.

Ja, ich nutze die Informationen aus dem Werkzeug zur Versionsverwaltung, um abzuschätzen, wer wieviel an der Entwicklungsarbeit beteiligt war. Da immer nur einer als Bearbeiter angegeben werden kann, sollten Sie sich entsprechend beim Einchecken abwechseln. Und wenn Sie zusätzlich dokumentieren, wann Sie mit wem Pair programming betrieben haben, kann ich dies berücksichtigen.

Also: keine Angst vor Pair programming

Risikomanagement

Sie bemerkten, dass es Ihnen geholfen hat, eine initiale Risikoanalyse durchzuführen. Diese sollte aber im Laufe des Projektes immer wieder durchgeführt werden, da sich die anfänglichen Annahmen immer mal wieder als falsch heraus stellen.

Ja. Das nennt man dann Risikomanagement ;-). Ich nehme das einmal als Botschaft an Ihre Nachfolger.

Zeit- / Aufgabenbewusstsein

Hier gab es nach Ihrer Auskunft erhebliche Unterschiede zwischen einzelnen Teammitgliedern. Einige sahen es eher "locker", andere sehr penibel. Dies gilt es im Team zu harmonisieren.

Dies ist sicher ein Punkt zur Teambildung. Ist von mir so gewollt, das sollen Sie lernen. Manche können das besser als andere. Aber so ist das Projektleben ;-). Auch dies nehme ich als Anregung an Ihre Nachfolger im kommenden Semester. Evtl. kann auch hier der studentische Coach unterstützen, z.B. in den teaminternen Retrospektiven.

So, habe ich noch etwas vergessen? Ich hoffe mal nicht und freue mich, Sie dann im nächsten Semester in Projektmanagement 3 zu sehen, wenn Sie nicht das Proxasissemester absolvieren. Falls ich etwas vergessen habe, einfach eine E-Mail an mich. Oder hinterlassen Sie einen Kommentar zu diesem Blogeintrag.