火星人敏捷开发手册笔记

火星人敏捷开发手册笔记

Scrum敏捷开发方法

Scrum敏捷开发过程由多个冲刺（sprint）组成，每个冲刺表示一次迭代，周期通常是2-4周。在进入冲刺之前，产品负责人（product owner）需要提供一个产品待开发项（product backlog），这是一份从客户价值理解和描述的产品功能条目。开始冲刺后，第一天要召开冲刺计划会议（sprint planning meeting）。产品负责人按照优先级逐一对功能进行讲解，开发团队就需求细节和完成标准进行询问，估算任务量，然后加入冲刺待开发项（sprint backlog）。当任务量饱和时，迭代计划会结束。在冲刺内，任务不会发生大的变化。开始冲刺后，开发团队决定任务分配和技术选型，并逐一完成任务。每天开发团队进行一个简短的每日立会（daily stand-up meeting），沟通当前进度、下一步任务和遇到的问题。开发团队还维护一张燃烧图（burn down chart），以观察和预测工作进度。在冲刺的最后一天，开发团队召集评审会（review meeting），请产品负责人对已完成的产品功能条目进行评审，后者给出改进反馈。然后开发团队召开反思会（retrospective meeting），总结本次冲刺中的成功和不足，在后续冲刺中改进。

Scrum中的工作产出物

• 产品待开发项。从客户价值角度理解的产品功能列表。功能、缺陷、增强都可以是待开发项，重点描述使用方法，以客户价值为优先级排序。通常每个条目的工作量在0.5-10人天。
• 冲刺待开发项。从开发技术角度理解的迭代开发任务。
• 可工作软件（working software）。可交付的软件产品。产品负责人、客户代表根据可工作软件进行评审。“差不多完成了”的产品不应被视为可交付。

Scrum中的角色

• 产品负责人。负责产品需求的提炼、条目化、优先级排序。
• Scrum大师。负责维护Scrum方法的秩序，协助解决非技术问题。
• 团队（Team）。以扁平方式组织和管理，完成开发工作。团队是“自组织”的。

Scrum实施中的一些细节

• 产品待开发项怎么写。产品待开发项要包含角色、功能、价值三个要素。角色是用户在该场景下的身份，功能是角色执行的操作，价值是操作完成后，角色得到的利益。比如：作为一个观众（角色），可以查看电子节目单（功能），以了解一周以内所有电视频道的节目日程（价值）。要注意的是，角色必须明确，不能用模糊的“用户”替代。
• 有了文档为什么还要迭代计划会。文档类似电影剧本，迭代计划会类似导言说戏。让开发者对迭代任务和用户价值有更全面和深入的理解。
• 如何判断任务量饱和。通常开发者只有70%的时间可以投入到开发工作，因此每个人月安排15人天左右即为包和。对于新团队，可能低至10人天。
• 任务量估算。采用共同估算的方式。在估算前不应指定承担任务的开发者，而是以团队为单位进行估算，每个人提出自己的看法，综合起来。共同估算的目的是用集体智慧和知识对“做什么、怎么做”达成共识。产品负责人必须全程参与估算过程，产品复制人需要解答团队提出的“做什么，做到什么程度”的问题。
• 扑克牌估算（planning poker）。产品负责人向团队进行讲解后，团队中每个人独立进行估算，选择对应的扑克牌，扣着放在桌上。所有人都完成估算后，进行开牌。如果估算结果较为接近，以平均数作为团队估算结果。否则让估算数值最大和最小的人进行PK，其他人也可以参与讨论。讨论结束后，重新估算和开牌。
• 每日立会时长。每日立会通常10-15分钟。
• 燃烧图怎么画。燃烧图的横坐标是时间，纵坐标是冲刺待开发项的剩余时间。
• 如何处理延期。敏捷开发采用时间盒（time boxing），即限定时间，而非限定范围。因此迭代不会延期。对于无法完成的待开发项，放弃这个任务。
• 评审的标准。评审的标准是产品功能是否达到可交付标准。“差一点”不能算是可交付。可交付标准在冲刺计划会上，有产品负责人和团队沟通确认。
• 反思会如何召开。反思会应当每次仅就关键的1-3个问题提出可行的解决方案。可行在这里是指：
  • 一、方法简单、影响面小、见效快。
  • 二、目标不要激进，要现实可行，积少成多。必要时，反思会可以执行领导回避制度，即具有管理职能的人回避。
• 如何分配任务。任务由开发者认领。

用户建模

• 用户建模的目的。理解哪些用户，为解决哪些问题或达成哪些目的而使用该产品。
• 用户建模的步骤。
  • 一、列出尽可能多的用户。
  • 二、识别关键用户，即购买决策者和主要使用者。
  • 三、合并次要用户。
  • 四、面向关键用户编写用户故事。

编辑记录

• 2019年8月27日 建立文档。
• 2019年10月28日 修改格式。