假设你在一个使用敏捷软件开发流程的项目组，但是，你们组没有做严格的kickoff。某一天你领了一个文件上传的用户故事卡的需求，你觉得很简单，因此没有做kickoff，就开始开发了。
花了2天时间，你自认为写了一个很漂亮的文件上传模块。但是，在需求验收环节结果却是，你的实现，业务分析人员想要的样子，测试人员以为的样子，这三者竟然都不一样。
这个结果无疑是一个悲剧，经过一番思考，我们会发现这个问题的根因是：与这个story相关的人都犯了同样的一个错误：做了一个包含以下两点的假设：
1： 我对这个需求的理解是正确的
2：其他人的理解和我的理解相同
如果继续发掘，会发现让大家产生偏差的理解的材料，却是唯一的：那张唯一的用户故事卡。
那为什么仅仅只是凭借那张包含文字描述，或许还辅以图片的用户故事卡, 无法传达出唯一的，准确的需求呢？为了回答这个问题，有必要先来认识一下用户故事卡。
用户故事是什么，不是什么
在《用户故事与敏捷方法》一书里面，对用户故事有这样的描述：
由于用户故事的描述信息以传统的手写方式写在纸质卡片上，所有Ron Jeffries(2001) 对这三个方面起了一个非常好的以相同英文字母开头的名字：
1 卡片（Card）
2 对话（Conversation）
3 确认（Confirmation）
“卡片”包含用户故事的文字描述，然而需求细节要在“对话”中获取，并在“确认”部分得以记录。
所以，我们似乎可以回答前面关于用户故事是什么，不是什么的问题了：用户故事代表客户需求而不是记录需求。
用户故事的目的之一是让大家交谈。需要交谈是因为书面语句，对于表达像软件这么复杂的需求是比较有限的。
而用户故事卡的kickoff环节，正是这样一个把相关人员集中到一起交谈的环节。
那么 kickoff 需要那些角色参与？谁来主导？需要确认什么呢？
参与角色
一般来说需要4个人：
1 写这个需求的业务分析师（BA）
2 负责UI设计的设计师（UX），如果这张卡涉及UI的话
3 准备去实现这个需求的开发（Dev）
4 准备去测这个需求的测试人员（QA）
谁来讲解
在BA，UX，Dev， QA这四个角色中，一般会让BA或者Dev来讲解这个需求的内容。
让BA来讲解的优点在于BA是对这个需求的上下文，需要特别注意的细节，是否和其他卡有一定联系这些方面最了解的人，如果由BA来讲解会输出非常全面的信息。
让Dev来讲解的好处在于，比起单纯地从BA那里被动输入信息，Dev会提前阅读用户故事，自己先消化，会加深对这个需求的理解，也能在kickoff环节产生更多有价值的提问，确认尽可能多的待确认项。
所以，比较推荐由Dev来主导解读用户故事的需求，而BA可以补充上下文和细节。
确认什么
BA和UX作为需求的提出者，在kickoff的过程中承担着解释和确认的工作。Dev和QA作为需求的实现和验收者在kickoff中则主要作为问题的提出者，尽可能多地提出和这个用户故事相关的问题，比如：
1 这个需求的价值（就某些不那么显而易见，且没在用户故事卡里写明的情况）。
2 确认需求细节。比如一个上传文件的模块，确认可支持上传的文件类型。
3 确认scope(范围)。比如要替换一个logo，是否是每个页面都需要替换。
4 性能问题。比如一个上传文件模块，上传超时时间是多少。
5 如过Dev已经提前有了一些实现的思路，也可能会和QA交流，QA由此获得一些测试的思路。
6 某条需求点是否是可灵活变动的（比如某个前端的组件UX是接受开发的具体实现和现有的设计不是100%匹配的）。
理想的kickoff就是，BA， UX， Dev， QA大家对这个用户故事所包含的需求的理解是一致的。
然而现实情况却往往不那么完美，我们也或多或少遭遇了一些kickoff的困难，让我们来看看经典的都有哪些，以及如何解决。
kickoff的困难
1 经常凑不齐人
2 参与人员参与度不高
3 故事卡本身达不到可以被kickoff的标准
经常凑不齐人
如果是偶尔一两次凑不齐人，倒也不是特别严重的问题。但是，如果经常出现这种情况（常常是因为项目里面某些角色太忙，会议占据太多时间），那就是一个需要被重视和解决的问题。一般可以采取两种方案：
1：提前约时间
2：每天固定一个时间段做kickoff
参与人员参与度不高
这个情况常常出现在参与人员没有提前读需求（或者没有时间提前读），导致在kickoff的时候只是被动的接收需求宣读。理想的kickoff是参与人员都提前读需求，带着待确认项来参与kickoff。不然就会出现，在kickoff之后还需要反复确认一下问题，确认的问题又需要再一次都同步到相关的所有人，这个是比较耗费时间和拉低效率的事情。
如何解决这个问题？这里提供一个思路：
因为kickoff常常由Dev发起，所以Dev在决定要kickoff某张用户故事卡之前，可以先通知到相关的人员你稍后准备kickoff那张卡，这样大家都可以提前读需求，然后带着问题去参加kickoff。
故事卡本身达不到可以被kickoff的标准
这个情况其实不常出现，但是确实也有出现过的情况。比如，在kickoff过程中，大家交谈下来发现，这张卡其实和另外一张卡有依赖（虽然从用户故事卡的原则出发，这种情况不应该出现）或者有待确认项目前无法得到确认等因素导致Dev和QA目前无法开始工作。
这种情况的话，就也许需要把这张卡从Ready for Dev一栏移走，需要BA进行更多的分析工作。
结语
写这篇文章的过程中，和不同的角色（BA, UX, QA， Dev）进行了交流，获取了大家对kickoff这一环节的想法，不同的角色看问题的角度会有很多不同，但是相同的一点是：kickoff是敏捷软件开发流程里特别重要的一个环节，希望项目人员对kickoff有尽可能全面和深入的理解以及保持敏感：如果kickoff环节出现了问题，需要及时纠正回来。
