项目管理（Scrum Master）的38个面试问题（二）

本书主要分为5个部分来讲，分别是 Scrum Master的角色、待办项的改进和估算、 Sprint计划、 每日站会、 回顾会；
以下是尽可能用易理解的语言来看待38个问题。

---

代办事项简要知识点

代办事项

---

待办项的改进和估算

1. 背景知识点：

   产品经理掌控产品待办事项以交付最大价值，但是他们需要整体团队的帮助。对于每个Scrum团队来说，待办事项的改进和评估都是非常重要的任务；

   把跨职能的Scrum独立于其他团队（UX、UI团队）是非常理想的方式，现实中经常依赖于这些团队；

   良好的Scrum团队表现主要有两个基本的要素：

   1. 整体编写用户故事：
      产品经理需要解释为什么要做（市场情报、实验结果、用户访谈、统计数据等）；整个Scrum团队一起协作编写用户故事，构建主人翁意识（产品：为什么做；Scrum团队：怎么做；共同定义做什么）。

   2. 达成用户故事’已就绪‘的定义：确保我们能够较为完整的完成用户故事的开发，在编写之后，Scrum团队应该和产品经理对用户故事’已就绪‘的定义达成一致。

      ’已就绪‘的定义：此定义是关于需要为用户故事提供哪些内容以使其准备好进行评估的约定。那么如何定义什么样的用户故事已经是’就绪‘的？这也是一位PMO负责人问过我一个问题，什么才是一个好的需求？可以参考：用户故事该怎么写

      在明确’已就绪‘之后，需要对用户故事进行评估，没有评估的用户故事是一个未知实体，Scrum团队不应该对未知实体进行承诺，只有评估过之后的用户故事才能当做冲刺待办事项的一部分。

2. 问答：

• 问题11 产品负责人从利益相关者那里收到的需求文档转换为故事卡片，给到你并要求对其进行估算。 你对此程序感觉如何？

问题意图：产品经理是否可以直接把用户需求转化为故事卡片，而作为Scrum Master是否允许类似行为？

可接受的回答：

1. 产品经理不可直接把用户需求转化为故事卡片，Scrum Master决不能接受这种流程，这是用伪敏捷的方式来掩饰瀑布流方法；
2. 组织应该专注于为客户提供价值，则必须放弃类似不经过Scrum团队成员共同评估产品需求的过程（对需要构建的内容达成一致意见），而只是进行开发阶段的做法；

关键点：需求评估需要团队成员一起评估

• 问题12 您需要产品负责人提供什么样的信息，以便为您的团队提供有关产品和市场情况的最新信息？

问题意图：候选人是否有关注到Scrum做出产品的价值？

可接受的回答：

1. 需要密切关乎到市场or客户的反馈信息，可以有定性（能更快的帮助用户）or定量的（用户满意度、用户点击率等）；
2. 通过参与用户访谈来参与收集相关信息，或是通过运营团队获取到相关的用户数据；

关键点：客户反馈信息，客户反馈渠道

• 问题13 谁应当编写用户故事？

问题意图：是否所有的用户故事应该由产品经理来负责编写？

可接受的回答：

1. 需要Scrum团队的共同努力，一起完成用户故事的编写；
2. 好处：主人翁的归属感，如果是分派，可能导致团队成员减少承诺，动力降低，最终导致产品质量下降；
3. 遵循用户故事编写规范（问题14）；

关键点：用户故事编写，全员完成，主人翁意识

• 问题14 好的用户故事是什么样的？它的结构是什么样的？

问题意图：候选人是否了解用户故事的编写规范？什么才是一个好的用户故事？

可接受的回答：好的用户故事应当具备以下特征：

1. 包含描述;
2. 具有可接受标准定义；
3. 能够在单个冲刺中交付；
4. 具有所有可用的UI交付物；
5. 具有所有（可能的）依赖项确认；
6. 具有性能标准的定义（达到什么样的性能）；
7. 具有跟踪标准的定义（各阶段应该实现哪些功能）；
8. 是整个Scrum团队估算的；
   

里面涉及了一些标准的定义，其实可以归结于DoD（完成的定义），即整合一下：

1. 需求的基本描述，（作为xx，想要xx，为了xxx）；
2. 能在一个冲刺中交付；
3. 相关依赖项确认（UI、UX文件、架构变更、数据准备）；
4. DoD；
5. 团队成员全员估算；

关键点：DoD， 全员估算完成，用户故事编写；

• 问题15 就绪的定义应包括什么？

问题意图：什么样才是一个好的用户故事？

可接受的回答：

1. 同问题14，已经告知用户故事应该包含哪些信息；
2. 采用用户故事使用框架(INVEST):

• Independent(独立的): 自包含，与其他用户故事没有依赖；
• Negotiable(可讨论到): 在进入冲刺计划之前，是可以重写和变更的；
• Valuable to Pruchasers or Users(有价值的): 对客户是有价值的；
• Estimateable(可评估的): 可以评估用户故事的大小；
• Small(小的): 不应该太大，超过20小时，就应该进行分拆；
• Testable(可测试的): 可通过测试的方式来定义完成状态；

关键点：用户故事编写要点；

• 问题16 为什么不能简单按工时估算用户故事？

问题意图： 如何进行用户故事的评估；

可接受的回答：

1. 人月神话中告诉我们了人力和时间不能简单的进行转化，人-小时的评估方式也是类似。
2. 真正目的是为了让团队所有成员之间建立未来任务的共识，所以，估算只是一个副产品；
3. 故事点的估算是一个好方法，可以准确反映出任务的复杂性和完成任务所需要的精力，可以使用planning Poker；
4. 用工时代替故事点来估算是传统的成本和预算项目管理，是实施了瀑布式的流程。

关键点： 故事点估算，plannig Poker；

• 问题17 你的Scrum团队的产品负经理倾向于将各种想法添加到产品待办事项列表中，工作下一个阶段工作的提醒，随着时间的累积，导致在过个阶段累积了200多个卡片，你对这种情况有什么想法？一个scrum团队能够从事200个故事卡吗？

问题意图： 产品经理的待办事项的管理；

可接受的回答：

1. 任何一个产品的代办事项如果超出2-3个冲刺的范围是很难进行管理的；
2. 需要与产品经理沟通，支持产品经理进行待办事项的管理，与干系人沟通，重新确认代办事项的优先级排序，重新整理相关人力；

关键点： 代办事项管理，干系人的需求输入。