forked from openkylin/docs
46 lines
3.6 KiB
Markdown
46 lines
3.6 KiB
Markdown
# openKylin需求管理规范
|
||
|
||
|
||
## 1.1 需求收集
|
||
当版本发布计划明确后，产品经理发布相关邮件，通过以下两个途径收集需求，这两类需求的提出者以及在码云提交issue的规范如下：
|
||
- 社区版本的技术规划需求，由社区技术委员会提出，由产品经理将需求issue录入Release-Management仓库下，选择issue类型为“需求”，填写需求标题、详情，标记release SIG和feature标签，并标记版本里程碑。
|
||
- 各SIG项目对本版本的规划需求，由各SIG组提出，由各SIG组Maintainer将需求录入本SIG项目仓库下，选择issue类型为“需求”，填写需求标题、详情，标记本SIG和feature标签，并标记版本里程碑。
|
||
- 当所有需求都录入码云后，产品经理可以通过社区的全量issue筛选汇总版本全部需求。
|
||
|
||
说明：
|
||
- 通过标记SIG归属标签，将所有需求issue与SIG组对应起来。
|
||
- 需求详情须按模板填写清楚：需求背景、需求描述、实现方案、验收标准。
|
||
- 对于需要保护的需求可以选中内容风险标识复选框，以防仓库外成员访问。
|
||
- 数据统计时，以issue类型来统计需求，标签feature以便于码云前台页面筛选。
|
||
|
||
## 1.2 需求审核
|
||
产品经理汇总需求后，组织技术委员会完成评审，评审通过后将审核结论通过邮件列表通知所有订阅人，并对码云issue进行以下操作：
|
||
- 本版本计划完成的需求issue，确认关联正确的里程碑。
|
||
- 未来版本计划完成的需求issue，确认关联正确的里程碑。
|
||
- 审核确认暂无规划的需求issue，不关联里程碑，更改状态为“已拒绝”，待后续有新的规划，可以修改状态为“已确认”，并关联正确里程碑。
|
||
|
||
## 1.3 需求细化
|
||
需求评审完成后，本版本计划完成的需求issue均须一周内输出《需求说明文档》，并可以通过以下方式提交文档：
|
||
- 需求说明文档：创建PR，选择目标分支，填写标题为：“【需求issue标题】需求说明书”，PR详情描述第一行写明：本文档是对需求（issue编号和链接）的详细说明，同时标记标签为PRD，选择版本里程碑。
|
||
- 提交PR后，审核人员通过后，合并PR。
|
||
- 需求issue：需求说明PR合并后，在需求issue的评论框写明：需求说明PR链接。
|
||
|
||
## 1.4 需求排期
|
||
Release SIG组明确发布计划后，产品经理可将版本计划通过邮件列表通知所有订阅人，并通知各SIG组对需求issue进行排期，具体操作如下：
|
||
- 各SIG组Maintainer明确本SIG组需求issue完成计划，在码云标注issue的“开始日期”、“结束日期”，并可设置“优先级”。
|
||
- 待需求issue排期完成后，Release SIG组发布经理核对需求issue排期情况，对于有争议的需求可以组织评审。
|
||
|
||
说明：
|
||
- 评审结论可通过邮件列表通知所有订阅人。
|
||
|
||
## 1.5 需求变更
|
||
在版本计划内，若需求范围和计划等出现变化，产品经理要组织技术委员会/Release SIG组进行变更评审，评审完成后产品经理将结论通过邮件列表通知所有订阅人，并进行以下操作：
|
||
- 在变更需求issue的评论框内，标注本需求变更原因和评审结论。
|
||
- 对于里程碑有变更的需求issue，要确认关联变更后的里程碑计划，并设置正确的排期，对于暂无规划的需求issue，不关联里程碑，更改状态为“已拒绝”。
|
||
- 对于需求范围有变更的需求issue，需求负责人要输出变更后的需求文档，并按1.3章节方式提交需求文档PR。
|
||
|
||
说明：
|
||
- 评审结论可通过邮件列表通知所有订阅人。
|
||
|
||
|