scrum要素读书笔记

一、敏捷力介绍
1、瀑布模型：在瀑布流程中，每一步骤都必须等待前一步骤结束后才能继续，也只有等待所有步骤都结束后才有可能向客服交付价值。
瀑布模型相当于在投入生产前就“完美化”产品设计是可以做到的。但软件产品是复杂系统，而不是静态物件，毫无经验数据只能设计出致命的烂系统，从而导致不良的后果。
2、敏捷：
所有种类的敏捷流程都有一个共同点：他们拥抱变化，视变化为成长的良机，而非障碍。
敏捷与瀑布模型的差别在于：敏捷一点点需求收集，一点点设计、编码、测试，最后交付一点点价值给客户。接着团队在重复此过程，周而复始，直到项目完成为止。
敏捷需要的：边做边测试、及早且频繁地交付产品、文档边做边写、构建跨职能团队。
敏捷的核心思想在于：迅速交付商业价值，体现为可工作的软件，还要以定期增量的形式持续地交付价值。
3、敏捷价值观与原则：
敏捷价值观：

1. 个体和互动高于流程和工具：流程和工具是为人服务的，不能强加，可以尝试，允许犯错。
2. 工作的软件高于详尽的文档：不奉行文档，但同样记录工作（包括每次变化：构建、测试集成），因此一直在积累和演变的敏捷计划是活物。
3. 客户合作高于合同谈判：降低客户风险，不是靠前期担保方式转嫁风险给承包商，而胡思依靠流程中客户的持续参与，以及敏捷团队定期交付可工作软件增量的能力。
4. 响应变化高于遵循计划：软件开发的变化不可避免且理所当然的，认为变化是好事而积极响应好过“变化控制”。

敏捷原则：

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，及时在开发后期也一样，为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于才去较短的周期
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目，提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简为本，他是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并依次调整自身的举止表现

4、敏捷力的商业案例：
敏捷的持续交付，把一整个项目多次迭代，频繁交付，每次都能交付可运行的软件。开发周期较短，接受变化的能力较强。每次交付都能获得利润，即使项目终止于某个迭代周期也不至于亏损严重。大大的降低了成本，控制了风险。因为在软件开发过程中不断适应变化，持续满足新的需求，潜移默化的提高了最终交付软件的质量，因此收获的利润也更可观。
而瀑布模型每一步骤都必须等待前一步骤结束后才能继续，客户只有等待整个项目开发完毕才能看到可运行的软件，周期较长，几乎没有接受变化的能力，无法适应开发软件这段时间，外界变化而带来的需求变化。一旦最终交付的产品不能令客户满意，面临的亏风险是相当大的。

二、Scrum

1、角色：
(1) 产品负责人：是唯一有权要求团队做事以及改变列表条目优先级的人。因此需要和干系人密切合作。持有产品愿景、代表业务、代表客户、拥有产品列表、划定故事优先级、设立故事的接收标准、有空回答团队成员们的问题。
(2) Scrum Master：担当教练角色，引领团队达到更高级的凝聚力、自组织和表现。作为专家，为团队获取最大价值，为团队移除障碍。Scrum专家和谏言者、教练、障碍推土机、引导者。
(3) 团队成员：团队全权决定如何完成工作、使用哪种工具和技术，以及如何瓜分任务。负责交付用户故事、做所有的开发工作、自组织地交付用户故事、支配估算流程、支配“如何干活”的决策、避免“与我无关”

2、Sprint周期：
(1) Sprint规划会议：团队选择一组交付物作为当前Sprint的承诺。团队罗列出交付用户故事所需完成的所有任务。回答：“做什么？”（完成哪些功能点）“怎么做”（功能点分成哪些任务）
(2) Scrum站会：在每天工作前开会，只有开发人员参与。简要、直截了当的说明已经完成的内容和期望完成的内容。
(3) 故事时间：每周一次，估计还未制定大小的故事，将较大的故事拆分成更小的故事。在中期召开，修整好列表，以便流出充足的前置时间。
(4) Sprint评审会议：演示可工作软件
(5) 回顾会议：每次迭代都要召开回顾会议，在迭代最后才举行，专门留给团队的时间，专注于讨论他们当前sprint的心得和体会。准备阶段（让参与者放心大胆的畅所欲言）、收集数据（用索引可或便签记录，回忆上一个sprint发生的事）、洞察问题（发现数据的模式、最重要的条目，然后深化理解寻找因果关系，最后确定解决方案或改进方案）、确定方案（在团队控制范围和能力范围内去改进）、结束（感谢）
(6) Sprint异常终结：为了响应外部的事情或是团队遇到一些情况。团队和产品负责人交换自己的意见，看产品负责人是否想要终结sprint。提早终结sprint本质上是商业决策，因为需要由产品负责人来操持。

3、Scrum工件：
(1) 产品列表：包括特性、缺陷修复、文档变更和任何值得创建的东西。
(2) Sprint列表：任务清单，存活时间有限，仅存活一个sprint的时间，包含所有已承诺的故事以及相关联的任务，以及此外的附加工作。
(3) 信息辐射器：待办、进展中、已完成（任务版）
(4) 燃尽图：描述剩余工作随时间变化的轨迹。

4、用户故事：
作为<某类用户> 我想<做某事> 从而<创造出某些价值>
聚焦目标：为了<达成某目标> 作为<某类用户> 我想<做某事>
聚焦价值：为了<创造某价值> 作为<某类用户> 我想<做某事>
用户故事不是完整的需求或说明书，它们是占位符。找过一系列测试，直到所有人都认同测试通过，就意味着故事按预期实现，则得到验收标准。

5、用故事大小值估计工作：
第一步：给所有的工作项都分配相对大小值。大小值表明需要完整的工作有多少。
第二步：完成几个工作项，度量她们实际花费的时长。得到实测数据后，结合制定给其他条目的相对大小值使用，预期的进度可见性也就有了。
找出一个故事，估计值为“1”，成为度量的相对单位，来估计其他故事所需的工作量。
估算方法：计划扑克

三、辅助性实践
1．在固定时间、固定资源的情况下，做规划时，得做出一些艰难的权衡决策，使不使用scrum都同样需要考虑。

2．铁三角（速度、成本、范围）：三者需要平衡，改变其中任何一个，必然会导致另一个或两个相应地产生变化。

3．绘制故事地图：用户故事按优先级从高到低的顺序排序。

4．纸上原型：（用户、计算人、引导者）
（1）画出轮廓，并写出按钮和特性的名称
（2）使用便利贴制作因用户的操作而显现、消失的按钮。
（3）用户看到的所有界面都要用纸张做出来，指导完成操作为止。
引导者告诉用户，他们被要求使用此应用来完成一些事情，用户轻拍纸张进行单机，告知计算人要输入的内容，计算人翻转或操作页面，以响应用户的动作。用户不可以向计算人或引导者问问题，这个测试就是为了看看应用能否干得了活。
纸上原型不是scrum的一部分，但他具有敏捷的本质，是充实产品负责人工具箱的上佳之选。

5、项目微章程：
越长篇大论的业务文档，越是无人问津。微章程涉及多个话题，最终还是会在其它文档中详细叙述，是份非常有用的总结。
包括：代号、使命宣言、愿景宣言、电梯演讲（剪短几句话，关注项目要解决的问题）、商业价值（金钱或其他方面的价值）、客户和用户、度量指标（如何度量价值）、里程碑（重要的时间点）、资源、风险、权衡。

6、重构：只构建今天你需要的架构，随后根据需要而不断发展它。以此方式，架构一直都是恰到好处，系统因而也易于理解、维护和强化。

7、测试驱动开发
目标在于快速地开发出设计精良、正确性已获证实的代码。这个循环“红色—绿色—重构”红色需要重新运行测试，若全部通过则处在“绿色”状态。维护者一层保护性测试使得开发人员可以大胆地修改和改进代码，就带来了快速、敏捷的开发。
一旦开发人员切实地理解了代码需要做什么，就已经准备周全可以妥善地设计代码实现了。TDD可以降低缺陷水平，且无需牺牲生产力。

8、结对编程：两个程序员一前一后，用一台电脑写代码。更加快速地生产处设计更精良、简洁的代码。消灭了只是简仓，因为至少两个开发人员都熟悉了对方那部分代码。结对的方法很多，应该多试几次，以便找到是和他们的方式。
(1) 驾驶员—导航员结对：驾驶员控制键盘，关注当前代码行。导航员关注战略，思考该编写哪部分代码。
(2) 乒乓结对：反复交换键盘，挑战对方以解决问题。
(3) 测试驱动开发结对编程游戏：代码永远只有两种状态：红色（测试没通过）或绿色（测试通过）。把合法动作看成是状态转换，发生转换则递交给另一名玩家。