敏捷项目管理实战之质量管理

  • 时间:
  • 浏览:1
  • 来源:彩神幸运飞艇_神彩幸运飞艇官方

  《敏捷宣言》中提到“客户相互相互合作胜过合同谈判”,需求澄清活动的基本前提可是客户代表的参与。可是它是符合敏捷开发的价值观的。

  诚然,软件测试的目的是发现不足。也正可是大多数公司和人个 也就把测试人员定位成不足的发现者。然而,测试毕竟是四种 事后控制型的质量管理手段,这就有上上策。不需要 往测试人员某些角色的职责的定义中增加另一个 不足预防的职能呢?笔者可是在所带团队中引导测试人员往不足预防方面发展,在这方面多做贡献,而就有仅仅把人个 定位为不足的发现者。在开发测试一体化团队中,测试人员同开发人员一起参与需求分析、评审。项目经理不需要 通过某些奖励法律法律依据鼓励测试人员多去发现需求四种 的错误以及开发人员对需求理解的偏差,从而除理了需求相关的不足。人个 面,测试人员往往习惯于从发现不足中获得成就感。在引导测试人员在不足预防上多做贡献的过程中,项目经理不需要 引导测试人员使其认识到预防不足比发现不足更加不需要 体现另一个 人的能力和价值。

表 4. 单元测试评审活动

  基于经验过程控制的质量管理真是施的基本思路是先通过经验机会对质量现象进行根因分析(Root Cause Analysis)发现影响质量的因素,再采取法律法律依据使那些因素成为可观察的因素(对应经验过程的“透明性”)。可是,在项目实施过程中对那些因素进行检查(对应经验过程控制的“检查”)。检查过程中发现不可接受的结果机会偏差时及时采取法律法律依据进行矫正以除理不足的引入机会不足流入下一道工序中(对应经验过程控制的“适应”),从而保证了最终产出的质量。

  团队成员对需求理解的偏差也是软件不足的另一个 重要来源。当我们当我们当我们当我们当我们当我们 不需要 应用经验过程控制的思想对某些因需求理解偏差而引入的不足进行预防。其基本思路是先使团队成员对需求的理解成为可观察的因素,可是对某些因素进行检查。检查过程中发现不可接受的偏差时及时采取法律法律依据进行纠正,从而除理了不足的引入。笔者通过在团队内开展需求宣讲活动来具体实施某些不足预防。

  从经验过程控制的三大支柱当我们当我们当我们当我们当我们当我们 不需要 看完其现象驱动的性质。现象驱动是处于过程实施时所进行的活动是基于有那些因素影响了最终产出的结果,而就有像某些传统的过程控制实施者是从某些预定义的活动集合中“剪裁”某些活动。从另一个 活动集合中剪裁出某些活动,这四种 就要求剪裁者对某些活动集合中的每个活动足够了解,从而不需要 挑选适合人个 的活动。某些剪裁的过程使得那些传统的过程控制实施起来相对困难,而经验过程控制机会省却了“剪裁”的过程而使得真是施相对容易。

  设计阶段所引入的不足不仅包括设计四种 的不足还包括了因编码人员对设计方案理解的错误和偏差而引入的不足。极限编程所强调的是简单设计真是一定程度上降低了设计四种 不足的概率,可是就能助 降低设计方案理解偏差而引入不足的机会性。可是,从经验过程控制和不足预防的深度1来看,当我们当我们当我们当我们当我们当我们 仍然不需要 将编码人员对设计方案的理解某些影响质量的因素成为可观察的因素,并对其进行检查。

  《孙子兵法·谋攻》中提到“百战百胜非善之善者,不战而屈人兵,善之善者”。每次打仗都取胜就有战争的最高境界,战争的最高境界是不费兵卒而取得胜利。同样,在软件开发过程中,找出所有不足并将其一一去除就有质量管理的最高境界。质量管理的最高境界是将不足扼杀在摇篮之中——不足预防。经验过程控制三大支柱所体现的其现象驱动的底部形态说明了它不需要 帮助当我们当我们当我们当我们当我们当我们 去实施不足预防。基于经验过程控制的不足预防是通过使不足来源成为可观察的因素,可是在软件开发过程中对那些因素进行检查,发现不可接受的偏差时及时采取法律法律依据进行矫正,从而除理了不足的引入。比如,当我们当我们当我们当我们当我们当我们 歌词 发现开发人员对需求理解的错误、不全面是不足的另一个 重要来源时,当我们当我们当我们当我们当我们当我们 就不需要 应用经验过程控制的思想,先采取法律法律依据使开发人员对需求的理解成为可观察的因素。可是对其进行检查,若发现有需求理解上的偏差,则进行矫正,从而除理了因需求理解偏差而引入不足。

简介:本文以笔者的项目管理实践为基础,介绍基于经验过程控制(Empirical Process Control)模型、不足预防以及敏捷价值观的敏捷质量管理思想及真是践。希望通过本文为广大项目管理人员提供质量管理的某些思路和经验分享。

  不足预防

  需求宣讲是在开发人员开使编码、测试人员开使设计测试用例前,由全体团队成员参与的另一个 头脑风暴会议。在某些会议上,开发人员随机挑选另一个 Story,可是口头表述其对所挑选的 Story 的理解。通过某些讲解,开发人员对需求理解就成为了另一个 不需要 观察的因素。当某些与会人从需求讲解人的讲解中发现其对需求理解上的偏差时,不需要 及时指出进行纠正。某些与会人员也可对其讲解提出现象和质疑。当讲解人的回复无法得到团队成员的一致认一起,则进行讨论,最终达到对需求理解的一致。而对于讨论无法达成一致认识的现象,不需要 记录入需求现象确认列表会后再进行确认。

  笔者可是在另一个 基于 SOA(Service Oriented Architecture)的项目中将单元测试过程中系统所产生的接口日志文件定义为单元测试产出物。在某些项目中,开发人员会将单元测试过程中每个测试用例执行时系统所产生的接口日志文件按所覆盖的测试用例的名称进行命名提交到配置库上,可是知会某些项目组成员进行评审。机会某些单元测试产出物不需要 反映系统所要实现的功能,评审人员不需要 通过分析产出物判断每个测试用例与非 真正执通过以及测试用例与非 覆盖充分。评审者把评审过程中发现的测试用例未通过机会未覆盖等现象会分类整理成评审意见提交到配置库上,并知会开发人员进行除理。

  需求澄清

  真是需求评审和需求澄清这另一个 活动不需要 一定程度上反映活动参与者对需求的理解,可是它们更多的是用于发现需求四种 的现象。而需求宣讲则是专门用于检验活动参与者对需求的理解正确性和全面性。

  笔者在所带的项目中开展设计会话活动。在设计会话中,通常由设计人员借助白板讲解设计方案,人个 员对讲解的内容有现象和异议时不需要 提出集体讨论。主讲的设计人员不需要 能针对其讲解提出某些现象让某些参与人回答,以挑选参与人与非 真正理解设计方案。设计会话开使后,白板上的内容不需要 先保留一段时间,以方便事后再查看。有条件的团队也可将其拍照存档。设计会话中所讨论的设计方案不需要 事后由编码人员写入 Story 文档。机会相关人员前一天都参与过设计会话,在 Story 文档评审时对其中的设计每种有哪几个他说人个 的认识和意见,这能助 发现对设计方案理解的偏差。

  设计会话体现了《敏捷宣言》中提到的“人个 与交互胜过过程与工具”某些价值观,除理了仅仅通过设计规格说明沟通设计方案是因为 的沟通速率单位单位低下、设计方案理解偏差的现象,充分类分类整理挥了人与人直接沟通的优势。

表 1. 需求澄清活动

  单元测试评审

  定义单元测试的产出物不需要 使单元测试活动成为可观察的因素。对单元测试产出物进行评审不需要 发现单元测试所覆盖的测试用例与非 真正执行通过以及测试用例覆盖与非 充分。若单元测试评审过程中发现有测试用例未通过的机会遗漏的,则及时反馈给开发人员进行纠正,从而除理了不足进入下一道工序——Story 测试。

设计会话(Design Session)与简单设计(Simple Design)

  单元测试是软件开发中被普遍接受的优秀实践,也是影响软件质量的另一个 重要方面。有效的、充分的单元测试不需要 提高代码质量,从而有效除理了返工。可是怎么都可以保证单元测试得到有效的执行呢?按照经验过程控制的思想,当我们当我们当我们当我们当我们当我们 不需要 先使单元测试成为另一个 可观察的因素,可是对其进行检查。检查过程中发现偏差时及时进行纠正从而保证单元测试得到有效的执行。

表 2. 需求宣讲活动

  需求宣讲

  上述例子正好体现了经验过程控制的三大支柱——透明性(Transparency)、检查(Inspection)、适应(Adaption)。透明性指影响最终产出结果的因素对于过程控制者来说可观察机会使其可观察。“透明性”在上述例子中表现为:菜肴煮熟程度是影响菜肴质量的另一个 因素,而某些因素不需要 通过菜肴的颜色或其硬度反映出来。检查指对影响最终产出的因素进行观察和评价的动作。上述例子中提到的观察菜肴的颜色、尝尝菜肴的咸淡可是“检查”。适应指检查过程中发现不可接受的结果、偏差时所采取的矫正动作。上述例子提及的在发现菜肴味道偏淡的具体情况下采取的继续加盐的动作可是“适应”。

  经验过程控制是四种 现象驱动的轻型过程控制模型。在进一步介绍经验过程控制前一天,当我们当我们当我们当我们当我们当我们 先看另一个 日常生活中应用经验过程控制的另一个 例子:在菜肴的烹饪过程中,当我们当我们当我们当我们当我们当我们 往往先观察菜肴的颜色,机会用一次性筷子子检查其软硬度来判断菜肴与非 机会煮熟。若不足熟,则继续煮。待到菜肴快熟时,当我们当我们当我们当我们当我们当我们 开使放盐、味精这类的调料。可是尝尝菜肴的咸淡与非 适中,若太淡了则继续加盐,直到当我们当我们当我们当我们当我们当我们 满意为止。经过可是另一个 过程,烹饪者满意的一道菜肴不需要 完成。

表 3. 设计会话

  经验过程控制

  当然,当开发人员被要求讲述其对需求的理解时,机会会说他真是机会理解了需求可是我可是知道怎么都可以表述。且不论这句话与非 属实,项目经理应当引导团队成员意识到:在敏捷开发团队中,人个 对需求是怎么都可以理解的,理解的对与错,深与浅就有其另一个 人的事情,可是整个团队的事情,机会它影响了某些团队最终交付的软件的质量!从另外另一个 深度1来讲,当另一个 人能清晰得表述一件事物时,才说明其对这件事物是真正理解的。

  需求规格说明书四种 的错误、不明确是软件不足的另一个 重要来源。可是,消除需求四种 的现象是不足预防的另一个 重要内容。笔者在所带的项目中是通过开展需求澄清活动来消除需求四种 的现象的。在开发团队内部进行需求规格说明书评审前一天,评审意见被汇总成另一个 列表,某些列表不需要 是另一个 Excel 表格,当我们当我们当我们当我们当我们当我们 称之为需求现象确认列表。可是,当我们当我们当我们当我们当我们当我们 邀请客户过来和开发团队一起对现象列表中的每个现象进行讨论。团队成员负责提出和解释现象确认列表中的现象,客户代表则负责解答和澄清团队成员提出的现象。客户对于现象的回复当我们当我们当我们当我们当我们当我们 会记录到现象确认列表的“回复”一栏。需求澄清活动往往是以头脑风暴会议的形式展开的,而不仅仅是另一个 一问一答的过程。对于客户当场给的现象回复,团队成员机会机会通过人个 的分析认为客户的回复是错误机会不合理的而当场对客户代表的回复提出质疑。客户代表往往也可是对其回复进行重新思考从而给出与会人员一致认同的回复。