《用户故事与敏捷方法》读书笔记

如果要开始一个敏捷项目，应该如何开始和逐步进行下去呢？有没有一些套路是我们可以学习和借鉴的呢？
以下就是我阅读这本有Mike Cohn写的《用户故事与敏捷方法》书后，自己的出来的一些经验。要开始一个敏捷项目，步骤有：

1. 识别用户

2. 与用户代理合作
3. 搜集故事
4. 编写故事
5. 估算故事
6. 确定故事优先级
7. 确定团队工作速率
8. 创建发布计划
9. 验收测试
10. 迭代计划
11. 测量并监控速率。

---

在开始详细介绍前，要先介绍一个引子结论：3C原则（Card，Communication，Confirmation）

一，识别用户

识别尽可能多，全方位全维度的各类型用户。

• 头脑风暴、整理角色、整合角色、提炼角色
  具体操作方法为：让尽可能多的干系人先各自在卡片上写下自己认为的用户。然后将卡片贴在墙上，经过一轮又一轮的讨论，最终达成一致的意见。

• 两个额外的技术
  虚拟人物：用户的假象代表。注意：虽然是假象的，但要将这个用户尽量的具体，尽量的真实。
  极端人物：一些平时不太容易出现，但确实存在的人物。（在极端人物上花费大量时间是不值得的，切忌拣了芝麻丢了西瓜。）

---

二，与用户代理合作

• 当我们识别用户后，理想的情况当然是想跟真正的用户开展接下去的工作。然而然而，在大部分情况下，真正的用户（就是真正使用这款产品／软件的人）就像我们的女神一样，可望而不可及。
  实际情况下，愿意跟我们这些技术人员联系的是他们：用户的经理、开发经理、销售人员、领域专家、市场营销团队、以前的用户、客户、培训师、技术支持、业务分析师或系统分析师。
  这些人我们统一称为：用户的代理。
  应该如何处理用户代理的情况呢？
  让我们分两种情况进行讨论：

能接触到用户代理但访问受限时：
对策: 邀请几个到几十个真正的用户成立"用户顾问团队"，顾问团队能够提出意见和建立，但真正的决定依然有用户代理来做。

实在不能接触到用户时：
**对策1: **使用多个用户代理，博采众长，也能规避一定的风险。
**对策2: ** 尽早发布产品，尽早让真正的用户能够使用产品，也就能够尽早得到真正用户的反馈。

---

三，搜集故事

方法:

• 用户访谈
• 问卷调查
• 观察
• 故事编写工作坊（头脑风暴与原型设计的结合）

金句:

• 搜集需求要像拖网（Trawling）一样：不同大小的网用来捕获不同大小的需求；需求会像鱼一样，会成长，也可能会死亡；捕获的过程中，也可能捞到一些废弃的货物。
• 确定需求是一个渐进明细的过程。一开始无法给出一个明确的需求，但是依然可以给出一个故事来作为"占位符"。

---

四，编写故事

INVEST, INVEST, INVEST(重要的事情说三遍）

I：Independent（独立的）
N：Negotiable（可讨论的）
V：Valuable to Purchasers Or Users（对用户或客户有价值的）
E：Estimatable（可估计的）
S：Small（小的）:对于无法做估计的复杂故事，将它分解成一个做调研的故事（用探针实验）和一个开发的故事。
T：Testable（可测试的）：尽量用自动化测试。

故事的套路：
我作为（角色），想要（功能），以此（商业价值）。。。

---

五，估算故事

• 用故事点进行估算，常用一个理想工作日的工作来表示一个故事估算点。
• 估算是团队估算的结果，不是个人的。（可以采用头脑风暴的方法）
• 通过和其他估算进行比较来进行三角测量。

---

六，确定故事优先级

• 故事的优先级有客户决定，但也要考虑开发人员的意见。
• Moscow原则：Must，hould，Could，Won't have this time。
• 敏捷方法强调：先做最有价值的东西。

故事优先级是如何体现在故事卡片上的呢？

---

七，确定团队工作速率

• 速率：团队在一个迭代周期内完成的故事点数（或期望完成的故事点数）。
  如何确定团队速率

1. 使用历史值

2. 执行一轮初始迭代，使用那轮迭代的速率。
3. 猜测：考虑到各种各样因素的干扰，一般我们把i 轮迭代改进的1/3到一半的开发日作为预计速率。如一个团队6个人，十个工作日为一个迭代周期，则总的工作日为60,计划的速率则应该为20~30个故事点。

---

八，创建发布计划

• 根据故事的点数，故事的优先级，团队的速率，创建发布计划。
• 理想情况下，开发人员和客户可以谈一个日期范围，而不是一个具体日期。
• 诚实的把发布期限告知开发人员，而不是故意告诉一个提前的日子。（信任，信任呢！！！）
• 开发人员和客户共同选择迭代长度，难以确定时，请选择短迭代而不是长迭代。

---

九，验收测试

• 为什么需要验收测试？
  验收测试将用户与开发人员之间Commnication的部分更加的明确化和细化，从而保证了开发人员的设计满足用户的要求。与DOD的意思一致
• 什么时候写验收测试呢？

1. 编写用户故事的时候（将测试要点纪录在故事卡的背面）
2. 在一轮迭代的正式编码前。
3. 在开发中或之后的任何时候发现新的测试的时候。
   切忌：在正式编码要有验收测试的ＣＡＳＥ．

金句：

• 一个优秀的开发团队会为很多详细的用例写单元测试。
• 测试的是缺陷，而不是覆盖率。如果一个团队一直强调我们的测试覆盖率是多少多少，那么很有可能他们做了很多用户并不需要的工作。如果测试对产品是有价值的，不管他的覆盖率是多少，都要继续测试下去。反之，一旦测试没有价值，就立即停掉。
  问题是，怎么判定测试是否还有价值呢？

---

十，迭代计划

• 其实就是sprint planning meeting
• 在迭代开始时进行这个会议，会议中团队讨论每个故事，然后从故事中分解出任务。每个任务需要有一个对应的负责人，以及每个任务所需的估算时间。
• 团队中需要有人记录下上述讨论的内容，可以记录在项目的白板上。
• 在整轮迭代中，负责监控自己剩余的工作，同时也需要监控队友剩余的工作。如果很快就能完成自己的工作，就有责任帮助队友承担部分工作。

---

十一，测量并监控速率

• 用集中全部力量完成一个故事的方法会提高团队的意识，好过所有的故事都只完成一部分。也建议一个故事完成后再做下一个。
• 让程序员觉得增加剩余时间估算和减少是一样正常的。
• 再公共区域的一个地方，挂上白板，用黑胶布作为固定的坐标轴线，这样在修改图的时候不会被擦掉。接着就定期更新下面这三个图：累计故事点、剩余故事点燃尽图、剩余小时每日燃尽图。