需求管理和变更控制的经验.docVIP

需求管理和变更控制的经验　　在学校里学计算机语言时以为，编程和架构是整个软件生命周期里最了不起的部分，但实际工作后才发现在商业产品里需求管理(包括新需求的发掘)更是一个商业软件成功与否的关键。在以下我和大家分享一点在90年代我经历的一些需求管理小故事，希望能对刚进入软件行业的精英们有点概念性的帮助。请理解在这么小的篇幅里，我们更多地只是概念性地理解需求管理的重要性而已，绝非是要提供完善的解决办法。 　　软件工程里的许多问题，诸如缺陷及资源运用不当，都是源于需求的不确定。在90年代，我曾在美国一个拥有数千员工的公司里从事大型软件开发工作。该软件主要是卖给汽车修复厂用的，它可估算出修复汽车的零件及劳力两项费用，甚至还可以找到提供新零件及旧零件的厂家。软件的的复杂度相当地高，要界定什么样的界面和功能是最适合市场的着实不易。所以，需求一变再变。在聊天时有个同事戏称：需求变更乃万恶之源!其他的人纷纷响应。当时，所有的需求都是写在Word文档里的，那些文档不是放在一个共享的服务器里，就是交由负责编写程序的人员管理。虽然没用什么管理平台及工具，但在团队成员的配合和默契下，一切事情都有序地在进展着。 　　但有一天产品经理换了个新的，一切事情似乎就全改变了。新的产品经理原是某汽车修复厂的经理，他对修汽车及车厂管理有不少的经验，但对软件的开发是很不懂的。很快地下列问题出现了： 　　(一)需求描述不清楚，导致开发任务的时间估算误差可到100%，甚至200%; 　　(二)优先及全由产品经理决定，有时不太重要的任务先做了，重要的反倒后做; 　　(三)需求变更一再发生，并且当某需求变更了，它的连锁反应会冲击其他的部分，许多缺陷因此产生了。 　　我们几个资深人员分析整个过程，发现造成问题的原因是这样的： 　　(一)我们的现有需求文档管理太乱，通常是找不到所要的版本。就算是找到要的文档，常常也没法找到要的那段内容。 　　(二)可判断任务优先级的因素颇多，可以是在商业层面或技术层面，每人的视角不同，公说公有理，婆说婆有理。 　　(三)需求文档、代码、测试用例及其他的工件(artifacts)之间应是相关联的，但在系统中我们无法从其中任一个工件找到其他的工件。 　　由于文档不全，这位新的产品经理很难在短时间内对整个系统有个概括性的了解。当他和资深人员沟通产品设计理念及历史缘由时，资深人员也没能明确地回答他的问题，这导致需求设计不完善，优先级也有误。找到原因后，我们想既然需求变更这一头凶猛野兽是杀不死的，那我们所能做的大概也就是将这兽关在笼子里，使它温驯点。为解决这问题，我们建立了以下的体制。 　　(一)细化需求的时间估算–我们将需求分解到程序员能清楚估算出完成时间的小单位，原则上每单位是可以让一个程序员及一个测试人员在二至十天内做完，而且每个单位都有个编号。 　　(二)使用版本控制系统管理需求文档–所有需求文档全保存在一中枢版本控制系统里。 　　(三)将需求分组并设优先级–所有的需求单位按照不同的版本区分开来，每个需求单位都有个优先级。 　　(四)建立工件之间的关联性–将程序及测试用例与相对应的需求单位连接上，明确地写上需求编号。 　　(五)建立评审团队–当需求产生或变更时，产品经理及干系人要一起评审，通过后才做更改。 　　我们开了好些培训会，务必保证每个程序员、测试人员及产品经理都遵照制度走。在会议室的白板上画出很多间隔，贴了满满的纸条。当然，我们也使用了Excel及一些小工具帮助我们管理需求。当年我们虽不知敏捷方法为何物，但却采用了好些敏捷操作，如站立会议等。 　　花了三个月把这个体制建立好后，团队气象一新。整个软件生产的过程严谨了许多，需求成为软件生命周期的核心。在任何阶段，需求及相对应的代码都有人负责。对需求的严格审核使得后期的修改及对缺陷的修复减少了许多，效率提高起来。 　　整体来说，当时我们所作的改进是有成效的。但我们也发现，对这体制的维护相当不易的。举例来说，需求变更的评审是需要有个流程的。但不同类型的需求要由不同组的人评审，甚至有些是外部修车厂的人员。更糟糕的是，评审流程也随需求种类的不同而不同。我们将流程写在文档里，但流程图及相关的人员经常在变动。我们不仅需要有专人来维护，有调整时还要开会通知，费力且常发生错误。 　　另外，在大系统里需求变更所产生的连锁反应是相当可怕的。曾经有一次，我们根据需求的变更找到了出现问题的某些代码，非常高兴地把代码改了，以为问题得到了解决。但不久，客户反馈我们在另两个地方发生错误。(实际上恐怕还不止两处呢!)我们把这两处改了后，又发现这些修改造成了更多其他多个问题。在代码的层面这可以是因软件代码的耦合。但它不仅是在代码的层面，更可能是在商业逻辑的层面。比如说，某公司在同一领域发展了三个互补性的软件产品。这三个产品可能