产品研发流程

产品研发团队基于Worktile的Scrum敏捷开发协作流程

Nov 8, 2017

最佳实践,适用于整个产品研发团队,参考:Scrum中文网知识库

产品研发完整流程

图片 产品研发流程

准则

  • 大的版本,按模块进行,把Product Backlog拆成多个Sprint Backlog进行;
  • 产品超前设计1-2个Sprint,设计包括:UI设计、开发设计、测试用例设计;
  • 设计超前后端开发1-2个Sprint
  • 后端开发超前前端开发1-2个Sprint
  • 所有需求,必须先经过需求确定阶段,不允许直接提给开发同学;生产环境问题是bug不是需求,提给QA同学
  • 产品输出必须详尽,Sprint计划会议后不允许修改需求

角色

  • 产品负责人
  • Scrum Master
  • 产品团队:产品和设计同学
  • 研发团队:开发和测试同学

产品Worktile协作流程

图片 产品Worktile协作流程

研发Worktile协作流程(BED & FED)

图片 研发Worktile协作流程(BED & FED)

研发Worktile协作流程(APP)

图片 研发Worktile协作流程(APP)

研发会议安排

Sprint计划会议

  • 每个Sprint都以Sprint计划会议作为开始;
  • 目的: Scrum团队共同选择和理解在即将到来的Sprint中要完成的工作;
  • 周期: Sprint周期一般为1周,特殊情况不超过2周;
  • 时长: Sprint计划周数 * 2小时内;
  • 成员: 整个团队;
  • 职责: Sprint Backlog的需求及优先级来至产品负责人,对Sprint Backlog任务的安排、拆解、细化由Scrum Master完成;
  • 标记: Sprint任务设置截止日期,Scrum Master心中要有数:产品同学当前Sprint的任务是设计同学之后1-2个Sprint迭代应该承接的任务;设计同学当前Sprint的任务是后端开发同学之后1-2个Sprint迭代应该承接的任务;后端开发同学当前Sprint的任务是前端开发同学之后1-2个Sprint迭代应该承接的任务;测试同学当前Sprint的任务应该在该Sprint结束前发布

  • Sprint原则
    • Sprint任务优先,如需插入新的紧急任务需要与Scrum团队协商(生产环境问题除外);
    • Scrum Master需要分清楚优先级,并协调好开发任务;
    • Scrum团队需要齐心协力;
    • Scrum团队需要提前准备Scrum会议内容;
    • Scrum Master是Scrum团队一起的,并不是独立出去的角色;
    • Scrum团队成员平等、齐心、自由。

每日Scrum会议

  • 每日Scrum会议来确认每日要完成的Sprint待办事项;
  • 目的: 确认我们仍然可以实现Sprint的目标,交流进展和需要协作的问题;
  • 周期: 每天;
  • 时长: 每次不超过15分钟;
  • 成员: 整个团队;
  • 周期: 每天;
  • 团队成员依次快速描述自己昨天完成了哪些Sprint待办事项、今天准备做哪些待办事项、有哪些Sprint待办事项需要其他团队成员协调。

Sprint回顾会议

  • 目的: 回顾一下团队在流程、人际关系以及工具方面做得如何,讨论并得出改进措施运用于下一个Sprint;
  • 时长: Sprint计划周数 * 1小时内;
  • 成员: 整个团队;
  • 周期: Scrum Master发现可能存在问题时开,如进展顺利可与下一次Sprint计划一起开。

技术方案评审会议

  • 目的: 评审技术方案以期获得最好的方案,并给团队介绍方案;
  • 时长: 视具体方案;
  • 成员: 相关开发同学;
  • 周期: 技术方案实施前。

测试用例评审会议

  • 目的: 评审测试用例,保证准确率和覆盖率;
  • 时长: 视具体产品而定;
  • 成员: 产品和开发同学;
  • 周期: 测试开始前。

文档协作

需求文档

  • 在石墨上文档相应文件夹内,可多人实时编辑,秒级同步; 图片

  • 在部门共享盘里新建文档放置石墨文档的链接: 图片 图片

图表

  • 包括:产品结构图、产品用例图、产品业务逻辑图、测试用例思维导图、业务实现逻辑图;
  • 在ProcessOn的对应小组内; 图片
  • 用于:需求文档内、实现相关文档、任务说明等;
  • 对于用于描述功能实现的图,在部门共享盘里新建文档放置图的链接: 图片 图片

配合环节输出的具体要求

业务部门—>产品

  • 需求说明
    • 格式:Worktile任务
    • 提至:App bug与需求收集站bug与需求收集 项目的功能改进新增需求运营需求任务列表列表 图片
    • 要求:描述清楚需求的目标用户、使用场景等;
    • 模板:如何将新增需求描述清楚
      • 这个需求的目标用户有那些?
      • 这个需求解决了什么问题,解决之后达到怎样的效果?
      • 这个需求主要使用的场景是什么?
      • 是否有其他参考方案或竞品?
      • 未来三个月内,针对该需求实现后,我们的运营计划是什么?
  • 活动策划方案
    • 格式:文档
    • 提至:需求说明附件
    • 要求:
    • 模板:

产品—>设计、开发、测试

  • 原型Mockup
    • 格式:墨刀、Axure原型
    • 提至:任务说明
    • 要求:
      • 仅交付设计师一份完整的原型图;
      • 原型图要详尽,每个功能点在原型上都有对应的标注;
      • 原型图以实例呈现需求;
      • 原型图标注尽可能精炼,不允许有概念模糊的文案或功能名称出现;
      • 原型图不必填充图片,以黑白灰深浅色的方法表现层级关系即可;
      • 设计师在交互上的变更产品需提前/同步修改原型/文档;
      • 最后保证原型图与QA验收的需求文档一致
    • 模板:
  • 产品需求文档PRD
    • 格式:石墨文档
    • 提至:任务说明
    • 要求:
      • 保持和视觉设计图一致;
      • 包括产品结构图、产品用例图、产品业务逻辑图等;
      • 需求说明需做到完备,尽量涵盖正常状态、数据缺失、服务异常等实际开发和使用过程中可能产生的各种情况。
    • 模板:

设计—>开发

  • 视觉设计图和标注
    • 格式:Zeplin
    • 提至:任务说明
    • 要求:
      • 保持和PRD文档一致;
      • 使用评论功能来尽量明确设计意图,以及需要开发同学注意的地方:比如底部留白等;
      • 使用拉线标注等方法,明确页面中需要开发设置的元素,避免页面中元素过多时,开发时遗漏;
      • 动画等动态交互需要提供具体、可复现、可操作的参数;
      • 设计评审之后,本地共享盘放置一份jpg效果图。
    • 模板:
  • 交互说明
    • 格式:PRD
    • 提至:任务说明
    • 要求:
      • 必要的标注;
    • 模板:

开发—>测试

  • 技术实现方案
    • 格式:文档(逻辑流程、技术实现流程、存储方案等为主)
    • 提至:任务说明
    • 要求:简洁解释
    • 模板:
  • 接口文档
  • 版本更新日志
    • 格式:文档
    • 提至:任务说明
    • 要求:清晰描述此版本修改的模块,已经可能涉及到的模块。
    • 模板:

测试—>产品、开发

  • 测试帐户和仿真测试数据
    • 提至:联系获取
    • 要求:
    • 模板:

测试—>项目经理

  • 测试报告/可发布评估报告
    • 格式:文档(数据为主)
    • 提至:Worktile项目的“发版备忘”列表
    • 要求:简明清晰
    • 模板: