對敏捷開發的誤解
誤解一：敏捷對人的要求很高
很多人在嘗試實施敏捷時說：敏捷對人的要求太高了，我們沒有這樣的條件，我們沒有這樣的人，因此我們沒法敏捷。可是，敏捷對人的要求真的那麼高麼？軟體歸根到底還是一種創造性活動，開發人員的技術水平和個人能力對軟體的質量還是起著決定性的作用，各種過程與方法只是幫助開發人員、測試人員等角色能夠更好的合作，從而產生更高的生產力。不管用什麼方法，開發人員的水平永遠都是乙個主要的因素。
從另乙個角度來看：過程和方法究竟能幫開發人員多大忙？對於技術水平較低的開發人員，敏捷方法和傳統方法對他的幫助是差不多的，因此看不到顯著的效果，甚至有些時候還有反效果；而隨著開發人員技術水平的提高，敏捷方法能夠解開對人的束縛，鼓勵創新，效果也會越來越顯著。
敏捷對人的要求並不高，而且會幫助你培養各種所需的能力，當然前提是你處在真正敏捷的環境中。
誤解二：敏捷沒有文件，也不做設計
這個誤解從xp開始就沒有停止過，xp鼓勵「在非到必要且意義重大時不寫文件」。這裡面提到的「必要且意義重大」是乙個判斷標準，並不是所有的文件都不寫。例如，使用者手冊是不是「必要且意義重大」？這取決於客戶的要求，如果客戶不需要，那就不用寫,如果客戶需要，就一定要寫；再如，架構設計文件要不要寫？複雜要寫，不複雜不用寫。通常架構設計只需要比較簡單的文件，對於有些專案，一幅簡單的uml圖就夠了。因此，寫不寫，怎麼寫，都要根據這個文件到底有多大意義，產出和投入的比例，以及專案的具體情況決定。實際操作時可以讓專案組所有人員表決決定，盡量避免由某乙個人（比如lead）來決定。
至於設計，xp奉行的是持續設計，並不是不設計。這實際上是將設計工作分攤到了每天的日常工作中，不斷的設計、改善（重構），使得設計一直保持靈活可靠。至於編碼前的預先設計，kentbeck等人確實實行著不做任何預先設計的開發方式，但是對於我們這些「非大師」級開發人員，必要的預先設計還是需要的，只是不要太多，不要太細，要有將來會徹底顛覆的準備。
誤解三：敏捷好，其他方法不好
有些人一提到敏捷就大呼好，只要是敏捷的實踐就什麼都好，而提到cmmi等方法就大呼不好，不管是什麼只要沾上邊就**都不好，似乎敏捷和其他方法是完全對立的。牛頓說過，我是站在了巨人的肩膀上。敏捷同樣也吸取了其他方**的優點，也是站在了巨人的肩膀上，敏捷依然保持了很多歷史悠久的實踐和原則，只是表現方式不同罷了。
從另乙個方面來看，方法本沒有好環，好與壞取決於是否適合解決你的問題。每一種方法都有他最善於解決的問題和最佳的發揮環境，在需求穩定、軟體複雜度相對不高的時代，瀑布模型也可以工作的很好，而敏捷恰好適用於變化快風險高的專案－這恰恰是現在很多專案的共性。
因此選擇乙個方法或過程，並不是根據它是否敏捷，而應根據它是否適合。而要了解乙個東西是否適合，還是要嘗試之後才知道，任何沒有經過實踐檢驗的東西都不可信。
誤解四：敏捷就是xp（極限程式設計），就是scrum
xp和scrum只是眾多敏捷方法中的兩種，還有很多其他的敏捷方法。龍生九子各個不同，敏捷的這些方法看起來差別也是很大的，可是他們之所以被稱為敏捷方法，就是因為他們背後的理念和原則都是相同的，這個原則就是《敏捷宣言》。學習敏捷不僅僅要學習實踐，還要理解實踐後的原則，不僅要理解怎麼做，還要理解為什麼這麼做，以及什麼時候不要這麼做。
即使將xp或scrum完全的應用的你的專案中，也未見得就能成功，適合別人的東西未必就適合你。敏捷的這些實踐和方法給了我們乙個起點，但絕對不是終點，最適合你的方式還要由你自己在實際工作中探索和尋找。
誤解五：敏捷很好，因此我要制定標準，所有專案都要遵循著個標準
沒有哪兩個專案是一樣的，客戶是不一樣的，人員是不一樣的，需求是不一樣的，甚至沒有什麼可能是一樣的。不一樣的環境和問題，用同樣的方法解決，是不可能解決的好的。方法是為人服務的，應該為專案團隊找到最適合他們的方法，而不是先確定方法，再讓團隊適應這個方法。因此也不存在適合所有專案的統一的方法。任何企圖統一所有專案過程的方法都是不正確的。
同時，對於同乙個團隊，隨著專案的進行，對需求理解的深入，對技術理解的深入，一開始適合專案的過程和方法也會漸漸的不適合。這時候也需要團隊對過程進行及時的調整，保證專案的質量和效率。敏捷是動態的，而非靜止不變的，因為這個世界本身就是變化的，在變化的世界使用不變的方法，是不現實的。銀彈從來就沒有過，在有限的將來也不會存在。
敏捷開發方法的誤解
有的人對採用敏捷開發是否能真的有效提高效率並生產出成功的產品表示懷疑。他們認為，在敏捷方法中，由於沒有經理的管理和約束，團隊和專案必然是一團糟，彷彿越是上層越有這種想法。敏捷開發的理念是信任開發團隊，信任每乙個人。試想一下，如果你們這個團隊對你們的專案充滿激情，而老闆又充分信任你們，那麼你們必會將更...
敏捷開發中對進度的把握
如何做effort的estimate?本文給出了敏捷開發模式中的乙個方法。專案經理被問到最多的問題就是，這個專案什麼時候才能完成？被問的時候，可能專案才定下來，僅僅知道大概的功能模組，非功能性需求還模糊不清，甚至團隊成員都沒到位。但是上級 銷售 客戶急切地要知道，這個專案什麼時候才能完成？被問的時候...
對SDN的誤解
誤解一 sdn一定要使用openflow協議來配置 面 openflow只是發展最早 目前影響力最大的南向介面，但是並不是唯一的。誤解二 sdn要求硬體 面的標準化 這只是openflow的要求，並不是sdn的要求。誤解三 sdn裝置可以代替所有裝置 誤解四 sdn得到了所有廠商的支援 誤解五 sd...