1.3 方法论与需求工作

在进一步阐释软件需求之前，我想简要谈谈一个合格的需求分析员应该从什么角度来理解方法论，从而更好地勾勒出需求分析员的工作视角。软件行业是一个新技术、新思想层出不穷的行业，诸如不同的计算模式、开发思想、软件工程方法论等。而作为一名需求分析员，应该更多地考虑方法论的适用性而非先进性。

1.3.1 计算模式

讲到计算模式，相信大家都不陌生，包括远古的“主机/终端”模式，以及C/S（客户端/服务器）和B/S（浏览器/服务器）两种现在仍然存在的模式。大家也都知道最早的C/S专指二层C/S，B/S则是三层模式的代表；而现在不管是C/S还是B/S都可以应用三层模式甚至N层模式，关键的区别就在于是使用专用客户端（C/S，也称为胖客户端）还是浏览器（B/S，也称为瘦客户端）。不过可能大家现在也注意到了，B/S计算模式也开始长胖了，增加了AJAX、Flash等技术，RIA（富Internet应用程序）也就应运而生了。而对于一名需求分析员而言，应该如何看待这些东西呢？

案例&场景：

那是2000年初的一个夜晚，一个年轻的开发团队兴奋地聚在一起，庆祝他们第一个基于B/S计算模式开发的软件系统正式上线。

可就在第二天，他们接到了无数个来自客户的电话：“我按下了后退按钮，可是回不到前一个页面，并且显示了一大堆令人讨厌的英文！”；“嘿，怎么修改程序的背景色呀，我不喜欢现在的配色方案！”；“唉，套打票据老是不准确呀”；“我离开电脑一会儿再回来就无法使用了，必须重新登录了”；“不小心点了窗口的关闭按钮，怎么一个提示都没有就把程序关掉了”……

将B/S模式应用于那些不合适的人群中时，也许并不是像你想象的那样更易于使用，而却给他们带来了巨大的操作障碍，而这一切都将转化成“客户服务申请”回报给你。我的经验是，对于那些计算机经验不太丰富而且工作比较单一的用户，也许更加固化的专用客户端（C/S模式）更加适合一些。

案例&场景：

几年前笔者有幸在为某城市规划第四方物流平台时接触到了DELL的物流部门，当我看到他们的系统仍然是黑底绿字的界面时感到万分惊讶！这就是世界500强公司的信息系统，就是以物流管理为豪的DELL！

当时接待我的主管说，这套系统的用户大多是物流专业的，系统界面与纸质报表是高度统一的，这样无须专门的培训就能够很容易地学会操作。

当技术团队们在为采用B/S还是C/S争论不休时，戴着“需求分析”这顶帽子的朋友们一定不要忘了从用户的角度分析哪种模式更加适用！

1.3.2 软件工程方法论

现代软件工程方法论大致可以分为重方法论和敏捷方法论两大阵营，在很多书籍中将它们之间的区别总结为“文档量”的重与轻，实际上有些以偏盖全！如果从对开发工作的影响角度看，它们之间更重要的区别在于：重方法论更加强调前期设计，为未来设计；而敏捷方法论则更加强调只为现在设计，未来再重构它！而就是这个最为本质的区别才是根据项目实际特点进行正确选择的基础。

案例&场景：

敏捷方法论中最具代表的是XP（极限编程），而最有名气的专家包括Kent Beck、Martin Fowler、Ron Jeffries等；但有意思的是，作为XP方法论的“实验室”，汇聚了这些专家参与的C3（克莱斯勒公司综合工资系统）项目最终却以失败告终！它在项目进行了4年之后被取消了。

这个项目启动于1996年，在1997年5月项目部分上线，实现了10 000名雇员的工资管理功能；计划1998年10月则实现另外16 000名雇员的工资管理功能， 1999年中期实现其余60 000名雇员的工资管理功能。

但最终却没有按进度完成这些承诺，而失败的导火索就是无休止的重构，而且发现“现场客户”并没有有效地发挥作用。

当然这并不意味着我认为敏捷方法论是无效的，恰好相反，我也曾有过采用敏捷方法论成功完成开发任务的经历！关键在于针对项目的实际情况做出正确的选择。例如，敏捷方法论对于业务复杂度高且相互制约的项目，对于人员规模较大（我的经验大约是30～40个内是敏捷方法论适用的极限）的开发团队而言都很可能不适用。

另外一方面，笔者认为敏捷方法论之所以被国内众多的开发团队所追捧，也是存在一些特定的原因的：

● 终于找到不写文档的理由了

● 你看，个人英雄主义是对的嘛

● 代码才是唯一有效的工作产物

● ……

敏捷方法论中的一些理念恰好成为了“作坊式”开发习惯的最好支持；这就让我想起了一位中国著名企业家和GE前总裁杰克·韦尔奇的对话，其内容大致是说韦尔奇的“无边界”管理思想在中国是不适用的，因为现在中国企业中大部分还没有清晰的边界，如果还强调打破边界就必将导致混乱，而在通用这类边界森严的企业中，适度地强调打破边界是创新之门。其中这样的思想，在Kent Beck为《规划极限编程》一书所做的序中有也体现。

隐喻

卡尔·冯·克劳塞维茨在《战争论》中指出，军事历史就是一个在装备和灵活性的相对优势之间来回摇摆的钟摆。身披鲜明盔甲的骑士相比没有盔甲的骑士有压倒性的优势，却不是那些横扫草原的行动迅速、骑着几乎没有任何盔甲的小型马的成吉思汗和他的蒙古战士的对手。而当坦克出现后，轻骑兵就注定要没落，但坦克却不是身背导弹、行动迅捷的反坦克兵的对手。

而且Kent Beck还提到：“在IT领域，我们正好都在从装备（流程）统治一切的时代走出来。现在我们正进入一个唯有灵活性至关重要的时代”。读到这里我就不禁要问，这是对中国绝大多数“作坊式”开发团队说的吗？我们是从流程统治一切的时代中走出来的吗？也许我们还是先需要用流程武装自己，然后再适度敏捷吧。

因此需求分析员应该基于对业务领域的了解，正确地评判项目的特点，为开发团队选择适合的软件工程方法论提出建议。

1.3.3 开发思想

软件开发是一个充满智慧和思想的领域，因此新东西总是层出不穷；作为需求分析员不应过多地跟风到先进性的讨论上，而应该更加重视其成熟度，尽量地对这些技术进行溯源，找到其本质，以便判断其适用性。

1.成熟度

在决定是否大规模应用某项技术之前，首先应该审视该技术的成熟度。实际上有一种很简单的方法来判断，那就是看该技术的见报率如何；如果经常在报刊、杂志、网站上看到关于它的宣传、介绍，那么它的成熟度极可能不高；试想现在还会有谁花心思写一些关于XML、UML的介绍性、宣传性的文章呢？因为这些技术已经实际地应用到工作中去了。

2.溯源

要对某种技术的作用有深刻的理解，最简单的方法就是了解它的发展历史，了解它出现的原因。例如Web Service技术，它的演变过程如图1-4所示。

通过这种思考过程就不难将各种技术串联在一起，更容易理解这些技术出现的原因，也就能够更好、更准确地应用它们。

3.了解局限性

技术并不能解决所有的问题，因此对于任何一种技术都既有优势又有不足，只有全面地了解其局限性才不至于误用、滥用。

例如“工作流引擎”技术，它的优势在于能够提供一个运行时可配置的流程顺序，从而提高了程序流程的灵活性。但是在不同流程之间的数据接口方面还是需要另外的措施。另外，流程块的抽取是十分关键的，如果新的流程破坏了最初的流程块，那么工作流引擎也是无能为力的。因此工作流的分析与抽象是基础，工作流引擎只是实现层的手段，不要认为只要引入工作流引擎就可以解决一切问题。