最小可行化產品
硅谷創(chuàng)業(yè)家 Eric Rise 在其著作 《精益創(chuàng)業(yè)》 一書中提出了 “精益創(chuàng)業(yè)”（Lean Startup）的理念，其核心思想是，開發(fā)產品時先做出一個簡單的原型——最小化可行產品，然后通過測試并收集用戶的反饋，快速迭代，不斷修正產品，最終適應市場的需求。
假如時光倒流，來到了2007 年，你要從零打造一個類似如今新浪微博的產品，有一系列需求擺在面前：
- 用戶注冊、登錄
- 發(fā)布 140 字的文字微博
- 發(fā)布帶圖片的微博
- 發(fā)布帶視頻的微博
- 發(fā)布投票
現(xiàn)在面臨兩個選擇：1. 花費 6 個月的時間，將以上的需求全部完成后上線，給用戶一個強大功能的社交網(wǎng)站體驗。2. 花費 2 個月時間，完成用戶注冊登錄和發(fā)布文字的功能，讓用戶最快體驗到這個功能相對較弱的全新社交產品，在接下來的時間里，根據(jù)用戶反饋，完善已有功能，同時開發(fā)上傳圖片的功能，一旦開發(fā)測試完成，就立即上線。以小步快跑的節(jié)奏不斷完成需求表格中的其他需求。
精益創(chuàng)業(yè)的思想就是采用第二種方案進行漸進式開發(fā)，這樣的開發(fā)模式有諸多好處：
- 最小可行化產品能在最短的時間內完成開發(fā)，以最快的速度驗證用戶需求
- 時間早意味著具有先發(fā)優(yōu)勢，方便更早地積累用戶，這一點在社交產品上尤為明顯，后發(fā)的同類產品往往需要背負“模仿”的帽子
- 能第一時間聽到用戶的聲音，最大程度避免了產品方向上的錯誤
敏捷開發(fā)模式（Scrum）實際上是精益創(chuàng)業(yè)思想的實踐指南。
敏捷開發(fā)模式
敏捷開發(fā)采用循序漸進的方法進行軟件開發(fā)，把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，分別去完成，在此過程中軟件一直處于可使用狀態(tài)，具體流程如下：
1. 梳理產品需求（Product Backlog）
在開發(fā)之前，一定會有一個需求列表，定義了產品在接下來需要具備的特性和功能，一般由產品經(jīng)理來定義，在敏捷流程中，稱這個人為 Product Owner（PO）。定義 Product Backlog 時，需要遵循 INVEST 原則，即：
- Independent 獨立的，盡量和其他需求沒有依賴
- Negotiable 可討價還價的
- Valuable 有價值的
- Estimable 可預估的
- Small 足夠小，拆分到一個迭代內能完成
- Testable 可被測試的
定義需求的同時，Product Owner 還需要定義需求的優(yōu)先級，定義優(yōu)先級可以借助一個公式：功能帶來的的價值除以實現(xiàn)難度， 這個值越大則代表優(yōu)先級越高。
2. 制定迭代計劃
一般規(guī)定兩周（ 10 個工作日）為一個迭代，在迭代開始之前，需要召開迭代計劃會制定這一個迭代的計劃，把 Product Backlog 按照優(yōu)先級排序，由 PO 為大家講解具體每一個需求，團隊成員根據(jù)需求的復雜程度評估每個任務的工作量，當前 n 個任務的工作量之和約等于團隊總工時時，那么這個迭代就把 Product Backlog 中前 n 個任務作為這次迭代的任務，在敏捷中稱之為 Sprint Backlog。
團隊總工時的計算方法：如果團隊有 5 個工程師，一個迭代的工時為 5 * 10=50 人日，考慮到工作效率和其他的意外情況，再乘以 80% ，那么最終實際用于開發(fā)的工時為 40 人日，有些團隊會以小時作為單位，同理，只需將單位換成小時。
團隊需要把 Sprint Backlog 和預估的時間寫在便簽紙上，把它們貼在白板上，白板劃分成三大塊：未開始、進行中、已完成，當然，所有 Sprint Backlog 的狀態(tài)開始都應放在未開始那一列。
3. 迭代執(zhí)行
在迭代進行期間，由大家認領白板上的 Backlog，每天早上要開一個每日站會，時間在 10 分鐘以內，由大家依次報告：
- 我昨天做了什么
- 今天計劃要做什么
- 遇到了哪些問題
每日站會強迫每個人向同伴報告進度，迫使大家把問題擺在明面上，盡可能讓信息公開透明。報告進度的同時移動對應的卡片到合適的位置，修改 Backlog 剩余所需要的工作量，Scrum Master 需要統(tǒng)計剩余所有的工時，更新到燃盡圖中。當燃盡圖的走到 0 ，就意味著完成了這個迭代中所有的任務。
4. 迭代總結
迭代的最后一天，還有兩個環(huán)節(jié)要做：成果展示和團隊的內部總結。
成果展示環(huán)節(jié)要求團隊成員在這個迭代中自己完成的任務展示給所有人看，除了團隊內部所有成員以外，還可以邀請領導等關心項目進展的人。內部總結則只在團隊內部進行，總結這個迭代中做的好的地方以及不好的地方，接下來如何改進等。
以上是實施敏捷開發(fā)模式的大致流程，當然，在實際執(zhí)行過程中會遇到或多或少的問題，一般需要幾個迭代的熟悉和磨合。
