有的人對採用敏捷開發是否能真的有效提高效率並生產出成功的產品表示懷疑。他們認為，在敏捷方法中，由於沒有經理的管理和約束，團隊和專案必然是一團糟，彷彿越是上層越有這種想法。敏捷開發的理念是信任開發團隊，信任每乙個人。試想一下，如果你們這個團隊對你們的專案充滿激情，而老闆又充分信任你們，那麼你們必會將更多的時間花在如何有效地提高生產率、如何創新地完成某個功能等方面，而不是按老闆的意思按部就班地工作了，這樣還會節省很多時間並簡化流程，例如開會、向老闆報告、請示老闆、等老闆批准等。就像咱們剛才的那個遊戲結果所揭示的那樣，充分調動參與專案的人員的主動性，讓他們自我組織、自我管理，由團隊自身來掌握專案進度，比老闆整天催促反而更有效率。
當然，敏捷開發的團隊也需要管理，但這些管理是非命令式的，很多時候是戰略指導和服務性質的。在敏捷開發中，管理者對團隊和專案的管理表現在挑選合適的人、為團隊創造乙個開放而自由的工作環境、經常性的反饋、為團隊建立評估和獎勵機制、當團隊有方向性錯誤時能及早發現並糾正、容忍錯誤的發生等
還有一種誤解，認為敏捷開發就是完全不需要計畫、文件和架構設計。這種看法也是不對的。敏捷開發也需要文件，也同樣要計畫。但我們要明白，計畫趕不上變化，在這樣乙個不斷變化的情況下要做出詳細的計畫是不可能的。因此敏捷方法認為不值得在這些因素上花費過多的資源，可工作的軟體才是敏捷方法關注的重點。敏捷團隊依靠變化來獲取活力，他們更願意使設計保持盡可能的乾淨、簡單。基於以上的原因，採用敏捷方法的專案初始設計是比較粗略的，並需要使用許多測試手段作為輔助，這就保持了設計的靈活性和易於理解性。團隊可以利用這種靈活性持續地改進設計，以便於每次迭代結束時的系統都具有最適合於那次迭代中需求的設計。擺脫一切對軟體開發不合理的束縛就是敏捷。」
敏捷聯盟的發起人martin fowler 和jim highsmith 曾經這樣解釋過：敏捷開發所追求的是一種平衡——我們也建模，但不僅僅是畫幾個模型圖存放在少人問津的專案文件庫里；我們也需要文件，但從不浪費紙張去編造那些極少使用而又沒有儲存價值的大部頭；我們也做計畫，但我們同時也認識到在這紛繁複雜的環境中做計畫是困難的
但是，敏捷開發不是可以解決所有問題的銀彈。在實際的專案中，受條件的限制，有些原則實施起來確實有困難，那該怎麼辦？要知道，敏捷並不要求你們一成不變地遵循這些條條框框，遇到困難時應該靈活地調整策略，這樣才真正達到了敏捷的目的
對敏捷開發的誤解
對敏捷開發的誤解 誤解一 敏捷對人的要求很高 很多人在嘗試實施敏捷時說 敏捷對人的要求太高了，我們沒有這樣的條件，我們沒有這樣的人，因此我們沒法敏捷。可是，敏捷對人的要求真的那麼高麼？軟體歸根到底還是一種創造性活動，開發人員的技術水平和個人能力對軟體的質量還是起著決定性的作用，各種過程與方法只是幫助...
敏捷開發方法
王老師讓撰寫一篇部落格關於敏捷開發方法，讓我們深入理解敏捷開發方法。我看來，在爆發軟體危機以來，我們一直沒有找到乙個完美的方法解決。敏捷開發是在人們探索中由以前的開發方法中探索和總結出來的，雖然不完美，但是正在逐步適應。敏捷開發是針對傳統的瀑布開發模式的弊端而產生的一種新的開發模式，目標是提高開發效...
敏捷開發方法
敏捷方法一覽 各種敏捷方法的要求千差萬別，但是它們都遵循以下12條原則。1 最重要的是通過盡早地 頻繁地交付有價值的軟體來滿足客戶 盡早交付有價值的軟體。2 頻繁地交付可執行的軟體，數週或者數月交付一次 頻繁發布新版本。3 可執行的軟體是衡量進展的主要標準 軟體比文件更重要 4 接受需求變更，即便是...