5.为何要作设计评审和测试用例评审

    敏捷开发系列文章目录

 

设计评审和测试用例评审咱们都是迭代的次日作，通常会给开发人员半天的时间思考一下他本身故事的设计，而后抽出1-2个小时进行设计评审，设计评审完后就作测试用例评审。
设计评审就是让团队帮你查遗补漏完善你的设计，而测试用例是测试、PO、开发三者又一次落到实处的交流。

 

设计评审和测试用例评审都是为了解决产品质量问题而提出来的解决办法。

    咱们团队敏捷开发前期也是没有搞设计评审和测试用例评审的，是有几个迭代产品的质量总是提不高，在迭代回顾会议中你们讨论出，就算设计评审和测试用例评审会占用咱们的开发时间也必需要搞，否则产品的质量永远提不上来。

    我以为定这个制度的由来能够好好说一下，那是在云HIS项目第二个阶段临床部分开发的Sprint2的回顾会议上提出来的，由于这个迭代失败了。团队在作sprint 评审会议展现产品成果的时候错误百出，药品入出库的流程都跑不通，当场PO就拒绝验收本次迭代的故事，宣布迭代失败。接下来的迭代回顾会议时，你们表现得比较沉重，SM就安慰你们，失败的迭代也是迭代，对团队也是好事，正好能够总结经验嘛。X君脾气比较火爆，一下就开火了，“我就搞不明白，为何要这么赶，一个迭代塞这么多故事，这仍是不是在搞敏捷？”这是现实状况，由于这个项目周期比较紧张，因此一些功能就按系统倒排，就致使每一个迭代的故事多了一些。T君是SM，“这个迭代故事可能是一方面缘由，但不是下降质量的根本缘由，搞敏捷有时候搞些强的冲刺也是正常的，而且迭代计划会议你们已经对这些故事作出了承诺，因此咱们应该找出此次失败的缘由，而不能抱怨找理由推卸责任”。Y君平时话很少，但写代码作事很是踏实，“产品的质量很差，我以为是设计这个环节作得太仓促了，没搞敏捷以前咱们开发经管部分是花了一个月时间作设计的，设计表结构、画用例图、时序图、类图，编写设计文档，但一个迭代才两个时间根本没有留时间作好设计。就像Y君和H君，大家两个同时使用的那个字段状态的定义，在迭代快结束了还在变来变去，一方刚修正bug，另外一方又产生新的bug，若是提早你们一块儿把这些设计细节讨论请求就应该不会出现这种问题。”H君认为Y君说得颇有道理，问题是设计该怎么作，像之前那样花一个月时间写设计文档确定不行，那不是有回到之前传统的那种开发模式上去了？接下来你们深刻讨论怎么作符合敏捷的设计，首先像之前那么详细的设计文档确定没时间写出来，为了节约时间设计文档不写了，原本敏捷就提倡轻文档重沟通，重点是必定要提早作出设计，而不是在编码过程当中思考设计，因此决定每一个人提早作好设计，而后进行设计串讲，每一个人把本身的设计讲出来让你们提建议，没有设计文档建议画一些流程图或者在白板上讲解本身的思路，讲完以后再拍照下来，分享在群里。后面的迭代按照这个想法尝试，效果还不错。再后来因为每一个人讲解设计的方式差异太大了，没有统一的表述方法，为了提高沟通的效率，又制定了一个简单的设计文档模板，因此慢慢的就造成了如今的设计评审的流程。

 

设计评审实例：

 病历维护工做站

用例设计

概要类图

 

界面原型

1)病历树节点维护

2)数据源维护

3)病历模板

表结构设计

 

    敏捷开发系列文章目录