产品所有者满足敏捷团队中最重要的角色之一。一般来说,产品所有者/跨生命周期的产品负责人的职责包括:

• 建立一个清晰的愿景的程序来完成
• 传达的概念操作项目管理办公室(PMO)和开发团队
• 管理程序和释放积压,确保需求/用户故事是当前,优先,技术上可行,有一个明确的“完成”的定义”验收标准
• 与开发团队将需求转换成用户故事
• 添加/删除/改进用户故事和验收标准输入来自多个利益相关者
• 坐标与运营高级赞助商,专家利益相关者,和广泛的终端用户,记录需求,优先级和反馈而分享见解,并提供演示程序的进展
• 从开发团队对用户故事回答问题,功能,和用户界面
• 协调功能演示与操作赞助商和最终用户在每个sprint向开发团队提供反馈。
• 定期提供反馈给开发团队进行临时的发展
• 标识在释放积极的参与者和sprint计划和回顾
• 识别活跃的参与者在建模、模拟和测试
• 坐标与其他产品相关项目的所有者将接口或集成
• 坐标部署的版本。

更紧密的与开发团队和产品所有者可以PMO在开发期间,成功的机会就越好。如果协同定位与开发团队或PMO是不可以实现的,应该有频繁的同步协作会话,如面对面的会议,视频/音频电话会议和在线协作/示威。产品所有者应该可以提供及时的信息和决策。异步协作工具,如JIRA也可以使产品所有者与开发团队密切合作。

程序必须选择那些有运营经验,沟通能力,和视觉形状程序所必需的。程序应指定和授权产品负责人(s)谁能传达项目愿景,作为客户的声音,和管理项目积压。这可能是由一个领导人或一个小团队的运营社区的领导人执行日常需求管理。

产品负责人引用:

• • 12个产品经理做的事情
  • 产品所有者抽象(按比例缩小的敏捷框架)
  • 产品负责人(敏捷建模)
  • 产品负责人角色(Pichler咨询)
  • 37个任务产品负责人(敏捷跟踪)
  • Scrum指南(ScrumGuides.org)

批准信息System-Initial功能文档(IS-ICD)在MDD授权程序使用这盒模型的JCIDS手册,调整后续需求文档/指定flag-level需求监督委员会的批准。程序可能将需求分解成需求定义包(rdp),能力下降(CDs),和/或替代文档结构。下面的图显示了一个潜在的文档结构的概述JCIDS手册。在这个例子中,rdp和cd是逐步开发和批准。rdp是主要的文档捕获ICD需求的一个子集。cd可以涵盖一个RDP的一个小子集或一个独立的项目,如一个小应用程序。
的这盒模型提供了很大的灵活性优势传统JCIDS文档,但是敏捷环境中需要更多的灵活性,以动态管理需求。敏捷软件在文档工作优先;关键是不要投入太多的时间和精力创建和批准提前冗长的需求文档。敏捷依靠持续的用户参与整个项目和需求细化。IS-ICD flag-level要求监督委员会确认,产品所有者应该共享一个清晰的理解的期望和当局。

一个清晰的、严格的需求管理过程是一致的关键利益相关者对常见的结果。一种方法是问要求董事会批准一套简洁的RDP作为初始的高级需求,功能,和/或用户故事版本或版本支持计划。管理需求在一个传统的采办计划包括一个需求所有者开发一个大型需求文档和用户社区和协作。在敏捷环境中,一个类似的角色有助于捕获需求(通过积压)和最终用户合作,但是也加入项目团队作为一个常任理事国定期进行迭代的需求。期间发布的计划和执行,产品所有者应委托给添加、删除、更改,并细化需求,每一个建立敏捷需求过程或用户故事。因为敏捷版本和冲刺的时间装箱,时间表是锁定的范围而灵活。同样,基于开发、示范和反馈在早期的冲刺,释放的需求或用户故事可能会改变。产品所有者应该要求董事会的重大变化在发布通知透明度和共同的期望。开发团队定义并同意每个sprint的范围,最后通过一个sprint计划会议,一天或更少。鉴于快速时间表,它会太麻烦协调批准cd作为RDP的一个子集,通过国旗officer-level需求。 The requirements board should empower the Product Owner should to approve the scope of each sprint and inform key stakeholders. This is best accomplished via a set of user stories and acceptance criteria, whether captured in a CD or ideally via collaborative Agile development tools. A small stand-alone capability independent of a release may be captured in a few user stories or CD and, depending on the requirements board’s expectations, approved by the board or the Product Owner.

• 操作环境支持小,频繁交付能力。
• 需求显然是分解成小任务。
• 终端用户可以在需求和开发分享作战的见解,并提供即时反馈从示威。
• 管理一个项目积压通过一半页面工作包与一个粗略的政府估计,设计背景和技术接口
• 授权产品所有者——单/多基于用户社区的规模/多样性

需求在敏捷环境通常是通过项目管理,版本,和sprint积压而不是通过正式的需求文档。积压可能需要数据库的形式,Excel电子表格,或者基于敏捷的软件工具。产品负责人积极管理(培训)计划和释放积压,处理用户社区和其他利益相关者识别所需的详细程度最大的最高优先级需求。

下图显示了项目之间的关系,释放,和sprint积压。项目待办事项列表包含所有所需的功能和要求。一个发行版计划安排中通常包括最高优先级需求从项目积压,团队可以在既定的时间内完成。每个sprint由最高优先级需求的发行版计划安排中。一旦开发团队致力于为sprint工作的范围,该范围是锁着的。Sprint示威活动由承包商在Sprint结束时可能确定新的特性或缺陷,团队将增加释放积压或程序。

产品所有者,与运营合作赞助商,要求组织、遗留系统运营商,一个广泛的用户基础,架构师、系统工程师、企业架构师,和其他利益相关者,捕获,集成,改进,重视项目项目积压。项目可以包括:

• 史诗或主题的主要需求元素,跨越多个版本
• 与其他系统的接口
• 基础设施需求/接口

程序之间的交互、释放和Sprint积压

许多商业敏捷开发工具都可以通过捕获程序要求用户故事验收标准。这些用户故事是保存在一个数据库进一步细化,优化,和估计的复杂性,时间,成本为每一个元素。在项目的早期阶段,这通常是由政府人员,如产品所有者PMO的支持之前,承包商选择EMD阶段。

政府人员,包括承包商FFRDC和支持敏捷开发技术,基于终端用户需求的用户故事草案;这些用户故事和估计是精制一次开发承包商被选中。用户故事必须清楚地呈现在操作使用一个既定格式条款,包括验收标准。政府捕捉草案估计的复杂性和时间要求完成必要的活动为首要任务的故事来支持构建版本和估计成本和时间表。低优先级的故事的细节将会在未来。

一旦选定承包商,开发团队评审和改进程序和释放积压产品所有者和PMO。这支球队是最适合估计的复杂性和时间表来完成每个用户故事。随着时间的推移,团队开发版本,估计将改善的忠诚的成员更好地了解团队的速度,细化的积压和评估技术。

产品负责人定期培训项目积压的帮助下许多利益相关者。定期会议持续的释放可能需要独立的完善与用户优先级用户故事,工程师,开发人员、架构师、测试人员,和其他利益相关者。在线协作工具的使用将确保利益相关者了解积压的细节,并提供输入和反馈。和敏捷的许多领域一样,一个小,授权,高性能的团队将会有更好的成功比在日常业务中涉及到很多人的努力。在5到9是一种常见的团队规模引用在敏捷论坛,最好的大小取决于程序的环境。

产品负责人,积极与用户和利益相关者合作,负责梳理积压,确保内容和优先级保持当前团队接收反馈和学习更多从发展和外部因素。用户和开发团队可能会增加需求的程序或发行版计划安排或转变的需求。发布的产品所有者和开发团队建议开发的影响这些决策,而用户建议释放团队的操作优先级和影响。依赖关系必须被理解,因为能力开发能力来解决一个特定的用户故事可能取决于外部交付功能(例如,从其他系统),内部开发能力已经开发或计划。一些程序可能使用一个变更控制委员会来帮助一些较大的待办事项列表的决定。

在敏捷环境中,用户经常将需求转化为史诗和用户故事来简明地定义所需的系统功能和提供敏捷评估和规划的基础。这些故事和史诗描述用户想要完成的系统。用户故事帮助确保用户、收购、开发人员、测试人员,和其他利益相关者有一个清晰的和公认的理解所需的功能。它们提供了一个动态的方法来管理需求远远超过大需求文档。开发团队定期审查的故事积压,确保细节和估计的精确度。工程师也可以编写用户故事来覆盖安全的基本特征,技术性能、可支持性、培训、或质量。与其他系统接口通常是捕获为用户故事。

用户故事需要很少的维护;他们可以写一些简单的索引卡。用户故事是一个共同的格式:

“作为一个用户角色,我想(目标),所以我可以(原因)。

例如,“作为一个注册用户,我想这样我就可以登录访问目前付费内容。“用户故事应该有以下特点:

• 简洁、功能价值用户的书面描述
• 高级特性的描述
• 在用户语言编写,而不是技术术语
• 包含的信息来帮助团队估计水平的努力
• 措辞,使一个可测试的结果
• 可追踪的首要任务线程

定义每个用户故事应该与验收标准以确认故事完成时和工作。这需要利益相关者有明确的“完成”的定义”,以确保共同的期望。验收标准由一组—语句指定可验证的基本功能需求(测量)。定义在规划阶段验收测试使开发人员能够测试临时功能经常和返工直到他们达到期望的结果。这种方法还简化独立测试后开发的一个版本。例子包括:

“注册用户可以登录95%的时间。”

“虽然登录目前付费内容可用100%的注册用户的时候了。”

开发团队、用户和其他利益相关者可能使用故事板和原型帮助可视化系统的使用和功能。

团队更新积压基于用户和开发者学习证明和部署能力。新项目可能包括使修复软件或产生新的想法。随着业务的变化,团队可能添加或更改需求和用户故事,无论是在内容和优先级。例如,团队可能会增加集成项目积压的程序接口与其他系统。系统工程师和企业架构师可能添加的项目支持的版本的完整性或技术基础能力交付和信息保障。理想情况下,团队应该解决发现的问题政府和承包商测试人员在未来冲刺或释放,但他们可能会增加这些问题积压基于修正的范围。

额外的参考用户故事:

• 敏捷联盟的用户故事
• 用户故事:一个用户故事是什么?Mike Cohn,
• 非功能性需求是用户故事Mike Cohn,
• 用户故事应用Mike Cohn,
• 200用户故事的例子MoutainGoat软件
• 编写有效的用户故事GSA技术指南
• 用户故事的例子GSA技术指南
• 5我们编写用户故事所犯的常见错误,Scrum联盟
• 10条建议编写好的用户故事,罗马Pichler
• 如何写好敏捷用户故事,冲刺
• 写好的用户故事的简单方法,代码
• 用户故事:一个敏捷的介绍,敏捷建模
• 编写用户故事、集会
• 你最好的敏捷用户故事亚历山大•考恩

用户和物资开发者密切伙伴关系国防采办项目的成功至关重要,是一个敏捷的关键原则。用户必须保持积极参与整个开发过程,确保整个收购和用户社区的相互了解。虽然大多数用户与他们的日常工作相关维护操作责任,他们可以更积极地参与发展,更好的成功机会。作战指挥官必须承诺为用户输出分配时间进行开发活动。

用户分享的愿景和细节操作的概念(CONOPS)和所需的目标功能的影响。通过持续的讨论,项目办公室和开发人员更好地理解的操作环境,确定备选方案,并探索解决方案。用户然后可以描述和验证需求,用户故事,和验收标准。项目办公室必须确保需求可以放在合同和负担得起的资助,时间表,和技术约束。测试人员也应该积极参与这些讨论,确保共同的期望和测试性能。

在主用户的情况下不可用常规与敏捷团队,正在进行的基础上,最终用户可以指定代表发言代表的主要用户。

用户论坛

用户论坛加强协作,确保所有利益相关者理解和同意的优先级和目标程序。论坛可以作为价值的机制,收集完整的社区的利益相关者和促进合作。他们给用户一个机会,让开发人员熟悉其操作要求和作战和交流他们的期望系统如何支持这些需求。连续接触的用户,开发者,收购者,测试人员,运动鞋,和许多其他利益相关者在这些论坛还使响应程序的更新和一致的理解定义。

成功的用户论坛的建议包括:

• 保持定期的用户论坛和用户社区基金旅游利益相关者;另外,此外,提供虚拟的参与。
• 安排开发人员展示现有能力,原型和新兴技术。这些演示给用户宝贵的见解可能的艺术和当前可用的能力。反过来,用户反馈指导开发人员和收购者在塑造这个项目和研发投资。
• 允许完整的社区作出贡献计划的未来,讨论战略眼光,程序状态问题,行业趋势。项目经理不应该依赖于单向陈述。
• 给利益相关者机会转达期望和获得信息的反馈。
• 建立工作小组,定期开会来解决用户的行为。
• 举办培训课程和利益相关者提供教育机会。

通常大型企业敏捷系统可能需要额外的独立团队的参与测试人员执行系统——/企业级测试和集成。请参考合同的准备为外包合同的细节测试。

• 这个项目有什么需求文档吗?
• 什么需求存在监督委员会和审查/批准吗?
• 负责管理项目backlog是谁?
• 的过程是什么添加、编辑和优先元素在待办事项列表吗?
• 如何要求翻译成用户故事、任务验收标准,和测试用例?
• 有明确的“完成”的定义,团队和涉众达成一致?
• 开发人员参与范围下一个sprint(或同等)?
• 待办事项列表是否包括技术需求从系统工程师,开发人员,和测试人员一起与用户需求?
• 频率是积压培养?
• 有一个建立变更控制过程的需求积压?
• 在积压架构或系统需求管理吗?
• /用户故事/积压需求保持在一个中央存储库访问广泛的用户基础,内容共享用户论坛吗?
• 定期做产品所有者与开发团队沟通新作战概念呢?
• 是测试人员积极参与需求过程,确保需求是可测试的吗?
• 有一个映射在需求、用户故事、任务,以及相关的物品吗?
• 有发布/ sprint需求之间的映射和更高层次的程序/企业需求吗?
• 这个项目有一个动态的过程,定期更新、完善,和区分需求?
• 每个需求/用户故事相关的发布/ sprint计划成本和验收/性能标准吗?
• 用户积极参与整个设计、开发和测试过程中为每个sprint提供反馈?
• 与生命周期的集成支持迭代过程和工具改进和评估每个sprint的一部分?