级别： 初级 Gary Pollice (gpollice@cs.wpi.edu ), Professor of Practice, 伍斯特工学院
2007 年 3 月 15 日 本文来自于 Rational Edge：Gary Pollice 继续研究他所列出的在软件开发实践中的常见错误，并将这个月的有关人员管理和工具采用方面的第二批和第三批内容增加到上个月关于过程采用的观测报告中。
上个月我提及了在过程采用上的一些反模式。
1
这个月我将继续观察反模式，但是我集中关注在1）人 2）工具采用上，这是另外两个影响成功软件开发的关键因素。
我先快速重述我所说的“反模式”是什么意思。上个月我将反模式描述为“一个表面上能够解决问题的合适的方法，事实上，使问题变得更加糟糕。”切记这一点，现在让我们看看管理人员和看起来很有意义的处理工具采用的方法，而事实上对我们的项目和组织来说预示着一场灾难。
人：关键因素
软件开发不仅仅是一个技术学科的问题。实际上，有人可能会争辩说它主要不是一个技术成就，而是一个包括每个个体能够平稳地在一起工作的团队的成就。优秀的管理人员能够达到并能够在小组成员中培养合作与协作的精神，从而获得巨大的软件系统的研究成果。在过去五年的时间里——假设随着敏捷开发不断流行的趋势，伴随有为了协作而在工具特性方面的快速发展（拿SourceForge社区来举例说明）——比以往更多地强调了软件开发的联合作业。随着越来越多全球性分布式开发模式的出现，开发小组中人员的合作逐渐变成成功的关键因素。
我们将按照我们的喜好来开始列表中关于“人”的反模式。如上个月提到的反模式，这些模式是基于我在过去的四十年中个人所观测到的。
| 名称： | 人就是资源——用这样的方法来对待 |
|---|
| 环境： | 人员就是软件工程成功的关键因素。 我们工作在一个以知识为基础的行业中，人是知识的宝库。我们雇用优秀的员工是为了他们带给工作的技能。这使我们可以稍微交叉地将他们分派到各个项目中。 | | 影响力： | 如果我们能够像对待其它资源一样来看待人力资源，那么我们就能够用相同的方法来管理他们。这样给管理者有更多的灵活性，并使组织具备能够处理通常在软件开发中遇到的的不断变化的问题的能力。这样，预算以及工作性能可以变得更有预见性。 | | 解决方案： | 人力通常是按照他们的技能而不是他们本身来进行鉴别的。典型的组织是一个矩阵的形式进行组织的。我们拥有如此多的编程单元天才，如此多的测试天才等等。当出现对这些人员的需求时，他们就会从一个项目迁移到另一个项目。 | | 结论： | 无论哪里需要他们的技能，对于任何从一个项目迁移到另一个项目的知识型工作人员会有两者结果。第一，雇员们很少拥有主人翁的意识，这对绝大多数软件开发人员来说都是十分重要的。他们喜欢骄傲地表明他们的造诣，并谈论他们对最终产品的贡献。第二，他们会否定属于某个小组的想法，团队对于软件开发最佳实践是基本原则。工作相对隔离环境中的个体会因为对他们技能的需要从一个项目迁移到另一个，并且对于开发大型的软件他们很少能够维持他们的热情。 |
我曾遇到的绝大多数矩型阵软件开发组织通常是在IT组织，尤其是较大的公司。构建软件产品的公司似乎给予了团队更多的生机。
在过去的几年中，我曾观察到所有主要软件开发人员的一个特征是他们对工作的热情。成就感和知识的增长是他们从工作中获得的最重要的回报。当他们变成大型机械中的一个可互换的嵌齿时，他们就会失去热情，他们的职业就会变成仅仅是一份工作而已。他们要么离开那份工作，寻找可以让他们重新获得热情的更大的挑战，要么他们就会变成完全的服从者，绝不做过多的事情。无论哪一种情况，这个组织都会失去巨大的潜能。
Chris Lowe，几年前曾是我的一个同事，他曾做过一个观测报告，让我思考了很长时间。他主要是说，“当他们将职员这个名字变换成了人力资源，事情就开始变得每况愈下。”简单地说，当我们把职员看作是人力资源时，我们就会使工作失掉人性化。我认为那是现代商业的一个悲剧。
| 名称： | 经常性奖励 |
|---|
| 环境： | 高手往往各不相同！当他们能够拼命工作和拼命玩耍时是最开心的时候。尽管很多人并不喜欢其它雇员可能会珍惜的“惯例”奖励，但是他们却喜欢被赞赏，喜欢可以提高他们的地位并让他们明白他们的工作已经被高度评价的回报。如果您跟软件开发者接触一小段时间，您就会发现，他们会以他们收藏的T恤衫，从他们参加过的各种会议带回来的小玩意，以及其它能够鉴定他们身份和地位的事物感到骄傲。 | | 影响力： | 小的奖励通常和大的奖励一样受到欢迎，因此您可以经常为员工们提供一些小的奖励，这是一种保持您的技术雇员们快乐的有效方法。 | | 解决方案： | 经常用一些小的，相对便宜一点的报酬来奖励您的员工们。 | | 结论： | 不幸的是，太频繁就会被轻视。今天的奖励是明天的期望。太频繁的奖励像分发糖果一样，就会很快失去它们的价值。正确的做法是，奖励不一定要昂贵，但是必须在合适的时间奖励给适当的员工。 |
我确信每个读者都可能认为奖励失去它们的有效性是因为它们已经变成组织中太平凡所事情。我可以想出几个发生在我的职业生涯中例子。许多好像是食物奖励。我曾工作过的几个组织中，公司提供免费午餐，可能是免费的正餐、免费比萨饼、爆米花等等。不用多久，雇员们就视这些为标准，并有一种完成了良好的工作也完全不会有奖励的概念。事实上，通常会发生这样的情况，小组成员们开始抱怨缺乏多样性 ，缺乏特别的食物等等。什么是奖金，对于他们来说就成了小组和公司中争论的一个焦点。小组成员开始认为这些奖励并没有满足他们的需要，并将其转化成公司不在乎他们的抱怨。
当您经常为那些完成了他们的职责但是并没超出他们职责范围的员工给予奖励时，也会出现这种效果——那就是说，他们完成了他们的工作，并完成了很好，但是并没有作出什么突出的贡献。这些奖励，或者T恤衫，或者夹克等等，在长远看来实际上是一种促进因素。
在学术界，对这个问题也有类似的情况——分数膨胀。我发现我很难让我的学生信服：等级B就是很好的分数了。他们认为如果他们很好地完成了功课，并不一定要很突出就应该被评为A。这不会发生在我的课堂上。
| 名称： | 持续奖励 |
|---|
| 环境： | 您想奖励您的雇员，并想确信这些奖励是一致的。雇员们希望以一种公平且一致的方式受到奖励。 | | 影响力： | 雇员们能做什么，不能做什么，对于不同层次的雇员有很多限制。我们需要非常小心，偏袒不是好的实践的。 | | 解决方案： | 我们创建可以根据公司方针而调节的奖励标准。我们始终如一地运用这些奖励是为了确保能工公平对待我们的每一个员工。 | | 结论： | 正如“经常奖励”的反模式中所说，这些奖励变得越来越没什么意义。它们变成了仅仅是公司给每个员工的额外的东西。即使不是给每一个员工，所有受到奖励的人都受到相同的奖励和特殊认可的相同机会，但这些人在公司中却是无人知晓的。 |
每年我都会告诉我的学生们这个故事，它阐明了为什么奖励实际上应该是有着特殊含义的。我曾经供职于一个公司，工作给员工一个五年的奖励。赠品都是有金额限制的，管理者们都希望获得并向分给他们的雇员们。这个习惯是在允许的范围内获得一个礼券，并将它赠给员工。这就意味着员工们可以获得他们所真正想要的东西。这对于管理者来说也更加简单。
我曾有一个新管理者仅跟我见过一次。她被赋予“奖励”我的任务，是为了让我留在公司中。不是像通常的礼券一样，她花时间找出我的兴趣所在。我收到一个shakuchi——是我一直都想要的一个日本竹笛，添加到我的乐器收藏品当中。现在，礼物的金额总计实际上少于所允许的最大限额，而且并没有花费我的经理过多的时间来发现我的喜好。但是这却使我一直清晰地记得，使我非常感激，并使我有一种被赏识的感觉。
| 名称： | 最大化技能使用 |
|---|
| 环境： | 每个员工都有一套独特的技能使他或者她能够对公司有所价值。我们为了他们所拥有的技能以及他们所能给这个项目带来的效益而选择他们。 | | 影响力： | 特殊的技能在人才市场具有很高的价值。我们必须努力通过确保拥有一定技能的雇员一直使用这些技能，从而使我们的资源使用最优化（请看“人力就是资源”反模式）。 | | 解决方案： | 每次需要特殊技能的时候，我们必须确保那些因为这些技能而知名的雇员来完成此任务。 | | 结论： | 这个解决方案可能是短期利益，对于组织的长远利益不是很大。通常会发生的情况是雇员的厌烦情绪，或者失去激情，最后变成普普通通的执行工作。最糟糕的是，员工们罢工。 |
由于我们处在一个以知识为基础的行业，我们不得不认识到，对于员工来说知识就是资本。软件开发人员以他们懂得的编程语言的数量为骄傲，以他们所擅长的新技术领域的数目为骄傲，以他们所学习到或正在学习的新事物为骄傲。如果我们发现在他们的工作时间需要运用所有这些技能，那么他们怎能有时间去学习新技能呢？
当今许多公司需要对他们的员工有训练目标的要求，这变成了他们每年评估的一部分。这通常变成了一种课程的形式——在公司内部或者都在组织外部，员工们找出他们兴趣中的新事物。这只是一个片面的解决方案。参加课程培训或者会议只是学习新技术和技能的开始。学会如何运用它们和对它们精通会花费大量的时间。在确定了最终期限的项目中运用新的方法是相当困难的，通常是不可能的。然而，适当地学习需要时间来使新的信息和试验内在化。因此，仅仅让员工们学习新技巧远远不够的。
一些公司为了这样的学习，尝试将计时作为员工进度表的一部分。其中有一些较好的方法。我曾学习过的一种相当好的方法是Google的20％的时间，员工们可以“自由选择自己所感兴趣的项目。这种自由已经创造出Google News、 Google Suggest、 AdSense for Content，以及Orkut——否则这些产品很可能需要花费整个启动时间来开始。”
2
另一个使员工们真正将新的技巧整合到现存的项目中的方法是，经常为员工们提供周期性的休息时间。很容易被人们接受的是，大学教授通过周期性休息的调节可以很好地关注他所处的研究领域的最新的研究进展，并能作出重要的研究成果。他们去其它公共机构或者行业组织中工作，这将帮组他们扩展他们的知识。我只见到极少的公司会提供周期性休息时间，但是我认为这是一个促进员工变得更优秀的很好的方法。
包括这个关于人力反模式的部分，我推荐一本Joe Marasco的书，Software Development Edge: Essays on Managing Successful Projects。Joe处理了很多管理软件开发人员棘手的问题，比如如何奖励您的超级明星。这是非常值得看的一本书。
工具：帮助还是障碍？
谈到Joe Marasco，他向我推荐了一篇最近的文章“The Gatekeeper's Guide, or How to Kill a Tool”。
3
这篇文章非常幽默，并间接地提到了许多关于工具的反模式。我不想将这篇文章中所提到的内容形式化为反模式，我将会把这些留给您们。无论怎样，当面临工具采用时我会提供两个我曾评述过的两个附加的反模式。其中有一些与前面所提到的文章的知识相违背，但是您需要考虑环境和影响力。
| 名称： | 加强在所有项目上的使用 |
|---|
| 环境： | 为了使工具能有效发挥作用，它们必须被有规律地使用。在组织中，我们能够通过使它变成所有项目开发过程的一部分来加强工具的使用。 | | 影响力： | 为了精通这些新工具，花费在购买许可证，培训以及花费在这些工具上的时间成本时非常高的。如果这些工具没有被利用，金钱就被浪费。因此，我们需要找到确保这些工具被使用的方法。 | | 解决方案： | 修改开发过程并合并每个工具必须在所有项目中利用的请求。这就保证了团队成员能够熟悉工具并能够使用它们。 | | 结论： | 由于有些工具提供了很小的利益或者根本就没有提供利益，那么这些工具就会无效。这些工具没有被合适地利用，也没有为小组成员提供一些便利，反而成了开发优秀软件的障碍。小组通常会找出方法来完成过程的最低请求，而决不会将工具当成助手来使用。 |
软件工具是为特殊类型的项目和环境而设计的。没有一个软件能在任何一个开发项目中都成功运用。软件工具在许多方面与木制工艺工具或者任何其它工具工具都十分相似。一个熟练的工匠能很好地为不同的工作选择工具。软件开发人员必须发展相同的技能。通过强迫开发人员使用相同的工具，仅仅是因为它可能是这个工具箱中最新的或者最昂贵的一个工具，鼓励小组成员避免因为他们实际的需要制造出一个有思想性的选择。
| 名称： | 使用所有的特性 |
|---|
| 环境： | 工具可以提供很多特性来帮助使用者提高他们的工作。每一个特性，从理论上讲，嵌入在工具中是因为它被认为是有用的。
| | 解决方案： | 因此，我们应该使用提供的所有特性，或者尽可能在任何使用这个工具的时候都使用到这些特性。 | | 影响力： | 既然我们有一个工具，我们就应该使用它。为了补偿我们在工具和培训中的投资，如果我们尽可能多地利用这些工具就可以更快地收回成本，这还是很有意义的。 | | 结论： | 尽管软件工具中包含了许多特性，拥有这些特性是因为在某些情况下它们是有用的，而并不是因为它们始终都是有用的。正如我们不想始终使用一个工具，我们不会在使用这个工具的任何时候利用到每个特性。我们想要有效地利用一个工具，这表明对于当前的问题我们知道那些特性是可应用的。如果我们盲目地使用了一个工具的所用特性，那么我们就会失去很多利益。这种损失完全是因为对于当前的问题使用了无用的特性而浪费大量精力而造成的。 |
作为一个开发者，我已经担任过好几个工具的销售，咨询并提供了专业的培训。我发现当一个组织获得一种新的工具时，人们就好像有一种都要使用这个工具的义务。但是工具采用跟过程采用一样——会花费较长的时间，并给您留有一定的空间来理解怎样使用它以及什么时候使用。
UML对于通信设计和分析问题毫无疑问是一种非常有用的工具。让我不太理解的是在从模型中产生代码时它究竟有多大的用途，以及什么时候有用。对于UML语言以及相关工具的使用有不同的层次，这取决于我所处理问题的类型。
如果我构建了一个简单的语言处理器，我一点都不能确定对UML的使用。语言处理器以及其实现的结构已经是众所周知的。用一个形式化语法来确定语言事实上一种适当的方法。
现在，如果我有一个中等规模的项目，我可能会利用UML和一个支持UML的工具来创建足够的类图、序列图以及其它图来传达设计。事实上，当我真正将我的图放入一个永久性表单中时，使用工具将取决于这个图在工作中被创建和修改的难易程度。换句话说，对于这个图表，我不能详细地指出在什么地方，我有足够详细的资料为这个项目产生有意义的代码。
设想一个同样的中等规模的项目，我利用IBM Rational ClearCase作为我的源代码管理工具。当然我也会安装ClearCase，以此开始检入和检出工件并将它们与我团队的其他成员分享。但是我并不确定对于这种规模的项目，我是否需要利用ClearCase的并行开发能力，使用多分支等等。
对于一个较大的项目，我当然想运用这个工具更多的特性，以确保这个小组更多的合作，并有一个更为正式化的沟通方法。对于代码生成十分有用的很可能是这个模型的一部分，如果这个项目十分冗长，就很可能有使用SCM工具的并行开发特性的机会。
总结
我认为，事实上也希望，大多数读者都应该看看这个月的栏目（以及上一个月的），并思考一下“这仅仅是个常识”这句话。然而，我实际上也明白，这并不是个常识。如此多的软件项目陷入了困境，是因为项目管理人员想运用并不能起什么作用的公式化的方法。软件开发是一个组织所有IT工作中非常重要的一部分，IT本质上也的确是一个以知识为基础的行业。那就意味着我们需要在正确的方法中运用知识并掌握成功的三个关键因素——人、过程和工具。
注释
1参见 “过程引入的反模式——如何避免一个过程对您的影响”。
2
http://www.google.com/support/jobs/bin/static.py?page=about.html。
3 Eugene Farmer所著的"The Gatekeeper's Guide, or How to Kill a Tool," IEEE Software，于2006年11/12月发表。
参考资料
关于作者  | 
| | Gary Pollice是位于伍斯特的伍斯特工学院的一个实践方面的专家，他获得了硕士学位。他教授软件工程，设计，测试，和其它计算机科学方面的课程，并且还指导做项目。在进入学术领域之前，他花费了多于三十五年的时间来开发各种类型的软件，从商业应用软件到编译器和工具。他的最后一份行业工作是做IBM Rational软件，在那里他以"RUP 倔老头;著称，并且他是Rational Suite团队最初的成员之一。他是Software Development for Small Teams：A RUP-Centric Approach，的主要作者，那本书是由Addison-Wesley于2004年出版的。他取得了数学专业的学士学位和计算机科学专业的硕士学位。 |
对本文的评价
| 
