敏捷 - 用户故事定义

我正在为我朋友的业务编写一个小应用程序,并且我想借此机会了解我在年初时所做的一些敏捷项目管理培训.

我(我认为,我现在的组织!)一直在努力以用户故事的形式收集需求,其形式如下:

作为[用户类型]我想要[功能]以便[一些好处]

我总是想要错过开始和结束,然后离开这个功能 - 但这就成了收集旧方式的要求!

但是我不想让它变得合适,所以我可以说'我正在做敏捷'......例如,如果我知道用户将被呈现一个项目列表,那么原因不言而喻,不是吗？

例如

作为[商店经理],我想[查看库存商品列表]以便...？

通常的做法是省略[so that]条款吗？

我们过去常常错过它.把它留下来我们错过了很多.要正确理解这个特征而不仅仅是做正确的事情,而是做正确的事情,知道为什么这个特征是关键,并且下一个关键是WHO(角色)在DDD术语中,利益相关者.利益相关者可以与众不同,每个人都在乎.从程序员和数据库管理员到所有类型的用户.

所以,首先要明白,谁是利益相关者,然后你知道他关心的50%,然后是利益,然后几乎已经明白了实施的内容.

尽量不要只写"作为用户".指定."作为商店经理",甚至"作为负责结束这一天的转变的领导",我需要....所以....

也许你可以实现不同的东西,这将给予同一个利益相关者更好的利益!

尝试,实现[商业价值]作为[用户]我需要[功能].

目标是专注于功能提供的价值.它可以帮助您在垂直切片中进行思考,从而减少不可见的纯"技术任务".这不是一个简单的过渡,但是当你开始垂直思考时,你开始真正能够减少过程中的浪费.

另一种方法是考虑客户可以编写的验收测试,以确保该功能可行.这是一个短暂的跳跃,然后使用FitNesse之类的东西来自动化这些测试.

不,它实际上并不明显 - 有很多理由希望查看列表,您可能想要使用它的许多内容 - 扫描一些信息,获取概述,打印,复制并粘贴到究竟是什么,它将为您提供有关合理实施细节的宝贵提示 - 列表格式,确切内容; 或者甚至暗示一个不同的特征可能是满足这种需求的更好的主意.不要惊讶地发现原因实际上是"我可以计算参赛人数"......

当然,这可能实际上不适用于您.事实上,我的实际观点是有人提出这个模板的理由 - 而且还有很多有经验的人没有真正使用它的原因.当你不熟悉这种做法时,你不能很好地评估遵循练习的所有优点和缺点,所以我强烈建议你试着密切关注它一段时间.你可能会对它的用处感到惊讶 - 或者不是,在这种情况下你还是学到了什么东西,并且可以用简洁的方式删除它...... :)