ProjectCodeMeter
Software Development Productivity Monitoring Guidelines and Tips
ProjectCodeMeter enables actively monitoring the progress of software
development, by using the Productivity Monitoring process. In case the productivity drops significantly and steadily, it is recommended to
improve the accuracy of the project design specifications, check target
quality definitions, improve work environment,
purchase development support tools, reassign personnel to other roles, change development methodology,
outsource project tasks which your team has difficulty with, gain
experience and training for your team by enrolling them to
complementary seminars or hiring an external consultant.
This
assumes no motivational issues exist, such as personal issues,
compensation, daily experience, goal alignment, and
significant interpersonal conflicts.
Studies
done by IBM showed the most crucial factor in software development
productivity is work environment conditions, as development teams
in private, quiet, comfortable, uninterrupted environments were
260% more productive.
The second most important factors are team interactions and interdependency. Wisely splitting the project development tasks into small self-contained units, then splitting your team into small groups based on these tasks, will reduce the amount of interactions and interdependency, allow task parallelizing, exponentially increasing team productivity.
In
early design stage, creating a simple as possible control flow, modular
and intuitive code structure, using clear and accurate
function descriptions, and well defined goals, can significantly reduce development time .
Using
source code comments extensively to explain design considerations,
usage pitfalls, and external references, can dramatically reduce
development and maintenance time on
projects larger than 1 man month, increase code reuse, and shorten
programmer adjustment
during personnel reassignment.
Performance
review is best done weekly, in order to have enough data points to see
an average performance baseline. The purpose of which is for the manager
to detect drops and issues in team performance and fix them, not as
a scare tactics to keep developers "in line" so to speak, nor as a competitive scoreboard - It should be
done without involving the developers in the process, as developers may
be distracted or stressed by the review itself, or the implications of
it, as shown by the Karl Duncker candle experiment, that too high
motivational drive may damage creativity.