原创 2004年09月11日 16:41:00


Methods of Project Management

by Vox Guo  翻译 warton (出处不详)

This article is not called methodology but methods, because it concentrates on the specific ways used in the software development procedure. It focuses more on practical applications than on academic analysis. But as you all known, these conclusions are based on the past project experience and my personal feeling. So it is not confusing if there are some errors. Any further discussions and suggestions, therefore, are welcome. 

本文并未起名为方法学,而是叫做方法,因为这里集中讲述的是软件开发过程中被使用到的一些具体的方法。相对于理论分析而言,本文多集中于讲述应用软件开发实践。但是正如你所知道的那样,这些结论是基于过去的工程经验和我个人的感触。所有,请不要被我的文章搞胡涂了,如果这里有些错误的话。因此,任何近一步的讨论和建议都是欢迎的。<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

1.        Overview
For the software development procedure, the most pivotal factor is controllable. A disordered project directly causes high cost, prolonged developing period and finally low-quality software product. Of course that is not the result that we would like to see. 

1.   概述


In my opinion, when a project finishes, we need not only a stack of software, but also little maintenance (means high quality) and a bridle-wise team and a heritable developing procedure. Inheriting means accumulation and continuity. That is why many great companies can rapidly issue new products to survive from the competitive market. It is just like the words from a famous scientist, I have gained so much success. Because I am standing on the shoulder of giant. 

依我看来,当一个项目结束时,我们需要的不仅仅是一堆软件,而要有更少的维护费用(意味着高质量)和训练有素的团队以及可继承的开发过程。继承意味着积累和连续性。这也是为什么那么多大的公司能够快速发行他们的新产品以幸免于市场的竞争。这就像著名科学家(newton 译者注)讲的那样,“我之所以取得成功,是因为我站在巨人肩膀上的”。

For those developing little-sized companies, it is not worthy to manage software project entirely according to procedure of CMM (Capability Maturity Model for Software), because the cost is so high that these companies will lose their flexibility. Software developing, however, should conform to some basic rules for software quality management. It is helpful for the quality of final product.

对于那些小型开发公司,完全依据CMM(Capability Maturity Model for Software 软件能力成熟度模型)来管理软件项目是不值得的。因为这样的花费太大,以致于公司将失去它们的韧性。为了软件质量管理,软件开发无论如何应该遵守一定的基本规则。这将对于后期的产品质量很有帮助。

If I am asked to describe the project management using only one sentence, Id like to say it is controllable procedure. What I mean is that the quality and schedule should be controllable whichever software phase you are in. 


2. Tips for Software Developing
Herein I list some tips for software developing. As the background and habits are different, these tips probably are not available to every person. But if these tips will bring you some further thoughts, I think they are valuable.



2.1 Software Estimation

The working-out for any plan is based on the software size. In case we grasp the software size and architecture cognition for software project, we can originally arrange the manpower resources and schedule. This arrangement must not be accurate. As the software developing procedure goes along and the understanding deepens, however, software estimation will become more and more accurate and also the plan arrangement will press close to practical case.



In the initiation phase of software project, we should carry out the first software evaluation. The software project can be divided into some correspondingly independent functional modules (note: the modules are different from those modules defined in HLD phase). Functional points of every module should be nailed down. According to these functional points, we can evaluate the size of the module through our software common sense (note: some methods are provided by software engineering). Meanwhile we can also realize which module is most difficult and which module is most significant. Once we have these data, our rudimentary manpower resources and schedule are not far from us. At the same time, we can keep our eyes on those difficult and significant modules on which more resources are used.


At the end of every software development phase, such as SRS and LLD, we should re-estimate our software size and adjust our project plan. In fact it is a review procedure to the project plan. The advantages of this review are to make good use of our project resources and find the existing problems in the project. Only through these continuous updates, can the project plan really direct our developing activities. Otherwise it will become a piece of useless white paper with the project going on. Then you will feel that the schedule is always controlled in your hand. Of course, it is a very pleasant feeling. 


2.2 Discussion and Review 

Software development is a team project. So we think that team spirit is very important, even it is a key to the success of the project. Usually there is not so much time left to software project because of market competition. Every project manager, therefore, should pursue doing a thing well in one time. Discussion and review are good ways to reach that goal.

2.2 讨论和评审


A good project must have a good developing procedure. It is document that reflects this good developing procedure. How can we finish top-quality documents in limited time? I think there are three significant factors. First of all, before you begin to write, discussion among related team members is required. This discussion includes not only technical problems, but also some details such as document style. Once these problems are solved by the team, the following work is only documental work which is a piece of cake. Secondly, in the process of writing document, if you find new problems that you cant understand or you think the previous design is wrong, please dont hesitate to put forward these problems to discuss with your colleagues. Through this continuous discussion, we can converge the wisdoms of all the team members to assure there are few errors left in the final document. With the project going on, our understanding will deepen. Then we maybe find some ignored sectors which will influence our design. So the third factor to get top-quality documents, I think, is the review and upgrade of the finished document whenever we have new findings. 


Undoubtedly, for a limited-period project, discussion and review mean abundant cost of time and it is not easy to arrange in most cases, especially in case of work occurring synchronously. The key to resolve the problem is elaborate partition for time and manpower. Giving an example, if we have some documents to review next week, it is reasonable to finish arrangement in this weekend. This arrangement includes attendees, time, sites and duration of every review. Only through this careful arrangement, can we avoid conflict of review. Usually before the formal review, we leave time to team members to prejudge the review content. In the review meeting, in order to save time, the only aim is finding problems, not solving problems. Further discussion should be held after the review meeting. Meanwhile we should adopt some steps to trace the problems found on the review meeting to avoid missing. 


It is worth using plenty of time on discussion and reviews, because many personal errors are exposed in discussion and reviews. At the end of our project, we find that the value of discussion and reviews is incredible. Additionally, through this continuous communication and cooperation, we know each other better and the effectiveness of the team has been strengthened. 


2.3 Venture Management

Venture occurs everywhere. In the process of software developing, we will meet many difficulties and we will indeed try our best to overcome them. On the other hand, we still need to forecast the ventures we will encounter in the future and take action to decrease the influence of those potential ventures. This is the concept of venture management.



For a software project, the most serious venture is manpower. Most projects are divided into different functional modules managed by individual engineer. Can you imagine some engineer leave the company suddenly? To avoid catastrophic sequent, manpower backup plan should be initiated in the beginning phase of software project.


How can we process manpower backup plan in case of lacking engineers, which is occurring in many companies? Although we have no way to make some engineers backup the other engineers, it is possible that some engineers are partly in charge of other modules. At least they must understand the basic principle of other modules. This thought can be realized in the process of discussion and review if we make management reasonably. If one engineer is selected as a candidate to a module, he should take part in all the discussion and review related to this module. That is to say he is relative to this module. When a project manager lays a course, therefore, he should consider this relationship. As long as we stick to this method, that engineer or more engineers will be familiar with that module which is not in the scope of his or their charge essentially. As a result, even if this venture becomes reality, the project can survive more smoothly. 


There are other ventures beside manpower, such as lab equipment, tool software and test environment. All these ventures should be recorded and traced. Meanwhile the project should have a plan to reduce the effect of the ventures. While one venture disappears, the record related to this venture should be closed. At the end of every developing phase, project manager should call a meeting to discuss which venture we will probably meet in the next phase. It is just like a saying, Although it does not rain, we should get the umbrella ready.  


3. Epilogue

There are many factors determining the success of a software project. After all person with ability is the most important resource in a company. For most companies, we think that controllable and regular developing procedure is also an essential condition. Efficiency from the combination of person with ability and fine developing procedure will be incredible.



软件项目管理方法 (转)

  • yuelengxin
  • yuelengxin
  • 2006年05月28日 14:37
  • 1868


  • Eastmount
  • Eastmount
  • 2014年11月25日 17:06
  • 4351


需求管理的过程:需求获取、需求分析、需求规格编写、需求验证、需求变更 风险的三个属性:风险事件、概率、影响 当项目进行到某一阶段,项目经理发现项目组的一些人(包括关键人)要离开公司,这是项目经理首...
  • liuchuo
  • liuchuo
  • 2016年12月26日 17:20
  • 1408


一、项目启动(项目开工会) 了解项目干系人及其利害关系。 所有项目组成员是否到位,如到位则拿到项目开发人员的简历,详细了解每个开发人员的情况(可能会组织到客户方面试)。 根据项目需求...
  • u012576527
  • u012576527
  • 2016年08月28日 08:03
  • 5209


  • yuyunli1989
  • yuyunli1989
  • 2016年01月31日 23:51
  • 565


问题一:缺乏项目管理系统培训 相关对象:项目经理、管理人员 问题说明:项目经理在项目管理方面的培训较少或不够系统。项目经理或管理人员不了解项目管理的知识体系和一些常用工具和方法,所以在实际工作中没有项...
  • hbzhangjian
  • hbzhangjian
  • 2006年08月17日 11:47
  • 1044


第1章 软件项目管理概述 项目就是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力区分项目与日常运行 项目 日常运作 一次性的 ...
  • liuchuo
  • liuchuo
  • 2016年11月23日 17:23
  • 1630


多快好省建设共产主义。 这个口号包含了项目管理的三大目标: 快:进度 好:质量 省:成本...
  • Testingba
  • Testingba
  • 2014年02月27日 14:19
  • 1233

了解编程的心理 谈谈软件项目管理的重要性 (转)

关键词: 了解编程的心理    谈谈软件项目管理的重要性    (转)                                           了解编程的心理 原著...
  • ljafl9988
  • ljafl9988
  • 2012年06月03日 22:32
  • 3315


  • qq_net
  • qq_net
  • 2004年09月13日 13:47
  • 748