【读书笔记】《Scum要素》-团队成员不是为了完成自己的工作，而是工作

这本“Scrum实践者的必读材料，澄清Scrum概念之作”按照中国读者可以理解的方法进行了诠释。

敏捷座右铭“早交付、频交付”，却又感觉相对夸大敏捷与瀑布两种方法之间的连接。

scrum：预估，验证和适应

三种仪式：sprint规划会议、scrum日会、sprint评审会议

三种角色：产品负责人、scrum master、团队成员

产品负责人：持有产品愿景、代表业务、代表客户、拥有产品列表、划定故事优先级

scrum master：专家和谏言者，团队守护者与引导者，却不是团队的老板，非“岗位权利”

团队成员： 目标不是完成自己的工作，而是工作 。

Scrum团队周记 ：高效的团队不是靠疯狂压缩开发时间，而是将团队凝结成同伴而盟友，否则带来的只能是低效和软件缺陷数目，和更多的压力与工作时间。

研发团队要实现的每一个用户故事，都需要非常充分的信息及明确的验收标准，而这些故事都是业务和客户想要的那种有商业价值的内容。

针对业务和客户想要的需求，需求获取人员和研发人员一起，将需求进行分解成大的故事和小的故事点，明确团队承诺，并用一张白纸制作一个检测任务完成进度的图标-“燃尽图”

团队成员通过“每日站会”，在15分钟内了解团队间信息及是否需要帮助。同时通过讨论，团队可以第一时间发现之前某些“预估”过于乐观，需要更多地时间才能完成，这种提前的预警可以让管理者尽快的调整团队干系人的期待。

每周团队成员拿出1个小时进行“故事时间”会议，对之前的故事进行精简和完事，新增和预定一些故事。

公开守卫，团队成员都参加评审会议，休息之后，团队进行整体回顾，寻找项目流程中可以提高的地方

Sprint周期

要做什么，要怎么做->细化任务小时、任务点、任务数

回顾会议：

1. 1. 准备阶段：建立开会讨论的共同目标，达成共识

   2. 收集数据：故事卡片、缺陷清单、构建受损相关数据、客户意见-->只关注(什么what)

   3. 洞察问题：为什么会发生这些事情（不关注谁）-->只关注(为什么)

   4. 确定方案：“谁”“什么时候”“做什么事情”

   5. 结束：我感谢《某人》做了《某事》-->我感谢frank待到很晚修复出故障的构建

Scrum工件

产品列表：产品预期交付物的累积清单。

sprint列表：任务清单，与产品列表不同，存活寿命有限。

用户故事：产品列表的基础构建。

1. 作为<某类用户>我想<做某事>从而<创造某些价值>-->更真切的感受用户和他们的重视程度

2. 为了<达成某目标>作为<某类用户>我想<做某事>-->交谈的敲门砖，通过交流大陈哥共识找到标准。

用户故事估值：提供进度的可预测性度量。

用户角色人物：针对真人行为的人物为产品分析可行性提供更准确假设。

1. 面向目标建立角色人物->他们想要做什么

2. 给人物取名字、癖好->显得真实，具体明确

3. 收集需求过程中记录真实用户的性格特征

4. 合并真人的性格特征行程组合图象

首要角色：必须首先满足人性需求

负面角色：绝对不用系统的人->不为他们设计的功能，不去费时

微项目章程：明确记载项目相关信息的概要文档：

1. 代号：给项目取个名字

2. 使命宣言：表达项目目的，简洁而强有力-->通过其创意性的硬件、软件及设备，将最佳的体验带给消费者。

3. 愿景宣言：描述想要创建的未来-->让每一个家庭都拥有个人电脑。

4. 电梯演讲：简短几句话，言简意赅使人记住不忘。

5. 商业价值：对业务而言在金钱或其他方面的价值是什么。

6. 客户和用户：可能是同一些人，也可能不是，可能是外部也可能是外部

7. 度量指标：清楚计划如何去度量

8. 里程碑：重要的时间点

9. 资源：项目必须或必用的资源

10. 风险：可能危害或颠覆项目的事情

11. 权衡：评估团队运作环境中的各种约束：范围、时间、资源、质量等。

每个团队都有其自身的特点，敏捷开发第一句说“个体与交互大于过程与工具”，也就是在强调组成这个团队的个体很不同，因此要根据团队的实际情况出发，使用对症的方法去解决对应的问题。