Question

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

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
这种比较好玩的方式分配自己的时间直到时间耗尽。当然啦，这种形式本质上就是想确保每个人都能均衡的完成任务，免得出现瓶颈，如果达到同样的目的采用其他
方法排任务也无妨。