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，非常简明扼要。
推荐一本书：清华大学出版社《敏捷软件开发原则、模式与实践》。美国人写的。