软件工程实践者的思想(PDF格式)-第7部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！



…………………………………………………………Page　54……………………………………………………………

第　4　章　　流于形式的沟通　　



3。　　最简沟通　　



　　　在　D　　项目中，我向我的项目组员提出在需求阶段与　



客户的沟通计划。这个计划只有三条：　　



　　　）　　在一个月中，只能跟客户作三次联系；　　



　　　）　　　三次联系中，最多只能有一次面谈的机会；　　



　　　）　　　一个月后，提交全部的需求调研报告、需求分析　



　　　　　　　和关于该项目的远景规划。　　

　　　　　



　　　D　项目并不大，所以从主观上来讲，客户（代表）　并不　



会为这个项目投入太多的精力。重要的是，我们在前期交　



涉中已经发现：这个客户代表为大量其它的项目和工作所　



困扰，他不会有时间来处理我们的问题。因此，减少沟通　



和保障沟通质量的问题就显得非常突出。　　



　　　在大多数的项目中，这样的问题都是存在的。真正能　



满足极限编程（XP）所提出的“现场客户”的情形并不经常　



出现。即使能将程序员送到客户现场中去，沟通问题仍然　



是不可避免的。　　



　　　因此在　D　项目中我提出了“最简沟通”。　　



　　　　　



　　　我们开始在网络上查看相关的软件系统的特征以抽　



取客户所关注的内容；了解该客户的公司、经营理念、组　



织结构形式以及工作模式；了解同类公司的成功经验和优　



秀的管理模式，以及客户的竞争对手在做什么和在关心什　



么……　　



　　　最后，我们开始综合以下两个方面的因素：　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…50


…………………………………………………………Page　55……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



　　　）　　客户在公司层面的外在表现、内部机制和运营管　



　　　　　　理手段。　　



　　　）　　客户在项目中既已明确的需求和可能发生的需　



　　　　　　求，以及客户围绕其公司行为（和方向）所提出的　



　　　　　　需求。　　



　　　这样我们就了解了客户项目中所有会产生需求的信　



息点。　　



　　　我们开始设计提问，每一个提问涵盖尽可能多的信息　



点，尽可能的具有发散性以便形成更多的推论和假设。　　



　　　我们把这些做成项目概要用　mail　　　　　提交给客户，并在　



第二天电话回访他。他以口头的形式回复了这封　mail　，这　



让我们尽可能地得到了项目在方向上修正。　　



　　　　　



　　　我们确定了项目的实际目标，以及远期的方向。接下　



来就是设计需求条目。　　



　　　客户已经先期提供了一些关于项目的文档、报表和工　



作数据。因此基于这些数据的需求分析，将是下一个沟通　



前所进行的最坚苦的工作。项目组员被要求：　　



　　　）　　分析用户的每一个表格，以构建基础数据库；　　



　　　）　　分析每一条数据的含义以确定它的上下限，以及　



　　　　　　数据间的相关性；　　



　　　）　　从工作文档中去了解客户的组织机构及其相互　



　　　　　　关系，同时确定了每一类使用该系统的角色；　　



　　　）　　从报表中去了解客户关注的数据信息，以及被他　



　　　　　　们所忽略掉的数据信息。　　



　　　我们从数百条的需求条目中，整理出系统结构和模　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…51


…………………………………………………………Page　56……………………………………………………………

第　4　章　　流于形式的沟通　　



块，需求条目被映射到各个模块。我们很快画出了模块间　



的相互关系图，并通过这个图分析了数据交叉关系，设计　



了相应的数据索引并增加了一些新的关系性数据。　　



　　　　我们对用户角色、原始数据和系统结构进行了梳理之　



后，我们花了很短的时间实现了第一个系统模型。当然，　



很多的功能项目，我们都只是简单　show　a　dialog　。但我们　



优化了每一个操作流程，以保证不同的用户（角色）在使用　



时都尽可能流畅。　　



　　　　　



　　　　这一次的沟通我们使用了面对面的模式。我们很庆幸　



的得到了与这个系统的每一类用户（角色）接触的机会，而　



正好我们有一个模型，我们便让他们来操作并提出意见。　



这一次我们终于有了一份详尽的的调研报告。　　



　　　　　



　　　　接下来的分析设计是顺理成章的事。我们在一个月后　



完成了这个项目的需求分析报告，以及在这个分析上的一　



些框架型的设计。还有，一个被用户所接受的原始模型。　　



　　　　——尽管，第三次的沟通中还发现了一些问题。但我　



们终于有了一个好的开端。　　



　　　　　



　　　　应该清楚的是，保障每一次沟通的有效性都是最重要　



的事。沟通不是打电话或者请客户吃饭那么简单的事。你　



得到的每一次沟通机会，都是向客户了解更深层次的需求　



的机会，因此最好在见到客户之前，你就已经设计了所有　



的问题和提问方式。　　



　　　　吃饭并不是有效的沟通。大多数时候，那将以酒醉收　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…52


…………………………………………………………Page　57……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



场。　　



　　　　　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　



4。　　为不存在的角色留下沟通的渠道　　



　　　　大多数人不会知道，我们中国的“五千年文明史”实　



际上仅有三千年“有史可查”。　　



　　　　司马迁在史记中写道：“维三代尚矣，年纪不可　



考，……于是略推，作三代世表”。也就是说，他在写史　



记时“（夏商周）三代”的年代已经不可考了，因此只能做　



　“世表”；而其后十二诸候国的年代才可考证，因而有“（十　



二诸侯）年表”。　　



　　　　世表和年表的准确性和可靠性有明显的差异，因此我　



国古代编年史能追溯到的上限，就成了《史记·十二诸侯　



年表》中记载的西周共和元年，亦即公元前　841　年。　　



　　　　司马迁无法做夏商周三代的年表是因为其年代不可　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…53


…………………………………………………………Page　58……………………………………………………………

第　4　章　　流于形式的沟通　　



考，这是因为自黄帝以来的许多文献材料部分虽有年数，　



但比较模糊且不一致，所以他只能弃而不用。　　



　　　　现在国家在“夏商周断代工程”中再次推算和考证编　



年史，这些相关资料也同样只做参考，实际采用的方法是　



更有可信度的金文（记载）　、历史学、天文学、碳…14　　　　　　　　　　　　　　　　测年　



等。　　



　　　　资料的缺失、及其有效性的缺乏，给中国编年史撰写　



带来了莫大的困难。　　



　　　　　　



　　　　项目的中断和中止，与历史产生断层的内因是一致　



的。——我发现很多的项目（尤其是产品计划）在负责人员　



离开后，就自然而然地死掉了。我把这一切的原因归咎于　



　“没有history　”。　　



　　　　　　



　　　　在先人写“谱牒”（简、册）　时想必是没有考虑过后人　



要读的，或者更为远古的先人可能根本没想过要留下他们　



的生活和部落记录，再加上有象秦始皇这样的人在前面放　



火烧东西，所以司马迁拿不到夏商周三代的确切史料，也　



是情理之中的事了。　　



　　　　——远古的先人不知道司马迁这一号角色的存在，司　



马迁也没有办法跟古人约定一下要留点记录给他写《史　



记》。　　



　　　　　　



　　　　我　们　做　项　目　的　时　候　，　如　果　也　不　留　下　历　史　记　录　



（History）　，那么以后别人来看这个项目，也会是两眼一抹　



黑，要么就象司马迁一样“存而不论”，项目便就此中止；　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…54


…………………………………………………………Page　59……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



要么就象“夏商周断代工程”一样，花大量的人力物力来　



攻关。　　



　　　维护旧项目比做新项目更难，许多人深有同感。然而　



这些“有同感”的人又何曾想过，自己在做“新项目”的　



时候，要为“项目维护”这种还不存在的角色，留下一个　



沟道、对话的渠道呢？　　



　　　　　



　　　我把项目的　History　　作为跟这种“不存在的角色”沟　



通的一种方式。History　　的丰富和准确为项目的后继开发、　



维护提供了可能。　　



　　　　　



　　　历史记录（History）　与注释（ment）不是一回事。代　



码中的注释是为阅读代码而留备的，而　History　　是为整个　



项目而记录的。一些参考的记录内容有：　　



　　　）　　　需求阶段：与谁联系，联系方式、过程、结果以　



　　　　　　　及由此引发的需求或变更；　　



　　　）　　　设计阶段：如何进行设计、最初的构架、各个阶　



　　　　　　　段的框架变化、因需求变更导致项目结构上的变　



　　　　　　　化（有助于了解构架的可扩充性）　；　　



　　　）　　　开发阶段：每一种技术选型的过程、每一种开发　



　　　　　　　技巧的细节和相关文档、摘引的每一段代码、算　



　　　　　　　法、开发包、组件库的出处和评测；程序单元的　



　　　　　　　测试框架；每一个设计和构架变更所导致的影　



　　　　　　　响；　　



　　　）　　　测试阶段：还记得测试用例和测试报告吗？那是　



　　　　　　　最好的　history　之一。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…55


…………………………………………………………Page　60……………………………………………………………

第　4　章　　流于形式的沟通　　



　　　　当然，另一件最重要的事，是记得在每一笔记录后写　



下时间和你的名字。你的每一笔记录都是打算留给一些根　



本不了解这个项目的人看的，之所以要记下你的名字，是　



便于那些人能够再找到你并溯源到问题的源头。——当　



然，这得赶在你和古人一样“与天地共存”之前。　　



　　　　　　



　　　　我们知道，大多数的工具都有历史记录的功能。在开　



发工具和测试工具中尤为突出。此外，版本管理工具也留　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　①　

下了每个阶段的印迹。然而，我不建议过于信任它们　　，　



如果不明确要求项目组员写下详细的History　，那么他们可　



能在每一次版本签入时都只写下两个字的备注：“完成”。　　



5。　　流于形式的沟通　　



　　　　在很多的时候，我所听到的沟通，都是一种形式。例　



如与客户吃饭或者打回访电话。　　



　　　　其实沟通是具有目的性的，如果在没有明确目的的情　



况下与客户沟通，那将是浪费客户和自己的时间。这种目　



的，可以是了解项目的讯息、挖掘潜在的项目……最末了，　



才是交流感情。　　



　　　　然而大多数的情况下，它仅仅被看着交流感情。这便　



　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

①　　　大多数的软件公司已经意识到版本管理的重要性。然而项目各　



个阶段的文档、代码及其它输入输出都是具有版本问题的。单一　

的版本管理软件并不能胜任这些。因此我仍旧采用相对原始的、　

编写History　这样的方法，来弥补ClearCase　、SourceSafe　、CVS等这　

些软件的不足。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…56


…………………………………………………………Page　61……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



成了形式。且往往是客户所讨厌的一种形式。　　



　　　　　



　　　沟通问题不仅仅存在与客户交流之中。还存在于与项　



目的各个角色之间。项目的分析报告为设计人员所看不　



懂，设计人员的方案为开发人员所看不懂，而开发的结果　



以为测试人员所看不通。等等都是沟通问题。　　



　　　UML　　的确是解决沟通问题的最佳手段之一。然而如　



果项目一开始就不能用它，那么强求的结果必然是痛苦　



的。——要让　UML　在一个没有经过相关培训的团队及其　



各个角色之间用起来，几乎是不可能的事。即使用得起来，　



也存在经验问题。千万不要指望仅仅一个项目，就能让你　



的组员深刻的理解　UML　　的思想。　　



　　　也不要指望在每个项目中都能用它，如果你的客户能　



理解并支持使用　UML　，那以这个项目就会有一个良好的　



UML　使用环境。否则，开发环节中资料的不一致性，将　



会使得项目难以收场。　　



　　　使用与不使用　UML　，其根本的问题在于沟通方式的　



选择。只要是行之有效的、能在各个项目角色间通用的，　



就是好的沟通方式。　　



　　　　　



　　　在每一次回顾项目时都应该注意：流于形式的沟通，　



可能是使得你的项目被不断推翻和不断延迟的最直接原　



因。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…57


…………………………………………………………Page　62……………………………………………………………

第　4　章　　流于形式的沟通　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　

　　　　　　　　　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…58


…………………………………………………………Page　63……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　



　　　　　　第5章　　失败的过程也是过程　　



　　　　　　　“虚有其表耳。”　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《明皇实录》　　



　　　　　1。　　　做过程不是做工程　　



　　　　　软件工程这个概念被提出的时候大概是在上个世纪　



60　　年代末。它作为成熟的概念的标志是软件工程的瀑布　



模型的提出。瀑布模型将软件开发