I 敏捷方法的十个知识点Reifer咨询有限责任公司发表了一份名为敏捷方法定量分析的基准报告这份报告比较了敏捷方法软件生产率成本持续时间和质量与传统的计划驱动项目的差异这份报告分析了个项目（其中有个敏捷项目）的工作数据跨越年使用了由个组织提供的完整工作数据 读者可以在我们的敏捷研究中找到以下十个知识点我们所参考的基准报告中记录了相关研究成果这份报告目前售价美元可在此订购点击这里可以详细了解国际软件基准组织 敏捷生产率——敏捷生产率（以产出/单元投入成本进行度量）高于已交付产品的由计划驱动的项目的经验基准该经验基准取自年中在名义值上下浮动%的数据采用敏捷后一年内生产率平均最多能提升%到%但是这些提升取决于应用的领域并且受许多因素的影响（如劳动力构成结构产品复杂度项目规模等等）例如有一些项目需要通过认证的形式（比如飞行安全和安全认证等）这些项目看起来就不太适用于敏捷方法Capers Jones的数据证实了我们提出的观点此类项目使用像RUP（统一软件开发过程）和TSP（团队软件过程）之类的结构化过程可以更快地通过认证 驱动因子改善团队工作使用轻量级过程重点关注产品可执行的代码和潜在的霍索恩效应 问题开发维护或组织问题过程僵化和教条过于严格的管理外包问题缺少产品管理的核心 应对措施我们提出以下几个提升敏捷生产率的建议 理解影响生产率的变数（架构稳定性产品复杂度员工技能水平和经验等）当你转用敏捷时要处理好这些变数 收集生产率测量和度量结果这些数据有助于我们做必要的调整 改革时难免会遇到阻力建议先运行试点项目收集这些项目的度量和测量数据用这些数据说明敏捷是一种更好的商业运作方式 在试点项目中调整过程和敏捷方法找出达成商业目标的最佳方法 如果条件允许的话最好让大家在一起工作以避免在第一个项目中就出现管理和合同上面的问题 使敏捷重点关注能够带来差异化的那些应用的开发 星星之火可以燎原敏捷的一次成功可以带来更多的成功
敏捷成本——敏捷成本（以开销/单元产出进行度量）低于以计划驱动项目的经验基准该经验基准范围取自年间在名义值上下浮动%的数据采用敏捷后一年内平均最多能降低%到%的成本同样这种成本变化在很大程度上也取决于所在的应用领域并且受许多因素（包括劳动力构成结构和工资水平）的影响 驱动因子降低人工费用率降低管理费用简化沟通机制更加关注产品而不是过程 问题更重视开发而非规避维护成本机构重组和角色澄清僵化的过程治理过于严格外包问题以及不重视产品的管理 应对措施我们提出以下几个降低敏捷成本的建议 理解影响成本的变数（这些变数与生产率有所不同）转用敏捷时要处理好这些变数 基于事实做项目估算（通常所有sprints估算的交付物之和少于最终产品应有的交付物） 监控项目成本跟蹤预算开支 重视敏捷教育和培训的早期投入 在工作开展之前选购适当的工具并设置适当的运作机制（战情室任务板等） 转用敏捷时应该尽可能遵循节俭和简单的原则
敏捷上市时间——敏捷上市时间（度量软件从开始到最终交付的总体有效时间）比计划驱动项目的经验基准要短%到%在采用敏捷之后平均最多能缩短%到%（不同项目规模会有所差异）但需要注意的是一味地想要加速交付周期常常会遗漏一些需求使交付的功能和特性无法完全满足客户或用户需求从而降低了客户满意度 驱动因子关注正在开发的工件在sprints期内快速开发在最终投入市场之前增量交付演示版本 问题sprints期内未能完成所有工作承诺待办任务未能清空客户或用户可能没有成为团队成员管理者可能没参加到敏捷工作中来 应对措施我们提出以下几个缩短敏捷上市时间的建议 敏捷质量——敏捷质量（以发布后的缺陷密度进行度量）比计划驱动项目的经验基准要高%到%交付后的质量甚至能高出%到%同样质量取决于应用的领域并受许多因素的影响其中包括质量控制和质保实践 驱动因子过程监督执行不利过多地强调测试而没有做整体项目的质量保证没有产品质量目标在设计产品时未考虑质量缺少指导决策的质量文化 问题在敏捷初期没有强调质量就急着直接编码把测试视为质量保证不执行质量控制不收集质量指标不应用成熟的质量控制和质保实践 应对措施我们提出以下几个提升敏捷质量的建议 把发布速度优先的文化转变为质量优先的文化 拥抱质量让它成为所有工作过程中的一部分还需支持同行评审在每日站会上讨论质量从版本控制资源库中收集缺陷信息在任务板和版本状态报告中展示这些缺陷 让每个团队成员互相检查彼此间产品的质量可以举办一个竞赛为了使活动更有趣味性可以为做得好的成员颁发奖品和奖状 记录质量度量和测量结果不论是软件开发期还是软件维护期都可以用这些指标量化产品的质量 经常分析质量问题的根本原因不要只关注问题的表面症状还要关注导致缺陷的原因 永远不要发布很可能有缺陷的产品当质量和发布速度产生沖突时应该坚持原则说到做到勇于承担责任 使用精益和看板法原则能让我们随着产品开发过程关注工程质量在sprint期找出缺陷并修复它们或者把它们放到待办工作中随后解决
敏捷的竞争优势——敏捷最具竞争性的优势在于它能让组织发挥优势改进不足使用敏捷不仅可以提高生产力降低成本加速上市时间它还能帮我们吸引和留住人才这些人才是智力成本能让我们在竞争激烈的市场中脱颖而出但是有些应用领域不要使用敏捷方法敏捷在这些领域起不到应有的作用也没有什么意义比如需要认证资质的应用以及大型的分布式的复杂的开发等 驱动因子敏捷已经被过度夸大和使用任何新鲜事物都会被质疑许多公司并不把软件作为竞争格局的一部分（例如软件只是辅助性服务而不是创收的生产活动） 问题既要了解敏捷的优点也要了解敏捷的缺点采用敏捷需要做出一定的组织变更（比如一些新的角色和职责）对于组织来说转用敏捷像采用别的新做法一样充满风险 应对措施我们提出以下几个更能发挥敏捷优势的建议 变更组织结构把敏捷融入到组织的主要流程里 通过岗位职责说明书明确定义敏捷职位说明角色和团队的概念然后为岗位配备工作人员雇用敏捷教练对这些工作人员进行指导和培训 自上而下地转变文化由领导命令驱动的风格转变为自组织分享式团队至少要让你的软件组织转用敏捷 完善必要的治理使合规性保证不再依赖于上级或外部的监督让敏捷团队独立自主即使需求超出了范围也要相信他们可以应对但是当度量和其他指标显示工作进展滞涩时你就需要监控他们的工作并帮他们做些调整了 争取达成商业目标比如先完成优先级高的任务而不要把主要精力都放在那些即将要交付产品的项目上这种做法虽然可以满足一个客户（或用户）但却牺牲了其他的客户（或用户） 尽量让事情简单从产品架构到软件产品本身都要遵循这一原则此外还可以把这一原则延伸到组织结构上承担交付责任的组织也要尽可能地简单 将组织重心从实现单独的目标（按计划执行分派的任务等）转变成通过团队协作为组织及其客户提供价值把重点放在产出的工作产品上 营造一种鼓励尝试的文化无论尝试的结果是成功还是失败鼓励那些勇于做决策冒风险努力去解决问题的人 当结果可以预测但没有十足把握时由团队自己做出决策 尽量创建更好的商业模式为个人企业和客户提供更好的工作环境
具有一定规模的敏捷——一直以来在大型项目中都难以应用敏捷方法基于我们的数据分析（个不同组织的个项目其中有很多已经使用了多年的敏捷）敏捷不适用于大型复杂项目虽然有一些大型项目也使用敏捷取得过一些显着的成就但由于缺乏针对大型项目的体系和指南软件工程实践者需要面对很多不利条件从我们收集的数据来看当项目员工总数超过人而且他们处于不同的地理位置分属多个民族时应用敏捷方法的工作效果是达不到平均值的另外从我们和Capers Jones的数据来看当用户和客户总数超过时敏捷就会出现问题因为大家对系统愿景有着各自不同的理解或许造成这种局面的根本原因就是大多数大型项目并不直接面对用户这与敏捷是有所背离的反之这些项目在真正投入使用之前要先交付给一些集成和测试组经历各种严格的系统测试（性能可用性等） 驱动因子敏捷实践在大多数情况下只适用于小型团队和项目虽然也有人提出过一些针对一定规模项目的敏捷方法但由于它们并未重视和应用传统的项目管理技术我们并不太认可这些方法此外正如前文所说敏捷项目应快速交付给客户或用户但大型系统要先经过系统集成和测试后才能交付使用 问题无法协调监控跟蹤和调整分散在不同地域不同团队的开发人员无法跟蹤产品业绩和里程碑完成情况流程不当无法满足客户期望 应对措施针对大型项目的敏捷应用我们提出以下几个建议 借鑒敏捷的观念通过建立自组织分享式团队突破组织级障碍例如因为做计划管理时矩阵式管理方式会产生很多沖突所以应捨弃这种方式 在具有一定规模的敏捷项目中你可以继续沿用传统的项目管理计划日程安排和控制的概念用它们设定目标和跟蹤业绩你们在项目运行过程中可以使用传统方法在sprints运行过程中可以使用敏捷技术 不要让敏捷组织和团队成为特例而要让它们成为常态并使它们能够面对更多的客户和用户处理一定规模的问题这些正是传统大型项目（比如通信项目）所要解决的问题 为团队提供了推荐的大规模敏捷项目管理体系和指南 在软件开发过程中做每件事都需要兼顾敏捷性和纪律性 针对敏捷确立系统工程并请客户当测试代表除此之外内部讨论时也不要忘了系统实际的用户客户或甲方因为最终完工交付的时候是由他们评判特性功能和性能是否达到要求 为了确定迭代项目和组织等各个级别开发基线的程度你需要定义并执行度量和测量 找出指南中不适用的过程和问题并完善它们特别要注意那些用于配置管理发布管理质量控制（或保证）和供应商管理的敏捷实践
敏捷系统工程——你需要更新系统工程实践以提升敏捷化程度否则因为不适用的过程会使组织产生很多沖突举个例子因为系统工程师开发系统需求并把它们从硬件到软件进行逐层定位所以应随着软件开发过程同步开发系统需求未来的发展趋势是系统扮演客户但如果不暴露出各种操作角色就无法达成这样的目标再举一个例子由于架构是软件运行的平台所以在过程初期应该拥有稳定的系统架构 系统工程经常无法做到这一点即便他们采纳了软件工程师针对面向特性和即插即用功能的建议最后再举一个例子通常情况下测试工程师也隶属于软件工程师为了确保增量开发出的系统能够满足需求需要他们支持持续集成和测试的理念不幸的是系统工程师不接受这种按待办任务交付的方式因为他通常都认为每次增量之间要交付的内容是不能延迟的为了集成和测试系统中的软件部分测试工程师还需要与软件团队一起定置相应的机制和工具有时系统在交付使用之前需要让实际用户（或系统操作人员）用真实的设备先予以验证 驱动因子过于严谨和理论化的系统工程孤立的系统软件文化和过程缺乏真正的跨领域的和整体团队的概念 问题太晚提供软件需求未定义系统接口直到编程末期才开始关注系统测试而在初期根本就没有关注系统测试和集成的机制建立得太晚系统和软件过程不匹配缺乏跨领域团队协作缺乏其他领域体制的尊重发生系统工程故障时互相推诿 应对措施我们提出以下能够改善敏捷系统工程的几个建议 邀请客户或用户代表参与到团队中来作为团队成员与大家在一起工作 真正拥抱整体产品团队或跨领域团队的概念平等对待团队中的每一个成员让客户或用户代表参与到团队中成为团队成员 引领工程改进而不要反被其制约 不仅仅让系统硬件和软件支持敏捷宣言还要让工程支持敏捷宣言 嫁接所有的工程和制造过程使工作切换同步简单 制定一个单一的基于敏捷的工程过程胜过让每个独立的领域（系统软件硬件特定工程等）都有各自的过程 在过程早期专注于开发客户需要的工件胜过专注于那些独特的工程理论 抱着探险家的心态去挖掘需求胜过仅仅遵循规范的过程 在整个开发过程中把重点放在开发工作产品上胜过那些面面俱到的有些官僚主义的文档 拥抱持续集成实践使它成为所有工程的统一框架 集成还有一个好处它简化了完备的系统为团队提供了一套简单的模型使团队清晰哪些已经构建哪些已经准备测试了哪些正在测试哪些已经可以投入使用了 可以定义同步点在适当的时间集成半成品以处理过程中必要的同步
敏捷软件维护——敏捷是否适用于软件维护？评审委员会还没有给出最后的定论本阶段的开发使用敏捷方法有哪些利弊？我们可以从Reifer咨询公司近期针对软件维护的研究成果中找到一些答案本次研究发现由开发期的预算和进度计划是由需求驱动的会有较大差异而用于软件维护任务的资源较为固定所以软件维护团队的一项很重要的任务就是充分考虑工作（修复变更更新优化等）的优先级使他们能在固定的预算下尽可能完成更多的工作其实完成那些积累下来的变更申请和待处理的故障报告只是他们最基本的工作任务 本次研究还发现同一个团队要并行完成以下四种版本的开发任务 当前版本——维护团队的主要任务是开发新的版本通过升级代码为客户完成需求变更问题修复和性能优化 现场版本——维护团队的首要任务支持现场版本为保障系统运维执行必要的修复和补丁 完整版本——维护团队的次要任务配置和定制近期的完整版并发布到各个现场他们的工作内容包括做更多的测试和协调各个现场 需求版本——维护团队的次要任务目标是开发下个版本的内容（举例来说必要时要开发原型去界定需求范围）
为了在软件维护期能够更好地执行敏捷方法必须让敏捷方法能够处理以上四种版本的相关工作我们的研究表明与软件开发期相比这些工作环节的组成和分布均有所不同例如这类工作在很多时候要用回归测试的方式验证最新的版本变更另外这类工作可能需要现场支持和运行测试的参与 驱动因子不清楚维护期的工作性质当计划内的任务和紧急任务产生沖突时不清楚怎么为维护活动或设施做预算才能更合理地完成功能增强问题修复性能优化等任务 问题分不清做的是软件开发项目还是维护项目不适用于维护的过程或预算预算不足导致工作积压每次变更都要重新验证版本产品分布式管理的问题和缺乏产品管理规范 应对措施我们针对软件维护期的敏捷提出以下几个建议 考虑如何让敏捷方法适用于上述四种版本的所有相关工作讨论在软件维护阶段需要做哪些工作 提供一份指南解释在上述四种版本的开发过程中如何应用敏捷技术和实践例如如何让sprint不仅能为完整版本引来价值还要在当下产生价值 软件维护工作主要是保障系统的运行甚至可能要在现场做功能增强问题修复和性能优化你需要确定这些工作的优先级 设计适当的支撑架构（例如针对所有项目的配置分布质量供应商和风险管理实践）在软件维护期内使不同的设备上的不同软件都能保持最新的发布即使它们是不同的版本和遗留系统 清楚维护设备和客户支持职能需要单独做预算你们在预算时要基于待办任务中涉及的所有工作量而不仅仅是单独的工程在协调计划和员工时要充分考虑这些工作 持续拥抱持续集成和自动化回归测试的实践因为在维护期投入到验证版本变更的测试工作量要占到总工作量的%这些活动能产生巨大的影响 坚持过程规范特别是处理多样的发布客户和产品版本时一旦放松就可能酿成大祸
敏捷风险管理——你们必须要拥抱敏捷风险管理实践特别是面向更具规模更加复杂的敏捷项目时虽然有一些现有的技术可以用来做敏捷风险管理（比如风险燃尽表）但在我们的数据中却很少有组织使用过这些技术按我们通常的理解这些技术可能更适用于国防和通讯领域 驱动因子把风险管理看成重量级过程团队领导并不把它当成项目管理（比方说没有风险管理任务）缺少项目管理规范和实践（特别是具有一定规模的敏捷项目） 问题移除在预算内按时交付高质量产品的不利因素尽可能地满足客户的预期提升识别风险和缓解风险的能力 应对措施我们提出以下几个加强敏捷风险管理的建议 把敏捷风险管理实践实际开展起来让团队管理者客户用户共同参与风险的识别量化排序和缓解 制定前十风险列表把它们放在任务板上在站立会和分派任务时掌控它们的状态 按潜在的技术和编程影响排出前十风险列表使用类似风险燃尽表之类的技术去跟蹤这些风险的缓解过程 让客户或用户参与到风险管理过程中让他（她）们根据你评估的影响为风险排出优先级创建类似于风险委员会的组织让大家就风险优先级达成共识 当风险合理存在并且不会造成严重后果时可以冒这个险 鼓励冒险当你觉得有必要冒险并能够最小化和控制冒险带来的潜在后果时你就可以鼓励冒险
敏捷外包——我们需要精确的敏捷外包实践目前合同管理员和甲方并不清楚如何规定敏捷承包或分包的具体合同类型工作范围工作状态交付物里程碑支付条款和条件我们可以通过这些条款准确地推导出敏捷合同中要使用的时间和资源而不是为了鼓励组织高效地工作笼统地制定激励措施 驱动因子敏捷是一个相对较新的商业模式几乎没有公司做过涉及到采购方的敏捷在实际工作中也没有多少可供参考的合同样本 问题缺乏针对工作效率的激励和鼓励机制没有合约性的控制与保障措施甲方觉得敏捷无法控制所以不想采用 应对措施我们针对敏捷外包提出以下几个建议 制定一套合同模版软件甲方可以用它拟定会用到敏捷方法的软件开发承包或分包识别里程碑和交付物并在合同中规定如何鼓励效率提升（比如激励措施等）如何处理违规（比如撤销条款等） 制定一份敏捷承包或分包样本为敏捷采购提供一套有理有据的条款和条件（包括支付条件和里程碑） 为了描述交付物的形式和格式制定一套交付物模版尽量提供电子文档而不要到供应商的办公室去拿纸制的文件 制定一份法律模版使客户（或用户）代表根据有限责任保护伞条款作为成员参与到开发团队中 为甲方和合同管理员制定敏捷承包或分包的培训和认证课程使大家在工作时能够拥抱这些概念
II 主要研究成果因为对于大多数调查过的组织来说敏捷方法是一种全新的商业模式所以在前文讨论了大家比较感兴趣的知识点很明显还有许多问题（比如敏捷外包一定规模的敏捷等）一直困扰着组织仍然需要一段时间的过渡可能才能解决鑒于现在已经掌握的素材我们整理了以下五个主要研究成果希望在读者采用敏捷方法时能够有所帮助 敏捷方法最适合用于明确的业务用例在此前提下实施最大的障碍无非就是向新人解释方法论的用法 当你转用敏捷方法时最主要的是要改变管理原则在过渡时期你需要制定策略落实计划调整架构培训员工训练管理人员还需要运行敏捷试点项目找到如何在你的组织环境组织商业目标组织流程和组织历史背景下运行敏捷项目的最佳办法 某些类型的软件开发项目可能不适用敏捷方法前文白皮书中曾经提到那些安全和安保项目可能并不太适用敏捷方法而适用于其他同样轻量级的方法（比如RUPTSP等等）因为这些项目会涉及到一些认证资质另外如果不解决外包问题就难以在一个采购环境中使用敏捷方法因为不容易界定任务是否实际完成了另外优秀的敏捷专家能帮你做出决策找出适用的方法时机和理由以及对客户（或用户）带来的价值 由于组织和流程不匹配缺少项目管理规范一定规模的敏捷项目一直难以运作很难处理组与组之间的控制权沖突为了避免这些问题我们推荐单一的工程原则该原则聚拢受到影响的小组探索真正的跨学科团队的概念时刻记得通过敏捷思想改进流程充分利用那些传统项目管理规范（比如项目管理协会在知识体系中[PMBOK]所提倡的那些规范）在这种情况下优秀的管理分析师所拥有的敏捷过程改进以及项目管理的技能知识和能力会带来一定的帮助如果他具备你所经营行业和应用领域的相关经验就能带来更加显着的帮助了 在当前的竞争格局下转用敏捷方法通常很有意义主要有三点原因首先你可以使用这一套方法论去赶超你的竞争对手他们极有可能已经准备使用敏捷方法了第二你可以使用敏捷方法吸引人才因为高效的人才希望自己的工作环境能够使用到最新最好的技术第三个也是最后一个原因你可以向客户展示你使用的敏捷技术向他们说明这就是他们所希望采用的最好的技术
你可能想要了解更多关于敏捷的信息比如敏捷的优势和弱点敏捷投资回报率这十年的动态和我们关于敏捷软件生产率成本和质量调查研究相关的细节我们建议你从或从这里订购敏捷方法定量分析报告这份报告在下列十个应用领域中按行业报告了这些敏捷软件生产率成本和质量的结果 自动化 指挥控制 金融 国防 信息技术 医疗 移动应用 软件工具 通信 电子商务
|
