《軟體工程與 VSTS》心得:增值與減工思維模式(Value-up and Work-down Paradigm)

摘要:《軟體工程與 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 的開發流程範本,讓團隊能夠以增值方法來開發這兩種類型的專案(當然也支援其他開發流程,你甚至可以自訂流程範本)。至於實務上的要怎麼做,這是本書的其 他章節要談的,這次就先聊到這裡吧!