When we first thought of partitioning SPI (software process improvement) project this way, we never though that we will uncover such illuminating facts about configuration management. For example, the fact that Workitems should be identified and tracked is central to CM; however, it was never highlighted or drawn attention to by us or by anyone else in the field.
Another note is that collecting all process increments falling under the CM umbrella and really add value to the organization resulted in an excellent collection of practices. These practices are often overlooked by Agile teams. If you are Agile, just have a look below, and think twice whether or not this practice will add value to you.
 |
| Configuration Management partitioned into 7 process increments |
Below is short description for every process increment:
- Version Control: Project configuration items are under version control, and team is trained on basic copy-update-merge and lock-modify-unlock procedures
- Workitem Tracking: Workitem types are identified, and workitems are managed and tracked
- Traceability: Bi-directional traceability of requirements and work products is defined and enforced
- Release Management: Release and release scope is identified; Changes are received, prioritized, and planned; packaging, releasing, and post-release verification procedures are enforced
- Baselining: Baselining procedure is defined and enforced at points where work product(s) are delivered to an external party
- CM Environment: Project structure is defined, access rights are enforced, backup/restore procedures are employed, and proper branching/merging techniques are in-action
- Continuous Integration & Deployment: Builds are automated; Integration between team members, and between teams is automated and frequent; and deployment is automated across different CM environments
In later posts, I will elaborate more on specific practices.
2 comments:
I like the post, except for the statement that "For example, the fact that Workitems should be identified and tracked is central to CM; however, it was never highlighted or drawn attention to by us or by anyone else in the field."
This is actually not at all true. There has been much published and written on this in SCM since the 90s using names like task-based SCM, activity-based SCM, and even the early work on change-sets and change-packages, and the whole "change control" (classical terminology) refers to (among other things) using what we now call workitems (before they were more formally called change-request or change-orders or change-tracking tools).
There has also been much writing in the area of "Agile CM" and "Lean CM" starting in the early 2000s that have touched on this many times.
Brad, I agree that there were a lot of attention to 'change requests' and other synonyms. However, workitems are much broader that change requests.
Workitems, as I described in other blogs, are broader than change requests. They have different types, may be hierarchical, and may have relations (different types of relations) to each other; and it should be the basic subject of configuration management.
I agree that there were so many resources that touched upon the concept, but never dealt with it as a central topic.
Post a Comment