设计评审和测试用例评审我们都是迭代的第二天做，一般会给开发人员半天的时间思考一下他自己故事的设计，然后抽出1-2个小时进行设计评审，设计评审完后就做测试用例评审。
设计评审就是让团队帮你查遗补漏完善你的设计，而测试用例是测试、PO、开发三者又一次落到实处的交流。
设计评审和测试用例评审都是为了解决产品质量问题而提出来的解决办法。
我们团队敏捷开发前期也是没有搞设计评审和测试用例评审的，是有几个迭代产品的质量老是提不高，在迭代回顾会议中大家讨论出，就算设计评审和测试用例评审会占用我们的开发时间也必须要搞，不然产品的质量永远提不上来。
我觉得定这个制度的由来可以好好说一下，那是在云HIS项目第二个阶段临床部分开发的Sprint2的回顾会议上提出来的，因为这个迭代失败了。团队在做sprint 评审会议展示产品成果的时候错误百出，药品入出库的流程都跑不通，当场PO就拒绝验收本次迭代的故事，宣布迭代失败。接下来的迭代回顾会议时，大家表现得比较沉重，SM就安慰大家，失败的迭代也是迭代，对团队也是好事，正好可以总结经验嘛。X君脾气比较火爆，一下就开火了，“我就搞不明白，为什么要这么赶，一个迭代塞这么多故事，这还是不是在搞敏捷？”这是现实情况，因为这个项目周期比较紧张，所以一些功能就按系统倒排，就导致每个迭代的故事多了一些。T君是SM，“这个迭代故事多是一方面原因，但不是降低质量的根本原因，搞敏捷有时候搞些强的冲刺也是正常的，并且迭代计划会议大家已经对这些故事做出了承诺，所以我们应该找出这次失败的原因，而不能抱怨找理由推卸责任”。Y君平时话不多，但写代码做事非常踏实，“产品的质量不好，我觉得是设计这个环节做得太仓促了，没搞敏捷之前我们开发经管部分是花了一个月时间做设计的，设计表结构、画用例图、时序图、类图，编写设计文档，但一个迭代才两个时间根本没有留时间做好设计。就像Y君和H君，你们两个同时使用的那个字段状态的定义，在迭代快结束了还在变来变去，一方刚修正bug，另一方又产生新的bug，如果提前大家一起把这些设计细节讨论请求就应该不会出现这种问题。”H君认为Y君说得很有道理，问题是设计该怎么做，像以前那样花一个月时间写设计文档肯定不行，那不是有回到以前传统的那种开发模式上去了？接下来大家深入讨论怎么做符合敏捷的设计，首先像以前那么详细的设计文档肯定没时间写出来，为了节约时间设计文档不写了，本来敏捷就提倡轻文档重沟通，重点是一定要提前做出设计，而不是在编码过程中思考设计，所以决定每个人提前做好设计，然后进行设计串讲，每个人把自己的设计讲出来让大家提建议，没有设计文档建议画一些流程图或者在白板上讲解自己的思路，讲完之后再拍照下来，分享在群里。后面的迭代按照这个想法尝试，效果还不错。再后来由于每个人讲解设计的方式差别太大了，没有统一的表述方法，为了提升沟通的效率，又制定了一个简单的设计文档模板，所以慢慢的就形成了现在的设计评审的流程。
设计评审实例：
病历维护工作站
用例设计
概要类图
界面原型
1)病历树节点维护
2)数据源维护
3)病历模板
表结构设计
