? ? ? ? 移動產品團隊的運作強調高質量、零風險、高速度交付；結合這些年來參與的團隊運作經驗，特別是之前帶領團隊進行敏捷運作試點的經驗，寫了這篇概述性文章。
1 快速迭代
? ? ? ? 版本快速迭代運作流程參考了SCRUM敏捷運作模型，但是更重落地、而不重形式。目前我們App采用Hybrid混合架構，以一個月一個原生版本為正常迭代節奏，月中最多可夾雜一個h5熱更新版本。
2 需求分析前置下的版本周期規劃
? ? ? ? 版本規劃周期為四周，實際執行周期為六周，需求分析前置兩周，在上一版本Uat階段即開始需求分析工作，與開發測試并行運作。
? ? ? ? 在前置兩周內，需求分析、預研開發、系統測試三者并行運作，具體而言是將需求分析的時間節點較版本開始時間點前置兩個星期：第一個星期做業務需求分析與原型開發（產品）、核心需求技術可行性預研（主程），最終交付版本需求原型與交付范圍確認、技術方案預研報告；第二個星期根據原型做需求評審、UI設計稿開發（UI設計師）、核心需求底層實現開發（主程）、后臺服務設計與開發（后臺開發人員）。
? ? ? ? 版本正式啟動后立即開始功能開發（開發）、測試用例開發（測試），即便UI設計稿還未開發完成，也先按原型稿來開發，到ST測試后期再分批次做視覺還原。
關鍵評審節點：
? ? ? ? Pre第一周：需求開發（包括原型開發）、核心需求技術可行性預研，星期五依托原型稿進行需求評審與需求交付范圍確認；
? ? ? ? Pre第二周： UI設計稿開發、核心需求基礎開發、后臺接口服務設計，星期五進行UI設計稿評審，技術方案評審與宣講（包括后臺接口服務設計，如果有的話）；
? ? ? ? Cur第一周：主要進行功能開發、用例開發，星期一產品做需求宣講，最好能結合UI設計稿（如果沒有就用原型稿）；星期五進行測試用例評審；
? ? ? ? Cur第二周，主要是完成功能、Bug修復、ST測試，星期五產品經理開始介入ST測試、UI設計師開始準備做第一期視覺還原；
? ? ? ? Cur第三周，主要是完成ST測試、開始UAT測試，星期三進行UAT驗收評審、后臺服務做發布準備；
? ? ? ? Cur第四周，主要完成UAT測試，版本上線發布，星期三進行版本上線評審，包括版本需求驗收、上線發布材料評審、后臺服務發布驗收；星期五完成app上線發布審批，待后續上線后進行試運行驗收；
3需求承諾與交付承諾
? ? ? ? 在敏捷迭代項目中，承諾是一個非常重要的詞匯，通常主要包括需求范圍承諾與交付質量承諾，上文提到，納入版本交付范圍的需求，必須是零風險、高質量的需求，需求范圍一旦確定，在當前版本執行周期內，原則上決不允許再有需求變更事件發生，如果有，也只能做需求替換，而不是需求追加。
? ? ? ? 敏捷項目之所以能快節奏持續迭代，一大重要原因就是認可團隊開發能力有限這一基本原則，成員相對固定的團隊，在產品架構、技術能力等因素沒有顯著提升的情況下，開發團隊的產出是有限而且可評估的。也基于此論斷，在一個迭代周期內，需求交付量也必然是有限的，如果中途增加需求，其結果必然是增加版本交付風險、延長版本交付周期。
? ? ? ?而在基于“需求分析前置”的敏捷迭代運作方式下，各個版本就像坦克履帶一樣是環環相扣的，一環延期必然導致環環延期，最終結果就是版本迭代節奏被徹底打亂、版本穩定性遭到致命性破壞。這種結果在之前我呆過以及現在的團隊中均是有血淋淋的事實的。
? ? ? ? 版本持續穩定高質量迭代除了需求穩定之外，最重要的還是要有高質量的交付。一旦承諾交付的需求，開發就應當高質量高效率地完成并保證最終成功上線。當然開發質量的提升是一個非常復雜的命題，既與開發人員能力直接相關，也與產品系統架構休戚相關；既跟需求交付質量間接相關，也跟測試質量正向相關。但是，并不能因為事情難做，就放棄努力?？傮w而言，系統架構足夠優秀，就能極大提升功能開發效率、減少初級開發人員犯錯幾率；普通開發人員能力提升既能帶來開發效率的提升也能帶來代碼質量的提升，最終還是能提升后續功能開發效率與功能穩定性；需求交付質量的提高，既能減少需求溝通成本與時間，也能盡早發掘異常分支場景，避免重大功能場景遺漏；測試用例質量的提升，能直接保證功能場景的覆蓋程度；自動化測試的落地，是大幅提升原有功能回歸驗證的效率與正確度。
3 每日站會
? ? ? ? 每日站會發生在每天上午開工之前，主要是為了跟進團隊成員每日開發測試工作進展、協調各成員資源與問題，時間控制在5~10分鐘，每人3~5句話，重點簡述昨日進度、今日計劃、出現的問題，具體問題處理留到會后單獨溝通，每日站會會貫穿整個版本開發周期，即從版本開發啟動開始直至版本上線結束。
關鍵時間節點：
Cur第一周：產品、UI、開發、測試參與站會，重點協調UI資源、核心需求的開發資源分配；
Cur第二、三周：產品、開發、測試參與，重點協調技術疑難、測試bug處理；
Cur第四周：產品、UI、開發、測試，重點協調視覺還原資源、上線工作安排；
4 UAT驗收
? ? ? ? UAT驗收標準：Bug數量總體收斂，1級bug為0，bug總數不超過10個，已做過一輪視覺還原；
UAT期間重點處理頁面效果優化，盡量少產生功能類bug；
5 生產問題處理規范
? ? ? ? 生產問題特指分流到產品手中的生產環境用戶問題，總體分兩類處理：
? ? ? ? 1、緊急問題，緊急處理，開發臨時開分支版本修復并上線，盡量通過發布h5包來熱修復；
? ? ? ? 2、一般問題，統一轉需求，納入后續版本處理（非當前開發中版本）；
6 技術架構演進
? ? ? ? 技術架構演進總體要比當前業務版本提前至少一個版本，技術任務的形成依托于中長期產品功能規劃，也即是年度核心需求實現的技術儲備任務、未來兩至三個版本內核心需求實現的高耗時技術預研類任務。技術預研任務的目的是為了確保核心需求在版本實施過程中能做到零風險交付，將技術攻關工作提前完成，確保核心需求實現時的零風險高效交付。
? ? ? ? 前期預研、方案設計評審、框架代碼開發均獨立于當前迭代版本，開分支進行獨立開發，在方案開發完成后，作為需求支持項納入該需求對應版本實施。
? ? ? ? 上文需求前置一節中也有提到主程預研工作，特此說明一下，主程預研任務也是技術架構演進任務的一部分，只是相對風險更低、周期更短，一般是一至兩個星期以內可以確保交付完成的任務，此類任務遵循快速立項、快速交付、快速結項的原則運作。而此節所指的技術任務更多的還是大型、高難度、高耗時、高收益的產品架構級別任務，要么不動，一動就牽動全身。
? ? ? ? 結合目前產品組項目管理方案——禪道，做了如下具體運作規劃：
? ? ? ?技術架構演進相關的項目主要有三類：技術任務池；技術預研階段項目；開發實施階段項目；
6.1 App架構改進優化任務池項目
? ? ? ? 這個項目做類似產品需求池作用，所有技術改進類任務先統一納入這個任務池中，編排優先級，并關聯產品需求。對于最高優先級（優先級為1）的任務，統一納入下一期項目“App架構優化**期”中啟動研究或開發。
? ? ? ? 關鍵節點：
1、方案優先級編排：一般采用郵件評審確認的方式，原則上一個工作日給出評審意見，否則按默認優先級執行；
2、方案評審：方案確認后，有主要預研人員組織技術團隊、核心產品經理進行方案評審；
3、方案轉需求：方案預研人員與產品經理協商，選擇合適版本以關聯需求的形式轉入版本需求進行實施并上線。
6.2 預研階段項目
? ? ? ? 高優先級的任務會定期排入新的分期項目，先由核心技術人員進行技術可行性預研，預研階段要求形成方案預研文檔，并在技術核心團隊中組織技術方案評審，評審通過后再開始基礎框架代碼的封裝開發，基礎開發完成后才轉入下一階段全面實施階段。而對于主程預研類任務，因為影響范圍相對較小，經過預研階段就可以直接關閉項目，結合當前版本需求進行開發實施即可。
6.3 開發實施階段項目
? ? ? ? 在基礎開發工作完成后，方案主導人員結合方案預研文檔對團隊內普通開發人員進行技術宣講（即技能培訓），宣講完成后分配全面實施任務給普通開發人員進行全產品級別的統一整改開發，開發完成后，結合所關聯的產品需求納入對應版本測試并發布上線。
7 需求分析
? ? ? ? 在移動產品團隊中，產品經理是一個非常關鍵的角色，除了產品功能設計與規劃，還有一項核心技能即是需求分析，需求分析能力的強弱直接決定了功能開發效率與返工率、測試用例開發質量、測試質量，最終決定版本交付質量。
? ? ? ? 雖然現如今項目運作方式變了，但是軟件開發周期中的事情并沒有減少，只是做了角色重新分配，傳統項目式運作方式中除了項目經理，還有需求分析師這一角色，而在敏捷迭代運作方式中，這一角色其實是由產品經理承擔的，所以不客氣的說，不是把你擺上產品經理的位置，你就真是產品經理，只有真正具備了產品經理的相關能力，你才能稱得上真正的產品經理，而不僅僅是所謂的“產品狗”。
7.1 需求分析技巧
? ? ? ? 需求分析是一類非常專業的IT技能，筆者三年前寫了兩篇文檔，之前是放在CSDN上的，現也收錄進簡書專輯中，內容的整理格式是基于以前傳統瀑布式項目運作流程，但分析過程其實不論哪種項目運作方式其實都是一樣的，只是交付成果不同，原來是《需求分析報告》與《需求規格說明書》，現在是《需求原型稿》與《需求補充說明文檔》，如下鏈接僅供參考：
http://www.lxweimin.com/p/fc857ac86766
http://www.lxweimin.com/p/c4c368cbd892
7.2 需求優先級編排
? ? ? ? 文章末尾再扯一句需求優先級編排，需求優先級依照價值、風險、成本、依賴性四個維度來綜合評判。這四個維度中，產品經理會優先關注價值，而項目經理會優先考慮交付風險與交付成本，而至關重要的技術依賴性，只能是由開發負責人來識別，三個角色各司其職，缺一不可。
