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 ereicht, 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 Spitzelversich 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.

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.

1. 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. :-)

2. 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 7 aus dem letzten Semester.

3. 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.

4. 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.

5. 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:

6. 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 dem Pair programming

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

8. 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.

Wenn Du ein Schiff bauen willst, so trommle nicht Männer zusammen, um Holz zu beschaffen, Werkzeuge vorzubereiten, Aufgaben zu vergeben und die Arbeit einzuteilen, sondern lehre die Männer die Sehnsucht nach dem weiten endlosen Meer.

Heute habe ich in einem sehr interessanten Buch ein Zitat von Plutarch gelesen, das mich sicher auch einige Zeit in meiner Arbeit als Lehrender begleiten wird:

Der Geist ist nicht wie ein Gefäß, das gefüllt werden soll, sondern wie Holz, das lediglich entzündet werden will.

Wenn das keine Handlungsanweisung für Lehrende (und Lernende!) ist.

Das Zitat in einem größeren Kontext erhellt (!) sicher noch mehr:

Wir müssen uns – nachdem wir die grundlegenden Aspekte begriffen haben – (gegenseitig) dazu ermuntern, in uns selbst alles andere miteinander in Verbindung zu setzen, unsere Erinnerung zu nutzen, um unser originäres Denken zu lenken, und das, was ein Anderer sagt, als Ausgangspunkt anzuerkennen, als Saatkorn, das genährt und aufgezogen werden will. Den die richtige Analogie füe den Geist ist nicht etwa das Gefäß, das gefüllt werden muss, sondern Holz, das entzündet werden will – sonst nichts -, und dann spornt es einen zu Originalität an und flößt einem die Sehnsucht nach Wahrheit ein.

Angenommen, jemand ginge los, um seine Nachbarn um Feuer zu bitten; er fände dort eine zuverlässige Flamme vor und bliebe einfach dort, um sich fortwährend zu wärmen. Dies unterscheidet sich in nichts von einem Anderen, der jemanden aufsucht, um etwas von dessen Vernunft mitzubekommen, und nicht begreift, dass er seine eigene Flamme, seinen eigenen Intellekt, entzünden muss; aber er ist zufrieden damit, vom Vortrag verzaubert dort zu sitzen, und die Worte lösen lediglich assoziative Denkvorgänge aus und bringen quasi nur seine Wangen zum Erröten und Glut in seine Glieder. Aber er hat im warmen Schein der Philosophie die feuchte Düsterheit im Inneren seines Geistes nicht vertrieben oder zerstreut.

Wir Lehrenden dürfen nicht einfach nur Fakten, Fakten, Fakten präsentieren. Sicherlich haben diese einen Wert, wenn es darum geht, Grundlegendes aus einem Fach als Starthilfe weiter zu geben. Aber dann muss der Funke überspringen. Wir Lehrende müssen die Flamme unseres Wissens weiterreichen, nicht nur mit warmen Worten wärmen.

Wir Lernende dürfen uns nicht damit zufrieden geben, dass ein Anderer uns schon mit dem richtigen Wissen versorgen wird. Wir müssen selbst lernen, das kann der Lehrende nicht für uns tun. In der deutschen Sprache gibt es aus gutem Grund keine wirkliche Passivform zu “Lernen”. “Ich wurde gelernt” klingt jedem grausam in den Ohren.

Her mit dem Feuer, ich brenne darauf zu lernen und zu lehren ;-)

Ich möchte mich auf diesem Wege noch mal bei allen Beteiligten bedanken. Es ist schwer, Feedback zu geben, wenn die Noten noch nicht vergeben sind. Es gehört eine gehörige Portion Vertrauen dazu, so offen zu agieren, auch wenn ich betone, dass ich den Inhalt von Feedbackgesprächen nicht in die Notenvergabe mit hinein beziehe. Vielleicht gab es in der Vergangenheit auch negative Erfahrungen mit dem einen oder anderen Kollegen. Deshalb: Danke schön!.

Was hatte ich mir aufgeschrieben (meine Anmerkungen in kursiv)?

1. Firmenprojekte

Die Themen von zwei der vier Projekte wurden von externen Firmen gestellt. Dies wurde von allen positiv gesehen. So (relativ) früh im Studium schon mit Unternehmen in Kontakt zu treten und “echte” Projekte durchzuführen war für alle Beteiligten gut.

Sehe ich auch so. Ich hoffe auch für das nächste Semester wieder Unternehmen zu gewinnen, die für Projekte zur Verfügung stehen.

2. Zu viel Zeit vertan, sich selbst überschätzt

Gerade in der Anfangsphase wurde nicht genug Arbeit in die Planung und den Entwurf der Software investiert. 15 Wochen sind eine Menge Zeit und zu Beginn sieht man nicht, dass man diese wirklich benötigt. Dazu gehört auch, das die Aufgabe eher unterschätzt und sich viele selbst überschätzt haben. Am Anfang wurde zu viel dokumentiert. Die geforderte Dokumentation wurde als zu umfangreich bewertet, die Struktur für das Pflichtenheft sollte vorgegeben werden.

Ja, auch nach meinem Gefühl haben Sie es zu Beginn etwas zu locker angehen lassen. Die zu Beginn ungenutzte Zeit kann später kaum aufgeholt werden, dazu sind 15 Wochen zu kurz! Sie besuchen nicht nur meine Veranstaltung ;-)

Durch die zu erstellende Dokumentation möchte ich sicherstellen, dass Sie die wichtigsten Schritte der Softwareentwicklung auch durchführen. Es geht mir nicht nur um das Endergebnis. Mir ist auch der Weg zum Ergebnis wichtig. In einem relativ kleinen Projekt wie diesem mag es egal sein, wie man zum Ziel kommt. Spätestens bei einem größeren Projekt bekommen Sie dann aber Probleme. Das erste größere Projekt ist dann u.U. Ihre Abschlussarbeit.

Die Struktur für einzelne Dokumente gebe ich ungern vor, da diese nur als Formulare denn als lebende Dokumente aufgefasst werden. Ich möchte Ihr Nachdenken und die Kommunikation fördern und nicht nur ihr Vermögen Formulare auszufüllen. Das müssen Sie woanders genug.

3. Mehr Coaching

Einige Teams waren der Meinung, sie hätten sich zu früh auf eine später als falsch erkannte PM-Methode festgelegt. Statt V-Modell wäre z.B. eine agile Methode besser geeignet gewesen. Um dieses zu verhindern, sollte vor dem Festlegen auch eine Methode ein Coaching vorgesehen werden. Gut wäre auch eine Art “Pflichtgruppencoaching”, bei dem ein Termin als Pflicht zum zwanglosen Kennenlernen vorgesehen ist.

Sowohl die studentische Hilfskraft als auch ich stehen Ihnen beratend zur Seite. In einer Projektstudie sollten die Aktivitäten von Ihnen, den Teilnehmern, ausgehen. Wenn Sie unsicher sind, fragen Sie. Und wenn Sie meinen, eine falsche Entscheidung getroffen zu haben, dann korrigieren Sie diese.

4. Verschiebung des Termins für “Projektmanagement 2″

Die Verteilung der Stunden war nicht optimal. Der Termin der parallelen Veranstaltung Projektmanagement 2 lag nicht optimal. 6 Stunden am Block für die Projektstudie und 2 Stunden für “Projektmanagement 2″ erlaubten keine so gute Nutzung von gemeinsamer Zeit.

Positiv war das Vorziehen der Inhalte von “Projektmanagement 2″.

Für das kommende Semester ist geplant, 2 Blöcke a 4 Stunden für beide Veranstaltungen vorzusehen.

5. Rolle des Prof.

Es war nicht immer klar, in welcher meiner diversen Rollen ich mit Ihnen kommuniziere:

1. als Professor, der Ihre Arbeit bewertet,
2. als Entwicklungsleiter, der dafür sorgen soll, dass die Projekte vorangehen,
3. als Kunde, sofern es kein “Firmenprojekt” ist,
4. als Berater für Probleme aller Art.

Am Anfang, als Sie mich noch nicht vertieft kennen gelernt hatten, ist vielen von Ihnen auch nicht klar gewesen, dass ich wirklich genügend “schizophren” bin, um diese Rollen auch auszufüllen.

Wie jemand von Ihnen meinte: zum ersten Termin sollten wir in den Biergarten gehen. Dem stimme ich dem Sinne nach zu (Mitte März und evtl. Anfang Oktober könnte das Wetter nicht mitspielen). Möglicherweise haben Sie sich in den ersten Semestern ein Bild von den Professoren gemacht, dem ich in dieser Veranstaltung nicht entspreche. Und zur Kennzeichnung der aktuellen Rolle bin ich auf diese Mütze hingewiesen worden (Dank an A.K.).

6. Technische Probleme

Der Zugriff auf die technischen Hilfen, wie Mantis, DokuWiki und Subversion-Server, ist nur über das fehleranfällige VPN der Hochschule möglich. Das Wiki erlaubt es zudem nicht, mehrere Versionen einer Datei zu speichern.

Den Server betreiben wir selbst. Wir sind darin aber höchstens geübte “Laien”, die grob wissen, wie man es richtig macht. Einen Server öffentlich ins Netz zu stellen stellt evtl. ganz andere Anforderungen, gerade wenn der Quellcode bei “Firmenprojekten” nicht zu sehr öffentlich sein soll. Wenn es mit dem VPN Probleme gibt, melden Sie diese bitte an das Rechenzentrum der Hochschule. Das mache ich auch ;-).

Kaum eine Wiki-Implementation erlaubt es von einer Datei mehrere Versionen zu speichern. Ich sehe mir aber einmal an, ob ich die Konfiguration so ändern kann, dass ein ähnlicher Effekt erreicht wird. Ansonsten bleibt als Abhilfe, dass die zu versionierenden Dateien im Subversion gespeichert werden und im Wiki dorthin per URL verwiesen wird.

7. Technische Hilfen

Der Einsatz von Dropbox war für das Arbeiten im Projekt sehr hilfreich. Gut war auch, dass projektübergreifende Tipps & Tricks im Wiki standen.

Dropbox, ggf auch mit TrueCrypt sind seit einiger Zeit auch in meinem Werkzeugkasten. Diesen suche ich zu erweitern. Evtl. helfen auch Dienste wie Twitter bei der Projektkommunikation. Ich probiere gerade auch andere Werkzeuge zur Versionierung, Bugtracking und Dokumentation aus.

Das Wiki lebt übrigens auch von Ihren Beiträgen ;-)

8. Viel gelernt

Sie haben viel über sich und andere gelernt. Positiv vermerkten Sie, dass Sie in dieser Veranstaltung aus ihren Fehlern lernen konnten und dies nicht erst im Berufsleben tun mussten. Sie haben nicht nur technische Fähigkeiten erworben, sondern begriffen, dass es sehr stark auf Kommunikation ankommt.

Das sollte das Ziel dieser Veranstaltung sein. Wenn es erreicht wurde, freut es mich sehr.

Eine kleine Anregung: es sollte m.E. nicht nur ein Kennenlerntermin mit dem Prof. geben, sondern auch Sie sollten sich untereinander kennen lernen. Denken Sie an die Teamuhr aus Projektmanagement 1 …

So, habe ich noch etwas vergessen? Ich hoffe mal nicht und freue mich, Sie dann im nächsten Semester in Projektmanagement 3 zu sehen. Dort geht es darum, erworbenes Wissen an andere zu vermitteln.

Filme

Matrix

Matrix ist ein Science-Fiction-Film aus dem Jahr 1999. Aus Informatiksicht ist er zweierlei interessant. Zum einen ist die Matrix nichts anderes eine riesige Simulation unserer Wirklichkeit. Sie ist so gut, dass sie nicht von der Wirklichkeit zu unterscheiden ist. Letzten Endes ist das eine Aufgabe in der Informatik: reale Vorgänge zu modellieren und in einem (digitalem) Rechensystem abzubilden.

Der Film Matrix zeigt, wie verwirrend eine solche Simulation sein kann. Übrigens, er ist nicht der erste seiner Art. Schon 1973 zeigte der deutsche Film Welt am Draht Konsequenzen einer sehr weitgehenden Simulation auf. Ebenfalls 1999 gab es ein Remake, The 13th Floor – Bist du was du denkst?. Wem die philosophische Überfrachtung von Matrix nicht zusagt, kann sich an diesen Filmen ausprobieren. Man verpasst aber auch nette “Special Effects” und den zweiten wichtigen Aspekt.

Nämlich die Frage nach der roten oder blauen Pille. Der Held des Film muss sich entscheiden, ob er die ganze Wahrheit erfahren möchte, mit allen Konsequenzen. Dann soll er die rote Pille schlucken. Mit der blauen Pille würde er glauben, was er bisher geglaubt hat. Natürlich nimmt er die rote Pille. Um den Film zu zitieren (aus: Fehler in der Matrix):

Dies ist deine letzte Chance. Danach gibt es kein Zurück. Schluckst du die blaue Kapsel, ist alles aus. Du wachst in deiner Welt auf und glaubst, was du glauben willst. Schluckst du die rote Kapsel, bleibst du im Wunderland, und ich führe dich in die tiefsten Tiefen des Kaninchenbaus.

Dies ist eine ultimative Entscheidung. Solche Entscheidungen sind immer mal wieder zu treffen. Mit meiner Entscheidung für die Informatik habe ich einen ganz anderen Blick auf die Hintergründe computergestützter Systeme erhalten. Im Positiven wie im Negativen.

Monty Python

Monty Python war eine britische Komikergruppe, die ihre Blütezeit in den 70er-Jahren hatte. Viele Informatiker haben eine gewisse Nähe zum Humor dieser Gruppe. Ich würde ihn als schräg, schwarz, britisch, absurd, hintersinnig bezeichnen.

So ist Monty Python zum Namensgeber der Programmiersprache Python geworden (siehe: Why is it called Python?).

Aber auch die Bedeutung des Wortes Spam ist auf einen Sketch dieser Gruppe zurück zu führen.

Alles Gründe, sich einmal mit Monty Python zu beschäftigen. Wenn man davon absieht, dass es einen Riesenspass macht.

Bücher

Per Anhalter durch die Galaxis

Sie wollten immer schon mal wissen, was es mit dem Sinn des Lebens auf sich hat? Oder warum Sie am 25. Mai eines jeden Jahres vermehrt Leute mit Handtüchern sehen? Das hat seinen Ursprung in der einzigen Trilogie in fünf Bänden, eben Per Anhalter durch die Galaxis.

Den Inhalt und den Geist dieser Bücher wieder zu geben ist so gut wie unmöglich. Ist es Science-Fiction? Oder ganz einfach ein Roman? Auf jeden Fall hat diese Reihe einen ähnlichen Einfluss auf die Informatik wie Der Herr der Ringe auf das Fantasy-Genre.

Der Humor hat etwas von Monty Python, ist also auch für Informatiker stilbildend. Und schon im ersten Band werden Sie die Antwort auf die wichtigste Frage kennen lernen: “42″!

Wie war noch mal die Frage?

Alice im Wunderland & Alice hinter den Spiegeln

Die Geschichten von Alice im Wunderland und Alice hinter den Spiegeln sind nicht nur einfach schöne Geschichten. Der Autor Lewis Carrol war Mathematiker und zeigt damit, dass auch technisch orientierte Menschen sehr phantasievoll sein können.

Beide Bücher können als Vorbereitung für den Film Matrix dienen, siehe das Zitat zur roten Pille. In Alice hinter den Spiegeln gibt es ein schönes Kapitel mit dem Springer (engl. “Knight”), in dem es um Namen geht. Hier der Ausschnitt (aus: Through the Looking-Glass):

‘The name of the song is called “HADDOCKS’ EYES.”‘

‘Oh, that’s the name of the song, is it?’ Alice said, trying to feel interested.

‘No, you don’t understand,’ the Knight said, looking a little vexed. ‘That’s what the name is CALLED. The name really IS “THE AGED AGED MAN.”‘

‘Then I ought to have said “That’s what the SONG is called”?’ Alice corrected herself.

‘No, you oughtn’t: that’s quite another thing! The SONG is called “WAYS AND MEANS”: but that’s only what it’s CALLED, you know!’

‘Well, what IS the song, then?’ said Alice, who was by this time completely bewildered.

‘I was coming to that,’ the Knight said. ‘The song really IS “A-SITTING ON A GATE”: and the tune’s my own invention.’

Wenn Sie dies verstanden haben, dann verstehen Sie auch die Zusammenhänge zwischen einer Variablen, die auf ein Objekt verweist, dem Namen dieser Variablen, dem Inhalt, der Objektreferenz, dem Objekt und der Objektidentität.

Und damit steht dem erfolgreichen Programmieren nichts mehr im Wege.

Mehr?

Haben Sie auch noch Vorschläge für Bücher und Filme? Dann bin ich gespannt.

From: pfpfp@web.de
Subject: Gesprächstermin
Hallo Herr Kreuz,
ich hätte gerne einen Gesprächstermin.
Gruß.

Tja, was sollte ich darauf antworten? Im Hochschulalltag geht manches drunter und drüber. Aber bei so einer E-Mail wird es dann doch schwierig.

Seit heute kann ich einen Link auf diesen Artikel zurücksenden ;-)

Persönliche Gespräche lassen sich durch nichts ersetzen. Um schnell und effektiv einen gemeinsamen Termin zu finden, sollte ein Gesprächswunsch etwas mehr als obige E-Mail enthalten:

1. Ihre Absendeadresse sollte gültig sein. Sonst ist eine Antwort schwierig. (Ja, auch das ist mir schon untergekommen)
2. Sie müssen Ihren Zu- bzw. Nachnamen eindeutig angeben. Ganz toll ist es, wenn ich erkennen kann, ob Sie ein weibliches oder ein männliches Wesen sind. So kann ich auch korrekt antworten. (Sind Sie “Frau Inka Frank”, wenn Sie mit “Gruß, Inka, Frank” unterschreiben, oder heißen Sie “Herr Frank Inka”?)
3. Sagen Sie bitte, worüber Sie mit mir sprechen wollen. Ich möchte mich auf das Gespräch mit Ihnen vorbereiten.
4. Vielleicht geben Sie auch Wunschtermine an. Alternativ sollten Sie als Studierender das Semester angeben, zu dem Sie die meisten Veranstaltungen besuchen. Dann kann ich einen Termin bestimmen.

Sie erhalten dann eine E-Mail von mir, in der ich einen Termin vorschlage. Sofern dieser auch Ihnen zusagt, bestätigen Sie ihn bitte per E-Mail. Warum? Lesen Sie einfach den Artikel über das sog. Drei-Wege-Handshake.

Wenn Sie diesen Termin nicht rechtzeitig bestätigen, sollten Sie sich nicht wundern, wenn ich zum vermeindlich vereinbarten Termin nicht anwesend bin. Erst mit Ihrer Bestätigung werte ich den Termin als vereinbart.

Beachten Sie bitte auch, wie schnell ich auf eine E-Mail antworte.

Danke! (Und das Leben wird für uns alles wieder ein Stückchen einfacher)

:-)

Sie soll zeigen, dass innerhalb einer vorgegebenen Frist ein Problem aus dem Fach selbstständig nach wissenschaftlichen Methoden bearbeitet werden kann. (§26 SPO HHN, Allgemeiner Teil)

Die Studien- und Prüfungsordnung gibt es vor: in der Abschlussarbeit, ob nun Diplomarbeit, Bachelorarbeit, Bachelorthesis, oder wie die Arbeit gerade benannt wird, muss der Studierende nachweisen, dass sie/er nach wissenschaftlichen Methoden arbeiten kann.

Doch was bedeutet dies konkret? Worauf hat der Studierende zu achten? Wie soll ich eine Arbeit als Gutachter bewerten?

Eine Bewertung aus dem Bauch heraus (“ich finde die Arbeit gar nicht einmal so schlecht”) ist nicht der Weg der Wahl. Spätestens nach dem dritten Gutachten skaliert das Bauchgefühl nicht mehr und man fängt an, Arbeiten miteinander zu vergleichen (“Die letzte Arbeit war eine 2, diese Arbeit ist nicht schlechter, also gibt es eine 2+”).

Jede Arbeit muss für sich isoliert bewertet werden.

Wenn Arbeiten nur noch in Relation zu anderen bewertet werden, besteht die Gefahr, dass sich die Bewertungen in eine bestimmte Richtung bewegen. Die Erinnerung an die letzte Bewertung trügt, und schon wird die vorliegende Arbeit anders bewertet. Im Endergebnis führt dies zu einer Schwemme von Einsen und Zweien. Wie kann da ein Durchschnitt von der Note Drei erreicht werden? Sind diese Einsen und Zweien dann noch etwas wert?

Deshalb habe ich angefangen, Bewertungskriterien auszuarbeiten. Ausgangspunkt war das Bewertungsschema für Seminar-, BA- und MA-Arbeiten von Joachim Grzega. Eine weitere wichtige Quelle war How science works: The flowchart. Nebenbei, eine nette Website für Studierende und Dozenten.

Herausgekommen ist die folgende Liste. Es mag auffallen, dass dort Inhalt und Umfang der Arbeit nicht explizit erwähnt werden. Das Arbeiten nach wissenschaftlichen Methoden steht nun einmal gemäß SPO im Vordergrund, nicht Inhalt und Umfang. Aber keine Sorge, inhaltslose und schmalspurige Arbeiten fallen auch bei diesen Kriterien auf.

1. Wurde ein einheitliches und übliches Layout verwendet?
2. Wird korrekt zitiert, sind Quellenangaben ausreichend und gibt es ein korrekt aufgebautes Literaturverzeichnis?
3. Stimmen Rechtschreibung, Zeichensetzung, Grammatik?
4. Ist die gesamte Arbeit, wie auch die einzelnen Kapitel, nach dem Muster Einleitung/Inhalt/Zusammenfassung aufgebaut (“Erst sagen, was man sagen möchte, dann sagen, was man zu sagen hat und zum Schluss sagen, was man gesagt hat”)? Ist die Zusammenfassung (“Management Summary”) wirklich eine Zusammenfassung und nicht z.B. eine thematische Einführung?
5. Wird die Frage/Hypothese in der Einleitung genannt? Ist sie fachlich relevant?
6. Wird das Themengebiet angemessen vorgestellt und gegenüber anderen Gebieten ausreichend abgegrenzt?
7. Erfolgen die einzelnen Schritte der Arbeit in einer logischen und dem Fach angemessenen Reihenfolge?
8. Ist der “Stand der Technik” ausreichend berücksichtigt und richtig eingeordnet worden?
9. Sind Begriffe klar definiert?
10. Sind Beobachtungen/Beschreibungen/Klassifikationen richtig und nachvollziehbar?
11. Sind Beobachtungen von Bewertungen deutlich getrennt?
12. Sind für Aussagen die jeweiligen Quellen oder eigene Erhebungen vollständig angegeben?
13. Ist die Qualität der Quellen ausreichend?
14. Sind Beurteilungen/Schlüsse nachvollziehbar?
15. Wurden Alternativen betrachtet (Produkte, Lösungswege, Szenarien, …)?
16. Ist eine deutliche Eigenleistung erkennbar?
17. Sind Aufbau und Präsentation der Arbeit der Publikationsform angemessen?
18. Zeichnet sich die Arbeit durch etwas Besonderes aus?
19. Gibt es einen Ausblick auf mögliche weitere Arbeiten?

Diese Punkte lassen sich kanonisch auf ein Notenschema abbilden: 0-2 = 5,0; 3-4 = 4,7; 5-6 = 4,0; 7-8 = 3,7; 9 = 3,3; 10-11 = 3,0; 12 = 2,7; 13-14 = 2,3; 15 = 2,0; 16 = 1,7; 17-18 = 1,3; 19 = 1,0.

Die andere Arbeit wurde offenbar von einem Buchbinder hergestellt. Festes Papier, Farbdruck, dicker Buchdeckel mit goldener Prägung und einem Bändsel als eingebautes Lesezeichen. Kosten ca. 50 Euro.

Was wollen mir beide Studenten damit (indirekt) sagen? Sagt mir Student #2, dass seine Arbeit besonders wertvoll ist? Was hält dann Student #1 von seiner Arbeit? Ich kann das nicht beurteilen.

Aber der relative Trend zu einer besonderen äußeren Form der Abschlussarbeit ist schon interessant. Ich kann nicht ausschließen, dass sich der eine oder andere Gutachter von der äußeren Form beeinflussen lässt. Aber kommt es darauf wirklich an?

Mir als Gutachter ist es wichtig, dass ich den Inhalt einer Arbeit beurteilen kann. Dazu muss ich diesen gut erfassen können. Ich möchte dort einfach mit einem Bleistift Randbemerkungen machen. Zig Seiten Quellcode schaue ich mir ohnehin lieber als Datei an. Oder, noch besser, live im Debugger.

Dafür brauche ich keine Goldprägung und 120g-Papier. Normales Papier reicht völlig. Ich kritzel dort sowieso herum. Ganz toll ist es auch, wenn der Seitenrand etwa 3-5 cm breit ist und der Zeilenabstand genügend Platz für Bemerkungen lässt.

Noch wichtiger ist natürlich ein Inhalt, der die Anforderungen an die Abschlussarbeit ausgezeichnet erfüllt. Angemessenes Thema, nachvollziehbares Vorgehen, Verwendung der wirklich relevanten Quellen, gute Strukturierung, ordentliche Querverweise und Quellenangaben. Das sind Punkte, die eine gute Abschlussarbeit auszeichnen.

Was das mit Schuluniformen zu tun hat? Soviel, wie Kleidung von Tommy Hilfiger oder von Kik mit den Qualitäten eines Schülers zu tun hat.

Aber ein eingebautes Lesezeichen ist trotzdem etwas feines.

Methoden mag es eine Million geben oder noch mehr, aber Prinzipien gibt es nur wenige. Wer Prinzipien begreift, kann mit Erfolg seine eigenen Methoden auswählen. Wer Methoden ausprobiert und Prinzipien ignoriert, wird ohne Zweifel Probleme bekommen. (Ralph Waldo Emerson)

Dies ist eine beliebte Frage in und vor der Prüfungszeit. Obiges Zitat beantwortet zu einem großen Teil diese Frage, ist aber für den einen oder die andere etwas abstrakt.

Erst einmal, die Hochschule sollte kein Ort mehr sein, an dem Informationen in großem Stil auswendig gelernt werden müssen. Vielleicht mag dies für den einen oder anderen Studiengang noch gelten, wie z.B. Jura. Aber letzten Endes sollen Sie an einer Hochschule lernen, wie man (wissenschaftlich) denkt und wie Sie Ihr Wissen selbständig und nachhaltig erweitern. Sie müssen eine gewisse Intuition für Ihr Arbeitsgebiet entwickeln, wollen Sie später erfolgreich sein. Das geht nicht über reines Auswendiglernen.

Beachten Sie auch die Halbwertszeit von Wissen, besonders in der Informatik. Nach ca. 2 Jahren ist die Hälfte Ihres Produktwissens nichts mehr wert. Sprich, alles was Sie heute auswendig lernen, ist nach Ende Ihres Studiums weniger als die Hälfte wert. Übrigens, Konzeptwissen hat in der Informatik eine Halbwertszeit von ca. 10 Jahren.

Doch zurück zur Ausgangsfrage: was kommt in der Klausur dran?

Diese Frage zielt in mehrere Richtungen.

1. Welchen Inhalt frage ich ab? Da ist die Antwort einfach: alles, was in den Präsenzveranstaltungen, Vorlesungen, Übungen, … vorgestellt bzw. besprochen wurde. Es gibt keinen spezifischen Schwerpunkt, für den Sie sich besonders vorbereiten müssen.
2. Wie vergebe ich Punkte? Auch da mag ich es einfach: für jede Aufgabe schätze ich, wie viele Minuten Sie für die Lösung/Antwort benötigen würden. Genauso viele Punkte gibt es. Sprich, bei einer Klausur über 120 Minuten gibt es maximal 120 Punkte. Ihre Lösung/Antwort für eine bestimmte Aufgabe bewerte ich mit einer Genauigkeit von 0,5 Punkten. Bei mir gibt es keine Viertel-, Achtel- oder Zehntelpunkte. Da bin ich dann doch auch Ingenieur: “Wer viel misst, misst Mist”. Multiple-Choice-Fragen gibt es auch nicht. Diese dienen im Wesentlichen dazu, den Korrekturaufwand zu minimieren. Von ihrer Legitimität, je nach Prüfungsordnung, ganz zu schweigen.
3. Wie bewerte ich Ihre Antworten? Ich habe zwar Musterlösungen, aber ich prüfe Ihre Antworten immer dahingehend, ob diese zur Aufgabenstellung passen. In dubio pro reo. Die deutsche Sprache ist nämlich so schön mehrdeutig und ich möchte nicht ausschließen, dass ich mich bei einer Aufgabenstellung sprachlich vergaloppiere. Errare humanum est.
4. Welche Note können Sie im Durchschnitt erwarten? Auch einfach, eine 3,0. Das ist die Definition der Note 3,0: durchschnittlich. Genauer: bei einer Gruppe von durchschnittlich befähigten “Prüflingen” ist die Durchschnittsnote eine 3,0. Aber Sie wollen doch besser sein, als der Durchschnitt, oder?
5. Was für Arten von Fragen stelle ich? Das ist jetzt nicht ganz so einfach zu beschreiben.
   Zunächst einmal nehme ich für mich nicht in Anspruch, dass die von mir geprüften Fächer die allein glückselig machenden Fächer sind. Einige von ihnen möchten sich in diesen Fächern weiter spezialisieren. Andere wollen die Klausur nur bestehen, weil sie andere Schwerpunkte setzen. Die letzteren möchte ich nicht zu ihrem Glück zwingen.
   Für das Bestehen einer Klausur ist eine 4,0 nötig, d.h. Sie müssen die Hälfte der maximalen Punkte erreichen. Zum Beispiel also in einer Klausur über 120 Minuten müssen Sie 60 Punkte schaffen. Die können Sie erreichen, wenn Sie die Inhalte der Folienkopien, Übungen, Zwischentests und meiner mündlichen Anmerkungen auswendig lernen (deshalb ist es eine gute Idee, in der Vorlesungszeit immer etwas zum Schreiben dabei zu haben). Aber etwas besseres als eine 4,0 gibt es dann auch nicht!
   Wenn Sie mehr als die Note 4,0 anstreben, müssen Sie Aufgaben bearbeiten, die ein gewisses inhaltliches Verständnis für das geprüfte Fach voraussetzen. Zum Beispiel müssen Sie in der Lage sein, aus einer Aufgabenstellung heraus einen Algorithmus zu entwerfen (“Programmierung 1 / 2″), Teile eines Projektplans zu verfassen (“Projektmanagement 1″), den Sinn oder Unsinn bestimmter Entwurfsmuster zu begründen (“Software Engineering”) oder Einsatzstrategien für Anwendungssysteme zu entwickeln (“E-Business Applications”). Dafür gibt es dann die andere Hälfte der zu erreichenden Punkte. Diese Aufgaben sind meistens nach Schweregrad für die zu erreichende Note gestaffelt.
   Sie streben mehr als eine Note 4,0 an, können aber nicht so gut auswendig lernen? Da haben Sie mein vollstes Mitgefühl! Mir ging und geht es genauso. Dafür gibt es die erlaubten Hilfsmittel, namentlich den Spickzettel.
   Ach ja, eine Frage wird es in so gut wie jeder Klausur geben: die “Sternchenfrage”. Das ist eine Frage, die auch fachlich unbelastete Personen beantworten können. Getestet in meinem direkten, persönlichen Umfeld ;-)

So, ich hoffe wir können in den Fragestunden diese formalen Dinge beiseite lassen und uns auf inhaltliche Fragen konzentrieren.

Im Übrigen bin ich sowieso für mündliche Prüfungen, bei Kaffee und Kuchen.

Zuerst auch dafür ein riesiges “Danke Schön!“. Ich weiß aus eigener Erfahrung, wie schwer es sein kann, jemanden Feedback zu geben, der einen per Note bewerten soll. Danke auch für den Vortrag, bei dem Sie Ihre Erfahrungen an das nachfolgende Semester weiter gegeben haben.

Aber nun zu den einzelnen Punkten. Ich hatte mir aufgeschrieben (meine Antwort in kursiv):

1. Die parallele Veranstaltung “Projektmanagement 2″ vorziehen.

Dort werden viele Aspekte angesprochen, die auch für die Projektstudie benötigt werden. Zum Beispiel, wie man am besten mit dem Werkzeug zur Versionskontrolle arbeitet, oder wie der “Issue Tracker” einem helfen kann. Welche Vorgehensmodelle gibt es und welches sollte man verwenden, …

Absolut ein guter Punkt. Im nächsten Semester werden wir “Projektmanagement 2″ vorziehen, indem wir die Präsenztermine der Projektstudie nutzen.

2. Externe Kunden.

Sobald eine (externe) Firma als Kunde auftritt, ist die Motivation wesentlich höher.

Ha!, reicht die Motivation mit der drohenden ungünstigen Note nicht? ;-) Nein, im Ernst, sehe ich auch so. Mit der einen oder anderen Firma bin ich schon in losen Gesprächen.

Falls hier jemand mitliest, der ein studentisches Projektteam sucht, bitte bei mir melden!

3. Direkt auf dem Lastenheft aufsetzen.

Nö, das Ermitteln der Anforderungen soll Teil der Projektstudie bleiben.

4. Mantis ist nicht nur ein Bug-Tracker

Mantis bezeichnet sich selbst als “Bug Tracker”. Erst später wurde während der Arbeit erkannt, dass es sehr gut als Planungs- und Kommunikationsinstrument für manchmal dann doch verteilte Projektarbeit verwendet werden kann.

Ja, wird Teil des vorgezogenen “Projektmanagement 2″ sein.

5. Einarbeitung in automatische Tests wäre zu aufwändig gewesen

Deshalb wurden Tests nur via JUnit automatisiert und Akzeptanztests manuell durchgeführt.

Erst einmal ist die Nutzung von JUnit ein erster guter Schritt. Und traurigerweise wird in der beruflichen Praxis häufig nicht mehr gemacht. Insofern war Ihr Vorgehen durchaus praxisnah. Aber im Zuge des vorgezogenen “Projektmanagement 2″ werden wir dies Thema eher und detaillierter angehen.

Gut, da ich drei Rollen hatte (Prof., Kunde, Leiter einer hypothetischen Entwicklungsabteilung) und da Sie zu Anfang nicht so recht wussten, wie ich ticke, ist Ihr Verhalten nachvollziehbar.

Aber einem Kunden gegenüber müssen Sie kommunizieren, besonders wenn Sie Ihr Vorgehensmodell als eine Mischung von UP und XP charakterisieren. Auch und gerade, wenn Sie nicht wissen, wie er tickt ;-)

Habe ich etwas vergessen, unterschlagen oder falsch dargestellt? Hier gibt es eine Kommentarfunktion oder senden Sie mir eine E-Mail.