《Scrum要素 – THE ELEMENTS OF SCRUM》
[美]Chris Sims，Hillary Louise Johnson 著
徐毅 译
人民邮电大学出版社
2013年2月
这本书写的还不错，推荐一读。虽然不是那种让人惊艳的感觉，但是确实愿意花时间多读几次，特别是项目开始之前或者结束之后。不同的人——指不同的角色——应该会有不同的收获。
我们目前工作中使用的开发方式，应该是“瀑布式”和“敏捷式”的结合。当然，我们号称是“敏捷式”的。
项目开始之前，会有产品经理收集需求，编写项目说明书；项目中的参与者们评审完之后，是交互/视觉的设计；接着又是一堆的评审，然后是技术方案的设计；技术方案也需要评审，评审完之后，进入编码阶段；编码完成之后进行测试，然后就上线了。这是经典的瀑布开发流程。
下面根据使用的情况，产品经理或者运营会收集一些用户的反馈，整理出修改的需求之后，针对每一个需求，安排一个日常进行改善。这里的每一个改善，就相当于一个sprint——更加简化版的sprint——我们会进行需求评审，开发，测试，最后再进行一个回归测试，保证不影响以前的功能。
这里的主要问题，在原型的开发中，也有大设计前置（BDUF）的问题；而且在开发过程中，产品经理和交互、视觉同学不进行参与或者参与度太低，导致开发中的一些问题没有很及时很恰当的解决——最差的结果是，开发出来的结果，大家都不满意；产品经理不满意、开发同学也不满意。在后期的迭代开发中，一般来讲，整个项目的所有成员，没有完全参与进来。
这个过程中，缺少一些指导性的东西，导致有时陷入迷茫之中。
大家都在讲敏捷式开发，但是估计都是“中国特色的敏捷”，真正学到的只是迭代式开发这一点，其他的要素要么不知道，要么就是根据自己的习惯、资源进行了。所以，某种意义上，很需要这样的书。
这本书用很简洁的语句告诉我们Scrum的要素。这里记录几个有感触的点，不覆盖全部。
1. “作为scrum团队成员，要完成的不是你的工作，而是这份工作”。
这句话的重点是，所有的任务大家共同完成，而不是某个人负责一方面。大家共同为这项工作负责，这不是绝对意义上的平等；scrum也不要求所有成员都是可互换的，而是他们在需要的时候，可以完成一些不在他们舒适区中的工作。大家平等的参与编码的工作，万一出现进度问题，所有人都可以进行协助，保证sprint的进度。
2. Sprint规划
其实就是编码开始前的设计和评审，同时估算工作量。比较特别的是，这里使用了故事点的概念来衡量工作量；每个sprint中，完成的工作量基本一致，可以最大程度的保证完成时间，从而也能够保证项目质量。
每个sprint的工作总量足够小，从而保证sprint的规划会议能够在限定的时间内完成，而不是陷入无休无止的评审会议之中。
3. 任务板
任务板是一种信息辐射器，用来同步项目的进度，对所有人可见。这里最大限度的让大家了解目前的进展，不管你是不是项目中的成员。
最简单的任务版由代办（to do），办理（doing）和已办（done）组成。
4. 完成定义
因为细分了具体的故事点，所以可以清晰的定义每一个故事的终结。避免含糊的事件存在，这也是信息透明的一个表现。
5. 用户故事
也就是产品的细节功能点，这里的翻译觉得有点看不懂，不过还是按照书中的概念来。
模版：
作为<某类用户>
我想<做某事>
从而<创造出某些价值>
说实话，目前看到的PRD，很少有能够把需求说的明确的。……作为一个开发，迫切需要一个没有歧义的需求描述。
6. 工作量评估
团队估算游戏：集体排队+你的数字是？。
很神奇，但是确实很有可能把工作量说清楚。对于一个项目来说，我们可以把所有需要的工作量估算出来，然后根据需求和进度安排几个sprint进行处理。有点迫不及待的感觉了。
7. 铁三角和“单指针表盘”
衡量功能、进度和成本的神奇工具。帮助我们进行优先级排队。
8. 项目微章程
代号、电梯演讲、价值、里程碑……
瞬间觉得有点高端大气了。
整本书总体上来讲，还是让人满意的，但是还是有点瑕疵。全书最让我觉得不太舒服的，就是名词的翻译了，比如sprint和用户故事。我现在还是靠猜来进行理解的，希望其他读者能够理解地清楚些。
最后，用书中的寓言进行结尾。
一头猪和一只鸡走在路上。鸡看着猪说，“嘿，我们一起开个餐馆怎么样？”猪回过头，看着鸡说，“好主意，那取个什么名字好呢？”鸡想了想，说“不如叫‘火腿和鸡蛋’吧？”“我可不这么想，”猪说道，“我得委身其中（committed），而你不过是参与其中（involved）罢了”。
在项目的开发中，一方面，我们需要每个人都全力投入，而不是involved；另一方面，我们需要分辨出谁是鸡谁是猪，从而能够减少不必要的意见对我们的影响。
以上是当前阶段的一些理解，希望随着经验的积累，再次翻开这本书的时候，能有不同的理解。