I mplementing a software development process will probably result in an initial performance reduction for the obvious reason that people will be adapting to new procedures. (Why this perennially shocks everyone is one of the mysteries of organizational life.) But while we expect things to slow down as we adapt to new processes, we must not let process paralysis creep in [4]. If we detect it, we must get the project back on track by emphasizing that our goal is a product rather than a process. Consultants and outside process improvement teams may help mired groups, but outsiders should not take over: removing process ownership hinders adaptation. Remember that processes, once defined, will undergo incre-mental evolutionary change, and that changes in the volume of work to be handled, or in the technology underlying the process, may cause fundamental changes in the process. For example , a process for defect tracking on a small project might be wholly inadequate for a large project. As processes evolve and environments change, the whole process hierarchy should be examined for improvement possibilities. If there is a project process group, it should coordinate with similar groups in other parts of the organization. When working on process improvement, remember that reactive change will make things worse, not better. In most cases, people are impatient with the time it takes to improve a process, and they identify every variation in process operation as a problem to be fixed. The result is chaos. Worse yet, this also inhibits learning. A cycle of change, measurement, and evaluation must instead be followed. Deming makes this point forcefully [3]. Again, the system must get worse to get better. People tend to attribute mystical properties to statistics sent to managers. " We just collect it and let management decide, " is often the attitude. Managers, on the other hand, are compelled to ask for statistical data, even if they do not use it or methodically review it. They somehow believe they are not doing a proper job— or think they seem uninter-ested—if they do not ask for and save piles of data. This only accelerates the collection and generation of useless data. In micro-level processes, statistics should definitely be oriented towards informing the people doing the process so they can control and improve it. Moreover, at the micro-level, some data measurement may come and go as needed. Giving up information will initially …
[1]
Wei-Tek Tsai,et al.
To Object-oriented Software Development Transition to Object-oriented Software Development
,
2022
.
[2]
Barry W. Boehm,et al.
Verifying and Validating Software Requirements and Design Specifications
,
1989,
IEEE Software.
[3]
W. Edwards Deming,et al.
Out of the Crisis
,
1982
.
[4]
Eric R. Ziecel.
Four Days With Dr. Deming
,
1995
.
[5]
P. Senge.
THE FIFTH DISCIPLINE
,
1997
.
[6]
M. Beer,et al.
Why change programs don't produce change.
,
1990,
Harvard business review.