敏捷開發迭代會議，主要是挑出產品設計和功能問題，保證迭代版本的產品原型完整性、正確性、合理性。如果產品大致功能沒有多大問題，留下些小問題，那麼可以進行專案拆分、工時估算。(一個細節要提醒的，產品必須在迭代會議之前，把原型提前2-3天交給相關人員，開發人員可以在會議上提出互動細節的問題、競品分析)

迭代會議一般 14-18點   或 15-17.30；前半場PM主導，講解原型，Team提出疑問、細節問題；後半場 SM主導APP團隊拆分專案，引導團隊成員進行工時估算。

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

PO或PM場

會議流程

一、PO或SM 公開迭代時間表

二、PO 講述 Product Backlog，對應的業務價值和優先順序

注意點：

1、有些功能程式設計師同事覺得多餘 、或沒必要做的；PO或PM要特別交代 業務價值。 

         2、相關業務也要對接其他部門、 或公司資源(如分享賬號)、支付寶 微信交易的公司賬號 或第三方銀 行的要交代跟誰對接

三、團隊針對Sprint Backlog和優先順序達成一致

注意點：

1、開發時候優先完成主要模組功能點再完成互動細節

 2、在提前兩到三天，Team拿到 原型後對產品沒交代明白的流程、

互動細節做競品分析記錄， 會中向PM或PO提出討論明確細節

四、Scrum Master和團隊成員共同確定Sprint Backlog

1、基本上產品設計都要做，只是一些特別的因"外部原因"、"資源不確定"不做要記下

參與成員

Scrum Master ：敏捷教練或懂敏捷開發的專案組長

PM 或PO：產品經理

Team(開發人員或專案實施人員)： 前端、後臺、app組、測試、UI美工

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

SM引導Team場(有兩種方式)

一種前面提到如果產品提前3天給了，這三天裡面不確定因素已經跟產品確認了。這種情況下可以讓team  app開發組來進行模組的故事講解拆分(迭代拆分)

一種因為team缺少拆分經驗、對故事講解不熟悉，產品給的時間較短，那麼這時候就要  SM去主導全程進行結合技術進行模組的故事講解、拆分；引導隊員完成專案評估任務

會議流程

1、團隊成員針對Sprint Backlog共同分解任務；

2、團隊成員共同進行工作量評估 (每個Task不超過2天)，確定開始時間和完成時間；

3、團隊成員共同認領任務；

5、團隊共同確認迭代目標和價值；

參與人員

一、Scrum Master

1、組織講解拆分細節      

       2、讓組員認領任務

3、與組員之一共同評估時間(一般安隊員能力 評估為準)                                        

        4、記錄Sprint Backlog  拆分的任務與時間

   5、考慮能力及業務熟悉度   優先制定重要的任務

       給能力強的或熟悉的人， 將簡單的任務分給新人或較薄弱的人

二、團隊成員

1、前端和後臺組、UI組、測試組 可團隊內部組織分工。  

 2、後臺分工完成後將分工表發至 交流群，並且介面文件上各個介面 標明誰負責

      3、美工明確出圖時間、與切圖時間；  明確出圖的規格：解析度

三、其他人員選擇性參加

1、對接公司賬號中心對接人

2、資源對接人(明確資源到位時間)

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

PS:DoD表示沒明白到底是什麼意思，如果是成功標準或完成標準那麼可以這麼幾個階段

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

以下Dod時間是以18天-21天的迭代

一、後臺：(迭代會議前 1個星期就已經介入後臺設計及功能開發，評審完後出介面文件)

在原型評審前，後臺就提前一週或兩週介入；

迭代會議評審完之後的兩天後出介面文件進行介面文件給app，app在拿到介面文件後當天或第二天進行介面評審

1、介面是否規範

2、key是否統一、介面設計是否規範

3、一般一個介面初始化的介面不會超過兩個

4、更高的安全性、快捷性相關設計是否到位token還是 session;)

介面確認階段差不多佔用4天時間，這個添加了一些不穩定因素

·測試：(專案評估完後，測試3天內熟悉原型、跟進反饋上一個迭代版本問題)

1、測試介面是否暢通

2、是否按介面文件輸出資料

3、json格式是否錯誤

4、關於一些增刪改查是否完整等等(這塊我應該理解不到位)

ui：(專案評估完7-10內出完UI及ios切圖及android大部分切圖 )

差不多按照迭代提前一個星期出ios  UI     2X，時間 不夠的  android先用這套 ()

android現在基本上用1080 * 1920p 切圖了，不知道ios 1080*1920的用，看上面文章應該不能通用；

app：(平均每人5-8天工作日的開發時間，專案的後一半時間，根據介面繼續完善邏輯、及介面問題跟蹤解決；需要留給測試一半時間測試app)

按照優先順序完成任務；沒有評估時間內沒有完成那麼個人留下加班，比較棘手問題那麼團隊成員有時間的幫助解決棘手問題，保證專案進度正常完成。