---谈谈为什么你的开发团队要做好showcase
一点背景介绍：目前我所处的金融业务渠道研发团队是按技术进行划分，分为前后端多个研发团队和测试团队（不是一个敏捷组织架构）；业务线处在高速发展中大量系统功能亟待上线且周围市场变化也比较快；开发团队采用双周迭代节奏进行研发。
因此我们的困难也是非常突出的，主要表现在
1）产品需求量非常大而且比较粗糙，双周迭代时间紧张，很多需求在来不及分析同时变更亦非常频繁，开发疲于应对；
2）开发周期内发生方案变化可能性高，无法及时移测，以及测试阶段的时间有限，质量达不到预期；
实际上，在整个开发周期内，我们有三个机会对交付物进行干预：
1）需求分析阶段，通过分析（PO、SA系统分析师）
2）开发阶段结束showcase，展示系统功能的大概并接受小量变更；
3）测试阶段，决定是否发布；
而以上三个阶段，只有阶段2是开发可控的，这个阶段的结束在scrum中是以showcase为标志。
作为开发团队，showcase要做几件事情
1）邀请重要PO到场，对交付效果进行认证和调整（接受必要的变更）
2）开发团队进行功能展示，并对系统功能进行解释（系统功能说明书）showcase完毕后，正式将功能移交给测试
3）测试认可并正式接受代码；
Or 异常分支，快速死亡。
极少数时候， 你会在showcase时发现整个团队的方向完全错误，并且是当前迭代内无法修复的。那么这个时候可以做出将代码撤出迭代的决策，避免在UAT发生变更导致整个版本的风险。
为了控制质量，我抓住showcase环节的目的是争取将不确定的消除在开发过程中，同时集体showcase也有利于建立规则，确保开发开发节奏。
在我所处的技能划分的组织下，组织showcase会遇到一些困难。可能刚开始你邀请的产品经理、测试并不能理解这些动作的意义，那就需要发扬“厚脸皮”精神，或动用领导影响力，尽量把po和测试邀请到现场。
实际上我们在几个迭代的showcase之后，产品经理就充分理解了这个活动的意义，并且到目前为止我们团队的showcase效果都是比较理想的，基本没有出现大功能研发过程的偏差。
