OSCHINA答讀者問之六：雜談（完結篇）

我曾經去給OSCHINA做過一期有關“軟體工程實踐”的有獎高手問答 （獎是給提問者的，哈哈），現在來看，許多問題仍然可讀之處，因此整理成文字，以為眾賞。

原貼在這裡：http://www.oschina.net/question/12_78459

本篇的問題：（沒有主題，呵呵）

問：我們公司準備進行“敏捷測試”。有沒什麼建議~！

答：基本上，所有帶著“敏捷”字頭的，我都很難有建議。那是個黑洞，什麼概念都往裡扔，卻沒人擔負解釋的責任。:)

問：軟體工程的風險控制，有沒有什麼可以一般都遵循的規律或者說指導原則？

答：我只知道一條，向一個進行中的項目添加人手和添加特性，都是萬惡之始。

問：對於沒有確定需求的開發工作,您有什麼好的建議？

答：事實上很難“確定需求”，軟體工程為解決需求變化問題已經努力很多年了。現今的一些情況是，以類似於快速迭代、每日構建等方式來應對需求的變化；用原型等方式在較少代價下將需求盡量確定下來；強化測試以在需求變化下保障品質等等。但背後的事實是：我們承認和接受了“變化的需求”。一些極端的情況，就是把客戶拉到Team中，讓變化直接反饋在階段產品中，或者讓客戶自己都疲於變化。總之，這些已既成事實。

問：軟體工程，請問一些中小型項目有必要用嗎？

答：無關大小。你要用“工程化的方式去做那個軟體”，就必然要討論軟體工程的問題。但顯然，你要得到“那個軟體”，可以買的，可以外包啊，為什麼一定要“工程化開發”呢？所以與大小無關，取決於你打算“如何得到它”。

問：大公司架構主要負責什麼工作？

答：很多架構師在大公司混飯吃，所以切莫以“公司大小”來看架構師的優劣。將“做架構”以及“做更優秀的架構”作為一個修鍊的過程，而不是將自己變成更加的開發高手，就好了。至於變化說到底就是一個“需求要不要滿足”的問題，個人意見是“接受需求，控制變化”。但這與敏捷與否是無關的，後者是表象。

問：軟體工程學到什麼程度才算合格?

答：知道那本叫《軟體工程》的書一點兒也不重要，就合格了。

問：您感覺像軟體工程這樣的課程應該怎麼來上呢？

答：按“標準流程”做一兩個項目即好。但條件是：要考核每個人的工作量，評估成效；並針對上述結果做出激勵機制；並針對激勵機制的價值寫出論文。至於項目最終成不成，做不做得出軟體，無視之。

問題：有沒有（類似標準流程的）完整的簡單一實例給大家來一份啊？

答：請寫一個記事本軟體。條件是：用十個人開發，其中三個人決定記事本軟體的產品特徵項、版本規劃。

問：您怎麼看待權利與規範？

答：真正的特權，是制定規範。無視規範是特權者的特權，無規範是打破特權的神器。但，無規範則無社會架構：沒有如水的組織，亦無如水的社會。無規範如是夢中。而做夢，是個體的最終自由和最終動力。