敏捷项目管理实战之质量管理
作者:网络转载 发布时间:[ 2012/7/24 11:56:15 ] 推荐标签:
当然,当开发人员被要求讲述其对需求的理解时,可能会说他其实已经理解了需求只是不知道如何表述。且不论这句话是否属实,项目经理应当引导团队成员意识到:在敏捷开发团队中,个人对需求是如何理解的,理解的对与错,深与浅不是其一个人的事情,而是整个团队的事情,因为它影响了这个团队终交付的软件的质量!从另外一个角度来讲,当一个人能清晰得表述一件事物时,才说明其对这件事物是真正理解的。
虽然需求评审和需求澄清这两个活动也能一定程度上反映活动参与者对需求的理解,但是它们更多的是用于发现需求本身的问题。而需求宣讲则是专门用于检验活动参与者对需求的理解正确性和全面性。
表 2. 需求宣讲活动
设计会话(Design Session)与简单设计(Simple Design)
设计阶段所引入的缺陷不仅包括设计本身的缺陷还包括了因编码人员对设计方案理解的错误和偏差而引入的缺陷。极限编程所强调的是简单设计虽然一定程度上降低了设计本身缺陷的概率,并且也有助于降低设计方案理解偏差而引入缺陷的可能性。但是,从经验过程控制和缺陷预防的角度来看,我们仍然需要将编码人员对设计方案的理解这一影响质量的因素成为可观察的因素,并对其进行检查。
笔者在所带的项目中开展设计会话活动。在设计会话中,通常由设计人员借助白板讲解设计方案,其他人员对讲解的内容有疑问和异议时可以提出集体讨论。主讲的设计人员也可以针对其讲解提出一些问题让其他参与人回答,以确定参与人是否真正理解设计方案。设计会话结束后,白板上的内容可以先保留一段时间,以方便事后再查看。有条件的团队也可将其拍照存档。设计会话中所讨论的设计方案可以事后由编码人员写入 Story 文档。由于相关人员事先都参与过设计会话,在 Story 文档评审时对其中的设计部分多少也许自己的认识和意见,这有助于发现对设计方案理解的偏差。
设计会话体现了《敏捷宣言》中提到的“个人与交互胜过过程与工具”这一价值观,避免了仅仅通过设计规格说明沟通设计方案导致的沟通效率低下、设计方案理解偏差的问题,充分发挥了人与人直接沟通的优势。
表 3. 设计会话
单元测试评审
单元测试是软件开发中被普遍接受的实践,也是影响软件质量的一个重要方面。有效的、充分的单元测试能够提高代码质量,从而有效避免了返工。但是如何保证单元测试得到有效的执行呢?按照经验过程控制的思想,我们可以先使单元测试成为一个可观察的因素,然后对其进行检查。检查过程中发现偏差时及时进行纠正从而保证单元测试得到有效的执行。
定义单元测试的产出物可以使单元测试活动成为可观察的因素。对单元测试产出物进行评审可以发现单元测试所覆盖的测试用例是否真正执行通过以及测试用例覆盖是否充分。若单元测试评审过程中发现有测试用例未通过的或者遗漏的,则及时反馈给开发人员进行纠正,从而避免了缺陷进入下一道工序——Story 测试。
笔者曾经在一个基于 SOA(Service Oriented Architecture)的项目中将单元测试过程中系统所产生的接口日志文件定义为单元测试产出物。在这个项目中,开发人员会将单元测试过程中每个测试用例执行时系统所产生的接口日志文件按所覆盖的测试用例的名称进行命名提交到配置库上,然后知会其他项目组成员进行评审。由于这个单元测试产出物能够反映系统所要实现的功能,评审人员可以通过分析产出物判断每个测试用例是否真正执通过以及测试用例是否覆盖充分。评审者把评审过程中发现的测试用例未通过或者未覆盖等问题会整理成评审意见提交到配置库上,并知会开发人员进行处理。
表 4. 单元测试评审活动
面对面代码复审
在比较常见的轻型代码复审过程中,开发人员提交代码到配置库上,然后代码复审人员从配置库上获取相应代码并借助一些代码复审工具将复审结果形成意见提交给代码作者进行处理,并跟踪复审意见的处理结果。代码复审人员往往只在复审过程中有疑问的情况下才找代码作者进行确认。这种轻型的代码复审复审表面上执行起来比较容易,成本也比较低。但是它和《敏捷宣言》中提到的“个人与交互胜过过程与工具”这一价值观是相违背的。因为它缺乏有效的人与人间的交互。这种缺乏人员间交互的方式也导致了评审结果终呈现给代码作者的往往是问题。这一方面使得代码作者只是被动得发现问题和解决问题。被动得发现和解决问题往往导致当事人对问题及其解决方法印象不深刻从而极易导致相同或者类似问题重复得出现。虽然我们可以将复审过程中典型的问题形成检查表由开发人员在代码提交前对检查表中的项目进行自检,但是这个检查表往往也是在重复的问题被重复得发现后才形成的。另一方面,这种代码复审往往给代码作者一种“挑刺”的感觉,而作者自认为代码中比较优雅的部分往往也被人忽略了,因为那不是问题因此复审人员也不会将其指出。这容易导致开发人员对代码复审的本能性排斥心理,因为人总是倾向于被他人肯定,而不是总是被人指出问题。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11