IT-Berufe-Podcast Archiv

Um konkretere Tipps zur Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung (nach der Neuordnung der IT-Berufe 2020) geht es in der einhunderteinundsiebzigsten Episode des IT-Berufe-Podcasts. TL;DR Nach meiner Mitarbeit beim Korrigieren der ersten Prüfung im Herbst 2021 empfehle ich dir, für Teil 1 der gestreckten Abschlussprüfung mindestens fünf Jahrgänge der alten Ganzheitlichen Aufgabe 2 (GA2) vollständig durchzuarbeiten. Die Prüfung umfasst ein breites Themenfeld und zählt 20 Prozent deiner Abschlussnote; alle vier Handlungsschritte musst du bearbeiten. Plane mehrere Monate zum Lernen ein, wobei du auch übst, dein Wissen auf konkrete Situationen anzuwenden und Antworten in eigenen Worten zu schreiben. Mit meinen IT-Azubis beginne ich spätestens sechs Monate nach Ausbildungsstart, etwa ein Jahr vor der Prüfung. Kapitelmarken [00:00:00] Ergänzende Tipps zu Teil 1 der Abschlussprüfung [00:01:17] Alte GA2 als Grundlage zum Üben [00:03:50] Inhalte und Aufbau der ersten Prüfung [00:04:59] Projektplanung und Netzplan [00:05:40] Energiekosten und elektrotechnische Aufgaben [00:07:08] Fehler im PowerShell-Skript finden [00:07:38] Projektarbeit und RAID [00:09:08] IT-Sicherheit, Datenschutz und Backup [00:11:22] Gleiche Aufgaben für alle IT-Berufe [00:13:06] Pflichtaufgaben und Punkteverteilung [00:14:51] Anspruch der Prüfung und Nähe zur früheren GA2 [00:17:17] Fachwissen auf konkrete Situationen anwenden [00:19:14] Rechenaufgaben und vorausgesetztes Wissen [00:21:10] Offene Aufgaben und Umfang der Programmierung [00:24:05] Folgefehler und Fragen beim Korrigieren [00:25:30] Sicherheitsthemen vertiefen [00:26:24] Schulstoff und selbstständiges Lernen [00:28:53] Erste Ergebnisse und IHK-Prüfungsstatistiken [00:31:17] Alte GA2 durcharbeiten und Zeit einplanen [00:32:49] Neue Inhalte der Ausbildungsordnung beachten [00:34:04] Früh anfangen und passende Literatur wählen [00:34:59] Wissen anwenden und frei formulieren [00:36:18] Alte Zwischenprüfungen als Ergänzung [00:36:51] Mein Zeitplan für die IT-Azubis [00:37:55] Fragen und Erfahrungen zur Prüfung teilen [00:38:44] Ausbildungsbegleitung per Newsletter Inhalt Als Ergänzung zu Episode #168: Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung der IT-Berufe kommen hier einige konkrete Tipps zur Prüfungsvorbereitung auf den ersten Teil der gestreckten Abschlussprüfung der IT-Berufe. Inhalte der ersten Prüfung Handlungsschritt 1: Projektplanung Was definiert ein Projekt? SMARTe Ziele erklären Netzplan vervollständigen, kritischen Pfad finden Handlungsschritt 2: Energiekosten Vergleich des Stromverbrauchs verschiedener Netzteile Amortisationsrechnung des Netzteils Weitere Maßnahmen zum Stromsparen vorschlagen Berechnung der erlaubten Geräte für eine Steckdose Fehler in kurzem PowerShell-Script finden Handlungsschritt 3: Projektarbeit Aufgaben im Projekt-Kickoff-Meeting Kosten für Einsatz von externen Mitarbeitern berechnen Dauer der Projektlaufzeit mit eigenen Mitarbeitern berechnen Vor-/Nachteile Remote-Arbeit vs. Vor-Ort Schulungsmaßnahmen erkläutern RAID 0, 1 und 5 erklären Handlungsschritt 4: IT-Security und Datenschutz Schutzmaßnahmen Vertraulichkeit, Integrität und Verfügbarkeit zuordnen und begründen Konkrete Maßnahmen zu Sicherheitsmechanismen nennen Schutzbedarfe verschiedener Anwendungen begründen Rechtliche Grundlage des Datenschutzes nennen Anforderungen an sichere Passwörter erläutern Backup-Verfahren bewerten Alternatives Backup-Verfahren vorschlagen Meine Einschätzung und Feedback zu den Prüfungsinhalten Die Prüfung war für alle IT-Berufe identisch. Die Aufgaben sind alle im Freitext zu beantworten. Es gibt keine Multiple-Choice-Aufgaben mehr wie früher in der Zwischenprüfung. Es darf kein Handlungsschritt gestrichen werden. Die Handlungsschritte sind unterschiedlich gewichtet: zwischen 24 und 26 Punkten statt einheitlich 25 Punkten. Niveau der Prüfungsfragen vergleichbar mit früherer GA2 (Ganzheitliche Aufgaben 2, Kernqualifikationen für alle IT-Berufe). Nicht nur auswendig gelernte Inhalte abspulen, sondern erläutern, begründen und bewerten. Einige "Standardinhalte" der ehemaligen GA2 wurden abgefragt. Durchaus triviale Rechenaufgaben (Multiplikation/Division, Dreisatz). Auch implizites Wissen zur Beantwortung der Fragen nötig (z.B. Umrechnung Watt/Ampere, Amortisation). Wenig Programmierung: nur Fehler in kurzem Code finden. Code eher FISI-lastig (PowerShell). Bei der Aufgabe zum Netzplan könnten sich Folgefehler ergeben, wenn die erste Teilaufgabe nicht korrekt beantwortet wurde. Eigener Handlungsschritt zu Security und Datenschutz. Nicht alle abgefragten Inhalte wurden bis zur Prüfung in der Berufsschule behandelt. Die ersten Ergebnisse waren durchwachsen (Noten 3-5). Tipps zur Vorbereitung auf die Prüfung Alte IHK-Prüfungen vor 2021 durchgehen mit deutlichem Fokus auf GA2. Insbesondere die "neuen" Inhalte des Ausbildungsrahmenplans (z.B. Security, Datenschutz) anschauen. Früh mit dem Lernen anfangen! Die Menge an Stoff ist sehr groß. Nicht nur auswendig lernen, sondern verstehen und mit eigenen Worten formulieren und anwenden lernen. Alte Zwischenprüfungen können als Ergänzung bearbeitet werden, helfen aber nicht wirklich weiter. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Neuordnungsverfahren der IT-Berufe: Interview mit Silvio Kennecke und Jörg Ferrando Datenschutz vs. Datensicherheit vs. Datensicherung Prüfungsstatistik der Industrie- und Handelskammer (Vorauswahl Oldenburg) Zusammenfassung Worauf sich meine Empfehlungen beziehen Ich habe beim Korrigieren der ersten Prüfung zu Teil 1 der gestreckten Abschlussprüfung im Herbst 2021 mitgearbeitet und mich darüber mit anderen Prüfer:innen aus meinem Prüfungsausschuss ausgetauscht. Darauf beruhen meine ergänzenden Tipps zur Prüfungsvorbereitung. Zu diesem Zeitpunkt lag erst eine solche Prüfung vor, sodass spätere Prüfungen andere Schwerpunkte haben können. Meine Literaturtipps aus Episode 168 gelten weiterhin. Zusätzlich empfehle ich dir besonders die alten Ganzheitlichen Aufgaben 2 (GA2), weil deren Aufgaben und Anspruch dem ersten neuen Prüfungstermin ähneln. Mit meinen eigenen IT-Azubis gehe ich genauso vor. Wie die Prüfung aufgebaut war Für alle IT-Berufe waren die Aufgaben identisch. Auch als Fachinformatiker:in Anwendungsentwicklung brauchst du deshalb Wissen aus dem gesamten gemeinsamen Themenfeld, einschließlich elektrotechnischer Grundlagen. Die Prüfung enthielt vier Handlungsschritte, die du vollständig bearbeiten musstest. Pro Handlungsschritt gab es zwischen 24 und 26 Punkten, insgesamt 100 Punkte. Alle Aufgaben waren offen gestellt. Deine Antworten wurden von Prüfer:innen korrigiert. Teil 1 zählt 20 Prozent deiner Abschlussnote, wodurch dein Ergebnis die erreichbare Gesamtnote beeinflusst. Welche Inhalte abgefragt wurden Projektplanung Im ersten Handlungsschritt solltest du Eigenschaften eines Projekts nennen und erklären, wofür die Buchstaben bei SMART-Zielen stehen. Den größten Anteil machte ein teilweise vorgegebener Netzplan aus, den du vervollständigen solltest. Dazu gehörten Zeitpunkte für Anfang und Ende sowie der kritische Pfad. Energiekosten und elektrotechnische Grundlagen Du solltest den Stromverbrauch verschiedener Netzteile berechnen und feststellen, wann sich die höheren Anschaffungskosten eines sparsameren Netzteils durch geringere Stromkosten ausgleichen. Weitere Aufgaben verlangten Vorschläge zum Stromsparen, etwa Bildschirme abends auszuschalten. Außerdem war zu berechnen, wie viele Geräte an eine bestimmte Steckdose angeschlossen werden dürfen. Dafür musstest du die angegebenen Leistungen in Watt mit der zulässigen Stromstärke in Ampere in Beziehung setzen. Die nötige Formel war vorausgesetzt. Zu diesem Handlungsschritt gehörte auch ein kurzes PowerShell-Skript aus einem Backup-Kontext, in dem zwei Fehler zu finden waren. Die Syntax war erläutert, sodass du den Code auch ohne vorherige PowerShell-Erfahrung verstehen konntest. Fehler betrafen einen Vergleichsoperator und einen Divisor. Projektarbeit Hier ging es um Aufgaben in einem Projekt und das Ziel eines Kick-off-Meetings. Anhand von Stundensätzen solltest du berechnen, welche Kosten beim Einsatz interner beziehungsweise externer Mitarbeiter:innen entstehen. Auch die mögliche Projektdauer spielte eine Rolle. Weitere Teilaufgaben behandelten Vor- und Nachteile von Remote-Arbeit sowie Arbeit vor Ort. Du solltest außerdem Möglichkeiten erläutern, Mitarbeiter:innen zu schulen. Für RAID 0, RAID 1 und RAID 5 waren Erklärungen aus dem Gedächtnis gefragt. Dazu gab es keine Zeichnung als Hilfestellung. IT-Sicherheit und Datenschutz Der vierte Handlungsschritt enthielt mehrere Aufgaben zu Sicherheit und zum Umgang mit Daten: Konkrete Maßnahmen im Unternehmen waren den Schutzzielen Vertraulichkeit, Integrität und Verfügbarkeit zuzuordnen. Du solltest weitere Maßnahmen vorschlagen, um Systeme abzusichern, beispielsweise einen Virenscanner. Für verschiedene Datenkategorien einer Krankenhausanwendung war der Schutzbedarf zu begründen. Dazu gehörten etwa Patient:innen- und Behandlungsdaten. Eine rechtliche Grundlage für den Datenschutz war mit einer konkreten Fundstelle zu nennen, etwa aus der DSGVO. Anforderungen an sichere Passwörter waren zu erläutern, darunter Länge und Komplexität. Ein bestehendes Backup-Verfahren solltest du bewerten und eine bessere Alternative vorschlagen. Welches Wissen und welche Fähigkeiten du brauchst Nach meinen Erfahrungen mit dieser Prüfung liegt der Anspruch nahe an der früheren GA2, die gemeinsame Kernqualifikationen der IT-Berufe abfragte. Teil 1 steht regulär nach ungefähr 18 Monaten an. Beim ersten Termin hatten manche Teilnehmer:innen, die ihre Ausbildung verkürzten, erst etwa ein Ausbildungsjahr hinter sich. Die Aufgaben verlangen Fachwissen, das du auf konkrete Fälle übertragen kannst. Beim Backup-Verfahren etwa musstest du Schwächen erkennen und daraus einen besseren Vorschlag ableiten....

Ü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. ...

Um reguläre Ausdrücke - das Schweizer Taschenmesser für ITler - geht es in der einhundertsechzigsten Episode des IT-Berufe-Podcasts. TL;DR Ich arbeite fast täglich mit regulären Ausdrücken, um Texte nach Mustern zu durchsuchen und gefundene Inhalte zu verändern. Mit wenigen Grundbausteinen kannst du beispielsweise E-Mail-Adressen herausfiltern oder Vor- und Nachnamen vertauschen. Als IT-Azubi kannst du diese Kenntnisse in vielen Editoren und auf der Kommandozeile einsetzen. Für beliebige HTML- und XML-Dokumente brauchst du einen passenden Parser; bei Anwendungen mit hohen Anforderungen an die Laufzeit solltest du den Rechenaufwand regulärer Ausdrücke beachten. Kapitelmarken [00:00:01] Einstieg: Reguläre Ausdrücke im IT-Alltag [00:00:49] Was reguläre Ausdrücke leisten [00:03:04] Die Syntax verstehen und mit Websites ausprobieren [00:06:13] Muster beschreiben und Zeichen getrennt von ihrer Anzahl festlegen [00:09:35] Unterschiedliche Schreibweisen von Meier suchen [00:10:50] E-Mail-Adressen aus Dateien herausfiltern [00:12:03] Einsatz in Systemintegration und beim Bearbeiten von Listen [00:13:06] Wörtlich suchen und Sonderzeichen escapen [00:14:40] Erlaubte Zeichen und Grenzen des E-Mail-Beispiels [00:18:12] Zeichenbereiche mit eckigen Klammern bilden [00:20:30] Zeichenbereiche negieren [00:22:01] Zeilenanfang und Zeilenende erkennen [00:24:15] Der Punkt als Platzhalter [00:25:19] Quantifizierer und genaue Anzahlen [00:28:53] Ein vereinfachtes Suchmuster für E-Mail-Adressen [00:31:16] Alternativen mit der Pipe verbinden [00:33:03] Gruppen bilden und Inhalte beim Ersetzen wiederverwenden [00:36:40] Die wichtigsten Syntaxbausteine im Überblick [00:38:41] Praxisbeispiel: UUIDs herausfiltern [00:40:28] E-Mail-Adressen suchen und Namen vertauschen [00:41:33] Leerzeichen am Zeilenende entfernen [00:42:07] Markdown-Aufzählungszeichen einfügen [00:43:47] Felder für Klassen vorbereiten und im Blockmodus bearbeiten [00:45:54] Links zwischen HTML und Markdown umschreiben [00:47:29] Grenzen beim Verarbeiten von HTML und XML [00:49:17] Rechenaufwand und der Ausfall von Stack Overflow [00:50:37] Reguläre Ausdrücke in Shells, Editoren und IDEs [00:51:51] Literaturempfehlung und Websites zum Lernen [00:53:14] Feedback und Abschied Inhalt Ich schwärme immer mal wieder von regulären Ausdrücken. Das liegt wohl einfach daran, dass ich fast täglich mit ihnen arbeite. Sie sind einfach so unglaublich vielseitig verwendbar und machen ITlern das Leben leichter - wenn man sie beherrscht. Nicht umsonst gibt es diesen "Witz": Ich hatte ein Problem und versuchte es mit regulären Ausdrücken zu lösen. Nun habe ich zwei Probleme. In den Händen eines erfahrenen Anwenders sind reguläre Ausdrücke allerdings äußerst hilfreich. Sinn regulärer Ausdrücke Reguläre Ausdrücke dienen der Mustererkennung in Zeichenketten und sind quasi Platzhalter on steroids. Statt der einfachen Platzhalter wie * oder ? z.B. in Dateinamen, gibt es viele verschiedene Platzhalter, Quantifizierer und weitere Regeln, um Muster in Texten zu definieren. Nach diesen Mustern kannst du suchen oder du kannst sie zum Ersetzen von Inhalten benutzen. Teilmuster lassen sich gruppieren und beim Ersetzen wiederverwenden. So gut wie jede Programmiersprache enthält eine eingebaute Unterstützung für reguläre Ausdrücke. Jeder vernünftige Texteditor unterstützt reguläre Ausdrücke beim Suchen und Ersetzen genauso wie eine gute Shell (z.B. Bash oder PowerShell). Grundlegende Muster konkreten Zeichen(-folgen): hallo Bereiche: [], z.B. [a-z], [0-9], [aeiou] Negation mit ^, z.B. [^abc] Zeilenanfang: ^ (nicht mit der Negation verwechseln!) Zeilenende: $ Platzhalter für ein beliebiges Zeichen: . Alternativen: A|B Quantifizierer (stehen hinter dem Muster) einmal oder keinmal (0..1): ? keinmal, einmal oder mehrmals (0..n): * einmal oder mehrmals (1..n): + genaue Anzahl: {8}, {2,5} (2 bis 5 mal) Gruppen: (), Referenz mit $1 Escapen von besonderen Zeichen (insb. alle obigen): \ Anwendungsfälle aus meiner Praxis Reguläre Ausdrücke gehören in den Werkzeugkasten jedes ITlers! Egal ob Anwendungsentwicklung oder Systemadministration, reguläre Ausdrücke können vielfältig eingesetzt werden. In der Linux-Administration können z.B. Black- und Whitelists für Hostnamen mit regulären Ausdrücken definiert werden. Die Apache-Konfiguration verwendet ebenfalls reguläre Ausdrücke. Auf der Linux-Kommandozeile kannst du mit grep in Dateien nach regulären Ausdrücken suchen. sed ermöglicht dir die Massenverarbeitung von Dateien. Das Suchen und Ersetzen im vi wird standardmäßig auch mit regulären Ausdrücken gemacht und du kannst sogar mit ihnen navigieren ($ springt z.B. zum Ende der Zeile). Suchen und Ersetzen in Dateien Listen umformatieren Nachname/Vorname zu Vorname/Nachname Anfang oder Ende von Zeilen manipulieren Markdown in HTML und umgekehrt Feldnamen mit public String ; umschließen Batchdatei generieren zum Verschieben von Dateien Whitespace trimmen UUIDs/Domains/Mails in Text/Logs finden Konkrete Beispiele Gerade vor wenigen Tagen hatte ich die - eigentlich triviale - Aufgabe, ein paar Dateien umzubenennen, die ein bestimmtes Präfix hatten. Dieses Präfix sollte ausgetauscht werden. Anstatt die Dateien per Hand umzubenennen (oder die entsprechende Shell-Funktion zu nutzen ;-) ), habe ich mir mit einem simplen regulären Ausdruck in wenigen Sekunden ein Shell-Script gebaut, das die Aufgabe für mich löst. Basis war die Liste der Dateien, die ich in der PowerShell mit dir | ac liste.ps1 erstellt habe. prefix-Datei1.txt prefix-Datei2.txt ... prefix-Datei100.txt Mit dem Suchen-/Ersetzen-Muster /^(prefix-(.*))$/move $1 neuerPrefix-$2/g im Vim wurde daraus: move prefix-Datei1.txt neuerPrefix-Datei1.txt move prefix-Datei2.txt neuerPrefix-Datei2.txt ... move prefix-Datei100.txt neuerPrefix-Datei100.txt Die Datei konnte ich dann einfach mit .\liste.ps1 ausführen und war fertig! UUIDs suchen Text: Text mit UUIDs wie z.B. 550e8400-e29b-11d4-a716-446655440000 mittendrin RegEx: [a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12} Suchergebnis: 550e8400-e29b-11d4-a716-446655440000 E-Mail-Adressen suchen Text: Stefan Macke (mail@example.com) hat einen Podcast. RegEx: [a-z]+@[a-z]+\.[a-z]{2,3} (nicht ausreichend für echte Mails!) Suchergebnis: mail@example.com Vor-/Nachnamen vertauschen Text: Stefan Macke RegEx: (.+) (.+) Ersetzen durch: $2, $1 Ergebnis: Macke, Stefan Trailing Whitespace entfernen Text: Zeile mit Leerzeichen am Ende RegEx: +$ Ersetzen durch: `` Ergebnis: Zeile mit Leerzeichen am Ende Aus Zeilen Markdown-Aufzählungen machen Text: Listenpunkt 1 RegEx: ^ Ersetzen durch: * (Asterisk muss ggfs. escapet werden) Ergebnis: * Listenpunkt 1 Aus Namen Java-Attribute machen Text: alterDerPersonInJahren RegEx: (.+) Ersetzen durch: private Integer $1; Ergebnis: private Integer alterDerPersonInJahren; Aus HTML-Links Markdown machen Text: IT-Berufe-Podcast RegEx: ([^

Um die Ermittlung und Dokumentation von Anforderungen für Projekte geht es in der einhundertneunundfünfzigsten Episode des IT-Berufe-Podcasts. TL;DR Für dein Abschlussprojekt empfehle ich dir, die Anforderungen selbst mit den beteiligten Stakeholdern zu klären und nachvollziehbar aufzuschreiben. Dabei gehören funktionale und nicht funktionale Anforderungen dazu, denn Qualität bemisst sich daran, wie gut das Ergebnis die Erwartungen erfüllt. Mit Interviews oder weiteren Methoden findest du heraus, was gebraucht wird; präzise und testbare Anforderungen helfen dir anschließend, den Aufwand zu schätzen und das Ergebnis zu prüfen. User Stories und das MoSCoW-Prinzip bieten dafür einen überschaubaren Rahmen, wobei du dich an der Arbeitsweise deines Unternehmens orientieren solltest. Kapitelmarken [00:00:36] Anforderungsermittlung für IT-Abschlussprojekte [00:01:50] Deine Aufgaben beim Klären der Anforderungen [00:02:57] Lastenheft und Pflichtenheft [00:05:45] Qualität und unterschiedliche Erwartungen [00:10:42] Funktionale und nicht funktionale Anforderungen [00:14:36] Stakeholder für dein Projekt finden [00:15:52] Anforderungen aus Fachbereich, Entwicklung und Support [00:19:07] Gesetze, Standards und Audits [00:21:52] Anforderungen aus dem kulturellen Umfeld [00:24:52] Den Betriebsrat einbeziehen [00:25:25] Interviews und weitere Methoden zum Ermitteln [00:28:18] Arbeitsabläufe beobachten und bestehende Systeme untersuchen [00:31:53] Anforderungen verständlich und präzise formulieren [00:33:24] Eindeutige, kleine und schätzbare Anforderungen [00:37:41] Den fachlichen Zweck einer Anforderung hinterfragen [00:39:44] Anforderungen testbar machen [00:40:58] Ein einheitlicher Aufbau für Anforderungen [00:42:59] Snow Cards und das Volere-Template [00:45:24] Geänderte Anforderungen und agiles Arbeiten [00:47:00] Zufriedenheit und Unzufriedenheit getrennt bewerten [00:50:04] Anforderungen als User Stories beschreiben [00:53:16] Mit MoSCoW priorisieren [00:55:00] Projektumfang abgrenzen und Feature Creep vermeiden [00:58:10] Die passende Methode für dein Abschlussprojekt [00:59:06] Rückblick und Hinweise zur Episode Inhalt Spätestens für das Abschlussprojekt im dritten Ausbildungsjahr müssen alle Azubis in den IT-Berufen Anforderungen ermitteln. Wen man dabei berücksichtigen sollte, wie man die Anforderungen erhebt und wie man sie verständlich dokumentiert, das erkläre ich hier. Qualität Beginnen wir zunächst mit den Anforderungen selbst. Dabei starte ich gerne mit dem Begriff der Qualität. Qualität ist definiert als Übereinstimmung mit den Anforderungen. Dabei können diese Anforderungen von sehr unterschiedlichen Personen oder Personengruppen gestellt werden. Daher ist es wichtig, alle am Projekt beteiligten Personen zu befragen. Anforderungen Es gibt grundsätzlich zwei verschiedene Arten von Anforderungen: funktionale und nicht-funktionale. Funktionale Anforderungen beziehen sich direkt auf die zu erbringende Leistung des Produkts, bspw. die Möglichkeit, Text in einer Textverarbeitungssoftware fett darzustellen. Nicht-funktionale Anforderungen beschreiben den ganzen Rest "drumherum", also z.B. die Performance, Sicherheit, Stabilität, Fehlertoleranz, Benutzbarkeit usw. Sie sind meistens sehr schwer zu definieren, da sie oftmals nicht bewusst wahrgenommen, sondern einfach erwartet werden. Daher werden sie oft vergessen oder können nur schwer quantifiziert werden. Es ist unsere Aufgabe als Projektleiter diese Anforderungen trotzdem so gut es geht zu dokumentieren, damit es am Ende kein böses Erwachen gibt, wenn sie nicht umgesetzt sind. Eine gute Übersicht über die zahlreichen möglichen nicht-funktionalen Anforderung bietet die Norm ISO 9126, die den Begriff der Softwarequalität definiert. Stakeholder Wer definiert überhaupt die Anforderungen an eine Software (oder allgemein an ein zu fertigendes Produkt)? Ein Stakeholder ist jede Person, Gruppe oder Institution, die an dem zu entwickelnden Produkt oder dessen Herstellungsprozess in irgendeiner Weise – positiv oder negativ – interessiert ist. Hier kommt eine nicht vollständige Liste möglicher Stakeholder unserer Projekte. Kunde: Der Kunde bezahlt uns für das Projekt. Seine Anforderungen sollten wir auf jeden Fall berücksichtigen. Anwender: Der Anwender ist die Person, die letztendlich mit unserem Produkt täglich arbeiten muss. Management: Auch das Management könnte Anforderungen an unser Produkt stellen. Marketing: Aus dem Bereich des Marketings kommen Anforderungen wie die Corporate Identity. Entwickler: Die Entwickler haben ganz eigene Anforderungen, wie z.B. eine Versionverwaltung. Support: Der Support muss nach Einführung des Produkts den Anwendern Hilfestellung leisten und bringt seine ganz eigenen Anforderungen mit. Gesetzgeber: In fast jedem Projekt gilt es auch bestimmte Gesetze und Richtlinien einzuhalten. Standards: Gerade in der IT gibt es eine Fülle von Standards, an die wir uns halten sollten, z.B. HTTP für Webserver. Auditoren: Wirtschaftsprüfer und andere Auditoren stellen ebenfalls Anforderungen an unsere Software, wie z.B. die Nachvollziehbarkeit von Benutzeraktionen. Kulturkreis: Auch der Kulturkreis, in dem die Software eingesetzt wird, hat bestimmte Anforderungen. So kann sich z.B. die Sprache je nach Land deutlich unterscheiden. Methoden zur Anforderungsermittlung Wenn wir wissen, wenn wir nach Anforderungen fragen müssen, ist die nächste Aufgabe, die Anforderungen auch wirklich aus diesen Menschen herauszukommen. Dafür gibt es neben dem Interview auch verschiedene weitere Methoden. Interview: Die einfachste Methode ist wohl, den Stakeholder direkt zu befragen. Selbstaufschreibung: Wenn dies nicht möglich ist, kann er seine Anforderungen auch selbst verschriftlichen. Fragebogen: Etwas mehr Struktur bietet dabei eventuell ein vordefinierter Fragebogen. Brainstorming: Gerade zu Beginn eines Projekts kann sich ein Brainstorming zur allgemeinen Definition von Anforderungen anbieten. Mind-Mapping: Auch eine Mind-Map hilft vielleicht die verschiedenen Bereiche der Projektes zu betrachten. Apprenticing: Hierbei spielt der Anforderungsermittler "Azubi" und lässt sich vom Anwender die Aufgaben erklären. Feldbeobachtung: Hierbei setzt sich der Anfoderungsermittler einfach neben den Anwender und beobachtet ihn bei seiner Arbeit. Workshop: In einem Workshop können mehrere Teilnehmer gemeinsam Anforderungen erarbeiten. Systemarchäologie: Wenn es schon ein bestehendes System gibt, können aus diesem Anforderungen für das neue System abgeleitet werden. Raten: Zuletzt kann es durchaus auch sinnvoll sein, einfach mal aufs Blaue drauflos zu raten. Anforderungen an Anforderungen Wenn wir nun wissen, wen wir was fragen müssen und wie wir dies tun können, müssen wir nur noch eine geeignete Form der Dokumentation der Anforderungen finden. Einige Anforderungen an die Definition der Anforderungen selbst folgen hier. eindeutig: Eine Anforderung soll immer eindeutig und nicht mehrdeutig sein, damit es keine Missverständnisse gibt. atomar: Anforderungen sollen nicht weiter unterteilbar sein. klein: Anforderungen dürfen nicht zu groß sein. schätzbar: Für die Projektplanung ist es wichtig, dass Anforderungen auch geschätzt werden können. unabhängig: Im besten Fall sind die Anforderungen unabhängig voneinander, damit die Umsetzung parallelisiert werden kann. nützlich: Die Anforderungen sollten auch einen echten Nutzen bringen. testbar: Wichtig ist auch festzulegen, wie die Umsetzung der Anforderungen geprüft werden kann. einheitlich: Zuletzt sollten Anforderungen immer gleichartig definiert werden. Wir schreiben keinen blumigen Roman. Methoden zur Dokumentation von Anforderungen Snow Cards aus dem Volere-Template Snow Cards aus dem Volere-Template sind eine Möglichkeit, um Anforderungen detailliert zu definieren. Sie umfassen für jede Anforderung mehrere Felder, die ausgefüllt werden müssen. Damit ist eine Klassifizierung und Priorisierung sehr einfach möglich. Allerdings erfordern sie auch einen enormen Zeitinvest. Allein das Inhaltsverzeichnis über die möglichen verschiedenen Anforderungen, die sich im Projekt ergeben können, ist mehrere Seiten lang. Auch wenn das Template selbst Geld kostet, kann dir die Übersicht der möglichen Anforderungen auf der Website vielleicht ein paar Hinweise geben, an was du in deinem Projekt noch denken musst. User Stories Eine einfache Möglichkeit, Anforderungen zu dokumentieren, stellen die User Stories aus dem Extreme Programming dar. Jede Anforderung besteht aus einem Satz, der aus der Sicht eines Anwenders beschreibt, was er mit der Software tun will und warum. As a bank client, I would like to log into the bank’s internet banking in order to check my account balance. Anhand dieser wenigen Informationen, die auch super auf kleine Karteikarten passen, können wir schon eine Priorisierung vornehmen, mögliche Alternativen finden und den Fokus auf die Umsetzung legen. Deswegen sind sie gerade in agilen Vorgehensmodellen wie Scrum, Kanban oder eXtreme Programming so beliebt. MoSCoW Außerdem kann man Anforderungen auch nach dem MoSCoW-System vorpriorisieren. The system... MUST have this SHOULD have this if at all possible COULD have this if it does not affect anything else WON’T have this time but WOULD like in the future Die MoSCoW-Methode finde ich sehr oft in Abschlussprojekten von IT-Azubis. Mit ihr lassen sich Anforderungen recht einfach priorisieren. Und oftmals reicht dies auch für den sehr begrenzten Umfang der Abschlussprojekte (80 bzw. 40 Stunden) aus. Literaturempfehlung Das Lehrbuch der Softwaretechnik* von Helmut Balzert hat zwar einen großen Umfang, beschreibt aber sehr gut das Vorgehen beim Requirements Engineering, also dem englischen Wort für Anforderungsermittlung. Die Buchreihe kann ich sehr empfehlen, auch wenn sie vielleicht eher an Studenten gerichtet ist und nicht so sehr an Auszubildende. * Links Permalink zu dieser Podcast-Episode ...

Um den Buchclub zu Funktionale Programmierung in Java geht es in der einhundertachtundfünfzigsten Episode des IT-Berufe-Podcasts. TL;DR Ich empfehle dir "Funktionale Programmierung in Java" von Herbert Prähofer als Lektüre ab dem zweiten Ausbildungsjahr. Das Buch vermittelt funktionale Grundlagen mit ausführlichen Codebeispielen und behandelt auch asynchronen Code sowie eigenschaftsbasierte Tests. Für deine Praxis und mögliche Prüfungsfragen sind besonders reine Funktionen, Funktionen höherer Ordnung und unveränderbare Daten interessant. Mit map und flatMap kannst du Daten verarbeiten und Funktionsaufrufe verketten, während CompletableFuture dir hilft, mit später verfügbaren Ergebnissen zu arbeiten. Kapitelmarken [00:00:00] Buchclub: Funktionale Programmierung in Java [00:01:53] Funktionale Konzepte für IT-Azubis und Prüfungen [00:05:09] Stärken des Buchs und praxisnahe Beispiele [00:08:38] Java-Schwerpunkt und anspruchsvolle Beispiele [00:11:41] Buchkapitel: Einstieg und sprachliche Grundlagen [00:13:08] Seiteneffekte und Funktionsparameter [00:14:28] Funktionen kombinieren und funktionale Datenstrukturen [00:15:47] Streams und parallele Verarbeitung [00:17:11] Asynchronität und Reactive Streams im Buch [00:18:30] Eigenschaftsbasierte Tests und Shrinking [00:20:54] Weiterführende Konzepte und Leseempfehlung [00:22:04] Funktionale Grundlagen für mögliche Prüfungsfragen [00:23:06] Lambda-Ausdrücke als anonyme Funktionen [00:25:00] Typ-Inferenz und statische Typisierung [00:27:41] Algebraische Datentypen: Produkt- und Summentypen [00:32:13] Pattern-Matching [00:34:47] Generics und parametrisierbare Klassen [00:37:34] Ko- und Kontravarianz [00:42:15] Begrenzte Wildcards in Java [00:43:25] Grundprinzipien der funktionalen Programmierung [00:44:01] Funktionen als First Class Citizens [00:45:22] Reine Funktionen und Seiteneffekte [00:47:52] Funktionen höherer Ordnung [00:50:43] Bedarfsauswertung und unendliche Folgen [00:53:18] Unveränderbare Datenstrukturen [00:55:40] Rekursion und Tail Call Optimization [00:58:21] Referenzielle Transparenz [00:59:59] Funktoren und map [01:01:24] Monoide, fold und neutrale Elemente [01:04:52] Monaden und flatMap [01:08:46] Funktionsketten und Streams im Alltag [01:11:18] Asynchrone Abläufe und reagierende Anwendungen [01:13:09] CompletableFuture und später verfügbare Ergebnisse [01:14:32] Optional und Future über Funktionen verarbeiten [01:16:48] Rückblick und Einordnung für die Prüfung [01:19:16] Ergänzende Links und Feedback Inhalt Die folgenden Inhalte werden im Buch besprochen. Meiner Meinung nach sollte jeder Azubi zum Fachinformatiker Anwendungsentwicklung diese Begriffe wenigstens einmal gehört haben, besser noch sie mit eigenen Worten erklären können. Die funktionale Programmierung ist neben der Objektorientierung heutzutage sicherlich eine gängige Vorgehensweise. Für die anderen IT-Berufe sind viele Inhalte sicherlich etwas zu speziell. Allerdings sollte jeder ITler zumindest die verbreiteten Programmierparadigmen auseinanderhalten können. Und dazu zählen meiner Meinung nach auch einige wichtige Schlagworte. So wie bei der Objektorientierung Vererbung und Polymorphie erklärt werden müssen, sollte man bei der funktionalen Programmierung Funktionen höherer Ordnung oder reine Funktionen erläutern können. Grundlagen Lambda-Ausdrücke: Anonyme Funktionen in einer kurzen Schreibweise, meist mit einem "Pfeil" als Trenner zwischen Methodenkopf und -rumpf (z.B. ->). Typinferenz: Implizite Ableitung der Datentypen z.B. von Funktionsparametern aus dem Kontext, z.B. var text = "Text" (text ist "automatisch" ein String). Algebraische Datentypen Produkttypen: Der Datentyp wird definiert durch die Kombination verschiedener Werte. Das sind letztlich unsere bekannten Objekte bzw. Structs. Summentypen: Der Datentyp wird definiert als Liste möglicher Alternativen bzw. Varianten, z.B. ist eine Krankenversicherung entweder eine GesetzlicheKrankenversicherung oder eine PrivateKrankenversicherung. Hierbei müssen die Alternativen nicht in einer Vererbungsbeziehung stehen, wie man am Beispiel vermuten könnte. Pattern Matching: Kontrollstruktur, die Datentypen "zerlegen" kann. Quasi switch "on steroids". Generics: Datentypen, die mit anderen Datentypen parametriert werden können. Sie bieten allgemeingültige Algorithmen an, die auf mehreren Datentypen ausgeführt werden können. Ko- und Kontravarianz: Legen fest, welche Verallgemeinerungen bzw. Spezialisierungen bei Typparametern von generischen Klassen erlaubt sind. Beispiele: Kovarianz: List students = new List(); Kontravarianz: List students = new List(); Prinzipien der funktionalen Programmierung Funktionsobjekte (first class citizens): Funktionen sind fester Bestandteil der Sprache und können z.B. Variablen zugewiesen oder als Parameter übergeben werden. Reine Funktionen (pure functions): Funktionen haben keine Seiteneffekte. Sie liefern zum gleichen Input immer den gleichen Output. Funktionen höherer Ordnung (higher order functions): Funktionen, die andere Funktionen zurückgeben oder als Parameter bekommen. Bedarfsauswertung (lazy evaluation): Ein Ausdruck wird erst dann ausgewertet, wenn sein Wert auch wirklich benötigt wird. Unveränderbarkeit (immutability): Bestehende Werte sollen nicht mehr verändert werden. Stattdessen werden immer neue Werte erzeugt. Rekursion (recursion): Das Mittel der Wahl zur Iteration ohne veränderliche Variablen. Referentielle Transparenz (referential transparency): Ein Ausdruck kann jederzeit durch seinen Wert ersetzt werden und umgekehrt. Funktionale Datenstrukturen Funktoren: Bieten die Funktion map() an, um den enthaltenen Datentypen in einen anderen zu transformieren. Beispiel: Optional. Monoide: Mit Monoiden kann man eine Menge von Elementen zu einem Gesamtergebnis verknüpfen, es also reduzieren (fold). Dafür wird ein neutrales Element und eine Reduktionsfunktion benötigt. Beispiel: Addition ganzer Zahlen mit neutralem Element 0. Monaden: Bieten die Funktionen of() und flatMap() an, um den enthaltenen Datentypen in einen anderen zu transformieren, wobei das Ergebnis dieser Transformation selbst wieder eine Monade ist. Beispiel: Stream. Listenverarbeitung mit Streams Grundlagen von map(), filter() und reduce. Parallele Streams und Eignung von Aufgaben für die Parallelisierung Sonstiges Asynchronität mit CompletableFutures und Reactive Streams Property Based Testing mit Quickcheck Ein komplett anderer Ansatz, um Funktionen zu testen. Statt Input und erwarteten Output selbst zu definieren, werden zufällige Input-Werte generiert und allgemeine Eigenschaften des Ergebnisses geprüft, z.B. dass bei einer Konkatenation zweiter Strings die Länge des Ergebnisses immer größer oder gleich der Länge des ersten Strings sein muss. Was mir am Buch sehr gut gefällt Es werden nicht nur die Grundlagen der funktionalen Programmierung erläutert, sondern auch viele andere wichtige Begriffe rund um die moderne Programmierung. Gerade die Grundlagen werden sehr verständlich erklärt und mit vielen praxisnahen Beispielen angereichert. Es werden auch sehr moderne Konzepte wie wie Reactive Streams und Property Based Testing erläutert. Einige Grundlagen, die jeder Informatiker einmal gehört haben sollte, werden ebenfalls behandelt, z.B. Algorithmen zur Tiefensuche. Auch einige Entwurfsmuster werden im Detail erklärt und mit der funktionalen Lösung verglichen. Die technischen Hintergründe der Implementierung in Java werden gut verständlich erläutert. Das sollte heutzutage jeder Java-Entwickler kennen! Was mir am Buch nicht ganz so gut gefällt Die Inhalte haben natürlich einen starken Fokus auf die Implementierung in Java. Man kann zwar auch als Nicht-Java-Entwickler im Bereich der Grundlagen einiges mitnehmen, aber am besten geeignet ist das Buch wohl für Hardcore-Java-Entwickler. Man merkt, dass der Autor Hochschuldozent ist. Die Beschreibungen und Beispiele sind teilweise etwas akademisch. Auch wenn die funktionale Programmierung ihren Ursprung in der Mathematik hat, ist das vielleicht für Azubis manchmal etwas schwere Kost. Die verwendeten Beispiele sind teilweise sehr umfangreich. Sehr lange Codeausschnitte, die schwer nachzuvollziehen sind, hätten vielleicht gekürzt werden können. Fazit Ich kann das Buch uneingeschränkt weiterempfehlen. Es vermittelt einen sehr guten Überblick über moderne Programmmiertechniken und die funktionale Programmierung. Auch Azubis werden es gut verstehen können. Ich empfehle die Literatur allerdings erst ab dem zweiten Lehrjahr, wenn schon einige Programmierprojekte umgesetzt wurden. Auch als Nachschlagewerk für zentrale Begriff der funktionalen Programmierung finde ich das Buch sehr gut, da die Begriffe kurz und prägnant definiert und mit Beispielen erklärt werden. Insbesondere für Java-Entwickler empfehle ich das Buch zum Verständnis der technischen Implementierung der funktionalen Programmierung in Java. Literaturempfehlungen Naja, was soll ich wohl anderes empfehlen als das besprochene Buch Funktionale Programmierung in Java*? :-) * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Gregor Trefs über funktionale Programmierung, Konferenzen und Fachartikel Algebraic data type Summentypen Produkttypen Property-based Testing mit JUnit QuickCheck Präsentation: Property-based Testing mit JUnit-Quickcheck Railway Oriented Programming in Java Präsentation: Railway Oriented Programming - Funktionaler programmieren ohne Exceptions Zusammenfassung Das Buch für deine Ausbildung Mit meinen IT-Azubis lese ich regelmäßig Fachbücher. "Funktionale Programmierung in Java" von Herbert Prähofer, Professor an der Universität Linz, empfehle ich dir als deutschsprachigen Einstieg in funktionale Konzepte und ihre Umsetzung in Java. Meine Besprechung stammt aus dem Jahr 2020. Durch die ausführlichen Codebeispiele kannst du nachvollziehen, wie die Konzepte im Alltag funktionieren....