Bruce Wong Blog

非凡的结果始于伟大的问题.

如何组织一场用户故事地图工作坊

前言 用户故事地图通过对话,让不同的角色之间彼此对齐需求认知,发现Gap,增强协作,达成一致的目标。在产品开始动工前,可以说是成本最低的一种假设推研的方式,能够更早地发现不合理或者遗漏点。这也是为什么用户故事地图成为Product Owner工具箱中必备的工具。那么如何用好这一利器呢?今天就给大家介绍一下如何有效的组织场用户故事地图工作坊。 工作坊步骤 参与的人员 如果团队较小(5~9人...

增强团队协作,洞察真实需求,研磨优良产品

一次用户故事地图之旅

背景 最近公司在一个新的领域准备投入研发。前期的概念海报宣传尝试,得到了不错的反馈,感兴趣的客户咨询络绎不绝。这说明市场潜力很大。所以公司希望在年底前能够有一个可以投入市场的可用的产品,尽快验证市场反馈。在这个背景之下,是否业务、BA、Team已经目标一致准备大干一场了呢?我打算用一次用户故事地图工作坊的方式来验证一下。 什么是用户故事地图 用户故事地图是使用可视化方法把你的软件整体需求呈...

用户故事信息过多或过少带来的问题

来自Mike Cohn大师的建议

前言 上一篇文章介绍了用户故事拆分的5种方法,拆分故事需要足够的信息才能让PO或者团队来进行合理的拆分。所以Mike大叔给PO的意见是:“写用户故事就是在正确的时间给团队刚刚好的细节就够了”。而在实际中每一个用户故事所带的信息多少是参差不齐的,过少肯定不好,而过多也会带来一些问题。在本文,就让我们跟着Mike大叔的讲解探讨一下用户故事信息过多或过少带来的种种问题吧。本文是结合Mike的视频的...

五种简单高效的拆分用户故事的方法

来自Mike Cohn大师的方法

前言 最近在ScrumMaster的工作中收到团队成员的提问,如何拆分(User Story)用户故事,如何让迭代中的用户故事更适合在迭代中开发交付?我们知道好的用户故事要符合INVEST原则,而往往在实际操作过程中最难做到的是最后两点Size Appropriately和Testable。有时候一次迭代只能做一个用户故事;有时候可能有多个小的用户故事,但是彼此依赖要到最后时刻才能测试,可见...

我们需要软件工艺

《软件工艺》读后感

前言 软件开发并不是一项简单机械的活动,将其看作一种工程学实践是不恰当的。因此,我们需要给软件开发一个更好的隐喻:软件工艺。 上一篇我们提到,似乎一些对生命生死攸关的项目,人们要用一切资源来保证其不出错的项目我们应该使用软件工程的方式工作,那么一些出错代价较低的软件呢?似乎我们大量的软件项目都是这一类型的项目,我们应该用什么来对待呢? 答案是:软件工艺。那么接下来让我们来了解一下软...