軟體專案管理方法

轉：warton(一年沒有在這裡"發表"文章了,今天把半年前翻譯的一篇文章拿來貼出來，以證明我還來這裡:)。是關於專案管理的方法。譯得不好，有問題大家提出來也讓我學習一下。如果大家喜歡，我會抽空翻譯一些這方面的書...) Methods of Project Managementby 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.        OverviewFor 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 討論和評審軟體開發是一個Team 專案，所以我們認為團隊精神是非常重要的，甚至它是關鍵項目成功的一個關鍵。一般由於市場競爭我們沒有足夠的剩餘時間留給軟體項目。因此，一個專案經理，在任何時候應該追蹤正在做的事情。討論和評審是通向目的非常好的路徑。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 ManagementVenture 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. EpilogueThere 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. 結語決定軟體項目的成功的因素很多。畢竟，在一個公司有能力的人是最重要的資源。對於大多數公司來說，我想那種可操控，規範的軟體過程也是一個基本條件。來自人才的聯合和好的開發過程的功效將是令人難以置信的。