軟件文檔--揚棄還是傳承 (原文最終修訂於 2006-04-12,上午12:41:14)

在本人的《敏捷軟件開發:原則、模式與實踐》一書中曾提到“Martin對編寫文檔的第一原則是:除非是必須馬上撰寫文檔而且意義重大,否則的話就乾脆不要寫它”。有些人把這個意思曲解爲敏捷開發一種不需要文檔的開發過程,這並不屬實。

文檔是所有軟件開發過程中必不可缺的環節,打着“敏捷”的幌子拒絕編寫文檔是一種不健全的偏激行徑,而且這與那些不假思索就容忍產品中包含十幾種不同文檔,且自稱是“開發過程的終極迴歸”的說法沒什麼差別。撰寫文檔與其它軟件活動一樣,也需要經過一番投資回報的權衡。我們只會在確實需要文檔的時候才編寫它,同時編寫文檔帶來的收益也應該是值得其所花費的努力的。

敏捷方法需要兩種類型的文檔,它們分別是需求文檔和設計文檔,而其它所有類型的文檔都是選擇性的。但選擇性可不是說就不需要了。

  1. 需求文檔。在敏捷方法中,需求文檔往往會在某次迭代之中進行。它經常先於其他開發過程,但也要到開發過程的迭代開始的時候纔在內容上達到完整。此外,它也會被自動化驗收測試所用。其它種類的需求文檔,像是敘述型、工作流型和圖像型文檔,可能也會酌情使用。
  2. 設計文檔。在敏捷方法中,設計文檔往往是由測試優先方法指導編寫的單元測試所構成的。這些單元測試都是如何使用各部分代碼的鮮活的例子。其它種類的設計文檔,像是類圖、交互圖、狀態圖、ER圖等也可能會酌情使用。

文檔是開發團隊在必要的時候才創建的,當他們覺得需要的時候就編寫了它,就這麼簡單。而且文檔在開發團隊自身的開發過程中並不需要,往往是客戶或市場來決定它們是否需要。開發團隊會使用素材卡片(譯註)來預估、計劃並確定具體完成時間。如果某項素材在迭代過程中並未被加入,那此項素材也一定對客戶或市場來說是毫無價值的。而如果加入到了開發計劃中,那一定是因爲客戶或是市場認爲它們足夠重要所致。

 譯註:

用戶素材,原文user stories。索引卡片,原文index card。爲了進行項目計劃,必須要知道和項目需求有關的內容,但是卻無需知道得太多。需求的特定細節很可能會隨時間而改變,因此,在離真正實現需求還很早時就去捕獲該需求的特定細節,很可能會導致做無用功以及對需求不成熟的關注。在XP中,我們更願意客戶在索引卡片上寫下一些我們認可的詞語,這些片言隻語可以提醒我們一起這次交談。用戶素材就是正在進行的關於需求談話的助記符。它是一個計劃工具,客戶可以使用它並根據它的優先級和估算代價來安排實現該需求的時間。

 

 (原文鏈接網址:http://www.butunclebob.com/ArticleS.UncleBob.OnDocumentation; Robert C. Martin的英文blog網址: http://www.butunclebob.com/ArticleS.UncleBob 

作者簡介:Robert C. MartinObject Mentor公司總裁,面向對象設計、模式、UML、敏捷方法學和極限編程領域內的資深顧問。他不僅是Jolt獲獎圖書《敏捷軟件開發:原則、模式與實踐》(中文版)(《敏捷軟件開發》(英文影印版))的作者,還是暢銷書Designing Object-Oriented C++ Applications Using the Booch Method的作者。MartinPattern Languages of Program Design 3More C++ Gems的主編,並與James Newkirk合著了XP in Practice。他是國際程序員大會上著名的發言人,並在C++ Report雜誌擔任過4年的編輯。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章