《Scrum要素》读书笔记

1. 瀑布模型
瀑布模型将开发和交付企业软件项目的流程分割为相互独立的阶段：需求、收集、设计、编码、测试。每一个步骤都必须等待前一步骤结束后才能继续，所以只有等到所有流程都结束后才能向客户交付价值。这种开发流程导致设计必须完美化，但是由于软件开发与其他行业相比具有特殊性，很多问题在项目付诸实施后才会浮现，因此很难在前期就构建完美的设计，进而导致整个项目的开发失败。
2. 敏捷思想
为解决瀑布开发带来的问题，敏捷思想应运而生。极限编程、scrum等敏捷思想的共同点是：拥抱变化，将变化视为成长的良机而非障碍。实施敏捷开发模型需要做到：边做边测试、及早且频繁的交付产品、文档边做边写、构建跨职能团队。通过这些措施，敏捷开发实现了迅速地交付商业价值，以定期增量的形式持续的交付价值。
3. 敏捷价值观
个体和互助高于流程和工具；
工作的软件高于详尽的文档；
客户合作高于合作谈判；
响应变化高于遵循计划。
4. Sprint周期
Sprint规划会议：选择交付物（用户故事）、将故事拆分成任务（超过半天的就要拆分）。
Scrum日会：大家分享上次日会前我做了什么，然后到下次日会前我要做什么，最后说一下开发障碍。
故事时间：列表修整。
Sprint评审会议：邀请所有干系人到场，要求超高透明度，即使没有完成也要报告。
回顾：专门讨论他们当前sprint的心得体会，并用于继续改进。
5. Scrum角色
产品负责人：唯一有权要求团队做事以及改变列表条目优先级的人，代表业务和客户，拥有产品列表，需要划定故事优先级并设立故事的接受标准，需要有空回答团队成员们的问题。产品负责人要确保团队成员理解了客户和最终用户的需要，他可以直接创建需求并进行精炼和沟通。产品负责人要和干系人密切地合作，判别需要何时构建何物，从而交付最多业务价值。
Scrum master：担当教练角色，引导团队达到更高级的凝聚力、自组织和表现。Scrum master是scrum专家，帮助团队从scrum获取可能得到的最大价值，帮助团队清除障碍，要建言团队工作流程和进度，他依靠影响力来获得领导力，而不是依靠职权来获得领导力。当团队初建时，scrum master可能需要尽可能多的教育指引团队，但是随着团队技能的提升和对scrum理解的增进，scrum master也要调整自己的工作方式，由团队自行决策。
团队成员：完成所有的开发工作，自组织地帮助团队交付他们在当前sprint承诺的故事。未来能够达到这样的目标，团队成员需要高度协作，能够全权决定如何完成工作、如何划分任务以及使用的工具和技术。与传统筒仓型组织的人不同，scrum团队成员需要完成的是“这份工作”，而不是“自己的工作”，要完全避免出现“与我无关”的局面出现。每个团队成员都有自己的独特技能和经验，但是这些专长也不应是局限。
6. 异常
共识：管理层和团队之间有基本的协议：管理层不会在Sprint进行期间更改需求。
如果因为外来因素必须要更改，产品经理可以申请异常终结。就算sprint提前结束，只要有任何故事已经完工且可以交货，就要召开评审会议，总结会议进行检验和适应，继而开始下一个周期的Sprint。Sprint异常是一种商业决策，因此需要产品负责人来操持。
7. Scrum工件：用于实现进度可视化的工具
列表：（1）、产品列表是产品预期交付物的累积清单，列表上的故事都是按照优先级精确排序的。位于产品列表顶部的多是个头小且定义完善的条目；位于列表底部的条目更为抽象。产品列表由产品负责人拥有，只有他可以增减列表中的条目（2）、Sprint列表是团队当前sprint的任务清单，生存周期是当前sprint，它里面包括所有已承诺的故事以及相关联的任务以及此外的附加工作。它是可以变化的，由完成这些任务的团队成员提出变更请求，和产品负责人一起来修改sprint列表中的故事清单。
任务板：贴满便事贴，分为代办，进展中，已完成三种状态，任务板要处于所有人的视野内，让所有人全天候持续获得最新的信息，以保持整个团队都有共同的认识。根据团队的需要，任务板可以做出一些个性化的改变，包括增加已报告栏，横向分割为泳道、增加列表栏等方式，都可以用于适应团队的需求，更好的达到团队目标。
燃尽图：描述了剩余工作随时间不断变化的轨迹（可用于观察和检验团队成员是否能够按时交付故事）。纵坐标绘制剩余工作量，横坐标是时间。一般来说团队不断完成任务，剩余工作量也会随之下降，会呈现出一条从左到右向下延伸的斜线。当有工作范围的变更导致增减任务时，燃尽图上会以竖线的形式出现（增加时竖线向上，减少时竖线向下）。通常我们会使用两种燃尽图：发布燃尽图和sprint燃尽图。
8． 用户故事
用户故事是产品列表的基础构件。模板：
作为<某类用户>：说明功能的用户
我想<做某事>：说明预期功能
从而<创造出某些价值>：说明用户需要该功能的原因
用户故事不是完整的需求或说明书，它只是占位符，只是用于提醒团队有东西要完成，不必过多的探讨细节。
通常使用相对大小来对完成故事所需工作量进行估值，已最小故事的名字作为单位。