When we implement GJB5000, do not focus only on how many process areas/practice domains, how many dedicated practices each KPA has, the standard overview/general rules of the standard framework, the composition of the process area/practice domain, the interrelationship and other contents are particularly important for better implementation of GJB5000.
Among them, the constituent parts of the process area/practice domain are said as follows:
Model parts of this standard are divided into three categories: required parts, desired parts and interpretive parts, of which: a) required parts are organized to meet the necessary concerns of the practice domain and achieve the level of objectives; b) the desired component is the practice of the organization in order to implement the recommended implementation of the necessary components; c) Explanatory components are informative instructions that help the organization understand the necessary components or guide the implementation of the practice.
This clearly shows that our implementation of GJB5000 should be achieved with the goal of the practice domain as the primary purpose, and that the practices at all levels of each practice given in the standard are only recommended and desired components, which means that there is no need to copy these practices, and that every organization implementing GJB5000 can use alternative practices that are not in the standard but are appropriate in order to achieve a practice domain.
So why does the GJB5000 standard treat these recommended practices only as desired parts and not as required?
Software development can only be pragmatic
Our original intention in implementing GJB5000 is to improve the software engineering capabilities and quality of software products of the organization, and whether the implementation of GJB5000 can bring such an effect is ultimately based on the quality of the software product. No matter how good the recommended practice is, if it does not produce corresponding effects in the actual application of the organization or the cost performance is too low, then it is not worth the organization to implement as is.
There is no silver bullet in software development, and the GJB5000 is not theology. We do not have to worship GJB5000 as a truth, for the slightest deviation from it is considered blasphemy.
Experience is only for reference
Almost all popular software engineering methodologies are derived from the experience of software practitioners, rather than basic research.
The practices recommended in the GJB5000 are actually the experiences of previous generations. Software developers who are good at summarizing take notes of what works in their projects and pass them on to the wider community.
For these experiences, it is recognized that:
This experience comes from a particular field or project scale;
These experiences were never expected to be used in all possible contexts.
Therefore, our practice in GJB5000 should only be a reference and reference, not a blind follow.
This is exactly:
The implementation of five thousand should be pragmatic, and practice is originally experience
Whether it is good to use to see the reality, put an end to brainless copying
Bibliography: Project Style: In-depth Understanding of Software Project Behavior Patterns, Author: (US) Tom DeMarco et al., Translator: Jin Ming, Publisher: People’s Post and Telecommunications Publishing House