In the 321 Gang webcast , I walked you through a scenario for using Configuration Management of lifecycle artifacts and components to help manage strategic reuse. The examples are shown in the IBM Collaborative Lifecycle Management tools combined with the Global Configuration Management capability. The example is also based on a complex customer scenario with Product Line, Releases, shared components and shared requirements across product line variants of the components.
In this blog, I provide some guidance on the best practices we learned when implementing this solution with customers. The blog will assume that you have reviewed the webcast.
Have dedicated resources whose job includes setting up work streams and change sets for elements in the bill of materials
Normally the lifecycle artifacts are owned by one or a few people working in a lifecycle-domain-specific role. For example, a Requirements Analyst (traditional) or an Epic Owner (Scaled Agile Framework) would create the requirements for a component variant for a product line release. She will focus on requirements and coordination with other team members, and will therefore not necessarily have a holistic picture of how the work streams and change sets should be set up across lifecycle domains. She won’t really care if the naming convention is consistent because she is focused on requirements.
By assigning responsibility for setting up streams and change sets to one person or a small group of people, you help ensure that the configuration management is not an impediment to the team members getting their work done. This practice also ensures that the Bill of Materials view for any product line release as well as the detailed lifecycle artifacts for any version of a component are quickly understood.
These folks who own the responsibility for configuration management at all levels also become the mentors for team members who are adopting configuration management at a detailed level (e.g. testing) and for people working at a higher level who need answers that the global configuration management provides.
Determining who creates baselines and when is a part of your configuration management strategy. Your configuration management strategy is strongly influenced by your process type, e.g. Agile or Waterfall.
Use naming conventions to reduce confusion
Because the CLM tools we used in our example may or may not be used in conjunction with other tools in the same suite, the tools make no attempt to try to create or enforce a naming convention on baselines, streams or change sets. Yet a practitioner (e.g. Designer) needs to select the context in which she is updating a design. She needs to know for which component for which product line and which release she is making changes. If component versions are shared wholly across product lines, she needs to know for which component version she is making changes. Practitioners responsible for making changes in the same context but to other lifecycle domain artifacts (e.g. requirements) must also select the right context. Finally, the configuration manager must select the right sets of lifecycle artifacts to group together at the component level.
In our example in the webinar, we use this convention:
The name of the stream is <Component><Product Line> <Lifecycle Domain><Release>
Arguably, the use of the lifecycle domain is redundant because it is represented here in the Global Configuration Management view, but that is not the case everywhere in the tool that we view it, so we added it to leave no room for confusion.
For baselines, we also use the date-time stamp that the system offers us when we create the baselines.
And lastly, we chose to make a change set for each new business requirement approved for the release. While change sets are optional, we need it in our example so that we can choose whether to accept a change into the stream (based on testing or customer approval). We also use them to share common requirements across our component variants. Because the change sets belong to a Stream, we chose to only name the variants to distinguish them.
Set up a sandbox environment with GCM turned on and require practitioners to prove proficiency
If the practitioners do not work in the proper context, the whole use of configuration management can get really ugly, really fast. It will be tedious to undo and redo work that was done in the wrong stream or change set, and it may not even be detected without proper review of changes before they are accepted or baselined. Because this is a new work paradigm for practitioners in requirements, design and test, you must ensure that they are properly skilled to perform their jobs well.
Configuration Management is a necessary capability in complex enterprises, like those requiring Product Line Engineering. Mastering this capability will streamline the organization, but must be done with due diligence. Please share your best practices with us, and let us know how you are progressing in this area.
2017-02-08 – Blog Author: Cindy VanEpps
With a passion for whole-lifecycle streamlining for the Enterprise, Cindy brings deep expertise in software development lifecycle tools and methodologies. My specialties include Scaled Agile Framework, DevOps, Product Line Management in software and systems.