《MVP Workbook》Beta

参考指南（试行版）

工作流程和规则整体规划

关于项目管理：

1. bug统一由鲁炎管理，大家发现的bug鲁炎负责录入issues里（选择bug标签，对应里程碑版本号等），草姐负责分派任务和跟进进度。

2. 新功能由林可整理需求并制定版本号，每个版本预计2周左右的迭代周期（事先确定好发布日期），并拆分功能到issues（选择新功能，对应里程碑版本号等），草姐负责分派任务和跟进进度。

发布需求和完成需求的Workflow（暂行策略）

• 本石墨文档用于组织需求和总览开发计划
• PM在repo中建立一个md文档分期展示开发需求总览
• PM在Issues中提交所有的新需求，label设置为enhancement。并且对应到版本的milestone
• 由PM和CTO统一assign新的issue给开发者

以上流程是为了适应我司部分员工remote的情况，并且为了满足减少多地沟通和复杂沟通的情况。因此PM决定暂时采用该策略进行管理，作为试行方案。

发布生产环境规则：

我们后面生产环境发布，首先时间点和功能list是由产品、开发、运营事先约定好的。 除非需要解决紧急bug会随时发布。 其次发布时所有项目成员必须在线，随时解决各块的问题，

• 前端陈浩发布，张翔、小田是备份人
• 后端陈浩发布，Joe是备份人

测试和bug提交：

bug在鲁炎这边汇总，由鲁炎按照格式统一提交到issues上。已经在github上建立bug的提交模板 PM和技术负责人负责assign任务。 PM利用repo里面的Project工具来管理bug的完成进度状况。

工具平台

• 石墨--撰写文档
• 蓝湖--查看产品设计图和UI成品图
• github--代码管理
• Github_issues--需求发布和管理，bug发布和管理
• Github_Project--针对某一专项任务进行任务进度管理
• Microsoft Project--项目开发排期（仅作为PM的可选工具）

成员职责

所有人--每个人都要担任测试的职责 岛--舰长，台前幕后推手，副催 陈浩--技术方案决策，技术开发人员安排，开发评估 林可--产品设计，线框图制作，产品文档管理，需求管理，生命周期管理（待开发） 草姐--技术开发型主催，临时性前端，产品文档管理 Aaryn--社群经营者，文案好手 鲁炎--测试组织者， 咚咚--合约工程师，灵魂全栈 小田--仙女座全职前端工程师 张翔--仙女座全职前端工程师 秦孝文--仙女座架构工程师 Joe--Remote后端工程师 Frank--社区前端架构 Deaso--社区工程师

新需求决策流程（测试版）

按照Kano模型将需求划分为5种级别。 当前阶段我们应当将资源投入在去做+0和+2的需求。

开发执行优先级规范

P0--紧急关键，立马着手解决 P1--关键功能，按部就班必须完成 P2--重要功能，可以多寻找解决思路后分担完成 P3--暂时不用考虑

大目标

智能签名的目的是探索内容传播的更多可能性。目的是传播，裂变是手段的一种。