Scrum敏捷项目管理

五十个改善用户故事的快速构想

《五十个改善用户故事的快速构想》是Gojko Adzic的另一本书,他是顾问兼作家,已经就敏捷需求制作了一些非常好的书,例如《影响映射》和《示例规范》。目的是帮助涉及敏捷需求的人员改善与利益相关者的讨论以及与用户案例相关的计划活动。对于初学者来说,这显然不是一本有关如何编写用户故事的书。

改善用户故事的五十个快速构想围绕五个用户故事的主要活动进行组织:创建,计划,讨论,拆分和管理迭代交付。对于本书中包含的五十个有关用户故事的技巧,每一个都有一个关于概念的初步讨论,通常带有真实的生活经验报告。接下来是两个部分,解释了该想法的主要好处以及如何使其在实践中起作用。本书易于阅读,因为每个想法都在3-4页上展开,并将用户故事概念与作者的实际见解相结合’在敏捷软件开发项目中拥有丰富的咨询经验。您可以顺序阅读本书,或探索更适合您当前情况的想法。

我会向所有需要引荐和管理需求的软件开发人员推荐一本书,《改善用户故事的五十个快速构想》,无论它们是否是用户故事。本书所包含的哲学和思想具有远远超出敏捷软件开发的价值。

参考: Gojko Adzic和David Evans,《改善用户故事的五十个快速构想》, http://leanpub.com/50quickideas

网站: http://www.50quickideas.com/

五十个改善用户故事的快速构想

行情

放开模板并尝试使用不同的格式可以帮助改善讨论。这也有助于防止虚假故事。仅出于此目的而遵循模板是建立货物崇拜的好方法。这就是“作为交易者,我想交易,我想交易”和“作为系统,我想要…报告”等故事的来源。

MoSCoW模型将功能分为“必须拥有”,“应该拥有”,“可能拥有”和“想要”(确实不会),这似乎仍然是对工作项进行优先级排序的标准方法。我们经常看到与客户合作的这种模型的最大问题之一是,大多数项目最终都在“必须拥有”类别中。许多团队遭受优先级一个悖论的困扰:利益相关者被要求确定优先级最高的项目的压力越多,他们越害怕将任何东西排除在该类别之外。

如果业务利益相关者对迭代交付没有经验,则基于用户故事的计划通常会变成意识流。无论如何,故事甚至会从特色创意中得到逆向工程。普遍的结果是,利益相关者感到他们不断取得小的改进,但是交付团队没有能力实现任何大的改进。

技术讨论很重要,但不一定要与有关用户故事的业务角度的讨论同时进行。除非您的业务用户也是程序员,否则将这两个讨论分成单独的,更有针对性的会议