今日分享，来自《硝烟中的Scrum和XP》P1~64

提醒：在对SCRUM有一定了解的基础上，再来看本书才会有所收获。

什么是Scrum？

以下内容来自网络，帮助你有基础的了解。

书中内容：

用 Ken Schwaber的话说， Scrum不是方法学，它是一个框架。也就是说 Scrum不会告诉你到底该做些什么。

下面有一个好消息和一个坏消息。

好消息是我即将和你们分享我使用 Scrum的经验，还有种种恼人的细节。而坏消息是，这只是我个人的经历。你不应该完全仿照我的做法。实际上如果换个不同的场景，我也许就会换种实践方式了。

书中的其他内容偏向实际案例，这里不做赘述，说一下SCRUM创始人，他自己带的团队能够实行起来的要点总结。

----------------------------------------

读书感悟：

1，不是所有公司都适合敏捷，这种模式有自己的适用场景，适用于带有一定不确定性的创新型工作，面对部分未知的事物，比较适合此模式，而很多传统行业，大部分是确定的，可预测的，不适合此模式；

2，敏捷的核心，快速响应，将犯错的成本周期拉短；

3，实施敏捷之后，让团队趋于更好，而不是加班更多，很关键的一点是，团队能够说清楚自己的软件生产率，这是产品经理和团队之间博弈的基础；

4，敏捷中的故事（User Story），将需求以结构化的形式描述出来，是交付的载体。故事拆分的是否合理，能否独立交付，能否帮助用户解决核心痛点，提供价值，关键在于产品经理的能力。 很多企业把瀑布模型中的功能点当成了用户故事来搞，一个迭代结束后，发现功能不可用，因为和剩下的一个模块关联，这就是假敏捷。

5，Scrum中一个非常关键的动作，Sprint计划会议。

为什么开这个会？

• 让最接近用户的人（产品经理）确认故事优先级，保证最有价值的事；
• 统一团队所有人的目标，一起为同一个目标奋斗；
• 明确故事完成标准，避免过程中的信息不对称引入的沟通成本；

以此目的，设定会议时间限制，与会议输出的优先级：

• 优先级1: sprint目标和演示日期。这是启动 sprint最起码应该有的东西。
• 优先级2:经团队认可、要添加到当前 sprint中的故事列表。
• 优先级3: sprint中每个故事的估算值。
• 优先级4: sprint中每个故事的“如何演示”。
• 优先级5:生产率和资源计算，用作 sprint计划的现实核查。包括团队成员的名单及每个人的承诺（不然就没法计算生产率）。
• 优先级6:明确每日例会固定举行的时间地点。
• 优先级7:把故事拆分成任务。

6，内部质量和外部质量的抉择，技术债务的源头

外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。

内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。

一般来说，系统内部质量优秀，外部质量仍有可能很差。而内部质量差的系统，外部质量不可能好

------------------------------------------

以上内容属于作者观点，请大家以辩证思维阅读，结合自己经验，多看，多思，选择性吸收。