• 2009-08-08

    “不适”的敏捷

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/43760538.html

    敏捷,这个词汇越来越热,越来越多的团队“敏捷”起来,但随着敏捷的应用到不同的场景,很多之前驾轻就熟的实践,就显现出诸多不适。

    在敏捷开发中,最常用来管理需求的方法是User Story。Story除了捕获需求之外,还有一个很重要的角色,就是划分任务,这也符合人们解决问题时通常分而治之的习惯。Story划分有一个重要的原则:INVEST,其中的S,是Small。Story太大,人们是无法看清的,无法估计,即便可以开发,程序员也要花费大量的精力了解这个Story。

    我们在公司内部做项目时,User Story屡试不爽。所以,当我们扮演咨询师时,我们自然会引导客户以同样的方式管理需求。根据我们划分Story的理念,我们要找一个端到端的交互,结果,我们发现,无论我们怎么划分Story,每个Story都无法满足Small的要求,随便一个Story就会有几十个点。

    本着分而治之的理念,我们会把这个Story划分为一个个Task。直到每个Task都小到可以开发的程度。在当时的环境下,这种做法得到了大家的接受。但是,这种做法是有悖于我们对Story的理解,而且从实施的效果上来看,经常出现很长时间无法完成一个Story,所以,项目组内的测试人员无事可做。问题究竟出在哪呢?

    我们使用User Story处理的系统,大部分是存在大量交互的系统。而我们客户是一个通信系统,按照交互来看,可能并不多,但每次交互内部都要进行一大堆处理,这也是为什么Story都很大的原因。

    对于这样的系统,使用我们理解的Story是不是合适,就成了一个问题。不过,换个思路,我们就会发现,在这个情况下,我们真正需要的是分解问题,分解到可以由程序员可以进行开发,就像我们前面提到的Task。至于到底分解的结果还叫不叫Story就不那么重要了。当然,随着分解的结果的改变,还会引发很多问题,比如,怎样衡量工作是否完成,项目组内的测试人员应该做怎样的工作等等。

    这只是一个例子。

    分享到:

    历史上的今天:

    大龄程序员 2015-08-08
    引用地址:

    评论

  • story的“端”在当前domain里如何定义也是一个思路,我就觉得“端”不一定非得到用户。
  • “每次交互内部都要进行一大堆处理,这也是为什么Story都很大的原因”
    Story是End-to-End并不代表,这一次交互内部的一大堆处理都要包含在“一个 ”Story内。