瀑布 敏捷 文檔

剛接觸敏捷開發時候非常不適應，單單就沒有文檔這一項就感受很彆扭。什麼都須要去問旁邊的同事。開發團隊的人也說這是敏捷開發沒有文檔。我也就信覺得然了。如今從新審視一下文檔這個東西不覺發現其實敏捷開發的出現是有其道理的。

軟件開發雖然說是開發，可是從整個軟件的生命週期來看大部分的時間都是在維護，之前一直把軟件開發看成修建建築，如今想一想這麼比喻是有缺陷的。建築通常蓋好以後輕易不改變，要改變就是推倒重來。可是軟件不是這樣的，一旦產品上線這個產品會經歷用戶的檢驗而後產品升級經過一遍又一遍的迭代，逐漸的這個軟件變得愈來愈好，就像windows系統似的。與其說軟件開發是一個製做過程還不如說軟件開發是一個從普通逐步逼近完美的修補過程。

再來看文檔，早在軟件工程的學習中就知道文檔是爲了方便開發人員溝通，提升開發的效率而存在的。可是實際狀況真的是這樣麼？由於軟件開發不是一次性的工做，是須要不斷迭代不斷完善的，因此到最後頗有可能文檔比代碼還難以維護。試想一下把a=1修改成a=2原本一秒鐘都用不到的事情，若是加入文檔維護那麼就是一個須要至少半天的工做量。

因而敏捷開發出現了，提倡沒有文檔或者提倡代碼就是文檔；提倡沒有註釋或者說代碼就是註釋。註釋和文檔一個道理從a=1到a=2代碼改動已經很明顯了。若是加上註釋那麼讀註釋的人就要知道這段代碼爲何該在何時改的等等信息，可是這些信息也許不是讀代碼的人須要的。無用的信息佔用了寶貴的時間形成了資源浪費。

敏捷開發沒有註釋沒有文檔那麼靠什麼管理？答案是靠工具，各類工具，各類人性化的工具。

版本控制工具:按照上面的例子把a=1改成a=2，若是用以前的SVN很難保證代碼的可讀性，原本改動一個數字可能在這段代碼周圍就會有雜七雜八的註釋，上次的，上上次的，上上上次的……。若是使用git之類的版本控制軟件，狀況就會好不少。衆所周知Git每次提交都須要寫詳細的提交註釋，這就至關於咱們以前修改代碼要寫的註釋，與以前註釋不同的是這裏的註釋是對此次修改動做的一個整個描述，並且這個註釋只有你在調用的時候他纔會顯示，不會無緣無故的佔用讀代碼人的時間。

Bug管理工具:不管什麼事，歸根結底人才是主體，軟件開發更是這樣。敏捷開發須要一個融洽的團隊，須要一個和諧的氛圍，不然開發就是踢皮球，利用Jira之類的「缺陷跟蹤管理系統」每一個人每一個迭代幹了多少工做量一目瞭然，想偷懶都很差意思。因爲每一個迭代經過以後都會有獎勵，若是由於我的而影響到整個團隊那我的臉上也掛不住，因此人的積極性也調動了起來。每一個人天天早上來了以後會去這次迭代中尋找本身熟悉的bug，就至關於你們一致面對一個巨大的敵人而後各自利用本身擅長的部分去對付這個敵人。正應了那句話「好的團隊會讓每一個人力量發揮到極致」。最後的結果就是你們搶着修Bug，恐怕給整個團隊拖後腿。

以上兩個工具僅僅是冰山一角，工具是無限的可是思想是不變的，以人爲本不教條主義正是傳統開發過程當中最缺乏的東西。縱觀敏捷開發的過程，不是沒有文檔而是把文檔交給了自動化工具完成，把人從文檔中解放出來，將更多的精力投入到系統開發當中。自動化工具或者說開發管理工具的使用大大的節省了團隊的時間，提升了效率。這些工具以及這些工具產生的數據嚴格的說不能算是文檔，可是他們比文檔更加高效，更加具備時效性。

敏捷開發也有其自身的「缺點」，好比新手上手比較慢，若是文檔齊全（注意這是一個虛擬語氣）的話新人能夠更快的融入團隊，可是從國內大部分開發團隊的狀況來看，通常遵循瀑布模型的軟件開發所產生的開發文檔要麼和代碼不對應，要麼就是沒有文檔。因此照這樣來看在沒有文檔的狀況下，經過Jira等Bug管理系統學習已有的代碼反而是促進新人更深刻研究代碼的一個主要動力。也許這個過程當中雖然費了一些時間，可是獲得的倒是異常豐富的代碼經驗。通過前期新人對代碼的熟悉，公司對新人的水平就會有一個大體的瞭解，這同時也是保證了新員工水平的一種方式。一個連別人代碼都看不懂的人還搞什麼開發！機器能看懂你就應該能看懂，不是別人寫代碼的水平差，是本身的水平不夠而已。（最後一句是吐槽，請酌情忽略）