introduction:
I often see a lot of people's experience in project management on the forum, and they are all long-winded and talkative; I always see me dizzy, and I always feel that they are all stuck on the role of people and always emphasize the human factor in management. , almost many of the entries are highly artificial. After reading it, I always feel that these experiences are very good, but it is often difficult for me to implement them in my own projects.
idea:
I am a practicalist :), in project management, I always try to put aside the troubles of human factors, use some simple and general tools to assist project management, and let them automatically promote project management through the use of these tools. process, reduce the problem of human factors, and form an invisible production chain that promotes the process of the project.
Core chain:
Source Control Tools => Bug Tracking Tools => Daily Build Tools
WinCVS/CVSNT => Bugzilla => BAT and Perl scripts
The following is the experience of using these core tools:
1. The source code version control system must be established, which is cvs. The basic code submission principles:
1) Programmers try to submit only once a day before get off work;
2) The submitted code must be running normally on your own machine;
3) Each submission must describe the functional description of the submitted code in short words.
2. Establish a bug tracking system, using Bugzilla is good, configure the mail system, and make Bugzilla a bridge between testers and developers.
3. Use BAT and Perl scripts to implement a simple daily compilation tool with the source code in cvs as the core, put this self-written automation tool on a special compilation machine, and automatically download the code in the middle of the night every day. Automatically compile the code, automatically package the installation program, automatically record various compilation logs, and automatically place the installation program in a fixed public area with the date as the directory name. (Use cvs2cl.pl to get the code update log uploaded by the programmer for the tester's reference)
4. On the second day, the tester should go to the public area to get the latest version of the previous day, and test the new version according to the ChangeLog. And the bugs found in the test are fed back to the programmer through Bugzilla. Programmers can decide when to revise these bugs according to their own circumstances or company regulations. And the modification of these bugs will be written into the code log when the code is submitted.
5. On the second day of the developer, you should go to the public area to check the compilation log to see if your module is compiled normally, correct it in time, check your mailbox for bug reports, and modify it in time.
6. On the second day, managers can judge the development direction of the product based on the comprehensive project requirements and the progress of the previous day's version. If there is a deviation or misunderstanding or new requirements, they can adjust in time according to the current situation.
In this way, through cvs => bugzilla => daily-build, programmers and testers can interact and perform their own responsibilities. Reduce communication and human hassles. For the management, it can also be aware of: because there are new versions every day, you can keep abreast of the trend of the product at any time... and so on.
In addition: There is no specific discussion about the project management with customers, with the upper management of the company, cost, progress, etc., but if the above experience is practically used, the complexity of these relationships will be simplified to a certain extent, making each link relatively simple. .