Projektverlauf Praktikas

Praktikum 1

Das erste Praktikum war der Start in das BPaaS Projekt. Dort ist zum ersten Mal das Projektteam zusammengekommen. Recht schnell hat sich herausgestellt, dass die Teammitglieder aus der technischen Informatik in unserem Team überwiegen. Dies ist im Hinblick auf die Verwirklichung des Projektes bestimmt ein Vorteil, jedoch bedeutet dies dann auch eine starke Orientierung auf die technischen Themen.
Recht schnell ging es dann zur Diskussion über die Projektaufgabe "Entwicklung einer BPaaS-Plattform". Als Vorbereitung auf das Praktikum hatten wir uns das Aufgabenblatt von Frau Steffens durchgelesen und haben überlegt welche Komponenten wir brauchen, um alle User mit der Plattform zufriedenzustellen.
Edgar hatte sich zu den Komponenten schon im Vorfeld Gedanken gemacht und dieses zur Diskussion im Praktikum vorgestellt (siehe diesen Blogeintrag). Letztendlich waren seine Ideen schon sehr gut und wir sind auf eine ähnliche Architektur im Praktikum gekommen.
Im Laufe des Praktikums stellte sich heraus, dass die anderen Teammitglieder sich nicht viel unter Geschäftsprozessen vorstellen können und wie diese abgebildet werden mit BPMN2.0 oder eEPK. Also grob gesagt was die Plattform inhaltlich zu bieten hat. 
Daraufhin habe ich kurz ein Beispiel aus dem Internet gesucht und anhand dessen ein Business Process in BPMN2.0 Notation vorgestellt.
Ein Punkt war dann auch eine grobe Zuteilung von Personen zu den einzelnen Komponenten und Aufgaben. Siehe folgende Tabelle.

Komponenten	Ansprechpartner
Middleware & Infrastructure	Alex
Database	Lukas
Monitoring	Mikko
Schnittstellen	Sebastian
Frontend	Max
Logik/Controller	-
Beispiel Service/Process	Tasmin
Knüppel aka Projektleiter	Alex

Fazit: Nach dem Praktikum fühlte ich mich etwas gerädert, denn die ca. 3 Stunden durchweg konzentriert bei der Diskussion dabei zu sein war sehr anstrengend. Vor allem da die Diskussion sehr unkoordiniert war und alle etwas drucheinander geredet haben.

Praktikum 2

Schon kurz vor dem zweiten Praktikum wurde die Stimmung schlechter im Team, da es Leute gab die sich nicht wirklich beteiligt haben. Von denen hatte man quasi bis zu diesem Termin nicht wirklich viel gehört. So wurde unsere Professorin schon vor dem Termin benachrichtigt, dass man diese Leute mal auf den Boden der Tatsachen holen möchte.
Begonnen wurde das Praktikum damit, dass jeder erzählte was er getan hatte. Dort konnten sich die Personen erstaunlich gut verstecken, zu dem Ärger mancher Teammitglieder. Dies führte aber auch dazu, dass der Ärger runtergeschluckt wurde und nicht mehr zum Ausdruck kam.
Probleme die sich heraus kristallisiert haben war zum einen die Kommunikation die nicht richtig funktioniert. Da viele in ihrem stillen Kämmerlein an den Komponenten basteln und so wenig an die einzelnen Teammitglieder dringt. Das ist problematisch, wenn andere Komponenten von den Entscheidungen betroffen sind und diese bei der jeweiligen Umsetzung berücksichtigt werden müssen.
Außerdem wurde sich als Ziel gesetzt einen Prototyp schon zu diesem Termin zu haben, was aber nicht geklappt hatte, da es für den Controller keinen Ansprechpartner gab und der Arbeitsaufwand auch unterschätzt wurde.
Danach haben wir das Kommunizieren mal ausprobiert, in dem wir geklärt haben welche Ansprechpartner sich noch zusammen setzten müssen, weil jemand noch Input von jemand anderen braucht. In so einer Architektur gibt es ja Schnittstellen. Dies hat meiner Meinung nach auch gut funktioniert. In meiner Untergruppe haben wir uns über die Anforderungen der Spezifikation zu Business Processen unterhalten und diese Ergebnisse waren hilfreich für den Aufbau. Im Nachhinein hat sich dann herausgestellt, dass es nicht so gut war das Hannes als Ansprechpartner für BP Executer nicht dabeisaß. Da dann nicht ganz klar war wie BPs und BP Services aufgeteilt sind.

Fazit: Das Praktikum hat geholfen ein paar Probleme in der Teamarbeit aufzuzeigen und weil alle dort waren, konnte man endlich auch über gewisse wichtige Entscheidung zu den Komponenten reden. Leider ist es sonst schwierig alle auf einem Haufen zu erwischen.

Praktikum 3

Im dritten Praktikumstermin haben wir eine Scrum Retrospektive gemacht, die von unserer Professorin und dem Praktikumsbetreuer moderiert wurde.
Ziel war es dabei den Ist-Zustand unser Arbeit als Team abzubilden und daraus dann Verbesserungsmöglichkeiten abzuleiten.

Hier in dem Bild könnt ihr sehen was wir gemacht haben.
Unser Betreuer hat uns im ersten Abschnitt verschiedene Fragen gestellt und jeder musste seine Gedanken auf einen Zettel schreiben und kurz vorstellen.
Die Frage zum Einstieg war: 

• Wann warst Du das letzte Mal produktiv? 
• Was hast Du getan?
• Was war passiert.

Dabei hatte sich herausgestellt, dass einige noch in der Vorlesung zuvor am Projekt gearbeitet haben oder in der Nacht vorher. Beides finde ich etwas merkwürdig, aber jeder hat eine andere Arbeitsweise.

Mir hat die Retrospektive sehr gut gefallen, da sie meiner Meinung nach sehr hilfreich war und unserem Team gezeigt hat, wo noch Verbesserungsmöglichkeiten bestehen.
Außerdem war es schön in einen Praktikumstermin zu gehen und zu wissen, dass es nicht wieder so viele anstrengende Diskussionen geben wird und es ein strukturiertes Praktikum mit Plan wird.

• Was, von dem was Du entwickelt hast, hatte den meisten Wert? Warum?  

Hier hat sich herausgestellt, dass manche noch nichts entwickelt haben, bzw. sich nicht wirklich beteiligt haben an der Entwicklung. Dies war unserem Team aber bekannt, weil man sich untereinander ja nicht verstecken kann.

Toll war aber, dass die meisten hier etwas antworten konnten, auf das sie auch stolz sind.

• Aus technischer Sicht. Was ist die großartigste Sache, die Ihr entwickelt habt?
• Was daran ist so besonders?

Hier wurde die Business Process Logik genannt, denn der BPExcuter und die BPInstance wurden eigens entwickelt, um BPs in der Cloud Umgebung zum Laufen zu bringen.

• Wann war deine Zusammenarbeit mit dem Team am besten?

Hier hat sich gezeigt, dass es sich gelohnt hat an den Dienstagstermin an denen die Vorlesung ausfiel ein großes Meeting zu veranstalten. Dort konnten die Teams sich untereinander austauschen und auch direkt gemeinsam programmieren. Toll war das daran alle bis auf ein Teammitglied teilgenommen haben.

• Wann hast Du am besten mit dem Projektleiter zusammengearbeitet?
• Was war gut daran?

Welcher Projektleiter? Ja wir hatten diese Rolle eingeplant, die auch offiziell besetzt war. Aber die Rolle wurde nie wirklich ausgeführt. Geht auch schlecht, wenn der Projektleiter an den Meetings fast nie teilnimmt und wenig mit den anderen Gruppenmitgliedern kommuniziert.

• Was war der wertvollste Beitrag für das Projekt (nicht nur technisch)?

Die Antworten waren sehr ähnlich zur größten Sache, die wir entwickelt haben. Dies liegt daran, dass wir unseren Teamerfolg an unserer technischen Entwicklung messen.

• Welche Deiner Fähigkeiten/Eigenschaften sind am wertvollsten? Beispiele?

Hier war mir wichtig zu betonen, dass ich neutral eingestellt bin. Ich kannte schließlich keinen als wir mit dem Projekt begonnen haben. Natürlich hat man auch in der Zeit die Mitglieder besser kennen gelernt und kann so die Mitglieder selber einschätzen.

Jedoch bringt es nichts immer Voreingenommen zu sein und manchmal braucht das Team bei zwischenmenschlichen Problemen einen Vermittler (dies wurde aber nicht in Anspruch genommen).

Leider hatten wir zwei Teammitglieder, die schon mal in einem vorherigen Projekt eine Auseinandersetzung hatten, was dazu führte dass Einer das Projekt verlassen hatte.

Deshalb bin ich froh, dass sie sich auf ihre eigene Art und Weise einigermaßen zusammengerissen haben.

Für beide war das wohl ein gutes Training für reale Teamarbeit im Job, denn nicht immer kommt man mit allen Teammitgliedern gut aus. Man sollte aber immer professionell handeln und miteinander arbeiten, auch wenn es schwerfällt. Zumindest dies im Hinterkopf zu behalten

• Was ist die wichtigste Eigenschaft des Teams?

Hier wurde unsere Produktivität betont, da die Entwicklung gut voran lief.

Im nächsten Teil der Retro ging es darum, was wir beginnen möchten zu tun (start), was wir weiter so machen möchten (continue) und was wir nicht mehr machen möchten (stop). Dazu hatte jeder einige Zeit seine Gedanken und Wünsche aufzuschreiben.

Letztendlich ist Einiges zusammengekommen und darüber wurde diskutiert. Dann sollten wir Vorschläge zu den einzelnen Punkten machen, wie man dieses Umsetzen kann und letztendlich durften wir ein paar grüne Punkte auf dem Board verteilen, was wir als wichtig empfinden.

Hier hat sich gezeigt, dass wir uns eine bessere Doku der Bausteine wünschen. Wir wollen strukturiert nach realistischen Projektzielen arbeiten und dabei die Arbeit gleichmäßig auf die Teammitglieder aufteilen. Außerdem wünschen wir uns einen Termin an dem alle Mitglieder können. Behalten wollen wir die Produktivität der Teamarbeit und den Spaß im Team.

Daraufhin haben wir überlegt auf welchen Termin wir unser wöchentliches Teammeeting verschieben, aber leider gab es keinen besseren Termin als den bisherigen am Dienstag vor der Vorlesung.

Außerdem wurde beschlossen, dass zu jeder Komponente ein Readme nach festgelegten Kriterien erstellt wird und ein Issue Template soll entwickelt werden für sauber definierte Aufgaben.

Das Einführen eines neuen Projektleiters wurde von den meisten auf Grund der kurzen Zeit bis Projektende abgelehnt. Das anarche Team sollte also beibehalten werden. Stattdessen wurde Edgar als Aufgabenkoordinator ernannt, damit er anfallende Aufgaben an die weniger ausgelasteten Teammitglieder weitergeben kann. Dies soll die Arbeitsverteilung etwas verbessern.

Eine lustige Aufgabe war aus der Sicht unserer Professorin unsere eigene Arbeit zu bewerten und uns zu überlegen was sie denkt was wir noch mehr tun sollten.

Bei mir habe ich meine Arbeitsleistung als ok eingeschätzt. Ich war keiner der Leistungsträger des Projektes, aber auch nicht jemand der sich gar nicht integriert hat. Meine Aufgaben habe ich immer erledigt und auch immer wieder gefragt was ich noch tun kann.

Was unsere Professorin von mir erwartet hätte, ist meiner Meinung nach noch mehr meinen Wirtschaftsinformatik Hintergrund in das Projekt einzubringen, denn unser Projekt hat eine Stark technische Fokussierung. Als Beispiel nannte ich das wir ja nur sequentielle BPs auf unserer Plattform ausführen können, es aber z.B. noch Gateways gibt.

Fazit: Wie man nun vielleicht merkt hat mir das Praktikum 3 besonders gut gefallen und wir haben einige Anstöße für die letzte Projektphase mitgenommen. Nicht nur die Probleme wurden aufgezeigt, sondern auch konkrete Ansätze entwickelt, um die Probleme anzugehen.

Praktikum 4

Im letzten Praktikumstermin haben wir unseren Betreuern unsere BPaaS-Plattform vorgestellt. Wir haben gezeigt, wie man einen BP und Services in der Plattform anlegt. Außerdem wie ein Beispiel BP auf unserer Plattform läuft.
Danach war das Praktikum offiziell beendet und wir haben die restliche Zeit genutzt, um den Abschlussvortrag zum Projekt vorzubereiten.
Unser Hauptanliegen war die einzelnen Komponenten vorzustellen und eine Live-Demo unserer BPaaS zu präsentieren. Jedes Teammitglied sollte die Möglichkeit haben über seinen Beitrag zum Projekt zu reden und sich so als Team zu präsentieren.
Ganz wichtig war für uns den Zeitplan von einer halben Stunde einzuhalten und deshalb haben wir für jedes Thema eine Idealdauer festgesetzte, um dies zu erreichen. Mikko soll den zeitlichen Verlauf während des Vortrags dann kontrollieren und zur Not den Vortragenden auf eine Zeitüberschreitung aufmerksam zu machen.
Max hat sich dann der Aufgabe angenommen alle Folien entgegen zu nehmen und diese in ein einheitliches Design als Präsentationsfolien zu bringen.

Fazit: Es war schön in dem Termin zu kommen und unsere Plattform funktionsfähig vorstellen zu können und dann noch Zeit zu haben die Abschlusspräsentation vorzubereiten. Das Endergbnis der Plattform lässt sich wirklich sehen und wir haben viel geschafft und gelernt in dem Projekt.