#feature #modeling #tracing #portfolio
In the following, we will have a look where feature models can help improving management of software development.
Definition
In software development, a feature model is a compact representation of all the products of the Software Product Line (SPL) in terms of “features”.
source: Wikipedia
There are many more sources on the subject, but this simple one will suffice here.
Manage Development using Feature Models
In software development features are mostly implemented by code. Your development process like e.g. Scrum typically focuses on people, communication, self-organizing teams, and a running system among other things. A Scrum team sprints its own way from stories to running code. A typical question popping up looking at the big picture is:
“How can development be managed across teams and products?”
Cascaded agile working models like SAFe and LeSS (Scrum of Scrums) argue that architecture plays an important role and at the same time needs to be aligned with the code. How can you scale architecture from product code to product portfolio?
Scaling Architecture from Products to Portfolio
Imagine you need to report a KPI for sales YTD based on weekly and daily sales data from various sales apps having different sales models. Three different app teams might be involved probably using different technologies and documentation. How do we get to a common denominator helping to organize development?
First, let’s understand the business logic regardless of technologies. The feature “KPI sales YTD” itself is agnostic of sources delivering the raw data. It provides a unified concept into which some magic transforms the feature “Timeline of sales numbers” from sources B2C and B2B.
Having identified those features we can now organize development. The app “Sales Information System” is responsible for calculating the KPI sales YTD while the apps “Sales System B2C” and “Sales System B2B” each manage timelines of sales numbers. Development effort can now be partitioned for the teams and dependencies are known too.
The central idea here is to find a common concept for both products and portfolio. For those managing across products and teams features are used as basic units while app teams refine those to their specific needs.
If you need more precision e.g. in the case that the aggregation of the timelines needs to be done in several steps like export timeline, enrich timeline, and sum up timeline you can cascade features. There are good approaches refining a feature model using e.g. business functions or business data or a combination of both.
Conclusion
Breaking products down into features has a lot of benefits
- Speak a common language (portfolio and products)
- Avoid double work (deduplicate feature implementation)
- Avoid overall waste (streamlined feature catalogue)
- Make progress transparent (plan per feature)
- Ease analysis (impact per feature)
- Clearly specify changes (story per feature change)
Feature models support improvement of software development especially in case of self-organizing product teams.
