Getting Started with Jazz Project Areas and Process
Summary
The Team Process component provides the foundation for Jazz process support. This document is intended to familiarize those new to Jazz with the process related concepts and user interface elements and to assist them in defining their process, schedules, and team structure within Jazz.Introduction
Jazz lifts the burden of process by allowing your team to enact its best practices in software. Process enactment is built into Rational Team Concert from the development environment all the way to the repository.The purpose of this document is to help you get started using the Team Process component. Here is a summary of what you will learn.
Overview of the Team Process User Interface
Key elements of the Team Process user interface (UI) are exposed. Not a lot of detail on how to use the UI is offered because an understanding of the following topics is required.
Team Process Concepts
Here you will learn more about what the Team Process component can do for your team and how it works. The general concepts, terminology, and mechanisms for defining and customizing a project, defining your team, and the processes you wish to teach Rational Team Concert will be covered.Team Process Customization Exercises
With Team Process concepts and user interface in hand you will learn the mechanics for specifying your project’s process and how teams in the project can customize the process to their specific needs.Before proceeding we assume you have read the Jazz Tutorial. In particular, you need to know how to connect to a Jazz repository and create a project area using the Create Project Area wizard.
Overview of the Team Process User Interface
Here are descriptions and screen images of the primary dialogs, views, and editors that are part of the Team Process component. They are not described in detail but provide a context for the remainder of the document. The Team Process Customization Exercises section will expose more of the process user interface. Recall that the Jazz Tutorial exposed the user interface for creating a project area in the section titled Setup up a Project. Some process terminology is referenced here that will be explained later.Jazz Administration Perspective
The Jazz Administration shows many of the views discussed in this section.(this image has been scaled down)
Team Artifacts View
The Team Artifacts view is included in several Rational Team Concert perspectives because of its usefulness to all users. The view shows, among other things, the project areas the user is connected to, the repositories the user has access to, the team areas the user is a member of, and the user’s repository workspaces. The tool bar has actions for creating new project areas or connecting to existing ones.
The view can be filtered so that it shows only artifacts from selected project areas.
Team Advisor View
This view provides information when the governing process has been involved in a user-initiated operation. This view appears in the Jazz Administration perspective and will be opened automatically when the need arises. If a process violation has occurred, the user is encouraged to avoid this situation, blocked from completing the task, or possibly, permitted to overrule the process violation. The view can also be configured to show informational content even when an operation succeeds.
Team Organization
This view displays project areas the user is connected to and the hierarchical structure of the team areas within them. The process for these areas can be customized by opening the project and team area editors. This allows team members to understand and shape their process.
New Project Area Wizard and Connect to Existing Project Area Wizard
These dialogs are used to define new project areas and connect to existing project areas. They appear on the tool bars of the Team Artifact and Team Organization views.
Project Area Editor
This multipage tabbed editor is used to modify a project area after it has been created.The Overview page is used to describe the project, define global team members and define the project’s iteration structure. The iteration structure includes start and end dates for each iteration, the current iteration for each development line, and also the set of iterations which produce deliverables (this determines which iterations are available in the “planned for” field of work items, for example). The project area’s process is based on a process template which is identified. In the example below the Cloudburst Sample Process template was used. A brief description summarizes the process template.
(this image has been scaled down)
The Process Configuration page is used to configure how the process will behave for various roles during various iterations. Although the configuration is stored as XML, this page presents a user-friendly user interface for making changes.
The Process Configration Source page shows the XML source of the process configuration. The Outline view provides a structured view of its contents.
The Work Item Categories page is used to add and remove work item categories and to associate them with specific team areas. The team area with which the work item category is associated will determine the process which governs work items created with the category. For example, the team areas process configuration may specify required work item properties.
The Releases page is used to define the releases of the project for which work items can be created.
New Team Area Wizard
This wizard will create a new team area and is available on the context menu from a selected project area or team area in the Team Organization and Team Artifacts view.
Team Area Editor
Visually similar to the project area editor, this editor is used to define team members, choose the development line (more on this later), and optionally, customize the team’s process.
The Overview page is used to define team members and their roles, specify the development line, and browse, modify, and configure team artifacts.
The Process Customization page is used to modify or augment the process that the team area inherits from its parent project area and team areas. Note that team members can be defined with one or more roles in the project.
The Process Customization Source page shows the XML representation of the information that is on the Process Customization page.
The Work Item Categories page is used to link categories of work items in the project with teams that will work on the work items.
The Releases page is used to define the releases of the project against which work items can be created.
Process Templates View
This view is used to create or modify process templates that can be chosen during the creation of a new project area.
To create a new template right click on a repository connection in the view and chose New>Process Template from the context menu to open the Process Template wizard. When complete the Process Template editor opens. The editor looks very similar to the project area editor.
Team Process Concepts
The Team Process component helps teams consistently execute the processes they have agreed upon. It doesn’t define your process. In fact, it is process neutral. More appropriately, it maintains a constant presence in Rational Team Concert, ever ready to encourage or enforce the processes that your team has adopted. Process surfaces early in Rational Team Concert. When you define your project and teams, you have the opportunity to start specifying your process. Of course, you can modify your process to meet your evolving need to improve. Rational Team Concert includes some example processes that can be adopted and customized to suit your needs. You can contribute new process templates tailored to the needs of your teams and you can share your process with others. The expectation is that over time the best practices in software development will become available for the benefit of all.Before going any further you might wish to read the section on the Team Process component in the Jazz Platform Technical Overview. This describes the Team Process component architecture. It’s not very long and well worth reading.
This topic references the Cloudburst Sample Process frequently. In order to get the most out of this topic you should have a project area based on the Cloudburst Sample Process template. Before you create the project, you will need to create some users. Here is the information for creating the users:
- Name=Kim Cloudburst, username=kim_cloudburst, email=kim@cloudburst.com, license=Developer
- Name=Rick Cloudburst, username=rick_cloudburst, email=rick@cloudburst.com, license=Developer
- Name=Carol Cloudburst, username=carol_cloudburst, email=carol@cloudburst.com, license=Developer
JazzAdmins repository group can create a project area. You will need to be logged as user ADMIN or have assigned this permission to your user ID (See: Sidebar: System Permissions and Repository Groups).We apologize but this section is lengthy. If you wish to uncover the secrets of applying Jazz Team Process it will require some patience! You should find it worth the effort.
Let’s look at project areas and team areas in some detail.
Project Area
Rational Team Concert allows for a rich project and team structure to support small teams (even a team of one) to very large teams developing and maintaining a variety of product deliverables. The project structure is defined using a project area and typically includes one or more team areas. By now you should understand that project areas and team areas play an important role in Rational Team Concert. In fact, all Rational Team Concert components operate in the context of these areas. Your process is defined in a project area and can be further customized in a team area. In the real world a project may consist of many teams so Rational Team Concert allows for a hierarchy of team areas. Each team can customize their process by adding to and/or overriding the processes of the parent teams. Overriding can be disallowed by a parent. A project member (referred to as a user or team member in Rational Team Concert) can be a member of more than one team. In this case, the user must abide by the processes of each team that he/she participates in.A project can be quite simple or complex in terms of its schedules and its committed product deliverables. An established project that has been in business for a while could easily have the following active lines of development.
- Maintenance for one or more shipped releases.
- Development of a new release.
- Exploratory development for a future release.
A project area specifies a set of iterations. An iteration is an interval in the lifetime of the project. An iteration can be decomposed into sub iterations.
Let’s continue by exploring project area organization and the terms involved.
Here is an example hierarchy contained in a project area. What do these elements mean and how do they apply to your project?
| Project Area development-line iteration (project phase) iteration (milestone) iteration (milestone phase) |
You can define any number of iterations, nested to any depth.
development-line: A development line represents a structural element of a project that owns a set of deliverables and the schedule for producing them. Within a development line a hierarchy of iterations are defined. The development line may have specific process requirements. For example, a project with both new product release development and current product maintenance might define these two efforts in separate development lines because they have different delivery schedules and probably different processes.
iteration: An iteration divides the development line into separate periods that might have significantly different characteristics. In this example, the team first divides their development line into iterations which correspond to different phases of the project life cycle. For example, the feasibility phase of a project seeks to understand what is do-able based on its requirements. It is much more agile and expects to discard some or possibly all of its efforts. In contrast, the ready to ship phase of a project is highly controlled and seeks stability and quality. Its process is likely to be much stricter.
The example team then divides the project phases into iterations which correspond to milestones. Milestones are iterations of work with tangible deliverables. Their duration may be measured in weeks.
Finally, the team decomposes each milestone to configure the life cycle of each milestone. For example, this team’s milestone deliverables are made available to customers for evaluation so they have a development phase and an end game phase within each milestone; the latter having more stringent process requirements.
You could imagine that a large project, spanning a long period of time, might define an elaborate hierarchy of iterations using these elements.
Here is an example showing the default iterations provided by the Eclipse Way process template.
The purpose of all this is to define the project structure so that the process can be fine-tuned for different points in time. At any point in time, the project (more specifically the development line) is in a particular iteration. The process for the project can be customized to the needs of that interval. This suggests the need to define which project iteration is currently active. This allows Rational Team Concert to determine the current iteration and therefore what process to enforce at any given point in time. During a feasibility phase of a project the process is probably lightweight whereas the last phase of the milestone might require a stricter process. In the screen shot above, the currently active iteration is distinguished by the bright blue arrows adjacent to the iteration.
Finally, the process for the project can be defined in the project area. This will be explored in more detail later.
To summarize a project area:
- It contains a structure of development lines and iterations which can be decomposed into sub iterations. These provide an anchor for defining the different process requirements of the team as it moves through time.
- Each development line will have its own set of iterations, one of which is current. This allows for parallel development within a project area.
- Users that contribute to the project or perform some specific project role or task can be defined in the project area.
- The project process is specified in XML form and can be customized for different iterations.
- Since a project area is the root of all the items for the project, it cannot be deleted from the repository. A project area can be archived which places it in a dormant state.
Team Areas
In the Jazz Tutorial the Create Project Area wizard automatically created a team area when you defined your project area (this occurred because the Eclipse Way Process template that you chose was defined to create a team area as an initialization activity). A team area serves these functions.- Defines the users (team members) on the team and specify their roles.
- Defines the development line in which the team is participating.
- Customizes the project process to the needs of the team.
Process Roles
The project area can define a set of roles which are available for all teams to assign and each team can also define their own custom roles. Members of a team may be assigned multiple roles on the team. Process permissions and the behavior of various operations can then be configured based on these roles. For example, a project area can define a ‘team lead’ role and can configure the process to allow members with this role special permissions for managing the project.
Example of two roles defined in a process area.
Process Operations, Preconditions, and Followup Actions
You can enforce the desired behavior of your teams’ process by configuring preconditions and followup actions. Preconditions are checked before an operation is run (such as delivering code) and may prevent the operation from executing. Followup actions run after an operation has been run and may make additional automated changes. For example, when a workitem is resolved, a followup action could automatically create a verification task.Frequently, there is no single process that applies uniformly to everyone in the project nor is there a single process that applies during all phases of a project. Your processes can be applied selectively to the whole project, specific project teams, and varied during different iterations of a project’s lifetime. You can also configure how strictly your process is enforced by specifying whether or not preconditions can be manually overruled. The Team Process component is very flexible when defining which preconditions to check, when to check them, and to whom they apply.
Preconditions are authored using the Eclipse extension point mechanism and Java code. Preconditions can execute on the Jazz server and the Rational Team Concert client. We’ll discuss later the differences between client and server preconditions. Rational Team Concert ships with a collection of preconditions that you can use. Preconditions are specified in a project area. The set of preconditions can be customized for a specific team or for a particular iteration. For example, as a project nears completion the team may wish to specify additional preconditions or enforce that existing preconditions cannot be overruled when a product is getting ready to ship. Rational Team Concert accommodates all of this.
The Team Process component depends on other components being process-enabled. To be process-enabled means that a component invites preconditions and followup actions to participate in selected operations performed by that component. Followup actions can also be configured to run whenever certain types of events are generated by a component. All Rational Team Concert components are process-enabled. Let’s look at a couple examples of process-enablement by Rational Team Concert components and some preconditions that are available for these components.
The Work Item component is process-enabled for the work item save operation. This allows for preconditions that can validate work item content to ensure completeness and other requirements. One of the preconditions for work item save allows you to define which fields in a work item must be filled in before a work item can be saved. If a required field is incomplete then the save operation is stopped and details are provided in a view called the Team Advisor.
The Rational Team Concert Source Control component is process-enabled for it’s delivery operation. This allows for preconditions to be applied when content is delivered to the repository and shared with others. Content delivery is an important step in a software project because problems here can cause build and run-time failures. One of the Rational Team Concert delivery preconditions guards against submitting Java code that has compile errors. If compile errors exist in projects for which changes are being delivered, then the delivery operation is stopped and the user is notified. The notification appears in the Team Advisor view with details about the delivery problem.
These are just a couple of examples. Additional preconditions can be defined by extenders. There is almost no limit to the kinds of checks which can be implemented in preconditions defined by extenders.
Sidebar: Available Operations and Preconditions
New operations and preconditions are being added to Rational Team Concert all the time. This list is a representative set but not necessarily exhaustive. Some operations in this list do not have any preconditions, but access to them can be controlled (See: Roles and Permissions).Source Control Deliver Operation
- Prohibit workspace errors precondition
- Team members are advised not to deliver code with compilation errors.
- Prohibit unused imports precondition
- Team members are advised not to deliver Java code with unused import statements.
- Prohibit non-externalized Java strings precondition
- Team members are advised not to deliver Java code with strings that have not been externalized.
- Require work item approval precondition
- Team members are advised to associate that an approved work item with every code delivery.
- Require work items and comments precondition
- Team members are advised to associate a work item with every code delivery.
Work Item Save Operation
- Required properties precondition
- Team members are advised to complete certain fields in work items before they can be saved.
- Required Estimates precondition
- Team members are advised to complete the estimate field in work items before they can be saved.
Save Team Area Operation
This operation is used to define what user roles can modify a team area. There are no preconditions at this time.Save Project Area Operation
This operation is used to define what user roles are permitted to modify a project area. There are no preconditions at this time.Process Permissions
Depending on a team’s process they may wish to limit the access of some repository actions to specific team members who have been assigned certain roles. For example, a person may be assigned to bug triage. Their role is to examine incoming bug reports and assign them among the team. Other team members should not be allowed to make assignments. Rational Team Concert allows for this kind of control using process permissions.The Team Process component supports the definition of roles in a process area. Team members may be assigned one or more roles. There is a predefined role named
default. All users including those who are not members of the team assume the default role. A team member may be assigned additional roles when they are added to a team. Recall that preconditions and followup actions operate in the context of a component operation. In the precondition examples above you learned that work item save and source control deliver are examples of process-enabled operations. In order to execute a process-enabled operation the user must have the appropriate process permissions. Operations and their associated permissions are configured for a particular role.
Permissions are granted at the level of the actions performed by the operation. For example, the work item save operation performs actions like ‘modify / summary’ and ‘modify / severity’. In the graphical editor, these actions show up as nodes under the operation node. Permissions can be granted using for the action id to indicate that a specified role is granted permission to perform all actions at the current action level as well as any child actions. For example, the work item save operation can be configured to allow any type of modification by specifying permissions to ‘modify / any’ (or checking the “Save Work Item” operation in the editor). Granting permission to perform the top-level action
'any' to the default role would mean that the operation can be performed by anyone. Conversely, if an operation were configured for a particular role without granting any explicit permissions, users in that particular role would be prevented from performing the operation. For example, it might make sense to allow all users to write a bug report by allowing them to create a work item but to restrict delivering code to developers responsible for the code. To do this the default role would be configured such that all actions for the work item save operation are granted, but no actions for the SCM deliver operation are granted. A separate developer role would be defined and configured to grant permissions to perform all actions for the SCM deliver operation. Since your process specification represents the “rules of the road” for your project and your teams, it only makes sense that the Team Process component should have a fine grained permissions structure so that process definitions can be restricted to team members whose role is to manage the process. You might not want everyone on the team to be able to modify a project area or a team area. Otherwise, someone could subvert your well thought out process, possibly causing serious damage to the project. The process component’s save project area and save team area operations allow you to define such restrictions.
Here are some permission specification examples:
This example allows anyone to save a work item.
Here a developer is permitted to perform Rational Team Concert Source Control operations but the default user is not.
To get a better understanding of how to use roles and permissions see the
Restrict Process Specification Changes to Project and Lead Roles exercise later in this document.
Sidebar: System Permissions and Repository Groups
There is another permissions structure in Rational Team Concert called system permissions. Its purpose is to define coarse-grained access to the repository. There are three possible permission types: reader, writer, and admin. These permissions are exposed with Repository Groups. Users in the JazzGuests group have only reader permissions while users in the JazzUsers group have reader and writer permissions. Users in the JazzAdmins group have all three permissions. Some operations are currently restricted to users in the JazzAdmins repository group. For example, modifying permission settings of other users and creation of project areas.Permissions are assigned to a user in the user editor which can be opened from the project area and team area editors or from the context menu of a repository connection. Permissions can also be edited on the Admin page of the web ui.
System permissions are enforced on all operations in the repository. In contrast, process permissions provide for fine-grained control of process-enabled component operations.
Team Areas Can Define Specialized Processes
Process permissions and behavior can be configured with a great deal of precision and flexibility across the project organization.Each team can customize the process specified in the project area to meet the team’s particular responsibilities. If a team is defined as a child of another team, it can also customize the process of its parent. For example, the project might specify some preconditions which must be met before change sets can be delivered. If a particular team wants to set higher standards for their changes, they could customize the process of delivering change sets with additional preconditions which must be met when delivering code to their stream.
Teams can customize the process for all iterations at once or they can define their customizations such that they only apply during particular iterations. If a project (or individual team) has certain permissions or behavior which it doesn’t want teams to be able to customize, this is also possible by declaring them to be
final. Process Templates
A process template is selected when creating a project area. Among other things, it provides the project area with an initial process specification and iteration structure. The following is a list of the process templates provided out-of-the-box by Rational Team Concert. It is subject to change as the Rational Team Concert platform evolves.- Eclipse Way Process
- The process originally developed by the Eclipse Development Team. The ‘Eclipse Way’ is an agile, iteration-based process with a focus on consistent, on-time delivery of quality software.
- OpenUp Process
- The OpenUp process is one of the processes created by the Eclipse Process Framework project (EPF). It is included as one example of how to integrate existing processes.
- Agile Process
- The process is a mash-up of best practices of several existing agile processes.
- Scrum Process
- The Scrum process is a popular approach to managing projects in an agile way.
- Simple Team Process
- This is a simple process to get you started quickly.
- Cloudburst Sample Process
- The sample process is the process described for the Cloudburst reference project. For details see the Cloudburst project description in this document.
Sidebar: Process Documentation
A process template can include process documentation. You can define your process documentation in HTML form as a file archive. An example of this is provided in the Eclipse Way Process template. If you define a project area using this template, open the project area. On the Overview page, click on the Eclipse Way Process link under the Process Description section. This will open a browser window on a document that describes the process.
The documentation archive can be specified on the process template Overview page.
Putting it all together: the fictitious Cloudburst project
So far we have discussed project areas, team areas, and process permissions and behavior mostly in the abstract. To make this more concrete let’s look at a fictitious project named Cloudburst and map its project and team structure to what we have discussed. The Cloudburst project structure is straight forward but non-trivial. It is representative of an established project; that is, a project that must support an existing customer base, has shipped product releases that are being maintained, and is investing in new product development. It will be our reference project. The Cloudburst Sample Process template included with Rational Team Concert is a specification of the Cloudburst project. This is why you were asked at the start of this document to create a project area using this process.Take a few minutes to review the summary of the Cloudburst project below. Note that it has two significant but typical project groupings: development and maintenance, each with different delivery milestones and process requirements. Within development there are two teams. One is doing client development and the other is doing server development. For the purpose of this discussion, and to avoid trying to remember too many names, there are only five team members and they each have shared responsibilities by participating in multiple teams.
Cloudburst Reference Project
Project: Cloudburst, a software development project responsible for new release development and maintenance. Release 1 is shipped and Release 2 is under development.Team Members:
Kim:
project lead
Rick:
development team lead
Carol:
maintenance team lead
Mike:
release developer and maintenance developer
Zoe:
release developer
Development lines:
Development:
Sub teams:
Server Development
Members: Rick, Zoe, Mike
Client Development
Members: Rick, Zoe
Iterations (releases):
release 1, release 2
Iterations (milestones):
m1, m2
Iterations (milestone phases):
development (overrulable process)
end game (strict process)
Current iteration: release 2 / m1 / development
Maintenance:
Members: Carol, Mike
Iterations (releases):
1.01, 1.02 (comprehensive process; strict enforcement; few exceptions)
Iterations (milestones):
1.01, 1.02
Iterations (milestone phases):
maintenance
ready to ship
Current iteration: release 1 / 1.0.1 / ready to ship
For the following discussion you might find it useful to open the project area you defined using the Rational Team Concert Cloudburst Sample Process. This will allow you to map the discussion to the specification for the Cloudburst project.
The main development and maintenance aspects of the project are quite different in terms of process and deliverables. Each is working on different product releases with different schedules. Because of this, they are represented at the root of the project area as separate development lines. This allows them to operate in parallel, define their own iterations, and customize their processes to the differing requirements of development and maintenance.
Main development is currently working on release 2. Maintenance is supporting release 1.
Release 2 is currently in its first iteration, m1. This milestone is divided into two iterations named development and end game, where end game will require a stricter process to prepare the milestone deliverables for alpha testing. Maintenance has two iterations, 1.01, and 1.02, which are maintenance only releases. These releases need to be of very high quality. The maintenance release process is divided into two iterations which distinguish normal maintenance from the period shortly before a maintenance release, ready to ship.
What would this iteration structure look like in Rational Team Concert?
Cloudburst project area: development development line
Cloudburst project area: maintenance development line
If you examine the Overview page of the project area that you defined using the Cloudburst Sample Process you will see these development lines in the Process Iterations section of the overview.
Kim is the overall project lead and has been made the sole member of the project area. The rest of the project members will be defined within their respective teams.
What about team areas required to support this project? Examining the project definition, development needs a development team and two sub-teams, server development and client development. Rick and Zoe belong to both teams. Maintenance can be satisfied with a single team named maintenance with team members Carol and Mike. Here is how the team areas look in the Team Organization view for this team structure.
We have not described the mechanics for doing all this. We’ll cover that later. Let’s spend some time discussing how processes are specified in Rational Team Concert.
Sidebar: Jazz Development’s Project Structure
The Jazz Project itself has a comprehensive project structure as shown below. You can see that its 0.5 development iteration consisted of 11 similar milestones (M1 through RC2). Starting with release 0.6, it created a new iteration named 0.6 and added new development lines for maintenance.
Defining the Process for a Project and its Teams
Before continuing, let’s review a little bit.- A project area defines the teams, iterations, and deliverables which make up a project. When a project area is created you are asked to specify a process using a process template. This lays the foundation for your project’s process. The process applies to all project teams, but teams may customize the process to suite their needs.
- A project area must contain at least one development line, which defines a set of iterations. The Cloudburst project has two development lines in order to manage the parallel activities of current release maintenance and new release development.
- Team areas can customize permissions and behavior for artifacts which are associated with the team.
- Team areas and project areas are collectively referred to as process areas.
- Process can be customized for particular iterations. The active process is the process defined in the current iteration plus any process configuration inherited from parent iterations and the development line. In the Cloudburst example, the active iteration for the main development line is specified as release 2 / m1 / development. As they near the end of the milestone they will change the current iteration to release 2 / m1 / end game and the stricter rules specified in that phase will become active.
- Your team can define different roles and the process permissions and behavior can be configured differently for each role. There is a predefined global role named default, which applies to all users in the repository.
- Operation permissions define what operation actions are allowed for a given role.
- You may configure the behavior of your project area by using preconditions and followup actions which ship with Rational Team Concert, or are developed by your organization or other Jazz community contributors.
default role, which applies to all users in the repository. However, you can imagine that Kim, Rick, and Carol who all have a project lead role might be granted more process permissions than other users. In the Team Process Customization section you will have the opportunity to limit process changes to project leaders.If you read the Jazz Technical Overview for Team Process and the earlier Process Operations, Preconditions, and Followup Actions discussion you learned that there are different contexts in which preconditions can be specified in a process. You will need to understand what these contexts are in order to discover preconditions that are available in a given context. Let’s examine them.
- Configuration data: A component can declare that it has data affecting how it behaves which is configured in the project area. Configuration data is specified inside the project-configuration of the process specification, which means that it applies to the entire project and cannot be customized. An example of configuration data is the set of available work item types along with their priorities and severities. Each project can define its own work item types and then that set of work item types is available for the entire project.
- Operations: Operations are blocks of functionality which a component allows process to influence, either by determining permissions, affecting behavior, or both. A component’s operations generally center around the manipulation of its repository artifacts. When an operation is invoked, teams have the opportunity to insert appropriate logic both before and after the operation. For example, recall that the Source Control component defines a code delivery operation. The work item component’s save operation also invites process participation. There are two aspects of behavior which can be configured: preconditions and followup actions. Preconditions are run before the operation is performed and are designed to perform checking before allowing modifications to the repository. Preconditions support the notion of being optionally overrulable which will be detailed later. In contrast, followup actions extend the operation after it has completed, potentially making additional changes to the repository. If a server-side followup actions fails in some way then the entire operation is rolled back.
- Events: A component can generate events that report changes in the repository. These events provide the ability for the governing process to monitor changes and take appropriate actions after a change has been made. Followup actions can be defined that respond to events and perform some specific operations of their own. For example, when a work item state changes an event is broadcast. By configuring a followup action for this event, it is possible to specify that when a work item defect changes state to Resolve/Fixed that a verification work item be created.
Work item priorities are an example of configuration data which is specified for the project.
Here is an example of a precondition that has been specified for the SCM deliver operation. This precondition is checked when code is about to be delivered to the team. It encourages users to not deliver code with compile errors and will display information in the Team Advisor view during a delivery.
To locate this in the Cloudburst project you need to open the development team area editor from the Team Organization view and select the Process Customization tab. Note that more than one precondition is defined for this operation.
Observe that this precondition is configured for the Deliver (client) operation. It would not make sense to include this precondition in other operations. It is also worth noting the “User may overrule” checkbox, which applies to preconditions but not followup actions. If the process template does not specify this attribute, the precondition will default to not being overrulable. The assigned value affects what is presented to the user in the Team Advisor view. You might wish to uncheck the box for your team and customize the description to explain why the precondition is configured to be strictly enforced.
When you deliver code with compilation errors you see this problem indication in the Team Advisor view.
If the precondition is configured to be overrulable, a quick fix will be presented in the detail pane and in the context menu which allows you to request that the precondition be ignored. Here is how it would look in the Team Advisor view.
After requesting that the precondition(s) be overruled, you can retry the delivery from the toolbar or the context menu of the Team Advisor view (note that if you retry from the Pending Changes view, your overrule request will not be honored).
The delivery will then be run and any problems detected by the overruled precondition(s) will be ignored. Note that you will have to toggle the Show Failures Only toolbar action to see the successful delivery.
If you open the Cloudburst project development team area you will see that the end game iteration of milestone m1 has redefined the preconditions’ overrulable value to
false by unchecking the “User may overrule” checkbox. This is because the team wants to be more careful as the milestone nears completion.We’ve mentioned that operations can also have followup actions; let’s take a quick look at one. Recall that a followup action, unlike a precondition, becomes part of the operation. The followup action is called after the component operation has finished. If the followup action’s execution fails in some way then the operation does not complete (more correctly, it is rolled back). When a project area is created there is an initialization operation that process can participate in. This is how the Rational Team Concert Cloudburst Sample Process is able to create the Cloudburst reference project. Here is an example of that followup action.
Event handling is the last process enablement mechanism to be discussed. The Jazz server can generate events to report changes. A process specification or configuration can declare an interest in an event and specify one or more followup action that should be called when that event occurs. The followup action receives control when the event occurs and does whatever it was it was designed to do. There are no followup actions specified for events in the Rational Team Concert 1.0 product.
These concrete examples should give you some idea of how configuration data, preconditions, and followup actions are specified and some of the responses in the user interface when preconditions detect problems. You will be pleased to know that Rational Team Concert provides assistance in the discovery of available process operations, events, preconditions, and followup actions.
Whew! We have covered a lot of ground. Soon, we will show how to create your own custom project. Before we do, we will discuss process enforcement on the client and server.
Client versus Server Process Enforcement
Process operations can be implemented on the server and the client. Each has its advantages. A precondition that executes on the client can sometimes be more interactive, informative, and helpful to the user but you can’t be sure that you are protecting content on the server if that is your intention. Other applications with server access (like the Rational Team Concert web UI, for example) could make server content changes and subvert your intention. On the other hand, a process advisor implemented on the server will be less interactive, but it will be guaranteed to run before the server content can be changed.The Eclipse Way Process template provides a good example. In the initialization section of the process specification there are two followup actions; one for the server and one for the client. Here is a snippet of the XML.
<initialization>
<client-initialization>
<followup-actions>
<followup-action
id=”com.ibm.team.process.internal.client.runAssignedWorkitemsQuery”
….
</followup-actions>
</operation>
<server-initialization>
<followup-actions>
<followup-actions id=”com.ibm.team.process.internal.server.setUpProject”
….
In the example above there is a client and server process operation. The convention is to distinguish client and server operations by including these terms as a qualifier in the id.
Team Process Customization
A team can customize the process in their team area. The team area editor has an action on the Overview page named Customize the process which, when selected, will create a new editor page named Process Customization that will allow a team to customize their process relative to their parent(s).
In a team area, the process can be customized to override aspects of the process defined by its parents by creating a ‘team configuration’. Customizations only override the parent process for the operations and events specified; any operations and events which the configuration doesn’t mention inherit their configuration from the parent team(s) and the project area. Customizations completely replace (they do not extend!) the configured permissions or behavior of the operation or event defined in the parent process.
Finalizing a Process
For situations where your team doesn’t want behavior or permissions to be further customizable, operations and events can be marked asfinal. The default value for final is false. The “Final” checkbox on the Process Customization page of the team editor exposes the value of final. If the checkbox is checked then the configuration of the permissions or behavior for that operation or event cannot be overridden at lower levels of the project structure. For example, suppose a parent process is specified like this:With the “Final (ignore customization of this operation in child areas)” checkbox unchecked, a child team is free to ignore the compilation error precondition.
If the checkbox is checked in the parent specification then any attempts to customize this operation would be ignored.
Recall that the Cloudburst project’s maintenance team requires a strict process to help ensure high quality fixes. If you open the maintenance team area you will see that all the source control delivery operations have the “Final (ignore customization of this operation in child areas)” checkbox checked.
Process Templates
As you know Rational Team Concert includes a few example process templates out of the box. The Team Process component supports creation of new templates through the use of a simple wizard. This wizard produces a template containing a single development line, and a few nested iterations, and opens the Process Template editor. Within the editor you specify your development lines, iterations, permissions, and process behavior in much the same way that you might customize an existing process.An important difference between a template and an instantiated project area is that the iteration structure of a template is not persisted as records in the repository. For templates, iterations are defined in a separate XML document which is shown in the Process Iterations Source tab of the template editor. This XML document can also be edited graphically on the template’s Overview tab. When a project area is created from a template the iteration structure is converted into persisted objects in the repository.
Templates are managed in the Process Templates view which is visible in the Jazz Administration perspective and is available under the Administer context menu item on repository connections. Creating and applying templates will be covered in the third exercise in the next section, Team Process Customization Exercises.
Team Process Customization Exercises
Now that you have a general understanding how process works and some experience with creating a new project area let’s try to perform some basic configuration. First you will make some updates to an existing project area. Then you will create a simple process template and apply it to a new project area. Finally, you will work with process permissions and roles. This section is written as a tutorial.Customizing an Existing Project Area
Let’s start with the project area that was created using the Cloudburst Sample Process and make some basic modifications. If you wish to follow along and did not create a project area using this process, you will need to create three users and then create the project area. Here is the information for creating the users:- Name=Kim Cloudburst, username=kim_cloudburst, email=kim@cloudburst.com, license=Developer
- Name=Rick Cloudburst, username=rick_cloudburst, email=rick@cloudburst.com, license=Developer
- Name=Carol Cloudburst, username=carol_cloudburst, email=carol@cloudburst.com, license=Developer
The following process customizations will be made:
- Update the current iteration to reflect the evolution of the project to a later milestone phase.
- Add iteration start and end dates to the iteration structure.
- Create a new process template.
- Restrict process specification changes to project and team leaders.
1. Update the Iteration Structure to Reflect the Evolution of the Project to a Later Milestone Phase
The current iteration can be changed from the project area editor Overview page as follows. The current iteration for the development line is release 2 / m1 / development. Each iteration along the path to the current is decorated with a bright blue arrow. To change the current iteration to end game, select that phase, and use the toolbar action to Set as Current.
The end game iteration is now marked bright blue and the development iteration is marked as completed with a green check mark.
To make these changes permanent save the editor using the Save button.
The consequence of this change is that the process defined for the end game phase (specified in the Process Configuration tab of the project area editor) now becomes the active process.
2. Add Iteration Start and End Dates to the Iteration Structure
Iteration start and end dates allow you to define plans using the Rational Team Concert Agile Planning component. These dates are defined in the Process Iterations section of the project area Overview page. Select any iteration and click Edit Properties… and you will be presented with a dialog which lets you set the start and end dates.
3. Creating a New Process Template
Let’s create a simple process template. It will be very lightweight, containing the minimum required content. You can augment it to suit your own particular needs. Afterwards, you can deploy it to a new project area.Using the Process Templates view in the Jazz Administration perspective, start the template wizard from the context menu for a repository connection by selecting the action New>Process Template. Fill in the basic information and press Finish.
The template will appear in the Process Templates view and the Process Template Editor will open.
(this image has been scaled down)
Initially, there is a simple hierarchy of iterations defined in the template.
Let’s continue by adding an additional iteration. Select the “First Milestone” node in the Process Iterations section of the Overview page of the template editor. Click the “New Iteration” button. Specify an id and name for the iteration. Click the “Save” button. Voila! You have the skeleton for an additional iteration.
Return to the Overview page and set the new milestone-phase as the current milestone-phase using the context menu as shown here.
At this point you could save your process template and it would be available for use but there is thing that you’ll probably want to do first: configure the permissions of the
Save Project Area and Save Work Item Categories project operations and the configuration data for work items. You can change the permissions this in the Process Configuration page of the template editor, by selecting the Permissions node under the Project Configuration node and then selecting the appropriate roles and permitted actions. For information on configuring Work Items, see the Work Item Customization section of the Getting Started with Work Items document.If you wish to do more you can. You can modify permissions, preconditions and followup actions on the Process Configuration page. You can copy interesting content from other templates and experiment creating content from scratch in the Process Configuration Source page. You can use the content assist function (with keys Ctrl-Space by default).
Here are the basic steps for manually setting up a new project using this template .
- In the Team Organization view create a new project area using this template.
- Using the context menu for the new project area create a new team area.
- Add or define members of the team using the team area editor.
- Optionally, customize the process for project and team area.
- Optionally, add work item categories to the project area using the Work Item Categories tab of the project area editor.
- Optionally, define a source control delivery stream.
4. Restrict Process Specification Changes to Project and Team Lead Roles
In this exercise you will gain some experience with the use of process permissions by limiting process changes to users defined with a role of project lead or team lead. You will incorporate this into a new project area that uses the Cloudburst Sample Process template, the base for the Cloudburst project. You could also put this change directly into the template but since this a learning exercise let’s make the changes in a project area.Recall that Kim is the project leader for the Cloudburst project. One of Kim’s many responsibilities is to manage the project’s process.
Let’s start with an undisturbed project area based on the Cloudburst Sample Process template (don’t use the same project area that was used in exercises 1 and 2 above). Remember that creating a project area can only be done by a user who is in the JazzAdmins repository group. If you are not logged in as a user in thet group, do so now.
From the Team Organization view create a new project area using the Cloudburst Sample Process template and name it Cloudburst2. When complete the project area editor should be open.
The Cloudburst Sample Process template defines several users. Before continuing let’s make sure Carol, Kim, and Rick, all have access to the repository (See Sidebar: System Permissions and Repository Groups ). One way to do this is to open the Rational Team Concert web UI using this URL: https://localhost:9443/jazz/admin, login as user ADMIN (with a password of ADMIN). Click the User Management tab at the top. Click the name of “Carol Cloudburst” to open her user page. In the Repository Permissions section of the user page, make sure “JazzUsers” is checked. Click the Save button if you made changes. Repeat for Kim and Rick.
Returning to the Rational Team Concert desktop client go to the project area Process Configuration page. In the Configruation section, expand the Project Configuration and Permissions nodes. In the Roles section, select the Everyone node. In the Permitted actions section, notice the Save Project Area node under the Process node. It is currently checked. This means that the
saveProjectArea operation is currently configured for the default role (Everyone). To remove the permission for the default role to save the project area, uncheck the box. 
To allow the
projectlead role to save the project area, select the projectlead node in the Roles section. Then, check the box next to Save Project Area in the Permitted actions section. 
Note that the permissions for this operation are displayed under the Project Configuration node. This is because the
saveProjectArea operation is run in a global project context. That is, the permissions for saving a project area do not depend on the current iteration of any particular development line and the permissions cannot be customized in any team area.With this change in place only Kim, the project lead, can modify a project area and create root team areas. If you were to expand the Save Project Area node, you would see the actions this operation performs.
You can verify this by logging out, switching to user
kim_cloudburst, and logging back in. As user Kim, you should be able to modify and save the project area. If you logout and login as rick_cloudburst, who is not a project leader, and attempt to save the project area you will be advised that you cannot do this.
All you have done so far is limit project area modification to the project lead. You have not excluded anyone from making process changes to a team area. As an agile team we want to delegate where we can. This means we should allow the team leads to manage their own process (within the purview of the project area, naturally) so let’s limit team area changes to the team lead roles. In the Cloudburst project Rick is the development lead and Carol is the maintenance lead. There are two specific team lead roles defined in the
development and maintenance team areas named development_teamlead and maintenance_teamlead To limit changes to these roles you will use another process operation named
Save Team Area. Permissions can be defined for this operation to control who can make process changes. You will explicitly grant access to this operation for the team lead roles and, very importantly, exclude access for the default role.To limit permission to the team lead role for the development team area make the following changes. Open the development team area from the Team Organization view.
Go to the Process Customization tab. In the Configuration section, select the Permissions node. In the Roles section, select the Everyone node. In the Permitted actions section, check the Save Team Area node, then uncheck it. When you check and then uncheck a node, you are specifying that the permission is configured in this team area and that permission is not granted.
Next, select the development_teamlead role in the Roles area and check the Save Team Area node in the Permitted actions section. This configures the development_teamlead role to be able to save the team area.
Notice that we configured the
Save Team Area operation for the development_teamlead role and granted permission to modify team areas. In addition, we configured this operation for the default role and denied permissions for any actions performed by this operation by not assigning any actions to its permissions structure.One final remark. The permitted actions available to an operation are under the control of the component that provides the operation. A component might not define any special permissions in which case the operation is available to all users.
Conclusion
Team Process is a deeply embedded core component of Rational Team Concert. It does not define your process, rather it helps you enact the processes used by your project and your teams. As a core component it’s presence emerges when you create a project area, which is the root of all your team’s activities in Rational Team Concert. Team areas help you staff, refine, and structure your project. Your chosen processes can be defined across the project and tailored to the needs of individual teams. Rational Team Concert provides a set of process templates and a variety of process extensions to illustrate how your processes can be embedded into your everyday development activities. This translates to consistent execution within the project and teams. Whether your process needs are modest or extensive the Team Process component has the ability to help you execute the process that you choose.Additional References
Process Component Home – This wiki topic contains links to other topics that may be of interest to process users and authors.Team Process Developer Guide – This wiki topic maintained by the Process component explains how other components can open up for process enablement and how to extend the set of available process building blocks like advisors and participants.