Scrum敏捷项目管理

关于需求和用户故事的小书

用户故事可以被认为是管理敏捷中需求的最常用形式。但是,就像通常在理论上看起来很简单的敏捷概念一样,在实践中使用它们会产生许多问题:用户故事应包含哪些内容?它们何时应准备好开发?最佳积压量是多少?艾伦·凯利(Allan Kelly)在他的有趣的《关于需求和用户故事的小书》中讨论了这类问题。

关于《 艾伦·凯利的需求和用户故事》的小书探讨了 用户故事 和敏捷性要求。从商业价值到 非功能性要求,从理想的积压量到接受标准,每个主题都在3-4页的部分中进行了清晰的讨论,使阅读和掌握变得容易。关于需求和规范之间差异的文章以及用户案例FAQ完善了本书。

我向所有在敏捷软件开发环境中工作的人推荐这本书,因为这是每个人都关心的话题:产品所有者,Scrum管理员和开发人员/测试人员。在传统项目管理组织中工作的业务分析人员和项目经理还将在本书中找到有关需求启发和管理的深刻见解。

关于需求和用户故事的小书

参考: 关于需求和用户故事的小书–在敏捷世界中对需求的启发式 艾伦·凯利, http://leanpub.com/userstories,ISBN 978-0-9933250-5-2

使用折扣码以50%的折扣购买这本书“ScrumExpert” or the link //leanpub.com/userstories/c/ScrumExpert

行情

许多传统的需求工程和启发技术在敏捷中仍然有效。只是结果并没有包含在大文件中。敏捷强调即时的需求,而不是预先准备。需求人–是产品所有者,业务分析师,产品经理还是其他人–体现了对所需内容的理解,而用户故事则代表了需要完成的工作。

对于用户故事,我有两个黄金法则。首先是每个故事都应该对业务有利。理想情况下,它应该带有价值说明-当然,并非所有收益都具有财务价值,因此,谈论业务收益胜于业务价值更好。第二个黄金法则是:每个故事都应该代表一小部分作品。虽然很难定义“小”的大小,但基本上,这项工作应该可以在某个时候交付。

团队通常感到困难的事情之一就是使故事变小。毫无疑问,要使工作几天之内就能完成并证明其业务收益是很难的。而且,如果您以前没有做过,那就更难了!验收标准或AC在这里可以发挥作用。每个单独的标准本身都可能是一个故事。

仅将工作量估算值放在故事上,意味着故事选择通常基于最小的工作量或在剩余时间或预算范围内适合的内容。如果不了解价值,那“最大的爆炸”可能最终不会那么赚钱。当开发人员指出提出一个现实的估计有多困难时,事情就变得很实际了。即使没有价值估算,业务代表也会迅速说:“但是,如何在没有成本的情况下进行成本效益分析?”最重要的是,只有对成本和收益都进行了估算,才能进行成本效益分析。

2关于需求和用户故事的小书的评论

  1. 您如何处理非功能性要求,例如内容(例如网页上的确切用语,作为注册过程的一部分发送的电子邮件的内容)?如果未在要求之前提供电子邮件内容,那么开发人员将在PBI上开始工作,何时提供该电子邮件,是否会等待该电子邮件提供给正在进行的开发工作?

1引用和引用

  1. 2018年1月月度报价

评论被关闭。