原本是计划这个周末把产品研发项目的运作流程和规范好好写一下，周六早上列了提纲。之前的想法只是把要点列出来，产品研发已经确定要按照Scrum方式运作，大家对Scrum应该都是理解的，所以应该只写要点就可以了。不过在列提纲的时候心中升起了一些疑问，所以一直没有开始动笔写。按照敏捷的原则，如果方向错了，做的事情后面要返工那都是浪费了。
内心疑惑的时候，还是先读书吧，也许读完书就豁然开朗了。前阵子买的《Scrum精髓》，之前只是读了电子版的前面几章，这次希望能全面的读一下。

全书正文大约450页，白天大约花了5小时完整的时间，阅读了210页，大概每小时40页的速度，应该是个平均速度，不过平常读书似乎很难达到这样的速度。总结下原因应该有几条：一是昨晚睡眠比较充分，睡足了7小时，比较容易集中精神；二是儿子放假了，睡了很长时间的懒觉，有比较安静的环境；三是书中的大部分内容还算是熟悉的，读起来不用太费脑子，只是在阅读过程中画了一下重点。这次读书笔记就只把我画出的重点列一下。

Scrum看起来简单，但实际上很复杂。
做冲刺规划时没有一个普遍适用于所有团队的套路。适用于某个公司或项目的方法在另一个公司或项目中却行不通。

Scrum Guide只有十几页，这本书却有400多页，足以说明Scrum所宣称的易学难精。从试点团队的情况看，冲刺计划会的形式变化对团队的影响确实还是挺大的，做计划的方式和团队成熟度、团队人员能力水平有很大的关系。

速率和技术债这两个主题都非常关键，我建议大家重点关注。速率向我们表明团队随着实践的推移要交付多少价值。技术债这个说法现在已经非常普遍，泛指会导致代码出问题的所有东西。

不过Scrum Guide中只是描述了Scrum的运作框架，而《Scrum精髓》中其实是完整描述了Scrum落地的过程，包括了用户故事地图、技术债等不在Scrum框架中的内容。

Scrum依赖于快速反馈来进行探索。

Scrum主要是用来应对不确定性的，很适合新产品开发的。如果产品本身的需求是比较确定的，虽然也能从Scrum中受益，但是可能收益有限。

Scrum框架有强大力量，其生命力来自于其简约，但要想获得成效，何其不容易。

为什么要用Scrum？

对于复杂的开创性的产品，未知的东西比已知的多，需要快速探索和反馈，Scrum很适用。需要避免事先进行大量架构设计，但不是说不要设计，而是需要采取另外一种更均衡的设计方法，开始时做一些设计，再结合进行适量、适时的设计。

我们现在希望所有团队成员都能不断协调、步调一致——我们的目标是每天都能做到协调一致。

Scrum关注在每个迭代交付可以工作、集成好的、经过测试的、具有业务价值的特性，力争更快交付成果。

可交付的产品是进度衡量的标准，这是敏捷价值观，必须遵守的。

虽然Scrum在很多情况下都是优秀的解决方案，但不是所有场合都适用。Scrum特别适合复杂域。Scrum不太适合事务性工作，因为不知道今后很长一段时间中会有多少工作，所以无法为一周或更长时间的迭代制定可行的计划。对于事务性工作，最好考虑另一种敏捷方法，即看板。软件维护和支持领域最适合使用看板。Scrum和看板都是敏捷开发方法。

Scrum框架

Scrum是一个令人耳目一新的框架，简单，以人为中心，以诚实、开放、勇气、尊重、专注、信任、授权和合作八大价值观为基础。

读到这里有点奇怪，不是5个价值观吗，什么时候加了3个？不过按《管理3.0》中的说法，无所谓了，每种方法都会有自己的价值观，这些价值观其实也不大会相互冲突。

Scrum角色

Scrum框架只是定义了Scrum中特定的角色，并没有定义在使用Scrum的组织中所有可以存在并且应该存在的角色。

想起母公司的敏捷角色中除了PO/SM之外，有BA/SA/DEV/QA，其实也就不用疑惑了，Scrum并没有说不能有其他的角色。

产品负责人负责敲定要开发什么、以什么顺序开发。产品负责人的身份决定着他要对正在开发或维护的解决方案全面负责。

产品负责人还有责任确保总能完成价值最高的工作，这些工作也可能包括偏技术的工作。

完成

“完成”的最低限度的定义是应当产出一个完整的产品功能，经过设计、构建、集成、测试并且编写了文档。

强调完成怎么都不为过，这是敏捷达成质量内建的主要手段之一。实际执行时往往是团队最容易放松的，如果来自外部的验收压力不强的话。

敏捷原则

Scrum与传统计划驱动的顺序开发分别适用于解决不同类型的问题。对于明确定义、可预测且不可能发生任何重大变更的问题，计划驱动开发方式是很适用的。但产品开发很少是按照计划进行的。

反复强调Scrum的适用场景。如果需求基本不变化，那么事先做详尽的设计并按计划执行确实应该是速度最快的，因为每个迭代中的各种会议沟通成本其实并不算低，不过这些是为了打造优秀团队不可或缺的。

迭代开发最大的缺点是在遇到不确定性因素时，很难事先确定（计划）需要改进多少次。

Scrum的要义是找到平衡点，即取得平衡预测性的前期工作和适应性的刚好及时工作的平衡。

一般情况，软件开发企业根本意识不到自己是有WIP的。在软件产品开发中，如果出现大量WIP，后果是很严重的，它会严重影响前面所介绍的变更成本取现。在Scrum中，我们深信闲置工作比人员更浪费，经济危害也更大。工厂停顿所产生的成本远远高于人员空闲所产生的成本。

重要不是开始了多少工作，而是完成了多少对客户有价值的工作。Scrum是一种以客户价值为中心的开发方式。

Scrum中的很多思路是继承了精益思想的，Stop Starting, Start Finishing。

团队在当前冲刺中无法完成所有的工作，这并不是延长冲刺长度的正当理由。到了冲刺最后一天才意识到无法完成工作，所以想通融通融，增加一天或者一周来完成，这种做法也是不允许的。

时间盒规则和DoD规则，必须形成团队纪律，由团队成员自行维护和坚持才有效果。

每个冲刺都可以通过冲刺目标来概括，冲刺目标描述当前冲刺的商业目的和价值。

冲刺目标，要想办法从PO/SM那边骗出来，然后在每天的站会上找个人员抽查下？

Scrum团队需要有一个健全的完成的定义，自信构建的产品增量质量高、可交付。

还是产品的DoD。

如果将通过接收标准的PBI称为完工(Done)容易造成混淆，就把它们乘坐已完成的(Completed)或者可以接受的(Accepted)。

这个是可以考虑区分一下，向大家强调产品完成的定义。对于产品待办项，感觉Accepted可能更好一些。

（未完待续）