移動網際網路行業是個快速發展的行業，需求不斷變化，產品更新快。基於移動網際網路的以上特點，在開發產品的過程中，我們放棄了傳統的瀑布流開發模型，引入了精益的理念和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回顧會議。

（1）sprint計劃會議

在開sprint計劃會議前，產品經理必須所要實現的產品需求（產品Backlog）以使用者故事的形式確定下來，並畫好原型圖，UI

應該要出設計稿（在sprint計劃會議前出設計稿很重要，因為設計對估算時間影響非常大）。產品經理同時確定各個產品需求的優先順序。

開sprint計劃會議期間（一般是2天），開發團隊的成員不應該做任何的開發工作，把全部精力都放在把產品需求變為一個個開發任務，並對開發任務估算時間。

估算時間有幾點注意：

1. 對於需要使用的新技術，要估算學習和調研的時間。

2. 根據統計，每個程式設計師每天的有效工作時間是5個小時左右，其他時間都被溝通，喝水，休息，上洗手間等佔據，所以如果某個任務估算超過5個小時，那就代表了這個任務完成需要超過一天的時間。

3. 對於開發任務，估算儘可能的細，一般來說，每個任務的估算不應該超過5

個小時，如果超過5個小時，就應該再把這個任務細分。只有儘可能細的估算任務，總的時間是大概精確地，因為估算時間是一個正態分佈，有的任務估算的時間偏大了，有的時間任務估算的時間偏小了，估算越細，總體下來估算還是準確了。

最後，根據產品經理的優先順序和開發人員的估算時間，確定最終的開發任務和優先順序，即完成Sprint backlog。

（2）日常開發

在每個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確定後原則上只能做小修改。

（3）每日的例會

在每天的例會前，每個團隊成員應該更新自己的任務列表，包括：

1. 昨天完成了哪些任務，每個任務使用了多少時間，沒完成的任務估算還需要多少時間

2. 更新總的剩餘開發時間

例會一般是產品經理和開發團隊的成員都要參加，如果可以的話，讓運營人員和市場人員也參加，這樣可以使每個成員都公司的產品有個整體的瞭解。

每個人在例會上說下面3方面的事情：

1. 昨天做了哪些工作。

2. 今天準備做哪些工作。

3. 有什麼工作需要其他同事配合。

注意，避免在會議上討論問題，如果真的需要討論，請在會議後和同事討論，不要浪費整個團隊的時間。

（4）測試和修bug

開發完成，就進入測試和修bug的階段。如果人手不足，可以使用交叉測試的方式，即android開發人員測試iphone的app，iphone開發人員測試android的app，後臺，運營，UI等人員看情況分配測試任務。

針對每個bug，應該有3部分：

1. 問題描述和重現步驟

2. 測試人員

3. 負責解決這個bug的人員（這個人員一般由技術總監指定）

（5）sprint評審會議

一般是全體人員都參加，在測試和修bug後。

iphone的演示有個收費的工具，可以把iphone的螢幕通過電腦放到投影儀，android上沒有哪個好用的工具！當時我們的方法是android演示的時候，用iphone的攝像頭對著android機，通過iphone的收費工具在投影儀上看。

（6）sprint回顧會議

每個成員都要參加，每個成員都要提兩點：

1. 在這輪sprint中值得表揚的點

2. 在這輪sprint中做得不好的地方

這個過程走兩輪，即每個成員都要說2次。

注意，當一個成員提出自己的意見時，其它成員不作任何的批評。

（7）及時反饋

在精益的理念中，很重要的兩點是快速反饋和快速迭代。快速迭代是通過scrum這個敏捷開發框架實現了，但快速反饋呢？產品投入到市場後，怎麼快速收集使用者的反饋呢？

我們採用的方法：

1.建立相關的qq群，收集意見。

2. 在app中，有個意見反饋的功能，能把反饋的意見傳送到伺服器。

3. 後臺中，有個系統的賬號。每個使用者一註冊就和這個系統賬號自動加為好友，可以隨時通過聊天功能向這個系統賬號提問題。一般我們的產品經理會經常登入這個系統賬號和使用者真正交流的。

如果您覺得這系列的文章對你有所幫助，歡迎打賞。
支付寶賬號：[email protected] 收款人：曾健生

[文章作者]曾健生

[作者郵箱][email protected]

[作者QQ]190678908

[新浪微博] @newjueqi

[部落格]http://blog.csdn.net/newjueqi

          http://blog.sina.com.cn/h6k65