FreeNeb tracking process - 版本历史

2019年5月6日 (一) 23:10 Cslt

2019-05-06T23:10:30Z

2019年5月6日 (一) 23:07 Cslt

2019-05-06T23:07:46Z

Cslt：以“我们需要对工作流程进行把控，对产品质量进行控制，对信息进行积累，对问题可以回溯。为此，需要利用各种辅助工具，包...”为内容创建页面

2019-05-06T23:07:25Z

以“我们需要对工作流程进行把控，对产品质量进行控制，对信息进行积累，对问题可以回溯。为此，需要利用各种辅助工具，包...”为内容创建页面

新页面

我们需要对工作流程进行把控，对产品质量进行控制，对信息进行积累，对问题可以回溯。为此，需要利用各种辅助工具，包括wiki, github, bugdb, tapd。我们需要建立一个清晰的框架，让大家共享信息，沉淀知识。综合起来，tapd是流程导向，bugdb是问题导向，wiki是知识导向，github最重要的是代码共享协同开发。

从前面使用经验来看，我个人感觉是tapd管理流程方便，适合项目进程控制。 Tapd的弱点在于不适合知识积累，因为缺少统一知识架构，不容易在其中提取过往知识。

Bugdb适合单一问题解决流程，利于knowhow知识的共享，同时，因为统一的NO.，适合整体knowledge talk。Bugdb适合research和engineer部门，分享研究进程，分享实验结果，track问题解决流程，建立问题从开始到结束的周期性管理。Bugdb不能派生子问题，不适合变动性流程管理；bugdb缺少富文本能力，不适合重量级知识积累。

Wiki适合较重量的，具有通用性、共享性，需要长期备份的知识，如release note, 公司规章制度等。这些知识需尽可能在成员间共享，放在wiki中较为合适。通用性较低的文档可以放到企业微信共享盘中。

Github主要用于代码共享，同时维护和代码相关的设计文档。Github具有track 问题解决的能力，但这一功能更重要的是在项目成员内部的共享，因此对开发者本身是方便的，但不利于整个公司的知识共享和问题回溯。

综上所述，FreeNeb目前可采用如下基本模式：

（1）项目流程管理用TAPD，只用来做进度控制，不要用来做知识分享。
（2）问题管理用bugdb，针对某一具体技术问题进行进度管理和知识管理，利用其统一编号来建立整个公司的问题空间。
（3）知识管理用wiki，用于归纳与总结。
（4） Github管理和某一产品相关的代码、文档和测试用例。

如果再精简一些，那就是“流程管理TAPD，问题管理bugdb”。

@@ 第14行： / 第14行： @@
 （2）	问题管理用bugdb，针对某一具体技术问题进行进度管理和知识管理，利用其统一编号来建立整个公司的问题空间。
 （3）	知识管理用wiki，用于归纳与总结。
-（4）	Github管理和某一产品相关的代码、文档和测试用例。
+（4）	产品管理用Github，管理和某一产品相关的代码、文档和测试用例。
 如果再精简一些，那就是“流程管理TAPD，问题管理bugdb”。

@@ 第1行： / 第1行： @@
 我们需要对工作流程进行把控，对产品质量进行控制，对信息进行积累，对问题可以回溯。为此，需要利用各种辅助工具，包括wiki, github, bugdb, tapd。我们需要建立一个清晰的框架，让大家共享信息，沉淀知识。综合起来，tapd是流程导向，bugdb是问题导向，wiki是知识导向，github最重要的是代码共享协同开发。
-从前面使用经验来看，我个人感觉是tapd管理流程方便，适合项目进程控制。 Tapd的弱点在于不适合知识积累，因为缺少统一知识架构，不容易在其中提取过往知识。
+从前面使用经验来看，tapd管理流程方便，适合项目进程控制。 Tapd的弱点在于不适合知识积累，因为缺少统一知识架构，不容易在其中提取过往知识。
 Bugdb适合单一问题解决流程，利于knowhow知识的共享，同时，因为统一的NO.，适合整体knowledge talk。Bugdb适合research和engineer部门，分享研究进程，分享实验结果，track问题解决流程，建立问题从开始到结束的周期性管理。Bugdb不能派生子问题，不适合变动性流程管理；bugdb缺少富文本能力，不适合重量级知识积累。