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