現代軟體工程 第七章 練習與討論

標籤：style   http   使用   os   檔案   資料   

 7.7  移山開發方法——比TFS敏捷更精簡

幾個軟體學院的學生來請教阿超，同學們自豪地說，我們要用全套TFS敏捷開發模式開發項目！

真的？阿超不敢相信。

同學： 對！我們要用全5個工作項目類型 – 任務、缺陷、情境、風險、服務品質需求、

阿超： 你們有多少實戰項目的經驗？哦，都沒有。這麼說這是你們第一個真正的實用項目，我建議你們先忘記這麼多工作項目類型，把時間花在寫代碼上好了。

同學： 可是老師要我們上敏捷開發模式呀?

阿超： 當敏捷模式變成強迫，那還能敏捷到哪兒去呢？如果你們非用不可，我建議你們只用其中兩個工作項目類型：

• 任務
• 缺陷

同學： 超總，我覺得其他的工作項目類型也很好用耶，比如情境，風險——沒有風險管理，我們咋能上CMM等級呢？

同學： 還有“QoS——服務品質需求”，難道你不重視程式的效能和可擴充性？

阿超： 看來你們讀書都不錯，那些類型都很好，但是不直接使用這些類型並不表示我們不重視，特別是風險。因為在一個全新的團隊中不加辨別地使用所有工作項目類型也是一種風險。它增加了VSTS的系統複雜性，從而增加使用者（就是你和我）學習和使用的難度，浪費時間。有可能使項目的進展受到影響！至於“服務品質需求”，我們很重視程式的效能和可擴充性，但是不必拘泥於非要用某一特定的類型不可。

對於小規模的項目，我的原則是“直奔主題，精簡過程”，我們的主題是啥？讓使用者買我們的產品，只要使用者滿意我們的產品，他們會關心我們內部開發模式用的是哪幾個工作項目類型嗎？

我個人認為項目開發過程中有兩件不同類型的事：

（1）事先預計到的要做的事。這就是任務，把要做的事情組合起來實現使用者某一個特定的需求，這就是情境，也可以用任務來表達。

（2）事先沒有預計到，但是為了項目成功而不得不做的事。這就是缺陷。

軟體開發的過程就是做完這些“計劃要做的事”和“沒計劃，但是不得不做的事”，做好就行了。等你們做了三五個項目，寫了一萬行以上的程式，再來看情境、風險、服務品質需求也不遲。

同學：您說得在理，但是老師讓我們用全套敏捷模式，我們怎麼辦？

阿超：你們可以回去告訴老師說這是最新的“移山精簡開發模式”，填補了國內外空白，很好用。

把同學們打發走了以後，阿超轉念一想，為什麼不呢？“移山精簡開發模式”，說不定對小型團隊來說是一個很好的模式。

舉例說明：例如我們要設計一個網上拍賣的網站，商業使用者（簡稱商戶）可以開商店，賣東西；一般的使用者可以瀏覽，購物。

商戶可以用我們的系統進行登入。這是情境，也可以叫任務，我們要以此為基礎，驅動開發與測試工作：

我們計劃要在網路使用者介面實現商戶登入管理，這是任務。

我們計劃要在中間邏輯層實現商戶登入管理，這是任務。

我們計劃要在資料層實現商戶登入管理，這是任務。

我們計劃要測試商戶登入，這是任務。

我們計劃要系統能支援100個以上的商戶同時訪問，這是任務，同時也是“服務品質需求”。

在某些情況下，商戶登入失敗，這是缺陷。我們事先沒有預計到會出這樣的問題。

在標準配置情況下，20個以上的商戶同時登入時，系統的回應時間很慢，這是缺陷。我們事先沒有預計到會出現這樣的問題。

系統在上傳某種影像檔時出錯，這是缺陷。

對於一個不太複雜的系統來說，每次裡程碑（迭代）中要實現的情境應該兩個手掰指頭能數得過來。而且情境是相對穩定的，不會突然間有大的變化。對於一線的開發與測試人員來說，每天打交道更多的是任務和缺陷。過多的類型會增加管理和交流的成本，一個開發人員每天很簡單地瀏覽“我的工作”和“我的缺陷”這兩個檢索，就能知道今天該做什麼。同時開發與測試的交流也主要通過“缺陷”這一類型來完成。管理員在跟蹤進度、報告進度的時候也很簡明。在這種情況下，“情境”只是起到一個綜合與歸類的作用，使管理員和客戶知道哪些功能能夠使用了，哪些還差得遠。因此，“情境”可以等同於“任務”。因為這是我們預計到要做的事情。

如果加上“服務品質需求”，那麼團隊中每個人需要接觸的工作項目類型就有4種，如果測試人員發現“服務品質需求”的某些部分不符合要求，需要重新啟用“服務品質需求”，並建立一個新的“缺陷”，並且通報所有相關人員，對於一個小規模、人員相當集中的團隊，真的有這個必要嗎？

對於一個建立的團隊，保持一個精簡的過程和管理方法是很重要的。只要任務、缺陷這兩個類型足以解決問題，就不必考慮更多的工作項目類型，而是集中精力把項目開發好。

 

 

在軟體工程發展的過程中，各個專家在不同時期總結了軟體工程的原則，下面是1983 年Barry Boehm在總結了多重專案（各個項目總共耗時約175000人月，主要是國防、航空、航天相關）之後提出的軟體工程原則[i]，請把它和MSF、Agile的原則相比，看看有什麼異同?

表7-2  Barry Boehm總結的軟體工程原則

Principles	中文翻譯和解釋
1. Manage using a phased life-cycle   plan.	使用分階段的計劃來管理流程，強調需求分析和抵制隨意地改變專案計劃。
2. Perform continuous validation.	持續地檢查認證，爭取在早期發現問題。
3. Maintain disciplined product   control.	堅持規範的產品控制– 驗證過的程式或文檔只有通過規範的流程才能修改。
4. Use modern programming practices.	使用現代的編程方法和工具
5. Maintain clear accountability for   results.	確保團隊成員能分階段，分模組地產生可以測試，可以複審的結果，並對結果負責。
6. Use better and fewer people.	用少而精的人員，減少交流成本，提高效率。
7. Maintain a commitment to improve   the process.	持續地收集資料，和反饋，爭取通過多個迭代實現流程的改進和整體軟體品質的提高。

小飛： 能否有一個打折扣的MSF？讓一個團隊一下子接受MSF的“9項基本原則”似乎並非易事，那麼我們可以打折扣地貫徹MSF嗎？如果可以，應該如何實施呢？

阿超： 這些原則都是相互依賴、相互促進的。如果只實施了50%的原則，也許只有10%的作用。但是不必為此煩惱，只要開始改變，經常總結，就是好事。

小飛： 越是充分授權和信任，很多人在團隊中越不自覺，結果寫的代碼都是敷衍了事（大學裡面的團隊很多都是這樣），需要用什麼激勵機制來促進嗎，還是說只能依靠團隊成員的個人自覺？

阿超： 那我們要問一下這個項目的商業價值是什嗎？如果這個項目沒有任何商業價值，我想你也不好意思照搬商業軟體的做法。但是也許這個項目對個人而言很有價值（提高個人技術的價值），那些有心鍛煉自己的同學，能夠自我驅動，值得你去“授權”和“信任”。

小飛： 我體會最深的是——“如果你問一個技術人員，技術人員往往略帶不屑地告訴你——把“工具 | 選項”開啟，在某個“進階選項”下，改某個參數即可”這一段。移山公司的一些技術人員，特別是開發人員，甚至還帶有一些輕蔑的眼神。參照這一新聞（北京禁止售貨員用輕蔑審視的眼光掃視顧客）[ii]，我大膽地提一個建議——“移山公司禁止開發人員用輕蔑審視的眼光掃視測試人員”！

大牛： 我同意，而且要擴充到“禁止開發人員用輕蔑審視的眼光掃視非開發人員”！

果凍： 西方管理學大師戴明曾經說：“Eliminate numerical goals, numerical quotasand management by objectives. Substitute (that with) leadership”，意思就是說（在團隊中）要消除以數字定義的目標、份額，以及以類目標為基礎的管理原則。我們要用領導能力取而代之。
這和“數量化的管理”層級的要求有沒有衝突？

二柱：軟體工程講的淨是一些奇妙玄幻的概念，拗口的專業名詞加上紛繁複雜的流程，其實做軟體完全沒那麼難，主要靠的還是程式員自身的修養和完成工作的素質。

你怎麼看二柱的觀點？

[i]      論文資訊：Seven Basic Principles of Software Engineering, Barry W. Boehm, 連結：http://dx.doi.org/10.1016/0164-1212(83)90003-1

[ii]      http://news.sina.com.cn/c/2006-11-30/202110650498s.shtml