也曾嘗試過，不帶文檔的“裸體”前進，可想而知，最后經常造成項目的返工，新來的人員要拼命讀以前的人留下的幾乎沒有注釋的源碼。
后來嘗試過，制訂完善的規范，用了大量的軟件開發文檔模板，可惜仍然無法減輕開發者的負擔，另一方面令人尷尬的是，情況并沒有比不帶文檔好多少，因為在項目的實施中，很少有文檔與軟件能夠完全同步的。一份簡單的需求文檔從項目開始到項目結束，往往會改動得面目全非，在此同時，要花費專門的軟件開發人員去整理文檔，不得不說是一種資源浪費。
與其做著虛假的文檔，穿著皇帝的新衣，不如就干脆裸體，這是我的想法，但一直沒這個膽子去實施。
不知是誰說過：軟件=程序+文檔，我持一半的贊同一半的不贊同，軟件最終就是要給用戶用的東西，用戶只要用了滿意，就是一個好軟件，不滿意就不是好軟件。對于用戶來說，他需要付出的是軟件的費用，另一部分軟件開發過程中的文檔等，是公司為了產品以后的升級、維護、擴展而準備，用戶沒有義務為此付費。
一直以來，我們都采用Case工具，采用UML圖進行交流，有時候盡是這些工具很難滿足我們的需要，我們也會想盡一切辦法去表達自己的意思。使用了這些工具后，我的感覺是，大家都已經由原來的正常人變成了啞巴。有時候，明明一句話可以解決問題的，卻要比上半天的手勢。
新技術與新工具的采用，帶來的應該是人與人之間更通暢的信息交流，如果效果正好相反，那么我們不得不考慮一下，為什么會這樣。
直到接觸敏捷開發，才覺得開朗了一些，軟件開發盡管沒有銀彈，但在不同的形勢下，總有合適的方法來讓開發人員爬出焦油坑外。
在<<敏捷建模、極限編程和統一過程的有效實踐>>這一本書上，開頭作者就指出了，他們在快速交流中，并不使用Case工具，他們使用的不過是幾張紙片，而且抓了支筆就開始畫草圖，甚至，在書中的后半部分，在設計用戶界面時，也居然是用草圖畫出來的。
也許我看起來很可笑，但是說實話，我真的沒有這樣去做。向來我都認為，嚴格地管理，嚴格地遵循規范才能夠出高質量的產品，現在看來，好像是我誤解了些什么東西。軟件設計的目標是成功開發出一個成品，讓用戶可以使用它。
在做項目的過程中，我們往往過份關注了軟件的擴展性與易用性，以致于過度的分析需求，不但提供了一些用戶用不著的功能，也讓用戶投入了不需要花費的資金，同時，我們還浪費了大量的時間。
在XP實踐中，有許多實踐是令人興奮的，不說其它的，雖然XP中不反對文檔，但根據它的思想，給了開發人員一個盡量少寫或不寫文檔的借口。 我一直沒有機會去實踐結對編程，但直覺上認為它是一個好東西，雖然并不相信，可以提高百分之幾十的效率，但軟件的開發畢竟是一個腦力活動，做個小功能，轉換一下思路，是一個好辦法。
但結對編程中，有一個讓我迷惑不已的地方：一般而言，人要進行做某事，要進入狀態，大約要15分鐘左右的啟動時間，然后，無論是任何打擾（包括電話，有人問話），都會造成思路的中斷，從而使得人要重新調整狀態，這又有幾分鐘的時間耗費。我不認為這樣會使得人更專注（有人在旁邊監視也一樣）。
因為沒有結對編程的經驗，所以也不過妄言幾句。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
