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

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

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

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

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

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

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

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

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

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

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

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

额外的参考用户故事:

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

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

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

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

用户论坛

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

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

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

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

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