IT-Berufe-Podcast

Über seine Arbeit als IT-Freelancer erzählt Christian Dröge in der einhundertsiebzigsten Episode des IT-Berufe-Podcasts.

TL;DR

Ich habe mit Christian Dröge darüber gesprochen, wie du als IT-Freelancer:in arbeitest und eigene Projekte findest. Seine Arbeit verbindet Fachbereiche mit der IT und umfasst Anforderungen, Geschäftsprozesse sowie Datenbanken, wodurch sich viele Bezüge zur Ausbildung als Fachinformatiker:in ergeben. Beim Stundensatz zählen neben dem Marktpreis auch deine Kosten und die Zeit, die du abrechnen kannst, während du für deine Altersvorsorge selbst verantwortlich bist. Für den Einstieg empfiehlt Christian, die Nachfrage nach deinem Angebot zunächst nebenberuflich oder mit einem ersten gesicherten Projekt zu prüfen.

Kapitelmarken

[00:00:00] Einstieg ins Thema IT-Freelancing

[00:02:20] Christian Dröge und sein Weg in die IT

[00:06:21] Programmieren und die Rolle zwischen Fachbereich und IT

[00:10:18] Business Analyse und Requirements Engineering

[00:12:15] UML, BPMN und Werkzeuge für Diagramme

[00:13:46] Datenbanken, Schnittstellen und Software auswählen

[00:16:45] Prototypen bauen und Daten strukturieren

[00:18:05] Bezüge zur IT-Ausbildung

[00:18:47] Arbeitsalltag und langfristige Projekte

[00:23:41] Christians Einstieg in die Selbstständigkeit

[00:27:25] Aufträge in anderen Regionen und Branchen

[00:29:03] Arbeit während der Finanzkrise

[00:30:34] Stundensatz festlegen und den Markt einschätzen

[00:33:54] Kosten, Ausfallzeiten und Altersvorsorge einplanen

[00:37:35] Buchhaltung und eigene Website

[00:41:29] Arbeitszeit und Weiterlernen

[00:44:18] Methoden, Technologien und Branchenwissen

[00:46:53] Sich in neue Projekte einarbeiten

[00:50:27] Passende Software und langfristige Lösungen finden

[00:51:50] Fachliche Breite und spezialisiertes Wissen

[00:56:13] Kund:innen beraten und Lösungen selbst umsetzen

[00:58:05] Tipps für den Einstieg als Freelancer:in

[01:00:32] Technologietrends und Nachfrage beobachten

[01:02:34] Selbstständig bleiben und berufliche Perspektiven

[01:06:03] Buch zu Requirements Engineering

[01:08:18] Christian kontaktieren

[01:10:36] Shownotes und Abschluss

Die Arbeit als IT-Freelancer

Allgemeines zur Person

Wie ist dein Name?

Christian Dröge, 43 Jahre alt, aus Frankfurt. Ich bin seit 2007 Freelancer in der IT.

An welchen Projekten arbeitest du zur Zeit?

Als IT-Consultant bin ich zurzeit in einem Digitalisierungsprojekt bei einem internationalen Real Estate Asset Manager, der Immobilien-Fonds verwaltet.

Hier habe ich mit einem IT-Freelancer-Kollegen (Software Entwickler/Architekt) eine Art ERP (Enterprise Resource Planning) bzw. ein Portfolio Management System mit DWH (Data Warehouse) gebaut. Ziel des Projekts ist es, von der Excel-Welt via Datenbankanwendung zur Web-Anwendung zu kommen.

Technisch habe ich hier mit Microsoft SQL Server, Access und Excel also mit T-SQL und VBA viel zu tun. Mein Kollege programmiert sehr viel mit C# und PowerShell für Schnittstellen, um u.a. CSV- und XML-Dateien zu importieren und exportieren.

Ich beginne bald noch ein weiteres Projekt als Requirements Engineer bzw. Anforderungsmanager im öffentlichen Sektor, wo ich es mit Oracle-Datenbank, XML, BPMN und UML zu tun habe. Das bestehende Projekt bzw. System betreue ich dann ein bisschen nebenbei.

Wie bist du zur Informatik gekommen?

Über das Computerspielen hatte ich schon in der Kindheit mit C64, Amiga 500 und PC immer schon viel Spaß mit dem Computer. Ende der 90er kam noch das Internet dazu.

In den 90ger-Jahren habe ich ein Fachabitur Wirtschaft und eine Ausbildung zum Groß- und Außenhandelskaufmann gemacht. Ich wollte unbedingt etwas Kreatives studieren, weil ich gerne zeichne und mir Comics und Brettspiele ausdenke. Aber mein Wunsch Kommunikationsdesign hat nicht geklappt.

Irgendwann wusste ich, dass ich etwas Kreatives bzw. Technisches erschaffen können muss, um langfristig erfolgreich und unabhängig zu sein. Als Kaufmann braucht man ja jemanden, der ein Produkt bzw. Dienstleistung erschaffen kann, um es verkaufen zu können.

Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?

Ich habe ein FH-Diplom in Wirtschaftsinformatik.

Angefangen habe ich mit Medieninformatik, aber darunter hatte ich mir etwas anderes vorgestellt.

Vor paar Jahren habe ich auch an der Uni Bamberg Wirtschaftsinformatik studiert, um einen Master berufsbegleitend zu machen. Habe ich aber nach 3 Jahren abgebrochen, da zu aufwändig und zu wenig Mehrwert für einen IT-Freelancer wie mich.

Mit welcher/n Programmiersprache/n arbeitest du im Alltag?

Hauptsächlich VBA mit SQL.

Was ist deine Lieblingsprogrammiersprache und warum?

Mir gefällt aus dem Studium Java und im Job bzw. Fortbildung C#, da einfacher als C++ (Studium). Aber ich kann aktuell nur noch VBA gut, da ich direkt bei den Fachabteilungen arbeite und die haben nur Microsoft Office und somit VBA im Einsatz.

IT-Freelancing

Welche Dienstleistungen bietest du genau an?

IT-Beratung mit Schwerpunkt Business Analyse und Requirements Engineering für Datenmanagementlösungen also Datenbanken und Business Intelligence.

Vor Projekten berate ich die Kunden zu Business Cases oder Make-or-buy-Entscheidungen.

Ich berate auch dabei, welche Rollen für das Team benötigt werden. Und am Ende gibt es "Lessons Learned".

Im klassischen Wasserfallmodell erstelle ich z.B. Pflichtenhefte. Hier wird oft DOORS eingesetzt.

Methodiken, die ich einsetze: Pflichtenheft, UML (Aktivität, UseCase), BPMN (SwimLanes, Prozessmodellierung).

PowerPoint setze ich auch gerne zum "Malen" von Prozessen ein. Visio hat meist niemand, genau wie Microsoft Project. LucidCharts ist auch interessant für kleine Projekte.

Weiterer Schwerpunkt von mir: Datenbanken, Business Intelligence, Datenmodellierung, XML-Schnittstellen, relationale Datenbanken, Microsoft SQL Server/Oracle. Daten modellieren und für Fachbereich bereitstellen mit Excel/Access, PowerBI etc.

Bei "Make-or-buy" schaue ich, ob es Lösungen am Markt gibt ("best of breed"). Sonst bauen wir die selbst.

Prototyping ist dabei immer wichtig und macht auch viel Spaß.

Viele Kunden haben Daten noch in PDF-Dateien und Excel und sind noch längst nicht bei "Big Data" angekommen!

Wie sieht dein Alltag als Freelancer aus? 9-to-5 oder Überstunden ohne Ende?

Wenn die Familie versorgt ist, setze ich mich an den Computer und bearbeite meine E-Mails (erst die wichtigen des Freelancers, dann die der Kundenprojekte) oder fahre zum Kunden.

Arbeitest du wirklich "selbst" und "ständig"?

Ich arbeite in den Projekten selbst. Beim Drumherum (Büro, Papierkram, Buchhaltung, etc.) unterstützt mich meine Frau, die für mich seit 10 Jahren arbeitet.

Ständig arbeite ich nicht. Ich bin natürlich immer an Methoden, IT und Wirtschaft (also Prozessen und Management) interessiert. Ich arbeite nicht mehr als andere. 40 Stunden pro Woche.

Wann und warum hast du den Entschluss gefasst, dich selbstständig zu machen?

Während meines ersten Projekts als festangestellter IT-Berater. Ein Kollege hat mir gesagt, er mache sich jetzt selbstständig, und mir empfohlen, das auch zu tun.

Mein Ziel war, selbst über die Projekte entscheiden zu können und natürlich auch mehr zu verdienen.

Vorher war ich Praktikant und habe mitbekommen, dass Berater 1.000 EUR Tagessatz haben. Das hat mich schon beeindruckt.

Wie lange dauern deine Projekte?

Ich mache eher lange Projekte, also durchaus mehrere Jahre.

Oft gibt es auch Folgeprojekte, denn die Systeme haben eine lange Lebensdauer. Da kommen dann weitere Anforderungen dazu.

Wie entscheidest du dich zwischen konkurrierenden Projekten?

Das Projekt, welches zur meiner Rolle, meinen Skills und zu meiner Lebenssituation passt, nehme ich an. Also IT-Berater (Datenbanken), Remote, langfristig (> 6 Monate) und höchster Stundensatz ist am interessantesten.

Ich habe meist ein Hauptprojekt und ein Nebenprojekt in "Teilzeit".

Wie findest du deine Kunden/Projekte?

XING, LinkedIn, Freelancermap, Lyncronize, Gulp, oder Personalberater (z.B. Hays) kontaktieren mich.

Wie bist du in die Selbstständigkeit gestartet? Was war dein erstes Projekt?

Ein Kollege hat sich selbstständig gemacht und mich "inspiriert".

Ich hatte einen "Deal" mit meinem Arbeitgeber, dass ich 25% vom Tagessatz abgebe.

2007 lag ich bei 67,50 EUR pro Stunde "all in". Das war viel Geld für mich!

Als IT-Freelancer konnte ich innerhalb eines Monats mein Einkommen im Vergleich zu meinem Gehalt als festangestellter IT-Berater verdreifachen.

Festangestellt hatte ich zwar eine gewisse "Sicherheit", aber ich habe es einfach ausprobiert und bin das Risiko eingegangen.

Seit 2007 war ich nicht einen Tag ohne Projekt!

Ist der Freelancer krisenfester als eine Festanstellung?

IT wird immer gebraucht, aber es kommt auch auf das Unternehmen an.

Ich habe als Junior IT-Consultant im Jahr 2008 schon einmal über 20.000 EUR Umsatz im Monat durch viele Überstunden verdient. Das ist als Festangestellter nicht so einfach möglich.

Was sind aus deiner Sicht die Vor- und Nachteile des Freelancings ggü. einer Festanstellung?

Mehr Freiheit (wo und was) und (viel) mehr Geld als Fachkraft.

Kein Geld bei Urlaub, Krankheit, wenn kein Projekt läuft und während Fortbildungen.

Wenn man oft krank ist, ist der Job Freelancer nichts! Und viel Urlaub ist meist auch nicht drin, denn in der Zeit verdient man nichts.

Arbeitest du eher remote oder vor Ort bei Kunden?

Vor Corona vor Ort. Jetzt ca. 80% Remote.

Wie hast du deinen (ersten) Stundensatz bestimmt?

Deal mit Arbeitgeber: Stundensatz - 25%

Ansonsten Durchschnitt IT-Freelancer-Marktpreis (Projektmanager, Berater, Entwickler, Admin, Tester, Support), immer mehr als jetzt und nicht weniger als aktuell, weniger nur, wenn es andere Vorteile gibt, wie z.B. 100% Remote.

95 EUR ist aktuell der Marktdurchschnitt, geht aber 2021 wieder runter (ca. 10%) wegen 100% Remote-Arbeit.

Ein hoher Stundensatz heißt aber auch oft: "Den müssen wir schnell wieder loswerden!" Daher eher am Markt orientieren....

Um die Frage, wie oder woran du ein gutes bzw. schlechtes Ausbildungsunternehmen erkennst, geht es in der einhundertneunundsechzigsten Episode des IT-Berufe-Podcasts.

TL;DR

Aus meinen Erfahrungen in IHK-Prüfungen habe ich Hinweise zusammengestellt, mit denen du als IT-Azubi die Qualität deiner Ausbildung einschätzen kannst. Ein betrieblicher Ausbildungsplan und fachlich geeignete Ausbilder:innen gehören ebenso dazu wie Zeit zum Lernen und regelmäßiges Feedback. Achte schon beim Bewerben darauf, wie das Unternehmen dich begleitet, und prüfe während deiner Ausbildung, ob du fachlich weiterkommst. Bei anhaltenden Problemen empfehle ich dir, zuerst mit deinem/deiner Ausbilder:in zu sprechen und bei Bedarf die IHK einzubeziehen; dein wahrheitsgemäß geführtes Berichtsheft dokumentiert dabei, welche Aufgaben du übernommen hast.

Kapitelmarken

[00:00:00] Thema: Die Qualität eines Ausbildungsbetriebs erkennen

[00:01:15] Während der Probezeit auf Warnsignale achten

[00:02:03] Hinweise im Zusammenhang bewerten

[00:03:36] Im Bewerbungsgespräch eigene Fragen stellen

[00:05:08] Gemeinsame Büroaufgaben und berufsfremde Tätigkeiten

[00:06:35] Erfahrungen aus IHK-Prüfungen und frühzeitig handeln

[00:08:16] Veränderungen im Betrieb und laufend auf die Ausbildung achten

[00:09:12] Hinweise auf den Einsatz als billige Arbeitskraft

[00:09:56] Eigenverantwortung und selbstständiges Lernen

[00:13:02] Probleme zuerst mit dem/der Ausbilder:in besprechen

[00:14:45] Weitere Ansprechpersonen im Betrieb und bei der IHK

[00:16:08] Das Berichtsheft als Nachweis

[00:17:17] Den Ausbildungsbetrieb wechseln

[00:18:34] Probleme direkt ansprechen und schwierige Phasen einordnen

[00:19:59] Gesetzliche Anforderungen und Missstände melden

[00:21:41] Pflichten des Ausbildungsbetriebs nach § 14 BBiG

[00:25:04] Externe Angebote und das Berichtsheft während der Arbeitszeit

[00:26:07] Aufgaben, die dem Ausbildungszweck dienen

[00:27:03] Das Verhältnis zwischen Azubis und Fachkräften

[00:27:53] Eignung und Qualifikation von Ausbilder:innen

[00:32:29] Bewerbung: Welche Vorkenntnisse werden vorausgesetzt?

[00:36:32] Nach dem betrieblichen Ausbildungsplan fragen

[00:38:16] Zuständige Ausbilder:innen und ihre Qualifikation klären

[00:39:37] Bisherige Prüfungsergebnisse und Übernahmen

[00:41:09] Ausbildungsvergütung und Mindestvergütung

[00:44:43] Lernzielkontrollen und Prüfungsvorbereitung

[00:47:00] Azubi-Projekte über den eigenen Fachbereich hinaus

[00:48:38] Prüfen, ob genügend Fachkräfte für die Betreuung da sind

[00:50:15] Probezeit: Umgangston und persönliche Betreuung

[00:51:47] Wiederkehrende einfache Arbeit und Leerlauf

[00:53:49] Zeit zum Lernen und fachliche Antworten auf Fragen

[00:55:45] Feedback und ein erkennbarer Ablauf der Ausbildung

[00:57:42] Ausbildungsmittel und berufsfremde Aufgaben

[00:58:58] Überstunden und ungewöhnliche Arbeitszeiten

[01:01:09] Die Vergütung pünktlich und vollständig erhalten

[01:02:15] Berufsschule und Arbeit vor oder nach dem Unterricht

[01:04:32] Berichtsheft prüfen lassen und falsche Einträge vermeiden

[01:07:06] Hinweise einordnen und nächste Schritte abwägen

[01:07:53] Umsetzungshilfen des BIBB und weitere Quellen

[01:10:18] Rückmeldungen und Podcast-Bewertungen

[01:11:12] Newsletter passend zum Ausbildungsjahr

Inhalt

Viele angehende Azubis fragen sich (und auch mich), woran sie erkennen, ob sie sich bei einem "guten" Ausbildungsunternehmen bewerben. Und auch Azubis, die schon eine Ausbildungsstelle haben, sollten in den ersten Monaten der Ausbildung - also in der Probezeit - genau prüfen, ob sie wirklich in den nächsten drei Jahren in ihrem Unternehmen vernünftig ausgebildet werden. Worauf man dabei achten kann, erzähle ich heute im Podcast.

Vorweg: Meiner Erfahrung nach bildet der Großteil der Ausbildungsunternehmen vernünftig aus! Trotzdem gibt es auch immer wieder schwarze Schafe, die Azubis nicht ausbilden, sondern ausbeuten. Und darunter leiden dann nicht die Unternehmen, sondern die Azubis, die oft insb. bei der Prüfungsvobereitung alleine gelassen werden und dementsprechend schlechte Prüfungsergebnisse abliefern.

Die möglichen Anzeichen für eine schlechte Ausbildung auf der folgenden Liste sind erstmal nur Indizien! Wenn einzelne Dinge davon ab und an mal in deinem Unternehmen vorkommen, muss das nichts heißen. Unter gewissen Umständen sind sogar dauerhafte "Probleme" tragbar, wenn drumherum alles andere passt. Urteile also bitte nicht vorschnell, nur weil du hier ein bestimmtes Stichwort gelesen hast!

Und zu einer Ausbildung gehören immer zwei Seiten! Auch du musst deinen Teil zu einer guten Ausbildung beitragen und kannst nicht erwarten, alles auf dem Silbertablett serviert zu bekommen. Schließlich sollst du nach der Ausbildung selbstständig handlungsfähig sein und deinen Job machen können.

Was kannst du tun, wenn du nicht richtig ausgebildet wirst?

Suche das Gespräch mit deinem/deiner Ausbilder:in/Chef:in.

Geh mit deinem Ausbildungsnachweis zur IHK (Ausbildungsberater:in).

Wechsle den Ausbildungsbetrieb (ggfs. mit Hilfe der IHK).

Immer gilt: Suche bei Problemen in der Ausbildung immer zuerst das Gespräch mit deinem/deiner Ausbilder:in und nimm nicht "hinter ihrem Rücken" Kontakt zur IHK auf. Vielleicht gibt es eine gute Erklärung für die aktuelle Situation und sie dauert nicht länger an. Und alle Menschen - auch du und ich - machen mal Fehler, also erwarte nicht die "perfekte" Ausbildung. Das ist unrealistisch.

Formelle Anforderungen an Ausbildungsunternehmen und Ausbilder:innen

Ausbildende haben

dafür zu sorgen, dass den Auszubildenden die berufliche Handlungsfähigkeit vermittelt wird, die zum Erreichen des Ausbildungsziels erforderlich ist, und die Berufsausbildung in einer durch ihren Zweck gebotenen Form planmäßig, zeitlich und sachlich gegliedert so durchzuführen, dass das Ausbildungsziel in der vorgesehenen Ausbildungszeit erreicht werden kann,

selbst auszubilden oder einen Ausbilder oder eine Ausbilderin ausdrücklich damit zu beauftragen,

Auszubildenden kostenlos die Ausbildungsmittel, insbesondere Werkzeuge, Werkstoffe und Fachliteratur zur Verfügung zu stellen, die zur Berufsausbildung und zum Ablegen von Zwischen- und Abschlussprüfungen, auch soweit solche nach Beendigung des Berufsausbildungsverhältnisses stattfinden, erforderlich sind,

Auszubildende zum Besuch der Berufsschule anzuhalten,

dafür zu sorgen, dass Auszubildende charakterlich gefördert sowie sittlich und körperlich nicht gefährdet werden.

(BBiG, §14, Absatz 1)

Die Punkte 1 bis 3 sagen im Prinzip aus, dass du vernünftig ausgebildet werden musst. Du sollst nach der Ausbildung in der Lage sein, deinen Beruf selbstständig auszuüben. Diese Aufgabe kann dein Unternehmen auch nicht delegieren, sondern muss sich selbst darum kümmern. Außerdem muss dein Unternehmen dich auch finanziell unterstützen, wenn du Ausbildungsmittel (in der IT z.B. Fachbücher) benötigst.

Die Ausbildung in Deutschland heißt nicht umsonst duale Ausbildung, denn ein wichtiger Teil dabei ist die Berufsschule. Klar, dass du am Unterricht teilnehmen können musst, oder?

Der letzte Punkt überrascht dich vielleicht, ist aber auch eine wichtige Aufgabe des Ausbildungsunternehmens. Es gibt ja durchaus auch Azubis, die mit 16 oder 17 Jahren in die Ausbildung starten. Da kann man wohl noch nicht von einem "gefestigten Charakter" sprechen. ;-)

Als Ergänzung zu 2.:

Eine Ausbildungsstätte, in der die erforderlichen beruflichen Fertigkeiten, Kenntnisse und Fähigkeiten nicht im vollen Umfang vermittelt werden können, gilt als geeignet, wenn diese durch Ausbildungsmaßnahmen außerhalb der Ausbildungsstätte vermittelt werden.

BBiG, §27, Absatz 2

Ausbildende haben Auszubildende zum Führen der Ausbildungsnachweise nach § 13 Satz 2 Nummer 7 anzuhalten und diese regelmäßig durchzusehen. Den Auszubildenden ist Gelegenheit zu geben, den Ausbildungsnachweis am Arbeitsplatz zu führen.

BBiG, §14, Absatz 2

Das sollte für sich selbst sprechen.

Auszubildenden dürfen nur Aufgaben übertragen werden, die dem Ausbildungszweck dienen und ihren körperlichen Kräften angemessen sind.

BBiG, §14, Absatz 3

"Azubi-Aufgaben" (Kaffee kochen, Spülmaschine ausräumen etc.) dürfen nicht die Regel sein.

Auszubildende dürfen nur eingestellt und ausgebildet werden, wenn die Zahl der Auszubildenden in einem angemessenen Verhältnis zur Zahl der Ausbildungsplätze oder zur Zahl der beschäftigten Fachkräfte steht, es sei denn, dass anderenfalls die Berufsausbildung nicht gefährdet wird.

BBiG, §27, Absatz 1, Satz 2

Mehr Azubis als Mitarbeiter:innen sind ein schlechtes Zeichen.

Auszubildende darf nur einstellen, wer persönlich geeignet ist. Auszubildende darf nur ausbilden, wer persönlich und fachlich geeignet ist.

BBiG, §28, Absatz 1

Ausbilder:innen haben eine wichtige Aufgabe, für die sie entsprechend qualifiziert sein müssen, z.B. weil sie selbst eine Ausbildung oder ein Hochschulstudium in diesem Beruf absolviert haben. Es werden auch bestimmte pädagogische Anforderungen gestellt. Diese werden durch eine Ausbildung nach AEVO erworben. Außerdem sollte der/die Ausbilder:in eine "angemessene Zeit" im Beruf praktisch gearbeitet haben. Wenn der gerade fertige Azubi direkt zum/zur Ausbilder:in wird, ist das also etwas seltsam.

Fachlich geeignet ist, wer die beruflichen sowie die berufs- und arbeitspädagogischen Fertigkeiten, Kenntnisse und Fähigkeiten besitzt, die für die Vermittlung der Ausbildungsinhalte erforderlich sind.

BBiG, §30, Absatz 1

Prüfung bereits im Bewerbungsprozess

Wird erwartet, dass ich Ausbildungsinhalte schon vor der Ausbildung kann?

Gibt es einen betrieblichen Ausbildungsplan?

Gibt es eine:n "richtige:n" Ausbilder:in mit Ausbilderschein (AEVO)?

Welche Prüfungsleistungen haben die bisherigen Azubis erreicht?

Wurden die bisherigen Azubis übernommen?

Liegt die Höhe der Azubivergütung (deutlich) über dem Mindestlohn?

Wie werden in der Ausbildung Lernerfolgskontrollen durchgeführt

Um die Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung (nach der Neuordnung der IT-Berufe 2020) geht es in der einhundertachtundsechzigsten Episode des IT-Berufe-Podcasts.

TL;DR

Mit 20 Prozent deiner Abschlussnote zählt Teil 1 der gestreckten Abschlussprüfung schon nach etwa 18 Monaten Ausbildung. In der 90-minütigen schriftlichen Prüfung zum Einrichten eines IT-gestützten Arbeitsplatzes werden die gemeinsamen Grundlagen aller IT-Berufe geprüft, darunter Projektmanagement und kaufmännische Themen sowie Programmiergrundlagen. Ich empfehle dir, früh und regelmäßig mit passenden alten Prüfungsaufgaben und Fachbüchern zu lernen, wobei dir die Berufsverordnung und die Umsetzungshilfen zeigen, welche Inhalte dazugehören. Wenn du die Methoden auch in eigenen Projekten ausprobierst, kannst du sie später im Beruf anwenden.

Kapitelmarken

[00:00:01] Einstieg zur schriftlichen IHK-Prüfung

[00:00:37] Neuordnung und erste Termine für Teil 1

[00:04:22] Ablauf, Dauer und Zulassung zur Prüfung

[00:06:36] Gewichtung und Bedingungen zum Bestehen

[00:10:12] Einfluss von Teil 1 auf deine Abschlussnote

[00:11:19] Früh anfangen und die Themen kennenlernen

[00:14:19] Programmiergrundlagen und Umfang des Prüfungsstoffs

[00:16:59] Fachliche Inhalte und Prüfungsvorbereitung parallel einplanen

[00:20:17] Mit alten IHK-Prüfungen lernen

[00:22:02] Passende Aufgaben aus früheren Prüfungen auswählen

[00:23:26] Methoden in eigenen Projekten ausprobieren

[00:24:38] Deinen betrieblichen Ausbildungsplan prüfen

[00:27:24] Den Prüfungsstoff durch Fachbücher ergänzen

[00:29:07] Regelmäßig lernen und Wissen langfristig behalten

[00:32:25] Prüfungsinhalte und gesetzliche Grundlagen

[00:36:16] Aufgaben rund um einen IT-gestützten Arbeitsplatz

[00:38:51] Projektmanagement und konkrete Beispiele aus den Umsetzungshilfen

[00:43:06] Weitere Vorgaben zu Arbeitsaufgaben und Aufträgen

[00:44:08] Newsletter mit Hinweisen für dein Ausbildungsjahr

[00:45:09] Offizieller Prüfungskatalog

[00:45:51] Umsetzungshilfen für die IT-Berufe

[00:46:50] Westermann-Schulbuch und Arbeitsbuch für die Lernfelder 1 bis 5

[00:49:51] Übungsbuch "Prüfungsvorbereitung aktuell"

[00:51:24] IT-Handbuch von Westermann als Nachschlagewerk

[00:53:37] IT-Handbuch von Sascha Kersken

[00:55:56] Themenlisten und Literaturempfehlungen auf der Website

Inhalt

Art der Prüfung

Teil 1 der gestreckten Abschlussprüfung der IT-Berufe ist eine schriftliche Prüfung von 90 Minuten zum Themenbereich "Einrichten eines IT-gestützten Arbeitsplatzes". Diese Prüfung ist für alle IT-Berufe identisch, da die gemeinsamen Qualifikationen geprüft werden, die in den ersten 18 Monaten der Ausbildung vermittelt werden müssen. Zulassungsvoraussetzung ist u.a. das ordnungsgemäße Führen des Ausbildungsnachweises.

Gewichtung des Prüfungsergebnisses

Der erste Teil der gestreckten Abschlussprüfung zählt - anders als die ehemalige Zwischenprüfung - voll zur Abschlussnote. Und ihr Anteil liegt sogar bei 20%. Das heißt, ein Fünftel der Abschlussnote wird bereits durch diese Prüfung festgelegt. Daher sollte man - weder als Azubi noch als Ausbilder:in - diesen Prüfungsteil unterschätzen, sondern sich gut darauf vorbereiten.

Die Abschlussprüfung ist bestanden, wenn die Prüfungsleistungen – auch unter Berücksichtigung einer mündlichen Ergänzungsprüfung nach § 17 – wie folgt bewertet worden sind:

im Gesamtergebnis von Teil 1 und Teil 2 mit mindestens "ausreichend",

im Ergebnis von Teil 2 mit mindestens "ausreichend",

in mindestens drei Prüfungsbereichen von Teil 2 mit mindestens "ausreichend" und

in keinem Prüfungsbereich von Teil 2 mit "ungenügend".

(FIAusbV, §16, Absatz 2)

Demnach kann man seinen Abschluss auch schaffen, wenn man in Teil 1 der Prüfung durchfällt, da lediglich das Gesamtergebnis "ausreichend" sein muss und man eine schlechte Note in Teil 1 mit einer guten in Teil 2 "ausgleichen" kann. Trotzdem ist schon ab einem Ergebnis von 55% oder schlechter in Teil 1 rein rechnerisch keine "sehr gute" Gesamtnote mehr möglich! Rechne es dir gerne selbst nach: Notenrechner für die neue IT-Abschlussprüfung.

Allgemeine Prüfungsinhalte von Teil 1

Aufgrund der Wichtigkeit der Prüfung für die Abschlussnote empfehle ich, so früh wie möglich mit der Prüfungsvorbereitung anzufangen. Leider sind die Inhalte von Teil 1 aber wenig fachspezifisch und/oder technisch, sondern eher "allgemeiner" Natur (z.B. Projektmanagement, Abrechnungen, Angebotsvergleich, Schulungen, Präsentationen, Datenschutz). Ein wenig Technik wird eigentlich nur durch die Grundlagen der Programmierung integriert. Insbesondere - meiner Meinung nach - grundlegende IT-Themen wie Netzwerke, VPN, RAID oder Backups sollen zwar laut Ausbildungsrahmenplan bereits im 1. Ausbildungsjahr vermittelt werden, sind aber nicht prüfungsrelevant. Nur die ersten sieben Absätze der "Fertigkeiten, Kenntnisse und Fähigkeiten der Berufsbildpositionen" werden in Teil 1 der Prüfung abgefragt.

Teil 1 findet im vierten Ausbildungshalbjahr statt, Teil 2 am Ende der Berufsausbildung.

(FIAusbV, §7, Absatz 2)

Das heißt, dass die IT-Azubis den ersten Teil ihrer Ausbildung fast gar nicht mit den vermutlich für sie spannenderen Themen ihres Berufs oder ihrer Fachrichtung verbringen (z.B. Netzwerke beim FISI oder Machine Learning beim FIDP), was zu Frustration führen könnte. Ein:e Anwendungsentwickler:in, der/die im ersten Ausbildungsjahr nur Angebote einholt (überspitzt dargestellt), hat sich das sicherlich anders vorgestellt (kein Coooooode!). Und als Ausbilder:in bekommt man auch erst spät eine Einschätzung über die Eignung der Azubis für die eigentlich Kernthemen des Berufs. Daher schlage ich vor, zu Beginn der Ausbildung die Probezeit für diese Kernthemen zu nutzen und erst danach mit der parallelen Vermittlung der unten genannten Inhalte zu beginnen. Dann haben die Azubis noch gut ein Jahr Zeit, sich auf die Prüfung vorzubereiten und lernen trotzdem schon die für sie interessanten Inhalte des Berufs (z.B. Programmieren oder Netzwerkadministration).

Strategie zur Vorbereitung

Meine empfohlende Vorgehensweise zur Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung sieht wie folgt aus.

Alte Prüfungen durchgehen!

Solange es noch keine bzw. wenige alte Prüfungen gibt (bis ca. 2023) mit alten IHK-Abschlussprüfungen und Zwischenprüfungen lernen.

Dabei insbesondere die Aufgaben bearbeiten, die den Inhalten der neuen Prüfung zuzuordnen sind.

Die erste Prüfung Teil 1 wird im Herbst 2021 stattfinden (für Verkürzer).

Echte Projekte in der Praxis umsetzen und dabei die genannten Methodiken anwenden.

Die Reihenfolge und zeitliche Durchführung hängt vom gewählten Beruf und dem Unternehmen ab. Hier gibt es keine allgemeingültige Empfehlung oder Vorgabe.

Mit Hilfe von (Schul-)Büchern und Beispielaufgaben gezielt Inhalte vertiefen, die vielleicht nicht in der Praxis vermittelt werden (können).

Für die Prüfungsinhalte von Teil 1 sind inzwischen einige (gute) Bücher verfügbar und auch einige "Standardwerke" können in Teilen integriert werden.

Regelmäßig üben (mit Feedback durch Ausbilder:in) und kein "Bulimie-Lernen" kurz vor der Prüfung.

Azubis und Ausbilder:innen müssen sich diese Zeit auch reservieren (z.B. 2 von 5 Tagen Lernen/Prüfen, Rest Praxis).

Konkrete Prüfungsinhalte von Teil 1

Die Paragraphen, die für Teil 1 der gestreckten Abschlussprüfung relevant sind, können jeder Berufsverordnung der neuen IT-Berufe entnommen werden, da sie für alle IT-Berufe identisch sind. Beispiel: FIAusbV: Verordnung über die Berufsausbildung zum Fachinformatiker und zur Fachinformatikerin.

Teil 1 der Abschlussprüfung erstreckt sich auf

die im Ausbildungsrahmenplan für die ersten 18 Monate genannten Fertigkeiten, Kenntnisse und Fähigkeiten der Berufsbildpositionen nach § 4 Absatz 2 Nummer 1 bis 7 sowie

den im Berufsschulunterricht zu vermittelnden Lehrstoff, soweit er den im Ausbildungsrahmenplan genannten Fertigkeiten, Kenntnissen und Fähigkeiten entspricht.

(FIAusbV, §8)

Zusammengefasst ergeben sich folgende Prüfungsbereiche.

Im Prüfungsbereich Einrichten eines IT-gestützten Arbeitsplatzes hat der Prüfling nachzuweisen, dass er in der Lage ist,

Kundenbedarfe zielgruppengerecht zu ermitteln,

Hard- und Software auszuwählen und ihre Beschaffung einzuleiten,

einen IT-Arbeitsplatz zu konfigurieren und zu testen und dabei die Bestimmungen und die betrieblichen Vorgaben zum Datenschutz, zur IT-Sicherheit und zur Qualitätssicherung einzuhalten,

Kunden und Kundinnen in die Nutzung des Arbeitsplatzes einzuweisen und

die Leistungserbringung zu kontrollieren und zu protokollieren.

(FIAusbV, §9, Absatz 2)

Die den relativ allgemein und eher abstrakt gehaltenen Paragraphen zugeordneten konkreten Inhalte der folgenden Liste stammen aus den Umsetzungshilfen für Fachinformatiker/Fachinformatikerin des BIBB*. Die Lektüre der Umsetzungshilfen kann ich allen IT-Ausbilder:innen unbedingt empfehlen!

*

1 Planen, Vorbereiten und Durchführen von Arbeitsaufgaben in Abstimmung mit den kundenspezifischen Geschäfts- und Leistungsprozessen

Mein Vorschlag: Konkretes Projekt "von vorne bis hinten" umsetzen und parallel die genannten Methoden anwenden.

1a: Grundsätze und Methoden des Projektmanagements anwenden

Initiieren, Planen, Steuern, Kontrollieren und Abschließen von Projekten nach aktuell gängigen Projektmanagementstandards

Anwendung von Methoden, Hilfsmitteln, Techniken und Kompetenzen in einem Projekt, z.B.:

Projektplan

Meilensteine

Risikoanalyse

Standards und Normen

Projektmanagementsysteme

Basiskenntnisse des Veränderungsmanagements

Unterscheiden verschiedener Projektmanagementmethoden und Vorgehensmodelle, z.B.:

agiles Projektmanagement

V-Modell

Spiralmodell

Wasserfallmodell

Konkrete Literaturempfehlungen

Prüfungsvorbereitung aktuell Kapitel 2.1

Grundstufe Lernfelder 1-5 Kapitel 5.3

IT-Handbuch Kapitel 8

IT-Handbuch für Fachinformatiker:innen Kapitel 11 (Software-Enginee

Einen Rückblick auf Teil A (Projektarbeit) der IHK-Sommerprüfung 2021 gibt es in der einhundertsiebenundsechzigsten Episode des IT-Berufe-Podcasts.

TL;DR

Aus meinen Erfahrungen als Prüfer in der Sommerprüfung 2021 bekommst du Hinweise für dein Abschlussprojekt und die mündliche Prüfung. Wenn du die Vorgaben deiner IHK einhältst und deine eigene Arbeit anhand aussagekräftiger Ergebnisse zeigst, machst du dein Vorgehen nachvollziehbar. Für das Fachgespräch solltest du deine eingesetzten Technologien ebenso erklären können wie die wirtschaftlichen Grundlagen deines Projekts. Übe deine Antworten laut und beschreibe genau das, was du selbst gemacht hast.

Kapitelmarken

[00:00:01] Hinweise zum Fachgespräch

[00:00:36] Rückblick auf die Sommerprüfung 2021

[00:03:37] Ausweis und Unterlagen für den Prüfungstag

[00:06:01] Berichtsheft und genehmigter Projektstart

[00:07:20] Fehlende Ausbildungsinhalte im Betrieb

[00:08:46] Programmiersprachen und häufige Projektarchitekturen

[00:09:54] Umfang der Projektdokumentation

[00:11:09] Aussagekräftige Artefakte und lesbarer Quelltext

[00:13:50] Sinnvolle Auszüge und Dokumentation für Entwickler:innen

[00:17:21] Screenshots und Aktivitätsdiagramme

[00:19:14] Formelle Fehler in der Dokumentation

[00:23:40] Stundensatz und Projektkosten

[00:25:44] Unit-Tests mit fachlicher Aussage

[00:26:47] Fehler in Use-Case-Diagrammen

[00:29:58] Vorlagen und Inhalte passend zum Projekt auswählen

[00:33:57] Gelungene Beispiele aus Projektdokumentationen

[00:36:20] Ergebnisse aus Code-Reviews dokumentieren

[00:38:07] Präsentationszeit und fachliche Inhalte

[00:41:01] Architektur verständlich darstellen

[00:42:31] Gestaltung und Qualität der Folien

[00:45:12] CI/CD und glaubwürdige Projektbeschreibungen

[00:48:32] Vertraute Technologien für das Abschlussprojekt

[00:51:31] Standardisierte Diagramme und angemessene Sprache

[00:53:39] Gelungene Foliengestaltung und Testvideos

[00:55:42] Projektbezogene Fragen im Fachgespräch

[00:57:12] Eigenen Code und Sprachelemente erklären

[01:01:02] Fragen zu Entwicklungskonzepten und Werkzeugen

[01:01:53] Kanban verstehen und erklären

[01:02:47] Backup und RAID im Fachgespräch

[01:03:15] Ergebnisse der Codeanalyse kennen

[01:05:20] Respekt gegenüber dem Prüfungsausschuss

[01:07:20] Erfahrungen mit Prüfungsleistungen und Bewertung

[01:09:06] Häufige Fragen aus den Fachgesprächen 2021

[01:13:13] Antworten laut formulieren und üben

[01:14:54] Abschluss und weiterführende Links

Inhalt

Ich gehe mein Highlights und "Lowlights" der diesjährigen Sommerprüfungen durch. Trotz Corona liefen sie eigentlich ab wie immer, nur halt mit mehr Hygieneauflagen. Und die altbekannten Fehler in Dokumentation, Präsentation und Fachgespräch gab es auch immer noch! :-)

Allgemeines

Ein Prüfling hat seinen Personalausweis im Auto vergessen und brauchte 5min Verschnaufpause, nachdem er hektisch die Treppen hochgelaufen kam.

Ein Abschlussprojekt wurde scheinbar schon 2019 begonnen, wenn man dem Berichtsheft trauen kann.

Ein Berichtsheft wurde im Minutentakt (!) geschrieben.

Viele Sprachen waren vertreten: Java, C#, Go, RPG, TypeScript, JavaScript, Ruby.

Dominierende Technologie: SPA + Spring Boot im Backend.

Projektdokumentationen

Die kürzeste Dokumentation war 9,5 Seiten lang bei einer Vorgabe von 15 Seiten.

Lächerliche Inhalte, die wohl ausschließlich dem Füllen der Seiten dienten

Klassendiagramm aus einer einzigen Klasse

Screenshots der IntelliJ-Projektstruktur (drei Ordner)

Seitenweise langweiliger Quelltext auf schwarzem Hintergrund

"Auszug" aus einem Lastenheft mit lediglich drei Aufzählungspunkten

Generierte "Entwicklerdokumentation" ohne echte Kommentare

Standard-Dateispeicherdialog als Screenshot der Anwendung

Triviales Aktivitätsdiagramm mit einer einzigen Verzweigung

Formelle Fehler

Kein Deckblatt

Keine Überschriften über Verzeichnissen

Abkürzungsverzeichnis nicht sortiert

Flattersatz statt Blocksatz verwendet

Farbe der Überschriften nicht exakt gleicher Farbton wie im Logo des Unternehmens

Erklärung grausig schlecht eingescannt (dunkel und schief)

Inhaltliche/fachliche Fehler

Stundensatz 5 EUR (Azubivergütung / Arbeitszeit) ohne Arbeitgeberanteil zur Sozialversicherung, Gemeinkosten etc.

Unit-Tests, die gar nichts testen (kein assert() oder nur assertNotNull())

Use-Case-Diagramm war sehr (!) häufig fehlerhaft

"excludes", seltsame Pfeile, keine Vererbung genutzt

Als Ablaufdiagramm missbraucht

Unsinnige Inhalte, die Platz für wichtige Inhalte rauben

Für das Projekt unsinnige Kapitel (meiner Vorlage) ausgefüllt

Clean Architecture als Grafik im Anhang

Scrum, PHP und andere Grundlagen "erklärt"

Positive Inhalte

Vernünftig gegenderte Dokumentation

Entscheidungstabelle für komplexe Logik modelliert

Pandemie in Amortisation einberechnet (Software für Sporttourniere)

Ergebnisse des Code Review erklärt (z.B. Variablen umbenannt)

Projektpräsentationen

Die Präsentationen waren dieses Mal zwischen 11:10 Minuten und 16:15 Minuten lang.

Eine Präsentation bestand aus nur 7 Folien und der Prüfling hat trotzdem die Zeit überzogen.

Häufigstes Problem: keine oder zu wenige Artefakte gezeigt.

Die Architektur wurde fast nie gezeigt. Das ist gerade bei SPA + REST ein Problem.

Cliparts! Cliiiiiiiiparts!?

Trivialer Code (for-Schleife mit if-Statement) wurde minutenlang erklärt.

TDD/Scrum wurde erklärt.

Absolut unnötige Fehler

Rechtschreibfehler auf den Folien.

deutlich sichtbare kaputte Formatierung (Zeileumbrüche mitten im Wort)

Harte Pfade (C:\Users\Prüfling\...) im Test-Code, aber angeblich CI/CD benutzt.

Viele Prüflinge haben bei ihrer Projektarbeit "viele Erfahrungen gesammelt". Das heißt, dass viele von ihnen zum ersten Mal mit der eingesetzten Technologie gearbeitet haben.

Es gab eine (sinnvoll) gegenderte Präsentation.

Statt ein Use-Case-Diagramm zu zeigen, wurde eine Tabelle der Use-Cases mit Zuordnung zu Akteuren erstellt.

Ein Prüfling hat "lol" und "sounds fun" laut in der Präsentation gesagt. *cringe*

Positives

Foliengestaltung und insb. Agenda als "Browser-Tabs" dargestellt mit "Klick" auf Links im Burger-Menü.

Video eines Selenium-Testlaufs eingebaut.

Fachgespräche

Fast immer (!) waren die selbst verwendeten Technologien nicht bekannt!

JavaScript: let/var/const, TypeScript vs. JavaScript

Java: Lambdas, Generics, Typinferenz

C#: using, String-Interpolation, out/ref, bool?

Go: Coroutines

DDD, CI/CD, PWA

Jemand konnte tatsächlich Kanban erklären (Visualisierung, Pull-Prinzip, WIP-Limit).

Wir haben zweimal nach Backup-Verfahren gefragt.

Mehrere Prüflinge haben (angeblich) eine Codeanalyse gemacht, aber keine Ahnung, was dabei herausgekommen ist (z.B. Code Coverage, Smells).

Frage eines Prüflings an meinen Prüferkollegen: "Kennen Sie sich mit IT aus?"

Häufigste Fragen im Fachgespräch

Stundensatz, Gemeinkosten/BAB, Sozialversicherungen (fast in jedem Gespräch)

Typisierung der verwendeten Sprache(n) (fast immer bei Backend + Frontend)

REST, HTTP, Statuscodes, Methoden (insb. GET/POST) (fast in allen Web-/SPA-Projekten)

Kardinalitäten

Lambdas, Generische Klassen (insb. wenn sie verwendet wurden)

Lastenheft vs. Pflichtenheft

Datenschutz

Datenbank-Transaktionen

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Checkliste für die Projektpräsentation und das Fachgespräch der IHK-Prüfung

Zusammensetzung des Stundensatzes - Häufige Fragen im Fachgespräch

Erläuterung der Gehaltsabrechnung - Häufige Fragen im Fachgespräch

Datenbankmodellierung (Lernzielkontrolle zum Entity-Relationship-Modell)

Datenschutz vs. Datensicherheit vs. Datensicherung

Lasten- und Pflichtenheft in der Projektdokumentation

Weitere Infos zum FachgesprächDu suchst noch mehr Tipps rund um das Fachgespräch? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um das Fachgespräch.Kennst du schon meine Hörbücher zur Vorbereitung auf das Fachgespräch? Unter dasperfektefachgespraech.de kannst du sie herunterladen. In insg. über 10 Stunden gehe ich über 200 Fragen im Detail durch und gebe Tipps für die Beantwortung.Und wenn du dich für meinen Newsletter einträgst, bekommst du immer direkt alle Neuigkeiten von dieser Seite in dein Postfach geliefert.Jetzt anmelden!

Zusammenfassung

Hintergrund: Sommerprüfung 2021

Als ehrenamtlicher Prüfer habe ich in der Sommerprüfung 2021 Projektdokumentationen gelesen und mündliche Prüfungen begleitet. Aus diesen Erfahrungen gebe ich dir Hinweise für Teil A der damaligen Abschlussprüfung. Im Mittelpunkt stehen deine Projektarbeit und das anschließende Fachgespräch. Die Beispiele bleiben anonym und sollen dir helfen, wiederkehrende Fehler zu vermeiden.

Vor dem Prüfungstag

Lies deine Prüfungseinladung: Darin steht, welche Unterlagen du mitbringen musst. Packe sie am Vortag zusammen mit deinem Berichtsheft ein. Für den Lichtbildausweis kannst du beispielsweise deinen Personalausweis oder Reisepass bereitlegen. Bei einer Prüfung musste jemand den Ausweis erst aus dem Auto holen und kam anschließend außer Atem zurück.

Beginne dein Abschlussprojekt nach der Genehmigung: Mein Prüfungsausschuss schaut auch ins Berichtsheft. Hinweise auf einen früheren Projektstart können dazu führen, dass die Arbeit als Prüfungsleistung infrage steht. Dein Berichtsheft muss wahrheitsgemäß sein.

Halte die erlaubte Projektzeit ein: Für Fachinformatiker:innen Anwendungsentwicklung waren im damaligen Kontext 70 Stunden vorgesehen, nach der Neuordnung 80 Stunden. Für die anderen IT-Berufe wurden 35 beziehungsweise 40 Stunden genannt.

Achte auf die Inhalte deiner Ausbildung: In einem minutengenau geführten Berichtsheft mit rund 150 Seiten war fast jede Tätigkeit einem Kundenauftrag zugeordnet. Zeit zum Lernen für die Prüfung fehlte, während auch fachlich wenig passende Aufgaben auftauchten. Für mich zeigte dieser Fall, wie ein Ausbildungsbetrieb eine:n IT-Azubi als günstige Arbeitskraft einsetzen kann. Die Folgen zeigen sich später in der Prüfung.

Projektdokumentation: Umfang und eigene Arbeit

...

Um meine Ausbildungsbegleitung für die IT-Berufe per E-Mail geht es in der einhundertsechsundsechzigsten Episode des IT-Berufe-Podcasts.

TL;DR

Mit meiner kostenfreien E-Mail-Begleitung bekommst du Inhalte passend zu deiner Phase in der IT-Ausbildung: von der Suche nach einem Ausbildungsplatz über die einzelnen Ausbildungsjahre bis zu deinem weiteren Berufsweg und deiner Arbeit als Ausbilder:in. Die E-Mails sollen dich rechtzeitig an anstehende Aufgaben erinnern und dir fachliche Inhalte sowie Tipps für die Prüfungen schicken. Unter itberufepodcast.de/newsletter kannst du dich anmelden und deinen Ausbildungsstand auswählen; über einen Link in jeder E-Mail kannst du dich jederzeit wieder abmelden.

Kapitelmarken

[00:00:00] E-Mail-Begleitung für deine IT-Ausbildung

[00:01:04] Passende Inhalte für jede Ausbildungsphase

[00:03:50] Automatische E-Mails passend zu deinem Ausbildungsbeginn

[00:04:24] Inhalte aus meinem Ausbildungsalltag und vorhandenen Beiträgen

[00:05:30] E-Mail-Begleitung auch für meine eigene Arbeit

[00:06:27] Anmelden und deinen Ausbildungsstand auswählen

[00:08:04] Kostenfrei teilnehmen und jederzeit abmelden

[00:08:46] Vor der Ausbildung: Berufswahl und Bewerbung

[00:09:45] Erstes Ausbildungsjahr: Einstieg und fachliche Grundlagen

[00:11:21] Zweites Ausbildungsjahr: Teil 1 der Abschlussprüfung und vertiefende Themen

[00:12:40] Drittes Ausbildungsjahr: Abschlussprojekt und Prüfungen

[00:14:15] Nach der Ausbildung: Weiterlernen und berufliche Wege

[00:15:39] Selbst ausbilden: AEVO und Ausbildungsalltag

[00:17:02] IT-Azubis finden und rechtliche Grundlagen beachten

[00:17:31] Bereiche auswählen und Feedback geben

Inhalt

Bislang enthielt mein Newsletter nur Infos zu neuen Podcast-Episoden und Blogartikeln. Jetzt möchte ich einen Schritt weiter gehen und dich individuell bei deiner Ausbildung mit meinen E-Mails begleiten. Egal, in welchem Ausbildungsjahr du bist, oder ob du sogar selbst schon Azubis ausbildest: Ich schicke dir über das Jahr verteilt die jeweils passenden Themen zu deinem aktuellen Ausbildungsstand.

Vor der Ausbildung

Vor der Ausbildung unterstütze ich dich bei der Ausbildungsplatzsuche und gebe dir Bewerbungstipps. Außerdem zeige ich dir, wie du einen geeigneten Ausbildungsbetrieb findest und welcher IT-Job für dich der richtige ist.

Tipps zur Bewerbung um eine Ausbildung

Ablauf des Bewerbungsverfahrens für potentielle Azubis

Ausbildung oder Umschulung?

Wie erkenne ich einen guten Ausbildungsbetrieb?

1. Ausbildungsjahr

Im ersten Ausbildungsjahr geht es um einen erfolgreichen Einstieg in die Ausbildung. Hierbei geht es nicht nur um die fachlichen Fähigkeiten, sondern auch um das Miteinander im Ausbildungsbetrieb. Außerdem gehören berufsübergreifende Pflichten wie das Führen des Ausbildungsnachweises (Berichtsheft) dazu.

Tipps zum erfolgreichen Einstieg in die Ausbildung

Informationsquellen, Bücher und Podcasts für angehende ITler:innen

Literaturempfehlungen

Hilfreichsten Tools

Erläuterung der Gehaltsabrechnung

Produktivitätstipps

Häufige Fragen zum Berichtsheft

Verschiedene Buchclubs

Ergonomie am Arbeitsplatz

Einführung in die Versionsverwaltung mit Git

Aufsetzen eines eigenen Webservers

Einführung in die Programmierung und Objektorientierung

Effektive Informationsrecherche mit Suchmaschinen

2. Ausbildungsjahr

Das zweite Ausbildungsjahr startet mit der Vorbereitung auf Teil 1 der gestreckten Abschlussprüfung. Hier wird es zum ersten Mal ernst, denn 20% der Abschlussnote stammen aus diesem Prüfungsteil. Aber auch die Vertiefung der bisherigen Ausbildungsinhalte und die Erweiterung um neue Themen gehören zum zweiten Ausbildungsjahr.

Relationale Datenbanken, Normalisierung, SQL

Zeichensätze und -kodierung

HTML, CSS, XML

Vertiefende Buchclubs

Das ISO/OSI-Modell

Cloud Computing, Docker/Kubernetes, Big Data

Usability

Kryptographie

Vertiefende Themen der Programmierung, z.B. Unit-Tests, Mocks etc.

Datenschutz vs. Datensicherheit vs. Datensicherung

Das agile Manifest und Scrum

3. Ausbildungsjahr

Im dritten und letzten Ausbildungsjahr geht es natürlich um ein zentrales Thema: die IHK-Abschlussprüfung. Sowohl die schriftliche Prüfung als auch die praktische Projektarbeit sind wichtige Themen, auf die sich jeder Prüfling vorbereiten muss. Mit meiner Hilfe kommst du sicherlich gut durch beide Prüfungsteile.

Aufbau und Ablauf der Abschlussprüfung

Themenfindung für das Abschlussprojekt

Professionelle Anforderungsermittlung

Inhalte des Projektantrags

Inhalte, Gliederung und Layout der Projektdokumentation

Vorbereitung auf häufige Fragen im Fachgespräch

Vorbereitung auf die schriftliche Abschlussprüfung

Vorbereitung und ansprechende Gestaltung der Projektpräsentation

Nach der Ausbildung

Wenn du deine Ausbildung schon abgeschlossen hast, bekommst du von mir Tipps zur Jobsuche, Fort- und Weiterbildungen oder einfach allgemeinen Themen aus der IT. Vielleicht hast du sogar vor, selbst einmal Azubis auszubilden. Dann gebe ich dir noch mehr Tipps für deinen Weg zum Ausbilder.

Bewerbungstipps und Recruiting-Prozess

Continuous Improvement

Teilnahme an User Groups und Fachkonferenzen

Duales Studium und IHK-Weiterbildung zum Operative Professional

Mögliche Karrierepfade (z.B. SAP-Consulting, Freelancer)

Für Ausbilder:innen

Wenn du selbst bereits Azubis ausbildest oder sie in Zukunft ausbilden möchtest, habe ich eine Vielzahl an Tipps aus meiner Ausbilderpraxis für dich zusammengestellt. Von der Einführung neuer Azubis bis hin zur Prüfungsvorbereitung begleite ich dich durch den gesamten Lebenszyklus eines Azubis in der IT.

Ausbildung der Ausbilder (AEVO)

Agile Ausbildung

Erstellen des betrieblichen Ausbildungsplans

Potentielle Ausbildungsinhalte

Bewertung von Auszubildenden

Verschiedene Maßnahmen für eine erfolgreiche Ausbildung

Einführung eines neuen Azubis

Mögliche Praktikumsinhalte in der IT

Rechtliche Grundlagen wie das Berufsbildungsgesetz (BBiG) oder die Ausbildungsverordnungen

Jetzt anmelden

Um dich für meine ausbildungsbegleitenden Inhalte per E-Mail anzumelden, musst du lediglich ein kleines Formular ausfüllen. Du wirst dann Schritt für Schritt mit einigen Mails durch den Prozess geführt, um die für dich passenden Inhalte auszuwählen.

Anmelden zum IT-Berufe-Newsletter

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Vor der Ausbildung in den IT-Berufen

Einstieg in die Ausbildung in den IT-Berufen

Ausbildungsinhalte der IT-Berufe

Vorbereitung auf die IHK-Abschlussprüfung der IT-Berufe

Nach der Ausbildung in den IT-Berufen

Für IT-Ausbilder:innen

Zusammenfassung

So ist die E-Mail-Begleitung geplant

Mit meiner kostenfreien E-Mail-Begleitung möchte ich dich durch deine IT-Ausbildung begleiten und dir auch davor sowie danach passende Inhalte schicken. Dafür sind sechs Bereiche vorgesehen: die Zeit vor der Ausbildung, die drei Ausbildungsjahre, dein weiterer Berufsweg und die Arbeit als Ausbilder:in.

Die E-Mails sollen dann bei dir ankommen, wenn die Themen für dich anstehen. Wenn du deinen Ausbildungsbeginn angibst, etwa den 1. August oder den 1. September, lassen sich die Nachrichten daran ausrichten. Vor der Abschlussprüfung bekommst du beispielsweise Hinweise zum Projektantrag und dazu, wann du mit alten IHK-Prüfungen lernen solltest. Als Ausbilder:in erhältst du Erinnerungen, wann du Anzeigen für neue Ausbildungsplätze schalten solltest.

Vor der Ausbildung

Wenn du einen Ausbildungsplatz suchst, bekommst du Hinweise zu folgenden Themen:

Einen passenden IT-Beruf wählen und dich mit den Möglichkeiten einer Umschulung beschäftigen.

Eine Bewerbung schreiben und deine Chancen auf einen Ausbildungsplatz verbessern.

Dich auf Bewerbungsverfahren vorbereiten, einschließlich Tests und Assessment-Centern.

Einen geeigneten Ausbildungsbetrieb erkennen und einschätzen, wie dort ausgebildet wird.

Erstes Ausbildungsjahr

Zum Einstieg bekommst du Anregungen, wie du deinen Betrieb kennenlernst und herausfindest, womit er Geld verdient. Dazu gehört auch, mit deinem/deiner Ausbilder:in ins Gespräch zu kommen.

Für deinen Alltag stelle ich dir Bücher und andere Informationsquellen vor. Ergänzend gibt es Tipps zu hilfreichen Tools, etwa zum Üben des Zehnfingersystems. Auch deine Gehaltsabrechnung und ein ergonomischer Arbeitsplatz gehören zu den Themen. Das Berichtsheft wird ausführlich behandelt, weil es Pflicht und Voraussetzung für die Prüfung ist.

Fachlich sind unter anderem diese Inhalte vorgesehen:

Versionsverwaltung mit Git.

Einen Webserver aufsetzen und absichern sowie eine eigene Website bereitstellen.

Grundlagen von Netzwerken und der Funktionsweise des Internets.

Für Fachinformatiker:innen Anwendungsentwicklung: der Einstieg ins Programmieren und in die Objektorientierung.

Zweites Ausbildungsjahr

Nach ungefähr 18 Monaten steht Teil 1 der gestreckten Abschlussprüfung an. Er zählt bereits 20 Prozent deiner Abschlussnote. Dafür bekommst du Hinweise zu den erwarteten Inhalten, den Aufgaben und geeigneten Unterlagen zum Lernen.

Im weiteren Verlauf vertiefst du fachliche Themen, die für die IT-Berufe und die Prüfungen relevant sind:

Relationale Datenbanken, einschließlich Normalisierung und SQL.

Zeichensätze sowie HTML und XML.

Das ISO-OSI-Modell.

Cloud Computing und Docker.

Big Data.

Usability und Kryptografie.

Dazu sind auch Buchclubs vorgesehen, unter anderem zum IT-Handbuch für Fachinformatiker:innen und dessen Ausgabe von 2021.

Drittes Ausbildungsjahr

Für die Abschlussprüfung bekommst du Inhalte zu ihrem Ablauf und dazu, wie die einzelnen Teile gewichtet werden. Mit alten IHK-Prüfungen kannst du dich auf den schriftlichen Teil vorbereiten.

Bei deiner Projektarbeit begleite ich dich vom passenden Thema bis zum Fachgespräch:

Ein Projektthema finden, den Antrag schreiben und deine Zeit planen.

Anforderungen für das Projekt erfassen.

Deine Projektdokumentation vorbereiten, etwa mit einer Vorlage oder einem LaTeX-Projekt.

Inhalt und Gliederung der Dokumentation ausarbeiten sowie das Layout gestalten, damit Prüfer:innen deine Arbeit bewerten können.

...

Über das spannende Thema Big Data spreche ich mit Maurice Knopp in der einhundertfünfundsechzigsten Episode des IT-Berufe-Podcasts.

TL;DR

Ich gehe mit Maurice Knopp der Frage nach, wann du Big-Data-Technologien brauchst und wie du damit arbeitest. Entscheidend sind die Datenmenge, unterschiedliche Datenstrukturen, das Tempo und die Qualität der Daten. Data Engineering führt Daten zusammen und bereitet sie auf; Data Science sucht darin nach Mustern und entwickelt Modelle für Vorhersagen. Du lernst zentrale Werkzeuge wie Hadoop und Spark kennen und erfährst, wie du als IT-Azubi durch praktische Übungen in das Thema einsteigen kannst.

Kapitelmarken

[00:00:00] Big Data in der IT-Ausbildung

[00:01:19] Maurice Knopp und sein beruflicher Hintergrund

[00:02:50] Programmiersprachen, IDEs und aktive Ökosysteme

[00:07:53] Wann beginnt Big Data?

[00:09:48] Die vier Vs und typische Datenprobleme

[00:14:11] Datenqualität verbessern und Daten verstehen

[00:16:08] Warum Big-Data-Projekte in die Cloud wechseln

[00:19:02] Hadoop, Lizenzkosten und der Einstieg in die Cloud

[00:21:51] Für welche Unternehmen Big Data relevant wird

[00:23:50] Daten auswerten und Ausschuss in der Fertigung reduzieren

[00:26:42] Klickdaten und interessenbezogene Werbung

[00:28:08] Data Engineering und Data Science

[00:29:54] Ausfälle vorhersagen und Wartung planen

[00:31:04] ETL, Hive und der Data Lake

[00:33:52] Klassische Datenbanken und verteilte Systeme

[00:36:34] SQL, Spark und die Konzepte hinter den Werkzeugen

[00:40:55] Fähigkeiten und Ablauf eines Datenprojekts

[00:43:46] Modelle auswählen und neuronale Netze trainieren

[00:47:06] Mathematik, KI und die Qualität der Trainingsdaten

[00:52:16] Edge Computing und lokal verarbeitete Sensordaten

[00:54:45] Werkzeuge im Hadoop- und Cloud-Umfeld

[00:57:38] HDFS als Grundlage eines Data Lake

[00:59:25] Wie MapReduce funktioniert

[01:03:21] Dateiformate, virtuelle Tabellen und Bilddaten

[01:05:44] Python und PySpark

[01:08:18] Berufseinstieg durch Ausbildung oder Studium

[01:11:12] Daten- und Prozessanalyse und Overfitting

[01:13:03] Bücher und Videokurse zum Einstieg

[01:14:31] Datenprojekte im Unternehmen anstoßen

[01:18:43] Weiterlernen und Empfehlungssysteme

[01:21:00] Praktisch lernen und Wissen weitergeben

[01:23:46] Weitere Quellen und Kontakt zu Maurice Knopp

[01:25:32] Cloud und softwaregesteuerte Infrastruktur

[01:27:32] Abschluss des Gesprächs

[01:28:18] Shownotes und weitere Podcast-Empfehlungen

Inhalt

Allgemeines zur Person

Wie ist dein Name und wo arbeitest du (falls gewünscht)?

Name: Maurice Knopp

Beruf: Softwareentwickler seit über 16 Jahren; Anfangs Enterprise Software (Java, Backend), seit 4 Jahren Schwerpunkt Big Data Technologien.

Freiberufler in Zusammenarbeit mit der skillbyte GmbH aus Köln.

Hobbies: Podcaster f. skillbyte & OpenSource Entwickler (LaTeX-Vorlage für Abschlussarbeiten (Bachelor, Master, PhD))

An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob?

Konzeption von Big Data Architekturen (Data Lakes) & Big Data Softwareanwendungen (on premise; seit 2019 ausschließlich Cloud) für Großunternehmen (z.B. Medienbranche)

Implementierung von ETL-Strecken (Daten extrahieren, transformieren, laden in neuer DB oder Cloud Storage)

Enterprise Software (Java, Backend) (z.B. Energieversorger)

Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?

Bereits als Kind mit 6 Jahren von Technik fasziniert (GameBoy). Ich wollte immer verstehen, wie die Technik funktioniert. Erster PC MacIntosh + DOS: PC-Tuning. In den 2000ern Faszination für Internet und Linux entwickelt.

Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?

2004-2008 Medieninformatik Bachelor an der TH Köln

2008-2010 Wirtschaftinformatik Master an der TH Köln

viele Projekte nebenbei: Für Firmen Software und Webseiten erstellt, Abschlussarbeiten (B.SC. / M.SC.) stets in Unternehmen gemacht (Luxemburg / Köln).

Mit welcher/n Programmiersprache/n arbeitest du im Alltag?

Java (riesiges Ökosystem, viele Data-Komponenten wurden in Java entwickelt (HDFS), super für threaded Entwicklung)

Python (Data Libs, Microservices)

Scala (Spark)

SQL (extrem wichtig, auf jeden Fall lernen)

Bash (Scripting)

Container + Orchestrierung: Docker + Kubernetes sind aktuell das große Ding (on-prem und cloud)

Was ist deine Lieblingsprogrammiersprache und warum?

Java, top Entwicklungsumgebungsunterstützung, riesiges Ökosystem mit vielen frei verfügbaren Bausteinen, hoher Reifegrad, von App-Entwicklung bis Server-Softare alles möglich.

Aber: Keine religiöse Einstellung zur Programmiersprache! Ökosystem ist wichtiger, da eine gute IDE per Autocompletion viel Arbeit abnimmt. Man sollte die zum Anwendungsfall passende Sprache auswählen.

Die IDE ist ein wichtiges Werkzeug, dessen Benutzung man perfektionieren sollte. Macht einen großen Unterschied bei der Produktivität.

Wichtig ist, dass die gewählte Sprache lebt und sich weiterentwickelt. Gute Features werden eh mit der Zeit übernommen (z.B. aus Rails).

Big Data

Was verbirgt sich hinter dem Begriff "Big Data"?

Die Frage wird meist von Kunden gestellt, um herauszufinden, ob sie "schon" Big Data machen oder noch ganz normale Datenverarbeitung.

Wann wird aus Datenverarbeitung Big Data? Ab 1 Mio Datenzeilen? Ab 100 Mio?

Big Data bezeichnet Technologien zur Verarbeitung und Auswertung "riesiger Datenmengen" -> 100 Mio von Datenpunkten.

In kurzer Zeit entstehen viele Datenpunkte, meist Millionen am Tag. Sie werden dann oft aggregiert in Dashboards.

Software zur massiven Parallelverarbeitung mit Standard-Hardware (Enterprise Grade Linux Server, Cloud VMs).

Big Data fängt an, wenn eine Maschine nicht mehr reicht für die Verarbeitung der Daten.

Beispiel: Aggregiere Verkaufsdaten in riesigen Datenbeständen (Divide-and-Conquer-Modell). Selbstfahrendes Auto liefert schnell viele Daten.

Viele DAX-Konzerne haben das im Einsatz, da bei ihnen viele Daten anfallen.

Was verbirgt sich hinter den "vier Vs" (velocity, volume, variety, veracity)?

Volume (Datenmenge): Big Data macht nur bei extrem großen Datenmengen Sinn. Für die Verarbeitung von 10-100 Mio Datensätzen reichen Standardwerkzeuge. 10-100 Mio Datensätzen pro Stunde -> da wird es interessant.

Variety (Vielfalt der Datenstrukturen): strukturiert (DB) vs. unstrukturiert (Text, PDF Dokumente, Bilder, Video).

Velocity (Geschwindigkeit): Wie schnell werden Daten erzeugt bzw. müssen verarbeitet werden, z.B. beim autonomen Fahren.

Veracity (Wahrhaftigkeit): Unsicherheit bzgl. der Datenqualität. Beispiele: unterschiedliche Zeitzonen, Umlaute, fehlende Daten, doppelte Daten, ungültige Daten etc.

Veracity macht häufig Probleme bei Kunden. Kann das nur durch manuelle Arbeit gelöst werden?

Standardlösungen sind für häufige Probleme möglich (Kleinschreibung von Benutzernamen usw.).

Auf Hadoop gibt es viele Lösungen

Seit 2019 läuft alles in der Cloud und nicht mehr im eigenen RZ. Das sollte man aber vorher rechtlich klären.

Warum wird so viel in der Cloud betrieben?

Die vier Vs schreien nach der Cloud. Dort ist z.B. NoSQL einfach verfügbar und scheinbar "unendlicher" Speicher.

Skalierbarkeit ist in der Cloud auch optimal.

Realtime geht natürlich nur lokal.

Hat die Cloud Big Data vorangetrieben?

Ja, da die Einstiegshürde nun geringer ist.

Hadoop ist als Open Source gestartet (Spielzeugelefant des Kindes des Entwicklers hieß so), aber man brauchte viele Server dafür.

Big Data startet oft klein und wächst dann schnell, daher ist Infrastruktur immer hinterher.

Hortonworks wurde gekauft von Cloudera. Dadurch gibt es jetzt hohe Lizenzkosten pro Node. Strategie ist nun, die Top-Kunden zu betreuen, die nicht in die Cloud dürfen/können.

Warum ist das Thema Big Data aktuell und in Zukunft wichtig und interessant?

Daten sind das neue Öl (Treibstoff)!

Datenanalyse ist der Verbrennungsmotor (richtigen Schlüsse aus Daten ziehen).

Beispiele (Daten/Analyse)

Logdaten: Systemfehler finden. Wo können Kunden nicht bedient werden? Welche Prozesse schlagen fehl? Wo sind Antwortzeiten zu hoch?

Nutzerverhalten: Welche Funktionen werden genutzt, welche nicht? Dementsprechend Entwicklungsleistung konzentrieren. Welche Produkte werden nachgefragt? Wo brechen Kunden im Prozess ab? A/B-Tests verschiedener Varianten, um optimalen Kandidaten zu finden (z. B. bei der Buchung von Flügen).

Telemetriedaten von Systemen: Voraussage, wann Maschinenteile ausfallen werden (Ersatzteilbestellung optimieren, Ausfallzeiten minimieren). Voraussage von Technikereinsätzen. Festlegung von Wartungsintervallen.

Welche Unternehmen sollten sich mit Big Data beschäftigen und warum?

Jedes Unternehmen sollte sich fragen:

In welchen Prozessen generieren wir heute schon viele Daten und welche Erkenntnisse könnten in diesen liegen?

Welche Prozesse erfassen noch zu wenig Daten?

Welche Erkenntnismöglichkeiten hätten wir, wenn wir alle Unternehmensdaten an einer zentralen Daten-Sammelstelle (Data Lake) bereitstellen würden, sodass wir Abfragen kreuz und quer über diese Daten fahren können?

Beispiele: Medienunternehmen -> User-Nutzungsdaten, Energieversorger -> Messzählerdaten etc.

Große Datenprobleme brauchen Big Data! Viele Daten müssen erfasst werden, meist bei Millionen von Kunden.

Aber generell steigt das Datenvolumen weltweit, auch der Mittelstand braucht irgendwann Big Data.

Was sind übliche Use Cases für Big Data?

Beispiel: Industrieunternehmen hat Teile für Weltraumunternehmen gebaut auf sechs Fertigungsstraßen. Dabei durfte es nicht mehr als 2% Ausschuss geben, da sonst Verluste drohten.

Verschiedene Geräte arbeiteten zusammen: Öfen, CNC, etc. Alle hatten Sensoren, die aber nicht abgefragt wurden.

Irgendwann wurden dann diese Daten gesammelt und man näherte sich der 2%-Hürde. Durch die Daten wurde festgestellt, dass 90% des Ausschusses aus einem einzigen Ofen kamen. Der Hersteller wurde angerufen, der Ofen neu kalibriert und 0,1% als neuer Ausschuss erreicht.

Wird bei Big Data meist etwas aus großen Datenmeng

Über verschiedene Möglichkeiten der Qualitätssicherung bei der Softwareentwicklung spreche ich mit Christian Kranert in der einhundertvierundsechzigsten Episode des IT-Berufe-Podcasts.

TL;DR

Ich gehe mit Christian Kranath einen mehrstufigen Prozess durch, mit dem du als IT-Azubi Softwarequalität sichern kannst: vom eigenen Codecheck über Unit-Tests und kurze Code-Reviews bis zu manuellen Tests und Exception-Logging im laufenden Betrieb. Früh entdeckte Fehler kosten weniger, während klare Namen und gemeinsam entwickelte Patterns die Komplexität begrenzen. Zum Prozess gehören außerdem zeitnah festgehaltene Dokumentation und begründetes Feedback im Team, in das auch IT-Azubis früh eingebunden werden.

Kapitelmarken

[00:00:00] Thema und Bezug zur Abschlussprüfung

[00:01:58] Christian Kranath und sein Arbeitsumfeld

[00:02:46] Technologie-Stack und TypeScript

[00:04:38] Einstieg in die Programmierung und Ausbildung

[00:07:29] C# und die Wahl einer Programmiersprache

[00:09:13] Warum Softwarequalität gesichert wird

[00:11:41] Die Stufen des Qualitätsprozesses

[00:13:29] Eigener Codecheck vor dem Commit

[00:15:05] Checklisten und DevBuddy

[00:17:29] Unit-Tests und 95 Prozent Testabdeckung

[00:20:05] Erfahrungen mit Test-Driven Development

[00:22:02] Code-Reviews nach spätestens einem Tag

[00:24:09] Review-Checkliste und offene Teamkultur

[00:25:36] Reviews auf Branches und persönliche Rückmeldungen

[00:30:24] Manuelle Tests und Testfälle aus dem Entwicklungsteam

[00:33:27] Kommunikation in der Softwareentwicklung

[00:34:27] Release und Exception-Logging im laufenden Betrieb

[00:37:48] Bugfixes priorisieren und bündeln

[00:40:22] Dokumentation in DevBuddy und zeitnahe Stichpunkte

[00:45:40] Architektur und Company-Patterns

[00:49:17] Gemeinsam ein Settings-Pattern entwickeln

[00:52:12] Komplexität begrenzen und klare Namen wählen

[00:56:52] Legacy-Code, Refactoring und Rewrite

[01:01:15] Mehrwert für Benutzer:innen bei Releases

[01:03:27] Ausbildung und Praxissemester im Unternehmen

[01:05:42] Früh am echten Produkt lernen

[01:07:55] Bücher und Videokurse zum Weiterlernen

[01:10:04] Weiterbildung im Arbeitsalltag

[01:11:45] Diversität im Entwicklungsteam

[01:13:16] Kontakt zu Christian und weitere Ressourcen

[01:14:15] Shownotes zur Episode

Inhalt

Allgemeines zur Person

Wie ist dein Name und wo arbeitest du (falls gewünscht)?

Christian Kranert, 31 Jahre alt, Nürnberg, ich arbeite bei der Head-on Solutions GmbH.

Wir entwickeln eine Software zum Cloud Management für Frisöre, Kosmetikstudios usw. für eine moderne Organisation: Terminbuchung, Kasse, Marketing.

Wir sind eine rein interne Entwicklungsabteilung.

An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob?

Die Software, die ich mit meinem Team der Head-on Solutions GmbH entwickle: studiolution.

Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?

Ich war schon immer fasziniert von Computern und hatte mit 12 Jahren meinen ersten eigenen PC

Darauf habe ich schnell ein erstes Programm erstellt mit Visual Basic 6.

Ich habe mir nie erträumt, ohne Studium programmieren zu können.

Zum Einstieg habe ich "Hello World" programmiert und danach einen Paint-Klon.

Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?

Nach der Schule (die war nervig, weil ich schon wusste was ich will) habe ich die Ausbildung zum Fachinformatiker Anwendungsentwicklung gemacht.

Ich bin in der Automobilindustrie gestartet und habe bei der Brose Group eine sehr gute Ausbildung bekommen. Die hatten 200 Leute in der IT und ich konnte viele Abteilungen durchlaufen. Dort habe ich viel gesehen und gelernt.

Ich bin gestartet mit der SAP-Entwicklung, aber parallel habe ich mit .NET begonnen.

Mit welcher/n Programmiersprache/n arbeitest du im Alltag?

Im Backend setzen wir auf C# in Kombination mit dem SQL Server.

Im Frontend setzen wir JavaScript ein, aber in Form von TypeScript. Für HTML/CSS nutzen wir SASS als Präprozessor.

TypeScript mag ich wegen der Typisierung.

Was ist deine Lieblingsprogrammiersprache und warum?

ABAP habe ich in SAP zwar auch gemacht, aber C# ist meine Lieblingssprache. Ich mag die Typisierung und viele Features, die konsistent umgesetzt sind.

Java habe ich mir angeschaut für die SAP-Entwicklung.

Ich bin kein Freund der "religiösen" Gefolgschaft von Programmiersprachen.

Qualitätssicherung bei der Softwareentwicklung

Warum sollten wir uns überhaupt Gedanken zur Qualitätssicherung machen?

Das ist eine gute Frage, die man oft im Alltag beantworten muss, z.B. bei Diskussionen mit Kunden oder dem Chef.

Vergleich mit der Industrie: Teile müssen "perfekt" sein, der Kunde soll am Ende glücklich sein.

Bei Software ist es genauso: das Release soll den Kunden zufrieden stellen.

Ansonsten muss man nachbessern und hat unzufriedene Kunden.

Die Behebung von Fehlern ist sehr teuer im Nachhinein.

Außerdem ist Kosteneffizienz und Mitarbeiterzufriedenheit wichtig für das Unternehmen.

Welche Maßnahmen gibt es grundsätzlich zur Qualitätssicherung?

Wir setzen auf eine Art Stufensystem. Je früher Fehler behoben werden, desto billiger ist es.

Das beginnt beim Entwickler: wir haben eine Entwicklerselbstkontrolle, Stichpunkte, die die Entwickler:innen selbst durchgehen, z.B. Diff checken vor dem Commit. Das machen wir extra in einem externen Programm, damit eine andere Schriftart für eine andere Denkweise sorgt und Flüchtigkeitsfehler, vergessener Debugcode etc. vermieden werden.

Danach kommen die Unit-Tests, die die Entwickler:innen selbst schreiben.

Dann folgt ein Code Review durch eine andere Person.

Und zuletzt kommt noch ein manueller Test.

Welche technischen Maßnahmen zur Qualitätssicherung gibt es auf Ebene einzelner Commits?

Die genannte Entwicklerselbstkontrolle.

Regelmäßige Routinen aus Checklisten sind auch in der Industrie gängig, dort haben wir das abgeschaut.

Das nimmt Komplexität aus dem Prozess und führt zu weniger "Mental Load".

Wir haben auch weitere Checklisten, z.B. für Releases etc.

Wo sind die Checklisten abgelegt?

Wir haben den DevBuddy, unsere interne Entwicklungsplattform für die Ablage. Dort haben wir auch mit HTML/JavaScript einen "Fortschrittsbalken" gebaut, um ein wenig Gamifaction einzubauen.

Wann und wofür verwendest du welche Tests: Unit-Tests, Snapshot-Tests, manuelle Tests?

Wir setzen kein TDD ein, die Mehrheit im Team glaubt nicht daran.

Aber unser Code muss immer mit Tests abgedeckt werden, auch wenn die Tests erst nach dem Code geschrieben werden.

Warum setzt ihr nicht TDD ein?

Wir entwickeln agil und auch bei der Konzepterstellung wirkt das Team mit.

In diesem Prozess wird gerade zu Beginn viel am Code angepasst, daher hemmt TDD uns eher, z.B. bei Prototypen, bei denen der Test erstmal nicht implementiert wird.

TDD ist aktuell einfach nicht zuträglich, aber wir haben es auch nur einmal ausprobiert.

Achtet ihr auf die Code Coverage?

Sie wird noch nicht automatisch ermittelt, geht aber mit Visual Studio ganz gut.

Bei der Line-/Branch-Coverage peilen wir 95% an. Durch wenig Boilerplate-Code schaffen wir das auch.

Wie (gut) lassen sich Code Reviews in den Entwicklungsprozess integrieren?

Bei uns wird jede Zeile geprüft, alles braucht ein 4-Augen-Prinzip.

Direkt nach Implementierung folgt das Review, niemand darf länger als einen Tag entwickeln ohne Review.

Bei anderen Unternehmen wird oft nur über die Findings gesprochen und dann aber nichts gemacht. Wir erzwingen aber die Änderungen aus dem Review.

Macht ihr das auch mit Checklisten?

Ja, aber sie dienen nur zur Einarbeitung neuer Kolleg:innen. Danach sind die Konventionen dann bekannt.

Alle Mitarbeiter machen ein Code Review, sogar Praktikanten bei erfahrenen Entwicklern. Das fördert die Teamkultur: viel und häufiges Feedback. Die Kritikfähigkeit wächst dadurch stark.

Macht ihr Pull Requests? Oder wo/wie läuft das Review?

Das Review wird direkt auf dem Branch durchgeführt. Durch eine Verknüpfung zwischen Work Items und Commits geht das sehr gut.

Wir überlegen gerade, Pull Requests einzuführen, aber wegen der kurzen Zyklen hätten wir dabei wohl zu viel zu mergen.

Wie sieht das Ergebnis der Reviews aus?

Die Findings werden im persönlichen Gespräch geklärt. Kleinigkeiten werden auch direkt von Reviewer gefixt, abhängig von Skill des Gereviewten (z.B. Flüchtigkeitsfehler).

Eine Diskussion über mögliche Alternativen geht persönlich besser und die Begründung ist enorm wichtig, da nur so ein Diskurs und eine bessere Lösung entsteht.

Dann ist aber viel Zeit für Gespräche nötig, oder?

Kurze Wege sind dafür unbedingt nötig! Das Review muss beim Team akzeptiert sein und die Arbeitszeiten müssen zusammen passen.

Dann kommen die manuellen Tests?

Unser Ziel ist die Automatisierung, aber komplett wegkommen werden wir nicht von den manuellen Tests. Sie decken Dinge auf wie Wording oder fachliche Fehler (z.B. negative Umsatzsteuer).

Manuelle Testfälle werden bei uns schon von den Entwicklern erstellt, da Tester den Code nicht kennen.

Jeder Entwickler ist verpflichtet, Tests zu formulieren, weil sonst Tests "verloren gehen".

Ursprünglich haben wir das mit Excel gemacht, jetzt haben wir DevBuddy um ein Testtool erweitert mit Testrunner für ein wenig Gamification.

Das fördert auch die Kommunikation mit dem Kunden.

Und dann sind wir schon beim Release?

Ja, danach kommt das Deployment, aber wir sind dann noch nicht fertig! Stichwort: Exception Logging.

Wie behandelt/protokolliert ihr Laufzeitfehler?

Wir haben eine ganz einfache Methode: ein globaler Exception-Handler schickt Stacktraces per Mail an ein Postfach, das rotierend von Entwicklern beobachtet wird.

Das motiviert die Mitarbeiter, Fehler zu vermeiden/beheben.

Vorteile des Postfachs: man kann die Mails einfach weiterleiten und viele Infos transportieren.

Eigentlich war die Lösung nur ein Provisorium, aber inzwischen bleiben wir gerne dabei.

Wie integrierst du Fehlersuche und Bugfixing in deine Arbeit?

...

Um das Neuordnungsverfahren der IT-Berufe geht es im Interview mit Silvio Kennecke und Jörg Ferrando in der einhundertdreiundsechzigsten Episode des IT-Berufe-Podcasts.

TL;DR

In meinem Gespräch mit Silvio Kennecke und Jörg Farando erfährst du, wie die IT-Berufe 2020 neu geordnet wurden und wie schriftliche IHK-Prüfungen entstehen. Die Ausbildungsordnungen beschreiben grundlegende Fähigkeiten, während die Umsetzungshilfen konkrete Beispiele für deinen Berufsalltag liefern. Die Projektprüfung blieb erhalten; mit der gestreckten Abschlussprüfung verteilen sich die geprüften Inhalte auf zwei Zeitpunkte. Für deine Prüfung kannst du passende Aufgaben aus älteren Prüfungen bearbeiten und dich an den Umsetzungshilfen orientieren.

Kapitelmarken

[00:00:20] Thema und Gäste des Interviews

[00:01:47] Silvio Kennecke und Jörg Farando stellen sich vor

[00:02:49] Aufgaben von Sachverständigen und Berufemacher:innen

[00:06:21] Silvios Programmiersprachen und Einstieg in die IT

[00:09:32] Anlass und Vorgeschichte der neuen Ausbildungsordnungen

[00:13:19] DGB, KWB, Ministerium und BIBB im Verfahren

[00:16:20] Sachverständige auswählen und erste Sitzungen

[00:18:13] Beteiligte und Größe der Arbeitsgruppen

[00:20:42] Arbeitsweise, Eckwerte und Phasen des Verfahrens

[00:25:04] Dauer des Verfahrens und Erhalt der Projektprüfung

[00:27:07] Projektprüfung und betrieblicher Auftrag

[00:29:31] Ausbildungsinhalte und gemeinsame Programmiergrundlagen

[00:32:23] Bedarf an zusätzlichen Fachrichtungen

[00:38:15] Langlebige Inhalte und Umsetzungshilfen

[00:42:15] Streitpunkte bei Prüfungsform und Elektrotechnik

[00:44:23] Ziele und Ausgestaltung der gestreckten Abschlussprüfung

[00:49:49] Handlungsorientierte Prüfungsaufgaben erstellen

[00:52:28] Alternative Lösungen und fachliches Bewerten

[00:54:40] Ausschüsse und Prüfung der Aufgaben

[00:56:45] Eigene schriftliche Prüfungen in Baden-Württemberg

[00:57:48] Rückmeldungen und erste Ausbildungszahlen

[01:00:24] Vorbereitung auf die neuen Prüfungen

[01:03:18] Abgleich mit dem e-Competence Framework

[01:05:32] Rückgang der Ausbildungsverhältnisse

[01:07:03] Datenschutz und das IT-Weiterbildungssystem

[01:08:36] Weiterlernen und Buchtipp

[01:11:02] Kontakt und Fragen an die Gäste

[01:12:38] Shownotes und Quellen

Neuordnungsverfahren der IT-Berufe im Jahr 2020

Wie sind eure Namen und wo arbeitet ihr?

Silvio Kennecke, 22 Jahre alt, Softwareentwickler für Webshops in Bremen. Bundessachverständiger im Neuordnungsverfahren der IT-Berufe.

Jörg Ferrando, "Berufemacher" bei der IG Metall. Gewerkschaftssekretär im Ressort für Bildungs- und Qualifizierungs-Politik bei der IG Metall, hat das Verfahren als Koordinator auf Arbeitnehmerseite von Anfang an begleitet. Er organisiert den Prozess und führt die Verhandlungen mit den Arbeitgebern. Er hat bereits verschiedene Berufe umgesetzt.

Wie wird man mit 22 Jahren Sachverständiger?

Nicht die Berufsjahre zählen, sondern der Weitblick im eigenen Beruf und den Branchen. Über die Arbeit in der Gewerkschaft ist er zur Rolle gekommen.

Jörg hat Silvio "ausgesucht".

Wie seid ihr zur Informatik bzw. Softwareentwicklung gekommen?

Silvio: Über die Eltern, die aus dem IT-Umfeld kommen. An der Oberschule hat er Informatikunterricht angeregt und sich selbst Übungsaufgaben ausgedacht. Dort ging es um Websites mit HTML usw. Dann hat er sich in der Bibliothek ein Buch über JavaScript ausgeliehen und einen ersten Einstieg in die Programmierung gefunden. Danach hat er dann PHP programmiert und auch Cross-Platform-Entwicklung gemacht.

Welche Ausbildung bzw. welches Studium habt ihr im Bereich der Informatik absolviert?

Silvio: Ausbildung zum Fachinformatiker Anwendungsentwicklung

Jörg: Hat mal PHP programmiert und kann ein bisschen SQL, aber er hat keine IT-Ausbildung.

Was ist deine Lieblingsprogrammiersprache und warum?

Silvio: PHP, Swift (aber er macht aktuel lzu wenig damit)

Wie kam es zur Neuordnung der IT-Berufe? Wer hat den Prozess "angestoßen" und warum?

Es ging schon 2012 los. Jörg hat mit der Bitkom gesprochen aufgrund des "20. Geburtstages" der IT-Berufe.

Zunächst waren es zähe Gespräche. Die Arbeitgeber wollten nicht zustimmen. Dafür gab es rückblickend gute Gründe.

Die IG Metall ging auf die Arbeitgeber zu. Das hat dann bis 2018 gedauert.

Wer sind "die" Arbeitgeber?

Es gibt mehrere Arbeitgeberverbände mit einem Dachverband. Die DGB ist der Dachverband für die Gewerkschaften.

Wer hat bei dem Verfahren den Hut auf?

Die Spitzenorganisation KWB (Kuratorium der Deutschen Wirtschaft für Berufsbildung) und der DGB haben einen Antrag beim Wirtschaftsministerium gestellt mit Auftaktgespräch.

Das Wirtschaftsministerium hat dann eine Weisung an das BIBB herausgegeben und die Neuordnung gestartet.

Dann hat das BIBB Briefe mit der Bitte um Benennung von Sachverständigen verschickt.

Die "Berufemacher" haben dann Sachverständige ausgesucht.

Das BIBB moderiert das Neuordnungsverfahren, letztlich verantwortlich ist aber das Ministerium.

Wer hat an der Neuordnung der IT-Berufe mitgewirkt und wie wurden diese Personen ausgesucht?

Die Berufemacher suchen die Sachverständigen aus. Dazu sind natürlich gute Kontakte in die betriebliche Praxis wichtig.

Wie war eure Rolle bei der Neuordnung und wie seid ihr dazu gekommen?

Jörg hat Silvio angesprochen.

Das BIBB hat zur ersten Sitzung eingeladen. Dort wurden alle ins Thema und den Prozess eingeführt. Wer hat welche Aufgaben? Welche Ziele werden verfolgt? Wie ist das genaue Vorgehen?

Wie viele Menschen waren beteiligt?

Es gab sehr viele Stakeholder (Verbände etc.) und Sachverständige, insb. weil es eben mehrere IT-Berufe gibt.

In Summe über Arbeitgeber, Arbeitnehmer und sonstige Beteiligte ungefähr 30-35 Personen.

Normalerweise (für Monoberufe) sind 3 Arbeitnehmer, 3 Arbeitgeber und ihre Stellvertreter beteiligt.

Für die IT-Berufe: je Fachrichtung 2 Arbeitgeber, 2 Arbeitnehmer und Stellvertreter.

Wie lief der Prozess der Neuordnung ab? Wer hat wann was entschieden?

Grundfragen wurden gemeinsam geklärt, danach wurden Arbeitsgruppen gebildet, die auch gar nicht unbedingt nach Berufen aufgeteilt wurden.

Welche Inhalte sind noch aktuell laut Ausbildungsplan? Welche sind nicht mehr zeitgemäß?

"Gruppenarbeiten" sind aus der Schule bekannt. Wichtig ist es, einen Konsens zu schaffen.

Bereits vor dem Anfangsgespräch werden Eckwerte festgelegt wie Berufenamen und Prüfungsform.

Das Vorverfahren hat Entscheidungsgrundlage für Eckwerte geliefert und auch der Datenschutz wurde geklärt.

Das hat 1,5 Jahre gedauert. Die Berufsordnung ist quasi ein Gesetzgebungsverfahren, an dem viele Personen und Stellen beteiligt sind.

Normalerweise dauert das nur ein halbes Jahr, aber die IT-Berufe sind eine Ausnahme wegen extrem vieler Beteiligter.

Schnelligkeit basiert auf Vertrauen und das hat länger gedauert wegen vieler Beteiligter.

Die Arbeitgeber haben zunächst nicht gesagt, warum eher nicht neugeordnet werden soll. Ihre Angst war, dass die Prüfungsform des Praxisprojekts vielleicht abgeschafft werden soll.

Der "betriebliche Auftrag" war nicht gewünscht von den Arbeitgebern, sie haben gekämpft für die Projektprüfung.

Die Formulierung des Auftrags ist Teil des Projekts. Beim betrieblichen Auftrag wird das Thema vom Ausschuss vorgegeben bzw. der Auftrag muss "fertig" sein.

Das Projekt muss komplett durchgeführt werden aktuell inkl. Wirtschaftlichkeit, beim betrieblichen Auftrag ist eher nur die Umsetzungsphase Inhalt.

Wie wurden die Inhalte der neuen Verordnung und insb. des Ausbildungsrahmenplans festgelegt? Wer hat die Themen bestimmt?

Das ging immer zwei Schritte nach vorne, dann wieder einen zurück. Das Einspielen im Team hat zunächst gedauert.

Was ist elementar wichtig für den Beruf? Was erwarten wir von FIAE, FISI usw?

Dann wurde der alte Ausbildungsplan durchgeschaut und in berufsspezifischen Arbeitsgruppen gearbeitet.

Die berufsübergreifenden Themen haben lange gedauert, weil diskutiert wurde, wie intensiv man was können sollte. Beispielsweise sollte jeder ITler mal ein Programm geschrieben haben. Dieses "Grundverständnis" gehört dazu für alle ITler.

Wieso brauchen wir vier verschiedene Fachrichtungen des Fachinformatikers?

Die Weisung aus dem Antragsgespräch hat das vorgegeben. Der Auftrag war die Evaluierung der Bedarfe aus der Industrie. Das war zwar schon gegeben, aber ergebnisoffen. Es sollte nochmal evaluiert werden.

Bei Audi gab es eine Sitzung, um im Betrieb mit Azubis zu sprechen usw. Da gab es dann auch Einblicke in die Industrie mit ihren ganz eigenen Anforderungen an die Ausbildung. Silvio vertritt eher KMU. Es war schwierig dort einen Konsens zu finden.

Man darf bei der Bewertung der IT-Berufe nicht nur in seiner eigenen Blase denken. Die Wirtschaft ist vielfältig. Ziel war nicht, vier Fachrichtungen zu schaffen, sondern den Bedarf aus der Praxis zu decken.

Ungefähr 2016 ging es los mit der Angst vor einem "Apple/Google-Auto" in Deutschland. Die Industrie brauchte jemanden für das "deutsche Apple-Car". Das sollte dann zunächst der "MATSE" (Mathematisch-technischer Softwareentwickler) sein, der auch in Hessen umgesetzt wurde.

IT-Berufe waren für viele Betriebe immer noch als "Telekom-Berufe" im Kopf und sie hatten keinen guten Ruf. Daher wurden neue Berufe bzw. Fachrichtungen geschaffen.

Wie stellt ihr sicher, dass die Themen des Ausbildungsrahmenplans eine lange Lebensdauer haben?

Das ist schwer zu sagen. Es gibt eine Umfrage unter Betrieben mit Zielen/Ausrichtung/Bedarf für die Zukunft. Der Abschlussbericht der Voruntersuchung zur Neuordnung enthält diese Informationen.

Zusätzlich haben wir uns an der eigenen betrieblichen Praxis orientiert.

Und dann wird nicht "NoSQL" oder "Big Data" aufgeschrieben, sondern das grundlegende Handwerkszeug. Nicht "Java", sondern "Objektorientierung".

Im Verfahren gibt es auch Personen, die aufpassen, dass die Inhalte nicht zu spezifisch werden.

Wie wurden die Umsetzungshilfen erstellt und wer hat daran mitgewirkt?

...

Um Scrum, eines der bekanntesten agilen Vorgehensmodelle, geht es in der einhundertzweiundsechzigsten Episode des IT-Berufe-Podcasts.

TL;DR

In meinen Fachgesprächen mit angehenden Fachinformatiker:innen gehört Scrum zu den wiederkehrenden Prüfungsthemen. Das agile Rahmenwerk organisiert die Arbeit in wiederkehrenden Sprints, durch die ein Produkt schrittweise wächst und Kund:innen regelmäßig Feedback geben können. Du lernst die Aufgaben des Teams kennen sowie die Rollen von Product Owner:in und Scrum Master:in; außerdem gehören Backlogs und die Scrum-Meetings zum Ablauf. Die Definition of Done legt fest, wann ein Ergebnis fertig ist, während das Burndown-Chart den geschätzten Restaufwand sichtbar macht.

Kapitelmarken

[00:00:00] Einstieg in Scrum

[00:00:45] Scrum in der Praxis und in IT-Prüfungen

[00:03:45] Ursprung und Bedeutung des Begriffs Scrum

[00:06:26] Scrum als Rahmenwerk

[00:08:40] Das selbstorganisierende Team

[00:10:27] Agilität und wiederkehrende Sprints

[00:12:06] Wie das Produkt inkrementell wächst

[00:14:12] Anforderungen erfassen und schätzen

[00:16:54] Anforderungen für den nächsten Sprint auswählen

[00:18:24] Feste Sprintdauer und Timeboxing

[00:20:11] Produktinkrement und Feedback der Kund:innen

[00:22:01] Täglicher Austausch während des Sprints

[00:23:50] Die Rolle des Teams

[00:26:09] Aufgaben von Product Owner:innen

[00:28:36] Scrum Master:innen und Hindernisse im Projekt

[00:32:45] Das Produktinkrement als zentrales Artefakt

[00:36:44] Definition of Done

[00:38:01] Product Backlog und Sprint Backlog

[00:40:16] Aufgaben nach Priorität bearbeiten

[00:42:01] Sprint Backlog laufend aktualisieren

[00:43:27] Gemeinsames Commitment und geschätzte Aufgaben

[00:46:29] Sprint Planning

[00:47:25] Gemeinsam schätzen mit Planning Poker

[00:53:03] Sprint Review mit Kund:innen

[00:54:59] Daily Scrum mit festem Zeitrahmen

[00:57:38] Warum das Daily Scrum im Stehen stattfindet

[00:58:35] Fragen im Daily Scrum und Transparenz im Team

[01:01:50] Den Prozess in der Sprint Retrospective prüfen

[01:04:11] Aufbau des Burndown-Charts

[01:05:44] Velocity und realistische Schätzwerte

[01:08:00] Restaufwand täglich neu schätzen

[01:11:14] Den Verlauf im Burndown-Chart lesen

[01:12:06] Beispiel zum Burndown-Chart

[01:15:06] Fragen und Erfahrungen aus der Praxis

Inhalt

Scrum ist einer der bekanntesten und praxiserprobten agilen Entwicklungsprozesse. Die Bezeichnung "Scrum" (deutsch: Gedränge) kommt aus dem Rugby und bezeichnet das Aufeinandertreffen verschiedener Spieler "auf einem Haufen".

Entwickelt wurde Scrum von Ken Schwaber und Jeff Sutherland für die Softwareentwicklung, aber Scrum wird heute in allen möglichen Bereichen eingesetzt.

Scrum ist lediglich ein Framework und definiert z.B. keine konkreten Methoden für die Softwareentwicklung, wie es z.B. bei Extreme Programming der Fall ist (dort gibt es z.B. TDD, Refactoring, 40-Hour-Workweek etc.). Stattdessen verlässt sich Scrum auf selbstorganisierende Teams.

Scrum ist ein agiler, iterativer und inkrementeller Prozess, was bedeutet, dass er sich an die Gegebenheiten in konkreten Projekten anpassen lässt, in mehreren gleich ablaufenden Iterationen zum Ziel gelangt und dieses mit wachsendem Funktionsumfang erstellt wird.

Grundsätzlicher Ablauf von Scrum

Zunächst werden alle bekannten Anforderungen erfasst und geschätzt.

Dann werden die Anforderungen für die nächste Iteration identifiziert (z.B. wichtigste, kritischste, einfachste) und geplant.

Die Iteration ist time boxed. Sie wird nicht unterbrochen und auch nicht verlängert. Die Iteration heißt auch Sprint. Er ist üblicherweise 30 Tage lang.

Am Ende der Iteration steht dem Kunden ein "fertiges" Produkt zur Verfügung, das er sich anschauen und zu dem er Feedback geben kann.

Der Fortschritt der Arbeit wird täglich in einem kurzen Meeting im gesamten Team besprochen.

Die wichtigste Zahl bei Scrum ist die Drei: Es gibt jeweils drei Rollen, Artefakte und Meetings.

Rollen

Bei Scrum gibt es drei verschiedene Rollen: Team, Product Owner und Scrum Master.

Das Team führt die Arbeit aus und entscheidet wie viele Anforderungen es in einem Sprint umsetzen kann. Seine Arbeitsweise ist völlig frei durch das Team selbst bestimmbar, es gibt keine Vorgaben ("selbstorganisierendes Team").

Der Product Owner repräsentiert die Kundenbedürfnisse. Ihm "gehört" das Produkt und er trifft die nötigen Entscheidungen (in Abstimmung mit dem Kunden). Er entscheidet, welche Anforderungen für eine Version umgesetzt werden und wann die Software ausgeliefert wird. Er arbeitet eng mit dem Team zusammen und ist weit mehr als ein einfacher Produktmanager oder Projektleiter, hat aber keine Weisungsfunktion.

Der Scrum Master hilft allen Beteiligten, Scrum korrekt anzuwenden und unterstützt das Team, indem er z.B. "Impediments" (Hindernisse) beseitigt. Der Scrum Master ist kein Projektleiter, sondern sollte eher als "Consultant" oder "Coach" verstanden werden, der penibel prüft, ob die Regeln von Scrum eingehalten werden. Er hat daher auch keine Weisungsbefugnis.

Artefakte

Im Rahmen von Scrum werden drei verschiedene Artefakte erzeugt und bearbeitet: Das Product Backlog, die Sprint Backlogs und das (End-)Produkt. Die obige Darstellung zeigt die Zuordnung der einzelnen Artefakte zu den Phasen von Scrum.

Das Product Backlog ist das zentrale Instrument zum Erfassen und Managen von Anforderungen. Aus ihm werden die in den einzelnen Sprints umzusetzenden Aufgaben oder Tasks abgeleitet. Vereinfacht gesagt ist das Product Backlog eine absteigend nach Priorität sortierte Liste aller bereits geschätzten (!) Anforderungen an das Produkt.

Aus dem Poduct Backlog werden im Rahmen des Sprint Plannings die wichtigsten Anforderungen herausgenommen und für den nächsten Sprint in das Sprint Backlog übertragen. Dort werden alle nötigen Aktivitäten zum Erreichen des Sprint-Ziels aufgelistet und detailliert beschrieben. Das Team schwört sich auf das Sprint Backlog ein und verpflichtet sich zur Umsetzung der dort definierten Punkte ("commitment"). Das Sprint Backlog wird täglich aktualisiert.

Das Produkt(-inkrement) ist das wichtigste Artefakt, da letztlich nur die erstellte Software dem Kunden einen Mehrwert bietet und kein Product Backlog oder Sprint Backlog. Um den Kundenanforderungen bestmöglich zu entsprechen wird es in Iterationen entwickelt, um sich nicht von den Vorstellungen des Kunden wegzuentwickeln. Das Produkt beinhaltet: Das Programm, die Dokumentation und die nötigen Tests ("definition of done").

Meetings

Bei Scrum werden drei Meetings abgehalten: Das Sprint Planning, der Daily Scrum und der Sprint Review. Die obige Darstellung zeigt auch die Zuordnung der Meetings zu den Phasen von Scrum.

Beim Sprint Planning werden die im nächsten Sprint umzusetzenden Anforderungen vom Team realistisch geschätzt (z.B. muss die verfügbare Entwicklungszeit realistisch definiert werden, etwa mit 2 Tagen/Woche) und das Team legt sich verbindlich auf das Ziel des Sprints fest. Die Aufgaben werden an die Teammitglieder verteilt. Für die Schätzung kann z.B. Planning Poker gespielt werden.

Das Daily Scrum ist ein "time-boxed Standup-Meeting", das max. 15 Minuten dauern sollte und am besten direkt vor dem Sprint Backlog durchgeführt wird. Ziel ist, das Sprint Backlog auf den neusten Stand zu bringen und drei Fragen durch jedes einzelne Teammitglied beantworten zu lassen:

Was habe ich seit dem letzten Daily Scrum gemacht?

Was werde ich bis zum nächsten Daily Scrum tun?

Was hat mich bei meiner Arbeit behindert? (das sind die Impediments, die der Scrum Master beheben muss)

Beim Sprint Review am Ende eines Sprints wird das Produkt dem Kunden vorgeführt, damit dieser Feedback geben kann. Im besten Fall wird immer eine lauffähige Software präsentiert und keine theoretischen Überlegungen oder UML-Diagramme. Auf Basis des Kundenfeedbacks können im nächsten Sprint dann gezielt die Probleme behoben oder die nächstwichtigen Anforderungen umgesetzt werden.

Sonstiges

Optional wird von Zeit zu Zeit eine Sprint Retrospective am Ende eines Sprints durchgeführt, um sicherzustellen, dass die Arbeit im Projekt regelmäßig verbessert wird. Der Scrum-Prozess soll ständig optimiert werden und somit ein noch besseres Ergebnis geliefert werden.

Die Velocity des Teams sagt aus, wie schnell dieses Aufgaben abarbeiten kann. Sie pendelt sich im Laufe des Projekts auf einen stabilen Wert ein, da zu Beginn des Projekts die Schätzungen häufig ungenauer sind, weil z.B. die Domäne nicht bekannt ist, Technologien evaluiert werden müssen usw.

Auf dem Burndown Chart kann zu jedem Zeitpunkt der aktuelle Fortschritt des Projekts abgelesen werden. Hier werden im Daily Scrum die Schätzungen der aktuellen Aufgaben aktualisiert, wobei sich diese nach unten (erfolgreich bearbeitet) oder oben (Probleme aufgetreten) entwickeln können. Es geht nicht darum, die aufgewendete (vergangene) Arbeitszeit zu protokollieren, sondern darum, die Schätzung der zukünftigen Aufwände an die aktuellen Erkenntnisse anzupassen.

Literaturempfehlungen

In diesem Video erklärt Ken Schaber, einer der "Erfinder" von Scrum, den Prozess: Scrum et al..

Ein gutes deutsches Buch, das Scrum im Detail erklärt, ist Scrum: Agiles Projektmanagement erfolgreich einsetzen* von Roman Pichler. Ich habe es damals selbst während meines Studiums gelesen.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Das agile Manifest

Scrum – Wikipedia

Das Minimum Viable Product (MVP) (Grafik mit Auto vs. Skateboard/Roller)

Agile Ausbildung bei DATEV mit Uwe Ritthammer

Zusammenfassung

Scrum in deiner IT-Ausbildung

In meinen Fachgesprächen mit angehenden Fachinformatiker:innen Anwendungsentwicklung frage ich regelmäßig nach Scrum. Für dich als IT-Azubi gehört das Modell auch in anderen IT-Berufen zu den praxis- und prüfungsrelevanten Themen. Für das zeitlich begrenzte Abschlussprojekt empfehle ich das Wasserfallmodell. Kenntnisse über agile Modelle brauchst du ebenfalls, weil viele Unternehmen damit arbeiten.

...

Um das agile Manifest - die Grundlage aller agilen Vorgehensmodelle - geht es in der einhunderteinundsechzigsten Episode des IT-Berufe-Podcasts.

TL;DR

Aus meiner Prüfungsvorbereitung mit IT-Azubis kenne ich Fragen zu den Grundlagen agiler Softwareentwicklung. Das agile Manifest von 2001 setzt den Schwerpunkt auf Menschen und ihren Austausch, lauffähige Software, die Zusammenarbeit mit Kund:innen sowie darauf, auf Änderungen zu reagieren. Prozesse und Werkzeuge behalten dabei ihren Wert, ebenso wie Dokumentation, Verträge und Pläne. Für dein Projekt hängt das passende Vorgehen davon ab, wie klar die Anforderungen feststehen und wie viel sich während der Arbeit verändert.

Kapitelmarken

[00:00:00] Einstieg ins agile Manifest

[00:01:19] Agilität in Prüfungen und im Fachgespräch

[00:03:19] Herkunft und Bedeutung des agilen Manifests

[00:06:37] Werte und Spielraum für klassische Vorgehensweisen

[00:08:13] Wasserfallmodell und Big Design Up Front

[00:10:44] Veränderte Anforderungen und Folgen für Projekte

[00:13:26] Das magische Dreieck im Projektmanagement

[00:14:57] Wasserfallmodell beim IHK-Abschlussprojekt

[00:16:53] Ein Vorgehensmodell passend zum Projekt wählen

[00:17:52] Wortlaut und Grundgedanke des agilen Manifests

[00:19:49] Menschen und ihr Austausch

[00:22:48] Lauffähige Software und Dokumentation

[00:25:19] Zusammenarbeit mit Kund:innen

[00:27:26] Werkvertrag und Dienstleistungsvertrag

[00:30:40] Auf Änderungen reagieren und Pläne anpassen

[00:33:27] Den Arbeitsprozess an neue Erkenntnisse anpassen

[00:35:21] Änderungen während eines Scrum-Sprints

[00:37:26] Die vier Werte und ihre Bedeutung für IT-Berufe

[00:39:27] Bekannte Unterzeichner:innen

[00:42:09] Buch zum Einstieg und weiterführende Links

Inhalt

Das agile Manifest wurde 2001 von mehreren namhaften Softwareentwicklern aufgestellt als Gegenentwurf zum bisherigen Vorgehen bei der Softwareentwicklung.

Es bildet die Grundlage für alle agilen Projektmanagementmethoden und Softwareentwicklungsprozesse wie z.B. Scrum und Extreme Programming.

Das Manifest verbietet nicht die klassisches Vorgehensweise, zeigt aber bessere Alternativen auf, um zum gewünschten Ergebnis zu kommen.

Wasserfall und "klassische" Softwareentwicklung

BDUF: Big Design Up Front. Lange Planungsphase mit viel Dokumentation, danach "standardisierte" Entwicklung als "Abarbeitung" des Designs.

Umgang mit sich ändernden Anforderungen ist schwierig, weil das System zu starr ist, um darauf zu reagieren.

Durchschnittlich ändern sich aber 2% der Anforderungen an Projekte pro Monat.

Folge: Projekte verzögerten sich, wurden zu teuer oder lieferten nicht das gewünschte Ergebnis ("magisches Dreieck": Kosten, Zeit, Qualität).

Achtung: Wasserfall ist nicht immer schlecht. Es gibt auch Projekte, die sich gut dafür eignen (insb. das IHK-Abschlussprojekt).

Agiles Manifest

Siehe Manifesto for Agile Software Development.

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

Menschen sind wichtiger als Prozesse

Lauffähige Software ist wichtiger als Dokumentation

Zusammenarbeit ist wichtiger als Vertragsverhandlungen

Reaktion auf Änderungen ist wichtiger als das Verfolgen eines Plans

Einige Unterzeichner

Kent Beck: Begründer des Extreme Programming, Entwickler von JUnit, "Erfinder" von Test Driven Development (siehe Test Driven Development: By Example*)

Robert C. Martin: Autor von Clean Code*, Entwickler von FitNesse

Ward Cunningham: "Erfinder" des Wikis

Martin Fowler: Autor von Refactoring* und Patterns of Enterprise Application Architecture*

Ken Schwaber: "Erfinder" von Scrum

Literaturempfehlungen

Eine gute Einführung in agile Softwareentwicklung liefert das Buch Agile Softwareentwicklung* von Henning Wolf und Wolf-Gideon Bleek.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Manifesto for Agile Software Development

Zusammenfassung

Hintergrund und Prüfungsbezug

Als ich im Frühjahr 2021 zwei IT-Azubis bei ihrer Prüfungsvorbereitung begleitet habe, begegnete mir eine Frage zu den Eigenschaften agiler Softwareentwicklung. Auch in deiner Abschlussprüfung oder im Fachgespräch als Fachinformatiker:in Anwendungsentwicklung kann es darum gehen, warum du dein Projekt auf eine bestimmte Weise durchgeführt hast. Dafür brauchst du die Grundlagen des gewählten Vorgehens.

Auf agilemanifesto.org findest du das agile Manifest, das erfahrene Softwareentwickler:innen 2001 aus ihrer praktischen Arbeit heraus formuliert haben. Seine vier Werte bilden die Grundlage für agile Vorgehensweisen. Dazu gehören beispielsweise Scrum und Extreme Programming; auch Feature-Driven Development greift diese Ideen auf. Die Aussagen sind allgemein gehalten, während konkrete Vorgehensweisen daraus Regeln für den Arbeitsalltag ableiten.

Wie es zum agilen Manifest kam

Beim Big Design Up Front, kurz BDUF, werden die Anforderungen und der Entwurf vor dem Programmieren ausführlich ausgearbeitet. Im beschriebenen Wasserfallmodell entstehen zunächst Lasten- und Pflichtenhefte sowie Modelle, die den Entwickler:innen anschließend vorgeben, was sie umsetzen sollen.

Während eines längeren Projekts können neue Gesetze oder technische Möglichkeiten die Anforderungen verändern. Ebenso können sich Arbeitsabläufe ändern. Ein umfangreiches, bereits abgestimmtes Pflichtenheft muss dann überarbeitet und erneut besprochen werden, was Zeit kostet.

Wenn solche Änderungen schwer in den Ablauf passen, kann sich das Projekt verzögern oder teurer werden. Werden Termine und Budget eingehalten, kann das fertige Produkt inzwischen an den Bedürfnissen der Kund:innen vorbeigehen. Im Projektmanagement beschreibt das magische Dreieck die Zusammenhänge zwischen Kosten und Zeit sowie der Qualität des Ergebnisses.

Aus Erfahrungen mit solchen Projekten entstanden die vier Werte des agilen Manifests. Alle darin genannten Aspekte behalten ihren Wert; die agilen Werte erhalten besonderes Gewicht.

Die vier Werte

Menschen und ihr Austausch

Wenn eine Anforderung unklar ist, kannst du direkt bei deinem/deiner Kund:in nachfragen. Zum Projekt gehören neben den Entwickler:innen auch Designer:innen und weitere Beteiligte, etwa die Projektleitung oder Fachleute für Datenbanken.

Durch den direkten Austausch lassen sich Missverständnisse früh klären. Extreme Programming behandelt Kommunikation als zentralen Wert. Bei Scrum schafft beispielsweise das Daily Scrum regelmäßig Raum dafür, dass sich das Team abstimmt. Prozesse und Werkzeuge unterstützen diese Arbeit.

Lauffähige Software

Am Ende eines Scrum-Sprints soll dein:e Kund:in lauffähige Software ausprobieren können. Dabei wird sichtbar, ob die Funktionen zu den Anforderungen passen und was noch fehlt. Wenn du deine Zeit einteilen musst, erhält das Programmieren deshalb besonderes Gewicht.

Zur fertigen Software gehört auch die Dokumentation, damit dein:e Kund:in mit ihr arbeiten kann. Bei Scrum kann sie Teil der Definition of Done sein, die festhält, wann die Arbeit als fertig gilt.

Zusammenarbeit mit Kund:innen

Während sich Anforderungen verändern, brauchst du regelmäßigen Kontakt zu deinem/deiner Kund:in. Gemeinsam lässt sich besprechen, welche Funktionen gebraucht werden und wie das Projekt weitergeht. Verträge bilden dafür einen Rahmen.

Bei einem Werkvertrag wird ein bestimmtes fertiges Produkt vereinbart, einschließlich Preis und Termin. Ändern sich die Anforderungen, können daraus zusätzliche Abstimmungen oder Konflikte entstehen.

Ein Dienstleistungsvertrag sieht vor, dass geleistete Arbeit beziehungsweise Entwickler:innenstunden bezahlt werden. Für das beschriebene agile Vorgehen bietet diese Vertragsform Spielraum, etwa um den Umfang der Arbeit oder das Team anzupassen. Wie teuer das fertige Produkt wird, lässt sich dabei vorab schwerer bestimmen.

Auf Änderungen reagieren

Wenn du während des Projekts neue Erkenntnisse gewinnst, muss dein Plan angepasst werden können. Auch bei agilen Projekten planst du, welche Anforderungen du bearbeiten möchtest und wie du dabei vorgehst.

Agilität bedeutet Beweglichkeit. Sie betrifft sowohl die Software als auch den Arbeitsprozess. Beispielsweise kann ein Team seine Sprintlänge verändern, wenn die bisherige Länge zu den Anforderungen des Projekts schlecht passt.

Damit Entwickler:innen konzentriert arbeiten können, gibt es weiterhin verlässliche Arbeitsphasen. Bei Scrum werden Änderungen gewöhnlich für die nächste Iteration berücksichtigt. Dringende Ereignisse, etwa wenn ein:e Kund:in das Projekt beendet, können ein sofortiges Eingreifen erfordern.

Das Vorgehen für dein Projekt wählen

Für kurze Projekte mit klar festgelegten, stabilen Anforderungen kommt das Wasserfallmodell infrage. Beim damals beschriebenen IHK-Abschlussprojekt mit 70 Stunden empfehle ich dieses Vorgehen, weil der Zeitraum kurz und der Umfang eng begrenzt ist. Einzelne Schritte können wiederholt werden: Du kannst beispielsweise ein Mock-up dem Fachbereich zeigen und anhand der Rückmeldung überarbeiten.

Wenn dein Projekt länger dauert oder das gewünschte Ergebnis noch offen ist, bietet agiles Arbeiten Raum für neue Erkenntnisse. Auch außerhalb der Softwareentwicklung finden agile Vorgehensweisen Anwendung, etwa in der Administration oder bei der Daten- und Prozessanalyse.

Bekannte Unterzeichner:innen

Aus dem Kreis der Unterzeichner:innen greife ich fünf Personen heraus:

Kent Beck begründete Extreme Programming, entwickelte JUnit mit und schrieb Test-Driven Development by Example.

Robert C. Martin, auch Uncle Bob genannt, ist der Autor von Clean Code.

Ward Cunningham entwickelte das erste Wiki.

Martin Fowler schrieb Refactoring sowie Patterns of Enterprise Application Architecture.

...