我说的精简和敏捷并不是说我的减肥或瘦身的经历。精简和敏捷是制造业里的敏捷管理和精简库存的意思。精简和敏捷管理在90年代初才被引入软件制造业，现在国内知道多的是Martin Fowler，或是IBM用的那一套，还有近微软也开始推崇精简和敏捷管理，并为此设计了一些软件。我所经历的精简和敏捷管理和这些都没有联系，话收回来，我的经历和微软有一点点关系，和Martin Fowler也有点关系。下面是我的故事。

　　在2005年11月份左右，我还是微软一个普通的合同工，当时我和Volt Computer Services的合同差不多过期了，我刚刚把我的夫人接到美国，不找份正式工作心里不踏实。我一开始先尝试着在微软找份工作，我去了一个MS Office测试组的面试，结果面试发现这个组使用手动测试居多，自动化测试很少。我的能力和方向和他们相差还很大，自然没有通过。

　　我当时所在的小组又没有任何全职机会，所以我开始寻找雷德蒙地区（华盛顿州的微软的老窝）其他机会。有我收到了一封来自Peter Stroeve的信，可能是我在HotJob上张贴的Resume引来的注意。我和他来回了几封电子信，我后决定去这个名叫Net Objectives 的公司进行一个面试。当时我们聊了聊天，我和Peter见了面，他是个很沉默的人，和他一起的还有David Moynohiem（不知道有没拼错），后来还来了一位Kevin Yu（广东人）。我和他们海吹山侃地聊了25分钟，然后又做了些他们出的题目。他们对我非常满意，派我到MSN旗下一个搞上网安全软件的小组面试。我轻松搞定了这个简单面试。

　　随后我开始了我事业生命中光彩，难忘的经历。当时David告诉我说，这是一个微软MSN的外包项目，我们准备用了Lean & Agile的管理模式来进行这个项目的设计和制作。我不知道这个Lean & Agile究竟是什么，我当时心想不管怎么样，先当的士兵，在连长安排下冲锋陷阵，做好本职工作，发挥110%的自我能力，肯定没有问题。我打心里不相信所谓的Lean & Agile能够做好一个软件。

　　当时我看到的微软在Vista上的人员互动，我对软件设计管理丢失了信心，我只知道自己能力不错，能处理任何问题，当时的信念是“一夫当关，万夫莫开”。我对自己的能力的信任是没有任何疑问的。

　　第一个星期整个小组在招人，和我同时选上的还有一名叫 Nadim Rubeiz 的黎巴嫩人，Kevin是项目负责人。后来我们又招了一个叫Brian Young的测试员。他是个硬件驱动高手，对视窗内核和驱动设计了如指掌，是个不折不扣的高手。我们又招了一个叫Said Fathababel的埃及人，此人对视窗内部的构造十分了解，也是高手。

　　Brian和Said都有一定的问题，我后面再慢慢叙述。这第一周我们先是选定办公地点，是公司中一个稍大的会议厅，Kevin定购了一张很大的会议桌，我们四人团团围着桌子坐，当时我觉得这样办公好寒惨。几分钟后才知道这才是Lean & Agile的佳工作方式。我们随后安装了新买的Dell电脑，开始将所有的任务写在纸上，贴在窗上。我们的开发此开始。

　　第一个星期的工作基本上是投石问路，我们大概知道我们的用户期待的是什么，我们大体把前三个星期该做的事列举下来了，第一周过后，我们和客户见面进行了45分钟的会谈，首先Kevin介绍了Lean& Agile的管理原理，我们外包人员是一辆汽车，我们的客户是驾驶员，客户的意愿加上我们的做事程序，将完成客户所期待的价值。

　　随后我们把该做的事和客户进行沟通，选出了两周左右该做的事。这些都叫“故事”（Stories），准确的名称应该是“任务”。我们把故事的重要性进行分类；重要急迫的被划分并放入“Front Burner”；不急不缓的“故事”被放入“Back Burner”；不急的“故事”被放进“Cold Frig”。所有重要的“故事”必须在第一个开发周期（两周）内完成。这并不是硬性指标，因为完不成的任务往往是重要“故事”中不重要的任务。这些完不成的任务和“Back Burner”中的任务重新被衡量，重要的这些未完成的“故事”被选择到“Front Burner”中，作为下一周期中该进行的任务。

　　这样周而复始地，所有的任务要么在后基本完成，要么时间全部用完但是一部分任务根本没有完成，而这些“故事”正是客户不需要的。这是Lean & Agile。

　　我们开完会，回到公司开始开工。我们先总结了的工作，这是一个15分钟的短会，叫“Scrum”。每个人必须站立着，向工程负责人汇报昨天作的事，这是每个开发人员每天做的一件事。然后在每个周期开始，我们要进行设计会议，我们把故事细化，然后把所有的故事列在白板上，大家每人选择一个自己有兴趣的“故事”去做，做完验收后，再选择一个新的“故事”去做。我们第一个开发周期的进度完成地非常顺利，我们设计了一个简单的用户界面，然后是一个简单的中间件，后是一个后台数据存储件。

　　设计的时候我们遵循了“测试为先，开发随后”（Test Driven Development）的设计准则，利用CxxText作为我们的单元测试框架，事实上我们好多测试都是用CxxUnit来完成的，我们除了硬件，操作系统，和Visual Studio .Net 2005外所有的资源都是自己搞出来的，微软贡献的，或是开源资源。我们五个人组成的开发团队大的价值是我们过硬的技术能力，这些基本上能在外包行业赚取利润。当然，这并不代表我们的团队没有任何问题。下面我要谈谈我们所面对的问题。

　　从第二周开始，我们的进度开始影响。首先是Brian在第一个开发周期时没有完成他所要完成的测试任务。事实他在整个开发过程中没有做什么事，他有一个不满周岁的小孩，每天不到10：30或11：00我们不一定能见到他走进办公室。下午早在3：30，见他准备回家接孩子。好在他的合约签的是合同制，否则这样每天五小时的工作算成八小时的工作，我们的公司不是被他骗去不少钱。

　　随即出现的问题是，Lean & Agile要求组配对设计，两人一起解决一个设计问题，这需要两人相互给对方提意见，然后相互吸取对方的意见，这种做法是强迫设计小组中的任意两人进行取长补短。既然这是一种硬性规定，我们必须虚心相互沟通。Brian并不是这样的人，他的智商可能有156，所以他认为所有的人都比他愚蠢。我根本和他合不来，我的意见他根本听不进去。一个简单的测试程序我们争吵了三四小时，我觉得这个程序五十行码能写完，他偏偏要用各种钻进牛角尖的方法进行设计，我的简单设计他听不进去，我也无法说服他采纳我的意见，然后我只好和他抬杠。这种情况本身是与Lean & Agile背道而驰的。面对这样的问题我毫无办法。

　　等到我们的程序突破三百行代码时，我们才设计了整个程序的一半。我实在无法控制这样的局面，在他离开后只好向Kevin坦白我实在无法和他沟通。Said和Brian几天前出现过同样的问题，他们甚至为双方的专业背景而产生争执。事情是这样，Said背雇佣后，Brian问他是否是搞驱动背景的。当时Brian的态度很不好，给Said的感觉是Brian 藐视了他对小组能做出的贡献。当时大家的心态都很不好，我们三人（我，Brian，Said）都在微软工作过，我们刚刚被Layoff，大家都希望自己在这个新公司里的位置稳一点。Brian大概是害怕Said作为一个懂视窗结构的老手来夺取他在公司里的位置，而Said则觉得自己好不容易在丢了工作后找到这么一个来之不易的机会又受到一个年轻Punk的排挤。

　　Said气忿之下两人争吵起来，后来我们只好开会互相谅解。后来Nadim花费了一个上午才说服Brian尝试简单的设计思路。后面我们发现Brian和整个小组的配合并不很好，所以我们后面的做法是，尽可能少给他事情做，将他变成一个可以随便取代的成员。因为他拥有更好的测试手段，和硬件测试技术，有利用价值，所以我们一直容忍他的不作为到项目结束，后我们也发现他的存在确实在关键是可能帮上忙，正应验了古时候“鸡鸣狗盗”故事中的寓意。

　　在第二个开发周期的前期， Nadim 重新设计了后台数据存储系统。然后我们重复了几次有关UNICODE和ANSI的争执。Nadim希望使用ANSI编码作为后台数据存储系统文件的编码，这样文件的大小比较小。我觉得视窗都是用UNICODE编码，如果使用ANSI，我们要用一堆的转换函数，这是非常繁琐的操作。具体的原因我也不记得了，我们改了两次，终将设计定为用UNICODE编码作为后台数据存储系统文件的编码。

　　我也在设计中犯过错误，我和Said花费了三小时设计了用户界面和中间件衔接。Nadim来了以后审核了我们的工作，结果推翻了我的设计，我们花了一小时半，将所有的设计重新搞了一遍。我当时非常恼火，但是仔细看了看他的设计思路，他的思路更好，完全分开了中间件和用户界面。这时我才意识到这样成对进行设计的好处是取长补短，这种好处是有条件的，两人都必须是水平相等的；两人都必须是有一定深度的开发能力；两人都必须尊重对方，并能接受成对设计这种思想。

　　在第二个开发周期中，大的一次问题是第二个星期的星期五。我们把所有的设计源码上交后准备回家，结果单元测试输出了六十多个错误。结果我们仔细察了一下，有人没有完全做好自己的单元测试，随随便便提交了自己的代码。这个人是Said。既然出了问题，那我只好留下来陪他把问题解决。那天是2005圣诞前夕，Brian已经早退；Kevin好像有事所以也先走了；Nadim腿有上伤，比Kevin还早走了。既然是程序出错，我又是QA，所以我和Kevin说我可以留下帮一下Said。