幾個軟體學院的學生來請教阿超，同學們自豪地說，我們要用全套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」，意思就是說（在團隊中）要消除以數字定義的目標、份額，以及以類目標為基礎的管理原則。我們要用領導能力取而代之。
這和「數量化的管理」級別的要求有沒有衝突？
二柱：軟體工程講的淨是一些奇妙玄幻的概念，拗口的專業名詞加上紛繁複雜的流程，其實做軟體完全沒那麼難，主要靠的還是程式設計師自身的修養和完成工作的素質。
你怎麼看二柱的觀點？
[ii]
現代軟體工程 第七章 MSF 練習與討論
幾個軟體學院的學生來請教阿超，同學們自豪地說，我們要用全套tfs敏捷開發模式開發專案！真的？阿超不敢相信。同學 對！我們要用全5個工作項型別 任務 缺陷 場景 風險 服務質量需求 阿超 你們有多少實戰專案的經驗？哦，都沒有。這麼說這是你們第乙個真正的實用專案，我建議你們先忘記這麼多工作項型別，把時間...
現代軟體工程 第七章 MSF 練習與討論
幾個軟體學院的學生來請教阿超，同學們自豪地說，我們要用全套tfs敏捷開發模式開發專案！真的？阿超不敢相信。同學 對！我們要用全5個工作項型別 任務 缺陷 場景 風險 服務質量需求 阿超 你們有多少實戰專案的經驗？哦，都沒有。這麼說這是你們第乙個真正的實用專案，我建議你們先忘記這麼多工作項型別，把時間...
《軟體工程》第七章 實現 作業
1 模組測試 指把每個模組作為乙個單獨的實體來測試。目的是發現模組內部可能存在的差錯，保證每個模組作為乙個單元能正確執行，所以又稱單元測試。對多個模組的測試可以併發進行。在這個測試步驟中所發現的往往是編碼和詳細設計的錯誤。2 整合測試 是測試和組裝軟體的系統化技術，包括子系統測試和系統測試。子系統測...