随着Venus
体系逐渐定型,社区和产品对Venus
需求变多。建立一套适用于Venus
产品需求管理流程。本文档将着重于来自团队外部的需求管理。
当前针对Venus
产品的需求类型大致分为以下类型:
- 社区需求
- PM需求
- 生态合作伙伴需求
社区需求着重于鼓励社区参与到issue
提交的过程中。尽量引导/鼓励社区对其所期望的应用场景,即,想要得到的结果,来提出issue
。这样由社区提出场景
,然后Venus
团队具体进行工程设计的模式推进。
PM会在不断追踪Boost
和Lotus
的新功能特性的同时,把他们的一些好的实践同样以issue
的形式作为需求提到Venus
相关的repo
中。产品和PR追踪都在github
上以讨论的形式留下记录。
当Venus
需要集成生态合作伙伴时,团队可能需要对Venus
系统本身做出调成,以对接生态合作伙伴的需求。这个部分可能会对应到更大,更全面的一个业务场景流。
- 由PM统一对接外部需求
- 在明确要做的情况下,建立
issue
,加入到sprint
开发计划;[流程结束] - 在不明确要不要做的情况下,由PM对
issue
打上C-triage
标签,并assign
一位工程师,如工程师不熟悉该issue
的领域可以询问或者assign
另一位工程师
- 在明确要做的情况下,建立
- 每个
sprint
总结会之前,被assign``issue
的工程师需要对其被assign
的C-triage
的issue列表进行评估- 如可直接判断需求不需要做,在
issue
中选择Closed as not planned
;[流程结束] - 如可直接判断需求已经满足,在
issue
中选择Closed as completed
;[流程结束];(可选)并关联相关PR或者功能特性说明 - 如判断需求有效,那么把需求
issue
加入到开发计划中
- 如可直接判断需求不需要做,在
- 在
sprint
总结会上,对需要C-triage
的issue
进行整体把控,把有问题的issue
单独拿出进行讨论;[流程结束]
- 每月一次对运维,商务,生态,社区等用户的需求做收集。
- 对收集的需求,核心开发者内部开专门会议进行需求分析。
- 分析结果在共享文档上进行记载,记录对应的issue,并通过venus群、共享文档和github等方式向需求方进行反馈。