敏捷開發：軟體與文檔

       也曾嘗試過，不帶文檔的“裸體”前進，可想而知，最後經常造成項目的返工，新來的人員要拚命讀以前的人留下的幾乎沒有注釋的源碼。

       後來嘗試過，制訂完善的規範，用了大量的軟體開發文件範本，可惜仍然無法減輕開發人員的負擔，另一方面令人尷尬的是，情況並沒有比不帶文檔好多少，因為在項目的實施中，很少有文檔與軟體能夠完全同步的。一份簡單的需求文檔從項目開始到項目結束，往往會改動得面目全非，在此同時，要花費專門的軟體開發人員去整理文檔，不得不說是一種資源浪費。

       與其做著虛假的文檔，穿著皇帝的新衣，不如就乾脆裸體，這是我的想法，但一直沒這個膽子去實施。

       不知是誰說過：軟體=程式+文檔，我持一半的贊同一半的不贊同，軟體最終就是要給使用者用的東西，使用者只要用了滿意，就是一個好軟體，不滿意就不是好軟體。對於使用者來說，他需要付出的是軟體的費用，另一部分軟體開發過程中的文檔等，是公司為了產品以後的升級、維護、擴充而準備，使用者沒有義務為此付費。

      一直以來，我們都採用Case工具，採用UML圖進行交流，有時候儘是這些工具很難滿足我們的需要，我們也會想盡一切辦法去表達自己的意思。使用了這些工具後，我的感覺是，大家都已經由原來的正常人變成了啞巴。有時候，明明一句話可以解決問題的，卻要比上半天的手勢。

　 新技術與新工具的採用，帶來的應該是人與人之間更通暢的資訊交流，如果效果正好相反，那麼我們不得不考慮一下，為什麼會這樣。

       直到接觸敏捷開發，才覺得開朗了一些，軟體開發儘管沒有銀彈，但在不同的形勢下，總有合適的方法來讓開發人員爬出焦油坑外。

       在<<敏捷建模、極限編程和統一過程的有效實踐>>這一本書上，開頭作者就指出了，他們在快速交流中，並不使用Case工具，他們使用的不過是幾張紙片，而且抓了支筆就開始畫草圖，甚至，在書中的後半部分，在設計使用者介面時，也居然是用草圖畫出來的。

      也許我看起來很可笑，但是說實話，我真的沒有這樣去做。向來我都認為，嚴格地管理，嚴格地遵循規範才能夠出高品質的產品，現在看來，好像是我誤解了些什麼東西。軟體設計的目標是成功開發出一個成品，讓使用者可以使用它。

      在做項目的過程中，我們往往過份關注了軟體的擴充性與易用性，以致於過度的分析需求，不但提供了一些使用者用不著的功能，也讓使用者投入了不需要花費的資金，同時，我們還浪費了大量的時間。

　　

　　在XP實踐中，有許多實踐是令人興奮的，不說其它的，雖然XP中不反對文檔，但根據它的思想，給了開發人員一個盡量少寫或不寫文檔的借口。 我一直沒有機會去實踐結對程式設計，但直覺上認為它是一個好東西，雖然並不相信，可以提高百分之幾十的效率，但軟體的開發畢竟是一個腦力活動，做個小功能，轉換一下思路，是一個好辦法。

　　但結對程式設計中，有一個讓我迷惑不已的地方：一般而言，人要進行做某事，要進入狀態，大約要15分鐘左右的啟動時間，然後，無論是任何打擾（包括電話，有人問話），都會造成思路的中斷，從而使得人要重新調整狀態，這又有幾分鐘的時間耗費。我不認為這樣會使得人更專註（有人在旁邊監視也一樣）。

　　因為沒有結對程式設計的經驗，所以也不過妄言幾句。