Roles

Once you have planned the key goals and focus areas for a team, you need to “design” a team that fits the target profile. This is analogous to the design of software after the target requirements are established. A good design meets the requirements, and a poor design doesn’t. A great design will exceed the requirements and deliver unanticipated value.

Every design has constraints. If you are working with an existing team, clearly you are constrained by the reasonable changes and improvements you can make. In most cases you are constrained by budget. When recruiting new team members, you may be constrained by the candidates available at the time in your region. But, within your constraints, you still have many design options from which to choose and many aspects you will need to consider.

A proven approach to good design is to use patterns and templates. That is where roles come in. Roles represent the different parts that coders can play on a team based on their individual qualities and skills and based on the team’s needs. Traditionally, you may think of roles as the titles or functions that coders fulfill, such as “architect,” or “database expert,” or “user interface developer.” In this section, I’d like to introduce a very different set of roles that are aligned with the codermetrics introduced in previous chapters and are not dependent on a coder’s title or functional role. Again, I use analogies to sports teams in naming and describing these. With a team’s goals in mind, ...

Get Codermetrics now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.