一个性能工作报告(PWS)或声明的目标(秀)在提案申请是一个关键的文档(RFP)包。RFP描述要执行的工作的目的,与合同要求明确,具体,和客观的和可衡量的结果。PWS描述政府的要求,任务必须完成,以满足需求,和政府何时/如何知道什么时候结果已经圆满实现。秀,相比之下,描述了政府希望实现高层次的结果或目标,给供应商一个机会提出创新的解决方案来满足政府定义的目标。

没有特定的格式PWS /秀,但他们通常包含一个简短的描述服务、背景、目标、范围、时间的性能、质量控制和质量保证。

在敏捷开发中,政府必须首先确定要采购服务或产品。推荐在接触的准备部分,服务合同通常是首选的敏捷合同努力因为它提供了最大的灵活性改变通过合同的生活需求。以下问题可以用来帮助推动背后的批判性思维的发展规模/秀敏捷开发合同。

问题来帮助开发规模/秀:

• 政府决定,敏捷是唯一可以接受的发展战略?PMO开放给其他供应商提出的开发方法最好的交付产品或系统吗?
• 将政府或承包商定义敏捷开发过程的细节?
• 政府与承包商的角色和职责是什么?
• 政府将向承包商提供(例如,设施、信息)?
• 政府的“完成”的定义是什么?
• 如何PMO的承包商将接口,测试人员、工程师、和其他承包商?
• 是什么政府的承包商的预期与其他承包商的关系计划?
• 政府的承包商的预期的支持系统工程的评审和测试?
• 数据的权利要求是什么?如何将数据转移供应商脱离上述期间的合同?
• 所需的最小的可交付成果是什么?
• 最小的一组指标,承包商需要跟踪和报告吗?
• 政府将如何衡量绩效?
• 什么是与性能相关的奖励和惩罚措施?
• 政府是否有特定的工作类别对敏捷开发支持,还是政府预计,要约人提出自己的团队提供一个最佳的组合?

PMO必须决定谁将负责定义敏捷开发流程和方法。在某些情况下,政府可能已经成熟的敏捷过程中的计划,政府可能想要支配特定的敏捷开发过程,将利用浆。下面是样品浆可以使用语言,如果政府“拥有”或指导敏捷方法或过程:

政府引导敏捷方法:

该计划将为这个项目使用敏捷开发方法。该计划将提供功能交付产品发布每6个月。为期6个月的每个版本将由四个sprint中周期。Sprint周期是由1周的设计阶段,包括需求定义和优先级,四周开发和操作测试周期,1周终端用户演示。承包商将与政府团队的敏捷环境中。程序将创建和维护的系统架构,需求积压和路线图,将承包商的工作的基础。承包商应支持政府的开发和评估用户故事,发布计划,系统工程产品,和验收标准。

另外,政府可能希望供应商社区提出了敏捷开发流程和方法,最适合由政府确定的结果或目标。在这种情况下,它甚至可能不是必要的政府决定使用敏捷,而是简单地描述其期望和目标,利用秀文档格式。下面是样品/ PWS -秀可以使用语言,如果政府希望承包商提出的开发方法和过程,将最好的满足由政府确定的目标。

承包商提出的开发方法:

承包商应提出一种开发方法,最好的满足合同的要求。至少,承包商应开发和部署6个月增量项目的使用功能。每个增量应包括测试、IA和部署以确保功能可以给用户以增量的方式发布。建议的解决方案应包括一个解释的项目和合同管理、通信/与政府合作,安全和隐私需求,文档和报告将函数结合提出的开发方法。承包商应确定承包商的角色和职责而下的政府提出的开发方法。

根据服务类型的合同,政府可以提供规范的类型将根据合同提供的支持。敏捷服务需求的例子包括用户故事协作,用户为中心的设计,代码开发,自动化测试、可用性测试、集成支持,数据迁移,部署支持,DevOps支持、配置管理、用户培训、度量报告,过渡支持、便利的支持,和Scrum Master辅导和培训。同样重要的是包括转变和调整出来支持PWS的一部分。

由于敏捷的迭代性质,重要的是要有一个共同的“完成”的定义达成一致由整个团队。因此,规模应该包括一个明确的“完成”的定义。“这将被用来确定个人用户故事是否完成,可以接受。政府要求要约人可以包括一个“完成”的定义提出了敏捷的解决方案,政府将评估作为技术方案的一部分。作为一个团队的成熟,可以扩大到包括更多的元素定义。合同应包括规定允许的”政府和承包商之间的协议。

最初的“完成”的定义可能包括下列例子:

• 所有的代码已经对程序或代码检查。
• 能力已经交付给用户的满意度代表
• 已经符合编码标准,并且可以在必要时。
• 所有508合规、安全需求,法律要求考虑到发布的代码。
• 决策者已经接受了最后的交付
• 功能交付符合关键性能参数

RFP的焦点/ RFQ很大程度上取决于政府是否追求一个服务或一个产品合同。

如果追求服务合同,最重要的方面建议应注重个体的团队成员的资格和经验的集体团队执行敏捷开发过程。政府应该要求的技术或管理计划包括的简历提出敏捷团队成员,并提供具体的例子执行敏捷开发流程相关经验的相似和相关工作。

如果追求的产品合同,政府应该重点放在如何要约人描述他们的计划,以满足政府的要求。在这方面,如果承包商提供政府要求,政府不应授权使用敏捷流程,而是允许承包商提出一个方法最能满足需求的由政府确定。

下表给出的例子可以使用语言,在敏捷开发RFP,包括语言部分L(要约人指令)和部分M(奖)的评价因素。政府可能会使用以下样品评估元素的组合,但这个网站的作者强烈建议不要使用太多的评价因素/ sub-factors(超过3),这将大大增加时间评估和奖励合同。政府应该只使用技术评估因素/ sub-factors将生成提议鉴别器在评估过程中。此外,它被认为是一种最佳实践在承包社区定义部分M(奖)的评价因素在写作部分L(要约人指令),反映在如下表。

请注意,这不是建议,政府发行时使用以下建议指导和评估标准任务订单现有合同车辆。政府建议充分利用提供的灵活性到15.505公平机会的规定。在这些情况下,政府不应该使用正式的评估计划或详细的评估标准(有关更多信息,请参见合同车辆部分合同的准备)。

评价要素	部分米(奖)的评价因素	要约人节L(指令)
敏捷实现策略	政府将评估的完整性、可行性和合理性提出了敏捷实现包括技术的发布计划,计划参与终端用户,方法捕获和应用经验,测试流程,原因他们的敏捷团队的构成和背后的基本原理提出的开发人才和项目监督(与产品愿景),要约人将如何使可用资源在进度和预算约束,要约人的配置管理方法。	要约人应当描述敏捷实施他们的方法来管理,
角色和职责	政府将评估的完整性、可行性和合理性描述的要约人的角色,责任,和承包商的预期,政府PMO, PMO团队成员(例如,测试)在执行敏捷过程中,全面识别和解释所有假设由要约人。	要约人应当描述敏捷团队的角色和职责,包括政府人员。
资源分配策略	政府将评估的完整性、可行性和合理性的要约人适当资源中的敏捷开发团队的计划进度和预算约束。政府将评估要约人提出的团队结构和人员,以及他们的策略来保持团队激励和参与项目的整个生命周期。	要约人应当描述他们的战略资源和管理团队绩效。
技术解决方案	政府将评估的完整性和全面性的技术解决方案,以确保其地址项目和合同管理、通信/与政府合作,安全和隐私需求,文档和报告(包括根据需要附加的元素)。	要约人应当描述他们的解决方案以满足政府需求。
产品开发路线图	政府将评估如果要约人提出的产品开发路线图与要约人的既定目标和期限有关要约人提出的敏捷方法的实现。政府将评估如果产品开发路线图显示,测试,培训,安全,隐私,和切换计划将进行合理性的方法。	要约人应当提供产品开发路线图。
绩效管理	政府将评估的完整性、可行性和合理性要约人提出的质量控制和性能测量方法,包括如何监控提出了性能标准,评估和报告。政府将评估如果措施和指标提出了结合提出了技术解决方案。	要约人应当提出绩效管理策略为政府在合同使用性能,包括具体措施和指标来衡量团队绩效。
技术债务	政府将评估的完整性和合理性提出要约人的策略来减轻建筑技术债务的风险在项目和解决积压的技术债务的计划。	要约人应当描述其战略管理和项目技术债务。
从瀑布过渡到敏捷	政府将评估: 如果要约人展示了当前环境的理解 识别的时间表,关键风险,并要求决策点完成后,彻底的和合理的 如果策略是合理和基本原理,并将允许平滑,有效,并完成从瀑布过渡到敏捷。	要约人应当描述该方法从政府目前的瀑布式方法过渡到提出要约人的敏捷方法。
发布计划	政府将计划发布评估要约人的方法,以确定是否提供了一个全面的和全面的方法来满足政府为交付系统功能目标和重点。	要约人应当描述方法首次发布计划,构建增量发布的软件功能,并响应改变政府重点在发布计划和执行。
发布策略	政府将评估发布计划提出的要约人对现实主义和计划的可行性和实施提出的资源。政府还将评估要约人的理解的目标征集,国土安全部,程度提出计划满足请求中指定的目标。	要约人应当描述能力寻求释放的征集。要约人应当描述它提出的迭代的数量和长度必须满足的目标征集并描述每个迭代产生的产品导致的整体能力。
敏捷方法	政府将评估如果要约人提供了一个完整的,全面的,令人信服的理由,为什么敏捷方法提出最合适的,将是最好的结果。政府将评估: 如果要约人给予适当的考虑政府当前的组织和环境。 拟议的敏捷方法适当满足招标书要求的需要。	要约人应当描述为什么敏捷方法被提出了这种努力是最适合这个招标书的要求。
政府敏捷实施支持	政府将对要约人的方法来支持政府实施敏捷方法首次。 政府将评估的完整性和全面性的策略指导和支持政府的整个过程 政府的透明度和完整性对要约人的角色和责任 过程将被用于测量和跟踪敏捷实施的进度。 政府将更高的分数分配给要约人能够提供具体的成功的例子,他们支持政府实施敏捷首次在其他项目和组织。要约人应当描述这些组织或项目采用敏捷实践是成功的。	要约人应当描述的方法来支持政府敏捷战略的实施。
敏捷需求管理	政府将评估的完整性、全面性和理由提出战略管理敏捷需求。要约人应当提供一个详细的解释他们如何计划工作与政府和用户代表,不断平衡跨用户需求,业务目标和技术要求。	要约人应当描述他们的策略来管理敏捷需求。
人员配备计划	政府将评估: 的完整性和合理性提出了敏捷开发团队的描述和一贯团队功能如何结合技术中概述的开发方法的建议。 描述的完整性和合理性的经验和成功的敏捷开发团队支持先前的计划/项目,使用敏捷开发。要约人能够确定计划和项目,也有类似的范围和复杂性的需求征集将获得更高的收视率。	要约人应当提供的描述敏捷开发团队,包括人员的数量来支持敏捷开发流程和具体的个人名称与敏捷团队的作用。要约人应当描述如果敏捷团队提出之前一直在支持敏捷开发项目/计划,这些计划/项目的成功。要约人应当识别所有人员在敏捷开发团队和角色(s)他们在支持敏捷过程。要约人应当提供人员简历描述的细节大家的整体经验和教育。简历应包括具体的引用与敏捷流程和培训经验。简历也应该确定个人的工作经验以前敏捷开发项目和他们的角色在项目(s)。(建议设置一个特定的页面限制简历,或提供一致的审查简历的简历模板)
相关经验*	政府将评估: 要约人是否已经提供或目前提供敏捷开发支持类似的和相关的工作。 的规模、范围和程序/项目引用的复杂性与规模、范围和这项工作的复杂性。 要约人可以展示多个实例的成功实施敏捷开发过程将额定高。要约人给其他程序/项目的例子使用一样的敏捷团队在此工作将被提出更高。	要约人应当描述完整的敏捷开发方法提出了一直在利用其他相关计划和项目。为每个客户参考,提供以下: 名称/当前客户的识别 叙述项目/产品的描述 故事描述的大小、范围和复杂性的计划/项目参考,以及它如何与大小、范围和这项工作的复杂性。

*评估相关技术/管理经验建议不同于评估过去的表现作为一个单独的和不同的因素。一般来说,过去的表现必须被评估为所有主要的收购;相关经验(如技术评估因素的一部分)不是必需的,但强烈推荐这个网站的作者。

另一种流行的方法来评估敏捷请求包括challenge-events供应商的现场演示他们的能力。例如,政府可以要求供应商提交一个工作原型基于一个共同的数据集在一个24小时的产品开发的挑战。这个事件进行结合的技术方案和/或口头建议,或可用于代替传统的书面技术方案。

产品适合敏捷开发挑战募捐,因为他们要求供应商交付能力的证明或证明自己的能力。他们还减少供应商的报价和建议费用如果挑战取代了技术方案。另一方面,可以创建一个产品的挑战政府的风险,因为它没有保证的团队工作所面临的挑战将是相同的团队,将合成的工作合同。理论上,供应商可以利用他们的“A”团队为产品演示但随后员工项目缺乏经验的员工。因此,建议政府结合product-challenge“轻量级”的技术方案,介绍了人力资源计划,并提出开发方法流程。Youtube视频的使用记录口头建议可以用作“轻量级”技术的建议。

国土安全部、灵活敏捷支持国土提案申请了一个技术挑战。挑战可以访问的细节在这里。

下面是建议语言,可用于视频口头建议:

要约人应当提交视频不再是比X分钟长,解决以下评价方面(插入评估标准,问题,或场景)。推荐视频功能敏捷项目团队成员提出了这一努力。

注意:视频提交的质量不会考虑到政府的反馈。政府鼓励低成本影片制作,如手机摄像机。

提交指令——视频提交必须为政府发布到Youtube.com访问。视频可能标志着公共或私人。通过XX日期,供应商必须发送一个Youtube链接和密码(邮箱地址)为了让政府访问视频提交。政府将不提供供应商的视频以外的政府评估小组没有供应商的许可。不提供缩短URL,比如youtu.be。

合同应包括同意定价方法或模型。对定价敏捷开发一些其他注意事项包括:

• 定义结账期和价格说明个人迭代和项目作为一个整体。
• 定义每工作单元(UoW)的价格。UoW的例子包括价格/故事点,价格每个功能点,每个特征点和价格。
• 点估计的大小或相关工作;关键是每一个“点”是明确定义的。

两种典型的方式来确定价格每点:

• 基于之前的几个项目的平均
• 定制的数量:供应商平均点值几个迭代期间详细的成本跟踪。然后供应商和客户同意一个定制的价格每点(FP或T&M《)。
• 固定价格的考虑:
  • 固定价格每个迭代计算(也许通过引用所需的工作量,迭代或者相关的商业价值开发项目)
  • 工作单位固定价格(价格每个用户故事,或特征点);可能很难估计如果用户故事有不同的范围或价值)

传统的项目通常包括一个详细的规范的列表的厂商应该提供的形式(通常是冗长的文档)和工件是如何接受。繁重的文档要求(例如,挣值管理)花时间远离团队应该专注于交付。一份详细的交付文件清单不需要敏捷;当应用适当,敏捷是一个结构化和自律的过程,政府将获得“实证”的证据表现形式的工作软件。政府应该要求“足够的文档”验证功能交付符合机构治理和IT系统生命周期的需求。可交付成果的类型的例子,可以对敏捷的要求包括:

• 敏捷度量报告(例如,团队速度)
• 系统设计文档
• 建筑/合规文档的引用
• 自动化测试的结果
• 经验教训
• 定期进度报告
• 培训手册
• 信息支持计划

• 做合同策略和时间支持频繁的能力释放?
• 是追求服务合同或完成的程序/产品交付合同?
• 是政府的主要系统集成商?
• 项目有专门承包支持吗?
• 合同管理人员与程序共存吗?
• 缔约环境是否支持敏捷开发流程?
• 现有合同车辆支持敏捷交付吗?
• 什么是合同管理人员之间的接触和敏捷团队吗?
• 政府监督承包商的表现如何?
• 合同包括一个过程来确定有多少高优先级项目确定的产品所有者可以开发在当前sprint吗?
• 合同必须包含一个“最小可行产品”的定义为每个特性?
• 合同确定的开发和对sprint backlog的过程吗?
• 合同描述改进同意在一个sprint回顾会议是如何实现的?