超越灭蟑仪――探索《探索需求》
think 著
有价值的思想不会凋谢
作者的工作主要是研究UML相关技术的应用，并指导软件开发团队如何将相关方法真真正正应用到自己的当前项目中。本文以学习笔记的方式，记录作者对《探索需求》一书的阅读心得。
【原文】
所属章节：序言
软件业——一个倍受这种毫无根据的白日梦折磨的行业。我们乐意引用约翰·冯·诺依曼的话，因为我们的许多客户认为他是软件之父。他们关注到他的名言：“如果你根本不知道自己在讨论什么，那么对其强求精确是毫无意义的。”
如果人们不知道他们想要什么，那么无论什么开发过程——不管有多么精确、多么聪明或多么有效率——都不能使他们满意。这就是为什么我们要做需求工作的缘故——只有如此我们才不会设计出人们不需要的系统。
【探索】
何止是毫无意义，简直是巨大的浪费。需求一旦出问题，越往后面做，就意味着在错误的方向上浪费的人力物力越来越多。如果有上帝在天上看到这一切，他应该会为我们这群蚂蚁而叹息吧？
正因如此，需求环节是软件公司最值得改进的环节。需求环节不解决，就象拿着好枪（面向对象分析设计）却打不中目标一样，旁观者首先怀疑的是你的枪不好、你的射击技术不好，而不会首先怀疑你的目标问题。不改善需求，软件开发的结果自然不会好，后续的改进无从谈起。
很多软件公司没有意识到这一点。即使有的软件公司意识到了，也需要面临需求的两个难题：难捕获＋易变。“难捕获”常常导致直到系统开发出来我们才真正了解客户的需要，“易变”常使开发团队陷入“需求变了！”的恐慌之中。
用例技术可以看作是朝着解决这些问题的方向迈出的一步。既然难捕获，我们就要学会从用户的视角看问题；既然易变，我们就以一种有层次的方式来组织需求――这就是用例，一种基于基于用户目标的、有层次的需求组织形式。
【原文】
所属章节：序言
美国第34任总统艾森豪威尔上将曾经说过，“计划本身什么都不是，而编制计划的过程就是一切”。我们认同这样的说法，并把它推广到需求过程：
产品什么都不是，而开发的过程就是一切。
发现什么都不是，而发现过程（探索过程）就是一切。
这就解释了我们的书名：探索需求。
【探索】
采用“用例”来代入――用例什么都不是，而探索用例的过程就是一切。
用例的发掘过程比结果还要重要。它“掀开了地毯”，迫使你去思考“系统到底是什么”的问题。在寻找执行者的过程中，迫使你去思考软件系统的边界；在寻找用例的过程中，迫使你去思考软件的价值；在书写用例文档的过程中，迫使你去思考哪些是需求（即问题），哪些不是需求而是设计（即解决方案）。
如果你有了这个过程，获得了成果。成果用何种方式表达出来，是不是按照严格的模板，并非那么重要。有价值的内容即使写在草纸上（Scott Ambler的说法是“餐巾纸”【2】），也胜过100页装潢精美的废话。
【原文】
所属章节：第1章
万无一失蟑螂杀灭仪。全部操作步骤为：把蟑螂放在木块A上，然后用木块B拍它。
以我们的经验，“分析和设计工作平台”类似于“万无一失蟑螂杀灭仪”里的木块A。“代码字典”类似于木块B。
本书就是关于你的那部分工作：将蟑螂放于木块上，并在你突然拍打之前让其保持立正。
不管是蟑螂还是需求，难点在于抓住它们并使其立正。与前两个步骤相比，不同的是生成代码和清理被压碎的蟑螂尸体是琐事。
【探索】
开发人员往往假设“蟑螂已经抓住”。
有开发人员说，“系统类已经提供很好了，只有一点点没有，我不知道我还能做什么”――其实，正是这一点点要了你的命。在现在这个不需要重复去造轮子造砖的开发时代，“这一点点”才是你真正要花时间去搞明白的东西。
“开发人员通常在几天内完成90%，一个月内完成95%，6个月内完成99%，然后在12个月内另谋高就，留下‘已完成99.9%’的工作。”【3】
有开发人员问，“使用用例技术，要思考的东西比以前多了很多，会不会影响进度？”还有开发人员质疑迭代式开发，“这不是自找麻烦吗？按照我们以前的方式，需求，分析，设计，编码，一切按计划进行，不用修改”。――如果以“可运行”作为指标，这些质疑确实有道理，甚至这些表面功夫都可以不用，把微软或Sun的样例改改，改成你的系统的名字，就OK了。
超越灭蟑仪，就是超越“可运行”的目标，朝着“可用”的目标进发。
比起故障频频的软件，鸡肋软件（可稳定运行，但无价值）的危害更大。用也不是，不用也不是。“业务工人”【4】们每天上班8小时对着这样的鸡肋，实在是一种身心的摧残。
中国也有和书中类似的笑话：
“你的万灵虱子药怎么用啊？”
“先把虱子捉住，然后抹在它嘴上”
【原文】
所属章节：第1章
这就是为什么我们认为，即使你使用了万无一失的CASE和CAD工具，你还是需要本书所讲的工具。不仅如此，你的CASE工具越好，你就越是需要本书所讲的工具。
【探索】
开发人员问，“开发平台提供的框架已经很完善，大部分工作已经做了，我不知道该做什么？”
人做人的事，工具做工具的事。
工具使人解放。工具帮助你从琐事中解脱出来，把更多的精力放在核心问题上。数学公式之于数学家，五线谱之于音乐家，UML之于软件开发人员，都是如此。模型转换、代码生成，现在又要朝MDA进发。它们不能解决和人相关的问题（如：需求获取、概念抽象…）。但我们有理由希望它们能帮助我们解决除此之外的各种问题，即书中的“清理被压碎的蟑螂尸体”等琐事。
你的工具好，恭喜你，同时也要提醒你，新层次的挑战来了。以前可以抱怨工具的理由如今已经不存在，你需要更加集中精力去面对真正的问题。――这也就是Weinberg说的“你的CASE工具越好，你就越是需要本书所讲的工具。”――更贴切地说：你的工具越好，本书的工具在你的软件开发工作中所占的比重越大。
（待续……）
【1】《人月神话》，Fred Brooks Jr. ，清华大学出版社，2002。
【2】《敏捷建模》，Scott W. Ambler，机械工业出版社，2003。
【3】《特征驱动开发方法原理和实践》，Stephen R. Palmer 等，机械工业出版社，2003。
【4】Business worker。《软件复用：结构、过程和组织》，Ivar Jacobson 等，机械工业出版社，2003。
本文地址：http://com.8s8s.com/it/it37107.htm