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

• 建立一个清晰的愿景的程序来完成
• 传达的概念操作项目管理办公室(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.

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