�。�3. 迭代就是敏捷，UP屬于敏捷。
�。牽吹竭@么多人都把UP歸入敏捷，我都開始懷疑是不是自己搞錯了。但是在我的印象中：
�。燯P是重型的過程，雖然引入了迭代，但是其原則和價值觀與敏捷是不同的。敏捷注重的是反饋，迭代周期盡量的短，重在客戶的參與，通過客戶的參與，獲取持續的反饋，不斷調整使整個項目走在正確的方向上。同時也給客戶一個感受和思考的機會，因為對于大多數客戶而言，目標是明確的(不排除有些客戶目標也不明確)，但是具體怎么做，開始時是沒有想法的，只有看到具體的東西的時候，才知道“噢，原來可以這樣，那我想把這里調整一下”。
�。�4. 敏捷是徹底革命的。
�。犆艚�，特別是XP，讓人有耳目一新的感覺，覺得以前的所有軟件工程理論，設計方法都可以拋棄掉了，推翻一切，從頭再來。抱著這種想法實施敏捷，那就錯了，敏捷不是“石頭里蹦出個孫大圣”，以前的軟件過程中也有敏捷的影子，只是沒有像敏捷一樣上升到價值觀和原則的高度，比如快速原型法。敏捷是在對已有的軟件過程方法的改進，拋棄的是傳統軟件工程低效的外表，以往的軟件過程中很多技巧都是很實用的。實施敏捷應該以現有的軟件過程為基礎，從敏捷宣言和原則出發，利用敏捷的方法來改善過程。
�。�5. 敏捷是反文檔的。
�。犖臋n只是為了達成目標的一種手段，如果這種手段是低效的，那就換一種手段�？墒峭耆珤仐壛宋臋n，怎樣解決溝通的問題?難道你想每次溝通都完全用手比劃，用嘴說，跟不同的人重復表述同樣的想法，那樣更是低效的。
�。爲撉宄臋n的本質是把知識顯性化。在一個項目中存在很多需要溝通的知識，知識具備兩種形態，顯性的和隱性的，傳統的觀念是盡量把隱性知識顯性化，即文檔化，而忽略了這其中的代價(特別是更新同步文檔的代價)。
�。犚虼�，在實施敏捷的時候，需要在團隊內明確哪些知識是必須顯性的，這些知識可以通過文檔交流。哪些知識是可以隱性的，這些知識則完全可以通過口頭的方式進行交流，以達到溝通的最佳效率。
�。犖臋n不是目的，有效溝通才是目的。
�。�6. 為了敏捷而敏捷
�。牎班�，敏捷這么好，我們也敏捷吧”，可能很多人會有這種想法。忘了以前是在哪兒看的大師采訪錄：
�。燪：“我們現有的過程很好，不知道怎么用敏捷改進?”
�。燗：“既然很好，那就不要用敏捷”。
�。犠鍪裁词虑槎家忻鞔_目標的，敏捷雖好，得看你需不需要，能不能解決你現在頭疼的問題，如果不是，那就不要給自己找麻煩了。
�。�7. 敏捷是CMM的反義詞
�。犜诠鹆謺h的討論中，很多人把CMM作為敏捷的反義詞，我覺得這不是很合適。CMM只是一種衡量軟件成熟度的標準，并非過程，和敏捷不是一類概念。如果要給敏捷找一個反義詞，我覺得傳統的瀑布式開發應該更合適一些。
�。牪⑶�，我認為，如果CMM還能繼續流行下去的話，應該會有公司可以用敏捷改善的過程通過CMM認證。
�。�8. 敏捷是自由的，無約束的。
�。犆艚輳娬{的是自組織團隊，發揮人的能動性，以動力代替壓力，讓人有絕對自由的錯覺。但是應該清楚，凡是都是要講究一個平衡，人也是兩面的，消極的一面和積極的一面同時并存，絕對的自由會放縱人消極的一面。敏捷并非是絕對自由，無約束的。作為管理者，有一個職責，就是引導團隊成員用自己積極的一面去壓制消極的一面，不能放任團隊中出現搭便車的現象，否則將打擊整個團隊的士氣。如果實在無效，那就只能將其排除出團隊了，這個懲罰夠有約束力吧?
�。�9. 重做就是重構
�。犞刈霾坏扔谥貥�，很多場合這兩個概念是混淆的。但是在敏捷中，重構的一個特征是必須可控的。當對系統結構進行大的調整時，如果沒有測試驅動輔助的話，那么可控性就會很差，這不能叫做重構。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
