说明：本博文最早发布于本人的新浪博客。
起源于Larry的一篇微博，我对这本书有些感兴趣并决定提高优先级先读一读。亚马逊上的英文原版评价三星半，豆瓣上中文版评价7.6分。英文原版在O’Reilly的网站上以Creative Commons 3协议分享出来，大家可以免费看；中文版么，@图灵郭志敏之前发过微博分享迷你书，然后，译言上似乎也有翻译小组翻译了一部分。
总体来说，个人感觉亚马逊和豆瓣上的评分比较真实地反映了这本书，IT职场的老油条看起来可能都会觉得有点初级或小儿科，但我想对于一些刚刚走上项目经理职位的朋友们，还是很值得一看的。当然，我自己并未亲身经历项目经理的角色，也有可能是我并未对某些部分感同身受。书中的文章偏重经验的介绍和分享，类似于技巧、诀窍之类的文章，所以，整本书并没有一个所谓的线索或主线，也并非一个完整的知识体系。
个人比较喜欢的篇章包括：
- 尽早让用户参与：这也是Standish Group的CHAOS调查中，多年来都位列首位的原则“User Involvement”。
- 避免打地鼠式开发：关注可延续性的开发速度，这也是敏捷原则所要求的。
- 为团队增添人才而非技能：他们是“人”不是“资源”，不要只关注完成“项目目标”需要的“能力”，还要关注承载这些“能力”的“人”。
- 优秀与普通的天壤之别：讲过很多次的东西，优秀和普通工程师的差距，以及人数增长带来的沟通压力。
- 矛盾体的需求说明书：要将用户需求和系统功能规格说明进行区隔。
- 授权-蒂姆的故事：这让我回想起以前有段时间不被理解的日子，因为我的思维超越了救火队员的模式，更期望从“预防”的角度做事，而不被理解，也被认为绩效欠佳，令我非常不爽。千里马还需伯乐，太对了。
- 遭遇敌人……敌人就是我们自己：软件开发团队的成员们一定非常高兴有人愿意理解他们，只是，我在想，如果他们需要理解这么多人才能开始工作，那么。。。是否需要他们呢。。。
- 艾丽丝不是美国人了：多站点开发、多时区、多语言的项目群体，绝对是软件开发的巨大挑战，敏捷社区多数人对此的解决办法是“Don’t Do It”。
- 要现在不要马上：“快速的成功仅仅比迟来的成功好上一百倍，但快速失败可比迟来的失败要好上百万倍。”
- 速度就是生命，越快越好：“科学研究证明，对于特定的行动、战术和表现形态而言，具有优势的是最佳速度，而非超常速度。”，我感觉这篇文章很贴合我在今年敏捷中国大会上的演讲主题《速度——敏捷的丹田之气》。
- 做实际工作的人才是最好的估算人员：让干活的人来估计，这才是王道。所以Scrum里说团队应该享有决定自己能做多少的权利。
- 状态的假象：这就是敏捷原则中所说的“可工作的软件是进度的首要度量标准。”
- 不要总是扮演信使、你没有控制住、分享观点、善于支持的组织就能获得成功：他们和我之前微博中提到的“全景”、“透明”的问题很相关，参考http://weibo.com/1408827293/xkbABxFd5、http://weibo.com/1408827293/xkbIFvuKi、http://weibo.com/1408827293/xkc6PrRjb。
