《轻松Scrum之旅》章节试读

《轻松Scrum之旅》的笔记-第60页 - 准备scrum之旅

产品Backlog 指根据初始需求分解出的任务列表，包括功能性的和非功能性的所有功能，由Product Owner 为Product Backlog 中的任务确定优先级别，当开发团队开始某个任务的时候，再精确定义和分解这个任务。

《轻松Scrum之旅》的笔记-第109页

Sprint 评审会议在Sprint 结束时召开，由开发团队展示这个Sprint 中完成的功能，长度为两个小时左右，不需要PPT，一般是已经完成功能的Demo，而且客户、管理层、Product Owner 以及其他开发人员等都可以参加。
在每个Sprint 结束时，应该组织一次Sprint 评审会议。Scrum 开发团队将在会上展示他们在这个Sprint 中所做的工作，一般采用向大家演示产品新功能的方式来展示。
相对来说，Sprint 评审会议不必很正式。通常不需要用到PPT，而且长度最好控制在两个小时之内。也就是说，不要让Sprint 评审会议成为Scrum 团队的负担，不必让他们花太多时间来准备这个会议。
Sprint 评审会议的参与者包括所有对该产品感兴趣的人，可以是产品责任人、Scrum团队、利益相关者、管理层人员、客户，甚至是来自其他项目的开发人员等。
在Sprint 评审会议上，Scrum 团队用Demo 的形式展示产品的新功能之后，与会人员依据在Sprint 计划会议上确定的这个Sprint 的目标来评审具备了这些新功能的产品。

《轻松Scrum之旅》的笔记-第134页

计划扑克（Planning Poker）
所谓“计划扑克”（Planning Poker）是一种标有各种数字的扑克牌。参加游戏的人每人各拿一叠扑克牌，牌上有不同的数字。
客户或者产品责任人为大家挑选1 个Story（Backlog），并简单解释其功能，以供大家讨论。
每个游戏参加者按自己的理解来估计完成这个Story 所需的时间，从自己手中的牌里选1 张合适数字的牌，并发给大家看。游戏参加者各自解释选择这个数字的原因，尤其是数字最大和最小的人。
根据每个游戏参加者的解释，重新估计时间并再次出牌，直到大家的估计值比较平均为止。
在这个游戏中需要注意的是：首先，这不像普通的扑克游戏，不是轮流出牌，而是大家考虑好之后同时出牌，这样就可以避免后出牌的人被先出牌的人干扰；其次，要告诉团队成员，他们需要估计所有的Story，而不仅仅是他们自己将要做的那些部分，比如测试人员不能只估计测试工作所需要的时间。

《轻松Scrum之旅》的笔记-第116页

Sprint回顾会议的宗旨就是：Scrum团队如何在下一个Sprint中做的更好
Sprint回顾会议通常是最容易被忽略的。然而，Sprint回顾会议其实是非常有用的，它是这个Scrum开发框架中第二重要的事件（最重要的是Sprint计划会议），因为它是团队成长和进步的最好机会。

《轻松Scrum之旅》的笔记-第116页

Sprint 回顾会议由产品责任人、Scrum 团队和Scrum Master 参加，会议中需要讨论有哪些好的建议或方法应该被采纳，在Sprint 中有什么做法不可取，有哪些做法效果很好，应该继续下去。
Sprint 结束后，Scrum 团队回顾刚结束的Sprint，对其进行总结和反思，使整个团
队能持续成长。
Sprint 回顾会议的形式可以比较随意，主要做到以下这些方面就可以了。
总之，Sprint 回顾会议的宗旨就是：Scrum 团队如何在下一个Sprint 中做得更好！

《轻松Scrum之旅》的笔记-第79页

在混沌中建立秩序是sprint开始阶段的目标
要下班了，mark一下
Ordo ab chao

《轻松Scrum之旅》的笔记-第54页

对于那些功能需求可能经常发生变化的项目来说，Scrum 是最为理想的选择之一。在一个采用Scrum 的项目中，首先要将所有需要完成的工作列在一个Product Backlog中，项目开发过程中需求的改变也要写进去。在每个Sprint 开始之前，要召开一个Sprint计划会议。在这个会上，产品责任人（Product Owner）为Product Backlog 中的各项功能需求确定优先级。随后，Scrum 开发团队按照优先级，从Product Backlog 中挑选出他们认为能在这个Sprint 中完成的任务，并把这些任务从Product Backlog 中挪到Sprint Backlog 中去。在Sprint 的进行过程中，Scrum 团队每天都要举行一个简短的每日Scrum 会议，以便团队成员了解开发进度。一个Sprint 结束之后，需要召开Sprint评审会议和Sprint 回顾会议。开发团队在Sprint 评审会议上把这个Sprint 的开发成果展示给大家。而在Sprint 回顾会议上，团队成员们会回顾刚刚过去的这个Sprint，从中总结经验和教训。

《轻松Scrum之旅》的笔记-第173页

Sprint评审会议实际上是个非正式的会议。要避免过多地讨论技术细节，要重点关注最后的成果

《轻松Scrum之旅》的笔记-第132页

Story、Backlog、Task（任务），它们之间的关系是怎样的呢？在Scrum 中，产品要完成的功能清单叫做产品Backlog。每一个Backlog项通常也叫Story，因为它是由User Story 来描述的，一个Story 是由一个完整的UserStory 来描述的。有时候，一个比较复杂的Story 也可以分解若干个成更小的Story。Task 是任务，在具体实现每个Story 的时候都要将其分解成具体的任务，比如编码、测试、调研、Code Review 等，这些都是Task，而不能称为Story。

《轻松Scrum之旅》的笔记-第37页

什么是敏捷开发？它是一种开发方法学（Methodology），可以应对客户快速变
更的需求。它强调以人为核心，采用迭代的方式，循序渐进地开发软件。在敏捷开
发过程中，软件项目被划分成多个相互联系但也能独立运行的子项目。这就使得每
个子项目在开发、测试直至完成的过程中一直保持可使用的状态。这个过程实际上
就是要形成开发过程中团队之成员之间更加有效的合作关系，使其灵活性更高，以
适应不断变化的需求。敏捷开发过程与传统开发过程的最大的不同之处在于，在敏
捷开发过程中，团队是有激情、有活力的，能够适应更大的变化，生产出更高质量
的软件

《轻松Scrum之旅》的笔记-第38页

敏捷开发方法的核心思想概括起来就是“适应变化”和“以人为本”

《轻松Scrum之旅》的笔记-第37页

敏捷开发强调以人为核心，采用迭代的方式、循序渐进地开发软件。
敏捷开发过程与传统开发过程最大的不同之处在于，在敏捷开发过程中，团队是有激情、有活力的，能够适应更大的变化，生产出更高质量的软件。
敏捷方法认为，人是软件开发中最重要的因素。开发团队成员之间有效的交流、沟通与协作，比单纯的编程能力更为重要。
敏捷方法认为最根本的文档就是源码

《轻松Scrum之旅》的笔记-第66页

Sprint Backlog 里的项目我们通常用User Story 来描述，User Story 是从用户的角度对系统的某个功能模块所作的简短描述。一个User Story 描述了项目中的一个小功能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值