整個實施階段大概分成幾個階段：
團隊非常多，每個團隊特點都不一樣，比如規模不一樣，應用方法不一樣；
一些長週期的專案，比如qq客戶端，乙個版本的發布可能要半年到1年的時間，像這樣乙個產品怎樣去做敏捷開發，也許它就不適合敏捷開發。
一、整體的框架結構
1、產品
fdd的核心是面向產品的功能點，但這個功能點是從客戶角度出發的，並不是從系統角度出來的。功能點是用乙個短句描述出乙個業務需求，而這個業務需求的粒度是按開發時間來衡量的（一般不超過兩個星期）。特徵與用例的相似之處是，兩者都可以用短句（動賓短語）來描述；兩者的不同之處在於，用例用uml的用例圖來表示，而特徵是用四色原型（類圖）來表示。產品經理這個角色有點scrum的product owner的味道。但產品特性和backlog相差甚遠，因為產品特性只是乙個動賓短語，而backlog卻是乙個完整的故事（story）。
2、專案管理過程
3、開發實踐
乙個完整的迭代過程 包括概念、設計、開發、測試和發布五個過程。
在概念階段，會採用fdd裡面提到的一些好的最佳實踐來支撐到我們怎麼樣去敏捷的做需求開發，會制定一些產品發布的計畫，比如產品在未來，某個迭代什麼時候發布，要發布哪些產品特性，都是在這個階段做的。
在設計階段，會做產品原型上的設計。對於網際網路產品說更多的是通過快速原型法快速的讓產品在不同範圍內去做一些體驗，比方產品在某個迭代的乙個小迭代裡面，可能會在乙個團隊裡面先去體驗，可能就會採取發布到公司某乙個部門去體驗，或者發布到整個公司範圍去體驗，它會是乙個不斷放大的乙個過程。
在開發和測試階段，更多的採取xp的一些實踐，包括編碼規範，**走讀，比如1周一次**走讀，構建持續整合的環境，包括自動化構建，自動化測試等，會有一些好的測試上的實踐，如全員測試，就是將測試看成不僅僅是測試人員的工作，更多的是整個團隊的工作，當然也包括這個產品的其他同事的工作，通過全員測試來激發大家對產品質量負責。
其中分析、設計、開發、測試、發布這五個過程可以內部再迭代，而且這五個過程不是分階段開展的，即不是分析完了之後才設計，全部設計完了才開發，開發結束了才測試，測試通過了才發布。而是邊分析邊設計——在業務不複雜的情況下，這是可行的——邊設計邊開發，開發完乙個功能就測試乙個功能，同時開發下乙個功能。
1、故事牆
就是白板story wall，平時工作中很多團隊都會使用，這些團隊會把每天開發的一些產品特性採用story的方式每天都在白板裡面展示出來，整個團隊每天都會圍繞這個白板能夠清晰的看到整個產品或者整個專案的乙個過程，包括整個產品特性的過程。寫在白板上比用excel或者其它工具管理好，因為寫在白板上讓人感覺更緊迫、更正式、更一目了然，有一種別人在監督、在注視的感覺。
2、每日晨會
每個團隊每天大概花15-30分鐘，回顧昨天做了什麼、昨天有些什麼問題、同時也會介紹每個人今天計畫做些什麼工作。對team而言這是檢查進度、快速調整非常有效的形式。
最早是通過白板的方式去做，就是每天專案經理組織團隊成員對著白板，白板上體現專案的進展情況，通過會議可以很明確的知道昨天大家做到什麼樣子，今天大家計畫做什麼，最早的時候每個成員都是口頭匯報的。實踐一段時間就發現了一些問題：
對於乙個20、30人的團隊，每天要怎樣做晨會，這是目前遇到的比較大的困惑；
晨會很容易形式化，究竟帶來什麼樣的效率和效果，目前也在通過一些方式去研究，去**。
有一些形式上的呆板，剛開始做會覺得比較有意思，覺得這跟傳統做法不一樣，每天這樣做並且做多了就感覺很枯燥，這也是面臨乙個挑戰。
3、規劃遊戲
4、時間盒
5、產品演示
提交測試前由開發人員演示實現的功能，產品經理到場review是否符合當初的設想，避免接近發布時才反饋。
6、迭代總結
在每乙個產品發布的時候都會有乙個總結。具體的做法是，把做得好的、不好的總結出來，做得好的在下一次迭代發揚光大，做得不好的在下一次迭代就要注意改進。這樣的總結是要求專案的所有成員都必須參加，包括專案的開發人員、測試人員、qa、專案經理、產品經理等，每個人都要去去總結他在上乙個迭代中碰到了什麼問題，通過便簽紙的方式貼出來，專案經理實際上可以看成是scrum master
，包括站起來總結這樣一些東西，包括我們下一次迭代繼續發揚什麼，必須要注意什麼東西，最後就會得出乙個excel的文件，包括上乙個迭代中出的問題，具體的解決辦法，都會有
7、自運轉團隊
早期的專案，為了能提高效率，專案經理希望每個角色都能全力以赴的提公升自己的效率，於是自己承擔起來大量溝通和推進的工作，那個時候的都在被pm推著走，一旦pm休假，專案基本沒有什麼產出，當時去了以後，發現問題很嚴重，團隊的主動性必須被調動起來才行。
自運轉團隊，是將需求開發過程詳細劃分成開發的各環節，並明確每個環節的負責人，由該負責人來驅動上下游的負責人，而不再由專案經理來連線各個環節，再配合上高效的專案協助工具平台，實現開發過程自運轉。這時專案經理則由指揮者變成服務者，觀察環節之間產生的瓶頸，並及時採取措施掃除障礙。
1、使用者研究
2、故事卡片/故事牆/特徵列表
3、結對程式設計
4、測試驅動
5、持續整合
自動編譯輸出報告，維護**可執行，及時暴露風險，降低整合成本。
dailybuild日構建系統，讓產品經理、測試人員可以盡早進行體驗和測試。
作為乙個自動化系統，利用靜態**檢查、單元測試報告等手段為團隊提供報告，促進編碼質量不斷得到重視，降低缺陷解決成本、縮短解決時間。
6、灰度發布
簡單說就是，將一項業務不是一下發布給所有使用者，而是分批分期的發布，目的有兩個方面，一是減輕伺服器壓力，二是期間可以在小範圍收集到使用者的反饋，如果業務出現問題，不會讓大範圍使用者受到影響。隨著經驗的累計，我們有了許多種灰度策略和方法，灰度也有了更多的應用，甚至引入到了測試環境，即選擇一些熱心使用者，將功能首先發布給他們，通過他們的使用，來幫助進行一些現網測試，這使得一些難於模擬的測試場景變得簡單，測試人員的壓力大大降低；更重要的使用者是最好的測試人員，測試結果更加真實；同時他們也享受到了優先體驗的特權，可謂一舉三得。發布的時候也有策略，比如發布時如何放量，對使用者有些什麼樣的實驗，技術上怎樣做一些後台開關，運營上怎樣跟進，怎樣保證4小時人員的留守，發布完後怎樣收集使用者反饋等等都會有一些統一的規則。
7、發布汽車
過於頻繁的發布會打破團隊節奏，有效的發布管理是必不可少的，根據業務特點，我們通常會採用三種發布模式，我們管它叫「發布汽車」。
8、重構
好的**不是設計出來的，而是重構出來的。
四、總結
從某個渠道了解到，tapd的原型是：果然是強大的山寨帝國啊~~~
敏捷開發 快速迭代
今天跟大家分享的是 敏捷開發 快速迭代 我們大都採用的是 瀑布開發模式 有了問題，就得返工，雖然最終的產品會比較齊全完善，但是開發周期太長，開發人員會產生排斥，甚至厭惡的心理。經過yh系統的開發，也且生體會到了這一弊端。有問題就要去解決它！於是我想到了 敏捷開發 借鑑敏捷開發模式，來改善軟體開發過程...
敏捷質疑 迭代開發
迭代在於我們明確的承認資訊和知識的不完備性,不可完備性.而專案的成功,需要某種程度的完備性.這種認知的侷限與成功的條件之間的矛盾,促成了人們解決這類問題的通用方法 漸進的試錯法 試錯法參考一 試錯法參考二 是解決問題 獲得知識常用的方法，即根據已有經驗，採取系統或隨機的方式，去嘗試各種可能的答案。當...
敏捷質疑 迭代開發
迭代在於我們明確的承認資訊和知識的不完備性,不可完備性.而專案的成功,需要某種程度的完備性.這種認知的侷限與成功的條件之間的矛盾,促成了人們解決這類問題的通用方法 漸進的試錯法 試錯法參考一 試錯法參考二 是解決問題 獲得知識常用的方法，即根據已有經驗，採取系統或隨機的方式，去嘗試各種可能的答案。當...