外刊IT评论 » 敏捷开发

【外刊IT评论】通过高频招募与解职组建最好的团队

花非花 — Tue, 16 Mar 2010 13:48:37 +0000

昨晚我出席了在圣地亚哥的一个极限编程的研讨会（实际上这个会议应该叫做敏捷编程研讨会，但我猜测这个会议组织诞生于XP之初，早于极限问世）。我的一个读者知道我到圣地亚哥去访友，就推荐我参加这个会议。我本意只是想走马观花，看看编程运动在我上次做了研究之后有没有出现有趣的新情况。特别是近来，敏捷开发有更多的关注到人的问题上的趋势，在这点上，我一直很迷茫。

首先引起我注意的是出席的人物。我估计在圣地亚哥应该有成千上万的从事编程的人，但只有10个左右的人出席。我想，这估计应该归罪于这种职业，大部分我们这行的人都不喜欢发现和学习新事物。也许还有其它一些原因，但其中最主要的原因，我认为应该是，人们总是喜欢依附于现有的技术和方案，大家都是这样干的。有一个发言人上台要做演讲了。演讲人很不错，而且尽量减少了内容条目，增加了很多PPT图片。可是每当幻灯片闪烁时，我脑子里总有一种声音告诉我“打个小盹吧”。这种研讨会上的交流基本上是单向的，有稿子的，但你又不能像在网上看演讲那样可以快进。

当我被问及时，我讲述了一下我感兴趣的人的方面的问题，在这个问题上，我开始认为还有很大的改进的地方。做为一个例子，我谈论了组建团队的问题，在目前我们所处的这种商业结构下，组建一个好的团队是如此的困难。有一个人提到了Kayak.com 公司，它的创建者招聘又解聘了好几百号人，最终从中挑选出了目前的30个员工。

对于建立一个公司，从某种角度去看，其实主要是如何创建一个优秀的团队的问题。我曾听到过无数的人谈论他们公司的各种各样糟糕的令人不满的状况，但他们却仍很开心的留在这样的公司里，就好想自己是在一个非常棒的团队里一样，永远不舍得离开。如果我们真的把团队当作一个公司的基本构件的话，那去创造一个环境，给优秀团队的诞生创造出一个文化氛围，这是很有意义的事情。

关于团队建设的问题，人们有时候把它想象成“少损失多少钱”类似的问题。尽管都知道当有投资损失时，损失掉的就不用惦记了，但当人们做决策时，我们的大脑总是让我们按照我们已经投资了多少来考虑。所以，如果你投资了很多时间和钱雇佣了某个人，你总舍不得放弃他，直到有一天，他给你带来的麻烦超过了你能承受的最大限度。这实际上是说：一颗老鼠屎可以轻易的在一个团队里待上很久的时间，直到有一天他把整个团队都给污染了，才会被迫被驱逐，而此时为时已晚。就像你把鲈鱼丢进一个金鱼队伍里，等鲈鱼把所有的金鱼都吃光了，你才认识到“这个鲈鱼终于吃饱了””

另外一个大的因素是劳动法的问题。有些人会投诉公司违法解除劳动合同，所以所有的公司都尽量避免这样的纷争。你不能随意的开除某个员工，你必须给他们6个月的适应期去观察他们的工作能力。

我猜测Kayak.com 的创立者肯定和每个员工事先达成了某种协议，才能够如此容易的解聘员工。在这种形式下产生的员工对公司的忠诚，未免很粗糙… 但如此一般，他们能得到优秀的员工，也不失为一条道路。因为他们真的想留在这样的公司团队里，间接的也会对公司产生忠诚。

给团队挑选成员，真正的问题是，你只能通过其实际的日常团队合作过程才能看出一个人的价值，没有其它的捷径。面试不能提供你任何这方面的信息。很显然，Kayak.com 公司规定，大部分的“面试”要延伸到把人安排的真正的岗位上，看其真正的工作表现。也许这样有点让人于心不忍，有点残酷 — 尽管没人把找工作的过程当成一种享受，也许先有一个，虽然只是短期的，总比长期没有、四处求职强 — 但从公司的角度，这绝对能收获很好的效果。

是否还有人知道关于Kayak.com 公司的故事？是否还有其它的方案能有助于组建团队的问题？

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides
development assistance in Python with user interfaces in Flex. He is the
author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd
Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM
(available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000,
Volume 2 with Chuck Allison, 2003), C++ Inside & Out
(Osborne/McGraw-Hill 1993), among others. He’s given hundreds of
presentations throughout the world, published over 150 articles in
numerous magazines, was a founding member of the ANSI/ISO C++ committee
and speaks regularly at conferences.

【外刊IT评论】企业主与代管人(职业经理人)

花非花 — Sat, 13 Mar 2010 04:53:35 +0000

Tim Bray 最近的一篇博客文章， Doing it Wrong，在最近几天受到了广泛的关注和议论。在这篇博客里，Bray 对两种软件开发过程进行了比较，一种是那些面向Web开发的创业公司使用的（大概意义上的）轻量级的敏捷开发方式，一种是受大企业采用的相对正规的、重量级的开发过程，观察到了如下的现象：

这些工作在Web领域的人，他们几乎不知到ADO或UML或JPA都代表什么意思，但他们却开发出来很好的低成本的、低风险的系统，相对来说，在那些大企业里，他们永远做不到这些。在那些高度灵活和快速成长的创业公司里，情况更是如此…

这真是让人难以接受。世界财富1000强里的那些企业正在流血，他们错失了大量的超越自己和完善自己的机会。我并不想说软件开发是一种唾手可得的过程，因为如果软件开发水平的差距可以简单的弥补的话，这样的弥补早就会发生了。但事实上，这种差距如此的大，报应是如此的强烈，现在已经到了我们需要严肃的看到这个问题，需要我们去做一些投资去消除这种差距… 这个问题也许是我这种职务的人目前最需要去做的事情。

Bray 然后尝试着去探索发生这种巨大差异的原因，并且认为，在企业中，技术问题和文化问题是导致不断增长的开发代价的原因。

Doing it Wrong 这篇博客的读者们已经指出，Bray 的分析中疏漏那些大量的创业公司最终是倒闭了的。另外的一些朋友指出，受风险投资控制的创业公司，他们对企业事务掌控的很少，他们必须很小心的计划如何使用这有限的资源：经理必须在软件项目动工之前计算出需要的投资和完工时间，开发人员呢？他们只能按照这种计算好的要求去做他们的开发工作。

企业主和代管人

然而，Bray的分析和人们对它的评论中，在说明为何软件项目的成本和质量上有如此大的差异的问题上，我认为，漏掉了一个重要的因素。这种差异，归根结底，并不是由于他们分别属于大企业和面向Web开发的创业公司的原因，而是两种不同类型的管理人和开发者之间的问题：企业代管人和企业主（企业所有人和职业经理人）。

从商业的角度去看—Bray的主要观点—企业代管人使用的是别人的钱，而企业主花的是他们自己的钱，或者说至少他们非常慎重的和切身的考虑如何在一个项目上投资。更通俗的说，业主通常会有很强的意愿让他们的客户满意，从财务上考虑或是从单纯的技术追求上考虑。这样，对于业主来说，高效和压缩成本并不是他们简单的行动指标。而企业代管人很少有让他们着急的工作目标。

大企业和创业公司里都存在企业主和企业代管人。我曾经在几个的很大私有公司里工作过—这些公司都是由几个合伙人管理的，而不是有无数的股东管理的—他们始终坚持很朴素的软件开发过程；我也在一些有由那些没有切身得失和职业焦虑感的职业管理人管理的大公司里干过。还有，尽管是一些创业公司，尽管他们的员工有着强烈的愿望使企业成功，但风险投资人却让他们的简朴创业的作风成为一个遥远的概念。

企业主和敏捷开发

我发现，企业主类型的公司喜欢在项目开发中使用敏捷的开发原则：举个例子，他们会对自己的钱包有绝对的控制，而你，作为销售或者是顾问，如果你的工作成绩不高或没有持续的进步，就不会从老板哪里得到很好的回报。这样往复，是一种良性循环。在这种背景下，开发人员都会得益于这些敏捷开发原则。另一方面，企业主对一些短期的看不到回报的企业项目会非常的谨慎，不会轻易投资。这样一来，某种程度上，出现了像Bray描述的那样：这些因素决定了这些企业采用的技术路线。结果是，成功的企业主们关注的是软件的可持续维护性和造价，敏捷原则能够更好的对需求变化作出应变，更适合这种环境下的企业们使用。

企业代管人，相反，他们很少有企业主的那样的动力：从商业角度上说，企业代管人通常会每年一次的或每季度一次的根据绩效获得红利或晋升，这和长远的角度上看问题是矛盾的。企业管理人同样很少会把自己的前途和一个项目的成功绑在一起：如果这个项目失败了，他们只有再找个项目或换个公司就行了。企业主关心他们的客户，而管理人关心他们的老板。这样一来，代管人相比较更注重决策的稳妥：他们的这种处境决定了他们不能让项目的失败对自己地位有所损害。企业代管人同样很少热心于迭代开发、持续集成、可测量产出原则，一部分原因就是他们是按固定的周期拿固定的薪水的。而企业主是没人给他发稳定的工资的：他们必须时刻想着如何从自己面前的客户那里能到自己的酬劳。

Bray 提到的 Basecamp 就是这样的一个例子；那种情况里，所以的开发人员其实都是公司一小块的拥有者。他们有着明确的动力去让软件朴素整洁，易于维护，这些于是就影响了他们的技术选择。而另一端，那些大规模的政府投资项目，所有人其实是无组织的纳税人，几乎每个人都是项目的一个代管人。 Bray 提到的那些引起轰动的失败项目很多属于这种情况。

这两种极端类型公司中的雇员，多少都有愿望他们的公司的决策正确。这“最好的”决策并不一定都会导致节省开支或者使用最合适的技术方案。是否是“最好的”是由环境决定的，人们可以根据不同的环境定义自己喜好：一些人创业公司的人在他们的日常工作中极力推荐一套技术方案，而晚上自己在公司里使用的却是完全不同的另一套方案。在一种环境里，他们是代管人的角色，而另一种环境里，他们是企业所有人，这就导致了不同的动机和决策。

我们都应该成为企业主吗？

从企业主和代管人的视角看这个问题，我们会发现Bray的博客中提到的问题实际上是一个很老的商业问题：一旦一个公司开始招募员工，或经理人，那么，这群带着不同的心思和动机的元素就会进入公司文化中。虽然只有合伙人的公司效率很高，但没有雇员你就很难成长壮大。

软件开发是同样的道理，即使是在开源软件项目里。单干或者带着几个合伙人或者几个关键持股人一起开发是一种理想的情况，当你开发出的软件项目被人广泛使用时，这种理想状态反而会制约公司的成长。我对这种处境没有个人的经历，但你可以想象，那些大的开源项目，例如Linux kernel 或 Eclipse IDE，它们需要比那些几个人开发出来的小项目需要更多的资源。

你必须接受这样的现实，损失一些效率，换来的是更壮大的企业，为更多的用户服务。很多公司都是这样，从微软到谷歌：谷歌拥有两万多怀着不同动机的员工，
而技术决策者只有5个。

我们当然不能全部都是企业所有者，但一个企业可以逐步的让他们的员工感觉像是个企业所有者。敏捷开发提倡“产品拥有人”或更甚“企业拥有人”的概念，聪明的公司可以在商业目的上也使用这种方法。

有一点还必须认识到，企业主虽然有着好的动机，但他们未必就能做出正确的决策。重要问题上的错误的决策会让一个公司倒闭，让企业主损失惨重，让他们的希望破灭。

你是否同意，用“企业主”和“管理人”如何做技术选型的角度也可以解释Bray所提出的问题呢？你对Bray的这篇博客有什么看法？

About the Blogger

Frank
Sommers is a Senior Editor with Artima Developer. Prior to joining
Artima, Frank wrote the Jiniology and Web services columns for
JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org,
the IEEE Technical Committee on Scalable Computing’s newsletter. Prior
to that, he edited the Newsletter of the IEEE Task Force on Cluster
Computing. Frank is also founder and president of Autospaces, a company
dedicated to bringing service-oriented computing to the automotive
software market.Prior to Autospaces, Frank was vice president of technology and
chief software architect at a Los Angeles system integration firm. In
that capacity, he designed and developed that company’s two main
products: A financial underwriting system, and an insurance claims
management expert system. Before assuming that position, he was a
research fellow at the Center for Multiethnic and Transnational Studies
at the University of Southern California, where he participated in a
geographic information systems (GIS) project mapping the ethnic
populations of the world and the diverse demography of southern
California. Frank’s interests include parallel and distributed
computing, data management, programming languages, cluster and grid
computing, and the theoretic foundations of computation. He is a member
of the ACM and IEEE, and the American Musicological Society.

【外刊IT评论】Do do XP

花非花 — Sat, 28 Nov 2009 15:21:36 +0000

agile software development

在文章 Don’t do XP 里, Tobias Mayer 建议人们不要去搞极限编程(XP)。我和Tobias相知已久，我想他这个问题上错了。我不知道他在跟谁争论，但他们的有些争论就是“嚼舌根”。我想如果他曾经试过一次XP，那他的言论会更有说服力。 XP并不是一个万能的解决方案，但它确实是一种方案，而且我们知道如何使用它。

作为一个临时的XP支持者，我并不抱怨 “在软件工业中Scrum没有提供很好的开发原则”，我只抱怨这个产业。如果我们能在这个产业里有效率的工作，那我们也就不会有这场关于方法论的战争了，因为我们的目地就是出产品。如今当人们把Scrum概念应用到这个产业时，Scrum也不幸被人们使用的混乱不堪。另一方面，责备XP阻碍了实施方法的进步显然有些牵强。

XP是一种很小的运动，只吸引了一部分人的目光。 XP（第一版）所实现的成果是让大家知道解决一直困扰很多开发团队的无法负担开发工期压力的问题是有办法解决的，而且是在不须求助高人协助的情况下。它提供了我一套好的实践方法让我们在开发中使用。 当然了， XP 并不能解决世界上的所有问题，它并不是对每个人都适用，至少一个原因是你必须对它有相当的认识和研究，这是一般的团队所不具备的。 Kent beck所论述的第一版XP极具有针对性：它的设计目标是让我们控制混乱，拓宽我们软件开发的思路，重新制定研讨框架。

我想Tobias似乎已经忘了这十年来发生的事情。其实我们所处的完全是一个理论性的运动，因为XP把推迟代码实现作为论述的中心—— 只需看看与此相关的人，他们是相同的一群人。他似乎也忘了众多的XP实施建议直接和我们的直观感觉有冲突，特别是和当前的产业发展方向有冲突。

Tobias说这些优秀的开发实施意见传播的如此缓慢，而我要说的是，没有XP，我们估计仍在原地等待。测试驱动开发一直没有被广泛的接受，甚至连最初的C3小组也没有完全的接受它——直到有一天Kent写出了这本书。持续反省理论有一小群学院派的人追随，但是这种理论的实践如果没有TDD很好的支持会存在一定的风险情。我怀疑大多数的团队仍旧不愿轻易重整代码，除非要添加新的功能。结队编程方式也在滞销，同样，这种方式在TDD的环境中发挥的会更好。我知道有相当多的Scrum团队都没有找到一套系统的方法理论。如果说他们需要改进Scrum的实施方法，这是把问题归咎于他们如何使用Scrum和他们的自我组织问题。

最的的一点挑剔。 XP的论著有二版，第二版发布不是很久远，而且里面提到的方法论更加“柔和”。与这些实践理论相关的一件事情：C3 项目组是在 (Smalltalk/Gemstone) 这样的环境中工作的，落后于大多数我们今天使用的环境。 XP社团里的很多工作都是在增加XP的灵活性，让它能在新的开发环境中使用。真正让人恐怖的事是这个产业缓慢的发展速度。

英文原文：Do do XP

【外刊IT评论】Don’t do XP

花非花 — Tue, 24 Nov 2009 14:56:12 +0000

Steve Freeman 写了一篇 blog Do do XP 来反驳我的这篇文章。

我开始厌倦了和那些坚持认为Scrum离开了极限编程就不再有价值的人的无休止的论战。 Scrum 很好用 — 但前提是实施者必须从基础上理解它的价值所在和实施原则。你应用Scrum所处的环境条件决定了你在实施过程中应该采取哪些措施。比如，在教堂里实施Scrum和在软件开发中实施Scrum有着不同的一套实施策略。而这两种情况下的实施措施又和传统的Scrum有不同之处。

极限编程的拥护者动不动就抱怨在软件工业中Scrum没有提供很好的开发原则。但就目前极限编程被业界采纳的缓慢进度来看，真正应该受责备应是XP的缺少实践措施的问题，XP应该为这种状况负责。

从八十年代到九十年代，随着开发语言的进步和更适合于软件设计，人们开发和测试的方式发生了改变。在广大的面向对象群体中，有些概念正在缓慢的、但广泛的被人们所接受。例如持续反省、限制责任、测试代码优先（TDD）、持续集成、推迟设计、编码规范、以及结对编程等。所谓的极限编程 (Kent Beck和他的一些同事所做的) 也就是将所有的这些好的实践方法集中到一起打成一个包，再加上Jeff Sutherland 1993年在Easel公司实践出的Scrum模式。某种意义上说，这也就有抽象Scrum概念的第一次具体的实现。

这些都很成功。然而他们的这些实践经验的推广和采纳并没有像他们想象的那样进行。也许就是因为取了个极限编程的错误名称；也许是因为主要的、嗓门最大的拥护者非要说这是唯一真理的原因；也许是因为管理者恐惧这个新出现的异类，暗中作梗反对它；也许是因为，说到底，XP也不过是另一种开发方法。我不知道。我只知道，只有很少的开发团队宣称和承认采用了XP。

然而与此同时，Scrum正在获得强大的发展动力。并不需要多少华丽的理由，实际情况却是Scrum正在被为数不少的团队接受，正在用它来改进我们软件的开发过程。反而是XP现在想来分一杯羹。他们确实很饥饿。

首先，让我把问题说明白。我十分赞同软件开发团队采用一些已知的实践指导来提高代码质量、生产更高水平的软件作品。但为什么这么多人不愿意这么做？我不太喜欢把十几个任务打个包直接丢给团队，也不喜欢事先指定一种开发方法让他们必须遵守。那样做很显然违反了“people over process”和自我管理原则。在好的Scrum实施里，团队成员应根据自身情况找到适合自身的实施策略，这样的Scrum应用过程才是与实际相结合、才有意义。这才是我追求的进步。有些Scrum团队一直没有找到很满意的开发方法，这说明Scrum实施方式需要改进，而不是去告诉团队成员强制实施。

我有一个问题思考：如果XP从来没诞生过，有多少团队愿意完全接受所有XP所推荐的方法？我相信会有很多。我相信这些宝贵的开发经验会自然而然的被程序员和团队们采用，对我来说，关心的是经验本身，而不是他们出现的形式。我从来没有“done XP“，但我显然可以写出高质量的软件。 XP的错误就在于坚持要求全盘接受。这并不是XP的创始人的初衷，可现在却搞成这样。很可能就是XP导致了这些好的实践经验不被人接受。很讽刺，不是吗？

另一个大问题是，XP论述写于12年之前，于此至今已有40多种新的语言诞生。 XP倡导者在向人们推荐12年前的、现在可能过时的经验 — 12年相当于整个软件工业年龄的四分之一。惊人吧。让人们去发现适合自己的开发方法，他们将会总结出最有效的开发经验，这远不是几个脑瓜好用的人在上个世纪末能创造的。

我强烈要求Scrum倡导者停止与XP的争吵，我们讨论的应该是软件艺术。这才是我们在这个领域里急切需要的最终目标。幸运的是，现在有一个有着自己的manifesto的软件艺术运动正在逐步为人们所关注。最终，我们可以通过好的软件艺术实践运动重新改革我们这个领域，而不是使用那些修修补补的策略。

开发者们：Don’t do XP。我们要实现一个通常意义上的指导框架，解决多年来的困扰，构建以人为本的核心基础。让我们重新为艺术而工作。或者从此离开这个行业。

英文原文：Don’t do XP

外刊IT评论 » 敏捷开发

【外刊IT评论】通过高频招募与解职 组建最好的团队

About the Blogger

【外刊IT评论】企业主与代管人(职业经理人)

企业主和代管人

企业主和敏捷开发

我们都应该成为企业主吗？

About the Blogger

【外刊IT评论】Do do XP

【外刊IT评论】Don’t do XP

【外刊IT评论】通过高频招募与解职组建最好的团队