expedITion Blog

expedITion Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Projekt ist nicht gleich Projekt!

Während des Studiums habe ich mich immer gefragt, wie Softwareentwicklung bei einem großen Unternehmen wohl tatsächlich abläuft. Werden wirklich zunächst etliche UML-Diagramme angefertigt, bevor angefangen wird zu entwickeln? Werden moderne Methoden wie Scrum benutzt oder auf klassische Methoden wie das  Wasserfallmodell gesetzt? Werden progressive Technologien wie AngularJS oder HTML5 verwendet? Oder wird doch eher mit Assembler programmiert?

Um es kurz zu fassen: Beides!

Im Folgenden will ich euch einen kleinen Einblick geben, wie abwechslungsreich Projekte bei Capgemini ablaufen und wie unterschiedlich die Methoden, Technologien und Arbeitsabläufe sein können.

Dazu möchte ich euch zunächst mein Einstiegsprojekt vorstellen, das ich im Februar 2015 kurz nach meiner Anstellung begann: In einem BioTech-Unternehmen galt es, den Lebenszyklus der Rohdaten aus einem Gensequenziergerät zu automatisieren. Dies beinhaltete u.a. das physikalische Kopieren von Daten, das Registrieren von Daten in einer Datenbank, die Steuerung von Analysen auf den Daten, das Abarbeiten dieser Analysen in Netz von Crunchern und schließlich die Aufarbeitung und Visualisierung der Ergebnisse in einem Webinterface.

Das Projekt war gerade erst gestartet, als ich dazu stieß, und bestand zu dem Zeitpunkt aus nur einem Kollegen. Wir Graduierten hatten insofern „grüne Wiese“, was die technische Umsetzung angeht, und konnten all jene Technologien verwenden, die wir selbst für geeignet hielten. Eine Auswahl der eingesetzten Technologien/Frameworks: C#, WCF, WPF, NHibernate, MySQL, JavaScript, JQuery, AngularJS, Bootstrap.

Auch das Vorgehensmodell konnten wir frei wählen. Während wir anfangs - zu zweit - noch recht ungeordnet „auf Zuruf“ entwickelten, haben wir im Verlaufe des Projekts ein Kanban Board eingeführt. Zwischendurch haben wir auch einen Ausflug zu Scrum gemacht, jedoch recht schnell gemerkt, dass es in diesem sehr schnelllebigen Projektkontext nicht wirklich anwendbar war.

Natürlich haben wir als frisch gebackene Softwareentwickler nicht direkt alles richtig gemacht. Dadurch, dass wir unsere Software parallel zu der Entwicklung und Erforschung des Sequenziergeräts entwickelt haben, hatten wir häufig sehr hohen Zeitdruck. Dies führte dazu, dass wir kaum Spezifikation und Unit-Tests entwickeln konnten. Hier könnte man jetzt natürlich die Hände über dem Kopf zusammen schlagen, aber in diesem Projekt und diesem Kontext war unser „Rapid Prototyping“ genau das, was der Kunde benötigte - und das Projekt wurde ein großer Erfolg.

Dass es auch ganz anders geht, habe ich dann gemerkt, als ich Anfang dieses Jahres in ein anderes Projekt beim selben Kunden wechselte.

Die Software, die dort erstellt wird, soll, im Gegensatz zum vorherigen Projekt, an den Kunden gehen und für medizinische Zwecke genutzt werden. Das bedeutet, dass es sehr strenge Richtlinien zum Softwareentwicklungsprozess gibt. Alle Requirements müssen in einem Dokumentenverwaltungssystem genau erfasst, auf einzelne Softwarekomponenten herunter gebrochen und mit Tests validiert werden. Die Software wird im Team von der allgemeinen Architektur bis hin zu den detaillierten Komponentendesigns zusammen geplant. Ein „Ich bau das mal eben ein“, wie im vorherigen Projekt, gibt es hier definitiv nicht. Für mich war und ist es erstaunlich zu sehen, wie stark eine gründliche Designphase die Qualität des Codes verbessert. 

Ein weiterer, maßgeblicher Unterschied ist die Technologie: Da die Software hocheffizient sein muss, wird komplett mit C++ entwickelt. Für mich als Freund von Java und C# war das zunächst natürlich, sagen wir mal… gewöhnungsbedürftig. Trotzdem begrüße ich die Möglichkeit, mein Skillset zu erweitern.

Ich denke, an dieser Stelle wird klar, wie stark sich Projekte unterscheiden können. Ich empfinde diese unterschiedlichen Anforderungen als eine willkommene Abwechslung und ideale Möglichkeit, viel zu lernen.

Über den Autor

Chris A.
Chris A.
Chris kam 2015 nach seinem Masterstudium in Angewandter Informatik zu Capgemini. Dort arbeitet er als Software Engineer in unterschiedlichen Projekten. In seiner Freizeit spielt Chris gerne Gitarre oder trifft sich mit Freunden.

Kommentar hinterlassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem * gekennzeichnet.