使用研发管理工具的现状以及对工具选型的建议

duck

软件研发团队越来越多使用某种开发模式（如敏捷、瀑布或其他的）并倚重工具是必然的趋势。就算是相信沟通重于文档的敏捷团队也必须使用某种软件作为其知识库和沟通的平台。多年咨询的经验告诉我们，现今软件研发公司使用工具的方式可概略分为三大类：

- x$ s+ l! e) N* L& z

1.   就用Word和Excel做最简单的管理。这种方式极易造成数据失真或文档流失，管理混乱的情况经常发生。

2.   使用多种研发管理工具，有的管需求，有的管项目和计划，有的管代码，有的管测试和发布。这个方式的问题是，工具之间数据不能相通。管理人员看不到全局，也没法有效使用数据作为其市场策略的依据。

3.    使用一个研发管理平台。如此，数据不能相通的问题多少被解决了。但团队的工作方式和需求的属性随着团队的成熟一直演变，因此工作流和需求字段也需要跟着变。大多数的工具是不能轻易解决这类问题的。所以，多数情况在用了一两年后就放弃了。

既然选择工具是早晚的事，而团队操作方法的演进又是必然的，那在选择工具时就必须具有前瞻性。也就是说，我们需要考虑到可扩展性。我认为一个软件研发平台的可扩展性至少包括以下五个方面：

1.    需求字段（属性）的可扩展 – 当需求属性增加或减少，在软件里我们要相对应地添加或减少字段。这一点基本上是不可避免的。

2.    工作流的可扩展 - 工作流的修改就在弹指之间，直接在图形界面上操作，不需要改写脚本，图形工作流保存后即可使用。

3.    研发方法的可扩展 – 我们曾看到在同一个公司有的团队是过了CMMI认证并且遵循其操作的，但偏偏有其他团队却是使用敏捷开发方法。甚至有某些团队是以达到CMMI的标准为目标，而其操作的方式却是敏捷。故工具应能同时被操作不同方法的团队使用。

4.   系统使用人数的可扩展 – 一个能被几十人使用的系统未必就能被几百人使用。这通常是由于软件系统的架构、数据库以及部署方式造成的限制。

5.    团队地理位置的可扩展 – 同一团队的成员可能分布在中国、美国和欧洲。他们平常工作时使用本地的数据库，每日一次或多次的数据集成使得他们可以共享资源，协同开发。

单单只能管理软件研发全生命周期中某一阶段（如需求、代码、测试或发布）的工具也已经过去了。现在在中国，不论使用哪一种研发方法，要的都是管理全部过程的整套工具。在这一点上中国的软件研发团队充分地表现出了后发优势。欧美的团队四五十岁的IT人员早年就使用某些功能独一的工具，他们已经不易改变多年的习性，公司也不太愿意花费巨资迁移数据。而我们的团队成员平均年纪不到三十。他们简装快行，在使用了合适的方法和高效的整套工具后，有望在未来的几年内工作效率提升几成，前景不可限量。

) D9 h: H$ j2 w& A3 M5 u6 z

“智者”能预见问题，避开问题或找到应对之道。希望我这小小的一点分享能让你成为研发工具选型的智者，少走一点弯路。让我们一起为高科技中国的未来贡献一点力量！

nut1

就用Word和Excel做最简单的管理。这种方式极易造成数据失真或文档流失，管理混乱的情况经常发生。