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

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




　　　确定被“弹性分工”的员工需要可以快速地转换到新　



的角色，但首要考察的并不是他是否“有能力”胜任这个　



角色。能力可以通过学习来增强，而角色的转换，则首先　



是思想的转换。　　



　　　　　



　　　1997　　年，P&J　的公司打算全面拓展市场，我随他一　



起到了成都。当时我是开发部的三个主力开发人员之一，　



因此在原定计划里，我是到成都组建西南区开发部（或技　



术中心）　。然而在两周之后，P&J　　　　　发现总公司的运作存在　



问题，因此他必须回郑州。P&J　　决定将成都市场的问题全　



权交给我，换而言之，我必须出任成都办事处经理。　　



　　　我对市场一窍不通，也不懂得公司的经营与管理。但　



很明显，做办事处经理不是做技术，这与我（　当时的）个人　



意愿是相背的。于是我拒而不受。理由也很充分：我不会　



做市场。　　



　　　P&J　用了两天的时间来说服我，直到在临回郑州的前　



一晚我仍未能接受这个任命。这时他告诉我：即使是做开　



发，也是需要了解市场的，你必须知道用户想要什么，你　



必须理解你的客户。因此你如果想要做一个好的开发人　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…41


…………………………………………………………Page　46……………………………………………………………

第　3　章　　　团队缺乏的不只是管理　　



员，你应该正视这次机会。　　



　　　　我沉默了许久。我想明白了两件事：从公司的角度上，　



我必须接受这个职务；从个人的角度上，我需要接受这个　



职务。于是，我问了我的第一个问题：“什么是增值税发　



票？”　　



　　　　P&J　笑了。接下来我们开始讨论经营问题。第二天　



P&J　　飞回郑州。五个月后我升任西南区总经理，一年后，　



西南区做到六个分区市场中业绩第二。此后我辞职回到郑　



州，再一次从开发人员做起。　　



　　　　　



　　　　“什么是增值税发票？”意味着从技术到经营的角色　



转变。这个问题本身带来的并不是能力的提升，但如果我　



提不出这个问题，我将没有可能理解经营与市场。　　



　　　　　



　　　　尽管弹性分工非常有效，然而真正做弹性分工却并非　



易事。蚂蚁的角色转换是本能的，而　P&J　　　　　　　　　　　　　却不得不花两　



天时间来说服我。因而更应当留意团队成员“自激”式的　



角色转换，知道他是不是真的想（而不是需要）转变一下角　



色，这样起码可以省去你两天的功夫。　　



　　　　然而能提问“什么是增值税发票”的愚公毕竟不是太　



多，大多数时候他们在“箕畚运于渤海之尾”，如果实在　



闲得厉害，他们可能会去发明翅膀，而不是思考“什么是　



增值税发票？”　　



　　　　　



　　　　更好的选择是明确分工，而不是弹性分工。你应该明　



白，重要角色的更替通常是极具风险的，例如项目经理或　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…42


…………………………………………………………Page　47……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



者开发经理；频繁的开发人员的调度也会直接影响到工程　



的质量和进度。　　



　　　　　如果所有人都在思考“什么是增值税发票”，那么你　



的组织机构将立即溃散。　　



　　　　　　



　　　　　因此，明确分工是你的管理职责。做管理≠做伯乐。　　



　　　　　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…43


…………………………………………………………Page　48……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　



　　　　　　　第4章　　流于形式的沟通　　



　　　　　“足下求速化之术，不于其人，乃以访愈，是所谓借　



听于聋，求道于盲。”　　



　　　　　　　　　　　　　　　　　　　　　　　　——唐·韩愈《答陈生书》　　



1。　　客户不会用　C　，难道就会用　UML　　吗？　　



　　　　我们总是要先接触客户的，是的，如果不这样，我们　



将无法确知要做什么。　　



　　　　作为开发人员，可能更希望客户能学习或者精通　C　



语言，这样客户就知道开发人员正在做什么，以及有多么　



地勤劳。或者，这样的客户还能以　C　　　　　　　　　　　　　　　语言的方式告诉开　



发人员他们究竟想要什么。　　



　　　　然而要求客户学习　C　　　　　　　　语言明显是自杀式的行为。在　



客户（　的代表）　学会用　C　语言来向开发人员描述他们的需求　



之前，可能他就已经被老板开掉了。因此没有客户会笨到　



愿意用　C　语言来描述他们的需求。　　



　　　　　　



　　　　C　语言是程序员与计算机交流的语言，而不是他与客　



户交流的语言。程序员面对的是计算机，但计算机不是客　



户。　　



　　　　因此在前面所提到的　R　　　　　　　　　模型中，开发人员最好不要　



　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…44


…………………………………………………………Page　49……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



直接面对客户。项目经理有这样的一种优势：他可以不用　



了解　C　语言，也可以用一种非　C　　的语言来与客户交流（　比　



如说汉语）　。　　



　　　　——或者你更愿意开发人员尽早地进入状态，那么你　



可以让开发人员以需求调研的身份出现在客户面前。但　



是，请注意这个人员的角色将变成“需求调研”，如果他　



不能适应这种转变，那就别让他去。——那会是灾难的开　



始。　　



　　　　　　



　　　　要深入项目的需求阶段的项目经理或者调研人员，被　



要求深谙项目所涉的业务。但这往往我们所做不到的，因　



为我们是软件公司，而不是做这些（客户的）业务的公司。　



这时惯常的做法是聘请行业咨询公司（　或者个人）　来介入　



需求阶段，协助了解和分析需求。　　



　　　　他们总是很喜欢把事情搞得很复杂，所以他们会说这　



一切的过程有个专用名词，“En。。。　这叫需求建模”他们很　



专业地说。　　



　　　　　　



　　　　现在你应该发现了差距。比如我们的项目经理，以及　



那个被调来充当调研角色的程序员，他们就不会什么“需　



求建模”。　　



　　　　　　



　　　　接下来咨询公司会与我们的客户一起做业务建模，然　



后再做业务到需求的映射，再抽取需求并完成需求建模。　



他们做业务建模的时候，可能使用一些客户业务范畴内的　



符号和标识；而在做需求建模时，则需要使用一些软件行　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…45


…………………………………………………………Page　50……………………………………………………………

第　4　章　　流于形式的沟通　　



业中（　的设计和分析人员）　习惯的符号和标识。　　



　　　　这些符号和标识也有个专用名称，“En。。。　这个叫模型　



语言（ML）　。”他们无时无刻不在向你展现他们的专业（这已　



经是他们还存在的唯一原因了）　。　　



　　　　如果他们更加专业，他们会告诉你他们用的是　UML　。　



向你介绍这个名词的时候，他们的眼镜或者眼睛里通常将　



大放异彩。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　①　

　　　　UML　是模型世界里的世界语　　。　　



　　　　　　



　　　　到现在为止，你应该看到，咨询公司除了把问题搞得　



更加复杂之外，他们仍然需要面对最直接的问题：与客户　



如何交流？　　



　　　　他们的解决之道是模型语言。　　



　　　　　　



　　　　有什么差别吗？　　



　　　　程序员不能要求客户会　C　Language　，难道需求分析师　



们就能要求客户会　Modeling　Language　　吗？！　　



2。　　项目文档真的可以用甲骨文来写　　



　　　　独　孤　木　（http：//javaworld。。tw/）　　曾　经　在　一　篇　



　《UML；　OOAD　and　RUP　》中讨论到　UML　　实际应用中的问　



题。其中的两个问题是：　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

①　　　现实的情况未必如此。但UML　这个名词起码显示了它本源性的　



期望：Unified　Modeling　Language（　统一模型语言）　。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…46


…………………………………………………………Page　51……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



　　　　）　　　　“大部分的使用者，以及客户的信息人员，其实　



　　　　　　　　并没有足够的能力，来确认这些文件（User　Case）　



　　　　　　　　的正确性与完整性。”　　



　　　　）　　　　“除了客户不了解UML　，OOAD　　跟　RUP　　　以外，　



　　　　　　　　另外一个更糟糕的现象就是　project　　team　　　里面　



　　　　　　　　的人也不懂。”　　

　　　　　　



　　　　这实在是很有趣的事。　　



　　　　看来在一些情况下，在项目中使用　UML　　只是完全不　



懂的老板，以及什么都懂的博士的主意，而真实的场景中　



去做事的那些客户与项目成员，其实是未见得就能用好　



UML　　的。　　



　　　　　　



　　　　仅以　UML　　的　User　　Case　　来说，由“用例图”和“用　



例规约”组成。规约跟我们写的需求说明书差不多，不过　



更加细节罢了，而且还有一套相应的方法论来阐述如果去　



实作。图则很简单，就是几个图形符号来描述系统边界和　



角色关系。　　



　　　　显然甲骨文也能描述范围与关系。例如甲骨文中的　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　①　，这个边界就定义　

　“家”这个字，就是上有房子下有猪　



得很好；在古文中，“三”通常是泛指，跟UML　图中的线　



条上标注的那个“*　”是同义的，而甲骨文中“众”这个　



　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

①　　　至于是“内有猪”还是“下有猪”的问题，不是我们要争论的。　



有些考古学家根据甲骨文的象形来认为古人与家猪是杂居的，但　

我想那时的猪可能还比较野性，因此这种可能性还是小些。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…47


…………………………………………………………Page　52……………………………………………………………

第　4　章　　流于形式的沟通　　



字，就是日字下立有三个人，也就是在同一个日头下做事　



的很多人即为“众”，这个关系也描述得很确切。　　



　　　　　　



　　　　所以只要你运用得法，甲骨文一样可以用来画用例图　



和写用例规约。同样的，只要约定一套“语法”，你同样　



可以用甲骨文来做活动图、类图、构件图……以及这些图　



相关的规约。相比来说，古巴比伦人使用的楔形文字“象　



形性”差一些，因此我不建议用它来画用例图。　　



　　　　既然甲骨文可以用来做为一种模型语言（　同时它也是　



一种文字和口头的语言）　，那么，如果你的项目中面对的　



对象是商周文化的考古学家，以及你的项目组都由精通这　



种语言的成员构成，这时你就可以用甲骨文来做项目文　



档，以及画各种模型图例。　　



　　　　　　



　　　　你要明白，要让考古学家看懂用例图，难度远大于看　



懂甲骨文。与其要求他们学一种语言，不如使用他们那个　



世界的通用语（　当然，前提你的项目组也懂得这种语言）　。　　



　　　　　　



　　　　在韩愈的《答陈生书》中，他因自己不会“速化之术”，　



所以说陈生是“求道于盲”。然而他用了一个不恰当的比　



喻：要知道盲人并非不知道路如何走，只是他不能象常人　



一样描述他所知道的路。因此“问道于盲”是没有错误的，　



真正错误的是你睁着眼睛问。　　



　　　　我们需要在正常人与盲人之间建立一种沟通的方式，　



既然盲人不能睁开眼睛，那么你就闭上眼睛好了。　　



　　　　　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…48


…………………………………………………………Page　53……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



　　　　UML　　图在一些客户眼里无异于盲人的世界，如果需　



要向他们做需求调研，你只能使用一种这些客户能够理解　



和接受的方式，例如表格、流程图以及……更深入的交谈。　　



　　　　你要确认你的沟通方式是否有效，而不是去追求这种　



方式是不是　UML　，以及用　UML　表达得是否正确。——客　



户是因为他认为你理解了他们的需求，而在“需求确认书”　



上签字，而不是因为你的　UML　　画得是否精准。　　



　　　　　　



　　　　现在来思考：为什么非要让客户看UML　图呢？如果　

有能够满足“极限编程（XP）　”所要求的“现场客户①　”，那　



当然可以不画用例图；相反，如果客户雇了一个专家组来　



评审需求，那么你就老老实实地画用例图好了。　　



　　　　需要留意的是，专家组还要一种方式与客户沟通，这　



有可能不是　UML　。——当然，客户愿意增加沟通成本，　



那是他们的事。　　



　　　　　　



　　　　一旦源头确定，你就可以接下来约定在项目组中要使　



用的沟通方式。愚公——这个伟大的项目经理——所使用　



的“聚室而谋曰”，就是很好的沟通方式。当然，如果客　



户精通　UML　，那么我想愚公采用的项目沟通方式将会是　



　“聚室而论UML　”。我想一定会这样，因为愚公是很懂得　



沟通的、伟大的项目经理。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

①　　　这是极限编程的特征之一，指的是要求客户可以在程序员开发　



的第一现场，随时可以向程序员确认完成功能的有效性，以及修　

正需求或者先前的需求描述。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…49


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

第　4　章