A. 2019-10-17 scrum敏捷開發流程梳理
TB項目規則：
1. 每個團隊默認會有2種類型的項目，1）user story 2) Development Task項目 （兩種項目內的任務寫法見圖）
2. 我們採用2周為一個迭代，每個迭代每個團隊都會創建一個user story項目以及Development Task項目
3. 一個迭代項目內的任務可以有不同的發版時間，但必須在這一個迭代內（2周）發布完成
TB任務規則：
1. user story 內的每個任務必須是一個最終可以被QA 測試 以及最終用戶使用的功能點
2. 一些比較小或者零散的任務，也可以寫成一個單獨的user story 任務然後關聯對應的開發任務。
3. 每個user story任務都需要通過關聯附件，或者備注鏈接的方式把需求寫明
4. 每個user story任務都必須有開始和結束時間
TB QA測試規則：
1. QA 測試過程中報出的bug，在user story項目里創建bug任務並關聯。QA不需要在Development Task項目里創建任務
1. 頭腦風暴 會議（基本針對比較大的需求）：
** 風暴產品需求，實現方案，可行性，確定owner 及 大概可以進入的Sprint燈**
** 參與者： 產品， CTO，架構師**
2. 需求溝通會（多次）
** 由產品與owner，QA進行需求的溝通，私下裡約會議，可能多次**
** 注意：建議在每個sprint 第二周的周三，周四之間進行溝通，因此第一版本的PRD 需要在這個時間就有**
2. 正式 Planning meeting
** 每個sprint的planning meeting必須在每個sprint第一周開始前召開結束（建議是每個sprint 第二周的周五）。召開會議的前提條件是 PRD 定稿，定稿的標准：**
** - 對涉及到頁面的需求，需要mockup並配有文字描述**
** - 對異常邏輯的分支需求的描述**
** - 涉及到導入導出的模版描述**
** - 沒有還需要確認的關鍵節點的疑問**
對不能定稿的產品需求，不考慮進入Sprint開發
** 參與者： 產品， Owner，QA，（ 產品， CTO，架構師 隨機）**
** 會議目標：了解需求以備拆分User story**
** 確定優先順序，**
** 依賴性，**
** 風險，**
** 確定測試環境，**
** 確定開發提測時間，**
** 確定是第一周的周四還是第二周的周四上Stage**
Planning meeting****的產出：
- 所有研發都已經把任務拆解到****3manday****之內，且****owner****完成該迭代甘特圖。
- ix****環境已經分配完畢。
- planningmeeting****之後的****3****天內，****test case review****需要被完成，****smoke case****和****test case****都被產出。
對PRD 的格式有一些需求
- PRD 統一上傳到Confluence
**- PRD 建議有統一的格式（現在有 pdf，Axure，Confluence wiki 甚至圖） **
- PRD 需要進行版本管理 （文件名上帶日期，每更新一次一個新的文件）
1. Ix 環境作為開發環境，在每個sprint開始前做 刷新以及DB restore （CMS 以及 Magento DB）
2. 原則上，每個業務團隊會有屬於自己的一個專有開發環境。開發環境由owner自己維護需要部署服務的分支以及tag。
3. Stage環境在一個sprint里默認有2次發布機會，****每周周四****。理論上stage環境的佔用不應該超過1天，也就是當天上stage的功能，當天上生產環境。平時stage都保持和生產一致以備hotfix
TODO // 默認狀態
Dev In Progress // 開發中
Dev Done
//前端：頁面開發完成，與後端介面在IX環境整合完成
QA In Progress // QA在Ix 環境測試
QA Done //Ix 測試完成，可以發布Stage 環境
Done // Go live
B. "敏捷開發"的內容是什麼
我不贊同huangmin8818的回答
敏捷方法的「敏捷」並非指的是開放速度，而是響應客戶需求變化的速度
傳統開發方法是基於客戶能夠在需求階段就給出完整、准確的需求的假設，所以期望於在項目初期獲得詳細的需求，然後嚴格控制需求變更，最終完成符合需求的軟體。
但我們發現實際上往往需求是「涌現」出來的，也就是說是隨著開發的不斷進展而不斷發現出來的，而無法在項目初期就明確的定義它，也就是說傳統開發方法的基本假設是錯誤的，這一新的假設導致了敏捷方法的一系列實踐。
敏捷方法的核心就體現在它的四句宣言中：
個體與交互 勝過 過程與工具
可以工作的軟體 勝過 面面俱到的文檔
客戶協作 勝過 合同談判
響應變化 勝過 遵循計劃
C. 簡單的說明敏捷開發是什麼意思最好是舉例或者打比方的方式，通俗的解釋。
敏捷開發是一幫追求快捷、可控的老程序員綜合了多種開發方法的優點，整理出來的一套開發組織方法。
簡單例子--一個開發任務，首先分割成多個獨立的小模塊，再分配給各個程序員，由程序員確定每個小模塊多久（人天）完成，綜合所有獨立模塊的時間成為整個項目的開發周期。
採用敏捷開發，項目進度可控，程序員工作量也可控。
去網上搜這個文檔：scrum-and-xp.pdf，非常簡明扼要。
推薦一本書：清華大學出版社《敏捷軟體開發原則、模式與實踐》。美國人寫的。