I code it

Code and Life

Thoughtworks Immersion Day 2

日常开发中,我们经常遵循的实践是,使用用户story来划分并确认需求,每个story有一个对应的点(point)。一般来说会将story写在一张卡片上,而很多的story卡会贴到墙上,不同类型的卡可能会用不同的颜色来标注:

2012-07-17 08.47.27

而一般书写用的笔会很粗,这样就导致能写在卡片上的信息不会太多,但是又有一些关键信息。这样做的好处就是驱使开发人员尽量频繁的与客户沟通,确认需求,而又不至于在沟通是lost context。

用户story只是一种确认需求的方式而已,如果一种形式能够做到:

  1. 回答Why(Feature的商业价值)
  2. 回答What(Feature做什么)
  3. 可管理

那么需求就已经清晰了,不过实践中,我们恰好比较喜欢用户story这种形式而已。另外一个比较容易误解的是估点,比如一个点对应一对pair/天等。事实上,点是一个相对的概念,先将一个迭代(一周-两周为周期)中需要做的需求分割成小的用户story,然后找出一个比较容易估计的作为基准,然后将其他的卡片与此卡对比,如果大家都认为更难一些,那么就从候选数列中选出下一个数字来作为它的点数,反之亦然。通常我们采用的数列是斐波纳契数列(1,2,3,5,8),但是5个点并不是说比1个点的卡难做5倍(需要投入5倍的人力,时间),只是说这张卡比1个点的卡更难做,也比2,3个点的卡更难做,仅此而已。

如果你愿意,完全可以在你的团队中采用其他的表示方法,比如我最近读到一篇博客讲述可以使用自行车,摩托车,小汽车,卡车等来估点。这样可以避免人们对数字长期以来建立的计算关系。

一般会将一个业务流程绘制出来,然后根据这样的原则进行分割:

  1. 每个story应该可以独立交付
  2. 每个story应该具有商业价值,对用户可以带来好处
  3. 尽可能的不要依赖其他story
  4. 尽可能的小,这样才能被管理

我们的课堂作业是模拟网上购物的流程,绘制流程图,切分story,估点。每个小组都有10分钟的brain storm时间,然后大家一起来写卡,很有意思。

2012-07-26 11.45.15

下午的培训是将上午讲解到的知识点巩固,但是形式非常有趣,每个组都分配一个客户,客户提出一些需求(用乐高来完成一个小怪物),然后小组按照用户story来估点,排优先级,然后分成pair来进行开发,过程中要不断的和用户确认需求,做的过程中让客户参与进来,不断改进。在前两个迭代中,我们遇到很多问题,但是很快做出了调整。

到第三次迭代之后,我们已经基本做出了用户接受的产品:

2012-07-26 16.55.11

感受比较深的一点是:

  1. 要相信自己的term,
  2. 沟通非常重要,不论是对内还是对外
  3. 积极与客户协商(好产品会使双方都受益)

关于这种培训,经常听到一个令人不舒服的词是“洗脑”,没有人的脑可以被别人洗掉。不过话又说回来了,如果非要称其为“洗脑”的话,这次“洗脑”非常成功(虽然我更喜欢称其为“洗礼”),我们都很喜欢这种形式,这种高含金量的“洗脑”过程,而且大家都很享受这个过程。

Comments