IBM® Rational® Team Concert is a collaborative software delivery environment that empowers project teams to simplify,
automate, and govern software delivery. Automated data collection and reporting reduces administrative overhead and
provides the real-time insight required to effectively govern software projects. Dynamic project provisioning enables
day one productivity, while real-time collaboration helps significantly reduce scrap and rework. Rational Team Concert
extends the capabilities of the Team with integrated work item, build, software configuration management (SCM) and the
collaborative infrastructure of the Jazz Team Server.
Terminology mapping
Process descriptions in IBM® Rational® Method Composer use general purpose terminology for work products because they
need to be understood across a variety of circumstances and tools. Specific tools often need to refine that terminology
to increase clarity and usability. This page describes how artifacts defined in this process are defined IBM® Rational
Team Concert™.
Common Artifacts
Rational Method Composer artifact
|
Rational Team Concert artifact
|
[Project Work]
|
The [Project Work] includes the Work Items List, which is a list of all work for the project or
release. In Rational Team Concert, work items such as user stories are initially added to the release backlog and can
be visualized in the release plan (Scrum Process template) or in the project plan (IBM Practices for
Agile Delivery Process template). The work items (such as user stories) are later assigned to
iterations and moved from the release backlog to the Sprint Backlog (scrum process) or Iteration Plan (IBM Practices for Agile Delivery). New work items such as tasks
needed to develop and test user stories are added to the Sprint Backlog or Iteration Plan.
Project tasks in Rational Team Concert are maintained as Work Items. A description of the work that needs to be performed during a specific
time period is defined in an Iteration Plan.
|
Risk List
|
In Rational Team Concert, risks can be represented as work items of type risk, issue, or any custom work
item type. The risks can be prioritized, assigned to owners, and further detailed with tasks that need to
be performed to address them. A risk list in Rational Team Concert can be retrieved by a query that shows
all work items of that particular type you are using to capture risks.
|
[Technical Specification]
|
Change requests and stakeholder requests in Rational Team Concert are generally maintained as Work Items. Technical specifications also contain requirements, so there are probably
other tools in your environment that maintain other parts of the Technical Specification.
|
Work Items List
|
The Work Items List is the list of all work for the project or release. All work items in Rational Team
Concert (such as requirements, defects, tasks, and so on) are added to the tool repository so that they can
be tracked, assigned to or taken on by team members, resolved, closed, and so on. Work items can be
assigned to plans (such as the Project Plan and Iteration Plan), retrieved by queries, and visualized in
dashboards.
|
Practice: Iterative Development
Rational Method Composer Artifact
|
Rational Team Concert Artifact
|
Iteration Plan
|
An Iteration Plan in Rational Team Concert displays the goals to be achieved in one
iteration and organizes the planned work items for the iteration. The iteration assessment or
Retrospective information can be captured in a tab of the Iteration Plan or, alternatively, in
a Retrospective work item type assigned to the iteration. Note: If you follow the
Scrum Process template, the plan for an iteration is called the Sprint Backlog, instead.
|
Practice: User Story Driven Development
Rational Method Composer
artifact
|
Rational Team Concert artifact
|
User Story
|
User Story artifacts are captured as User Story work items in Rational Team Concert. There are Rational Team Concert process
templates (such as Scrum and IBM Practices for Agile Delivery) that provide the User Story as one of
the available work item types to be created, and a state machine for the User Story work item type is
provided to help track the status of work associated with developing and testing each user story.
The user story work item contains the user story description and details that help the team implement
and validate the user story implementation:
User story confirmations are captured in different sections of the respective work item:
-
In the Overview tab, use the Description field to add detailed information, such as data
exchanged by users with the system. In the Discussion section, add a comment to capture the
decisions and the rationale for those decisions so that stakeholders and all team members have a
history of all discussions related to a user story.
-
In the Acceptance Test tab, use the Acceptance field to add acceptance conditions that will be used
to generate test cases for the user story (for example: exceptions, error conditions, alternative
behaviors, system-wide requirements, and so on).
-
Within the Links tab, in the Subscribers section, add team members and other stakeholders who are
interested in receiving notification when the user story is updated.
|
|