硝烟中的Scrum和XP
出版社:infoQ
出版日期:2008
ISBN:9789781430329
作者:Henrik Kniberg
页数:133页
内容概要
Henrik Kniberg（henrik.kniberg@crisp.se）是一名咨询师，在斯德哥尔摩的Crisp公司（www.crisp.se）工作。他的专长是Java和敏捷软 件开发。
自从第一本有关XP的书籍和敏捷宣言问世以来，Henrik就开始拥抱敏捷原则，并尝试在不同的组织中进行有效应用。在1998年至2003年间，他作为Goyada的合作创始人和CTO，构建并管理一个技术平台和30人的开发团队，充分试验了测试驱动开发及其它敏捷实践。这个网站上有他的更多信息：http://www.crisp.se/henrik.kniberg
书籍目录
第1章 简介
免责声明
撰写本书的原因
Scrum到底是什么
第2章 我们怎样编写产品backlog
额外的故事字段
我们如何让产品backlog停留在业务层次上
第3章 我们怎样准备sprint计划
第4章 我们怎样制定sprint计划
为什么产品负责人必须参加
为什么不能在质量上让步
无休止的sprint计划会议
sprint计划会议日程
确定sprint长度
确定sprint目标
决定sprint要包含的故事
产品负责人如何对sprint放哪些故事产生影响
团队怎样决定把哪些故事放到sprint里面
用本能反应来估算
用生产率计算来估算
我们用的是哪种估算技术
我们为何使用索引卡
定义“完成”
使用计划扑克做时间估算
明确故事内容
把故事拆分成更小的故事
把故事拆分成任务
定下每日例会的时间地点
最后界限在哪里
技术故事
bug跟踪系统VS．产品backlog
sprint计划会议终于结束了
第5章 我们怎样让别人了解我们的sprint
第6章 我们怎样编写sprint backlog
Sprint backlog的形式
任务板怎样发挥作用
燃尽图如何发挥作用
任务板警示标记
嘿，该怎样进行跟踪呢
天数估算vs小时估算
第7章 我们怎样布置团队房间
让团队坐在一起
让产品负责人无路可走
让经理和教练无路可走
第8章 我们怎样进行每日例会
我们怎样更新任务板
处理迟到的家伙
处理“我不知道今天干什么”的情况
第9章 我们怎样进行sprint演示
为什么我们坚持所有的sprint都结束于演示
sprint演示检查列表
处理“无法演示”的工作
第10章 我们怎样做sprint回顾
我们如何组织回顾
在团队间传播经验
变，还是不变
回顾中发现的问题示例
第11章 sprint之间的休整时刻
第12章 怎样制定发布计划，处理固定价格的合同
定义你的验收标准
对最重要的条目进行时间估算
估算生产率
统计一切因素，生成发布计划
调整发布计划
第13章 我们怎样结合使用Scrum和XP
结对编程
测试驱动开发(TDD)
在新代码上进行TDD
在旧代码上进行TDD
增量设计
持续集成
代码集体所有权
充满信息的工作空间
代码标准
可持续的开发速度／精力充沛地工作
第14章 我们怎样做测试
你大概没法取消验收测试阶段
把验收测试阶段缩到最短
把测试人员放到Scrum团队来提高质量
测试人员就是“验收的家伙”
如果没有任何事情需要测试，那测试人员该做什么
在每个sprint中少做工作来提高质量
验收测试应该作为sprint的一部分么
sprint周期vs验收测试周期
方式1：“在旧版本可以产品化之前，不构建新特性”
方式2：“可以开始构建新东西，但是要给将旧功能产品化分配高优先级”
糟糕的方式——“只关注构建新东西”
别把最慢的一环逼得太紧
硝烟中的Scrum和XP
……
第15章 我们怎样管理多个Scrum团队
第16章 我们怎样管理分布式团队
第17章 ScrumMaster检查列表
第18章 结语
有关Henrik Kniberg
作者简介
在本书中，作者Henrik Kniberg讲述了他在一年的时间里，带领40人的团队实施Scrum的过程。他们试过了多种团队尺寸（3～12人）、sprint长度（2～6星期），定义“完成”的不同方式，不同的backlog格式，各种测试策略，在多个Scrum团队之间进行同步的多种方式。他们还尝试过XP实践——持续集成、结对编程、测试驱动开发等等，还试过了把XP跟Scrum组合。
本书描述的是一个成功敏捷团队的工作过程，没有理论、没有引用、没有脚注、没有废话。读者可以把它当作一些基础实践的入门指南，帮助团队进行正确实施——但不能模仿，你需要了解自己所处的环境，进而对具体实践做出取舍，创造出属于自己的过程。
发布书评
精彩书评 (总计14条)
-
翻译的不错， 浅显易懂， 非常具有实战意义。完全是作者亲身体会的总结。不过感觉scrummaster相关的东东介绍的太少了。====================以下是读书笔记的分割线===================Scrum不是方法学，它是一个框架。也就是说Scrum不会告诉你到底该做些什么。Scrum 的强大和令人痛苦之处就在于你不得不根据自己的具体情况来对它进行调整。产品 backlog是 Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。 -
这本书是我所看的Scrum方面图书的一本。作者讲到了很多Scrum实践中的小细节，比如在Sprint计划会议的时候有些人不知道该干什么如何处理等等。其实给我印象最深刻的是对生产率的相关运用。比如生产率结合sprint来预测项目进展。 -
首先，个人觉得这是一本不错的小书。说它小，是因为这本书很薄，100多页吧，无非就是程序开发那点事。说它不错，是因为它很实用，没什么花哨的东西。其次，这是一本scrum的实施指南。周围的很多程序员，看了太多的敏捷的思想，听了太多的敏捷的原则，xp、scrum、sprint更是耳熟能详，我想，我们缺少的正是这样一本现实中的敏捷开发指南。从制定backlog（user story），再到制定sprint计划（iteration），任务跟踪，开发间布置，如何开早会，如何测试等等，你会发现，本书描写的是项目开发中的那些最最平常，却又最最重要的事情。如果你没有参与过敏捷开发，那么看本书，可以让你了解敏捷开发在项目的过程中到底是怎样实施的，我想这比空洞的说教要有用的多。如果你正在参与到敏捷开发中，那么看本书，至少可以让你了解别的团队，别人是如何实施敏捷开发的，从中我们收获什么样的经验和教训。最后，基于国内的情况，书中的一些方式我们可能无法实施，不过，我认为依然可以从中学到很多东西，从而进一步理解敏捷开发的实质和敏捷开发的应用哲学。OK，不多说了，just read it！
精彩短评 (总计80条)
-
#阿一读书# 《硝烟中的Scrum和XP》：把它放在《Scrum要素》之后阅读绝对是个明智的选择：两书一本重理论一本重实践，一本是框架一本是方法，一本是授道一本解惑。这本书其实两年前就看过，只是那时候太稚嫩，只看到了最肤浅的东西…… -
作者不是教条的列举scrum里面一个个价值观和XP中一个个技巧和“术”，而是结合自己的项目阐述在实施scrum过程中的得失以及一些心得。结合目前我们这边的项目情况，得到的启发还是有不少的 -
非常实用的书，真正的干货能够帮助我更好的自我管理，指导团队管理 -
在网易的时候，项目管理与此类似，效率还是很高的 -
再读，仍然收获很多 -
浅显易懂，言传身教。入门scrum实践最好的书。 -
经验之谈 -
简单可操作，适合于高效的团队学习使用。 -
40分钟看完了每天的工作流程 -
贵在真实。。。 -
这本书非常不错，猛然发现很多我们平时在做的事情，都有了雏形，但是偏离了行为的本来意义。这书应该常读常新。 -
半年前同事极力推荐了这本书而且谢了一篇对他来说茅塞顿开的读后感。春节期间看完了这本仅仅有着100多页的书，这也是今年看完的第一本书。看完给我的感觉就是“这是一个令我不是完全明白的好方法”。书中很多观点和方法对于产品开发都是很好的，不过正如作者所说，这种方法目前也是还在不断尝试和改进中，至于是不是最好的方法，当然取决于各个公司的“国情”。
依稀记得2011年公司曾经采用过类似的产品开发模式：评估项目工作量、确定开发进度和交付日期，采用白板更新进度等等。后来因为各种执行上的困难和弊端不了了之了。看完这本书结合公司之前的失败经验，我做一些关于产品开发管理和敏捷开发的个人认识和总结，希望能与大家一起探讨好的开发进度和管理模式。
1、产品开发/项目开发就像个人的职业规划和工作计划一样，必须有长线和短线。长线规划公司产品的未来发展及主要节点；短线要具体分解每一步具体要执行的步骤及模块，甚至要细分到每一周，每一天的工作安排。只有让所有人明白了项目的目标和需要做的事情，大家才能拧成一股绳一起去努力。我所理解的每一个sprint（我理解为“发布周期”）流程为：
理清工作思路→确定工作量（全体会议）→确定交付日期（全体会议）→分配工作内容（技术团队内部会议）→公布工作量及目标（对外公布）→及时更新工作进度（对外公布）
这样做的好处：
可以让团队都清楚大家接下来一段时间的目标是什么，拧成一股绳。
可以让每个人都清楚别人每天都在干什么，这样才会在内部形成竞争力。
可以让公司的领导及其他部门都知道团队都在干什么并且知道每天都完成了哪些内容减少了不必要的谈话，会议和质疑。
对项目的把控性增强了，知道什么时候需要催一催进度，什么时候可以让大家稍微放松。
难点：如何准确预估（评估）工作量，如何避免过多预估工作量导致产品失去竞争力？
2、合理使用“燃尽图”。它能够帮助团队及时判断项目进展是否在计划之中，避免产品开发进度过快或者过慢。
3、多做有用的事。去掉花里胡哨的东西。也不要把时间花在会议PPT的美化上，传达出报表大的信息即可。
4、下一个sprint中如何做得更好，需要总结上一个sprint中存在的问题和需要改进的地方。
5、制定一个大的产品发布规划大plan（plan1,plan2···）包括大致的发布日期。这中间牵扯到版本发布计划，除了正在进行的sprint需要确定精确的发布日期和发布内容外，后面的都可以根据实际需求的变更做出灵活调整。
6、上一个sprint和下一个sprint之间设立一个“缓冲日”，用于给团队成员调整状态。
7、我的疑惑：
拆分功能点（模块）的方法。
测试bug的修复安排是否占用下一个sprint时间，如果占用，如何来保证下一个sprint进度？
有一点是我在读书过程中发现的：书中一些自己经历过的事情读起来会很有味道，也很能揣测一些当时存在的不足和经验。而还有一些自己不是很熟悉的部分则比较拗口难懂，一扫而过有一个印象即可，随着经历也会慢慢深入并得到启发。 -
2014.10 读是很容易读懂的，对了解Scrum如何运行很有帮助。不过感觉每个scrum都是特别的，尤其国内的大环境下，团队达不到同样共识的情况下，实践起来应该会有很多不同。 -
很实用的一本指导书，顺便还给我扫盲了很多关于敏捷开发的常识，JIRA中的很多之前看起来莫名其妙不明白的字段现在也开始能够理解一些了。项目管理的各种经验总结。 -
10号开始5级正式评估了，现在回头来看，觉得CMMI一点也不注重流程，流程是你自己的，它完全不在乎你如何运作，给你的是目标，是建议，仅此而已。当你达到五级时，CMMI想要看到的，是你们已经建立的数据化的持续改进机制，然后疯查你的分析方法和数据收集。
交流是好的，是被建议的，但不是必须的，至少在CMMI来说。从这个角度来看，six sigma和 QC更为纯粹。情感上，我个人偏向于QC。 -
开始接触scrum -
在经历了一年多敏捷实践，看了几本Scrum理论书籍后（基本都没有看完），带了一堆疑问和困惑打开这本印刷精美的小书，顿时有一种豁然开朗的感觉。
好长时间没有看完一本书的冲动了，每一章看过后都有不少收获，里面总能找到当前项目Scrum实践中遇到的问题和解决方法。
另外中文版翻译总体质量也不错，值得推荐！ -
非常实用的一本书，几小时就可读完，没有枯燥的理论，全是作者自己项目的许多实践，大部分情形是实行Scrum的团队都会碰到的。强烈推荐！ -
非常不错的一本书。
关于敏捷方法的理论和介绍，可以说已经要汗牛充栋了，目前被人们广泛承认的敏捷方法也有一定的数量了。但是如何去敏捷，也许一千个组织有一千种各自迥异的实践方式。
没有哪一种敏捷实践告诉你要完全按照它所描述的章章条条照本宣科，也没有哪个组织所实施的敏捷实践会是银弹，更不用说是放之四海皆准的最佳时间。
那么这本书有什么意义呢？很废话的说一句当然有。作者Henrik Kniberg通过告诉你他们如何实践敏捷，具体来说就是最为流行的Scrum和XP这两个实践，给了读者一个敏捷方法在现实项目中实施的借鉴，从而为读者带来思考，如果自己的项目要实施敏捷，具体该怎么做。 -
主要是针对Scrum中的一些细节和作法给出了实例。虽然不一定适用于每个团队，但每个团队可以根据需要进行调整，从而达到自己的作法。但本书不适合成为一本Scrum的教科书，并没有Scrum基本流程，而是拆成了一个个点来讲，比较适合已经实行Scrum但是比较初级的Scrum Master进行参考。 -
工具书 -
帮助我对scrum有了一些感性认识 -
按部就班的正统流程如CMM注重评审，会议，周报。表面上是通过制度保障质量，深层次上也是营造交流的机制和环境。
SCRUM，或者说XP等敏捷方法虽然倡导了无设计，无文档的开发流程，但在充分交流这条路上走得更彻底：
* 结对编程是开发人员之间的强制交流
* 客户代表是开发人员与需求提出方的强制交流
* 持续集成是整个项目组开发人员的强制交流
* SCRUM中每次sprint计划会议，也是多方--需求方，管理者，开发人员的强制交流，最终的计划是多方意志妥协的结果。
...
http://blog.duofish.cn/articles/8%E6%9C%88%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0%E2%80%94%E2%80%94%E3%80%8Adreaming-in-code%E3%80%8B%E5%92%8C%E3%80%8A%E7%A1%9D%E7%83%9F%E4%B8%AD%E7%9A%84scrum%E5%92%8Cxp%E3%80%8B.html -
这本书中的内容绝对是实践中得来的干货，货真价实。对于在项目管理中实施敏捷理念的人来说，价值非常大。但关键的关键还是实践，只是觉得有价值，不去实践，永远到达不了大洋的另一边。 -
正如本书的副标题所说的那样，“我们如何实施Scrum”，该书能够带你走进Scrum的世界，告诉你每个Scrum对应的事件具体该怎么实施，比如怎么开sprint planning， 怎么开daily scrum等。同时，它还给出了一些在实施过程中遇到的问题以及解决方案。即使你从没实施过Scrum，看完此书，就好像你已经实施了一次完成的Scrum流程一样。 -
我手头的这本《硝烟中的Scrum和XP》是互动出版社赠送的，在这里谢谢"图灵教育－晓敏"和互动出版社。
在读这本书之前，我对敏捷开发基本上一无所知，虽说也听过结对编程，极限编程等概念，但没深究过。
我下面主要会说到2件事：
一，简要说明我所在公司所用的软件开发方法（估计也是大多是公司采用的）
二，敏捷开发中有哪些值得借鉴的（很多话可能摘自本书原文）
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
一，
我所在的部门所用的软件开发有点像“瀑布模型”，从产品的spec确定（主要由PM负责）--->需求分析（主要由项目经理以及RD参与）--->软件设计（项目经理和RD--->程序编码（RD负责）--->测试（测试人员和RD负责）--->运行维护（RD负责）。期间可能为了方便维护产生大量文档：PS（规格说明书），Mockup（产品雏形）， ES（需求说明书），DS（设计说明书），TP（测试计划）等等。确实很耗费时间，最耗费时间的2个点是：
1，ES这点（PS是由PM确定，所以我不知道实际情况），常常到编码完成了ES还会改变，PM有时自己都不知道需求，一天变一个说法，RD和PM有时交流有问题，大部分PM不会写code，有些问题跟他们说不清楚，当然RD有时也乱七八糟的。
2，测试阶段，我们的方法是先内侧，然后交给专门的测试人员，把所有feature测一遍，回归测试等，如果时间比较紧的话，RD没很多时间做单元测试，代码质量有待商榷，而且RD一般都不喜欢测试自己代码，现在测试自动化应用也没那么广泛，很多还是要手工测试，这又取决于测试人员的效率和素质，测试人员（QA）有时和RD沟通有时会有困难，尤其是异地！产生bug后，有些bug还需要跟PM确认，甚至会影响ES，RD修复然后再给QA测试，总之很耗费时间。
如果一款产品从Ps制定到交付给客户需要6个月，真正用于编码的时间可能只有1.5月，不顺的话，测试和修复bug阶段可能要占据接近2月。
效率是比较偏低的。当然这样出来的产品应该比较稳，但却是耗费了很多人力和时间。那么，我们可以从敏捷开发中学到什么？
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
二，
我对scrum和xp了解甚少，以后会持续关注，这我的水平也不适合阐述scrum和xp的种种。
这儿我主要提2个东西，backlog和sprint。
backlog就像需求分析文档，不过它是以条目的形式组织在一起，而不是分散在文档中，用excel等工具展示出来的话比较清晰。
有几点值得借鉴的是，它有一个字段是important，标识这个item的重要性。还有一个字段标识，这个item（比如添加一个用户）会花多少时间完成。还有个字段讲如何做演示（这里就考虑到测试了）。而且它的字段是弹性的，所以可以加一些其他标识字段，这样一来即便新人接手也会一目了然，总比看ps和Es文档来得快！！
Sprint就感觉像一个project（或者project阶段）从开始到结束的过程。
制定sprint计划，这里涉及到resource和时间的分配以及确定产品的哪些feature需要完成还有很多细节，我觉得站着开会是个不错idea。
然后把讨论后的规划贴出来，让大家都能看见，这样目标也比较明确，用小黑板和墙是个不错的建议。根据项目的进度更新小白板和墙是个更不错的建议。让别人知道你们在干嘛...在小白板上把任务分解，用一些曲线或者其他几何形状标识一些东西，这样客户心里也有底：哦，他们在干嘛干嘛...领导心里也有底，这些家伙没有混日子的。加入新人也能一目了然得知道你们在干嘛...自己人也看到进度条在动或者自己做了些事情。
RD之间坐的近，相互充分交流有助于开发效率的提高，遇见问题也可以立马问，总之团队气氛要活跃，死气沉沉不是好事。
像做销售一样，为了让项目经理知道项目进展状况，每日例会是个不错的建议，而且时间也短，大家早上来上班就制定计划，今天要干嘛干嘛，周围人也知道，你也偷不了懒，你也不好意思拖进度，没事可以给你找事做。
做阶段性的产品演示可以让rd感觉自己在完成某种东西，至少不是虚度年华！！！
集体进行阶段性的回顾。
多用维基百科(感觉这样文档只有一份，而且不会丢，便于查找，放在server上有时不方便，而且本地还有多份拷贝）。版本控制系统就不说了。
让员工有时间思考自己的工作，加入自己的idea或者完成自己的想法(这个要求太高，不是每个公司都像google）
发布产品最好不要延期，同时要确保质量，如果可以放到下一版，那就下一版本吧。
测试是个难题，测试是提高代码质量的最可靠方法之一。但测试需要时间，所以如何利用工具或者脚本多做自动化测试，如何提高手工测试效率等等问题都值得探讨。
结对编程不好实施。
提高自己的编码素质，变得更牛更牛！！
书中讲到的团队管理这里就不多copy了。
总之是本很具参考价值的书籍。
-
呵呵~一本简明的指导书，有自己的创见和经过试验结论。Pretty~ -
很简洁有效的scrum quick start。。。 -
InfoQ的迷你书，这本书内容质量蛮好，几趟地铁上速读完了，有些收获。由于一些变动，暂时又没有机会实践Scrum啦。 -
有意思，但后半部分看不懂，我还以为XP是windows XP. -
140多页，一天看完。
不亏是一本介绍scrum实施的书，写法也很实践，很敏捷。
我很喜欢sprint on the wall的方式，简单明了，比再先进的online app都来得爽快。非常适合集中式的开发，不过这样对办公室也有了一定成都的要求 ;) -
这本书是一口气看完的, 字里行间都能够体会到硝烟弥漫.
感觉这本书更像是一种CookBook, Scrum 是一种灵活的框架, 它没有那么多的繁文缛节, 在每一个不同的team里, 在同一个team的不同项目中, Scrum都在演变, 都在进化.
我觉得在众多的Scrum文章和书籍中,真的缺少这种详细的像实战报告一样的东西. 我现在所处的环境不能实施Scrum, 因此有很多的实际经验是无法得知的, 这本书正好弥补了这个我在学习Scrum中的缺陷. 尽管还会有很多的不解, 但是这种从实际中来的经验对于学习Scrum来说已经是相当宝贵了. -
嗯。作者马上要到清华园开会鸟。。你去不去？ -
简单粗暴，实践性非常强的一本书。是在深入研究敏捷开发前找感觉的一本好书。 -
没有什么废话，没有什么华丽语言的修饰，一切都是大白话和大实话。但是这一切都是出自真正的实战经验和总结。
刚开始看的时候不以为然，但是随着自己实施Scrum之后，发现里面的很多经验可以直接照搬过来，而且很多我犯的错误，书中都已经提示了，只是我没有注意而已。
如果从零开始Scrum的话，看看不错，如果没有正经的看过Scrum的书，这本书真的也不错。
-
@栾楚
你说的是译者，还是原著？
我猜下应该是译者吧，infoQ组织的那个吗？ -
不错，靠谱，实用 -
汗，大哥你读英文的速度还真是够快的，我零散但认真看了几天了，目前才看了一半左右。。。。 -
实践派，Step By Step的教练手册 -
很早的时候就已经读过，最关键的是，李剑的翻译真的很棒。 -
关于scrum一本顶十本的好书 -
去试试就知道了。不可能有完全适合的，都得根据你的项目进行裁剪一下。其实这类开发方法中有很多说不明白只能意会的东西，就像人件，方向和意思很明白，但是很难测量。
所以如果做的业务不值钱，再怎么测量生产率都是很SB的行为。 -
印刷很华丽，书也很小，页数也不多，不过里面没有什么废话，也没有让人晕头转向的哲学式的辩证方法。全部都是实践，真刀真枪干出来的经验。很不错的一本书，让我以最快的方法认识什么是scrum，而且怎么来实现scrum，看完它准备再scrum敏捷项目管理 -
这本书的实用不用我来废话了。我的team已经使用scrum有段时间了，今天我又重读了部分章节，现在是一个根据我的个人经验，反思我所在team的scrum实践所存在的不足。
1. 我们混淆了backlog的真正意义，他是产品负责人提出的，从业务角度出发的，可以demo的故事；但是我们的往往是开发人员根据项目需要所列举的要做的事情。我们需要进一步区分故事和任务。
2. 我们的sprint planning meeting并不规范，并不排每个故事的priority，而且花了太多时间在讨论how to design and how to implement,因此常常超时。
3. 每日例会对于昨天干了什么更看重，但更应侧重今天打算干什么。
但也有他没有很好解决的问题，比如“技术故事”，举个例子，“重构现有代码”，这些东西没法demo或者交付，而且优先级比项目的进度看起来更低，如何把他添加到backlog列表中，这是个值得思考的问题。
我很关心的测试问题，还需要再重读一下，看看作者是怎么做的。 -
写的太棒了，都是干货！ -
还是不错的，语言也很诙谐幽默 -
可读性很强，针对实际问题给出解决方案，项目管理本身就是过程不断改进的。 -
言简意赅的对scrum方法进行了讲解，并且从很多细节方面阐述了具体的做法。值得参考和学习 -
科普性极强，读起来也挺好玩的，但是在如何划分backlog依旧存疑。翻了好几本类似的书，大多都没有详细讲如何划分。TDD的开发模式还是一知半解啊，不过对比起来感觉还是比传统开发模式要好玩些。 -
我所在公司是个百年名企，和很多startup company相比，组织结构庞大臃肿，headcount绝对超过150法则所建议的神奇数字150（该法则认为将组织规模控制在150人以下命令才得以执行团体才能良性互动），而且凡事讲究process，对客户需求的response难免迟缓滞后，这在如今事事讲究速度效率强调快速反应的时代，这头巨象的转身自然不如土狼迅捷灵敏，尤其在行业利润日益稀薄的大趋势下，在各方豪杰名士土狼的环伺下，市场占有率，竞争力自然今非昔比。大概也是基于此，公司上层才会积极拥抱各类新概念，掀起一轮又一轮项目管理执行的evolution, revolution罢，可惜，往往是形似神不似。
Recently when I have still suffered the deployment of streamline development and doubted the benefits of it, there comes a new strategy to pilot and deploy agile in our project management. Sure, It is trendy that everybody talking about the agile and scrum. But what agile really is? How to scrum? How to adapt to this new concept, new way of working? How big benefit it will bring to our company? What are the obstacles we face? There is still no clear answer. We all are just learning when we swim.
This book can be viewed as good practices, I really learn something from this book, at least, not in theoretical level while combined abstract noun/theory with concrete example in reality. When I finished reading, I am clearer about agile and scrum. However, here I don’t want to get into the details what and how I learn from this book, how good this book is. I just select some interesting jargons from this book, I heard them somewhere else previously. In order to know them more: background, origin, story and meaning etc, I google them to get deeper understanding. You can view it as “买椟还珠”: I buy the glittering casket and return the pearls to the seller. I don’t care to be a modern version of 楚人。
Yesterday’s weather:
This is the principle that says you'll get as much done today as you got done yesterday. In iterative projects it says that you should plan to do as much this iteration as you did last iteration. The term comes from the Extreme Programming community. It is technique to make our future plans based on what we know.
Origin: Some country decides to build a sophisticated computer system to predict the weather. After spending more money than people can imagine, they come up with wonderful result - and proudly claim that the system is 70% accurate. Somebody then figures out that in this country if you predict today's weather will be the same as yesterday's weather you will be 69.5% accurate.
The point of course is that while Yesterdays Weather is a crude mechanism, it ends up being not significantly less accurate than more sophisticated (i.e. complicated) ways of doing it.
“Chickens and Pigs” metaphor:
It comes from the idea of a project to make breakfast of bacon and eggs. The Chicken suggests that the two involve themselves in a scheme making breakfast of bacon and eggs. In reply, the Pig always notes that, for the Chicken, only a contribution is required as a chicken can simply lay an egg and then resume normal activities, while for the Pig a "total commitment" (or total sacrifice) is needed as in order to make ham or bacon, the pig must be slaughtered. This example simply illustrates that being involved may mean being a participant with little or no effort, while being committed takes time and energy, and means much more than just being involved.
This fable is commonly referenced in the Agile software development community to illustrate two types of project members: pigs, who are totally committed to the project and accountable for its outcome, and chickens, who consult on the project and are informed of its progress.
Gut feeling:
A feeling that you are certain is right, even if you cannot explain why.
-
【第5波赠书】赠敏捷开发类图书25本
活动规则：
1、推荐本帖子，并回复说明自己希望得到赠书的理由，一句话即可，当然长了也不反对。
2、获得赠书者须在收到赠书的2个周内回馈1篇500字以上的书评。
3、回复中位于9楼、99楼、199楼、299楼、399楼者将自动获得赠书1册，每楼1册总共5册。
4、剩余20册赠书，随机抽取20名幸运者进行赠送，
活动地址http://www.douban.com/group/topic/21038601/
活动时间：
2011.07.12—2011.08.12日
赠书清单：
1、《用户故事与敏捷方法》http://product.china-pub.com/196596
2、《Scrum敏捷项目管理实战 》http://product.china-pub.com/44689
3、《敏捷软件开发：原则、模式与实践》http://product.china-pub.com/13569
4、《硝烟中的Scrum和XP——我们如何实施Scrum 》http://product.china-pub.com/197645
5、《Scrum敏捷软件开发 》http://product.china-pub.com/197153
注：赠书为目前这5种，《敏捷项目管理(第2版)》不再参加此赠书活动。 -
很不错 -
Scrum因为招式少，实践性强而受到推崇——把一个漫长无法预计项目开发映射到橄榄球简短的招式。跟传统的里程碑不一样，sprint 就是冲刺，基于时间的冲刺，里程碑周期会长检验结果，而Scrum周期短容易调整，并且Scrum检验效率，而非孤立的结果。 效率高了结果就当然更好。 -
这书不错，我也刚看完：
http://www.cnblogs.com/yuandong/archive/2008/06/19/Read_Scrum_and_XP_from_the_Trenches.html -
翻译的不错， 浅显易懂， 非常具有实战意义。完全是作者亲身体会的总结。不过感觉scrummaster相关的东东介绍的太少了。
====================以下是读书笔记的分割线===================
Scrum不是方法学，它是一个框架。也就是说Scrum不会告诉你到底该做些什么。
Scrum 的强大和令人痛苦之处就在于你不得不根据自己的具体情况来对它进行调整。
产品 backlog是 Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。 -
首先，个人觉得这是一本不错的小书。
说它小，是因为这本书很薄，100多页吧，无非就是程序开发那点事。说它不错，是因为它很实用，没什么花哨的东西。
其次，这是一本scrum的实施指南。
周围的很多程序员，看了太多的敏捷的思想，听了太多的敏捷的原则，xp、scrum、sprint更是耳熟能详，我想，我们缺少的正是这样一本现实中的敏捷开发指南。
从制定backlog（user story），再到制定sprint计划（iteration），任务跟踪，开发间布置，如何开早会，如何测试等等，你会发现，本书描写的是项目开发中的那些最最平常，却又最最重要的事情。
如果你没有参与过敏捷开发，那么看本书，可以让你了解敏捷开发在项目的过程中到底是怎样实施的，我想这比空洞的说教要有用的多。
如果你正在参与到敏捷开发中，那么看本书，至少可以让你了解别的团队，别人是如何实施敏捷开发的，从中我们收获什么样的经验和教训。
最后，基于国内的情况，书中的一些方式我们可能无法实施，不过，我认为依然可以从中学到很多东西，从而进一步理解敏捷开发的实质和敏捷开发的应用哲学。
OK，不多说了，just read it！ -
不错的书，至今仍然有借鉴意义 -
这本书是我所看的Scrum方面图书的一本。
作者讲到了很多Scrum实践中的小细节，比如在Sprint计划会议的时候有些人不知道该干什么如何处理等等。其实给我印象最深刻的是对生产率的相关运用。比如生产率结合sprint来预测项目进展。 -
确实是实践之书 -
作为项目管理门外汉，还是不能很好地get到Scrum的精髓和优点。可能是这种方法在互联网领域已经应用得很普遍的原因？ -
产品管理 -
不错，很实在的书 -
通俗易懂，书很薄，非常适合刚入门的使用，能够很快熟悉scrum的实践过程~ -
这本书很不错，轻松简单的带你进入Scrum之门，了解实施Scrum的一些实践。不想买的可以在InfoQ下载：http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches
万恶的资本家原来想用高度自动化的工具把软件这个行业推向流水线生产，把本来已经杯具的代码工变成《摩登时代》里扭螺丝的餐具，慢慢发现此路不通，至少在可预见的未来不通，当然也可能是发现成本太高划不来，像中国的建筑业一样层层包工才是王道？不过再怎么组件化低耦合，代码还是要有人写的，只好施展人文关怀，提高代码工的积极性，加强主人翁教育，这不正好符合社会*主……义先进性，我们从小就知道自己是主人，这一次要抓住机会跟包公讨要尊严。v5的Celestial Empire老板会给你这样的机会吗，在他们犹豫的时候发现还有Scrum master，这就好办了，这不“中国敏捷软件开发联盟”浩浩荡荡成立了（http://tech.163.com/10/1213/22/6NQL8IFV000915I3.html），想造反？先问问咨询的认证的去。
闲话扯完，希望不是又吹起一个认证的泡泡。
还有，如果未来流水线了开数控的会比拧螺丝的赚，如果未来层层插件组装了，大包工头比小包工头赚，开个挖土机或者拉土车自由职业比搬砖头赚，所以在工作之余还是得多学习多看书，未来别落后。 -
我只挑了几张读阿，比如如何管理地址分布的团队就不看，因为我想建立一个集中式团队，如何融入xp也不看，因为还做不到，慢慢来 ;) -
作者对scrum 实践中点点滴滴总结，正中要害。我即将在 团队中实施 scrum，这本书给我很多启示。尤其是对团队成员能力的要求，scrum 是一种方法，而不是一个 对团队成员能力要求的标准，或者注解。一个自我激励，自我组织，提高效率的团队 是一个 理想的 scrum 状态，但这只是终点，并非起点。
-
敏捷开发概念很火，在实际开发中几乎很少用。个人觉得scrum这种‘技术’有点反人性。。 -
这本书从始至终都实实在在、原原本本的介绍自己的scrum实践过程，有经验、有教训。对于任何想实施敏捷开发过程的团队都有借鉴意义，小到会议时间、地点、会议纪要怎么写，大到测试怎么做。
下面是我的读书笔记：
http://www.lixinyang.com/2009/10/15/scrum-xp/
-
非常好的Scrum经验谈。Scrum实践者必看。阅读前必须了解Scrum原理。 -
很不错的小书，在没有任何scrum基础知识的情况下对整个流程有了大体的认识，希望能用到实践当中 -
@charlee翻译的NB -
贴近实际 -
敏捷实践的一本小册子，提供了一些实践的方法。 -
这本书得到很高的评价，但是我用了一天时间看完后，获得点子有三个：
1、可以让两个SCRM团队交换SM进行回顾会；
2、要有迭代计划，还要有发布计划；
3、几个SCRUM迭代后，让团队休整一天是很好的行军方法；
不是我太挑剔，而是作者这本书写的太早了，这本书又写的太精简，像一个微型手册，给新新手用吧。 -
分了两段时间，但是算是一口气读完了这本书。很喜欢前面的序，特别是风清扬的那段话。
如今，敏捷开发确实收到很多企业的推崇，算是一个小潮流。但是多数团队使用敏捷的初衷都是又敏又捷，又快又爽。
这本书确实可以作为一本入门教材，不仅仅是因为他篇幅小，文字翻译后通俗易懂，而且他也着实符合了敏捷的经济学思想。虽说只是作者的所做所感，每一个环节又符合了敏捷的方法论及业界通用的流程。
但敏捷也没有固定的流程和方法，因此作者也没做太多赘述，但是忘记所有的方法和流程之前也确实需要先做一遍，才能整理出适合本团队的符合经济学的方法。符合风清扬的学完就忘。 -
简短通俗，实战案例丰富 -
非常不错的书，我得努力提高下自己的阅读速度 -
喜欢其Story式讲解 异曲同工之妙啊 -
非常好的一本书，用通俗的例子讲解一个项目管理，brishen所说的很重实践应用，但是理论知识实在是偏少，但是对入门来说有极大的帮助，我读的有点太匆忙，虽然多有余漏，但也是收获不少 -
读过的第一本关于scrum实战的书，入门不错。