DE EN IT NL
Software Engineering: "Experimentieren, ganz krass" (BJC013)
Karriereblog Schweiz Software Engineering: "Experimentieren, ganz krass" (BJC013)
Timm Süss 12. September 2016 IT, Podcast, Digitalisierung
In dieser Episode sind wir zu Gast im Software Engineering der Basler Versicherung Schweiz. Wir unterhalten uns mit Matthias Cullmann, Software Engineer Java, und Christian Josephy, Testing Engineer über ihre Entwicklungsumgebung, den Raum zum Experimentieren und was agiles Arbeiten im Alltag bedeutet.

Podcast abspielen (vollständige Folge)
Show Notes

Wenn dir diese Episode gefallen hat, dann könnte dich das Interview mit den Teamleitern der IT Schweiz interessieren.

Könntet ihr euch kurz vorstellen?

Christian - 03:19: Mein Name ist Christian Josephy, und ich arbeite seit 5 Jahren als Test Engineer bei der Basler Versicherung.

Matthias - 03:28: Mein Name ist Matthias Cullmann, ich bin Software Engineer und Leiter Competence Center Software Engineering.

Matthias, was wolltest du werden, als du klein warst?

Matthias - 03:38: Als ich klein war, wollte ich Landwirt werden. Dann habe ich als Steinmetz angefangen, bin aber über meine Liebe zur Mathematik ins Software Engineering gekommen und habe Informatik studiert.

Wie bist du zur Baloise gekommen?

Matthias - 04:09: Ich war zuerst bei einem Dienstleister in Frankreich und wollte zurück in die Region. In meiner Stellensuche hatte ich verschiedene Angebote, und die Baloise hat mir davon am besten gefallen.

Was macht ein Software Engineer bei der Baloise?

Matthias - 04:36: Ich mache Java-Entwicklungen für die internen Kunden der Baloise. Dabei arbeite ich in einem Scrum-Team und habe von Front End bis Back End-Entwicklungen eine ganze Reihe von Aufgaben. So arbeite ich moment an einem Partner-System, eine Art erweitertem Adressbuch mit zusätzlicher Qualitätssicherung und Features. Ein "Partner" ist dabei eine Person oder eine Firma, mit der wir Kontakte pflegen.

Matthias, was wolltest du werden, als du klein warst?

Christian - 05:54: Ich weiss ich nicht mehr genau, ob ich überhaupt einen Berufswunsch hatte. Als Teenager habe ich angefangen, mit Elektrizität zu experimentieren und habe als Hobby elektronische Geräte wie Verstärker oder Lautsprecher gebaut. Das hat dazu geführt, dass ich Elektrotechnik studiert habe - ganz ohne klares Berufsbild - und so bin ich in der Industrie gelandet. Und weil Software auch etwas mit Elektrizität zu tun hat, z.B. in der Steuerung, kam ich in die Software-Entwicklung, zuerst in der Industrie und später in der Bankenbranche. Als die Baloise dann Test Engineers gesucht hat, habe ich mich beworben.

Du bist Test Engineer. Was testest du?

Christian - 07:24: Meistens arbeite ich auf der GUI-Ebene, d.h. dort, wo Menschen eine Applikation benutzen. Beispielsweise verwendet ein Aussendienstmitarbeiter eine Applikation, für die Matthias' Team einen neuen Release zur Verfügung stellt.  Diese müssen getestet werden. Ich schreibe Automaten, die die menschliche Bedienung von solcher Software simulieren. So kann ich sicher stellen, dass unsere Mitarbeitenden einen neuen Partner fehlerfrei anlegen können.

Dann arbeitet ihr mit automatisierten Tests?

Christian - 08:10: Ja, sehr viel, vor allem in den Scrum-Teams. Unsere Fachbereiche machen daneben auch viele manuelle Tests. Aber da wir sehr schnelle Zyklen haben, sind wir auf automatische Tests angewiesen. Dazu gehören nicht nur GUI-Tests, sondern auch Schnittstellentests und Tests von Software Services.

Arbeitest du an denselben Produkten wie Matthias?

Christian - 08:38: Wir haben noch nie zusammen in einem Projekt gearbeitet, aber bei wichtigen Applikationen wie dem Partnersystem kommen wir natürlich nicht darum herum, Partner automatisiert anzulegen.

Mit welchen Sprachen arbeitet ihr?

Matthias - 09:05: Java ist für uns die wichtigste Sprache und für uns strategisch. Da wir aber eine lange Geschichte als interne IT haben, gibt es eine gute Mischung aus verschiedene Sprachen, z.B. C, Delphi und PL/I auf dem Mainframe. Ich selbst arbeite vor allem mit Java, JavaScript und SQL.

Wie sieht eure Systemumgebung aus?

Christian - 09:53: Wir entwickeln lokal spielen das, was entwickelt wird, über verschiedene Umgebungen bis in die Produktion ein. Dabei haben wir drei Testumgebungen - eine entwicklungsnahe, eine produktionsnahe und eine "halbe-halbe" Umgebung.

Mit welcher Hardware arbeitet ihr?

Matthias - 10:32: Ich benutze ein 64bit Notebook auf Windows mit genügend Arbeitsspeicher. Ich kann mich einloggen, wo ich will, kann auf Mails via mein privates Telefon zugreifen. Wenn ich will, kann ich auch von meinem privatem Rechner von zuhause aus arbeiten. Ich bin also ganz flexibel.

Wie sieht eure Arbeitsumgebung aus?

Matthias - 11:18: Wir sind im grossen roten Gebäude beim Bahnhof in Basel in einem Flex-Office. Das ist eine grosse Fläche, die in "Home Bases" mit verschiedenen Farben unterteilt ist. Ich bin normalerweise in der grünen Homebase, aber ziehe mich zum Konzentrieren auch gerne in die "Quiet Zone" zurück. Dort kann ich mich ohne Telefon in meine Arbeit vertiefen. Die Kaffeezone ist natürlich auch wichtig.  Daneben gibt es verschiedene Besprechungs- und Meetingräume, und das gute an diesen ist, dass man sie nicht buchen kann. So findet man immer Platz, um sich zu besprechen.

Was bedeuten die verschiedenen Farben der Home Bases?

Christian - 12:32: Es geht vor allem darum, die Bereiche abzugrenzen, damit man weiss, wo man arbeitet, und dass man mit den Menschen zusammen sitzt, mit denen man auch zusammen arbeitet.

Bedeutet das, dass ihr meist in eurer Home Base an einem festen Platz arbeitet, aber manchmal auch in andere sitzt?

Christian - 13:07: Nicht ganz. Innerhalb meiner gelben Home Base kann ich frei wählen, wo ich sitze. Aber ich könnte nicht einfach in die grüne Zone sitzen, die sehr begehrt ist - ausser, ich hätte ein Projekt mit jemandem aus der grünen Zone.

Matthias: Ich wechsle sehr häufig den Arbeitsplatz, da ich viel Support für verschiedene Applikationen mache. Dazu gehört auch GIT, das alle Entwickler benutzen. Manchmal werde ich auch per Chat irgendwo hin gerufen und bleibe dann für eine halbe Stunde dort.

Christian: Den Arbeitsplatz wechsle ich auch oft, aber eigentlich nie die Home Base. Man sieht also, dass es ganz viele Möglichkeiten gibt, zu arbeiten.

Ist man in den Quiet Zones richtig ungestört?

Matthias - 15:00: Das ist so. Es gibt geschriebene und ungeschriebene Regeln, und die werden gut respektiert. Im Home Office kann man natürlich auch ruhig arbeiten.

Wie seid ihr in der IT Schweiz organisiert? Wie kann man sich eure agile Methode vorstellen?

Christian - 15:57: Jeder hat unterschiedliche Rollen. Alle Mitarbeitenden in der IT Schweiz werden von insgesamt 3 Linienmanagern geführt, wir haben also sehr flache Hierarchien. Damit das funktioniert, haben wir in Scrum Teams aufgeteilt, die sich um inhaltliche Themen kümmern - z.B. ums Partnersystem oder um Motorfahrzeugversicherungen.  Daneben gibt es verschiedene Rollen - Entwickler, Tester - die in "Competence Centers" aufgeteilt sind, wo man sich interdisziplinär austauschen kann. Jeder Mitarbeiter hat also einen Vorgesetzten sowie eine oder mehrere Gruppen, denen er sich anschliesst.

Das klingt wie eine Matrix-Organisation mit Fachbereichen und Projekten.

Christian - 17:28: So ist es. Und in Scrum Teams werden die Projekte abgewickelt. Es gibt aber auch Projekte mit mehreren Scrum Teams. In dem Sinne ist es eher ein Würfel als eine Matrix-Organisation.

Wie ist es für euch, in einer solchen Organisation zu arbeiten?

Matthias - 18:03: Sehr spannend. Neben meiner Arbeit als Software Engineer konnte ich noch weitere Rollen übernehmen. Mir macht vor allem das gemeinsame Lernen, das gemeinsame Entwickeln und der Wissensaustausch besonderen Spass. Das ist möglich in einer solchen Organisation. Hier man hat einerseits ein projekt- und fachbezogenes Team, aber auch die Möglichkeit, sich in anderen Gruppen auszutauschen. Ich finde es auch schön, dass wir uns über die Firmengrenzen hinaus austauschen können, sei es bei Agile Breakfasts, in der Agile User Group, Konferenzen, und so weiter.

Christian: Das geht mir genau gleich. Wir sind z.B. am Swiss Testing Day vertreten. Es ist natürlich eine Herausforderung, wenn man so viele Optionen hat, was man machen könnte, andererseits sind die Chancen deutlich im Plus. Beispielsweise organisieren wir "Open X Days", an denen alle Mitarbeitenden einen ganzen Tag lang Themenworkshops besuchen kann, und die man selbst auch anbieten kann. Der Wissensaustaustausch über die Teams funktioniert, und man kann nur profitieren, wenn man andere Menschen kennenlernt und mit ihnen Problemlösungen diskutiert.

Open X Day - das ist eine Art Barcamp, nicht wahr?

Matthias - 20:41: Die Open X Days orientieren sich am Konzept der Open Space Meetings. Wir haben nach einem Format gesucht, das Leuten gleichzeitig Freiräume bietet, denn oft kann man Probleme nicht alleine lösen. Dabei gibt es keine Agenda. Alle treffen sich am Morgen, das Programm wird gemeinsam in Stundenslots aufgeteilt, und jeder geht nur an die Workshops, die einen interessieren. Oft laufen Workshops parallel, zueinander was dazu führt, dass man nicht zu viel, sondern nur die interessierten Leute dabei hat.

Was hat es mit den Postern für Hackathons auf sich, die hier hängen?

Matthias -22:10: Im Moment organisieren wir den ersten Baloise Hackathon. All diese Formate haben wir natürlich nicht erfunden, aber wir probieren die Konzepte für uns aus.

Ich merke, ihr habt viel Raum zum Experimentieren.

Christian - 22:44: Ganz krass. So etwas wie das hier war in meiner bisherigen Berufskarriere noch nie möglich - die Möglichkeiten, auszuprobieren, Fehler zu machen, aus Fehlern zu lernen, aber vor allem auch von unserer IT-Leitung so ermuntert zu werden, Dinge auszuprobieren, mehr vom Guten zu tun und vom Schlechten weniger zu tun - das erlebe ich zum ersten Mal.

Wo konntest du zum letzten Mal etwas aus einem Fehler lernen?

Christian - 23:27: Beispielweise, wenn ich etwas ausprobiere, das nicht auf Anhieb so funktioniert, wie ich es mir vorstelle. Dann brauche ich etwas mehr Zeit und habe kein schlechtes Gewissen dabei, mir diese zu nehmen. Ich muss mich nicht verpflichten, in 10 Stunden etwas abzuliefern, sondern kann sagen, in 10 Stunden weiss ich, ob ich 20 oder 50 Stunden brauche. Schrittweise vorgehen, und immer wieder innehalten.

Was bedeutet diese Flexibilität für neue Mitarbeitende?

Christian - 24:09: Menschen, die keine Eigenitiative haben und kein Gefühl haben, was nützlich ist und was nicht, die werden es schwer haben. Es ist unabdingbar, dass man mitdenkt, sich einbringt und die Chancen, die einem hier geboten werden, aktiv nutzt.

Matthias: Andererseits finde ich, dass es sehr viele Informatikerkollegen gibt, die diese Voraussetzungen gut erfüllen. Für Leute, die aus einer anderen Firmenkultur kommen, mag das am Anfang seltsam sein. Aber gerade wenn man jünger und mit Open Source aufgewachsen ist, dann ist das wahrscheinlich normal. Ich finde es wichtig, dass man in der Informatik diesen Spirit hat.

Du hast GIT erwähnt. Arbeitet ihr mit Versionskontrolle?

Matthias - 25:52: Auf jeden Fall.

Auf GitHub ist Baloise auch vertreten. Sind das auch Open Source-Projekte?

Matthias - 25:58: Baloise hat einen Organisationsaccount auf  github.com/baloise. Dort gibt es verschiedene Spielwiesen, zwei Eclipse-Plugins, die auch auf dem Marketplace sind und arbeiten am Thema ChatOps. Dafür habe ich gerade ein Rocket.Chat/Jenkins-Plugin geschrieben, das wider Erwarten auf Interesse gestossen ist. Das ist alles öffentlich - einen privaten Account haben wir nicht.

Christian: Auch auf der Test-Seite gibt es ein paar GitHub-Projekte, so z.B. ein Dashboard-Plugin für Confluence, mit welchem man Jenkins-Jobs  visualisieren kann, sowie ein ganzes Framework für Testautomatisierung, basierend auf Open Source-Technologien wie Selenium. Solche Projekte sollte man deshalb unterstützen, weil wir als Firma ja auch Open Source-Produkte einsetzen, und da ist es das Mindeste, wenn man etwas davon zurück gibt.

Wie baut ihr neue Versionen? Könnt ihr einen Build in einem Schritt erstellen?

Christian - 27:51: In dem Projekt, in dem ich drin bin, ist dies ein komplexer, mehrstufiger Prozess.

Matthias: Das kann man nicht pauschal beantworten. Wir haben Eigenentwicklungen wie auch eingekaufte Software, und da gibt es verschiedene Arten, diese produktiv zu schalten. Für unsere Eigenentwicklung ist unser Ziel, dass wir nur noch mit GIT interagieren, was bedeutet, dass im Idealfall nach einem Check-In der Rest automatisch läuft. Wir sind noch nicht ganz da, aber kommen hoffentlich bald ans Ziel.

Gibt es tägliche Builds?

Christian - 29:08: In meinem Projekt, ja.

Matthias: Wir betreiben Continuous Integration, was bedeutet, dass nach jedem Push die Scripts loslaufen und so eine neue Version gebaut wird. Ob diese Versionen auch deployed werden, entscheidet jedes Projektteam für sich.

Wie behält ihr den Überblick über Bugs und Features?

Christian - 29:53: Wir arbeiten mit Jira, welches verschiedene Issue-Typen definiert. Alle Bugs, die über ein Sprintende hinüber laufen, werden dort dokumentiert. Beim Einchecken kann man die entsprechende Issue-Nummer auch dazu angeben, so dass man automatisch sieht, wie und wo der Code geändert wurde.

Wie plant ihr eure Releases? Habt ihr einen Zeitplan?

Matthias - 30:37: Wir haben einerseits eine Releaseplanung, die beispielsweise quartalsmässige Releases vorsieht. Andererseits und wichtiger sind die Sprintlängen, die typischerweise bei zwei Wochen liegt. Wenn es der Fachbereich wünscht, könnten wir nach jedem Check-In einen Release machen - bei Bugfixes warten wir natürlich nicht 3 Monate.

Wie dokumentiert ihr Spezifikationen? Schreibt ihr User Stories?

Christian - 31:35: Ja, wir schreiben User Stories - dafür gibt es Jira eine eigene Verwaltungsmöglichkeit. Wie detailliert die Spezifikationen sind, hängt sehr vom Projekt ab. Es gibt Projekte, die mit einem Einzeiler arbeiten, andere benötigen Dokumente, Präsentationen und Tabellen. Aber wenn man nur 2 Wochen sprintet, dann können die Spezifikationen gar nicht so gross sein. Das Ziel ist es, Komplexes so weit herunterzubrechen, bis die einzelnen Aufträge wieder einfach und verständlich sind.

Wie prüft ihr Usability?

Matthias - 32:27: Wir haben das Glück, dass unsere Kunden intern und somit sehr nahe sind - manchmal nur einen Stock darüber oder sogar gleich daneben.

Christian: Und in unseren Teams gibt es auch Leute, die das entsprechende Versicherungs-Know-How haben oder die Themen wie Testing verstehen. Unterm Strich ist es immer ein Abwägen von Interessen, denn eine wunderschöne Benutzeroberfläche nützt uns nichts, wenn das Backend nicht funktioniert. Da kann man bei einem Schreibfehler auch mal ein Auge zudrücken.

Wieso seid ihr und bleibt ihr bei der Baloise?

Christian - 33:52:  Ich bin zur Baloise gekommen, weil es ein interesanter Job ist und bereits vor fünf Jahren Agilität gelebt wurde. In den letzten 5 Jahren ist so viel passiert, ich konnte so viel lernen und mit anderen Leuten interagieren, dass ich so richtig in diese IT Schweiz hineingewachsen bin. Deshalb wünsche ich mir, dass ich mir nicht die Frage stellen muss, ob ich einen anderen Job möchte. Denn das was ich sehe, ist so toll, dass mich andere Optionen überhaupt nicht interessieren.

Matthias: Bei mir war das ähnlich. Die Umstellung zu Scrum fand ich sehr spannend, auch wenn mich die Versicherungsbranche ursprünglich nicht gereizt hat. Und es bleibt immer noch spannend! Jedes Jahr kann ich zurückschauen und merke, dass sich etwas getan hat, und wir haben noch viel vor.

Gibt es auch Schattenseiten an eurem Job?

Matthias - 35:36: Was mir im Job noch nie so gelegen ist die Arbeitszeiterfassung. Aber wir haben Vertrauensarbeitszeit, und das tut nicht so weh.

Christian: Da kommt mir spontan nichts in den Sinn. Natürlich gibt es momentane Tiefs oder Konflikte, die Zeit zur Lösung brauchen - aber die bekommt man auch. Somit sind es nur kurze Momente in denen man sagt: Heute gehe ich etwas früher heim. Und dafür ist die Vertrauensarbeitszeit ja auch da.

Welche Tipps möchtet ihr Bewerbern mit auf den Weg geben?

Matthias - 36:50: Wenn mich Personalvermittler anrufen und mich fragen, nach welchen Profilen ich suche, so sage ich meist: Zwischen 18 und 80 und Skillsvoraussetzungen ändern sich schnell.  Viel wichtiger ist, dass Interesse vorhanden ist, dass man lernen und sich austauschen möchte.

Christian: Ein paar Grundanforderungen gibt es natürlich schon - als Tester muss man Java programmieren und das Test-Vokabular beherrschen. Aber ansonsten sind Neugierde, Wissens- und Austauschbereitschaft viel wichtiger.

Wenn sich ein Bekannter von euch bei Baloise vorstellen könnte, was würdet ihr ihm empfehlen?

Christian - 38:59: Überlege dir, welchen Beitrag du leisten kannst und warum du dich bewirbst. Sei im Interview neugierig und stelle Fragen, damit du spürst, ob die Chemie stimmt.

Matthias: Geh entspannt ins Gespräch und sei natürlich. Wir wollen wissen, wer ihr seid, und ihr wollt wissen, wer wir sind. Ich selbst lese gern Code - also wenn ihr einen GitHub-Account habt, interessiert mich das. Verstellen bringt nix.

Wie kann man mit euch in Kontakt treten?

40:25

Weitere Blogartikel aus der IT Alle Blogartikel