从“你叫这敏捷？”部门谈起

作者：周思博(Joel Spolsky)
属于Joel on Software, http://www.joelonsoftware.com

Dmitri Zimine用一个假设的范例说明打断一个程式设计师两个小时，解决销售案的问题，实际上会如何浪费掉两个星期。「如果Sarah 花了两个小时在旧专案上，那么他在新专案上会损失一整天的生产力。」

我同意切换工作有坏处。无庸置疑。

德米特里 指出开发经理应该「告诉开发员坚守原来的计划。提供保护避免他切换脑中的内容。提醒他专心在一个重要且有趣的工作上有多酷。向他保证我会处理所有的压力。」

听起来好像这我也会同意。我完全同意管理阶层有责任提供程式设计者一个抽象层，让程式设计师可以假装他们在工作写程式的时候，外界的事物完全不存在。

然而这结论里有件事让我觉得很惊讶.Dmitri只看到了成本/效益方程式的一面。他提出了一个很有说服力的论点说明为什么Sarah 不应该中断他仔细规画好的两个星期步骤，但他完全没有提到另一面的论点：可能会损失重要的客户/销售。

敏捷开发（敏捷开发） 应该是有关于敏捷的。它应该代表你可以很快地更改计划。敏捷不应该是一个死板的程式团队奴隶般投入他们的两星期步骤，以致为无法重新安排行事历来满足客户的需求.Dmitri 的结论对我来说等，恐怕和敏捷开发正好相反。敏捷不应该是为了排除一个官僚化僵硬的程序，而掉进另一个同样没有计算到客户需求的程序。

我不知道这个假设范例的细节。也许在现实生活中这个客户的需求没真的那么紧急。但是也许它就是这么紧急？也许这个客户可以拯救公司一命，让每个人都变成Web 3.0时代的大富翁，但是因为Sarah坚持要遵守两星期长的计划（因为它「敏捷」），让他们没了兴趣？不确定……这只是故事的一面。

最近微软释出了新版本的IE。他们在代理服务器的侦测程式里制造了一个问题，使得一小部份的Copilot客户遇到当机。在此同时，Copilot 开发团队，也就是Fog Creek里的“Ben”，正忙着把Copilot 2.0完成好推出上市。但你知道吗？我们安装了IE 7 的客户遇到当机。这令人无法接受.Ben停下他手上的工作，安装旧版的编译器，取出旧的原始码，修好了当机问题，把修正版放上伺服器。打断且延迟了 副驾驶 2.0，而且这切换有坏处。但这仍是一个正确的决定。正因为有能力处理切换工作这种高难度心智挑战，我们的产品才会更好。这是程式设计师赚大钱的理由。你给他们昂贵舒服办公椅，无限零食供应，豪华午餐，超赞三十吋液晶萤幕，因为这样能让他们去解决微软在他们程式里制造出来的，把原本一个正常工作的DLL 搞乱的新问题。

是的。切换很痛苦。是的，你要打断某人的工作时，需要计算到切换的代价。但是每个决定都有好处和坏处，当我听到有个经理只说到好处而没有考虑到坏处时，这经理并不称职。