敏捷展示会的七宗罪与团队实践反思

前言

最近在看《深入核心的敏捷开发》这本书，发现确实有不少干货的，能够解答我不少问题，特别是其中对于展示会的论述很到位。

七宗罪

准备工作没做好

由于参与展示会的目的是展示迭代成果，参与人员大多是关系到项目成功与否的关键人物，因此会有不少的上级领导或客户代表等大佬，他们时间都很忙，所以如果到了预约时间无法进行演示那么情况就不好了，你能想象你的老板盯着你花了半小时才的启动好系统，却发现数据不对么？可能给团队带来极为负面的影响。

没有上下文铺垫

同样的原因参与展示会的大佬普遍缺乏对于本周期的任务的了解，所以你直接将功能也许他们听的也是云里雾里，这样就达不到取得反馈的效果了。

逐条过AC

这个跟上一条一样的原因，演示内容前要首先建立场景，把用户故事体现在到场景中。

企图覆盖所有路径

展示会不是用来测试的，所以没有必要覆盖全路径，大佬一般是没有耐心讲解各种路径的。

过多提及演示无关的内容

展示会要集中在本周期完成的任务中，从参与者的反馈中获取有价值的信息从而对于后期的开发进行及时的调整。

认为只是BA或QA的事情

这个对于团队的伤害是很大的， 展示会是要展示团队的工作成果，跟每一个人都息息相关。每个对于业务熟悉的人都应该进行演示，以达到展示个人能力和与客户交流的效果。

不熟悉的新人负责展示

这个就不用说了吧，你做的东西再好，一次失败的演示也能搞砸一切，所以演示这种事要交给能够有对应能力的人。

团队思考

1. 相较之下目前团队在评审会议或展示会上的做的差的很远。甚至在评审会议中很难邀请到直接比较能代表客户的市场人员，更别提是真正的客户了。改进：提前一周跟重要人员约时间，重大节点邀请用户。
2. 演示内容也是缺乏准备，更多的是把大体的功能过一下，场景构建和数据准备都很不足。改进：将演示添加到任务中。
3. 评审会议的参与感较差，演示总是由SM负责，研发人员总是看耍猴的既视感。。。改进：轮流主持演示。

参考

1. 《深入核心的敏捷开发》之展示会的七宗罪