A role defines the behavior and responsibilities of an individual, or a set of individuals working
together, in the business. The behavior of each role is defined as a set of tasks. The
responsibilities of each role are usually defined relative to certain work products, such as documents, for
example. Examples of roles are designer, software architect, and reviewer. Through the associated set of
tasks, the role also implicitly defines a competence.
Note that roles are not individuals; instead, they describe how individuals should behave in the business,
and what responsibilities these individuals have.
The project typically has at its disposal a number of resources, individuals which have specific
competencies. For example, Joe, Marie, Paul, Sylvia are individuals with different, although overlapping
competencies. Using the roles defined in the delivery process, map resources available to the project onto roles
they can play.
The association of individual to role is dynamic over time, driven by the phase in the project lifecycle
and the work to be performed.
-
An individual might act as several different roles in the same day: For example, Sylvia might be a
Reviewer in the morning, and a Use-Case Designer in the afternoon.
-
An individual might act as several roles simultaneously: For example, Jane could be both the Software
Architect and the Designer of a certain class, and also the Package Owner of the package that contains
this class.
-
Several people can act as the same role to perform a certain task together, acting as a team: For
example, Paul and Mary could be both Use-Case Designers of the same use case.
Try to allocate responsibilities so that there is as little hand-off of work products from one resource to
another: have the same person or team design and implement a subsystem, so that they do not have to
re-learn work already done by others.
When the same team designs as well as implements, there is a smooth transition from design to
implementation. In addition, it makes for better designers: by learning what works and what does not, they
gain a better sense of good design and incorporate it into future work. Like a sculptor, the good designer
must understand the medium of expression, which for software is the implementation environment.
|