因为之前工作是做产品经理，为了及时地迭代产品功能、满足客户需求，我之前待的两个团队都有实践过敏捷开发。

在某一个迭代的需求澄清会上，作为产品经理的我准备了下个迭代要做的几个需求。当时，研发经理提出来说 “需求澄清会跟下个迭代要做什么是没有关系的，产品经理要讲手头上可讲的所有需求。然后，研发再筛出来可做的需求来安排工作”。“ 嗯？？” 心想，要回去系统地再了解看看。

然后回家开始翻起16年就购买的书：《用户故事与敏捷方法》，作者是Mike Cohn。

《用户故事与敏捷方法》书封面

如何实践敏捷？

1. 首先，收集故事

作者提出了收集故事很形象的一个词，叫“拖网”（trawling）。收集需求的过程，就像捕捞鱼一样，要用不同大小的网来捕获不同大小的需求。因为需求像鱼一样，会成长，也可能会死亡。重要性可能会降低，有时甚至降低到我们认为这些需求已经无效。

搜集故事的方法有：

• 用户访谈
• 问卷调查
• 观察
• 故事编写工作坊

同时，也可以通过与用户代理合作来收集故事。可以合作的用户代理有：

• 用户的经理：比如客户A是直接使用产品的用户，那找A的上司
• 开发经理：最坏的选择之一，除非软件就是给开发经理用的。要不然开发往往为了提早使用令人兴奋的新技术，讲故事的优先级不以产品的“价值”来做排序。
• 销售人员：最危险的选择。对销售人员来说，最重要的故事是那些如果没有实现，就会导致她“丢单”的故事，因此销售主导的产品不会有一个全面的蓝图。但这些资源我们要充分利用，通过他们把客户引荐给我们。

2. 根据收集来的需求，编写用户故事，并放入产品Backlog中

2.1 编写故事前，先对用户角色进行建模（约1小时）

方法：列表 >> 整合 >> 排列 >> 提炼

先头脑风暴，将这个产品目标用户的不同角色进行罗列，列个列表。这里要坚持的原则是，用户角色定义的是人，而不是其他外部系统。

根据上面列的用户角色，再做角色的整合。将多个类似角色，合并成一个单一的角色，也要丢弃对系统成功不太重要的角色。

之后是通过排列角色，展示已选角色之间的关系。最后，来提炼角色，描绘角色特征。

在这一个角色建模的过程中，我们可以从以下几点，对该角色进行特征描述：

• 用户使用软件的频率
• 用户在相关领域的知识水平
• 用户使用计算机和软件的总体水平
• 用户对当前正在开发的软件的熟练程度
• 用户使用该软件的总体目标。有些用户注重实用的便捷性、有些关注丰富的用户体验等等。

2.2 用卡片，记录用户故事

记录故事前，要先明白 “用户故事不是什么”。

• 不是IEEE830： 故事不是关于如何编写软件需求规格的指南。比如不能写成“系统应该允许公司使用信用卡支付招聘广告费用”，主语不应该是“系统”，应该是用户角色。
• 不是用例： 用例是对系统之间以及用户之间交互的一般性描述，比较容易包括用户界面的细节。因为用例编写者会过早地关注软件实现，而不是去关注商业目标，会失去交流碰撞来完善故事的意义。
• 不是场景： 场景是用户与计算机交互的详细描述，跟用户故事的主要的区别是范围和细节。看以下例子：
  • 场景可以理解为是交互设计：Maria 用用户名和口令登陆到站点。是否所有用户都需要登录？或者登录后是否允许Maria使用某些功能？
  • 故事可以理解为是需求设计：用户可以通过电子邮件给好友发送工作信息。

好，开始记录故事。

卡片代表的是客户需求，而不是记录需求。需求细节在“对话”中获得，并在“确认”部分得以记录。推迟细节很重要，因为这样一来，我们在不确定是否真正需要某个新特性时，可以不花过多时间来考虑它。

卡片正面记录故事

模板：“作为（角色），我想要（功能），以此（商业价值）。”

有时，上面还附着另一张卡片写着验收条件，也可以写约束故事卡片（约束卡不需要估算，也不会像普通卡片那样被安排到迭代中），标注“约束”。

卡片背面写测试故事的提示语句

可以是简短、不完整的描述。比如“A可以填写工作描述”的故事，可以写成“用空的工作描述来试试”或“用很长的工作描述来试试”等。

3. 召开一个Sprint计划会

有些团队会把Sprint需求的说明会和Sprint工作计划会隔开，我以前在的团队就是第二周周四是 “需求澄清会”，周五是“Sprint计划会”。具体看团队需求的量，以及沟通频次，哪个合适选哪一种。书里的做法是，将这两个会议放在一起了，即用“前半段” 和 “下半段” 来不同会议主题切分开了。

3.1 会议前半段，由产品负责人讲解故事

产品负责人把待开发的高优先级的功能介绍给Scrum团队，将下个迭代要进行的故事进行讲解，没有必要介绍产品Backlog的所有条目。（看到没，我看这本书的目的达到了，找到了答案！）

团队成员在讲解过程中，不断提出问题，讨论其中的一些用户故事，细化故事细节，确定验收标准。

3.2 会议下半段，团队决定下一迭代工作量

团队成员用计划扑克估算故事点。程序员估算一个故事时，要注意，应考虑完成这个故事需做的所有事。比如要全盘考虑测试代码、和客户讨论、可能帮助客户计划或自动化验收测试等诸多因素，不只是要考虑敲代码的时间。

️由程序员将故事分成一些小的任务，并估算工作时间后，根据历史值或预测来确定下个迭代的工作量，即确定要完成多少个故事点的需求。

之后，将故事放入Sprint Backlog中，并按照优先级排序。排列优先级需要考虑的事项有：

• 大部分用户和客户对特定特性的渴望程度。
• 小部分重要用户和客户对特定特性的渴望程度。
• 故事之间的关系。例如，“缩小”功能，这个故事的优先级可能不高，但是它可能被看作是高优先级的，因为它与高优先级的另一个故事“放大”互补。

4. 执行Sprint

4.1 初始阶段，各同学要干嘛

准备一个Dashboard，将故事卡片和任务卡片都贴在白板上

Sprint一开始，将故事卡片和任务卡片都放在白板的Todo栏，团队成员按照故事的优先级挑选任务，将任务卡片挪到Doing栏。

故事的任务完成后，产品负责人验收并确认故事已完成，将故事卡片挪到Done栏。

确认测试用例

故事开发的初始阶段，测试人员和产品负责人一起确认测试用例。

注意，只有团队成员才向Sprint添加工作

即使是CEO也不能让团队去做产品负责人没有提出的工作。产品负责人也不可以改变主意，往该Sprint添加更多的功能。只有在团队觉得，自己已经把Sprint承诺的所有任务都完成的前提下，才可以向Sprint中增加新的故事。

如果，真有十分重要的事情发生了，需要调整，那就把现在的Sprint取消，重新开新的Sprint计划会，然后启动新的Sprint。

4.2 Sprint每日例会

会议组织者确保所有人只回答3个问题：

• 昨天做了什么？
• 今天打算做什么？
• 有什么困难？

4.3 监控Sprint速率

有一个注意点，不用实际小时作为速率。计算速率是用迭代开始前分配的故事点数来计算。一旦迭代完成，就不要改变迭代中团队获得的任何故事点数。举个例子，假如一个故事估算是4个故事点，但其实更大。后来团队发现他们应该估7个故事点。在计算速率时，这个故事应该算4个点，而不是7个点。

主要的可视图表有：

• 计划速率 vs .实际速率对比图

  • 图：计划速率和实际速率

• 累计计划故事点和实际故事点：可以看出每轮迭代中完成的故事点

  • 图：累计计划和实际故事点

• 迭代燃尽图：更好展现项目的整体进展

  • 图：燃尽图说明

4.4 故事验收测试

测试工作可以包括从故事卡背面写下测试描述开始，到将测试放入到自动化测试工具中的所有工作。一般在下面这些时候写测试：

• 开发人员和客户讨论故事且需要记录明确的细节时
• 在迭代开始时，在写代码前作为一项专门的任务
• 在开发中或之后的任何时候发现新的测试时

测试类型有：

• 用户交互测试：确保所有交互组建如期工作
• 可用性测试：确保程序好用
• 性能测试：测量应用程序在各种负荷下的工作状况
• 压力测试：使应用程序在用户和事务的极限值情况或其他任何让程序处在压力下的情况运行

4.5 确定发布计划

如何确定发布功能优先级方面，可借用来自DSDM中排列优先级的方法，称之为莫斯科（MoSCoW）规则：

• 必须有（Must have）：系统的基本功能
• 应该有（Should have）：很重要但短期内有替代解决方法的功能
• 可以有（Could have）：如果没时间就可以在发布中不予考虑的功能
• 这次不会有（Won't have this time）：客户期望拥有但同时承认需要在后续发布中实现的功能

5. Sprint评审会

由开发人员演示本期迭代已开发的内容，团队审视自己是否达到了Sprint目标。

以上是一个完整敏捷迭代生命周期中的流程工作，比较简洁。如有任何问题，可留言继续交流。