軟體開發怎麼管?---產品、過程、人員三要素 (轉)

軟體開發怎麼管?---產品、過程、人員三要素 (轉)[@more@]

開發怎麼管?
----產品、過程、人員三要素
軟體世界記者 紅蓮

軟體開發過程中所特有的如質量、進度、人員流動等管理問題，讓不少公司也曾痛下決心來試行軟體工程的管理，但是往往從書本章程入手，注意力集中在概念和規則上，缺乏具體的操作手段。經過一段時間的堅持之後，管理慢慢流於形式，勞民傷財，效果不佳，最後成了紙上談兵，不了了之。

成功實施軟體工程管理的兩個條件

無論是在新成立的公司中，還是在一個已有的軟體隊伍中實行一種新的管理方法，要想成功有兩點是必須的：首先是要對軟體工程活動的主體，員和一線管理人員，有實用價值。使他們的工作更加有條理，有，因此更加輕鬆。他們是軟體工程活動的主體，必須是管理方法的受益者，才能樂於採用，而不是“配合”。如果一個方法是增加他們的工作難度，很難指望他們能夠長期配合。

其次是要符合循序漸進是事物發展的客觀規律。因為人們對新的事物都有一個逐漸適應的過程，各個部門之間也要有磨合的時間。有些公司試圖一次到位，部署實施某某體系，決心很大代價很高，結果是欲速則不達。大到蘇聯的休克改革，小到有些外科手術要分幾次進行，都說明了同一個道理。

科泰世紀在和欣操作的研製過程中，從軟體工程管理的三個主要方面入手：產品Product、過程process和人員People，可以簡單稱為3P開發管理方法。這套管理方法涵蓋軟體開發管理的基本內容，適用於我國大多數軟體公司。它的具體體現就是軟體工程中常用的幾個基本工具，具有很高的可操作性，能實際解決具體的問題。

3P工具是管理理念和實際操作的濃縮

3P管理工具從提高一線人員的效率入手，簡單易行，行之有效。從評估，到使用，最快的一週時間就能完成。大多數人所使用的基本功能只需要的一小時培訓，就能見效。透過工具的實際使用，落實管理的理念的規則。

科學技術每前進一步都伴隨著工具的發展，任何行業的進步都離不開工具的改良。而工具是否齊全配套，是衡量一個行業是否成熟的重要標誌。對於一個企業也是一樣，是否採用先進的工具對於企業的生產效率、產品質量有著決定性影響。修腳踏車靠幾把扳手螺絲刀就能開張，而開設正規的汽車修理廠至少需要幾十萬元的工具和裝置。不少軟體企業給人的感覺是“作坊”，其中一個重要的原因就是連基本的軟體工程工具都沒有采用，讓人聯想起鄉間公路旁邊“精修各種汽車”的鋪子。

世界其他軟體工業發達的地區，經過幾十年的摸索，已經逐步發展出很多有效的開發和管理工具。掌握了這些工具，就基本上掌握了軟體工程的實際內容。透過學習使用這些工具，可以瞭解在正規的專業化的軟體生產過程中，有哪些是必須注意的主要問題，採用什麼方法才能夠解決。從解決這些基本的實際問題開始，逐步完善軟體生產管理體系，是實施軟體工程的有效途徑。

產品管理（Product）

軟體開發隊伍的管理是最突出的問題。任何行業中技術骨幹離職對公司都不利，但是在軟體行業最為嚴重，甚至會影響到公司的生存。 如果離職的人要另立門戶，或者投奔競爭對手，對於公司就是一場災難。

如果一個公司的產品生命線是掌握在幾個人手中，這些人自然就有了某種特權。這種“少了他玩不轉”的人，在公司中比管理者更具有優勢。在這種局面下，勞動紀律，獎懲制度等等管理措施都失去了著力點。有人把這種現象稱為老闆給下屬打工，十分形象地道出了管理者的被動地位。

出現這種現象的根本原因在於沒有規範管理。構成公司產品的各個部分散落在個人手中。即使能夠在離職之前移交，也難免殘缺不全， 別人無法在短期內掌握，或者發現問題。要想徹底避免這種情況出現，需要把公司的產品Product管起來，使軟體生產過程隨時處於大家都可控制，可重複，可複製的狀態，減少對個人的依賴。

科泰世紀所採用的版本管理系統不僅僅管理源程式，而且可以管理開發環境，測試程式等等和最終產品有關的所有資料。有了這些資料，任何人都可以在一臺新機器上重複產品的生產全過程。

談到嚴格的管理，有人就會擔心怎樣為員工提供寬鬆的工作環境從而提高工作效率。其實在正確工具的輔助下，二者不但不相互衝突， 反而是相輔相成的。產品管理不但能夠方便個人的工作，還能夠有效協調多人的合作，參加的人越多，效果越明顯。這正是科泰世紀的管理工具受到程式設計師歡迎的根本原因。

過程管理（Process）

理想化的軟體生產過程是從需求分析開始，整體設計，模組設計，編碼，測試，等等。但是在實際過程中，往往是到了手中，又提出了新的修改或者增加功能的要求，工程的目標發生了變化。

從工程實現的手段上看，由於對於技術的掌握程度不同，迫於競爭壓力還要不斷採用新的技術和方法，結果形成用不確定的手段去實現不確定的目標。管理的困難程度自然就更大了。

人們經常會借用其它工程領域裡面的管理來管理軟體生產，但是最終卻發現不能適應。軟體生產過程具有一些特殊性，其中最突出的一點就是充滿了不確定性。在某個意想不到的環節上出現的問題都可能導致整個計劃的調整。常常看到“就差一點”的專案一拖再拖， 這時候按照各個工序的前後順序畫出來的進度表會變得毫無意義。

許多軟體專案都是由先期的試探開始，逐步確定方案和技術路線。先期的程式碼也就成了後來的基礎。這就引出了了軟體開發中的一個重要問題：任務跟蹤。

在先期試探的過程中，為了儘快達到驗證的目的，許多細節都被忽略。大樓已經封頂，可是遺留下來的工作卻還很多。這些工作有些是寫在計劃之中，有些是程式設計師隨手丟下的。為了解決某一個問題，發現涉及到其他問題，而時間和精力又不允許把所有問題一次解決，這在開發和維護軟體的過程中，是經常出現的正常情況。這些沒有完全解決的問題數量很大，靠人的記憶是沒法管理的。有些問題涉 及到其他模組，需要別人的配合才能解決，有時候甚至不知道應該由誰來處理最合適。所有這些特點都使得軟體工程的流程控制比起其他工程更加複雜。如果沒有相應的工具，管理起來十分困難，往往形成許多似曾相識的問題一再出現。

過程管理，就是要不斷記錄新出現的工作頭緒，隨時掌握工程進度，科泰世紀的“缺陷（）跟蹤系統”就是針對這一需求開發的 。需要跟蹤的BUG不僅僅是指程式碼中存在的錯誤，而是泛指全部有待處理的事情，包括功能改進的建議等等。

從管理角度看，BUG的狀態和負責人是兩個最重要的資訊。一個BUG從登記，修理，複查，驗收到最後關閉，形成一個完整的生存週期，在每一種狀態下都要有明確的負責人。每個人對於BUG的描述、判斷，和所做的測試、修改等工作都被記錄到中。這些都是寶貴的工程檔案，對於解決軟體中的缺陷和今後維護軟體都是十分寶貴的。

透過科泰世紀的BUG跟蹤系統，系統中還有哪些有待解決的問題，它們的困難程度，誰在負責等重要資訊都可以做到一目瞭然。產生的各種報表可以實現對BUG的全面，隨時掌握軟體的質量和工程進度。特別是在工程收尾階段，BUG清單是瞭解工程狀態的最好手段。

人員管理（People）

軟體生產不確定性也困擾著對軟體工程隊伍的管理問題。當工程遇到困難的時候，究竟是技術本身的問題還是個人的能力問題？當工程進度受到挫折時，是屬於正常的摸索試探，還是由於工作沒有做到位？一個最明顯的例子是對於修復BUG的工作量估計。有些問題看起來很嚴重，實際上修復起來卻很容易。另一些問題正好相反，表面上看起來問題不大，可是深層裡盤根錯節，修起來牽扯太多，不僅費時，還存在引出其他問題的風險。

軟體開發需要創造性思維，也是精力高度集中的工作，個人的精神狀態對於工作效率影響很大。 按時打卡上下班，對於軟體開發人員來說是限制的作用大於管理的作用。有些公司採用“計件”的方法，用每週的行數多少來衡量程式設計師的工作量。在這種制度下，不管程式設計師是否有意，程式越寫越長是難以避免的。也有的定下每週要修理三個BUG的工作定額，結果造成大家在不停地修小BUG，真正的大問題一拖再拖，還有人可能一週修了五個BUG只報告三個，留著兩個下週再報。管理到了這個份上，調動員工的積極性就無從談起了。

工作量的衡量已經如此捉摸不定，工作態度就更加難以把握了。程式設計師最有價值的勞動是發生在腦子裡，如何才能避免出工不出力得情況？有些人很有能力，可以做更多的工作，可是如果周圍的人是出工不出力，他們的積極性就很難長期維持了，時間長了甚至會造成和他人格格不入的局面。因此也就放慢腳步，做到心裡有數，完成自己的本份工作就行了。大家在這種情緒互相影響之下，結果往往是能力有限的員工影響那些有潛力的員工，使得“本份工作”的標準變得越來越低。

個人工作尚且如此，多人合作的任務考核起來就更難了。軟體開發過程中需要工程人員相互合作配合，幾乎每一項工作都要和別人銜接。工作中的這種交叉的相互依賴關係，沒法像生產線上劃分得那樣清晰，如果有了問題應該由誰來負責？有些事情雙方都需要有所改動，也有的時候雙方之中哪一方改動都行。如果相互等待就會消耗很多時間，造成整體的工作效率下降。

科泰世紀的績效評估系統能夠幫助管理層對於開發人員作出公正的評估，以此為基礎才能建立有效的獎懲制度。公開的評價體系可以為員工樹立明確的努力目標。有效的激勵機制能夠調動每個人的積極性，建立一支配合默契，團結奮鬥的隊伍。