无关敏捷，关乎责任
JJG在《The Elements of User Experience》特别强调，要让每一个人参与到网站设计中：高层管理人员，市场人员，销售人员，等等。不过这里，我想他忽略了一个很重要的群体，就是开发团队。
《The Elements of User Experience》把用户体验分为五个要素： Strategy, Scope, Structure, Skeleton, Surface。
其中最根本的是strategy，因为它是用户的需求和网站的目标。
在我们的开发过程中，拿到一个story并不意味着开发的开始，而往往很多时候我们会花很多时间论证这个story的价值所在。开发团队经常会向客户提很多问题，探究这个story的起源和目的；开发团队经常和客户一起讨论甚至争论一个story的功能或者设计，因为随着开发的深入，对项目的了解，我们有义务告诉客户我们所想，帮助客户找到真正所需。
讨论的结果可能证明开发团队是错的，也可能证明客户是错的。但双方都在讨论中对story的价值越加清晰。
因为通过争论，客户会发现
- 其实这才是我们真正想要的：经过向公司相关人员咨询，发现这果然是更好的方案。
- 原来可以通过这种更简单的方式得到我们想要的，得到用户所需要的。
- 应该丢弃这个功能，这样做是错的，这样的设计不仅对我们未来的业务发展没有好处，而且还可能成为一个束缚。
- ……
开发团队：
- 的确客户是对的，我们在实现的东西是有价值的。
- 又一次不仅帮助了客户找到了真正的价值，也避免了让自己花很多时间做一个用户不会喜欢的功能。
- ……
印象特别深刻的是在项目结束之后，客户的BA诚挚地对我们说：谢谢团队的每一个人，谢谢你们不停地问问题。
后面的那句话，我想，是他们意外得到的。所以在感谢的时候特别地提了一下。
开发团队保证正确实现客户所要的，就够了么？不，开发团队要保证正确实现客户真正想要的。
这里无关敏捷，这里关乎责任。
The Elements of User Experience
发布之后
发布之后，系统才开始在真实的数据、环境上运行，才开始经受真实用户的考验。发布，不意味着项目的结束，却是挑战的到来。如何在发布之后，快速修复影响到 系统使用的bug；如何在发布之后，快速改进在真实环境中无法承受的性能问题；如何在发布之后，快速调整用户体验较差的界面设计或者功能实现。开发团队或 者维护团队，如果不能快速响应这些突然袭来的变化，就会给客户带来损失。
同时，从发布之后出现的问题，可以反思开发过程中某些方面的不足。以下会列出我们在发布之后遇到的一系列问题，以及对这些问题的思考。
难以重现的问题
当发现bug的时候，立即想到的就是在测试环境或者UAT上重现问题，以便快速定位问题的根源。
场景
系 统发布一个小时之后，客户一封邮件过来，告诉我们有一个重要功能在产品环境上不工作：一个公司无法为她的包月套餐付费。于是，我们立即在测试环境上试图重 现问题，但失败了；UAT上也如是。这是一个重要的功能，经过详尽的测试，却在产品环境上突然出现问题，令人匪夷所思。于是，只好到产品环境上测试，果然 重现了bug。首先排除了环境的区别，那么肯定就是数据的区别。在仔细观察数据的时候，敏感地注意到一个特征：被测公司的所有员工都没有接受网站的条款。 马上在测试环境中建立同样特征的测试数据，果然重现了bug，并找到了问题的根源。
反思
有些bug会很难重现，而之所以难，根本原因在于忽略了出现bug的测试场景（包括数据、环境等因素）。导致这个bug出现的根源在于测试不够全面。如果在测试中尽量覆盖边际情况，就可以避免多数类似问题的出现。
产品环境中仅有的问题
产品环境和测试环境的差异在哪里？
场景1
这不是一个功能性bug：有一个页面在产品环境中出现了不应该有的滚动条，却十分影响页面的美观。对照测试环境和产品环境之后，发现是因为在产品环境中一个链接的url过长导致信息框出现了滚动条。
场景2
页面上有个回退链接，会回退到之前访问的页面。有些时候却回退到了网站的首页，在测试环境中无论如何也不能重现这个bug。在产品环境下，发现出现问题的页面都是从https跳转过来。查看代码，果然没有考虑这种情况。
场景3
在用某些关键词搜索的时候，会出现500错误。而在测试环境中却无法重现。非常幸运的是客户发来了产品环境的log，经过分析，发现问题在于产品环境中集成的第三方工具提供的有些数据会导致程序错误。
反思
这 些都是典型的由于测试环境和产品环境数据或者环境不一致引发的问题。如果能在测试环境中尽量保持数据的拟真性、环境的真实性，则可以尽量避免这些问题在发 布之后才被发现。但从另一方面看，出现这些问题的根本原因在于代码不够完善。场景一中前端代码的包容性不够好；场景二中引起问题的代码有一些比如hard code的bad smell，却没有被及时修复；而场景三的代码是有漏洞的，它没有很优雅地处理数据获取失败时的情况。
无法获知起因的问题
有些用户遇到了问题，但我们无法或者没有时间去一一获取这些用户的信息。
场景
新系统上线之后，所有老用户都得重新接受新的网站条款。但有些用户无法点击接受条款的按钮，严重阻碍了这些用户的回访。
反思
这 个问题可能只出现在千分之一的用户里面，试图去获取所有这些用户的客户端环境（浏览器版本）很困难，而客户又要求我们立即解决问题。所以，试图去重现问题 已经不可能了。不如凭着经验审查一下原有的代码是否有瑕疵，前端代码是否浏览器敏感。然后给出一个更通用、更完美的方案。这类问题是无法避免的，除非花费 大量时间对所有客户端环境都进行测试。但这类问题是可以解决的，比如上面那个bug我们就通过采用兼容性更好的代码解决了。
真实用户体验的问题
真实用户才是真正的测试人员。
场景1
一个页面有分页功能。用户来到了第n页，进行了一个操作之后，重定向到了第一页。而用户显然希望能继续回到第n页。
场景2
几个按钮应该排成一行，但当用户输入一个很长的名字之后，出现了换行。
反思
这类问题不算是bug，但却影响了用户的体验。测试人员虽然会站在用户的角度去测试功能，但最好的测试人员其实就是真实用户。如果有条件能在发布之前，让一些真实用户参与测试，是发现这类问题的最好方法。
遗留的疑难问题
既然是遗留的问题，肯定是难以解决的问题。
场景
系统中有几个暂时不影响发布系统使用的bug，它们被一直拖到了发布之后，因为之前“难以解决”。
反思
虽 然这些bug最终都被修复，但这是一种不正确的方式。疑难问题不应该留到发布之后：在发布之后能解决的问题，那么在发布之前也一样可以解决；如果在发布之 前确实无法解决，那么就应该选择其它方案。如果在发布之后花了很长时间也解决不了这些bug，就进退两难了。同时，维护团队一定要保证部分核心开发成员的 继续留任。如果在交付产品之后，开发团队立即全部撤离，而把系统的维护交给一群对业务和实现完全不熟悉的人，是一种很不负责任的态度。
不会有问题的问题
这个功能不是已经经过验收了么？
场景
第一眼看到客户报的有些bug时，脑中飘过的第一个想法是：这个功能肯定经过详尽的测试，而且肯定经过了客户的验收，怎么可能有问题呢？但在测试环境中确实重现了bug。
反思
之 所以在看到这些bug的时候比较难以置信，是因为我们以为这些功能已经被测试过，或者我们知道这些功能曾经被测试过。但事实是，有些功能可能根本就没有被 测过；而有些功能曾经被测过，但没有被自动化测试覆盖。同时，我发现后一类问题往往都是在last mile中被引入：在发布之前，为了解决性能问题，我们需要对设计或者实现进行一些大规模的改动；而到后期，测试人员因为功能性需求的结束而退出了团队。 当时非常担心大规模的改动会引起一些问题，在发布之后验证了这种担心。这类问题其实是可以尽量避免的：首先，更早开始性能测试和性能优化，以避免在 last mile进行大量改动；其次，last mile可能会出现赶工的情况，有大量功能的改动或者设计的变更，这时候是测试人员最不应该离开团队的时候。
不是问题的问题
客户坚持说，这里有问题。
场景1
客户说：在使用firefox浏览器的回退按钮时，能看到不实时的信息。
场景2
客户说：有一个bug… 过了一会儿，客户又说：bug好像没了。不过，总之问题出现过，你得去修复。
反思
这 些不是问题的问题，浪费了维护团队的大量时间。发布之后，维护团队需要及时地修复很多bug，应该尽量地排除不必要的干扰。在一个维护团队中，也需要维护 一个流程。我们的维护团队，由两个开发人员和一个测试人员构成。测试人员负责接纳并验证所有的bug，开发人员负责修复bug，再经测试人员测试，最后经 由客户验收。通过坚持这个流程，让团队的每个成员，都关心自己最应该关心的问题，而不应该被其它事情干扰。在发布之后，需要更加快速的反馈，而严格地执行 流程，能明显地提高团队的效率。
总结
系统在发布之后经历了一段时间的考验，bug不多，并且基本没有出现影响系统使用的bug；同时，维护团队保持了高效的反馈，及时地修复了大部分bug。高质量的代码和快速地反馈得到了客户的认可。
现在回头看这些在发布之后出现的问题，我相信，没有一个系统能确保全部避免。不过从我的反思中可以看到，这类问题大多是开发过程中的“不完美”而遗留下来的隐患，如果能做得更好，我们就可以尽早发现这些问题，以避免这些问题在发布之后才出现。
新博客，新种子
鉴于blogspot彻底被GFW，下定决心买了托管服务，搭建真正由自己控制的博客。
WebHostingPad，它号称不限空间不限流量。买了之后你会发现空间和流量都有限制，这叫上了贼船下不来了。不过10G空间和每月100G的流量对我来说已经太多了。价格很便宜，推荐购买三年的，每个月1.9美金。使用webhostingtop这个coupon code，可以优惠25美刀，最后只需要付46美刀。
发现WebHostingPad支持Rails，惊喜一下。以后可以在这里很方便的搭建一些实验站点了。
用wordpress作为博客的搭建工具，基本上是一键安装（cPanel这个控制工具很多托管服务商都在用么？）。选了一个博客模板，花了一些时间去掉广告，调整了一下布局，并fix了它的一些bug。但在IE6上显示不正常。强势地制止你使用IE6：http://www.ie6nomore.com/。每个人都应该主动放弃使用IE6，这个世界为IE6浪费的时间和金钱已经远远大于它在现在带来的价值了。
搬到了新博客之后，虽然保持了原有域名，但因为RSS地址不再一致，导致过去订阅的同学不能再看到更新。试图在.htaccess里通过rewrite使老的rss地址重定向到新的rss地址，但无耻地失败了。不想再花时间整这个。以后奔向feedburner去了：http://feeds.feedburner.com/andyhu1007 ，生活从此实现小康~~
感谢webhostingpad救助穷人，感谢wordpress救助懒人，感谢feedburner救助普罗大众，感谢我自己：一个勤劳多金的男人。
”框计算“的“框算计”
百度在2009百度技术创新技术大会上提出了一个叫做“框计算”的全新概念。
提出两点疑问：
第一个疑问：专注做购物的淘宝都没能让用户一键找到自己想要的商品，凭什么是你百度？专注做游戏的盛大都没有把所有玩家的需求覆盖，凭什么是你百度？
第二个疑问：搜索引擎的精神是开放和自由，给用户最优结果的同时，让用户保有选择的权利。百度如果变成一个路霸或者黑店，谁还愿过你这条路，谁还敢进你这家店？
百度的“框计算”不要最后反而成了“框算计”，算的不是别人，是自己。别让起点，成了终点。
我们都知道我们想要的是什么
人的内心中总有两股力量在打架。
“我想坐下来认真地看会儿书，但经不起朋友的呼唤就跟着他们腐败去了。”
”我想抛弃无规律的生活，但夜晚的寂寞让我忍不住在酒吧里挥霍自己的青春和身体。“
”我想拒绝朋友的要求，但碍于面子又不得不违心地答应。“
”我想放弃这份不属于我的爱情，但又害怕自己不能适应没有他/她的日子。“
这样的生活状态并不是我们想要的，这使我们经常生活在一种烦躁和空虚中。
你做的都是你”意识“中的事，而”我想“的却存在于你的潜意识中。”意识“和”潜意识“之间的关联出现了问题，这就是心理疾病的根源。
那这些想法为什么会进入”潜意识“，要受到压制呢？它们为什么要受到”意识“的抛弃？
”是因为我们的‘意识’不愿意面对这种情形，不愿承受处理消极情感而带来的痛苦，因而宁可视而不见。“
是的，它背后的根源是人类的恐惧和懒惰的天性。
”人生本来就是苦难重重的“，而不是安逸舒适的。这是《少有人走的路》中我最欣赏的一句话。
我们应该面对那些不舒服和痛苦，逃避的结果只能是更多的不舒服和痛苦。
人的心理成熟过程就是一个痛苦的过程。
很多人都说：我不知道我自己想要什么。其实这句话的真正含义是：我没有勇气和足够的努力去面对和争取我想要的。
—– 《少有人走的路》读后感
南京！南京！
火车站 夫子庙 鼓楼
明孝陵 中山陵 灵谷寺 音乐台
南京长江大桥 总统府 大屠杀纪念馆 夫子庙夜景
瑞金路 玄武湖 火车站
小吃
回味 — 鸭血粉丝汤
大牌档 — 糖芋苗
我的家私房菜馆 — 炭烧肉
瑞金路 — 南京第一糖蜜藕，樱桃盐水鸭
88
88，南京
爱人
站在修葺之中的外滩，面对璀璨的陆家嘴，亲吻一下身边的爱人。
AgileChina 2009: Pragmatic Agile
由在敏捷领域最具有影响力的技术社区InfoQ中文站、敏捷方法论的领导厂商 ThoughtWorks共同主办的敏捷中国技术大会（Agile China 2009），将于9月11日~12日（周五、周六）在北京举行。届时将有超过500人来自电信、金融、互联网、教育等行业在内的高级软件开发人员、项目管 理人员等参加。本次大会将特别邀请敏捷宣言缔造者、敏捷编程（XP）方法学创始人Kent Beck，敏捷开发权威人士、敏捷宣言的创始人之一，Dave Thomas，敏捷宣言签署人之一Steve Freeman等国际敏捷领域专家，以及在团队中成功应用敏捷的阿尔卡特、赛门铁克、诺基亚-西门子、华为、腾讯等公司的项目负责人参与此次大会并分享他 们的心得。
敏捷中国技术大会（Agile China 2009）是国内敏捷技术领域最高水平的大会，本次大会将由InfoQ中文站负责大会策划、营销和项目实施。InfoQ中文站在今年4月已成功举办了 QCon全球企业开发大会，邀请了国内外30多名讲师，超过550位架构师、技术总监、项目经理和高级工程师参加了本次大会，大会及其运营团队获得了空前 的好评，并誉为国内”技术含量最高”的大会。而今年的敏捷中国技术大会，也将一改往年的风格，参会者以高端开发者和技术管理者为主，融合管理和工程实践， 推广全面敏捷之路。
会务咨询： 010 – 89880682 agilechina@cn.infoq.com
赞助咨询： 010 – 89880682 sponsor@cn.infoq.com
孙子采花
庞子要下山，鬼谷子让他进山采花，为他卜卦。
正值花谢时节，庞子进到山里，花儿几近全没。好不容易采到一朵，但那花儿蔫儿模样。庞子弃之再寻，结果再也寻不着。于是回头，捡起原来被舍弃的那朵花。但那花儿因为被弃之路旁已久，已无任何生气。
孙子要下山，鬼谷同样让他进山采花。
孙子出门，见师姐蝉儿身边一水桶中正有一朵花，模样甚好。于是捡之鬼谷卜卦。
