l

2015年10月20日 星期二

敏捷開發都不寫文件?

Oct. 19 09:50~11:12

螢幕截圖 2015-10-19 11.11.21

 

敏捷開發都不寫文件」這個錯誤的刻版印象,Teddy以為在N年前就已經結案無需再提了,沒想到時至今日還是有不少人抱持這樣的看法。今天就來舊事重提,談談敏捷開發與文件的話題。

▼雖然敏捷宣言第二條提到「可用的軟體重於詳盡的文件(working software over comprehensive documentation)」,但這並不表示採用敏捷開發就不需要撰寫文件。

螢幕截圖 2015-10-19 10.09.24

 

首先思考一個問題:「軟體開發為什麼需要寫文件?」Teddy認為有最主要的目的有兩個:

  • 記錄知識:將人腦袋裡面的知識以書面形式記錄下來,以便於後續重複使用。例如,用use case記錄使用者需求。
  • 輔助溝通:將知識書面化之後,多個人可以同時閱讀這些文件,作為溝通的輔助工具。例如,開會前先閱讀會議通知文件。

所以文件是一種紀錄知識以及溝通知識的媒介

***

現在思考第二個問題:「記錄知識的方法,難到只有「文件」一途嗎?」Teddy在〈BDD(1):詳盡的文件就是可用的軟體〉介紹過,世界上有五種儲存知識的媒介:

  • DNA
  • Brain
  • Hardware
  • Book
  • Software

文件(book)只是其中一種。對軟體開發而言,產品的知識最終儲存於軟體(software)本身。如果鄉民們對於軟體開發的看法是把傳統所謂的「分析設計知識」先用文件儲存,之後再找人將這些知識「轉譯」成軟體,勢必就會遇到「知識同步」的問題—當文件與軟體不一致的時候,你要相信誰?

敏捷開發的想法很簡單:「既然可用的軟體重於詳盡的文件,而文件本身也有其價值。何不把詳盡的文件也變成可用的軟體?」如此一來,「詳盡的文件(通常以各種形式的測試案例存在)」與「最終產品(production code)」這兩種知識都是用「軟體」這個媒介來記錄。因為軟體是可以執行的,可自動驗正傳統分析設計的知識與軟體是否同步。而開發人員可以藉由閱讀測試案例與production code來理解系統。為了讓非技術人員也可以理解系統的商業邏輯,進一步可將記錄於軟體(測案案例或production code)中的知識轉成傳統一般人可以理解與閱讀的文件形式。

***

最後一個問題:「難道所有的知識都可以用軟體來記錄?」以現在的技術而言答案很顯然是否定的。例如,使用手冊、抽象的軟體架構圖,就無法或非常不容易直接由軟體產生。那怎麼辦?很簡單,就…寫文件啊。

Teddy認為敏捷開發對於文件的看法很簡單:「你覺得文件有價值,就寫。覺得沒有價值,就不用寫。」儲存知識的媒介有五種,對軟體開發而言,DNA、brain、hardware、book、software都是可利用的途徑,不必單戀一支花

***

友藏內心獨白:我超會寫文件的。

沒有留言:

張貼留言