In base allo stato cliente, dal tuo account Red Hat puoi accedere al profilo personale, alle preferenze e ai seguenti servizi:
Non ti sei ancora registrato? Ecco alcuni motivi per cui ti consigliamo di registrarti:
- Per poter consultare gli articoli della Knowledgebase, gestire i casi con il supporto tecnico e le sottoscrizioni, scaricare gli aggiornamenti e altro ancora da un'unica posizione.
- Per poter visualizzare gli utenti all'interno dell'azienda e modificarne le informazioni di account, le preferenze e le autorizzazioni.
- Per poter gestire le tue certificazioni Red Hat, visualizzare la cronologia degli esami e scaricare logo e documenti relativi alle certificazioni.
In base allo stato cliente, dal tuo account Red Hat puoi accedere al profilo personale, alle preferenze e ad altri servizi.
Per tutelare la tua sicurezza, se stai usando i servizi Red Hat da un computer pubblico, assicurati di disconnetterti.Esegui il log out
by Wander Boessenkool (Red Hat)
In the previous part of this series we explored the tools used by the Red Hat Curriculum Team to develop training courses. In this post we will explore the process behind our course development.
The process we follow when creating a new course consists of a number of steps.
- Course Focus/Objective
- Learner Analysis
- Task Analysis
- Classroom Setup
- Lab Development
- Content Development
- Lab QA
- Editorial Work
- Course Pilot
- Post Pilot Fixes
- General Availability
As you can see that is a fair number of steps to go through. All in all it can take between 20 to 50 man days to produce one day of Instructor Led Training, depending on the complexity of the material and the amount of hands-on exercises in the training. This means that producing a four day course can take between 16 to 40 man weeks to complete.
The first thing to do is to determine the focus of the course. This is actually harder than it seems, since just saying something like: “Let's write a course about Product™” will typically not lead to a good quality course. Instead you want a more Solution oriented course focus, something like: “Frobnicating FooBar widgets using Product™”.
The distinction between the first and the second objective might not seem too big, but when you start to develop a course using those two you will quickly noticed that a course based on the first objective will lead to a glorified product manual, while a course based on the second objective will give students realistic labs, and work-aids that they can use on their job.
The next step is figuring out who the target audience for your course is. Are you aiming your new course at architect level senior system administrators, or is it and introductory course for people migrating from a different operating system?
After you know your target audience you will have to analyze how much knowledge they will bring into the classroom with them. Do they have prior experience with these types of solutions, and is that experience relevant? Will you have to start from the ground up with the subjects you are covering, or can you skip some introductory topics. It might even be that your learners will likely enter your classroom with similar skills, but different enough that you have to de-train them a bit to not use those skills in certain scenarios.
Now that we know who our students will be we can tackle the next step: Figuring out which skills we will have to teach in our course, and to what level of detail. This step is all about identifying hands-on skills and tasks that will need to be taught in the course. If any theoretical knowledge is needed it will be brought in to support hands-on tasks.
Once a list of tasks (and sub-tasks) has been made we can now start scoring those tasks based on their importance, difficulty, and prior knowledge that students will likely have on those tasks. We can then use that scoring when decisions need to be made on which tasks and subjects to include in the course (e.g. when it turns out that we have 35 hours of material for a four day course, something will have to go).
Classroom Setup entails all the materials that one of our instructors will need install and provision all the machines in a classroom. In a modern Red Hat classroom this includes the instructor server, student workstations, software repositories, kickstart files, virtual machine provisioning, network layout, and far more. The basis of classroom setup is normally completed before Lab Development starts, but will be refined throughout the Lab Development phase and beyond.
Having a clear idea on what tasks we want to teach in a course we then set about writing all the hands-on exercises for the course. For most courses this will include writing setup and grading scripts, to prepare (virtual) machines for the task, and to provide the student with feedback on how well he or she accomplished the given task.
Lab Development is normally closely tied to Classroom Setup, and typically happens (somewhat) in parallel. The first draft of classroom setup materials is normally completed before serious development work starts on the hands-on exercises. The classroom setup is then refined during the Lab Development phase to provide a working environment for all exercises.
With all the labs completed we can then focus on writing the actual content of the Student Workbook. With all hands-on exercises already written we can use those exercises as a guideline for what information needs to disseminated to students during which chapter.
One of the big challenges during this phase is finding the right balance between too much and too little information. If we provide too little information students will not be able to successfully complete the corresponding exercises, while if we give too much, or too detailed, information students can get overwhelmed and zone out. Looking back at you Learner Analysis can be quite useful here to target the right level of existing and new knowledge.
While writing the Student Workbook we write the Instructor Guide in parallel. The instructor guide contains useful information for instructors, like hands-on examples and demos, expected timing, and more.
While writing the Student Workbook and the Instructor Guide we will also have to make choices on the Instructional Methods we will use. Instructional Methods include a classical Lecture, but also more non-conventional methods like a Search and Learn, where students are pointed towards documentation and then asked to research how to complete a set task.
If any graphics are needed to supplement the written materials we will make mock-ups of the desired graphics, then send those off to our graphics artists to produce something that's in line with the Red Hat standards of look and feel and quality.
During this phase we will also create the slide deck that will be used by instructors in the classroom to support their delivery.
With all the labs completed we will have to make sure that they actually work as-written. This means we hand over classroom setup materials and the written labs to members of the team who were not involved with writing the labs. These team members will then work their way through all the labs in the book, reporting (and fixing) any issues they might run into. Not only will these people have to run through the labs using the printed instructions and solutions, they will also have to attempt to mess up on purpose, especially for labs that include a grading script. This is because we do not only want the grading script to report success when someone has successfully completed an exercise, we also want the grading script to be able to tell a student what he has done wrong when something does not work as expected.
Lab QA can typically be done in parallel with content development.
With all the materials written and all the labs tested we can then hand our materials over to our friendly editor. Authors are expected to run spelling checks themselves, but they can only catch so much. Unfortunately English is full of words that have just a one or two letter difference with a completely different word. (And let's just not mention the whole they're, their, there thing). Our editor is responsible for fixing any remnants of bad spelling, horribly broken sentences, and all out abuse of the English language.
After the editor has straightened out our prose we can then proceed to one of the most important steps: Testing out the course in front of a real live audience. Course pilots are normally taught by an experienced senior instructor, with an audience consisting of internal Red Hat people and instructors. A member of the Curriculum Team will sit silently in the back, attempting not to look too embarrassed, while taking notes on everything that does not flow smoothly, is unclear in the books, confuses students, or slipped passed the editor.
Post Pilot Fixes
After the Pilot, and during the pilot in a lot of cases, feedback from the pilot will be analyzed and incorporated back into the course. This is the final step before we go to:
With all the last fixes from the Pilot incorporated into our materials we do a final build before sending our materials of to the printers and making them available to our instructors. This is also when translation work will start for those regions where they use localized materials.
By now our Curriculum Team is already knee-deep into planning and building the next course.
- When we want to release a new training course alongside, or close to, the launch of a (new) product, development work will typically have to be done on the alpha and beta builds of the product. From time to time this can generate some choice words when products change significantly when going from alpha/beta to release.
- Most of our courses will have some obscure pop-culture references hidden in plain sight. Try to catch them all!
- Hand-edited XML looks much nicer than auto-generated XML.
- An average four day course will have almost forty-thousand lines of source, spread out over more than fifty files.
- The Red Hat Linux Curriculum Team is normally working on two or three projects at a time, switching people between projects when needed, with other projects being done by the JBoss Curriculum Team.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.