Prof. Dr. Detlef Kreuz

Projektstudie Softwareentwicklung SS 2011: Lessons Learned

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.