一、公司产品管理
2.1现状
市场需求会导致产品的升级、产品子型号的诞生，如为中交公规院研发的A1P系列产品、针对不同量程的HCF700等等。按照公司现在的思路，产品有重大升级需求后由VP决定是否升级，然后通过会议通知组长和实际开发者、PM。之后产品升级的过程就被关进“小黑屋”，产品的开发进度可能只在组内流通，或者在某周周一的例会上被提及，核心研发人员才能得知这个产品的最新状态。
产品需求没有进行管理。有些从市场、销售发聩回来的需求都被“以后改一下”搁置了。公司现在安排的“产品经理”可能还只是一个title，并没有实际支配这个产品形态的权利，自己的意识形态里还只是一个程序员，产品需求的事可能惰性的认为应该是上级分配给自己的，因此可能不会主动记录产品需求。一个产品需求可能来自一个不经意间的灵感，可能来自实际用户的真实反馈，可能来自同事的建议等等，因此不做记录和评估，一些可能极大提升用户体验的需求就这样被搁置了。
产品测试无法进行用例管理。产品测试过程无从得知。
产品发布流程过于复杂。一个产品从提交测试到发布需要准备的东西过多，并且流程不够规范，稍有不慎就会遗漏东西，如果定制一款持续集成工具可很好的解决这个问题，并且能够提高交付产品的质量。
全产品状态的查看。现在最新产品状态只能通过seafile托管的定期人工合成的全产品状态文件进行查看，体现的信息少，并且可能由于沟通的问题造成错误。
2.2项目管理
因地制宜，制定符合xxxxx的工作流。公司产品研发使用的是瀑布式开发，但和现在盛行的Scrum有很多相似之处：制定需求、筛选需求、拆分任务、分配给产品经理（开发人员）、每周总结汇报、产品发布后进行展示等。redmine与禅道都可以进行敏捷项目的管理同时也适用于现在的瀑布流式开发管理，对于我们当前所有的项目我认为通过这两款软件都可以解决。
了解Scrum：
以人为核心、迭代、循序渐进的开发方法。
关键词： 激情、速度、争先恐后。
宣言：个体与交互、可工作的软件、客户协作、响应变化（对比过程与工具、面面具到的文档、合同谈判、遵循计划）。
http://zh.wikipedia.org/wiki/%E6%95%8F%E6%8D%B7%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91
二、禅道项目管理系统
3.1禅道能解决的问题
禅道项目管理软件的主要管理思想基于国际流行的敏捷项目管理方法—Scrum。Scrum方法注重实效，操作性强，非常适合软件研发项目的快速迭代开发。但它只规定了核心的管理框架，还有很多细节流程需要团队自行扩充。禅道在遵循其管理方式基础上，结合国内研发现状，整合了bug管理，测试用例管理，发布管理，文档管理等功能，完整的覆盖了软件研发项目的整个生命周期。在禅道软件中，明确的将产品、项目、测试三者概念区分开，产品人员、开发团队、测试人员，三者分立，互相配合，又互相制约，通过需求、任务、bug来进行交相互动，终通过项目拿到合格的产品。
禅道项目管理软件的主要功能列表：
1. 产品管理：包括产品、需求、计划、发布、路线图等功能。
2. 项目管理：包括项目、任务、团队、版本、燃尽图等功能。
3. 质量管理：包括bug、测试用例、测试任务、测试结果等功能。
4. 文档管理：包括产品文档库、项目文档库、自定义文档库等功能。
5. 事务管理：包括todo管理，我的任务、我的Bug、我的需求、我的项目等个人事务管理功能。
6. 组织管理：包括部门、用户、分组、权限等功能。
7. 统计功能：丰富的统计表。
8. 搜索功能：强大的搜索，帮助您找到相应的数据。
9. 扩展机制，几乎可以对禅道的任何地方进行扩展。
10. api机制，所见皆API，方便与其他系统集成。
3.2为什么不是redmine+testlink+插件
根据51Testing2015年第九届软件测试现状调查报告中关于测试管理工具分配的情况：
报告显示，测试管理软件中禅道占据主导地位。禅道软件的开源性质、商业化路线、敏捷开发方式使得禅道可以广泛接受用户的反馈、需求并实现快速迭代，这使得禅道的可靠性、易用性得到了保障。
腾讯移动品质中心对市面几款常用的项目管理工具按照常用的管理模块划分后进行对比：
报告显示，即使redmine与testlink做功能互补，仍会缺少产品整个生命周期的部分功能。并且这种互补会造成功能的重复，内部逻辑流程不清晰。
根据实际使用体验对两款软件的细节进行对比（5分制）
| 禅道 |
redmine+插件 |
|
| 项目管理功能 |
5 |
3（项目、产品、需求、测试用例无法集成） |
| bug管理功能 |
5 |
5 |
| 用例管理功能 |
5 |
3（需要testlink支持） |
| 需求管理功能 |
5 |
3（需要其他插件） |
| 版本管理功能 |
5（项目版本、测试版本） |
5 |
| 文档管理功能 |
5 |
3（不支持分类） |
| wiki |
0 |
5 |
| 项目论坛 |
0 |
5 |
| 项目关联产品 |
5 |
5 |
| 项目关联需求 |
5 |
2 |
| 项目关联测试用例 |
5 |
2 |
| 桌面端软件提醒 |
5 |
3（第三方个人插件） |
| 移动端软件 |
3（需要付费专业版） |
3（第三方个人插件） |
| 用例不通过直接报bug |
5 |
5 |
| 邮件提醒 |
5（还可设置短信提醒） |
5（每次状态更改，自己也会收到邮件、烦） |
| 领导审查项目进度 |
5 |
1（无进度提示、无法了解项目总体状况 ） |
| 销售、市场了解产品进展 |
5 |
1（无进度提示、无法了解项目总体状况） |
| 报告 |
5 |
3（需要插件支持，中文支持不好） |
| 报表统计图 |
5 |
4（可视化效果弱、统计项目少） |
| 研发查看所属自己的任务 |
5 |
5（mypage） |
| 界面友好 |
5 |
2 （无设计感、操作便携性） |
| 学习难度 |
2（涉及角色比较多） |
4 |
| 技术支持服务 |
5 |
3 |
| 总分 |
100 |
80 |
通过这个表格对两款软件进行详尽的对比，可见禅道在功能上要比redmine略胜一筹。并为以后加强产品管理提供了很大的空间。
在测试相关功能方面，列举几个禅道与redmine的差异之处：
首先在测试用例执行方面的对比如下。
| 禅道 |
|
| |
禅道提供了丰富的二次开发接口，用例执行甚至可以触发一个自动化测试脚本对其进行测试。用例执行失败后可以直接转到bug对开发人员进行反馈。 |
| redmine+testlink |
|
| |
testlink也支持测试用例执行并转bug，但是根据调研显示支持的bug管理系统有：jira、bugzilla、mantis，并不支持redmine。 |
为了在文档中体现测试用例、bug的情况，对redmine和禅道的导出功能进行对比：
| 禅道 |
|
| |
支持 csv、xml、html（可自定义导出字段、编码） html导出可点击链接跳转回禅道bug管理详情界面，功能很人性化。 |
| redmine |
|
| |
redmine 支持 pdf、csv，（中文不友好） |
为了查看产品测试迭代的状况，要查看bug的统计表，对bug统计表的对比如下：
| 禅道 |
|
| |
禅道报表（可视化效果一幕了然，统计项目更多） |
| redmine+testlink |
|
| |
用bug数量作为统计结果并不能反应产品bug的收敛情况。 |
对于产品经理、测试人员每天都要安排自己的工作内容，并且要跟踪自己负责产品、项目的最新状态，测试人员和开发人员要经常进行交互，因此每个人最好应该有个主页记录自己工作的完成情况。
| 禅道 |
|
| |
高度自定义的设计，产品经理可以查看还没有立项的需求，研发、测试人员可以查看bug的反馈。每个人都可以清晰地知道自己有哪些任务与没有完成。 |
| redmine |
|
| |
Redmine只能查看bug的反馈情况。 |
禅道在督促大家工作进度方面做的很好，每天早上一封邮件提醒，提醒还有哪些任务没有完成、哪些bug没有修复等等：
对于公司来说：研发、产品经理关注于任务、需求、bug状态等信息。QA测试人员关注于任务、用例、bug状态等信息。部门负责人可以安排任务并将其指派给产品经理、测试人员等。在禅道中每个人都可以自定义自己的todolist，这个功能有助于个人安排好自己的时间。
禅道中针对敏捷开发思想中的“任务”模块有时间跟踪功能，这个功能加以利用后可以通过燃尽图非常方便的了解项目当前的进展情况。
3.3使用禅道有哪些挑战
由于大家现在习惯了使用redmine进行bug跟踪管理，对于禅道的操作方法比较陌生，因此有一定的学习成本，但是我相信通过一两次培训加上一个项目的实践完全可以掌握的。
技术总监应督促大家更新任务进度，必须严格执行，如果加以行政处罚、奖励效果会更好。