移動網際網路行業是個快速發展的行業，需求不斷變化，產品更新快。基於移動網際網路的以上特點，在開發產品的過程中，我們放棄了傳統的瀑布流開發模型，引入了精益的理念和scrum這個敏捷開發框架，下面談談實施過程中的一些經驗。
方法/步驟
scrum簡介：Scrum是一個敏捷開發框架，是一個增量的、迭代的開發過程。在這個框架中，整個開發週期包括若干個小的跌代週期，每個小的的跌代週期稱為一個Sprint，每個Sprint的建議長度2到4周。
在Scrum中，使用產品Backlog來管理產品或專案的需求，產品backlog是一個按照商業價值排序的需求列表，列表條目的體現形式通常為使用者故事。Scrum的開發團隊總是先開發的是對客戶具有較高價值的需求。
在每個Sprint中，Scrum開發團隊從產品Backlog中挑選最有價值的需求進行開發。 Sprint中挑選的需求經過Sprint計劃會議上的分析、討論和估算得到一個Sprint的任務列表，我們稱它為Sprint backlog 。在每個迭代結束時，Scrum團隊將交付潛在可交付的產品增量。
我們的Sprint backlog是大概4周的時間，其中包括2天的sprint 計劃會議,2.5周的開發，每日例會穿插在開發時間裡，1周的測試改bug，1天的sprint評審會議和sprint回顧會議。
sprint 計劃會議:
在開sprint 計劃會議前，產品經理必須所要實現的產品需求（產品Backlog）以使用者故事的形式確定下來，並畫好原型圖，UI應該要出設計稿（在sprint 計劃會議前出設計稿很重要，因為設計對估算時間影響非常大）。產品經理同時確定各個產品需求的優先順序。
開sprint 計劃會議期間（一般是2天），開發團隊的成員不應該做任何的開發工作，把全部精力都放在把產品需求變為一個個開發任務，並對開發任務估算時間。
估算時間有幾點注意：
1. 對於需要使用的新技術，要估算學習和調研的時間。
2. 根據統計，每個程式設計師每天的有效工作時間是5個小時左右，其他時間都被溝通，喝水，休息，上洗手間等佔據，所以如果某個任務估算超過5個小時，那就代表了這個任務完成需要超過一天的時間。
3. 對於開發任務，估算儘可能的細，一般來說，每個任務的估算不應該超過5個小時，如果超過5個小時，就應該再把這個任務細分。只有儘可能細的估算任務，總的時間是大概精確地，因為估算時間是一個正態分佈，有的任務估算的時間偏大了，有的時間任務估算的時間偏小了，估算越細，總體下來估算還是準確了。
最後，根據產品經理的優先順序和開發人員的估算時間，確定最終的開發任務和優先順序，即完成Sprint backlog。
日常開發:
在每個Sprint backlog，後臺和app的互動都是通過api，所以由後臺先寫好相關的api並編寫假資料，先讓app端可以順利開展工作。
先編寫api和假資料，有兩個好處：
1. 能對整個開發計劃有個總體的規範。
2. 相當於是TDD（測試驅動開發）。
遇到問題的時候，必須要及時找相關的人員溝通。但這樣有個問題，如果開發人員正在開發，被打擾可能會被決定很不爽，為了保證溝通的效果，可以：
1. 如果真的不是非常緊急，可以等相關的人員休息的時候再溝通。
2. 解決一個問題，先梳理情緒，再梳理人際關係，最後才是問題本身。多微笑，別苦著臉，平時待人以善，說好話，存好事，做好事，溝通的時候只針對問題，不針對別人的不良情緒。
3. 可以試一下番茄工作法。但根據我們自身的實踐經驗，效果不理想。
在創業開發團隊中，scrum master 一般是由技術總監擔任的。團隊外部的溝通，必須統一通過scrum master。即如果市場部，運營部對開發團隊有任何要求，必須要經scrum master同意後由scrum master傳遞進開發團隊內部。團隊內部的溝通，由團隊成員自己解決，如果有重大的決策，必須經scrum master同意。通過scrum master遮蔽外部對開發團隊的影響。
在團隊建設中，定期的團體活動是個很好的主意，我們一般是週四下午集體去打羽毛球。
通過團體活動，不但能加強團隊的凝聚力，而且運動後，整個人沉悶的感覺都消失了，變得神清氣爽，活力十足。
在一個Sprint backlog中，需求不能變更，UI確定後原則上只能做小修改。
每日的例會:
在每天的例會前，每個團隊成員應該更新自己的任務列表，包括：
1. 昨天完成了哪些任務，每個任務使用了多少時間，沒完成的任務估算還需要多少時間
2. 更新總的剩餘開發時間
例會一般是產品經理和開發團隊的成員都要參加，如果可以的話，讓運營人員和市場人員也參加，這樣可以使每個成員都公司的產品有個整體的瞭解。
每個人在例會上說下面3方面的事情：
1. 昨天做了哪些工作。
2. 今天準備做哪些工作。
3. 有什麼工作需要其他同事配合。
注意，避免在會議上討論問題，如果真的需要討論，請在會議後和同事討論，不要浪費整個團隊的時間。
測試和修bug:
開發完成，就進入測試和修bug的階段。如果人手不足，可以使用交叉測試的方式，即android開發人員測試iphone的app，iphone開發人員測試android的app，後臺，運營，UI等人員看情況分配測試任務。
針對每個bug，應該有3部分：
1. 問題描述和重現步驟
2. 測試人員
3. 負責解決這個bug的人員（這個人員一般由技術總監指定）
sprint 評審會議:
一般是全體人員都參加，在測試和修bug後。
iphone的演示有個收費的工具，可以把iphone的螢幕通過電腦放到投影儀，android上沒有哪個好用的工具！當時我們的方法是android演示的時候，用iphone的攝像頭對著android機，通過iphone的收費工具在投影儀上看。
sprint回顧會議:
每個成員都要參加，每個成員都要提兩點：
1. 在這輪sprint中值得表揚的點
2. 在這輪sprint中做得不好的地方
這個過程走兩輪，即每個成員都要說2次。
注意，當一個成員提出自己的意見時，其它成員不作任何的批評。
及時反饋:
在精益的理念中，很重要的兩點是快速反饋和快速迭代。快速迭代是通過scrum這個敏捷開發框架實現了，但快速反饋呢？產品投入到市場後，怎麼快速收集使用者的反饋呢？
我們採用的方法：
1.建立相關的qq群，收集意見。
2. 在app中，有個意見反饋的功能，能把反饋的意見傳送到伺服器。
3. 後臺中，有個系統的賬號。每個使用者一註冊就和這個系統賬號自動加為好友，可以隨時通過聊天功能向這個系統賬號提問題。一般我們的產品經理會經常登入這個系統賬號和使用者真正交流的。