我的Lean & Agile（精简和敏捷）经历（这才是最佳实践）

我说的精简和敏捷并不是说我的减肥或瘦身的经历。精简和敏捷就是制造业里的敏捷管理和精简库存的意思。精简和敏捷管理在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”中&