Paula und Tommy über das Probestudium MINTLOOK

Paula und Tommy sind ab nächster Woche erfolgreiche Absolventen des MINTLOOK-Probestudiums der TH Brandenburg. Sie waren nun 3 Monate bei uns und haben „auf Probe studiert“ und Erfahrungen für ihr zukünftiges Studium gesammelt. Im Fokus standen dabei Vorlesungsbesuche, die Projektarbeit an einem realen Unternehmensthema und das Reinschnuppern in den Arbeitsalltag. Doch lassen wir sie selbst berichten.

Hallo ihr beiden, wie seid ihr denn überhaupt zum MINTLOOK-Projekt gekommen?

Paula: Nach dem Abitur 2018 hatte ich noch keine Vorstellung, was ich überhaupt danach machen möchte. Die technische Hochschule Brandenburg bot zu der Zeit das MINTLOOK Studium an, um Orientierung zu bieten. So bekommt man einen ersten Überblick ins aktive Studentenleben und kann schon erste Erfahrungen sammeln. Ich wollte mich nirgends einschreiben und nach kurzer Zeit feststellen, dass der Studiengang nichts für mich ist. Dadurch nahm ich das Angebot der Technischen Hochschule Brandenburg war und bewarb mich.

Tommy: Ich bin durch eine Informationsveranstaltung im Rahmen des “Studium- und Berufetags” meiner Schule auf das Probestudium der Technischen Hochschule Brandenburg an der Havel aufmerksam geworden. Da ich bis zu diesem Zeitpunkt unentschlossen war, was ich nach dem Abitur machen möchte, hat sich das MINTlook Projekt besonders angeboten. Es ist uns möglich in die zahlreichen Studiengänge und deren Vorlesungen reinzuschnuppern und einen Einblick in das Studentenleben zu bekommen. Besonders das Angebot, zusätzlich noch Praktika absolvieren zu können und damit Praxiserfahrungen zu sammeln, war ein ausschlaggebener Punkt mich für das Projekt zu entscheiden.

Was sind eure Aufgaben im CIC? Wie läuft das Praktikum im CIC ab?

Paula: Meine Aufgabe stand früh fest: Tommy und ich bekamen die Möglichkeit unsere erste kleine WebApp zu entwickeln. Nach einer ersten Ideensuche ging‘s dann auch gleich los.
Zuerst mussten wir unsere bisherigen Kenntnisse weiter ausbauen, um überhaupt unser Projekt starten zu können. In den ersten Wochen lernten wir  durch Tutorials, Übungen und eigenes Ausprobieren ein Verständis dafür zu entwickeln, wie eine Website aufgebaut ist und wie man sie nach Belieben gestalten kann.
Nachdem wir uns mit HTML, CSS und JavaScript näher vertraut gemacht haben, ging es los unsere erste HTML zu erstellen. Wir haben uns hier schnell eingewöhnt und unser Alltag  wurde durch Projekthopping und Meetings aufgelockert.

Tommy: Ich arbeite zusammen mit Paula, einer weiteren MINTlook-Studentin, mithilfe unserer Coaches an einer Web App namens MAP-deburg. Diese Web App soll es einem einfach machen, Aktivitäten in Magdeburg zu finden ohne viel suchen zu müssen. Dabei werden mehrere Filter einbezogen, wie z.B. Temperatur, um die optimalen Aktivitäten für Unternehmungen zu finden. Da der ganze technische Part für uns größtenteils neu ist, haben wir uns in den ersten Wochen durch Tutorials zu den einzelnen relevanten Programmiersprachen viel Wissen angeeignet, was uns später die Arbeit erleichtert hat. Zusätzlich dazu konnten wir gelegentlich einen Einblick in verschiedene Projekte bekommen und dadurch sehen wie andere Projekte ablaufen, welche Tools benutzt werden und wie ein Alltag bei den Kollegen aussieht. Außerdem konnten wir bei einer Softskillschulung zum Thema “effektiv kommunizieren” dabei sein und dort auch nochmal unsere Fähigkeiten testen.

Was gefällt euch besonders gut im CIC?

Paula: Ich habe mich hier im Center ab der ersten Woche wohlgefühlt. Für mich waren es viele neue Einblicke und durch ein super Team fühlte ich mich gut aufgehoben bei all den neuen Eindrücken. 😊
Es ist schön in einer so entspannten Arbeitsatmosphäre zu arbeiten und jeder Kollege hat ein offenes Ohr oder hilft bei Problemen. Es ist beeindruckend an wie vielen Projekten das CIC arbeitet und es war schön einen Einblick zu bekommen. Besonders hat mir die ausführliche Einführung in die verschiedenen Projekte gefallen.

Tommy: Ich habe mich einfach schon in den ersten Stunden wohlgefühlt, da man zum einen schon toll empfangen wurde und dann der Umgang miteinander auch sehr locker und entspannt war. Ich denke gerade dieser familiäre Umgang miteinander macht das CIC so attraktiv. Weiterhin gefällt mir sehr die Arbeitsweise, dass beispielsweise alle Projekte in Teams bearbeitet werden. Ich habe zudem auch jederzeit die Möglichkeit meine Coaches um Hilfe zu bitten und sie haben immer ein offenes Ohr für Probleme und Fragen.

Gibt es Punkte, die ihr euch anders vorgestellt haben?

Paula: Mein Ziel war es einen Einblick in die Informatik zu bekommen und für mich herauszufinden, wie mein Weg dannach weiter gehen kann. Das Praktikum hat meine Erwartungen sogar übertroffen, da ich in dem Projekt meine eigenen Ideen kreativ umsetzen durfte.
Ich bin mit  Erwartungen in das Praktikum gegangen. Alle Erwartungen wurden vollstens erfüllt. Ich bekam die Möglichkeit mit einem tollen Team zusammen zu arbeiten und konnte durch das Projekt eigene Ideen kreativ unsetzten.

Tommy: Ich habe anfangs erwartet, dass wir an unserem eigenen Projekt arbeiten würden. Dabei habe ich gehofft ich würde einen tieferen Einblick in den Informatikbereich bekommen und erfolgreich eine eigene App entwickeln. Diese Erwartungen haben sich vollkommen erfüllt und ich konnte vorallem viel lernen und habe sehr viel Spaß eine eigene App zu entwickeln. Durch die gesamte Planung und die einzelnen Arbeitsschritte, konnten wir erfahren, wie solch ein Projekt abläuft. Zusätzlich wurden mit dem Projekthopping meine Erwartungen getoppt und ich habe dort auch weitere Projekte kennenlernen dürfen.

Was nehmt ihr generell aus der Erfahrung im CIC mit?                                                                            

Paula: In meinem Praktikum habe ich Kenntnisse in HTML, Java und CSS sammeln können, sodass ich jetzt nicht nur in der Theorie fit bin, sondern auch in der praktischen Anwendung. Dadurch fühle ich mich sehr gut auf mein kommendes Studium vorbereitet.

Tommy: Es macht sehr viel Spaß eine eigene App zu entwickeln, besonders das Design hat mir am meisten Spaß gemacht. Außerdem bringt Teamarbeit mehr als allein ein Projekt zu bearbeiten, da man vielseitiger arbeiten, sich gegenseitig helfen kann und mehr Ideen eingebracht werden können.

Haben euch die Erfahrungen im CIC bei der Berufs-/Studienwahlentscheidung helfen können?

Paula: Das Praktikum beim CIC hat mir sehr viel gebracht. Ich war sehr unentschlossen was ich nach dem Abitur machen möchte bzw. welcher Studiengang zu mir passt. Durch die Erfahrung hier habe ich mich dazu entschieden, im Oktober 2019, an der Technischen Hochschule Brandenburg Informatik zu studieren.

Tommy: Auf jeden Fall! Ich war bis zum Praktikum im CIC noch unsicher was ich ab Oktober studieren möchte. Ich habe mich im Laufe des Praktikums dann aber für ein Informatikstudium entschieden. Dabei würde ich mich gern in die Richtung der Medieninformatik orientieren und mich, insofern es möglich ist, auf den Designbereich fokussieren.

Werbeanzeigen

Cloud Native-Bootcamp


Vom 27. – 29. März 2019 fand das erste Bootcamp zum Thema Cloud Native bei uns in Magdeburg statt. Was der Inhalt dieses Bootcamps war und was Container, Orchestrierung und Microservices sind, erklärt uns heute Christian.

Im vollbesetzten Schulungsraum haben wir uns mit 20 Lernenden und 2 Trainern intensiv mit Entwicklungstechniken, Teamkultur und verschiedenen Cloud-Anbietern beschäftigt.

Was heißt eigentlich Cloud Native? Ich kann mir einen IBM Cloud Account besorgen, dort meine Applikation laufen lassen und fertig bin ich? Nein, denn: Cloud Native betrifft jeden Aspekt der Entwicklung, von Architektur/Design über Implementation, Deployment und Operation. Generell zeichnet sich Cloud Native durch 3 Kernpunkte aus:

  1. Containerisierung: Jeder Teil (Applikation, Prozesse, usw) läuft in einem eigenen Container. Dies erlaubt Reproduzierbarkeit, Transparenz und die Isolation von Resourcen
  2. Dynamische Orchestrierung: Container werden aktiv geplant und gemanaged, um Resourcenauslastung zu optimieren
  3. Microservices: Applikationen werden in Microservices aufgeteilt. Dies erhöht Agilität und Wartbarkeit drastisch.

Eine Microservice-Architektur erlaubt kleinen Teams mit wenigen Entwicklern, sich auf genau einen Business Need einer Gesamtapplikation zu konzentrieren. Hierbei sind sie unabhängig von anderen Teilen des Gesamtprojekts z.B in der Wahl der Programmiersprache oder der Datenbank, beides kann optimal zur Umsetzung des Services gewählt werden. Abhängigkeiten zu anderen Teilen der Applikation bestehen nur über definierte Schnittstellen, wodurch eine lose Kopplung entsteht. Jeder Microservice kann individuell gebaut, deployed, versioniert, released und gemanaged (scaling, load balancing, usw) werden.

Wie ein Microservice in einer Gesamtapplikation agiert, konnten wir dann am eigenen Leib erfahren: Im Microservice Game schlüpfte jeder Teilnehmer in die Rolle eines Microservices aus einem Online Shop. Zum „Start“ der Applikation meldet sich jeder Service bei einem Discovery Service an, damit die anderen Services dort seine IP (seinen Namen) herausfinden können. Zur Fehlertoleranz gibt es natürlich mehrere, die sich nach dem Systemstart synchronisieren müssen. Auf die Anfrage „User xxx möchte seinen Warenkorb auschecken“ folgte großes durcheinanderlaufen: „Hallo DiscoveryService, ich bin ein CheckoutService, wo finde ich den ShoppingCartService, PricingService und ShippingService?“. In diesem Spiel wurde klar, auf was ein Entwickler bei der Umsetzung eines Services achten muss: Kommuniziere ich synchron oder asynchron? Kann ich Multitasken? Wie reagiere ich, wenn ein Service nicht mehr antworten kann? Kann ich vorherige Anfrageergebnisse cachen?

Um den Entwicklungsprozess so schlank und fokussiert wie möglich zu halten, werden zwei Techniken eingesetzt: Xtreme Programming (XP) und Test-Driven Development (TDD). XP ist noch schlanker als das bekannte SCRUM: Iterationen des Produkts dauern nur eine Woche und werden kontinuierlich aus dem Backlog gepullt. Ein Team besteht hier am besten immer aus Paaren (außer dem PO), und Aufgaben werden grundsätzlich zu zweit bearbeitet. Die Entwickler schreiben Code immer zu zweit, sodass während der Entwicklung gleichzeitig ein Code-Review und steter Wissenstransfer stattfindet. TDD bedeutet: Für neuen Code wird zuerst ein Test geschrieben, und dann der minimale Code, der den Test erfüllt. Dies hat gleich mehrere Vorteile: Gut getesteter Code hat weniger Bugs (reduziert Folgekosten), es gibt Sicherheit bei weiteren Änderungen nichts kaputt zu machen und gut geschriebene Tests dienen auch als Dokumentation der Funktionsweise einer Klasse. Wichtig ist, dass Tests automatisiert nach jedem Build laufen. Hierfür sollte in jedem Fall eine Continuous Integration/Continuous Delivery (CI/CD) Pipeline existieren, die Code Changes erkennt, einen Build startet, testet und das Produkt deployed. Einen eindrucksvollen Einblick in eine gesamte Unternehmenskultur, die auf die Entwicklung von Microservices ausgelegt ist, bietet Spotify in diesem Video.

Wie angesprochen wird ein Microservice einer Cloud Native App in einem Container deployed. Der de-facto Standard hierfür ist Docker. Eine Containerengine erlaubt es, jedweden Inhalt in einen portierbaren, autarken Container zu kapseln, der über Standardoperationen konfiguiert und konsistent auf jeder Hardwareplattform laufen kann. Container Images sind sehr einfach zu handhaben (create, delete, start, stop) und da sie den OS Kernel (in separierten Prozessen) teilen, sind sie kleiner und „leichter“ als virtuelle Maschinen. Außerdem ist ein Container gleichzeitig eine unveränderliche Einheit und damit auch eine Version einer App oder eines Services.

Wenn nun eine Applikation aus mehreren Microservices besteht, die jeweils in einem Container verpackt sind, muss sich noch um die Orchestration der gesamten Applikation gekümmert werden. Container Orchestration meint die Verwaltung und Ausführung aller Aufgaben rund um den Lifecycle eines Containers, beginnend bei Deployment, Cluster Management, Scheduling, Service Discovery, Replication und Health Management. In der IBM Cloud wird dafür Kubernetes genutzt. Kubernetes ist 100% Open Source, bietet eine einheitliche API zum Deployen von WebApps, Batch Jobs und Datenbanken und bietet ein riesiges Ecosystem an Plugins für jeden Bedarf. Ein Kubernetes-Cluster besteht aus einem Master Node und mehreren Worker Nodes. Einzelne Container laufen auf den Worker Nodes in sog. Pods, während der Master Node den API Zugang zur Kontrolle des Clusters bietet. Zur Installation eines Kubernetes-Clusters wird Helm genutzt. Helm ist ein Package Manager für Kubernetes wie z.B. pip für Python oder Homebrew für Mac. Leider konnten wir hier auf Grund der kurzen Zeit nicht näher drauf eingehen.

Neben den vielen Hand-On Sessions haben wir viele Service-Angebote nicht nur der IBM Cloud, sondern auch von AWS und Azure erhalten. An dieser Stelle möchte ich nochmal den beiden Instruktoren Roman Strachowski und Grigorij Kaplan für das lohnende und lehrreiche Bootcamp danken.

Headerbild-Referenz: https://www.ibm.com/cloud-computing/learn-more/get-started-garage-method/

Informatikstudent auf Probe

Wir haben eine weitere Runde MINTlook eingeläutet und dürfen wieder einen sehr netten Probestudenten bei uns im Unternehmen begrüßen. Carl besucht uns nun regelmäßig, um vor Ort an seinem Projekt zu arbeiten und sich in Teamarbeit zu üben. Heute stellt er sich einmal persönlich vor.

Wie bin ich zum MINTlook Projekt gekommen?

Ich wurde durch eine Informationsveranstaltung an meiner Schule im Zuge des „Studium- und Berufetags“ auf das MINTlook Probestudium der Technischen Hochschule Brandenburg aufmerksam.
Die Möglichkeit, sich einen sehr guten Überblick über die möglichen Studiengänge zu verschaffen, das Studentenleben live mitzuerleben und dazu erste Praxiserfahrungen in verschiedenen Betrieben sammeln zu können, war letztendlich ausschlaggebend für meine Entscheidung, mich für das Probestudium zu bewerben.

Was sind meine Aufgaben im CIC? Wie läuft mein Praktikum im CIC ab?

Meine Aufgabe im Center stand früh fest: Ich soll bei der Entwicklung einer Intranet-Seite für das CIC mitwirken.
Um in das Projekt richtig einsteigen zu können, musste ich daher meine bisherigen Kenntnisse weiter ausbauen. Die ersten Wochen verbrachte ich also damit, durch Tutorials, Übungen und eigenes Ausprobieren ein Verständis dafür zu entwickeln, wie eine Website aufgebaut ist und wie ich sie nach meinem Belieben gestalte.
Sobald HTML, CSS und Javascript keine Unbekannten mehr für mich darstellten, ging es an die Arbeit im Projekt.
Was sich bald zum Alltag entwickelte, wurde regelmäßig durch andere Termine aufgelockert. Ich erhielt Einblicke in verschiedene andere Projekte des CIC, lernte die verschiedenen Arbeitsbereiche kennen und konnte an einer Softskillschulung zur effektiven Kommunikation teilnehmen.
Neben unserer Projektarbeit durften wir in verschiedene Bereiche des Centers reinschnuppern und unsere eigenen Fähigkeiten, unter anderem in einer SoftSkill-Schulung, auf die Probe stellen.

Was gefällt mir besonders gut am CIC?

Ich habe mich hier direkt in der ersten Woche nach Beginn des Praktikums wohlgefühlt, was vor allem an der sehr angenehmen, lockeren Atmosphäre und dem Umgang miteinander liegt. Dazu haben natürlich auch die Events, an denen ich teilnehmen durfte, beigetragen, wie die Weihnachtsfeier oder auch das Weihnachtsbasteln, wo ich spontan eingesprungen bin. Ich habe Ansprechpartner für jegliche Art von Problemen, und auch jeder Kollege hat ein offenes Ohr für Fragen.

Gibt es Punkte, die ich mir anders vorgestellt habe?

Als ich noch vor Beginn des Praktikums gefragt wurde, welche Erwartungen ich habe, antwortete ich in etwa folgendermaßen: „Ich möchte mehr über die Entwicklung von Software erfahren und diesen Prozess kennenlernen.“
Ich wollte einen Einblick in den IT-Bereich bekommen und am liebsten an einem Projekt aktiv mitarbeiten, und genau das wurde mir ermöglicht. Meine Erwartungen wurden mindestens erfüllt, denn ich durfte mit einem tollen Team zusammenarbeiten und Fortschritte machen. Ich konnte meine eigene Gedanken und Ideen umsetzen, kreativ sein.

Was nehme ich generell als Erfahrung mit?

Das Entwickeln macht mir Spaß, ebenso das Arbeiten im Team an einem Projekt. Diese Teamarbeit ist weitaus komplexer und strukturierter als die mir bisher bekannte Gruppenarbeit in der Schule.

Helfen mir die Erfahrungen, die ich im CIC gemacht habe, schon bei der Berufs- bzw. Studienwahlentscheidung?

Das Praktikum beim CIC hat mich darin bestätigt, meinem Interesse an der Informatik weiterhin Bedeutung zu schenken – ich spiele mit dem Gedanken, nach dem Probestudium ein Informatikstudium zu beginnen und mich, wenn möglich, auf Software-Entwicklung zu fokussieren.

Scrum in der Praxis: Teil 4, a day in the life …Scrum Developer

Unser Tech Talk geht weiter, mit unserer Reihe Scrum in der Praxis. Heute beschreibt Steffi ihren typischen Alltag als Scrum Developer. Nachdem sie im ersten Beitrag zum Thema den Sprintanfang näher beleuchtet hat, entführt sie uns heute in die typischen  Abläufe eines Sprints und erklärt, wo es manchmal Abweichungen geben kann.

ibm-client-innovation-center-scrum-stefanie

Als Softwareentwicklerin in einem Team, das nach SCRUM-Vorgehensmodell arbeitet, ist eine große Kennzahl für mich in unserem Team eine Zehn. Das steht für die zehn Arbeitstage pro Sprint. So lang ist nämlich unser Entwicklungszyklus – immer zwei Wochen, also meist zehn Arbeitstage. Es beginnt mit der Sprintplanung bzw. dem Sprintwechsel und endet mit einer Review vor dem Kunden. Aber das reguläre Ereignis, zu dem wir uns fix jeden Tag treffen, ist das „Daily“. Wir Devs und Scrum Master sitzen zwar alle in einem Raum, aber nicht alle unsere Tester und auch nicht unser PO (Product Owner). Um uns einmal am Tag zu synchronisieren, gibt es das Daily.

In unserem Fall findet es vormittags statt und als Faustregel gilt, dass jeder reihum sagt, was er bisher getan hat, was er gerade tut und was er tun wird. Wer jetzt stöhnt und sagt „jeden Tag mindestens ein Meeting klingt nach Zeitfressern und gar nicht so agil“, den kann ich beruhigen: Es dauert nicht länger als 15 Minuten. Und es ist ein wichtiger Termin. Er gibt uns die Gelegenheit Fragen an den PO zu richten, wenn ein Akzeptanzkriterium nicht mehr so klar ist oder eine Vorgabe fehlt. Und, wenn ein Kollege nicht weiterkommt und Hilfe braucht, ist das spätestens der Moment, in dem man sagen kann „Wer hat Zeit sich das mit mir kurz anzuschauen?“

Abgesehen vom Daily gibt es wenige Sprint-Ereignisse oder –Meetings, die uns vom „arbeiten abhalten“ könnten. Regelmäßig ein Mal im Sprint werden User Storys geschätzt, ansonsten soll der Aufwand gering gehalten werden. Scrum geht davon aus, dass der Entwickler auch wirklich entwickeln darf. Es ist die Aufgabe des Scrum Masters andere Aufwände vom Team abzuhalten. So beispielsweise, wenn es etwas zu diskutieren gibt, wobei der beste Ansprechpartner noch nicht klar ist. Der Scrum Master schirmt das Team quasi vor nicht planmäßigen Aufwänden ab und dient als Sprachrohr nach außen, wenn beispielsweise Hilfe benötigt wird. Natürlich arbeiten die Entwickler aber nicht vollkommen isoliert. Sobald es etwas zu besprechen gibt, sollte jeder Entwickler zum Telefon greifen, zum Kollegen rübergehen oder dem Scrum Master und PO Bescheid geben, dass es einen Blocker gibt.

ibm-client-innovation-center-scrum-in-der-praxis-teil-4

Zwei Ereignisse gibt es im Sprint dann doch, die ein bisschen anders verlaufen als der übliche Sprinttag mit Daily. Das ist zum einen die Review mit dem Kunden und allen Stakeholdern und zum anderen der Sprintwechsel, der in unserem Fall meistens aus Retrospektive und Planning besteht.

In der Review werden allen Stakeholdern, d.h. allen, die Interesse am Arbeitsergebnis haben, die absolvierten Storys und gefixten Defects demonstriert. Meistens live in der Anwendung und unter Einbezug der Stakeholder, die das üblicherweise auch gern annehmen und das Arbeitsergebnis auf Herz und Nieren testen – und es hoffentlich abnicken. 😉

Je nach Projektsetup kann ein Sprint mit der Review enden, wenn im besten Fall alle Storys abgenommen und demonstriert wurden. Anschließend gibt es eine Retro und vielleicht sogar einen Sprintwechsel mit Planning. Manchmal funktioniert das logistisch nicht und wie im Falle meines Teams endet meistens der Sprint mit der Review, lässt aber noch etwas Platz für abschließende Arbeiten. Am  Tag darauf geht es dann weiter mit Retro und Planning.

Die Retro ist das Sprint-Ereignis, das allen Mitgliedern des Scrum-Teams Gelegenheit gibt zu sagen was gut lief und was noch verbessert werden kann. Damit gibt einem das Meeting Raum sich beispielsweise bei hilfsbereiten Kollegen zu bedanken oder auch einfach mal Erfolge zu feiern. Aber auch zu sagen, was nächstes Mal anders laufen sollte oder einen Konflikt neutral anzusprechen und Lösungen für die Zukunft zu finden. Retros sollen kein Sammeltopf für alle Probleme der Menschheit sein oder Jammer-Runden, sondern konstruktiv. Deswegen formulieren wir in der Regel Aktionen, die wir im nächsten Sprint versuchen umzusetzen.

Im Planning wird wiederum der kommende Sprint unter Berücksichtigung vieler Parameter geplant. Wurde im vergangenen Sprint alles absolviert? Wieviel kann laut Prognosen und Velocity-Kennzahlen eingeplant werden? Wie ist die Kapazität des Teams? Der PO stellt in der Regel die Priorisierung vor und die anderen Mitglieder des Scrum-Teams geben eine Einschätzung ab, was erledigt werden kann unter der Einschätzung des Scrum Masters, der beispielsweise die Kapazität kennt. Kommt man auf einen gemeinsamen Nenner, kann der Sprint gestartet werden. Der Sprintwechseltag ist meistens der Meeting-reichste und sorgt dafür, dass sich die Entwickler den Rest der Zeit auf die Umsetzung der Story konzentrieren können mit allem was dazu gehört. Was noch dazu gehört? Automatisierte Tests beispielsweise, PoCs (Proof of Concept) unter Einbeziehen neuer Technologien und was der Sprint eventuell noch so alles hergibt.

Wir haben euer Interesse für Scrum geweckt? Dann schaut doch mal bei unseren anderen Beiträgen aus der Reihe Scrum in der Praxis vorbei.

Scrum in der Praxis: Teil 1, der erste Sprint
Scrum in der Praxis: Teil 2, das Sprintende
Scrum in der Praxis: Teil 3, die Retrospektive oder Lego-Duplo am Arbeitsplatz

 

Just do IT!

Wie schon in der Vergangenheit berichtet, geben wir Jungen und Mädchen im Rahmen des MINTLOOK-Projekts die Möglichkeit ein duales Probestudium bei uns zu absolvieren. Unsere letzten beiden „MINTies“ Marlene und Maike haben uns ein abschließendes Review gegeben, bevor sie in die akademische Welt hinausgingen. 😀

ibm-client-innovation-center-marlene-maike

Wie wurden wir auf das MINTLOOK-Projekt aufmerksam?

Die Möglichkeiten, den Weg nach dem Abitur zu bestreiten sind vielfältig und oftmals undurchsichtig. Deswegen sind ausführliche Informationen auf Webseiten oder Newsletter zur Studienorientierung, wie der der Agentur für Arbeit besonders hilfreich. Auch die TH Brandenburg hat sich dies zu Nutze gemacht. Aufgrund der ansprechenden Projektbeschreibung, sind wir beide zu dem Entschluss gekommen, dass dieses Probestudium unser nächstes Jahr gestalten soll.

Was sind unsere Aufgaben im CIC?

Zu Beginn des Praktikums haben wir zahlreiche Tutorials absolviert, um einen ersten Einblick in Programmiersprachen, wie JavaScript, jQuery, HTML und CSS zu erlangen. Im Rahmen unseres selbstgewählten Projekts haben wir uns außerdem ausführlich mit dem UX Design beschäftigt.

Das Projekt ist eine Web App, die vor allem Schüler und Studenten das Lernen erleichtern soll. Denn mit Hilfe eines Timers ist es möglich eine Zeit einzustellen, in der, ohne den Ablenkungsfaktor Handy, konzentriert gelernt werden kann. Wenn das Handy in dieser Zeit nicht benutzt wurde, ist die ‚Mission‘ erfolgreich gewesen und der User kann seinen eignen kleinen Baum begutachten. Sollte er jedoch das Handy in dieser Zeit genutzt haben, stirbt der Baum.
So makaber die Idee zunächst klingt, so viel Freude und Tränen hat sie uns beim Designen und Entwickeln bereitet.

Neben unserer Projektarbeit durften wir in verschiedene Bereiche des Centers reinschnuppern und unsere eigenen Fähigkeiten, unter anderem in einer SoftSkill-Schulung, auf die Probe stellen.

ibm-client-innovation-center-mintlook-training

Was gefällt uns besonders am CIC?

Uns wurde von Anfang an viel zugetraut und so hatten wir die Möglichkeit uns selbst auszuprobieren und gerade beim Design unserer App auszutoben. Kamen wir dann doch mal an einer Stelle nicht weiter, hatten unsere Betreuer immer ein offenes Ohr für uns und standen uns mit Rat und Tat zur Seite. Generell war das Arbeitsumfeld sehr angenehm, da Hierarchieebenen kaum bemerkbar sind und man sich auch privat mit allen sehr gut unterhalten kann. Dadurch ist das IBM CIC für uns ein Arbeitsplatz, zu dem man gerne zurückkommt. Zusätzlich bekamen wir auch die Möglichkeit uns fortzubilden oder unsere Talente zu vertiefen, zum Beispiel bei der Softskills-Schulung, in der wir mehr über Kommunikation und Selbstpräsentation gelernt haben.

Was nehmen wir aus der Zeit in Magdeburg mit?

Für uns stellt das CIC definitiv einen attraktiven Arbeitgeber dar. Denn das Center bietet viele Chancen sich weiter zu entwickeln und über sich selbst hinaus zu wachsen. Es hat viel Spaß gemacht in einem Team mit vielen verschiedenen Charakteren zusammen zu arbeiten, seine Meinung zu vertreten und trotzdem Kompromisse einzugehen. Das hat

eine angenehme Arbeitsatmosphäre geschaffen und uns dazu gebracht den einstündigen Arbeitsweg auf uns zu nehmen.

Außerdem ist IT wesentlich mehr als stupides Programmieren und auch Büroarbeit kann alles andere als langweilig sein. Maike hatte die Möglichkeit sich kreativ auszuleben und Marlene konnte mehr über ihren Berufswunsch im Projektmanagement erfahren. Generell hat uns beiden das Praktikum geholfen unser Selbstvertrauen zu stärken.

Haben uns die gesammelten Erfahrungen bei der Studienwahl geholfen?

„Mir hat das Praktikum die Tore zu informatikbasierten Studiengängen geöffnet und gezeigt, dass man seine Hobbys, zumindest zu einem Teil doch zum Beruf machen kann.“ – Maike

„Für mich war schon vor dem Prakikum bei IBM klar, dass ich Wirtschaftsingenieurwesen an der TH Brandenburg studieren möchte. Des Weiteren fange ich ab Juni als Werkstudent in Berlin im Projektmanagement an. IBM hat mich in diesem Beschluss auch bestärkt und mir die Möglichkeit gegeben mit vielen Projektmanagern zu reden. Dadurch habe ich einen sehr guten Einblick in diese Jobrolle bekommen. Jetzt bin ich mir sehr sicher, dass das der richtige Weg für mich ist und bin dafür auch sehr dankbar!“ – Marlene

ibm-client-innovation-center-mintlook

Scrum in der Praxis: Teil 3, die Retrospektive oder Lego-Duplo am Arbeitsplatz

In unserer Rubrik Tech Talk stellen Thomas und Mandy euch heute wieder eine Situation aus dem agilen Umfeld vor, diesmal die Retrospektive. Ihr habt noch nie in der agilen Entwicklung gearbeitet? Dann folgt aufmerksam unserer Reihe „Scrum in der Praxis“.

ThomasWolf-0791

Würde man ein Scrum-Lehrbuch aufschlagen, würde man sicher auf den ersten Seiten darüber lesen, dass dieses Rahmenwerk auf der empirischen Prozessteuerung basiert. Das heißt im Grunde, dass Scrum von drei Säulen getragen wird – Transparenz, Anpassung und Überprüfung. Dementsprechend sind auch die verschiedenen Events, die bei Scrum vorgesehen sind, aufgebaut. Eines der wichtigsten Events stellt dabei die Retrospektive dar. Hier werden Themen aus dem Projektalltag des letzten Sprints reflektiert, Problemstellungen identifiziert und Verbesserungen erarbeitet. Oder anders gesagt, man wertet die „Lessons learned“ aus.

Was nicht mehr so genau im Lehrbuch stehen würde, ist der Verlauf der Retro. Da gibt es einige erprobte Methoden um Verbesserungspotentiale zu identifizieren. Die klassische Methode gliedert sich in 5 Phasen:

1. Set the Stage – Rahmenbedingunen schaffen

  • Eine Athmosphäre schaffen, wo sich die Teammitglieder wohl genug fühlen, um offene Punkte zu diskutieren

2. Gather Data – Informationen sammeln

  • Ein Rückblick bei dem man identifiziert, was gut lief und was hätte besser laufen können

3. Generate Insights – Erkentnisse entwickeln

  • Die tatsächliche Ursache erkennen

4. Decide what to do – Entscheiden was zu tun ist

  • Entscheidungen über konkrete Maßnahmen treffen, die im kommenden Sprint umgesetzt werden

5. Close Retrospektive – Abschluss

  • Dokumentation der Ergebnisse und Planung weiterer Schritte

Jetzt stellt euch vor, ihr befindet euch in der Phase „Gather Data“ und euer Scrum Master kommt und kippt einen großen Haufen Duplo-Steine (Kinder-Lego) vor euch aus. Im ersten Moment erscheint das größte Problem zu sein – „Was sollen wir mit diesem Kinderspielzeug anfangen?“ und „Wie soll es behilflich sein damit Themen aus dem letzten Sprint zu sammeln“. Zusätzlich gibt es bei dieser Art der Retro noch ganz andere Herausforderungen. Und zwar sind es die anderen Kollegen, die an dem Meetingraum vorbei laufen und duch die Glastüren neidisch zu schauen beziehungsweise sogar fragen ob sie mitspielen dürfen.

Scrum-Retrospektive

Natürlich ist der Sinn des Ganzen nicht mit den Duplo Steinen zu spielen. Es dient dazu in den unorthodoxen Ecken des Geistes nach Problemen zu suchen – also „Outside of the box“ zu denken. Denn was wir brauchen, und nicht nur in Scrum, sind kreative Mitarbeiter, die eigenständig und mit Freude helfen ihre eigene Arbeit zu verbessern. Dementsprechend soll die eigene Kreativität herausgefordert werden den Verlauf eines normalen Softwareentwicklungs-Zyklus mit Duplo-Steinen darzustellen. Dabei variieren die Ergebnisse von einfachen Würfeln bis hin zu komplexen Freizeitparks. Das Wichtige dabei ist natürlich nicht das eigentliche Bauwerk sondern die Interpretation dahinter und die Thematiken, die sich daraus ableiten lassen.

Grundsätzlich stellt diese Methode eine gute Möglichkeit dar, den Prozess aufzulockern und frischen Wind in das Team zu bringen. Die Atmosphäre wird positiv beeinflusst, das Team hat Spaß und wird auf eine neue Art und Weise gefordert. Außerdem können durch diese Vorgehensweise am Ende Themen hervortreten, die im normalen Prozess nicht aufgetaucht wären. Trotzdem sei abschließend zu bemerken, dass bei dieser Variante auch eine gewisse Gefahr mitschwinkt. Sie sollte eher bei erfahrenen Teams, die mit den Scrum-Prozessen bereits sehr vertraut sind, Anwendung finden als bei Teams, die gerade erst frisch mit Scrum anfangen. Denn durch den Spielcharakter, kann die Konzentration schnell abschweifen und das gesamte Vorgehen verliert an Sinnhaftigkeit und wird nicht ernst genommen. Deswegen lieber als Highlight in den altbekannten Standard-Retrospektiven-Rhythmus einbauen und das Team aus seiner Komfortzone locken.

IBM Watsons Oscar-Gewinner-Vorhersage im Realitätscheck

Wie ihr vermutlich mitbekommen habt, werden sich die Größen des amerikanischen Filmgeschäfts am 4. März 2018 wieder zur Prämierung ihrer Besten treffen. Jährlich wird den besten Schauspielern, Filmen, Regisseuren und Vertretern der Filmtechnik die berühmte Oscar-Trophäe für ihre herausragenden Leistungen verliehen.

Die Verleihung findet jetzt schon seit 90 Jahren statt und erfreut sich großer Beliebtheit. Doch kann man nicht die Vermutung anstellen, dass sich langsam ein gewisses Muster abzeichnet? Sind die Gewinner der „Academy Awards“ vielleicht sogar vorhersehbar?

Genau diese Frage stellten sich IoT-Kollegen auch. Kann „IBM’s Watson Personality Insights“ dabei helfen den Gewinner des „Best Picture“-Oscars zu bestimmen? 2017 wagten sie den Versuch den Ausgang der Verleihung mithilfe von IBM Watsons Analysefähigkeiten vorherzusehen. Doch wie gingen sie vor?

Sie ließen ihn die Skripte der letzten 10 „Best Picture“-Gewinner analysieren und verglichen sie mit den 9 aktuell nominierten Filmen. Die Ergebnisse, in Form einer „Sunburst-Visualisierung“ (Beispiel siehe Bild unten), sollten gemeinsame Merkmale der Gewinner-Filme aufzeigen und ein Muster erkennen lassen.

IBMWatson-TheBossBaby-Analysis

Als aktuelles Beispiel, die Analyse des Films „The Boss Baby“ mittels „IBM’s Watson Personality Insights“.

Nach den Analysen und Interpretationen bedeuten die Werte folgendes für den Gewinnerfilm. Er nutzt Fantasie, um eine reichere und interessantere Welt zu erschaffen. Er würde die intellektuelle Neugier mit Symbolik herausfordern und sich den Hochs und Tiefs des Lebens stellen können. Außerdem würde er Traditionen achten und damit ein Gefühl von Stabilität vermitteln, aber auch Mitgefühl erzeugen aufgrund des hohen Sympathie-Levels.

Nachdem also alle Visualisierungen auf die besagten Faktoren analysiert wurden, konnte eine Annahme getroffen werden. Die Trophäe für die Kategorie „Best Picture“ hätte somit an den Film „Hacksaw Ridge“ vergeben werden müssen. Sein stärkster Konkurrent war „Arrival“, dessen Werte nur um ein paar Prozente daneben lagen.

Doch kommen wir nun zum Realitätscheck. Der 89. Academy-Award in der Kategorie „Best Picture“ ging an „Moonlight“, einem Film, der nach Watsons „Sunburst-Visualisierung“ eher eine Außenseiter-Chance hatte. Schade, da lagen wir mit unserer Interpretation der Gewinner-Muster etwas daneben. Es scheinen also noch mehr Faktoren eine Rolle zu spielen, die wir mit IBM Watson nicht analysieren können. Beispielsweise beeinflussen die aktuelle, politische Lage, die Rollenbesetzung oder auch die visuelle Umsetzung das Ergebnis.

Doch eigentlich ist es auch beruhigend zu wissen, dass wir immer noch überrascht werden können und noch nicht jedes Ereignis vorhersehen. Dementsprechend müssen wir uns auch keine Gedanken machen, dass die  Filmemacher im letzten Jahr nur einem bestimmten Algorithmus gefolgt sind, in der Hoffnung dadurch die begehrte Trophäe zu gewinnen. Sondern nach wie vor Kreativität im Vordergrund steht und man seine Ideen frei entfalten kann.

Wir wünschen euch auf jeden Fall viel Spaß bei der 90. Oscarverleihung und hoffen, dass ihr Dank flexibler Arbeitszeiten am nächsten Tag etwas später erscheinen könnt. 😉 Und abschließend eure Vorhersage – was glaubt ihr welcher Film dieses Jahr den „Best Picture“-Award gewinnen wird?