老美的国庆节自然不是10月1日，因此在我们举国同庆祖国60华诞的日子里，他们不得不呆在Office里继续上班，所以微软在那天发给我的邮件，我到今天才看到。邮件的主题是“恭喜您成为Microsoft MVP”。想起来，这已经是我的连续第四任了。从2006年10月第一次被评上MVP开始，到现在还没有一次落选，这让我感到很欣慰。实际上，在这三年的时间（第四任MVP的任期是从今年１０月到明年。不过，微软准备将MVP任期调整到与自然年相同，所以不知这一届的任期是到什么时候结束），我在社区发表了无数篇与微软技术相关的文章，同时，还撰写以及翻译（与徐宁合译）了一本书（著作目前正在写第二版，而译著的第二版也由我承担，目前译稿已经交付出版社，就等着出版了）。尤其在InfoQ担任编辑之后，我的翻译量骤增，加上我自己写的一些原创文章，以及在技术方面的日积月累，使我在申请连任MVP时，显得底气十足。
但我深知，自己现在还存在诸多不足。技术的道路是没有止境的，我丝毫不敢懈怠。现在的我，除了平时的工作，主要是为我的第二本书做大量的准备，翻阅了大量的文献与著作，更需要从项目中总结经验。目前，我关注的技术重心还是在软件架构方面。经历得越多，越觉得自己无知。我还有很长的一段路要走。或许，过一段时间，我希望能写一些系统解决方案中关于架构的文章，尤其是架构模式在实际开发的运用。我正在学习Ruby，现在的我已经为动态语言之美而深深折服。未来，我希望能够用Ruby On Rails来开发自己的个人网站。当然，WCF和WF自然不能完全丢弃，这两个重量级技术在企业开发中是如此的重要，我怎么能够就此放弃呢？
恩，在微软创新日重庆站，我还将担任讲师，负责讲解“开启Web创新新篇章——ASP.NET MVC技术与微软Web平台简介”。我期待10月15日，在重庆市图书馆，与你们见面。
极限编程中有一条著名的懒汉原则，称之为KISS原则，KISS是Keep it simple and stupid的缩写。简略地说，就是设计尽量保证简单。极限编程坚持只为今天的需求设计以及编码，而不用考虑明天。这颇有一些“做一天和尚撞一天钟”的意味。
这个原则带来一个问题，那就是我们还需要设计吗？
我们强调设计，其目的就在于设计出合理、优雅的结构，以提供具有良好复用性与可扩展性的系统，这是一种未雨绸缪，为未来考虑。而现在，我们若要遵循KISS原则，就是不再考虑明天的需求。显然，这两者的观点是相悖的。于是，矛盾出现：一方面我们需要保持设计简单，不做无谓的功能预测；另一方面，我们又需要拥抱变化，在尽可能少的改变结构与代码的情况之下，满足未来的需求。
如何解决这个矛盾。让我们先看看提出简单原则的初衷。在《敏捷开发思想之拥抱变化》一篇中，我提到需求的变化是不可避免的。即使是最优秀的需求分析师和架构设计师都不可能在项目之初穷尽所有客户要求的功能，作出最完美的分析与设计，即做到“增之一分则太多，减之一分则太少”。我们需要把握分析和设计的“度”。但事实却是，我们总喜欢越俎代庖，利用自己的经验帮助客户提出需求，而事后证明这些需求往往是多余的。我们总是在重复做着“吃力不讨好”的事情，与其如此，还不如在事先偷懒取巧。因为需求的变化总是不可控的，根据“利益趋避原则”，自然应选择对自己更有利的一个趋向。
但这种简单并不是“简陋”，即使我们不需要考虑明天的需求，一些好的重用原则与可扩展原则仍然需要遵循。例如，我们应尽量保证对象是高内聚、低耦合的；我们应遵循“面向接口编程”原则。一言以蔽之，我们需要做到：
1、减少依赖；
2、合理抽象；
3、功能最简。
简单设计还需要重构来保证设计的质量。我们之所以敢于奢谈“简单”，正是因为重构的保障。即使设计过于粗陋，合理利用重构也能够亡羊补牢。在重构过程中，我们仍然需要遵循简单原则，仅为当前的需求对系统结构进行重构。例如，我们在最初的需求分析中，只有一个功能要求发送电子邮件。那么，我们可以编写一个方法来封装发送电子邮件的实现，这个方法甚至可以放在业务对象的私有方法中。随着需求的逐步演进，新增的几个功能同样需要发送电子邮件，此时就有必要利用重构技术，将原来发送电子邮件的方法独立到单独的类中。但是，基于简单原则，我们没有必要完善所有功能，例如增加发送Meet Request的功能。因为目前的需求并不需要。
“简单”并不只限于设计。在敏捷开发过程中，我们还需要保证项目计划的简单，以及文档的简单，乃至于过程的简单。项目计划的简单可以由小步行进的迭代周期来保证，通过对项目阶段的分解，简化项目计划。至于文档的简单，我们完全可以抛弃复杂标准的文档模板，转而书写仅仅是自己需要关注的内容。至少，项目内部的文档完全可以言之有物，而不需要注重形式。我们还可以通过对项目过程进行裁剪，来保障过程的简单性。事实上，在极限编程中，很多原则和实践都是为了实现简单而提出的。例如计划游戏、小版本、简单设计，包括持续集成和代码所有权，都是为了提高开发过程的效率，这实际上也是简单的一种体现。
“简单最好”是一种心态，更是一条原则。
最 佳的架构、需求和设计出自于自组织的团队。蜂巢中的工蜂们看似忙碌，但其工作却是有序而有效，归根结底就是它们的组织架构其实是自我组织的。在自我组织的 团队中，团队是一个整体，没有角色之分、职位之分、也没有高下之分。团队成员的任务不是项目经理强加于身，而是根据自己的愿望和能力对任务进行合理评估， 并主动进行领取。被动与主动所产生的驱动力显然不可同日而语。
自我组织的团队是一个平行的组织，由于没有管理与被管理之间的关系，因而氛围更加和谐，组织更加开放，管理更加松散，这种自由化的组织方式更容易让团队成 员体现自我价值，对团队会产生一种认同感，促发他们的开发热情，从而提高开发效率。平等的关系会促进团队成员的有效沟通，自由的管理有助于发挥团队成员的 技术特长，开放的平台则能够保证协作的效率。一个卓越的团队应该是目标一致，团结协作，同时又能各司其职，有条不紊。
自我组织的团队建立在团队个人能力的基础之上。它其实是一把双刃剑。如果团队成员个人能力有限，或者自我约束能力较差，而管理人员又无法把握松散管理的度，就很可能出现一些问题。例如：
1、团队人员无所适从，不知道该做什么。很多开发人员对敏捷方法不能适应，他们已经习惯了听从命令与安排的方式；
2、任务安排不平衡，团队成员在开发过程中偷工减料。耽于安逸的开发人员或许会利用管理的漏洞或管理人员对他的信任，胡乱估计任务的工作量，或者夸大任务实现的难度；
3、自由失去节制，无论是技术方案的讨论和评审，还是任务工作量的评估，因为没有绝对权威，很容易失去控制，因纠缠于细节而让大量的讨论浪费时间。
如 何解决这三个问题？对于第一个问题，基本无解，除非你有足够的煽动力或超凡的演讲能力，改变这些开发人员的思想，乃至于开发习惯。最佳方式是循序渐进，并 对自我组织的方式进行改进，例如和传统的管理方式结合起来。或者就放弃敏捷的管理方式吧。如果说敏捷是鱼，只能在水中生活，你怎么能让它上岸呢？
对于第二个问题，需要动用团队的力量。例如对任务的评估，我们可以利用计划游戏，或者设计计划纸牌对任务工作量进行估算。总之，我们应尽量让团队对任务工作量的估算不要出现太大的偏差，使任务的开发在可控的范围内。此外，及时召开回顾会议，也是杜绝这类问题的一件利器。
第三个问题需要团队的管理者建立某些准则，例如对技术问题的讨论设定时间的限制。一旦超出该时间，就应该把问题放在一边，或者由管理者利用自己的权威和经验下定结论，而不能无限制的争执下去。
自 我组织的团队管理者需要因时因人而置宜。Larry L. Constantine在《人件集》中提到：“对于开放型的团队来说，最好的领导应该表现得像他们中的一个同事一样，能够参与所有的技术问题讨论，包括分 析、设计和系统构建。”例如在Scrum中，团队角色就是一个自我组织的团队，由团队来确定每个Sprint的工作内容。而Scrum Master就不再是控制者，而是指导者；不是上司，而是教练。他必须理解自组织团队的重要性。
自我组织是敏捷管理的精髓，也是敏捷管理成败的关键！
秉承敏捷宣言的精神（个体与交付重于过程和工具；可用的软件重于完备的文档；客户协作重于合同谈判；响应变化重于遵循计划），我认为，敏捷开发大致应该体现如下的思想：拥抱变化、自我组织、简单最好、客户至上、有效沟通、精益求精。
1、拥抱变化
Kent Beck和Martin Fowler在介绍极限编程（eXtreme Programming）时，最先提到的就是要拥抱变化。这基本上代表了敏捷阵营对于变化的一种态度，那就是不拒绝，而且还要主动求变。有一句经典的论断 说得好：“在软件开发领域中，唯一的不变就是变化。”其实，不仅仅是软件开发领域，世间万事万物都处在永恒的变化之中，这是宇宙的基本规律。奥巴马在竞选 美国总统的时候，提出的口号就是“变化”。变化才是真正的常态。
传统的软件开发过程由于过分强调文档的完整，重视与客户的谈判与签订合同。 所以，开发团队最希望的一件事情是冻结需求规格说明书。只要双方签字，需求就确定下来，不可更改。若要更改，必须经过需求变更委员会，走非常严格的需求变 更流程。如果软件开发真能如此，倒也算是我们开发人员的幸事。但现实总是残酷的，需求总是会变化。变化的原因有以下几种：
1）业务发生了变化；
2）客户对业务的理解发生了变化；
3）需求分析人员对需求的理解出现了偏差，需要修正。
对于第一点，或许我们还能够根据合同与客户讨价还价，而对于后两点，尤其是第三点，我们显然是不可拒绝的。而敏捷方法则要求团队随时响应客户的需求，针对变化给出相应的解决方案。
如何拥抱变化呢？我想可以通过如下方式来实现：
1）现场客户
很 多开发团队并不喜欢客户对他们指手画脚，甚至认为他们不停提出的需求变化让他们疲于应对。但现场客户给团队开发带来的益处还是要远远超过他带来的坏处。无 论团队中聚集了多么权威的领域专家，但真正了解客户需求的还是客户自己。也许他们很难用语言来表述自己的想法，但有了和现场客户的及时沟通，我们才能够在 发生变化的初始就能够获得第一手的资讯。如果事情总要发生，早解决绝对比晚解决要好，而且要好得多。
如果在开发中，没有办法让客户成为团队 的一员，那么我们也应该指定一位客户代表，退而求其次，也应该在团队中指定一位业务专家负责业务事宜，也就是Scrum中Product Owner的角色。总之，我们需要在项目开发中，能够让开发人员在对需求理解发生困惑时，能够明确地知道由谁来负责。而一旦需求发生变化，也必须有专门的 角色负责向整个团队或者相关人士传达。至于业务功能的优先级和重要程度排定，也必须由这个角色指定。
2）定期迭代和小版本交付
不仅要定期迭代，而且要尽可能地让迭代周期短，并及时交付可以工作的小版本发布。XP的迭代周期通常为一周，而发布一个小版本大约是一个月。而Scrum则将迭代称之为Sprint，持续时间推荐为一个月。Sprint结束就需要向客户展示当前迭代完成的版本。
敏 捷方法绝对不可闭门造车，因为需求总是可能存在二义性，且需求总是处于不断的变化中。若能定期交付一个可以工作的小版本，一方面可以给与开发团队和客户以 信心，另一方面也有助于我们及时获得客户的反馈。而衍生带来的还有一个好处是我们可以免费找到最优秀的测试人员了，那就是我们的客户。如果没有现场客户， 则小版本的交付则显得尤为重要，因为它给了我们及早修订错误的机会。
3）持续改进
开发过程总是会出现错误，无论是开发方法、技能，还是团队管理与团队合作。持续地改进我们的开发方法、管理方法与开发过程，才能够及时而有效地解决错误，避免重蹈覆辙。一个能够持续改进的团队是一个成长的团队，同时必然会是一个拥抱变化的团队。
在 Scrum中，每个Sprint完成并结束了评审会议之后，都会召开一个回顾会议，即使总结优秀经验，检讨错误与教训，团队方能够从错误中成长起来。此 外，回顾会议还能够帮助团队正确地认识自己，帮助团队成员进行交流与沟通。作为“鸡”角色的客户若能参加回顾会议，可以让客户更直观地了解团队，比提出自 己的看法，有助于在后面的开发过程改善合作的质量。
罗素说：“参差多态是幸福的本源”。我们的生活若能丰富多彩，每天都是新鲜的，就会觉得生活有滋有味，生命是有价值的，而我们的存在则是幸福而有意 义的。如果每天的生活都是在重复，人就容易过得浑浑噩噩，茫然不知生活的乐趣，最后得过且过，浪费了自己的生命。我常常觉得，作为一名软件开发人员，或许 是幸福的，因为在这个行业中，每天都有新鲜的技术与技能产生，每天都有许多未知的东西等待我们去探索，去学习，去分析。但这种幸福也许从本质上讲，是“痛 并快乐着”。新鲜的技术让我们兴趣盎然，但这种快如流星的技术更新速度，又有些让我们应接不暇。
全文阅读>>
6日晚，参会的InfoQ编辑和国际讲师们一起在恭王府边的四川饭店腐败了一次。腐败的地方选得很好，居然就在清朝第一贪官和绅府的旁边。这是我第 一次参加InfoQ的线下活动，也是与中文站编辑的初次谋面。有了网络就是神奇，虽然素昧平生，却已是多年好友。国际讲师也是济济一堂，包括 Thoughtworks首席科学家Martin Fowler，Spring之父Rod Johnson，eBay架构师Randy Shoup，《硝烟中的Scurm和Xp》作者、敏捷教练Henrik Kniberg，Dojo Toolkit的联合创始人Dylan Schiemann，当然还有我们InfoQ的老大、C4Media的总裁Floyd Marinescu。为了便于编辑与这些讲师之间的交流，组织人特定将我们这些编辑与讲师们交叉坐在一起。我正好就坐在Martin Fowler和Randy Shoup中间。Martin Fowler的大胡子看来有些威严，我只向他表达了几分仰慕之情，什么敬仰如滔滔流水之类的，就没有多言语了。反而是Randy长得比较慈眉善目，和他相 谈甚欢。谈了架构，SOA以及云计算，谈到Java平台与.NET的整合，也谈到了eBay的架构设计。除了技术，自然还要谈点轻松的内容。例如川菜、中 国文化，以及他对北京的感受，甚至谈到了旧金山的天气。抓住这个机会，我还给他宣传了我所在的城市——重庆，欢迎他到重庆去品尝品尝重庆火锅。这是 Randy第一次到北京，所以多向他灌输一点中国的悠久文化，也可以培养培养他对中国传统文化的敬仰之情。我教他说中文，听他大着舌头痛苦地讲着“你好 ”，颇感到Randy的几分可爱之处。没想到Randy还知道中文“花椒”，一问之下，原来他妹妹的什么亲戚曾经在香港呆过一段时间，还曾向他们邮寄过“ 花椒”。原来如此。
全文阅读>>
这里所谓的“读书时代”，并不能与“学生时代”划上等号，盖因读书的时节并非一定要在作为莘莘学子的时候，只要有闲暇时，未尝不可以读书。
我素来对文字报有极高地热忱，我不敢想象仓颉造字鬼神哭泣的境况，但却知道如若没有文字，则世界不知会黯淡几分？孩童之时，喜读连环画，很多人会沉迷于图
画中的各种人物模样与风景，但我往往会因为阅读画下的文字，而忽略对所谓“画”的领悟。所以，对于我在无知幼童之时，竟然喜欢抱着繁体字的西游记吃力地阅
读，也就不足为怪了。当时的四大名著，《西游记》给我的冲击主要是一种让人激动的幻想，以及为那大闹天宫，打得众天兵天将屁滚尿流的威风凛凛的齐天大圣的
风采所折服。其实我最爱的还是那本“诲盗”的《水浒传》，那群傲啸水泊梁山的108众好汉，在一个男孩子的心理，完全是内心盼望着在长大之后也要成为这样
的英雄。也许，幼时的我，会认为这样才是一种挥洒方遒的写意人生吧！
《三国演义》对于儿时的我来说，其实太过于深奥了。但我记得那个时候有一个书系，唤作“小图书馆系列”，现在想来对我影响颇大。我始终觉得编写这一系列的
作者们必然是一些高超的小说家，能够在不失去原著原味的基础上，写得那么的浅显易懂。我阅读的三国演义，其实就是这一系列的三国演义改编版。我对这个小图
书馆系列始终抱有好感，我记得自己还阅读了《大卫·科波菲尔》、《汤姆大叔的小屋》以及《汤姆·索亚历险记》等国内外名著的改编版本。
《红楼梦》在我幼小的心灵里，充满了胭脂水粉的柔腻，在那时还不懂得什么是真正的文学作品，总会天真的认为《红楼梦》应该是女孩儿读的书，因而那时的我对于这样一本惊天之作，实际上是不屑一顾的。或许，每个男人的幼年心理中，都应该有一个英雄的梦吧。
我没有机会去看《封神演义》、《七侠五义》，也不曾看过《说岳全传》，因为那个时候，所谓通俗小说实际上是金庸先生的时代。“凡有井水处，皆能歌柳词”，
其实有井水之处，皆在读金庸小说，似乎也能说得通顺。我已经不记得自己阅读的第一本武侠小说是什么了，但还能清晰地记得在阅读残本的《射雕英雄传》时候的
那种眉飞色舞。都说武侠小说是成人的童话，其实在孩童的心理，又何尝不是童话呢？
初中的时候，我最喜欢翻弄舅父的书架。舅父是教授中文的，是以他的书架对于我而言，无异于宝山。也正是在翻弄书架的同时，我知道了罗曼·罗兰，列夫·托尔
斯泰，知道了契珂夫，屠格涅夫，还知道了拜伦，雪莱，济慈，当然，我更知道了周作人、胡适、钱钟书、沈从文、梁实秋、林语堂、郁达夫。我像一个饥饿的人，
阅读着约翰·克里斯多夫的故事，也为复活中玛斯洛娃的悲惨命运落泪，我背诵着拜伦如白银一般闪光的篇章，为济慈最后写在水上的名字而神伤。我像膜拜缪斯之
神一般，学着朱自清的锦绣华章，揣摩沈从文凤凰一般清艳的文字，为郁达夫的愁绪而感伤不已。
我还尝试着去阅读《诗经》、《离骚》，但最喜欢的还是李太白的豪放与瑰奇，尤爱他的乐府长诗，诵读出来也倍觉豪迈与旷达。我喜欢曹孟德的诗文，激赏曹植飘飘如仙的《洛神赋》，尤喜唐宋八大家，突然觉得读这些大家之作，则其余人的文字再无足观矣。
高中的时候，我终于体会到了《红楼梦》的超凡之处，虽然只是一鳞半爪，却也不得不为之而倾倒。如果说命运安排我流放到一个渺无人烟的荒岛，假设只允许我带
一本书的话，我会毫不犹豫地选择《红楼梦》。读《红楼梦》一遍是万万不够的，实质上，取出《红楼梦》来，不管翻至何页，你都可以饶有趣味地阅读下去，而每
读一遍，你又会有新的体会，新的感触。小说的魅力竟至于此，或者也可以说是一种灵魂的旅游吧。
对于进入大学的我们而言，才真正可以算是脱缰的野马，终于体会到了无拘无束的自由。至少，我可以不用偷偷摸摸地看金庸小说了。在将“飞雪连天射白鹿，笑书
神侠倚碧鸳”一一梳理个遍之后，我们慢慢发现了一个读书的宝库，那就是校图书馆的样本书库，除了馆藏的古籍与工具书外，全馆的书籍都要在此留存一本的。或
许是为了增加效益，样本书库的部分书籍以收费方式对学生公开。于是，我和几个室友利用课余时间帮助图书馆老师打打杂、跑跑腿，终于赚来了可以自由出入书库
的权利，从而开始了长达四年的读闲书生涯。
既然是闲书，也就无所谓书的类型和品味，但求兴之所致。随笔、小说、诗歌……无论体裁；文学、历史、政治……无论课目；凡是能给与我趣味的满足，能有一字
之得，统统都不放过。这样的闲读生涯，荒废了我本来的专业，却也开拓了视野，博览了群书，所失与所得，很难辨得清是与非，功与过。
在样本书库晃悠的时期内，最令我雀跃不已的是图书馆进新书的时候。由于是样本书库，但凡馆藏的新书到了，都得放一本到样本书库中。而我们则负责帮助老师对
这些新书进行分类，然后放入各自科目的书架上。有我们这些超级书虫在，可苦了那些秋水望穿期待着新书的其他同学们。正所谓“权利腐败”，在我们手上就产生
了书籍的“贪污”，为新书分类的时候就将自己感兴趣的书籍直接过滤了，他人若要阅读这些书籍，那就抱歉，只有等我看完之后才有机会拜读了。
如果说大学四年有什么值得记忆的时刻，或许就是我们在图书馆度过的快乐时光了。今后，也不可能再有这样的机会，蠹鱼一般钻进书山之中，忘我的阅读吧。
工作以及读研的几年，几乎就要失去读书的乐趣了。闲适的时光固然多多，然而闲适的心情却寥寥。由于受到一个人的影响，我开始阅读余光中。诗是诗人之诗，文
是学者之文，虽偏居海外孤岛，心却包容世界。这个时期的我，或许是因为工作的负累，更愿意阅读一些轻松悠闲的小品文章，最爱董桥的英式幽默与中式诗意，王
小波的嬉笑怒骂与诗人情怀，以及他冷眼旁观的静默人生；为杜拉斯的《情人》而忧伤，在博尔赫斯的《小径分岔的花园》中迷失；然后在李商隐的《锦瑟》中找到
自己惘然的一叹，最后在贝多芬的金铁铿音中找到慰籍的力量。
其余，就是阅读专业书的日子了。我终于发现了软件设计艺术的乐趣，这些乐趣都集萃在我的著作《软件设计精要与模式》中，在该书的序中已经记录了阅读的足迹。
双方前锋紧紧地站在一起，裁判哨声响起，球被掷出，双方球员奋力拼搏，反复地冲刺，竭尽全力向自己的目标冲去。这是英式橄榄球中Scrum的场景。然而这样的活动，却被Ken Schwaber和 Jeff Sutherland巧妙地借助隐喻的方式引入到敏捷项目管理中，仔细思索，却又如此的恰如其分。在橄榄球运动中，固然需要强健的体魄与迅捷的速度，但更重要的却是组织、协作、交流，以及一位优秀的指挥官。虽然二者的方式不同，然而赢得比赛与成功交付产品的目标其实是完全一致的。
Scrum是一种灵活的软件管理过程，它可以帮助你驾驭迭代、递增的软件开发过程。Scrum方法最初实践于Easel公司，现已被数十家公司数百个项目开发中应用，适用于需求难以预测的复杂商务应用产品的开发。作为一种项目管理方法，Scrum与其它方法颇有不同之处，规则与名称也自成一套体系。在Scrum管理活动中，包含三种不同的角色：Scrum Master，Product Owner，Team。Scrum的每一次迭代被称为Sprint，意为“冲刺”，生动形象地展现了项目开发活动的迭代过程。Scrum将功能需求称之为Product Backlog，它们通常是由Product Owner提出。Product Backlog会在Scrum Master主持的Sprint Planning Meeting中确定，并在确定了Sprint之后，形成Sprint Backlog。Scrum非常重视团队成员的交流，除了Sprint Planning Meeting之外，还要求召开Daily Scrum Meeting，以及Sprint Review Meeting与Sprint Retrospective Meeting。
虽然Scrum从名词的定义上来看，显得有几分离经叛道，但其本质仍然秉承了敏捷开发思想。重视成员的交流、功能需求的确定、迭代版本的交付、项目风险以及产品质量的控制。Scrum提供了一种经验方法，它使得团队成员能够独立地、集中地在创造性的环境下工作。Scrum过程是敏捷的、自组织的，产品的开发则是增量的迭代交付方式。
《SCRUM敏捷项目管理》一书全面细致地介绍了Scrum方法。作为Scrum的创始人与倡导者，作者Ken Schwaber将自己多年以来实施Scrum方法的经验、体会、教训浓缩在这本仅有163页的薄薄小书中，真可谓是字字珠玑。全书只有9个篇章，却涵盖了Scrum的方方面面，包括Scrum方法概述，Scrum角色的职责，如何从混沌中提炼Product Backlog以及如何划分Backlog的优先级，如何制定Scrum项目计划，跟踪项目计划的执行，以及如何在大规模项目中应用Scrum方法。书中的附录A更是Scrum方法的精华，总结了实施Scrum方法必须遵循的基本原则。
全书并没有长篇大论的理论分析与描述，而是通过一个个真实典型的项目案例，逐步为我们展现了Scrum的适用场景与实施细则。以实践指导实践，是本书最大的亮点，从而使得本书摆脱了通常所谓的项目管理书籍的那种沉闷与枯燥，以及空中楼阁般的不切实际。这得益于作者娓娓道来的深厚文字功底，更重要的是作为敏捷联盟的创始人之一，作者深谙敏捷之道，能够目光敏锐地发现传统项目开发的瑕疵；而作为Scrum的倡导者，对于Scrum方法的实施早已达到游刃有余的境界。因此，本书可以说是ken的厚积薄发之作。
Ken善于以案例启发读者。Scrum提供了一种经验方法指导团队成员独立、高效地完成项目开发，而本书则以项目实践指导读者从阅读中获取经验。全书的每一章几乎都提供了“Lesson Learned”小节，从而加深读者对Scrum方法的理解。
理解Scrum方法并不困难，最大的困难在于如何正确地在项目开发中应用Scrum方法。即使是富有经验的Scrum Master，在面对不同的场景，也需要做出不同的抉择。正如书中所述：“The ScrumMaster applies Scrum theory to projects with different types and degrees of complexity.”项目的类型不同，复杂度不同，则应用的Scrum方法就会有所区别。
以书中列举的Tree公司的项目为例，就需要成立XML Team，WebPub Team以及多个Journal Team。而在Journal Team中，Scrum Master并没有固执地按照Scrum原则安排7个成员，而是由9个成员组成，其中包括了兼职的XML成员与WebPub成员。
在MegaFund项目中，为了合理地分解任务与团队，在提炼Product Backlog时，则将非功能性需求的优先级提高到功能性需求之前。这样的调整，同样是根据项目的特点而定。
Scrum方法的优势在于它的设计自始至终具有很强的适应性。如何在自己的项目开发中准确地应用Scrum，让自己成为合格的ScrumMaster，让团队的需求分析师或者客户成为合格的Product Owner，让自己的团队成为合格的Scrum Team，相信你从本书能够找到扣开Scrum之门的钥匙。本书无法使你在一夜之间就成为一名优秀的Scrum大师，但本书作者Ken Schwaber却可以给你高屋建瓴般的整体指导，使你迅速成长。毫无疑问，《SCRUM敏捷项目管理》已经给你指出了一条掌握Scrum项目管理的终南捷径了。
在微软商店挑花了眼，终于花完了$150元，买到了自己还算满意的商品。最满意的是WM USB Powerd Speaker，有了它，我就不必再为laptop音量太小而烦恼了，我有了自己的移动影院。
虽然已经有了40G的移动硬盘，但再增加一个U盘也不为过。1GB的U盘价值$62.99似乎太贵了，看来如果要到美国生活不是件容易的事，如果不是Microsoft馈赠的，我还是舍不得。遗憾的是这个U盘没有mp3的功能，不然就太棒了。
微软商店提供的女士商品实在是太少了点，有心给老婆买一件好的，挑来挑去实在挑不出什么好东西来，最后只得买了个杯子了事，实在有些愧对老婆了。
没有什么好看的衣服，T-Shirt的设计也很一般，特别是for ladies的，就更少，而且剩下的还都是大号。最后没有办法，只有随便给自己挑了一件T-Shirt，主要是为了花完这$150元钱。此外买的一支笔，同样出于这样的目的。
鼠标是值得买的，虽然自己已经有了一个鼠标，但还是无线鼠标用起来更爽一些。
最后只剩下$0.04了，基本上做到了不浪费一粒子弹的目的。节约是美德，即使是别人白送的，丢了也怪可惜的。如果商店还有4美分的商品，我也会毫不犹豫放到购物车里，嘻嘻。下了订单，就等着收货吧！
自己申请了一个域名。本来想申请自己的中文拼音，不过已经被人注册了，无奈只有用英文名，所以域名是：
http://www.brucezhang.com。也想注册www.wayfarer.com。不过这个当然早就没有了。
这个个人主页其实也就是个人博客，不过约束会少一些，只要自己愿意，都可以放在上面。主要还是技术性的文章。我在博客园上发表的文章，会陆续迁移到上面。之后发表的新贴，就会出现在自己的主页上了。除了自己一些私人化的文章，其余文章仍然会在博客园和博客堂更新。欢迎大家访问，热情评论，呵呵:)
Google提供的语言工具（http://www.google.com/language_tools?hl=zh-CN）其实是一个好东东，用来当作辞典是绰绰有余，它还支持多种语言，真是一份免费的晚餐。
不过，你注意到了吗？如果你要利用Google的语言工具将“百度”翻译成英文，你得到的结果是“Lower”。面对搜索引擎尤其是中文的搜索引擎中最强有力的竞争对手，Google难道已经失去应有的恢宏的气度，对其竞争对手开始故意的嘲讽和贬低？也许是Google中天才们一时兴起的玩笑之作，但在我的眼中看来，却未免有失厚道了。
不要说这是百度的正宗英译，我相信从美国回来的李彦宏不会给自己公司取这样的英文名。也许是Google的老外们并不理解“百度”这两个字的含义，其实是那么的充满诗意，“众里寻她千百度，蓦然回首，那人却在灯火阑珊处。”
Windows Communication Fundation(WCF)的版本一直未有最终的版本，估计要在Vista的正式版出来才会确定（也包括WPF，即avalon）。由于没有和Visual Studio 2005一起发布，如果需要写WCF（即indigo）的程序必须另外获得WCF的版本。
WCF的版本是在不断的更新的，这也为我们开发WCF的程序带来一定的困难。在WCF的官方主页（http://windowscommunication.net/）上，提供了January CTP的下载（Download the Windows Communication Foundation Go-Live Release
）。得到的安装包版本是Runtime Component 3.0 Beta2，但实际上安装后的程序集版本为2.0.0.0。在Visual Studio 2005下，可以正常添加System.ServiceModel程序集，程序集版本为2.0.0.0，并被添加到GAC中。我写了一个Hello World程序，Service是可以运行的，但我却无法找到SvcUtil.exe，这样就无法自动生成相应的配置文件以及服务的Proxy。这显然是缺少SDK的原因，在下载页面中有如下说明：
This CTP release supports Visual Studio 2005 RTM and the .NET Framework 2.0 RTM. The Microsoft? WinFX? SDK contains documentation, samples, and tools designed to help you develop managed applications and libraries using WinFX. You can install the SDK that corresponds to this release here.
然而点击下载SDK，却提示“The download you requested is unavailable. ”下载失败。
事实上，微软已经推出了February 2006 CTP。下载页面是：
http://www.microsoft.com/downloads/details.aspx?FamilyId=F51C4D96-9AEA-474F-86D3-172BFA3B828B&displaylang=en
这个页面下同样可以下载Runtime Component 3.0 Beta2。在安装该版本之前，需要将之前安装的相关版本卸载。此外提供了SDK的链接http://www.microsoft.com/downloads/details.aspx?FamilyId=9BE1FC7F-0542-47F1-88DD-61E3EF88C402&displaylang=en
我们可以通过该链接下载SDK。安装SDK可以选择网络安装或本地安装。如果是本地安装，文件大小为1.1G左右，是ISO文件。安装了SDK后，在program files目录下，有microsoft SDK目录。在microsoft SDK\windows\v1.0\bin目录下，我们可以找到SvcUtil.exe工具。仔细检查该文件的信息，版本是v3.0.50727.357。如果我们用SvcUtil.exe生成Proxy类，可以发现它引用的System.ServiceModel版本是3.0.0.0。例如GeneratedCodeAttribute：
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
此外，2.0版本和3.0版本的System.ServiceModel在类的定义及方法和属性是有区别的，例如Binding。在2.0下，Binding类是在System.ServiceModel namespace下，而到了3.0，则放在了System.ServiceModel.Channels Namespace下。此外，生成的config也和2.0版本的不一致。也就是说，如果利用3.0的SvcUtil生成的文件，在原来的2.0版本，也就是Jan 2006 CTP下，是无法通过编译的。
我安装了Feb 2006 CTP的Runtime Component后，此时的版本应该和我下载的SDK是一致的。然而当我使用Visual Studio 2005创建项目，添加对System.ServiceModel的引用后，却在添加引用对话框中找不到该程序集。如果察看GAC，该程序集是存在的，版本信息是3.0.0.0。检查Machine.Config文件，有如下节的配置：
<sectionGroup name="system.serviceModel" type="System.ServiceModel.Configuration.ServiceModelSectionGroup, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
但为何却无法添加引用呢？
如果我卸载Feb 2006的版本，重新安装Jan 2006，版本信息是2.0.0.0，添加引用则是正常的。奇怪的是，如果此时保留该引用，重新卸载Jan 2006，再安装Feb 2006。打开该项目后，发现原来添加的对System.ServiceModel的引用仍然存在，虽然显示Assembly Property时，显示版本信息是0.0.0.0。但编译却是成功的，也能正常地运行。显然此时引用的确实是3.0.0.0版本。再通过Visual Studio 2005添加引用，还是无法找到System.ServiceModel程序集。
莫非是我的Visual Studio 2005版本的问题？或者这本身就是Feb 2006 CTP的一个bug？存疑！
今天，我偶然发现一个网站Business Opportunities Weblog，你可以输入自己的博客地址到这个网站（
http://www.business-opportunities.biz/projects/how-much-is-your-blog-worth/）中，它可以评估你的博客价值。到底有什么用，我还没仔细看，不过很好玩。我评估了自己在博客园的博客价值
http://www.cnblogs.com/wayfarer，结果让我很自豪。页面显示$2,258.16。要真换成美元，我倒是发财了，呵呵。
好玩的是，如果我用
http://wayfarer.cnblogs.com输入，得到的价值就是$0.00了。我把自己在博客堂的博客地址
http://blog.joycode.com/wayfarer/输入，结果仍然是$0.00，大概是因为这个博客内容也不多，申请的时间也不长吧。我把博客园站长dudu的网址
http://www.cnblogs.com/dudu输入，结果就让我汗颜了，页面显示的值是$19,134.36。再试一试开心
http://blog.joycode.com/joy的，哈哈，是$21,452.52，比dudu略高一些。
大家可以试试！
终日在技术海洋里倘佯，总不免会疲倦，来点文学小品，既能解乏，又能消遣，闲适写意，不亦乐乎？在北京度过两个夏天，体味北京的秋还是第一次。
初次体味北京的秋，实在是还不知道如何体味，秋已经来了。北方的秋与南方的秋是大不相同的，而北京的秋与重庆的秋比较起来，则是异乎寻常的迥异了。重庆的初秋，与夏天并无二至，更准确的说，“秋老虎”的狠劲儿，令人感觉比在大暑的时候还要难受。热，是真正的闷热，是没有空调风扇就活不下去的炎热。室外是明晃晃的亮，白的一片糊涂，与天混沌在一起，近乎于没有界限。都说“秋风习习，夜凉如水”，重庆的秋天即时是在中秋月明之际，还是被夏日所侵占，久久不肯归还。渐渐的，落叶下来了，等一阵秋雨下来了，这天儿才日复一日的下凉，单衣则渐渐地不能敌过秋风的凉意了。
从前读郁达夫的《故都的秋》，总是无法体味那种“特别来得清，来得静，来得悲凉”的北国之秋。由于总是被故乡的秋所牵绕着，所误解着，因此在北京度过夏天后，不觉之间，秋天已经来了，果然那么地清，那么地静，那么地悲凉。悲凉只是一种暗暗的思绪，而秋日的清与静，却是特别的明朗，我以为，这确乎可以贴切的形容这秋日中的北京城吧。
说是北京城，其实应该是在北京的城郊。因为少了车水马龙的喧嚣，所以那份静谧，就愈发让人回味隽永了。偶尔还会在树间草丛响起鸟儿的啁啾，鸣声婉转，在寂寞的天地里，仿若流动的行云，顿时使得一幅洗墨的画卷，多了几分卷舒自如的生趣和自在。可惜，少了古雅的四合院，也少见北国的槐树，至乎槐树叶间撒落的轻柔的落蕊，北京此时的秋味亦然减色不少，幸而在晚间，时而能清晰的听到秋虫的吟唱，在夜色之中传来，那么的渺茫而寂寥，在异乡人的心头，确实有几分悲秋的意味了。
北京的秋，让我最不可想象的还是天的高与远，还有那浸入得很深的，好似带着水气一般的蕴蓝的颜色。在这样的秋空下，景色即使有几分破败，即使有几分衰落，如此的秋也大可赞美了。事实上，处在这北京的城郊，放眼望去，确实能见到大片大片衰草萋萋的荒野，然而在这样高的天空下，反而有种凄然的美丽；尤其是瓦蓝的天下，更有鸟雀翻飞其间或者鹰隼高傲的盘旋，为这秋色增加了旷远的妙趣，实在是秋意“盎然”。假如趁着秋高气爽，到故宫、前门或者北海一带，看黄瓦红墙在如此高远的天地间存在，委实能感受到一种皇家气派。倘若是在四盒院里，在槐树的叶间缝隙仰望青天，对于北京的秋的理解，又是另一番滋味吧。听说香山的红叶已经红了，在这样的秋空之间，又会是何种颜色？陶然亭不曾去过，不过在颐和园的荡漾的湖水里，芦花凋残，破败在水里，站在桥上，看着那一片碧水，映照着蓝天，必然是格外的美丽吧。
所以说，北京的秋，所有的清，所有的静，乃至于悲凉与寂寥，全是因为这格外高、格外远的天空使然吧。如果将北京的景儿，诸如“陶然亭的芦花，钓鱼台的柳影，西山的虫唱，玉泉的夜月，潭柘寺的钟声”，搬到重庆那低沉压抑如锅炉罩子的秋空下，也体现不出北国这种特别的秋的意味吧。这么说，重庆的山水在秋日里，总是少了几分颜色啊。
北京的秋天，雨似乎格外的少，秋风却不曾断过。所以说，北京秋天的凉意，一大半是这秋风带来的吧。虽则这风并不算过分的肆虐，但有时候在夜间，也能听到窗外风声的呜呜。秋天顶适意的是秋日，因为云少，阳光没有遮拦的落下来，洒在身上格外的温暖。即使有秋风吹过，也是一种凉爽的感觉。一旦夜幕降临，太阳失去踪迹，月亮睁着冷眼，气温陡然的降下来，“夜凉如水”的形容就再贴切不过了。重庆则不然，虽然阳光的散去，稍稍消去几分热气，但夜晚的凉意与白天相比，却也多不了几分。如果是初秋与中秋之间，重庆夜晚的暑热依然是难以抵挡的，待得秋雨下来，方才会暑气褪去。由于天地混沌，云层密集而厚，在夏日里猖狂的艳阳，此时却暴露出色厉内荏的本色来，龟缩在云层里。此时重庆的晚秋，固然是秋风秋雨，但秋的意味却已经被冬日的严寒所替代了。因此，重庆的夏秋之间，总是那么严厉的热，然后是严厉的寒，却少了几分默默的温情，好叫人在心底把秋天留恋。
已近秋末了，不知道北京的寒冬会是怎么模样？想着这样的秋季就这样逝去了，不免有几分留恋与惆怅。如我这样的漂泊者，在下一个秋天，又会在哪一个城市的秋空下，体味这秋的况味？
