软件项目管理方法

(一年没有在这里"发表"文章了,今天把半年前翻译的一篇文章拿来贴出来，以证明我还来这里:)。是关于项目管理的方法。译得不好，有问题大家提出来也让我学习一下。如果大家喜欢，我会抽空翻译一些这方面的书...)

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. 

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

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, I’d 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．软件中开发的一些提示

于此我为软件开发列出一些提示。由于背景和习惯的不同，这些提示可能并非对任何人有效。但是如果这些提示能带给你某些深入的思考，我想它们是有价值的。

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.

2．1软件预算

任何计划的制订（working-out）都是基于软件大小。一旦我们抓住了对项目的软件大小和构架的理解，我们就能初步安排人力数据和进度。这种安排不必精确。当软件开发过程推进，理解加深之后，无论如何，软件预算将变得越来越精确并且计划安排将。。。。

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.

在软件项目的初始阶段，我们应该实施第一次软件软件评估。软件项目可以被分解成一些功能相对独立的功能模块(注意：这里的模块不同于那些在HLD阶段中被定义的模块)。其间，我们也能认识到哪个模块是最难以及哪个是最重要的。一旦我们有了这些数据，我们根本的人力数据和进度就离我们不远了。同时，我们可以保持我们的眼光在这些困难和重大模块之上，也就是那些投入较大的资源地方。

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. 

在每一个软件开发阶段的结束，正如SRS和LLD,我们可以重新评估软件的规模并调整我们的项目计划。实际上这是一个项目计划的回顾过程。这种回顾的优点是更好地使用项目资源和发现存在的项目问题。仅仅通过这些持续的更新，项目计划真的能指引我们的开发行为。否则，随着项目的进行，这将变成一块没有使用的白纸。于是，你会感觉进度总是在你的掌控之下。当然，这是一种非常令人愉快的感觉。

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 can’t understand or you think the previous design is wrong, please don’t 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.

2．3风险管理

风险到处都有。在软件开发阶段，我们会遇到许多困难，并且我们应该真正尝试克服它们。另一方面，我们仍然需要预见我们未来可能发生的风险，并采取行动来减少这种潜在风险对项目的影响。这就是风险管理的概念。

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.

结语

决定软件项目的成功的因素很多。毕竟，在一个公司有能力的人是最重要的资源。对于大多数公司来说，我想那种可操控，规范的软件过程也是一个基本条件。来自人才的联合和好的开发过程的功效将是令人难以置信的。