我新到這家公司，就開始了一場死亡之旅，我們的項目開發周期是3個月，人員大概有3～6個不一定。而以我的經驗，我們大概要做的，是一個3～5個人年的非常復雜的創新型項目。新加盟的技術總監，是一個崇尚文檔交流的“老干部”，因此，我們花了一個月的時間，在寫各種各樣的設計文檔。真正能夠用于開發的時間，是2個月。
?
我們這個小組的另外一位組員，也是一位經驗豐富的項目經理，他崇尚的，是文檔UML化描述。因此，我現在除了寫文檔，還要用Rational Rose畫好多好多的圖～～～
?
在他們兩位來這個項目組之前，我其實已經寫出了一份基本完整的User Case列表，而且和另外一位組員已經進入測試驅動的、結對編程階段了。。。
?
?
大家可能已經看出來了，這其中的開發模式，簡直就是混亂不堪。到底是文檔驅動？UML驅動？用例驅動？還是測試驅動呢？
?
問題還不止這些，我們的大老板比較喜歡和我們一起討論設計，甚至會和我們爭論具體的某個算法。開發文檔沒有統一的管理，匯報機制沒有明確的定義，項目需求隨時都可能變動，就連到底我們這個小組會有幾個人，都還是一個未知數，這樣的死亡之組，不知各位有什么好的建議？
?背景資料介紹完畢，抱怨結束，下面討論正題：
文檔驅動、測試驅動、用例驅動、模型驅動、特征驅動。。。。他們都要解決的是什么問題？
要回答這個問題，還真不容易。我們得問一個更加重要的問題，真正驅動項目的，究竟是什么呢？我想，應該是需求吧？
?
那么，這些“文檔”、“測試”、“用例”、“模型”、“特征”，究竟是什么呢？對于需求的描述！我們之所以不會直接用需求來驅動項目開發，而是要借助工具，來幫助我們描述需求，就是因為口語化的需求描述是非常模糊的，充滿歧義的。所以，選擇什么來驅動我們的項目，其實就是要看，以上這些工具，哪一個能夠更好、更準確的描述需求？
?
文檔其實是最難準確描述需求的一種方式，如果是純文字的文檔，就更難。我們的技術總監，非常喜歡讀寫文檔，我最近也創下了一天寫47頁文檔的最新記錄。但是，當我們開會的時候，我還是經常需要提醒我們的技術總監，麻煩他再仔細看看文檔第XX頁的第XX段，以及配合著另一份文檔的XX小節，來確切的理解我的意思！如果沒有我的解釋，他就會誤解我的文檔。
?
當然，如果要寫出不需要我來解釋，他就能理解的文檔，那么文檔的工作量，將會極其驚人！我以前寫過一篇blog，《Jacobson博士演講觀后感》是我對UP的創始人的極度反感的集中體現。GHawk，以及交大林老師的所謂“UP”的觀點，當然不可能獲得我的贊同。在GHawk的最新一篇blog：《UP & XP之爭，意義何在？(續)》中，GHawk說：“唯一的問題是：“如何確保測試用例的質量”。顯然，我們不能把一把不直的尺子度量出來的結果作為可靠的參考依據。怎么解決呢？“結對編程”么？嗯，這是一個不錯的方式，那么最終該信賴誰呢？是Pair中的A還是B呢？或者，是Leader么？那么又是誰提出的要求呢？是老板么？還是客戶？政府？法規？市場？……問題沒有終結了?！?/p>
?
由此我可以推斷，他對于XP的認識，基本上是停留在猜測的階段。對于這篇blog的觀點，我就不逐一反駁了，我的猜測是，他經歷過一次失敗的XP嘗試，而究其原因，我猜測是因為他們那個所謂的XP Team中，沒有一個人，曾經實踐過一次正規的XP開發。
?
再來看模型驅動，這中間有一個大問題，因為需求是“問題域”的范疇，而模型，則是“解答域”的范疇，試圖通過解答域的精確描述，來實現對于需求的準確描述，肯定不靠譜啊。
?
特征驅動，我認為FDD其實是老方法的新名詞，具體的實踐，可能更加接近測試、迭代式的過程。了解不過，所以我也不打算多說。
?
用例驅動與測試驅動，其實我認為這是一個硬幣的兩面，用例要盡快的翻譯為測試用例，而測試用例，正是為了更加準確的表述需求用例。這是我能夠想到的，驅動項目開發的，最好的方法！
posted on 2006-04-26 00:32
讀書、思考、生活 閱讀(29567)
評論(31) 編輯 收藏