Using the IBM Rational Team Concert Management Development Task trilogy

Introduction to RTC

The IBM Rational Team Concert (RTC), as a software collaborative development tool, is gradually being used in the production of large projects, maintaining a large project organization and methodically managing each development task, thus laying a solid foundation for creating high-quality software products.

The RTC provides an integrated environment throughout the development process, including requirements definition, iteration planning, source control, automatic build, bug tracking, change management, and statistical reporting. This article will detail how to use the RTC to track and manage the project's development tasks through three levels. First, describe the features and features of different kinds of work items in the Scrum method, and help the members of each role in the project to establish work item types that correspond to them. Then, it describes how to quickly and accurately locate specific work items from a huge amount of work items by retrieving and querying to get the work item content of individuals and teams. Finally, it introduces the use of reports and dashboards in the RTC, summarizes the work items in the project, shows the overall status of the project, and predicts future trends.

The cornerstone of development activities--work items

The work item (Work items) is the basic unit of project development and management in RTC, which is used to record development tasks, correlate development results, manage development progress, and achieve synergy. To meet different software project development processes, the RTC has a variety of software development process templates built into it, and the work item settings for each template vary. This section describes the common work item content and structural characteristics in the RTC, taking the Scrum development management approach in agile development as an example.

Scrum is a flexible method of software project management, which realizes the function of software product incrementally through a series of iterations. To effectively manage development tasks in an iteration, the out-of-the-box work items commonly used in the RTC Scrum method template include: Epic, User Stories (Story), Tasks (Task), defects (Defect). Their relationships can usually be expressed in Figure 1.

Figure 1. Scrum method Template Work Item diagram

Epic: usually refers to the overall goal of the project. This type of demand is proposed by decision management as the overall strategic plan for the software project. Its description is relatively concise, only from the high-level designated project direction, did not clarify how to achieve and specific requirements. For example, Figure 2 illustrates how to use Epic to represent the overall requirements of a project.

Figure 2. Epic example in the eye

In Figure 2, Epic's summary is "the customer needs to use Office automation system (OA)". and put the link address of the related document in the Description column. Epic's primary service object is the project stakeholder (stakeholder), so it does not directly contain the details of the requirement, but rather as a subtask, associated with the next-level parameter (Children). The project stakeholders can use the status and progress of this work item to display the overall workload of the project and the level of progress.

Story: In order to achieve the overall goal in Epic, the entire requirement needs to be further refined into a range of specific requirements that can be achieved. Business Analyst (Business analysis) records the requirements that can be implemented and tested in the user Story (Story). According to the Scrum development methodology, each user story should be guaranteed to be completed in one iteration so that the results of each iteration development can be demonstrated to the customer.

Figure 3. Examples of user Stories

Figure 3 is an example of a user story that implements Epic, called "Implementing the functionality of Shared documents in a system." Story points (Story point) are used to measure their size and complexity, and are evaluated by team members to indicate a comparison of the relative workloads between different user stories. Schedule (Planned for) specifies which iteration of the user story will be implemented. The acceptance rule (acceptance) contracts the acceptance criteria after the user's story has been developed. The business analyst validates the development results based on the acceptance rules after the development task is completed and demonstrates the results to the end customer after the iteration is complete.