成本估算

存在一个普遍的误解,敏捷软件开发意味着没有长期计划。敏捷开发做包括长期计划和成本估算是一个关键的活动在敏捷项目。它需要早期,前期分析,演示了一个高层的理解程序及其相关的成本和收益。程序必须提供高层次的问题的答案他们计划交付什么,如何当;成本是多少;并将获得什么好处。他们使用这些信息来证明他们的投资,以及规划和融资决策。

程序使用成本估算和收益评估在各种产品和许多不同的目的在整个收购阶段,包括权衡分析,如AoA、商业案例分析(BCA)和经济分析(EA)和生命周期成本估算(lcc)。成本估算和收益评估一般成熟随着时间的推移变得知道程序的更多信息。估计和评估应该考虑敏捷开发过程的细微差别初始程序层次的估计将为高层增量保真度较低,但后面都有详细的估计之前每个版本的发展。全面主管评估流程和方法给高级利益相关者信心放松严格的监管,并为这个项目提供有价值的成本信息,不断提高性能和管理。

敏捷开发的成本和收益可以相差很大,作为项目的复杂性,不同大小和范围。几个领域上升到表面键辨义成分影响所有成本元素和收益领域的整个生命周期。这些领域包括:

• 质量和经验的团队由政府和开发商使用
• 敏捷开发的项目需求和约束
• 敏捷开发方法由政府和开发商使用
• 程度的敏捷实施的外部环境(利益相关者和流程)

敏捷开发成本影响数据和收益实现数据仍然是成熟,特别是对政府的环境。对于任何软件方法,使用最佳实践和学科的程度应考虑影响成本和收益和成本估算或效益评估。

使用的主要技术为收购项目开发成本估算包括类比,参数,工程建设,从实际成本外推。一般来说,用于一个收购项目的成本估算技术的成熟的类比实际成本法程序变得更加定义和实际数据变得可用。方法的选择取决于在该项目在其生命周期。早期项目,定义是有限和类比方法是适当的。一旦一个程序在开发,成本估计可以使用实际成本和技术开发阶段的数据来估计程序的其余部分。因此,成本估计在早期阶段有更多的不确定性,变得更加确定随着项目的成熟和风险实现。

敏捷开发成本估算技术不一定使用不同技术在传统的发展项目。初步估计将作为附加程序高层将会有更详细的定义和数据变得可用。然而,敏捷开发项目故意没有尽可能多的可用的定义随着开发阶段临近的传统项目。近期发布的详细定义和工程建设技术可以使用。后来的计划版本不会有相同级别的定义和估计成本依赖于构件(如产品愿景和产品路线图和评估技术,如类比(近期发布)。版本的定义会随着时间成熟和成本估计可以应用工程建设方法以及实际收集的数据发布完成。一旦成本项目的固定,成本分析活动集中在评估如何完成很多工作中的资金。

估算成本在敏捷环境需要更多的迭代,集成和协作方法比传统的收购计划。传统程序通常治疗成本分析作为一个单独的活动,而不是作为一个完整的团队努力,但成本估算一个敏捷项目是一项团队活动。理想情况下,成本估计量是紧密耦合的系统工程师和开发团队每个敏捷版本范围,开发和测试。正在进行的用户之间的协作、开发团队、系统工程师、成本估计、和其他利益相关者是至关重要的,确保需求优先级协议产品待办事项列表,并深入了解每个版本所需的工作量。它还允许一个集成的操作和风险评估,技术性能,成本动因,支付能力,和时间表。

与其它软件开发方法,产品尺寸通常是最大的成本动因在开发一个软件开发成本估算。敏捷开发通常使用成本估算策略基于大小的相对措施,如故事点。没有固定的公式定义的大小存在一个故事,所以释放团队可以使用各种技术集中在小团队协作达成共识为每个故事点的数量。团队基本故事点估计的工作量参与开发的特性,它的相对复杂性,固有的风险。例如,一个小的,简单的故事可以被分配一个点,而一个适度复杂的故事可以得到8分——即相关产品开发需要八倍长。这个策略提供了一种方法来比较一个故事到另一个的大小,从而最终使项目相对测量整个池的大小的要求。一些常见的评分系统,团队可能使用分配故事点复杂性措施包括斐波纳契数列,理想的天,或small-medium-large。

开发用户故事之后,敏捷团队重视他们成为产品待办事项列表,然后构造一个释放产品待办事项列表。组成一个发行版的用户故事的数量是基于sprint计划来衡量团队的估计速度(衡量生产力的敏捷开发方法)。程序可以使用历史最初测量团队速度值或通过预测基于团队的技能和团队的经验与特定的产品或技术。第一次冲刺后,为下一次迭代团队选择用户故事和每个故事上的团队合作使更精确估计的恰当的故事点冲刺。团队可以评估是否可以构建提出的故事在冲刺时间,考虑到团队的实际速度。

团队定期开展这个活动,评估点的待办事项列表中的待办项基于洞察力来自最近的进展。这种迭代的方法随着时间的推移增加了估计的忠诚。版本的估计是在一个较高的水平,而sprint-level估计更精确和详细的帮助团队使用有效地管理项目的成本估计。

随着项目的发展在发展过程中,它应该检查初步估计匹配实际的努力,如果故事添加或删除从一个版本,如果评估方法或值改变的故事。跟踪完成迭代的计划与实际进度与有待完成的故事点,使用的燃尽图,可以帮助跟踪敏捷开发的进度。

成本的影响包括成本增加和成本减少在敏捷开发经验。成本包括初始投资增加(在某些情况下持续投资)实现发展所需。成本下降反映了降低成本预期一旦开发的版本已经完成,部署和计划已达到维护状态。这些减少反映区域与真正的潜在的成本节约等实实在在的利益和成本避讳。一些地区都反复的初始成本增加和减少成本(例如,程序必须投资为了省钱)。成本影响关系的措施,应该解释相比,传统的开发环境。每个主要成本的技术基线和成本影响区域有:

• 项目管理/系统工程——敏捷项目需要强化政府管理整个开发过程的参与和投入。政府项目办公室必须密切参与承包商开发团队在日常生活中,而且必须招募专门支持额外的政府资源(例如,成本估计、测试人员、用户、合同管理人员)。这个更高层次的参与和额外的敏捷原则(如产品所有者)可能需要政府资源的增加。
• 软件开发——敏捷开发寻求持续的用户参与和反馈整个开发过程。这可能导致增加计划外工作在发展变化纳入发展阶段而不是解决部署后(包括作用或检查更改),在传统的瀑布式方法。敏捷开发者通常是交叉训练由于较小的团队规模和快速交付。开发团队也在一次小批量的软件工作。的组合技能的开发人员和小批量的发展可能会增加生产力。敏捷开发可能减少软件增长由于不确定性需求,因为在敏捷需求优先和交易成本和进度。然而,程序必须仍占软件大小因其他原因不确定性。
• 集成和测试——集成和测试的成本估计必须考虑短期的影响,频繁,敏捷开发的集成实时集成和测试特点,和确定成本不同于那些传统的瀑布式方法。集成和测试大批量的功能,在传统的瀑布式方法,本质上是更复杂的比小批量执行这些任务的功能,和开发测试技术和检测错误在测试更加困难较大的批次的软件。频繁的测试还允许检测错误的早些时候,当他们能够更简单、更昂贵的修复修复这些错误在测试执行结束时发展。政府还必须评估对回归测试的影响。敏捷开发自动化测试并不是唯一的,但大部分的集成和测试在敏捷开发高度自动化,允许交付短,频繁的发布的软件。
• 用户参与——用户表示敏捷发布团队有必要帮助优先需求,协助创建用户故事,进行用户验收测试,并报告反馈部署能力。保持持续的成本长期用户表示在敏捷团队应该考虑到成本估计。
• 菲尔丁/部署——敏捷版本部署新功能简而言之,频繁的发布(通常每6 - 12个月)。变化的程度和水平的每个版本的复杂性,可能需要进一步考虑的部署成本。自动部署并不是唯一的敏捷开发,但作为一个敏捷的推动者。敏捷开发取决于高度的自动化部署使用提供短,频繁的有效版本的软件。的现场部署活动成本的关键驱动因素,可能产生显著增加部署的努力如果每个版本需要大量现场部署活动。
• 培训——软件开发版本和训练可以异步但敏捷开发将导致更多的培训交付比传统的瀑布式开发。最终用户参与和培训可能需要与每个版本的推出。现场培训的数量是一个成本的关键驱动因素,可能产生显著增加是否需要重现场培训。由于用户深入涉及整个开发过程,这就增加了内置的可用性与产品结合在一起的,可能减少培训材料的复杂性和所需的培训时间。
• 维护——作为部署新功能,程序必须从之前的版本部署运作和维护功能。程序必须维持多个评估成本的影响,频繁,重叠的版本。不断与自然高度自动化的测试在敏捷开发期间可能产生更大的错误检测,因此更少的缺陷横到维护,他们成为昂贵的修复。持续的用户参与整个开发过程可能减少与加强和优化相关工作部署软件维护阶段。

总的来说,比较敏捷开发与传统的瀑布式方法揭示了成本增加和减少的区域。项目管理/系统工程可能会经历略有增加程序接受和学习敏捷过程和集成了一个更高层次的参与。软件开发展示了一个复杂的增加和减少,但总体来说更高的生产率和减少软件增长由于需求变化可能导致成本下降。自动化集成和测试和部署都是敏捷开发的关键驱动力,和这些领域程序可以自动化的程度抵消了增加数量的测试和部署。所需的现场部署/部署和培训是一种成本增加在这些领域的关键驱动因素。现场存在必要的越少,越低潜在成本增加。维护代表最大的成本区域减少,由于高质量的代码,更少的缺陷,和更少的软件改进和优化部署后。维护成本通常占大多数的生命周期成本系统持续多年,所以这里可以证明任何造成重大影响。

下面的列表显示了一系列潜在的生命周期成本影响的主要成本。分析装备太不成熟,任何成本的影响趋势转化为真正的美元价值。此外,如前所述,许多变量因素的具体成本分析每一个领域的发展。因此,关系量表是用来总结的一般趋势和斜坡方向与每个区域关联成本增加和成本减少。缩放技术选择比较每个成本要素是一个相对的技术,一个象征性的措施被分配到选择如下:

• + +表示成本显著增加;
• +表示,成本增加;
• =表示,成本没有影响;
• ——表示,成本降低;
• ——表示,成本显著降低

扩展措施反映了一系列成本的增加和成本的降低归因于敏捷开发相对传统的瀑布开发方法。

+ +显著增加,增加,=没有影响,减少——显著下降

生命周期影响评价

总之,敏捷开发可能导致净减少总生命周期成本,特别是因为最大的区域在维护成本降低。

这里描述的成本增加和减少不一定是独立的。例如,如果没有高度的自动化集成和测试程序很多没有完全意识到提高代码质量和降低维护成本。一般成本影响范围呈现为每个区域可以作为指导,但程序必须评估他们的特殊情况来确定更具体的影响。

敏捷有很多潜在的好处。下面的表格识别的一些关键利益方面考虑。

敏捷效益考虑

受益面积		描述
响应的不确定性和变化	方法提供了构造拥抱不确定性和变化而不是避开他们,和这些结构构建到所有过程的水平
提高了生产率	软件开发生产率提高较小,多功能团队工作在较小的尺寸发货(超过的复杂性管理复杂性)
更快的部署能力	更快的交付使用,可工作的软件,提供价值在开发周期中更早比传统项目
改进质量	减少错误发现软件发布后通过继续测试,小批量测试和高度的自动化测试
提高用户满意度	增加用户满意度与最终产品,因为高水平的用户参与和反馈在开发过程
程序的稳定性	增加程序的吸收能力削减预算和优先次序的能力和贸易融资的不确定性需求

几项研究的数据表明,程序可以减少通过调度实现效益、提高生产力、质量和客户满意度。然而,发现患者显著差异在研究和范围从边际改善明显改善。

效益分析应考虑敏捷的迭代性质和交付功能的能力比传统的瀑布式方法,早不领域能力发展到最后。好处将软件部署。下图比较这两种方法。

利益实现的比较

工作分解结构(WBS)构成了每个程序的基石,因为它详细定义了必要的工作来完成项目的目标。WBS元素相关的工作要完成,最终产品并确保不遗漏的部分工作或双统计。WBS识别提供了依据和显示资源和任务开发项目成本估算。

其他横切敏捷WBS研究成果开发了一个全面的框架,项目执行敏捷开发可以利用定义活动和有效沟通的工作要做。这些努力确定和审查现有的敏捷开发活动故障和分解。开源社区研究发现一些商业活动和成本结构,但没有一个全面的生命周期模型。活动进行了分析,编制、修改和扩充为政府项目开发一个全面的敏捷WBS。WBS可以映射到共同的生命周期成本元素。敏捷WBS已经提出并讨论了在不同的论坛和会议成本的社区内。

敏捷WBS,如下所示,提供了一个高层次的、可扩展的结构来描述工作和产品适用于一个敏捷项目。它的目的是作为一个起点或引用协助组织管理过渡到敏捷开发方法和指南项目识别活动需要考虑。敏捷WBS可以根据每个程序,可以将更详细地随着时间的推移变得知道的更多信息。确定的活动可以被映射到传统WBS结构更大的理解和效用。敏捷WBS应该结合任何附加组件程序可能已经超出了敏捷开发的范围。

敏捷WBS跨越两个总体项目管理和系统工程活动以及版本级别活动和sprint-level活动重复每个版本和sprint,分别。WBS包括开发和维护活动;然而,它背离传统的wbs在发展——和sustainment-related活动不区分从一个另一个在顶层。在敏捷,软件生命周期开发的所有阶段可以发生在一个迭代和敏捷WBS结构反映敏捷的本质。它不明确识别维护,但活动将从发展过渡到维护时间和目的决定。适当的开发相关的活动将包括努力维持转换。这也意味着,虽然活动提出了一个逻辑顺序生成框架,他们不一定都是按时间顺序。

高级敏捷WBS

项目管理和系统工程(PM / SE)活动包括那些传统上由项目管理办公室(PMO)团队或由系统工程师不一定是一个开发团队的成员。包括传统的活动保持不变在敏捷项目中,如资源管理、合同开发、治理和决策、发展路线图,收购战略制定,等下午/ SE活动特有的敏捷的努力包括创建和梳理产品待办事项列表,和“定义”。

所有其他活动分为发布活动的类别:那些涉及规划、执行和评估/演示版本。许多的活动对于一个给定的释放发生在一个sprint;因此,“冲刺活动”包括相关活动策划、执行和评估/演示一个sprint中所进行的工作,以及一个sprint回顾改善未来的冲刺。执行一个sprint涉及潜在的开发生命周期的所有阶段,包括设计、架构开发,实现,测试,文档、部署和培训。其他活动,如代码审查和工程分析或实验,需要的基础上发生,每项目可能会有所不同。如前所述,维护活动是每个发行版的一部分,因此没有明确区分在WBS。维护活动应该包括在适当的元素从开发到维护。

一个敏捷开发项目的预算是基于政府项目成本估算,考虑到技术基线要求IT系统。项目成本估算必须考虑到敏捷开发成本以及其他所有的成本计划、管理、获取、维护和处置程序。敏捷的一个好处是,一旦预算已经建立了程序可以是结构化的,以“构建预算。”资助,该项目收到然后驱动器的数量每年释放它可以管理和交付的全部需求的整个开发周期内的性能。然而,程序必须小心追踪烧毁指标,确保进度对积压是充分的。在国防部,阻力分配预算程序,直到所有定义的需求是完全和批准通常构成了挑战。国防部高管和国会通常需要一个清晰的理解的需求成熟度级别预算授权。

敏捷开发的迭代,分段性质,敏捷项目可以向上或向下扩展更容易比传统项目交付能力的5 - 10年的增量。即使敏捷项目经验在开发过程中主要的资金削减或取消,部署版本已经有能力提供给用户,这是不能保证在一个传统的开发。

如下图所示,在传统的瀑布开发项目范围和质量是固定的,而进度和成本不同,通常随着需求进一步明确在项目。敏捷开发项目尝试修复进度和成本,同时调整了特定版本以适应这些约束的范围。每个交付版本的范围定义的优先级要求交付最终用户功能约束内的成本、进度和质量参数。因此,治疗成本作为一个独立变量驱动需求的优先级和促进发布计划。

传统的瀑布和敏捷的成本差异变量

如上所述,敏捷项目可以吸收比传统的收购程序更容易削减预算。更容易将资金从一个程序,可以推迟一个小版本比“打破”武器系统增量或显著延迟交付给用户。因此,项目通常是削减预算的主要目标,而不是武器系统在僵化的需求文档下运行的程序。它采用敏捷技术的程序必须确保他们有足够的支持服务/机构,OSD,联合参谋部的水平,以避免持续的风险资金。

将软件开发项目分解为几个可部署的版本使项目使用敏捷方法适应永久减少生命周期预算削减和临时开发预算。传统的基于瀑式开发项目发现它困难得多,在技术上和契约,以适应变化的预算情况。

关键问题来验证估计:

• 这个团队有良好的历史数据,进行新的估算的时候可以参考?
• 团队的速度定期更新和使用范围冲刺呢?
• 开发团队有很强的知识/经验用户域?
• 开发团队有强大的知识/经验与技术?
• 所有开发团队使用一致的估计方法吗?