客户端与服务器接口开发发版流程V1.0.pdfVIP

客户端及服务器接口 开发发版流程 V1.0 • 需求阶段 • 开发阶段 • 测试阶段 需求阶段 • 第⼀次需求梳理会议 • 开发人员和测试人员通过此会议了解下⼀个迭代的需求点 • 对需求有任何问题需要在此会议及时反馈给产品（技术层面，实现难 度，实现方式的建议等） • 产品人员收集反馈并修改需求 • 开发人员需在会后自发讨论会涉及到的开发工作 • 第二次需求梳理会议 • 产品提供修改后的需求点以及细节 • 开发和测试需要通过此会议理解需求 • 需求不在此会议上做任何修改了（除非⼀些实现细节方面） 需求阶段 • 迭代计划会议 • 结合第二次需求梳理会议 • 产品人员根据优先级排序Backlog • 根据评估的工作量，开发人员按照优先级承诺这个迭代能 够实现的Backlog • 承诺的Backlog必须这个迭代按时完成 • 其余Backlog放到下⼀个迭代 • 开发人员尽可能多的拆分Task 开发阶段 • 在此阶段出现的新需求⼀律放到下个迭代实现 • 需求不做任何更改（除非产品和开发在不影响时间的前题下都 同意的改动） • 根据项目开发情况，测试人员可以及时测试已完成的功能点， 并把问题报到bugzilla上。为确保开发可以顺利完成，测试人员 在此阶段不能干扰开发人员（除特殊原因） • 周五开发结束后，产品人员会拿到⼀个内测版本，主要用来总 结和收集反馈 • 如果反馈是bug ，则在测试阶段修复，如果是新需求，则放到 下⼀个迭代 开发阶段 • 特别强调 • 在开发过程遇到需求不理解或是不清楚等情况是很正常 的 • 但是在遇到这种情况时，⼀定要先和产品确认需求，确 保实现是正确的（换言之，有疑问就确认） • 如果最后发现由于沟通不及时导致实现有误，开发迭代 周期不会因此延长，开发人员只能加班完成 测试阶段 • 测试后的版本应该是⼀个没有大bug功能完整实现的beta 版 • 每⼀个迭代结束都有可能发布版本，具体根据产品及市场情况来定 • 当确定某个迭代发版时，会增加⼀个“发版迭代” • 在“发版迭代” ，测试人员会把从上⼀次发版后的所有迭代实现的功能点进 行统⼀集成测试，开发人员进行相应的debug任务（遵循目前的发版流程 即最少两次集成测试的原则） • “发版迭代”至少会在正式服上测试两天（如图），所以新的API需要提前 上线。另外，发版前的这个迭代的迭代测试时间减少⼀天。 总结 文本