expedITion Blog

expedITion Blog

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

Agil trifft Wasserfall

Weltanschauungen sind auch in der IT verbreiteter als man meint. Es gibt unter anderem die als chaotisch verschrienen agilen Methoden und es gibt das klassische Wasserfallvorgehensmodell, welches oft als langsam und veraltet angesehen wird.

Ich muss zugeben, in meiner bisherigen Tätigkeit als Software Engineer bei Capgemini und als Werkstudentin an der Uni sowie einem weiteren Unternehmen ordne ich mich eher dem Agilen zu. Dies wird oft als reaktiv, ohne Planung und sehr „In“ angesehen. Stimmt natürlich nicht. Ich, als pragmatischer Agile-Verfechter, muss sagen: Scrum zeichnet sich durch eine gute Planung aus, aber eben nicht mit einem Projektplan von über 2 Jahren, sondern von nur 3 Wochen langen Sprints. Besonders toll daran ist, dass jedes Teammitglied immer weiß, was ansteht und sich darauf konzentrieren kann, weil der Scrum Master versucht, Störungen vom Team fernzuhalten. Wer was abarbeitet, entscheidet das Team - manchmal ganz demokratisch, manchmal haben wir auch einfach gewürfelt. Und manchmal wurde auch das strenge Scrum-Verfahren (welches besagt, dass der Inhalt des Sprints unveränderlich ist) ganz spontan über den Haufen geworfen, weil dringende Produktionsprobleme anstanden.

Nach 3 spannenden Jahren im Scrum-Team mit unterschiedlichen Rollen als Requirements Engineer/ Designer, Softwareentwicklerin und Testerin stand eine Veränderung an. Eigentlich dachte ich, dass mich nach so vielen verschiedenen Rollen nichts mehr umhauen kann, aber ich muss zugeben: Ich habe einen Kulturschock erlebt.

Ich sollte als Requirements Engineer in ein sehr großes Projekt gehen, welches nach dem Wasserfallmodell organisiert ist, und dort Kollegen in technischen Querschnittthemen unterstützen. Meine Kollegen haben mich sehr freundlich aufgenommen und ich war von Anfang an beeindruckt, wie viele Prozesse es allein zur Erstellung von Software geben kann. Gleich in der ersten Woche erhielt ich erste Onboarding-Sessions über den Softwareentwicklungsprozess, über Spezifikationsartefakte, über Organigramme, die Gesamtarchitektur der Software, das fachliche Datenmodell … Mir schwirrte schnell der Kopf. Im agilen Manifest gilt funktionierende Software mehr als umfassende Dokumentation, und so habe ich oft in meinem alten Team erlebt, dass der Code unsere Dokumentation war oder dass man sich durch eine Delta-Spezifikation von User Stories wühlen musste. Hier im neuen Projekt ist es anders: es gibt Dokumentation, und das meist auch in guter Qualität. Besonders hilfreich finde ich es, dass ein Metamodell für die Verknüpfung der Spezifikationen untereinander eingeführt wurde. Anderenfalls hätte die Einarbeitung wohl viel länger gedauert.

Eine Sache scheint aber unabhängig vom Vorgehensmodell gleich zu sein. Die Fachseite möchte ihre Anforderungen so schnell wie möglich umgesetzt haben und als Requirements Engineer hat man die Aufgabe, sie bei der Findung einer guten Lösung zu unterstützen. Software und Technik lebt nie aus sich selbst heraus, sondern verfolgt immer einen fachlichen Zweck, und ich muss sagen, es ist sehr spannend, in die Arbeitsweise der verschiedenen Branchen hineinzuschauen.

 

JETZT EINFACH PER MAIL BEWERBEN!

Profitiere von unserem Bewerbungsspecial, der Capgemini Sommer-Bewerbung:
Den Sommer genießen und gleichzeitig in eines der größten IT-Unternehmen einsteigen.

Sende einfach deinen CV mit Wunschstandort, Starttermin und Interessenschwerpunkt an:

bewerbungsspecial@capgemini.com

Wir freuen uns auf dich!

Über den Autor

Kim M.
Kim M.
Kim kam 2013 nach ihrem Masterstudium in Informatik zu Capgemini in Hamburg. Sie hat 3 Jahre in einem Scrum-Team gearbeitet und ist seit Ende 2016 bei einem Kunden mit Wasserfall-Vorgehensmodell. In ihrer Freizeit liest sie gerne und ist leidenschaftliche Reiterin.

Kommentar hinterlassen

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