| UML软件工程组织 | |||
| |
|||
|
|||
软件工程师的软技能
作者：Gary Pollice, Professor of Practice,
伍斯特工学院 来源：IBM
本文内容包括: 本文来自于 Rational Edge：在那些组成软件开发团队的个体成员中，你认为哪些技能是有价值的？让我们来看一下一位现今是大学教授的软件业的老手，是如何将从学术环境中得出的技能成功运用到“现实世界”的实践中的。 我已经考虑过我会如何回答这一难题，而且我愿意与大家分享。从许多方面来看，在学校里为软件工程评分好比对业界软件开发者的成绩进行评价。 我们教育者在为软件工程作业评分上所遇到的一些难题来自我和其他一些人之前所讨论过的一些事情。软件工程不同于其他类型的工程。 1 如果我参与到一个土木工程－－或者其他已确定的工程－－课程，那么我学到的是掌控我所操作领域的基本物理规律。我学到的是已经被数学推理和实际经验所证明的公式。教员们提出一个问题，我用一个在理论和实际上都合理的知识体系来解决它。通常这一问题只有一个正确的答案。 而软件工程并非如此。当我在为软件工程作业的评分时，我觉得自己更像是一个人文学科的教授在为散文评分，而不是一个自然科学和工程的教授在为测试评分。我通过一些软标准来评分，对于我的学生们来说，这好像是纯粹靠主观决定。有问题的部分是我很难能够提供在评分时用到的标准的精确定义。我想这一现象在我的同事教授软件工程时也是普遍存在的。 在我看来，困难就是对于我们研究的和指定给学生的大多数问题没有权威性的、规范性的答案。事实上，有些问题可以很清楚的给出一个正确或者错误的答案，而大多数还是无法如此清楚的进行界定的。 让我们来看这样一个例子，一个问题既有准确的答案又有模糊的答案。对于这学习我的面向对象的分析与设计课程的第一个家庭作业问题是要求学生们扩展一个由 RemoteButton 类和 DoggyDoor 类组成的简单软件应用程序。狗的主人按一个按钮，门就持续打开5秒钟。作业是要增加吠声识别功能，使得当狗叫的时候，门持续打开5秒钟。此外，他们需要描述他们的设计决策并发现潜在的问题以及他们的解决方案。最终，他们还要提供一个描述解决办法的类图。 这一问题的简单解决方案如图1所示。我们增加一个新类与吠声识别硬件接口，以控制门的打开方式。这是一个立即可用的解决问题的完美方法。 图2展现的是一个完全不同的解决方案。采用这一方法的学生强调她引用了不重复自我(DRY)的原则来解决问题。按钮和识别器都需要开门，因此她将这一行为打包放在抽象的 DoorActivator 类里。
这两种解决方案哪一个是正确的呢？其中一个确定比另一个好吗？这些问题不是一下子就能回答的，这些问题能够引发很大的争论。这些问题值得讨论，因为如果问题能够被参与者相互探讨，可以产生对于不同设计理念和技能的深入理解。但是这两个学生应该因为他们的设计而得到不同的分数吗？ 在我尝试为这些解决方案评分时，以下是我的分析。首先，两种解决方案都有效。第二个解决方案需要硬件发送 openDoor 信息到适当的目标。如果你没有对硬件的控制，这可能是个问题。你将必须在 BarkRecognize 上增加一个方式，例如，一个适配器。在这种情况下，第一种方法要好一些。 两种解决方案都是清晰易懂的。第二种设计对于需要未来扩展的某些类型来说可能更好一些，可以增加其他一些驱动程序将门打开。第一种解决方案略显简易，只是一种仅能解决眼前问题的快捷方法。 2 作为一个老师，我不得不提出疑问：“其中任何一个解决方案应该比另一种得分少吗？”我选择都给他们满分。 其他一些解决方案容易发现一些不足。我的一些学生倾向于使用统一建模语言(UML)的图表，但是他们错误使用了标记或连接器。自从我们使用了能够将代码反向工程成为类图的工具以后，这一点就令我尤为困扰。即使他们不选择方向工程，这一工具也使得选择一个正确的连接器变得十分容易。在我的课上我并不强调使用 UML，但是我的确希望学生们能够利用这些工具创建正确的图表。 作业中容易评分的另一部分是他们提供的覆盖所有代码的 JUnit 测试的需求。所有的学生使用 Eclipse 平台来开发代码，当 JUnit 测试运行时我们使用 Coverlipse 插件程序来收集代码覆盖统计数据。 3 对于评分者来说在 Coverlipse 下运行测试并决定是否有100%的代码覆盖率是十分容易的。图3中显示的是在一个解决方案中通过运行测试产生的覆盖数据。所有那些没有100%覆盖的文件是正运行良好的测试文件。那些属于问题解决方案的文件都被100%覆盖了。作业的这个部分应该得满分。
但是仍然必须认真地检查这些 JUnit 测试以确保它们是真正良好的测试。一个最容易被忽略的测试是被设计用来确保系统在下面的情况能正常运转的测试： 狗叫了，门打开（持续5秒）。 作业的剩余部分给我提出了评分的另一难题。学生们必须考虑可能出现的问题并考虑如何解决。在他们写的东西里我寻找合理的、有创意的观点，又一次没有正确答案。他们应该考虑因邻居的狗叫打开门而让它从后院进入的情况吗？当狗正进出时门关闭的情况又如何呢？如果出现故障将会发生什么？所有这些事情都是他们应该考虑到的。如果他们没有按我所想的复杂因素那样进行类似的组合，他们就错了吗？谁又能说我是正确的？ 显然，至少对我来说，有许多很好的但可能不是最佳的答案。我和我的那些为这些作业评分的教学助理们必须运用我们从经验中获取的判断，来公正地为学生们评分。 我想指出我在为学生们评分的一个地方，是他们中许多人都不喜欢的一点。如果他们犯有拼写或者严重的语法错误，他们将会因此失分。他们必须学会很好地沟通，我在最开始的课上就明确提出过这一点。 我刚刚描述的是我最近在 OOAD 课上的一个例子，是我的软件工程学系列中的第二部分。第一部分是大多数计算机科学专业在第二年或第三年要修的软件工程学课程。因此，在软件工程学课程中，学生们还没有学 OOAD 班上的学生们所知道的大部分设计理念。评分便更加困难，通常更为主观。 典型软件工程学课程应该侧重于为学生提供在团队中有效工作、进行迭代开发以及交付工作软件的技能。 4 我所期望的这些目标和成果中许多是相当 软的。 在软件工程学中我给学生们的第一项作业是写一个简单的程序，但让学生们成对地工作（例如，尝试成对编程）。作为作业的一部分，他们必须写一些简短的文字描述他们在实践中的经验，不管他们是否认为那有助于他们开发更好的软件，并要维护他们的立场。在智力挑战层面上这一工作与他们将在 OOAD 课上面对的东西联系并不密切，但是它为团队协作奠定了基础，这是一个主要的学习目标。 你将如何为这个作业评分？很显然，如果程序不能运行，将是一个问题。但是那是一个学生们缺少技术知识的问题还是成对编程的问题呢？当目标是使他们尝试一个新的实践并引发对它的思考时，放在代码上的份量应是多少呢？我选择将大部分评分重点放在他们在双成对编程中得出的经验报告上。我在他们的介绍及慎重考虑后得出的论点和结论中找寻思路。关于成对编程是好是坏没有明确的答案，因为它取决于个体和成对的技能；但是正如一个好的论点和合理的论证一样，不完善的逻辑或是一个不好的论点很容易被看出来。 软件工程学课相对于 OOAD 课程来说作业较少。那是因为软件工程课的长期课程项目比他们所遇到的任何课程要庞大得多，从而在学术道路上更为长远。团队通常由十到十五名学生组成，所以他们花费大量时间学习协作技能。这种协作对于那种习惯了自然科学学科课程的学生来说是非常难的。 项目在评分占有三分之一的价值。我的教学助理和我一起讨论团队和他们的相互作用。在一个学期里作为一个或者更多团队的导师，我们尽力训练他们的开发协作技能，注意观察学生个体和他们之间的相互影响。这些观测报告是我们用来为他们评分的十分重要的部分。 十分有趣的是，最好的技术项目通常不是由得分最高的团队开发出来的。典型代表是，有着较好技术解决方案的团队动力很弱，通常是因为一个学生掌控整个团队而且只按照自己的方式去做。而这个自作主张的领导者并不是唯一一个应承担责任的人；放弃努力并让这个“英雄”按照自己方式去做的团队也有过失。我们看到了一个人的英雄成果，但同时也看到了一个涣散的、失败的团队，这个团队的成员们已经失去了开发软件的热情－－很像我在业内所遇到过的许多团队。 你们中大多数可能正处于这样的项目中，不管你是否是那个“英雄”，我想当你回想起这段经历时，都是不愉快的回忆。要么你变得讨厌那个英雄，要么你感受到队友们带给你的负面情绪。在我的软件开发生涯中，我遇到过一些十分聪明又有能力的软件开发人员，他们有助于公司生产线的短期获利，但在长远的工作质量上一败涂地。我想有一段时期我可能也陷入了这样的局面，现在回想起来深感惭愧。我愿把那当作是年轻气盛的表现，我希望随着年龄和经验的增长，自己已经知道更多的软技能并且对于如何使某人成为一名好的队友有了更广泛的理解。 雇用我们学校的毕业生的老板们告诉我从 WPI 出来的学生与其他学校出来的学生相比，最大的不同就是我们的毕业生在一开始工作时就能融入团队项目。他们不畏惧接受艰难的技术性工作，但是他们知道其他因素的重要性，技术含量较少的因素是项目成功的关键。 对于工作于学术界之外的大多数人来说，在一个组织里为软件开发人员“评分”的问题通常是类似的。如果你是一个经理，你想奖励好的价值和行为，但是哪一个更重要呢？如果你是一名开发人员，你有能力影响你的团队吗？如果是，你对团队的影响是积极的还是消极的－－而且是站在谁的观点考虑呢？ 我认为经理们应该考虑沿用我们学术界为学生们评分的方式来为他们的开发人员评分。我想我们在评测学生时用到的许多标准同样适用于企业，帮助他们更好的发展。 对我来说似乎显而易见的是任何一种评测都必须有一个底线。但是有一些战术上底线的成功可能会导致战略上的失败。成为一个好的经理需要具备开发团队潜能使其走向战略上的、长期成功的能力。你必须平衡企业短期获利与长期竞争生存能力之间的关系。 可以计量的技术能力是雇佣一名软件开发人员主要因素。他们为企业和项目带来必需的技能。许多年来，这是唯一要紧的事情。开发人员们将到一家公司，主要是做技术性的工作，然后他们觉得他们需要离开－－通常因为项目组里的其他成员实在不想和他们一起在另一个项目里工作。但是仍有许多公司需要他们的专业技术并愿意付报酬。跳槽在那几年成为一种标准。在二十世纪八十年代，我们很难碰上一个人真正地在一个公司待上足足五年。 坦诚的说，我承认八十年代对于我来说也是一段频繁变换工作的时期。有一部分是我工作的公司本身陷入困境，但大部分还是我自己试图在软件开发中找到属于我自己的道路。我想要学习，我想要做伟大的工作，但是没有人教我那些我现在认为如此重要的非技术性的技能。我的选择就是要做一个技术熟练的开发人员还是成为一名经理，而我从来没有想要成为一名经理－－至少没想成为一名拥有 MBA 学位并立志成为业内领军人的经理。此后我读了 Gerald Weinberg 的一本书 Becoming a Technical Leader，这本书使我对团队和团队合作有了不同的思考，使我知道如何更好的适应团队并产生积极的影响。 5 但是退回到这一点：如果技术能力是使一个人得到工作的主要因素，那么什么使得他们能够保持拥有这份工作呢？对于公司的战略目标和员工的供职期限来说，员工、公司和组织里的人三者之间的关系是重要的。 还记得我的评分推理吗？我教我的学生们软技能，并和我的教学助理一起帮助他们学习这些技能。但并不是对每一个人都起作用。我的一些学生被他们的团队“解雇”，因为他们无法在团队里工作。这些学生没有通过那一课程。另外一些学生发现了他们从未想过自己会具备的才能，并学习到通过合作交付的成果是一次相当有益的体验。 你评价开发人员的软技能吗？你有多么强调这一点呢？对于这个问题，你清楚你要评价的是什么吗？最后一个问题是关键，也是我想留给你们思考的。 我发现如果我没有准确地告诉学生们他们将如何被评分，其中一些人在他们没有做得很好的时候会感到惊讶。他们可能认为他们做了值得表扬的工作，从技术层面来说通常是这样的。但是我要他们成为团队的一部分，如果他们疏远他们的队友，他们将无法通过课程。如果你要在这个月的专栏中学到一样东西，那么我希望是清楚表达你所评价的事物的重要性，不管是给那些向你汇报的人还是那些和你同级别的人。 一些公司，特别是一些大型企业，有宠大的人力资源部门为如何执行成绩评估提供整体指导方针。他们为管理人员提供培训，绝大部分十分有益。但是当涉及到定义软技能的评分时，他们总是忘记打分。 当一年一度的评分即将到来的时候，回顾我在业界的那些日子，我总是感到失意，有时感到沮丧。我的妻子无法理解这一点。我几乎总是得到很多不错的评价和提升。我的问题就是我尽我所能辛勤的工作，将我最好的献给公司。我一直在思索“现在他们更多地想从我这里得到什么？”每当公司问我为下一年设置的拓展目标是什么，我总是把自己描绘成一个橡皮条，一年比一年伸得更长，直到有一年突然拉断。我确信这不是我们所想的，但那是我所感受到的。相反，通过简单的沟通将自己的目标讲清楚明白，而不是去提出让我得到更多的工作任务，将能够长期的帮助我了解如何更好的适应企业文化和为之贡献。 并不是所有员工－公司的匹配都是有效的。有很多时候目标、价值和需求恰恰并不相符，那没有关系。正如那些注定失败的软件项目，早发现总比晚发现好。但是一些失败可以通过清楚地描述如何为软件工程师“评分”来避免。通过清楚地表达对他们的期望以及对他们进行指导，你会发现比起许多不和谐，你将拥有更多的和谐。花费一点点时间提高你的评分技能，将使得员工们愿意长期与你工作。 1.这里我广泛地用到软件工程这一术语，它包括设计和分析课程以及标题为“软件工程”的课程。 2.这叫做不再需要它(YAGNI)。思维敏捷的人有另一个原则，那就是做可能有效的最简单的事情（为眼前的问题）。 3.Coverlipse 是一个开源的插件程序，可以在 http://coverlipse.sourceforge.net/index.php上找到。 4.查阅我的2006年2月份和2006年3月份的专栏了解更多我的软件工程课程： http://www.ibm.com/developerworks/cn/rational/rationaledge/content/feb06/pollice/index.html 和http://www.ibm.com/developerworks/cn/rational/rationaledge/content/mar06/pollice/index.html 5.Gerald Weinberg, Becoming a Technical Leader. Dorset House 1986, 国际标准图书编号 0932633021. 您可以参阅本文在 developerWorks 全球站点上的英文原文。 您可以参阅 Rational Edge 电子月刊中文版 的其他文章。 |
Gary Pollice是位于伍斯特的伍斯特工学院的一个实践方面的专家，他获得了硕士学位。他教授软件工程，设计，测试，和其它计算机科学方面的课程，并且还指导做项目。在进入学术领域之前，他花费了多于三十五年的时间来开发各种类型的软件，从商业应用软件到编译器和工具。他的最后一份行业工作是做IBM
Rational软件，在那里他以"RUP 倔老头;著称，并且他是Rational Suite团队最初的成员之一。他是Software
Development for Small Teams：A RUP-Centric Approach，的主要作者，那本书是由Addison-Wesley于2004年出版的。他取得了数学专业的学士学位和计算机科学专业的硕士学位。
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
