CodeScout

Du als Ausbilder bist aber auch verpflichtet entsprechende Maßnahmen einzuräumen und Zeiten zu schaffen, in denen du dich aktiv und stundenweise mit dem Azubi beschäftigst. 
Wenn der Azubi sich bei dir nicht meldet, wenn er Fragen hat und das Feedback am Schluss ist, dass er zu wenig Hilfe bekommen hat, solltest du als Verantwortlicher auf die Suche gehen, weshalb er diverse Fragen nicht stellt oder gestellt hat. 

Rhetorische Fragen: 
Wird er angemault, wenn er etwas fragt, was er bereits können sollte?
Hat er Angst dumme Fragen zu stellen?
Hat er Angst, dass ihm Fragen negativ ausgelegt werden?
Hat er Probleme beim Formulieren von Fragen und stellt diese deshalb nicht?
Hat er das Gefühl, dass er dich stört, sobald er dich anspricht?
Hat er das Gefühl, dass er dich nicht stören darf, wenn er Fragen hat? 

Ich bin kein Ausbilder, bringe diversen Azubis dennoch Themen bei und achte stets darauf, dass sie auch vermeintlich dumme Fragen stellen können. Erfahrungsgemäß fehlt auch einfach die Verknüpfung zwischen zwei Themen. Auch wenn sie Themen gelernt haben, können sie das Tranfserdenken nicht ordentlich einsetzen, weil halt einfach eine Art Verknüpfung zwischen A und B fehlt. Oftmals reicht auch schon ein "Erinnerst du dich an Thema X? Das ist hier notwendig". 
Als ich ein Azubi war, habe ich für manche Aufgaben auch exorbitant lange gebraucht, das lag beispielsweise an folgendem:
- Weil ich den Arbeitsauftrag nicht verstanden habe (einfacher Tipp: Der Azubi soll in seinen Worten wiederholen was verlangt wird, erst dann hat er es verstanden)
- Weil ich Thema X nicht verstanden habe und ich mir erst sicher sein wollte
- Weil ich das Gefühl hatte, dass ich es alleine machen muss, denn, wenn der Chef sagt ich kann das bereits, müsste ich das ja bereits können

Ein Azubi soll in erster Linie doch bitte einfach Fragen stellen, wenn er welche hat. Abhängig vom Alter und vom Reifegrad der Person kann das mehr oder weniger gut klappen. 

Im ersten Ausbildungsjahr war ich 16.. Ich war quasi ein fortgeschrittenes Kind ;')
Das heißt das Gespräch suchen, ehrliches Feedback deinerseits geben und seines ermöglichen. Positive Dinge und negative Dinge ansprechen, ggfs. inklusive einem Lösungsvorschlag/-weg. Regelmäßige Termine wie bei DPR können Verständnisprobleme lösen.

Wenn die Frage: "Woran hat es gelegen" ordentlich geklärt werden kann, kann basierend darauf auch alles angepasst und verbessert werden. 
Ist es das erste Mal, dass er länger gebraucht hat als du gedacht hattest? Wenn ja, dann weißt du, dass du zukünftig einfach mal ein "na wie läufts, hast du Fragen?" in den Raum wirfst, wenn nicht und du wartest noch immer darauf, dass er auf magische Art und Weise plötzlich deine gedachten Fristen einhält, dann herrscht hier aber Verbesserungspotential in der Kommunikation. 
Aktuelles Vorgehen der generellen Ausbildung dokumentieren und zukünftig verbessern/anpassen, damit du ein "Template" hast, erleichtert dir zukünftig stark das Thema. 
So lernt der Azubi aktives Geschehen, es bleibt aber jemand in der Lehre, der im Zweifel überfordert mit der Situation ist. In Projekten herrscht in der Regel wenig Spielraum für Fehler und der nicht-Einhaltung von Fristen, was sich kontraproduktiv auf die Psyche des Azubis auswirken und das Lernen negativ beeinflussen (kann natürlich aber auch echt gut und sinnvoll ausgehen). 

So würde ich persönlich nicht ansetzen. Frontalunterricht ist meiner Einschätzung nach (gerade bei solchen Themen) nicht der richtige Weg. Was für ein Lerntyp ist denn dein Azubi? Kommt er anstatt mit einem Buch, mit einem Videokurs zum Thema Java Programmierung besser klar? Eine Alternative wäre ein Fachgespräch wo ihr die Themen einfach zusammen erarbeitet. Ich persönlich habe sehr gute Erfahrung mit einem Projekt gemacht. Ich kann ja mal erzählen wie es bei uns ist (ist aber Systemintegration).
In der ersten Ausbildungswoche, bekommen die Azubis von mir mein Buch (Grundlagen der Systemintegration) was eine absolute Grundlage schafft. 
Danach kommen sie als erstes ins Netzwerkteam und machen da einen videokurs zum CCNA. Danach bekommen sie Hardware (Switches, Router, Firewalls und einen Server) und bauen ein komplettes Netzwerk auf mit Hilfe eines Netzwerkplans und einer Schritt für Schritt Anlleitung (ohne Konfigurationen - die sollen sie ja selbst machen).
Wenn sie dann das Netzwerk komplett aufgesetzt haben, geht es weiter im Linux Team. Sie machen noch mal einen Videokurs (LPIC-1) und setzen danach einen DNS Server, DHCP und einen Webserver auf. Anschließend kommt das Windows Server Team wo sie Active Directory machen und WSUS etc. 
So geht es quasi immer weiter und das Netzwerk, welches sie seit dem Anfang der Ausbildung aufgesetzt haben, wird immer größer mit jeder Abteilung. 
 
So kann man es ja auch mit einem großen programmierprojekt machen. Immer weiter in die Materie rein und sie selbst sind "der Chef" des Unternehmens oder der Applikation. 
Weil ich das alles bei uns so durchgeplant habe, verbringe ich kaum Zeit mit der Planung oder "Frontalunterricht". Wir halten zwei Mal die Woche ein Meeting für Verständnisprobleme und machen zusätzlich Präsentationen (alle zwei wochen) damit sie das auch für die Abschlussprüfung lernen. 
 
Grundsätzlich würde ich aber sagen: Such das Gespräch mit deinem Azubi. Sage ihm/ihr, dass du von dir aus gedacht hättest, dass es schneller geht, aber du dir Präsentation echt gut fandest. Stelle doch einfach die Frage womit er/sie Probleme hatte und frage im gleichen Zug womit du Unterstützen könntest um die Themen für den azubi verständlicher zu machen. Ich halte aber 12 Arbeitstage nicht unbedingt für wahnsinnig viel. Ihr habt doch schon so viel gemacht wenn ich mir die Themen bei dir angucke. Ihr habt drei Jahre zeit. Ihr braucht da nicht so schnell durch rennen. 
Das wären so meine Gedanken dazu

klar, ein spezialisiertes Studium hat definitiv seine Berechtigung, besonders in echt spezifischen Feldern. Aber wenn's um die Arbeit an normalen Softwareprojekten oder Produkten geht, kommt man an der Ausbildung zum Fachinformatiker und der dazugehörigen Praxiserfahrung nicht vorbei. Die ist einfach mega wichtig und legt die Basis für alles Weitere.
Und noch was: Ich hab wirklich super Erfahrungen mit Azubis gemacht, die ihren Realschulabschluss in der Tasche haben. Die bringen nicht nur ein gutes Fundament mit, sondern auch eine Hammer Lernbereitschaft, die in der Praxis total wichtig ist. Die Motivation und die Fähigkeit, sich schnell einzuarbeiten, sind im Arbeitsalltag goldwert.
Was auch noch super wäre: Wenn die Lehrer sich regelmäßig über Neuerungen in der Softwareentwicklung fortbilden würden. 
 
 

Aber was bringt mir super saubere Software, wenn sie nicht "fertig" wird. Ich glaube manchmal sieht sich ein Softwareentwickler zu sehr als Künstler und liefert deshalb lieber kein Ergebnis ab als ein nicht Perfektes. 

Geld verdienen tut man effektiv nur mit "Fertiger" aber nicht mit Schöner Software. 

Hallo zusammen,
Kennt ihr folgendes Phänomen? Manchmal scheint es, als ob die schnell zusammengezimmerten Projekte, die wir aus der Not heraus fertig machen, am Ende besser ankommen als die, über die wir ewig brüten und die nie wirklich fertig werden. Warum ist das so?
Ist am Ende des Tages "fertig" besser als "perfekt"? Am Ende zählt ja meist, dass die Software funktioniert und die Leute sie nutzen können.
Aber was ist eigentlich wichtig, damit Software erfolgreich ist? Die Software, die langfristig verwendet wird, ist oft nicht unbedingt diejenige mit dem schönsten Code, sondern eher diejenige, die dem Nutzer einen echten Mehrwert bietet.
Ich stelle diese Frage, weil ich oft erlebt habe, wie wir als Entwickler stundenlang über eine perfekte Lösung nachdenken, nur um dann festzustellen, dass sie an den Anforderungen der Stakeholder vorbeigearbeitet haben. Die Stakeholder wiederum ärgern sich darüber, dass das Endergebnis nicht das ist, was sie wollten. Meist endet das in dem immer gleichen Konflikt. 

Laut agilen Baukasten gibt es dafür genug Lösungen in der Praxis funktionieren sie aber meist nur, wenn beide Seiten sehr fit in dem Gebiet sind.
 
 

Oh da habe ich mich ungünstig ausgedrückt. Ich meinte mit fertig. Das Features oder Anpassungen ausgeliefert werden. Nicht, dass ich ein Softwarestand habe, den ich einfrieren kann. 

Hallo zusammen,
Kennt ihr folgendes Phänomen? Manchmal scheint es, als ob die schnell zusammengezimmerten Projekte, die wir aus der Not heraus fertig machen, am Ende besser ankommen als die, über die wir ewig brüten und die nie wirklich fertig werden. Warum ist das so?
Ist am Ende des Tages "fertig" besser als "perfekt"? Am Ende zählt ja meist, dass die Software funktioniert und die Leute sie nutzen können.
Aber was ist eigentlich wichtig, damit Software erfolgreich ist? Die Software, die langfristig verwendet wird, ist oft nicht unbedingt diejenige mit dem schönsten Code, sondern eher diejenige, die dem Nutzer einen echten Mehrwert bietet.
Ich stelle diese Frage, weil ich oft erlebt habe, wie wir als Entwickler stundenlang über eine perfekte Lösung nachdenken, nur um dann festzustellen, dass sie an den Anforderungen der Stakeholder vorbeigearbeitet haben. Die Stakeholder wiederum ärgern sich darüber, dass das Endergebnis nicht das ist, was sie wollten. Meist endet das in dem immer gleichen Konflikt. 

Laut agilen Baukasten gibt es dafür genug Lösungen in der Praxis funktionieren sie aber meist nur, wenn beide Seiten sehr fit in dem Gebiet sind.