The Essentials of Modern Software Engineering. Ivar Jacobson

5.3 Competencies

      The team members applying the programming practice must, of course, be able to program; that is, they must have a development competency. Competencies are the abilities needed when applying a practice. Often, software teams struggle because they don’t have all the abilities needed for the task they have been given. In these situations, a coach can help by explaining different ways the practitioner can address the problem, such as learning something that is missing in their competencies.

      Figure 5.6 shows the card for the Development competency. Similar in format to the alpha and work product cards, the top of a competency card has the competency icon (a star) and the competency name followed by a very brief description of the competency. Then a list of competency levels follows.

Figure 5.6 The Development competency card.

      The Development competency has five levels of achievement.

      1. Assists. Demonstrates a basic understanding of the concepts and can follow instructions.

      2. Applies. Able to apply the concepts in simple contexts by routinely applying the experience gained so far.

      3. Masters. Able to apply the concepts in most contexts and has the experience to work without supervision.

      4. Adapts. Able to apply judgment on when and how to apply the concepts to more complex contexts. Can enable others to apply the concepts.

      5. Innovates. A recognized expert, able to extend the concepts to new contexts and inspire others.

      Teams should be encouraged to conduct a self-assessment of their competencies and compare the results to the competencies they believe they need to accomplish their specific endeavor. This useful exercise can help software teams objectively determine any competency gaps they may have, which they can raise to management for resolution before serious problems occur that could hurt their team’s performance.

5.4 Things to Do

      To make progress in a development endeavor, or for that matter, any endeavor, all participants must do something. In our programming practice, this concerns writing code. The Essence language calls this an activity.

       5.4.1 Activities

      Activities are things that practitioners do, such as holding a meeting, analyzing a requirement, writing code, testing, or peer review. Similar to the challenges practitioners often face with determining the appropriate level of detail in work products, they also often struggle to determine the appropriate degree of detail or formality with an activity, or exactly how to go about conducting it. This is another motivation to specify explicit practices as they can provide guidance to practitioners in selecting appropriate activities, as well as in how to go about conducting each activity. A practice may include several activities that are specific to the practice being described. Thus, activities are specific and not standard—they are not a part of Essence. Figure 5.7 shows the activity card for Write Code. Its icon is an arrowed pentagon. (The activity space concept will be described in the next section.)

Figure 5.7 The Write Code activity card.

      An activity is always bound to a specific practice and cannot “float around” among the practices. If you find an activity that needs to be reused by many practices, then you may want to create a separate practice including this activity. The alternative is that you decide not to reuse it, but each practice that potentially could have reused it will have to keep its own copy of that activity. Changes to one copy of it will not impact the other copies; they will just change independently of one another, which means no reuse.

5.5 Essentializing Practices