如果用scrum做sprint plan，怎么确定user story和task？

Question

这两天我们请咨询公司的scrum master做顾问，为我们做scrum，开了几天的会，我怎
么觉得他们很忽悠。scrum master帮我们做user story的分析，就写了些As..., I
would like to..., so...的纸条，然后要我们打分，我也不知道为什么纸牌是1，3，5
，8，13，30，然后直接200，300了。而且我觉得他们的user story分析的也不对，有
些是feature，有些很epic，根本break down不出什么task了。

我们知道agile/scrum的基本原则，user story应该以用户的角度为主，粒度尽量小一
点。但是大家做scrum的时候，user story和task都是怎么分析的？sprint是怎么计划
的？

Answer 1

咨询公司当然像忽悠啦，不像才是奇怪呢~以前 StackOverflow 做调查，ThoughtWorks 是程序员最不喜欢的公司（貌似不是之一），可见一斑~

下面我来根据自己山寨的 scrum 理论和实践经验，稍微谈一下自己关于的理解，不一定正确。由于我并不是对着任何教材或官方文档来回答问题，所以请不要吐槽我说的哪里不够标准哦~

---

Scrum 过程的特色在于它是个可控的黑箱。每个 sprint 都是相对固定的时间长度，一旦 sprint 开始，其中的需求就不应该发生改变，时间结束的时候应该能产出计划好的产品。从外部看来，一个 sprint 就像一个黑箱一样，给固定的输入，得到固定的输出。

为了可控，scrum 的 sprint 计划会议极为关键，要点是保证需求稳定不发生改变。计划会议的最终目的是让 scrum team 中的每个人都明确自己的工作量和依赖关系，而要确定这些东西的大前提就是需求足够的清晰明确，且 sprint 结束前都不发生任何变化。不变是 scrum 能像黑箱一样运行的大前提，试想，如果需求做到一半砍掉了或者发生很大的内容变化，以前开会定下的各种 task 就会发生根本变化，导致计划成为废纸一张，sprint 也就执行不下去了。因此，一般 sprint 计划会议最终决策的时候，必须有 stakeholder 过来拍板认可，也算是在这个场合里给大家一个准信，确保这些 task 像泼出去的水一样不会再变了。

需求稳定还只是一个要点，最终还是要落实到 task 上。从需求到 task 其实还隔了几道墙，一方面并不是所有的需求都是真实需求，有时候 stakeholder 自己可能都不清楚自己想要什么，另一方面从产品概念到实现也不是一目了然，需要把各种细节提前约定清楚才行。这里面就需要引入一些需求分析的工具。

User story 是帮助需求分析的一个工具，各种敏捷方法貌似都比较推崇这种需求分析的方式，这种方式跟写一个需求分析文档或产品设计文档都没什么本质差别，只是个工具。从题主的描述来看，我猜想你所在的团队之前应该从未使用过 user story 来分析需求，所以感觉会比较虚也比较难以分解成 task。如果咨询顾问们无视你们之前的需求文档/产品文档的风格硬要用 user story 来套的话，有可能他们犯了形而上的错误。

能够清晰的分解成可执行、短小的 task 的需求才是好需求，无论用 user story 还是拿友商的同类产品直接山寨还是老板某天洗澡突发的灵感，只要是个 stakeholder 想要做且细节都定义清楚了的需求都是好需求。反之，如果无法分解，那就是需求分析的失败了，管你什么炫酷的方法都是浮云。像题主所说，一个任务给 200 或 300 的估计，那就是需求完全没有细化的结果，要知道那个数字的单位一般是小时，而一个 task 一般都不要超过 16 才对。

一旦需求分析完成，分解 task 就应该水到渠成才对。如果技术团队因为技术细节不确定而无法分解需求，那么暂停会议，会下讨论清楚再来。分解 task 本身没什么好说，跟传统的分任务一回事，其中 scrum 比较可取的一点就是那个 planning poker，每个人把自己的时间当做资源，通过 planning poker 这种比较好玩的方式分配自己的时间直到时间耗尽。当然啦，这种形式本质上就是想确保每个人都能均衡的完成任务，免得出现瓶颈，如果达到同样的目的采用其他方法排任务也无妨。

---

总结一下，关于题主的几个问题的回答。

• 如何分析 user story？
  
  
  • User story 是从用户的角度提出问题并找到解决方案，进而分解出可执行的 task。假设要给 SegmentFault 加个问卷调查功能，那么就从用户怎么使用问卷入手，从各种交互中最终发现页面具体逻辑和需求，确定需要哪些页面、如何交互、如何呈现，从而完成分解。
  • 山寨的说，user story 的源头就是 stakeholder 想要的需求/功能，分解过程就是这个需求怎么用，最终结果是这个需求怎么做。其实，这跟传统的写产品文档没有区别，只是能让整个产品团队都明白需求点的来龙去脉，也许能够更加调动所有人的积极性。
  • 就算是设计 api，也可以用 user story，把 api 调用者当做 user 来理解就好。
  • 要是不清楚怎么设计 user story 也没关系，能分解的需求就是好需求，定出 task 才是关键。
• 如何分解 task？
  
  
  • Task 的关键是要有一个明确的完成条件，比如实现 XX api、实现 YY 功能点等。如果程序员负责写单元测试用例的话，通过单元测试是一个比较明确的完成条件。
  • 要足够的小，不能超过 16 小时，或 2 ~ 3 天吧，目的是为了能够很好的控制延期风险。
  • 不要太小，半天或一天做个需求最舒服了，太小的话计划所花费的成本可能都大于实现需要的成本了，不划算。
• Sprint 计划会议如何开展？
  
  
  • 先准备好差不多成型的需求，如果没有，让少数一两个人先细化的差不多。
  • 开会讨论需求，让所有人清楚。有 user story？很好，讲给程序员听，让大家参与进来。没有 user story？无妨，反正明确了需求让程序们做就是。
  • 分解 task，确保每个人的 task 足够明确可完成，不是很大，没有失衡。
  • 可能要开几次会议，每次发现有任务分解不下去的时候终止会议，下去解决细节问题，等解决后再开会。

---

P.S. 几个个人的小经验，也许反传统，但貌似会比较有用。

• Sprint 计划会议的需求应该在开会前就有专人（比如产品经理）差不多细化好了，在计划会议上大家一起细化（甚至还想一起从头开始分析）几乎是浪费时间且难以达到效果的做法。
• Scrum 执行过程中必然会有意外发生，比如某些事情超期完成甚至需求发生变化，scrum master 要想协调好还是得了解业务细节加上有一定权力，scrum team 自治或者空降 scrum master 说不定会遇到大问题。
• Scrum 是需求驱动的，如果执行的好，往往意味着技术会不得不用一些 quick & hack 的方法快速完成任务，输出的代码有可能会比较缺(luan)乏(qi)质(ba)量(zao)，如果没有强力的技术负责人推动重构，代码也许会快速劣化影响后续的开发速度。最好隔一段时间就搞个 mini sprint 专门用来处理这些技术问题，不要一味求快，得有个人顶住老板的压力来优化质量才行。
• 中国的程序员普遍对 scrum 热情不高，不要指望每个人都会积极参与 scrum 的各个过程。没关系，不要纠结于是否有 scrum team 的氛围，只要这些人能够出活就行，性格如此，无需强求。

P.S.S. Scrum 是在互联网大潮来临之前提出的方法论，如果传统软件行业还好说，如果放在互联网行业，scrum 过程中对需求稳定性的假设很可能不成立。如果发现始终无法在 sprint 中稳定需求，那么或许要仔细思考是否真的要严格执行 scrum 了。

软件工程的东西终究是为了解决问题而存在的，如果反而造成了问题，不如果断抛弃。