摘要:《軟體工程與 VSTS》心得：增值與減工思維模式（Value-up and Work-down Paradigm）
《軟體工程與 Microsoft Visual Studio Team System》的第一章是「增值思維模式」，這次就先和大家分享個人對此主題的了解與心得。
以往在開發專案時，大都是先與客戶（或主要的利害關係人）討論出專案的目標與粗略的範圍（scope），然後透過與使用者訪談的程序，訂出比較細的 專案範圍與功能需求，最後得到一份完整的功能清單（至少當時雙方認為應該夠完整了）。這份功能清單將影響往後的開發計畫決策，包括人力、時間等資源的安 排，團隊也是以完成這份清單中所有的功能為目標。當開發團隊把功能清單裏的項目全部完成，就視為這個專案已經完成了。
但問題是，需求往往在一開始並不是那麼明顯。許多時候，使用者都是在看到實際執行的軟體畫面時，心中才開始浮現它所想要的軟體應該長什麼樣子。可是 當初卻做了一堆計畫，團隊成員、時間也都安排好了，怎麼辦？比較好的情況是，雙方各讓一步，若需求有大幅的變動（例如增加新的子系統）就延長交貨期限，要 不然就增加預算或人力。可是結果到最後往往雙方都不滿意，因為需求範圍的一再改變與擴大，將使開發團隊失去耐心，最後只好以合約書的內容拒絕變更需求；客 戶也一樣不滿，因為他花了錢卻沒有得到他真正想要的東西。
寫到這裡，突然想到有一種軟體生命週期是這樣的（摘自《我懂了！專案管理》）：
計劃開始 -> 火熱投入 -> 理想破滅 -> 一片混亂 -> 找代罪羔羊 -> 處罰無辜的人 -> 無功之人晉升 -> 限定各項要求
我想許多人應該也有類似的經驗吧（也許沒那麼誇張），也都曾發出感嘆：為什麼軟體這麼難做？！
前面舉的例子，多少都與需求蒐集的品質有關，但如果我們不試著從問題的本質出發，思考原本的觀念與作法有何不當之處，那麼不管需求文件寫得多詳細、採用什麼開發工具、什麼軟體平台，恐怕最後都會面臨相同的困境。
為了描述以上的問題，並指出解決問題的方向，《軟體工程與 Microsoft Visual Studio Team System》的作者在書中自創了兩個新名詞：value-up 與 work-down，它們分別代表了不同的軟體開發思維模式 (paradigm)。
Work-down 代表過去的軟體開發思維模式，也就是類似前面舉的例子，先列出要完成的功能清單，然後每當完成了一件工作，就把該工作項目從清單中移除或槓掉。等到工作清 單裡面的工作都完成了，就代表專案完成了。我在中文版裡面把 work-down paradigm 譯為「減工思維模式」。
相對於「減工思維模式」，是所謂的 value-up paradigm，我在書中譯為「增值思維模式」，它強調的是持續為專案增加新的客戶價值。什麼是顧客價值？講白一點就是客戶想要的、或對他有用的東西。 這些客戶價值當然也是根據事前規劃的工作清單所引導，但專案是否完成並不是以清單裏的工作是否做完來決定，而是看專案是否實現了所有的顧客價值 (customer value)。換句話說，這種思維比較站在使用者的立場，認為開發出來的軟體就應該符合使用者的需求。這也正是極致編程（eXtreme Programming，XP）的精神之一－－擁抱改變。
可是這麼一來，如果使用者的需求一直變來變去，恐怕沒有一個團隊撐得下去。因此，有了正確的觀念之後，還要配合適當的方法才行。這當中最重要的關 鍵，個人以為是反覆與漸進的開發方式－－既然軟體的需求一定會改變，那就不要一次定江山；把軟體需求分成幾個小的階段逐次完成，每完成一小步，還可以視情 況調整開發方向，對使用者與開發團隊雙方都有好處。這也符合 XP 的精神－－邊開車邊調整方向。
可是，有些類型的專案卻不適合這樣做，例如大型的政府標案，這類型的專案通常在一開始就要決定預算和專案範圍，而且以後也不可能更改預算（從其他預 算挪用除外）。因此，除非一開始預算就非常充足，否則當使用者提出比較重大的需求變更時，開發團隊通常得根據合約拒絕使用者增加或變更需求。若預算充足， 個人比較一廂情願的想法是，開發團隊不用太在意合約裡面的軟體規格，只要 end-user 滿意，實際上還是可以採用增值思維的模式來開發專案，以確保最終的產品符合使用者的需要，我想這才是最重要的吧。
像政府標案這類的軟體專案，通常需要比較正規的、重量級的開發流程，例如 CMMI。相對的，另一種不那麼正式、允許較多彈性的專案，則適用於輕量級的、可機動調整的開發方法，例如 XP。有了正確的觀念與適當的開發方法，如果少了方便的工具，效果也會大打折扣，甚至無法持續下去。因此，Visual Studio Team System 在設計時就考慮到要支援 XP 與 CMMI 這兩種不同「量級」的專案類型，所以預設就提供了 XP 和 CMMI 的開發流程範本，讓團隊能夠以增值方法來開發這兩種類型的專案（當然也支援其他開發流程，你甚至可以自訂流程範本）。至於實務上的要怎麼做，這是本書的其 他章節要談的，這次就先聊到這裡吧！
