一个迭代项目是如何开展进行的~
【迭代项目由哪些环节构成？】九大环节
①产品宣讲
②评估阶段
③反讲
④数据串讲
⑤任务拆分
⑥开发阶段
⑦demo
⑧测试阶段
⑨上线
可粗略分为以上九大环节，这是相对理想的状况：这里不讨论前期产品调研和产品相关决策而是假设产品原型已出，一切准备就绪。
【各环节中具体行为】
1、产品宣讲
- 需求宣讲应该明确业务场景和用户价值。
- 需求宣讲应该明确历史数据处理方案。
- 需求应该包括报表统计和运营指标。
- 宣讲之前产品经理需要跟技术负责人和测试负责人沟通需求内容。
- 需求没讲清楚不开工；原型没到位不开工；UI 没到位不开工。
- 复杂的迭代需要多轮宣讲。
- 前端、后端、测试等所有人都应该站在客户视角以产品思维质疑需求的合理性。
2、评估
包括业务背景调研、技术方案评估和资源评估。
3、反讲阶段
- 在迭代所有成员中抽签决定反讲人员，特别复杂的迭代可以分岗位抽签。
- 反讲结束由产品、开发、测试共同罗列业务影响点。
4、数据串讲
主持人以数据流转为主线，沿途约定前后端接口的功能、请求方法、参数、返回体，由后端落实为详尽的文档。推荐后端提供假接口进行前后端工作解耦。
5、任务拆分
- 单个开发任务分解项时长一般不超过 4 个小时，不要超过 1 天。
- 主张前后端解耦开发，如果需要联调，按照开发同样标准做任务分解。
- buffer 时间原则上不超过 1/3。
- 测试只评估验证用例时间。开发人员可以根据需要在测试环节加入改 bug 时间。
6、开发阶段=迭代启动
- 需要发送迭代启动邮件，邮件内容有特定模板。
- 开发 leader 需要对下属的整体技术方案、核心代码进行把关。
- 开发成员变更关键技术方案需要得到开发 leader 确认。
- 开发期间需要定期组织站立会议（站立会议需要注意的下面会提到）。
7、demo（功能演示）
- demo 可以分模块分别进行，但是最终 demo 需要演示完整版。
- 一般由测试操作，demo 质量不过关测试可以拒绝接受。
- demo 之后不接受过大的需求变动。
8、测试阶段
- 测试发版申请原则上应该一次性提交，且内容和顺序应该跟上线申请保持严格一致（包括历史数据处理）。
- 除代码以外的所有发版项需要走 svn 控制。
- 发版时间兼顾开发人员验 bug 的及时性和测试人员跑流程的完整性。
- 测试阶段包括模块测试、集成测试、labs 测试。
- 测试内容包括本迭代内容、业务影响点、主流程，粒度由细到粗。
- 测试出的 bug 指向顺序依次是具体负责人=>前后端负责人=>master。
- 开发根据 bug 优先级进行修复。
- 开发关闭 bug 时，需要标注 bug 产生的原因和影响点。测试重新打开时需写备注。
- 对于多人参与修复的 bug，一个人修复完毕将 bug 指向另一个人。
- 后端开发同学需要关注异常。
- 不要放过一个 bug。
- 第一轮日清 P1 级别 bug，第二轮日清 P2 级别 bug。
- 功能变动大的迭代需要向安全团队申请性能测试。
- 测试期间同样需要定期组织站立会议。
9、上线
- 产品经理提前三天发布上线公告。
- 测试负责人提前一天发布整版上线申请。
- 上线当日 19:00 之前封版，出现重要、紧急、复杂的 bug 需要结对编程。
- 上线测试环节，测试同学不要放过一个 bug，开发同学不要放过一个新异常。
- 定位问题时不排除运维发版失败因素。
【项目master】
每个项目有且仅有一个master，master 是整个迭代项目的把控人。
master的职责
- 自始至终紧盯目标、规划流程、推动进度、捕获障碍并排除、协调资源，确保迭代高质量准时上线。
- master 开发时间不要超过工作时间的一半（建议）。
【站立会议】
进入开发和测试阶段会定期组织站立会议，以便更加实时准确得跟踪项目的进度。
站立会议主持人（开发阶段由master担任，测试阶段由测试负责人）会议时说什么？
- 上次站立遗留问题跟进。
- 需求变更的传达公布。
- 暴露障碍并调整规划。
- 参与人员的进度跟踪。
站立会议时间尽力把控在10分钟之内完毕。
