If you plan to scale a face of Mount Kilimanjaro or Mount Everest, you certainly would want a well-trained team and some experts to guide your climb. This section helps you take those raw recruits you just selected and turn them into a well-prepared team.
As you begin to take these first steps, though, don't fall into the training trap. We all get those glossy magazine-like advertisements from training companies that list dozens of classes you can take. I surveyed a few recently. Overall, about 85–90 percent of the courses listed were for programming languages. The promise is that you'll take the one-week course, and then you'll return to your cubicle and be able to start coding in the new programming language the next week. This promise is the bait in the trap. This might work for programming languages, but not for understanding how to perform analysis and design with the UML. (By way of analogy, building a bridge is different from designing the bridge, requiring different skills and tools.) A programming language might be object-oriented, but learning an object-oriented language does not mean you will learn the concepts for good object-oriented design using the UML. However, the industry has expected that training outcome for so long (based on programming-language course results) that they expect it for UML and object-oriented training courses, too.
|
|
UML training classes can only take you so far. You also need training in OOAD. But even this only provides you with a foundation upon which to build your knowledge of the UML. To really develop the skills to perform excellent OOAD with UML, you need more. You need mentors to help guide your people through the intricacies. When starting out, you might have to hire mentors from outside your company. There are many consultancies where you can find such people. Make sure part of their job is to create in-house mentors for the future. In that way, you can seed new projects with your own in-house mentors. Then these internal people will groom additional mentors, and so forth. By repeating this process, you will develop internal expertise on UML and OO for your future projects and can reduce your dependency on external experts.
An activity closely related to mentoring is apprenticeship. Your external or internal mentor is not responsible only for helping train your up and coming UML specialists. Your newly minted UML/OO folks should not be thrown onto a real project alone—they should apprentice on a project with an experienced mentor. Projects in the real world have much more complex issues than you will ever see even in the best training regime. Training problems are structured and controlled in order to teach specific concepts and provide safe, no-risk learning. Not so on real projects.
Apprenticing will help your folks through the “Blank Sheet of Paper Syndrome” from which even your best newly trained OO folks are likely to suffer. This syndrome occurs when they are assigned to a new project and begin the task of modeling the system with that big, blank sheet of paper (or blank computer screen). Thoughts such as, “Where do I start?,” or “This isn't like what we learned in class,” or “What should I do?” immediately pop up. In the best case, this mentally paralysis doesn't last too long. In the worst case, these neophytes might start down the wrong path, and all their subsequent work can be for naught. You will also find that most people don't get over this syndrome until their third new OO project or so.