Dieser Blogbeitrag soll euch einen kleinen Einblick in den Alltag eines Software Engineers geben, und dabei womöglich ein paar Unklarheiten oder Vorurteile aus dem Weg räumen. In Vorstellungsgesprächen fällt uns immer wieder auf, dass manche Bewerber eine konträre Vorstellung von unserem Berufsalltag haben. Viele sind der Meinung, man würde nur noch beraten und beispielsweise keine Software mehr entwickeln.
Viel Spaß beim Lesen! Falls euch Punkte fehlen oder ihr noch Fragen habt, kommentiert gerne unter dem Blogbeitrag oder kontaktiert uns direkt über die üblichen Kanäle.
Tätigkeit: Erwartungshaltung versus Realität
(Meine) Erwartungshaltung
Zuallererst lässt sich festhalten, dass meine Vorstellung der Tätigkeit von der tatsächlichen Realität deutlich abgewichen ist. Meine ursprüngliche Erwartungshaltung war quasi folgendermaßen:
Ich werde Teil eines externen Projekts innerhalb Deutschlands. Hier werden mir beispielsweise klare Aufgaben bzw. User Stories anhand einer Sprint Backlog zugewiesen. Diese Stories muss ich innerhalb einer gewissen Zeit erledigen. Sofern ich nicht abliefere, wird das Projekt für mich nicht verlängert oder es folgen andere Konsequenzen. Anfangs bin ich demzufolge schon von dauerhaft hohem Projektdruck ausgegangen. Zudem hatte ich die Vorstellung, nie ein „vollwertiges“ Teammitglied im Kundenprojekt sein zu werden, da ich lediglich eine Story nach der anderen entwickeln muss. Schließlich bezahlt der Kunde genau dafür die 19bytes GmbH! Spoileralarm –> Dem ist nicht so!
Realität
Nun zu den Fakten!
In der Regel wird man im Projektprozess Teil eines agilen Teams beim Kunden. Die Teams bestehen meist aus internen und externen Kollegen. Dabei handelt es sich oft um kleine Entwicklungsteams nach Scrum, welche dann aus einem Scrum Master, einem Product Owner und mehreren Entwicklern bestehen. Es wird versucht, ein Team mit unterschiedlichen Fachleuten zu erstellen, welches dadurch einen klaren Fokus auf das Produktziel hat.
So auch wurde ich vor etwa zwei Jahren Mitglied in einem externen Projektteam. Im Regelfall erfolgt ein gutes Onboarding, um die IT-Infrastruktur und die unterschiedlichen Microservices kennenzulernen, welche für das jeweilige Produkt relevant sind. Mit der Zeit lernt man zwangsläufig auch die Produkte der anderen Teams kennen und ist im crossfunktionalen Austausch miteinander. Als vollwertiges Teammitglied nehmt ihr auch an allen bekannten Scrum-Events teil und unterstützt den Kunden so gut es geht in allen Bereichen. Dabei bringt ihr eure Expertise zu bestimmten Themen mit ins Projekt und teilt euer Wissen mit den Teamkollegen. Die Teamkollegen machen dasselbe und arbeiten euch gut in das Produkt und die IT-Infrastruktur ein, weil niemand im Nachhinein Lust hat, ständig hunderte Bemerkungen an eure Pull Requests zu kommentieren.
Bevor ich bereits in diesem Abschnitt den Rahmen sprenge, versuche ich im folgenden Kapitel einen typischen Arbeitsalltag zu beschreiben, damit ihr einen guten Einblick in das Berufsfeld gewährt bekommt.
Alltag eines IT-Consultants als Software Engineer in einem externen Projekt
In der Regel beginnt mein Arbeitstag zwischen 07:15 und 8:00 Uhr, meistens aus dem Homeoffice heraus. Ich bevorzuge die Ruhe zuhause, theoretisch könnte ich aber auch ins Dortmunder 19bytes Büro oder zum Kunden fahren. Hier hat jeder seine Vorlieben und es hängt definitiv auch einiges vom ausgestatteten Homeoffice Arbeitsplatz ab. Bei 19bytes gibt es neben der üblichen technischen Ausstattung (Notebook, Monitor, Kopfhörer etc.) zusätzlich bei Wunsch noch einen höhenverstellbaren Schreibtisch und einen Bürostuhl vom Arbeitgeber.
Bis 8:30 Uhr arbeite ich meistens an meiner aktuellen Story und prüfe kurz, ob alle Microservices unseres Teams im Kundenprojekt laufen. Falls vorhanden prüfe ich morgens auch gerne die Pull Requests der Kollegen. Ansonsten fallen die üblichen kleinen Tätigkeiten wie das Lesen und Beantworten von E-Mails und Slack Messages an.
8:30 Uhr
Das erste freiwillige „Morning Coffee“ Meeting bei 19bytes beginnt. Dieses Meeting dient dem Austausch mit den 19bytes Kollegen, da der Großteil in unterschiedlichen Projekten aktiv ist. Im Meeting wird meist über private oder aber auch teilweise über technische Themen gesprochen. Obwohl die Teilnahme an diesem Meeting freiwillig ist, ist es immer wieder schön zu sehen, dass ein Großteil der Kollegen gerne anwesend ist.
9:30 Uhr
Das Daily im Projekt startet. Hier wird der Fortschritt in Richtung des Sprintziels besprochen. Gibt es Impediments innerhalb des Teams oder Impediments von außerhalb, welche dieses betreffen, so werden diese geklärt und versucht vom Team abzuwenden.
09:45 Uhr
Im Normallfall arbeite ich ab jetzt allein oder im Pair Programming an einer Story aus der aktuellen Sprint Backlog.
12:00 – 13:00 Uhr Mittagspause
Üblicherweise bereite ich gerne in der Mittagspause mein Essen frisch zu. Befinde ich mich im Dortmunder 19bytes Büro oder beim Kunden vor Ort, so wird meistens zusammen etwas bestellt oder man geht in die Kantine des Kunden.
13:00 – 17:00 Uhr
Herrscht ein „terminfreier Tag“, arbeite ich weiter an meiner aktuellen Story und setze die Implementierung fort. Alternativ nutze ich die Zeit, um Pull Request von den Kollegen zu überprüfen. Im Alltag eines Entwicklers hat man allerdings selten „terminfreie Tage“, die ausschließlich zum Programmieren genutzt werden können. Mehr dazu im Abschnitt „Besonderheiten“.
Sonstige Scrum-Events während des Sprints
Auf die üblichen Scrum-Events werde ich an dieser Stelle nur ganz kurz eingehen. Falls ihr euch mehr mit dem Thema beschäftigten möchtet, empfehle ich euch die folgenden Homepages und meinen Blogartikel der sich mit der Scrum Master Zertifizierung auseinandersetzt:
https://scrumguides.org/download.html
- Daily:
- Fortschritt Richtung Sprint Goal transparent machen und überprüfen
- 15 min Timebox – gleiche Zeit, gleicher Ort an jedem Arbeitstag
- Impediments identifizieren
- Retrospektive:
- Reflektion des letztens Sprints
- Was lief gut? Welche Probleme gab es und weshalb konnten dieses auftreten?
- Identifizierung und schnelle Umsetzung möglicher Verbesserungen für den nächsten Sprint
- Sprint Planning:
- Das gesamte Team erstellt einen Plan für den kommenden Sprint. Der Vorschlag hierzu kommt vom Product Owner.
- Hinzufügen und Entfernen von Product Backlog Items – Erfahrungen einfließen lassen und Verfügbarkeiten der Mitarbeiter prüfen
- Die Product Backlog Items werden durch die Entwickler in kleinere Subtasks zerlegt
- Sprint Goal erstellen
- Dauer: Max 8 Stunden
- Sprint Review:
- Überprüfung vom Ergebnis des Sprints
- Vorstellung der Ergebnisse vor den wichtigsten Stakeholdern
- Feedback einholen und Diskussion über die nächsten Schritte für das Produkt
- Vermeiden einer simplen Präsentation, lieber eine Live-Demo vom neuen Feature vorstellen!
- Backlog Refinement (Kein Scrum-Event):
- Aufnahme neuer Backlog Items, Features und Epics
- Regelmäßiges Meeting, bei dem Product Owner und Entwickler zusammenkommen und die Backlog auf den aktuellen Stand bringen
- Diskussion über User Stories
- Schätzung der Komplexität einzelner User Stories
- Hinzufügen von Akzeptanzkriterien
Auf die folgenden Meetings gehe ich nicht weiter ein, da diese projektspezifisch sind. Die Meetings finden in der Regel wöchentlich statt. Nur die Spikes sind vom Umfang der aktuell geplanten Sprint Backlog abhängig.
- Backend JourFixe
- Architektur Community
- „Allgemeines“ JourFixe
- Sonstige Spikes
Besonderheiten im Alltag
Wie bereits oben erwähnt sieht es im Alltag häufig anders aus. In meinem aktuellen Projekt gibt es bereits ein Produkt, welches live ist und stetig um neue Features erweitert wird. Kommt es hier zu kleineren Störungen oder Meldungen von Bugs in unserem Team, muss bei Bedarf und nach Abschätzung der Priorität auch mal die aktuelle Story beiseitelegen gelegt und zuerst das Problem behoben werden.
Diese Abwechslung macht den Beruf meiner Meinung nach ebenfalls spannend – vom sich Stück für Stück immer tiefer in den Code eingraben und der Durchführung der Fehleranalyse bis hin zur Behebung des Problems.
Neben den gerade erwähnten Besonderheiten gibt es zusätzlich noch die „typischen“ Scrum Meetings wie die Retrospektive, Sprint Planning und die Sprint Review. Diese finden immer im gleichen Rhythmus statt und sind Pflicht für jeden Entwickler im Team. Zusätzlich gibt es im Sprint jedoch noch Spikes, welche häufig als Vorbereitung für kommende größere Stories oder zur Absprache mit anderen Teams genutzt werden.
Neben diesen Terminen gibt es dann noch weitere, an denen häufig nur Vertreter einzelner Teams teilnehmen müssen. Hier kann man als Entwickler beispielsweise seine Interessen in der Architektur-Community vertreten oder sich einfach mit Entwicklern anderer Teams austauschen.
Zusammenfassend lässt sich also festhalten, dass nicht ganz so viel Zeit für die reine Softwareentwicklung besteht. Mir persönlich gefällt diese Mischung aus Entwicklung und Austausch in Meetings allerdings sehr gut.
Neben den üblichen Hard Skills wie z.B. Programmiersprachen etc. solltet ihr als Entwickler unbedingt Soft Skills mitbringen. In einem agilen Team solltet ihr einfach teamfähig und flexibel sein, um auf schnelle Änderungen aktiv und konstruktiv reagieren zu können. Ansonsten bringen euch Soft Skills wie Kommunikationsstärke und Kritik- und Konfliktfähigkeit gleichermaßen in Meetings weiter. Ihr müsst die Ergebnisse des Sprints selbstbewusst vor den Stakeholdern präsentieren, auf deren Nachfragen eingehen und euer Vorgehen erläutern können.
4+1 Zeit – Abseits des Projektgeschäfts
4+1 Zeit bedeutet für uns als angestellte Entwickler bei 19bytes, dass wir ca. 20% unserer Arbeitszeit für Fortbildungen, Konferenzen oder – so wie ich jetzt gerade – für Blogartikel verwenden können.
Ich spare mir persönlich meistens etwas 4+1 Zeit an, um mich dann ein paar Tage mit einer neuen Technologie auseinandersetzen oder eine Konferenz besuchen zu können. Ihr könnt eure 4+1 Zeit natürlich auch einfach wöchentlich an einem festen Tag einbauen oder täglich für 1-2 Stunden. Insofern könnt ihr die Zeit flexibel gestalten und mit eurem Projekt und dem Team abstimmen.
Habe ich bei der Projektauswahl Mitbestimmungsrecht? Wie werde ich in Projekte vermittelt? Weisungsbefugnis beim Urlaub?
Ganz klar: Ja, du hast ein Mitbestimmungsrecht bei der Projektauswahl! Bei uns wirst du nicht einfach ins erstbeste Projekt gesteckt. Wir legen Wert auf deine Präferenzen in der Softwareentwicklung und versuchen diese so gut es geht zu berücksichtigen. Wir wollen, dass dir das Projekt Spaß macht und die Arbeit mit uns gefällt.
Die Vermittlung eines Projekts kann unterschiedlich ablaufen. Es gibt zum Teil Direktverträge mit Kunden. Diese Art von Verträgen entsteht häufig, sobald man bereits länger für einen Kunden gearbeitet hat.
Des Weiteren kann man über Projektvermittler beim Kunden vorgestellt werden. Diese werden explizit von den Kunden beauftragt, um passende Kandidaten für die freie Projektstelle zu finden. Ist ein Headhunter also der Meinung, dass euer Profil zu der Stelle passt, findet meist ein erstes Gespräch mit dem Headhunter statt und danach ein Vorstellungsgespräch beim Kunden. Das Gespräch beim Kunden findet dann oft direkt mit den anderen Teammitgliedern des Projekts statt. So können die erforderlichen Skills und die Sympathie schnell überprüft werden. Hier habt ihr auch die Möglichkeit, das Team gut kennenzulernen und wichtige Fragen zu stellen, um für euch persönlich zu überprüfen, ob euch das Projekt und das Team zusagen. Diese Chance solltet ihr bei einem Gespräch immer nutzen!
Als Junior-Entwickler kann man zum Teil auch mit einem Kollegen von 19bytes in einem Projekt eingesetzt sein. Oft begleitet man das Projekt dann im sogenannten „Praktikantenstatus“ – ihr nehmt also an allen Scrum-Events teil, lernt das Projektteam kennen und bekommt eure ersten User Stories zugewiesen. Anfangs werden die User Stories oft im Pairing mit einem 19bytes Kollegen umgesetzt, dadurch habt ihr immer einen direkten Ansprechpartner.
Nach einigen Wochen entscheidet dann das Projektteam, ob ihr als Kandidat für das Team in Frage kommt. Damit habt ihr euch die Einarbeitungszeit gespart, dem Team eure Skills gezeigt und im Optimalfall resultiert ein Vertrag und ihr werdet Teil des externen Projektteams.
Wie lange dauern Projekte bzw. laufen die Verträge?
Diese Frage ist schwierig allgemein zu beantworten. In der Regel sind die Projektaufträge häufig für drei, selten bis sechs Monate gültig, danach wird mit dem Kunden oder Vermittler neu verhandelt. Die meisten Projekte dauern aber deutlich länger, weshalb die Beauftragung in der Regel auch verlängert wird.
Die Kündigungsfrist für eine Beauftragung liegt in den meisten Fällen bei zwei bis vier Wochen. Dadurch besteht die Möglichkeit sich schnell ein anderes Projekt zu suchen, falls das Projekt überhaupt nicht den Beschreibungen entsprechen sollte oder es Konflikte im Team gibt. Mir persönlich ist bisher kein Fall bekannt, in dem wir oder der Kunde von der Kündigungsfrist Gebrauch machen mussten. Zumeist sind die Projekte sorgfältig ausgewählt und man erkennt im Erstgespräch beim Kunden, ob das Team zu einem passen würde oder eher nicht.
Muss ich ständig beim Kunden vor Ort sein? Wie viel Remotearbeit steht mir zu?
Nein, wir nehmen aktuell keine Projekte mehr an, bei denen wir vier oder fünf Tage vor Ort beim Kunden sind. Die Corona-Pandemie hat gezeigt, wie Scrum-Teams weiterhin erfolgreich Increments pro Sprints geliefert haben. Gerade für uns Entwickler und IT-Teams ist eine Anwesenheit nicht mehr zwingend notwendig. Bei unseren aktuellen Projekten liegt die vor-Ort-Quote bei 0-5%, also bei maximal einmal pro Monat.
In den meisten Fällen fahren wir also nur gelegentlich zum Kunden, was aber auch von der jeweiligen Entfernung abhängt.
In meinem aktuellen Projektteam versuchen wir uns mit einem Teil des Teams zumindest einmal pro Sprint vor Ort zu treffen. Diese Treffen finden aber auch nur statt, wenn es wirklich sinnvoll ist, sich in Persona zu sehen und die Themen eine Relevanz für den persönlichen Austausch mitbringen.
Wie viel Remotearbeit dir zusteht, lässt sich nicht genau beantworten. Wir von 19bytes schreiben dir jedenfalls keine Anwesenheitszeit im Büro vor, sondern überlassen es dir selbst. Inwiefern du beim Kunden vor Ort sein musst, hängt vom spezifischen Projekt ab. Der Großteil der 19bytes Kollegen ist allerdings so gut wie nie vor Ort, nur in seltenen Fällen. Wir haben auch einige Kollegen, die selbst nach zwei Jahren noch nicht ein einziges mal beim Kunden vor Ort waren.
Noch weitere Fragen? Kommentiere den Beitrag gerne oder kontaktiere uns direkt.
Falls du dir jetzt eine Tätigkeit als Software Engineer oder DevOps Engineer bei 19bytes vorstellen kannst, findest du die aktuellen Stellenausschreibungen hier https://19bytes.de/karriere/
