偽敏捷開發-用敏捷的框架來做事：有角色的劃分，任務的分解，有各種會議，也有sprint - 但迭代過程是隨意、鬆散的、沒有任何約束的，所以失敗。正確的方法如下：
1-明確了短期目標，一個迭代在兩週左右，可以明確告訴客戶，在一個迭代週期內，只能完成200個裡面的40個，先做最有價值的前20個。
2-便於進度控制和風險預測。
3-檢視與調整，逐步完善的過程 ， 迭代結束之後，產生可交付的成果，給客戶演示，及早獲得反饋，小步前進，不停思考，反省和總結。不停地進行自我檢視，調整和完善，一步步走向卓越。
靈活運用敏捷開發
項目負責人還要懂得“做人”。和客戶方負責人、聯繫人保持良好的關係是非常非常重要的
敏捷開發中，注重概念和架構設計，而輕詳細設計
概念設計： 可以看出為何要做這個模塊，強調的是產品路線規劃，市場趨勢，客戶價值 和技術趨勢等
架構設計，可以看成從整體上看，概念設計應該用什麼方式實現、分幾個層次、多少組件、不同層次和組件之間關係是什麼。
詳細設計，則是具體的設計和做法、API接口等。
SWOT 分析，在敏捷開發中，更加註重客戶需求。對產品進行SWOT分析，就能選出最小工作量，但能獲得最大價值的模塊。
業務和客戶驅動而非技術驅動：敏捷開發強調在整個開發週期內，業務人員和開發人員中必須天天都在一起工作，確保技術人員能夠開發出客戶需要的產品。
時刻考慮版本的兼容性， 當設計變動、API接口重構、配置文件變更時，要時刻考慮產品的架構、規劃路線圖，老版本的兼容性，及遷移平滑性。否則，隨著版本的增多，必將面對著大量的維護工作。
輕文檔而非文檔， 強調溝通的重要性， 但並不意味著無文檔，在敏捷開發過程中，適量的文檔還是很有幫助，有助於整體思路，加快溝通和討論；
產品敏捷開發中，每個迭代結束，都會有一個產品迭代演示大會，把這個月的開發結果演示給組員、業務人員、售前，甚至客戶，並收集反饋。此外，在開發的過程中，產品的業務人員和售前時刻保持與產品開發團隊的溝通和工作，保證開發出來的產品是符合業務需求。
充分利用資源和時間，敏捷開發後，迭代開發、強調溝通、縮減文檔，在每個迭代初期就可以充分地利用開發、測試人員的時間，達到效率最大化。
每日交付
產品開發過程中，每天都會做自動化Build，並生成可以交付的產品。業務人員、客戶都可以試用並提供反饋和新需求。
充分自動化
需要自動化去支持變化，在變化的同時保證質量和開發速度，包括編譯自動化、單元測試自動化、功能測試自動化、UI測試自動化、集成測試自動化等。
架構師和Scrum Master的重要性
1) 產品架構師
一個好的產品，特別是面向行業的產品，要具有長期的生命力，需要具有下圖所示的產品模型：
成熟的模塊：指的是推出市場有一段時間，這些功能模塊因滿足客戶的需求而被廣泛使用。隨著市場趨於穩定，大量競爭對手的產品也推出類似的功能。這些成熟模塊都是產品的基本模塊，不代表產品的競爭力。產品中如果只具有這些功能模塊，隨著需求和競爭的激烈，慢慢會走向滅亡。如90年代的BP機一樣，當手機一旦推出，這個產品也就走向滅亡。
發展中的模塊：指的是剛推出市場並且具有強勁的市場生命力、符合客戶當前幾年的業務發展需求，正在被大客戶所接受的功能模塊。這些功能模塊是產品佔領市場的動力，是繼成熟的功能模塊後，產品的新的增長動力。
研究中的下一代產品方向：指的是還沒有推出市場、正在研究中的、符合未來行業五到十年發展方向的模塊。當然如果能創造出未來的發展方向，則是最高境界。如任天堂的Wii、蘋果公司的iPhone。
一個行業軟件產品要保持長期的生命力，在整個產品的生命週期架構規劃中，需要考慮到這三種模塊和特性，只有這樣才能保持產品的先進性和長久生命力。
敏捷開發也強調擁抱市場變化，這對產品架構師提出了很高的要求——深厚的業務背景、創新能力、技術洞察力和架構思想。
2) Scrum Master
其工作內容和開發組長沒什麼太大的區別：安排任務、協調資源、控制進度和解決難題。Scrum Master會協調解決每天碰到的問題，確保產品進度和質量。
每天早上需要主持小組成員進行一個10分鐘左右Scrum會議。每個組員彙報昨天完成的任務，是否完成任務以及碰到的問題，最後是今天打算完成的任務。Scrum Master會協調解決每天碰到的問題，確保產品進度和質量。具體到業務中，Scrum Master各自負責架構中的不同模塊，並和開發人員一起把模塊分解成一個個單獨的、可以衡量的用例，然後協調開發人員高質量的完成任務。
閱讀更多 大衛Wu 的文章
