This chapter is from the book
This chapter is from the book
This chapter is from the book
11.5 Agile with the ALM Schema
Companies that have decided to adopt the CQ-ALM (ClearQuest Application Lifecycle Management) schema on an enterprise-wide basis may still need to deal with projects and teams that are using an Agile development method. Those companies may ask if they need an additional schema for these teams. Our answer is that they do not; they can use the ALM schema. We shall explain how they can configure an ALM project in an Agile way. We assume that you are familiar to some degree with the CQ-ALM and the ALM terminology. Section 12.4, "ClearCase, ClearQuest ALM, Build Forge Integrated Solution Architecture," in Chapter 12, "Sample Applications and Solutions," includes additional discussion and examples of the CQ-ALM schema.
The ALM schema includes three work management state-based record types: Request, Task, and Activity. The Request record is similar to the one described in the previous sections. A Task record is created when the request is approved for development. Priority behavior is mandatory and you should add a field of type Integer for the estimated effort unless you are using CQ-ALM 1.1 where this field is already provided. Approving the request means that it was analyzed by both the technical and the business teams, and it was prioritized by the product owner or the stakeholders. The product backlog is a list of tasks generated by a query that displays all the opened tasks of a given project sorted by priority.
The ALM schema defines project phases and iterations. Agile projects do not use phases, so the ClearQuest admin can create a single phase record and name it with a dummy name such as Iteration or Sprint. The next step is to create iteration records with the numeric values of the iteration. For example, create iteration records and label them with 1, 2, and so forth. Using numeric values is only a suggestion; you can use any method, such as week in the year. When using the system, you will have Iteration 1, Iteration 2, or Sprint 1, Sprint 2, and so forth.
Figure 11.24 shows an ALMTask record assigned to Sprint 2.
)
Figure 11.24 ALMTask record assigned to sprint (iteration)
Another differentiator between our Agile schema and the ALM schema is the use of roles. Agile projects usually adopt the whole team practice; the skills of the whole team are what matters and team members' roles are less relevant. So we suggest creating a Role Label record for each team, using names like Team-A, Team-B, and so forth. In the Members tab add the team members to the Members field and the team leader to the Primary field. If relevant to your project add additional role labels such as TeamLeader or ScrumMaster (see Figure 11.25).
)
Figure 11.25 ALMRole record assigned to an Agile team
In the Scrum schema described in the previous sections we used a record type called Sprint. Do we need to create such a record type in the ALM schema? The answer is no.
A sprint is a team effort for a given iteration. What we need to do is to link the Request, Task, and Activity to the team and the iteration (see Figure 11.26). Among the many possible solutions we shall mention three:
- Add a field called Sprint to each of the Request, Task, and Activity record types. The team will fill in a value that uniquely identifies the sprint. The field value should be automatically copied when a child record is created. Although this solution is simple, it requires a schema change.
- The second solution uses existing fields. The Task record already has the field Iteration that references the ALMiteration record that has fields such as start_date, end_date, status_label, description, and others. The Activity and the Request record types have references to Task, so for each record we can find the iteration that the record was assigned to. We also need to relate the record to the team working on it; this is done using the ALMRole record as previously explained.
- The third solution is similar to the second one. We previously explained that we gave the phase a dummy value, so instead of using a dummy value we can set the phase name to be the team name. Now we have for the iteration a meaningful value that is the team name and the iteration name. The user will see in the Iteration field Team-A 1, Team-A 2, and so on, which identify the sprint numbers for Team-A.
)
Figure 11.26 ALMTask record assigned to a team
The team (field Roles) in Figure 11.26 is automatically selected when the task type is selected. This is defined by creating an ALMWorkConfiguration record with the following fields: Project, Record Type, Type Label, Roles.
The three solutions allow you to create queries to see the sprint status, cumulative effort, status of each activity, defects reported against a specific sprint, and other sprint queries, charts, and reports as required.
During the sprint planning meeting the team creates one or more activities for each task. Each activity is assigned to a team member. The number of child activities that will be created per task and the types of those activities can be defined and set by each team in the ALMWorkConfiguration record. This is a powerful and useful feature of the ALM schema.
In the Sprint Review Meeting, if the team found the tested deliverables to have the required quality, the team can Complete (an action) the Activated (a state) Tasks. Now the stakeholder can Accept (an action) the related Requests to release the deliverables and to Close the sprint (see Figure 11.27).
)
Figure 11.27 ALMRequest solution is accepted by the requestor
The ALMRequest record is accepted by the requestor (stakeholder) after the ALMTask is completed with resolution code Completed.