一种新的软件生命周期模型

发表于:2009-12-04来源:作者:点击数: 标签:模型软件生命周期
拉动的力量:一种新的软件生命周期 IT项目的起因很多,但是只有一部分软件能够带来真正的改变。软件 开发 是昂贵的,在预算紧张时,把钱花在刀刃上就变得异常重要。 在这篇文章中,我们将要看到如何把来自精益方法的看板,与来自行为驱动开发的特性注入模版

  拉动的力量:一种新的软件生命周期

      IT项目的起因很多,但是只有一部分软件能够带来真正的改变。软件开发是昂贵的,在预算紧张时,把钱花在刀刃上就变得异常重要。

   在这篇文章中,我们将要看到如何把来自精益方法的看板,与来自行为驱动开发的特性注入模版结合在一起,来帮助我们识别最重要的软件,在开发的各个阶段中消除不必要的浪费,用最少的产出来完成目标。

  下面的图显示了本文所讲述的新的软件生命周期。这些产出物给每个角色发出信号,促使他们创建更多的产出物,直到完成目标并获得商业价值。

  最有价值的软件是还没有写出来的软件

  Dan North将软件与金属进行了比较。“生成报告”,他说,“就像铅。很容易得到,还很便宜。但同时也很重,没什么价值,还会拖你的后腿。开发人员耗费大量 时间编写报告软件。为什么不直接买一个、安装上、做一点修改,这样不是也行么?或者使用Excel。除非你是一家销售这些软件的公司,否则不要花钱来构建 报告软件。

  “还有些软件是比较难做的,需要配置并与第三方交互,但你还是可以购买。这就像铜”。他谈到了子域(subdomains)支持,这个词来自于Eric Evans的《领域驱动开发》。这就好比一个核心业务是寻找石油的公司,“他们需要GPS系统。虽然不是每个人都需要这样的系统,但是他们需要,而且还有 很多人也需要。那么你可以购买GPS系统,然后集成到你的系统中”。

  “因此”,我建议,“如果你有类似的需求,而且这种需求对谁都是一样的,但是还没有人卖,那么你或许希望能有人帮你做一个这样的产品。”

  “当然。”他在卡片上写道:

  
LEADCOPPER

  Dan说:“这个是铅。我跟CIO们谈谈,问问他们花了多少钱在这上。太多了!”

  “那么上面是什么?”我问道。

  “上面(左上角)是能快速带来价值的东西。我们有一些软件,它们很容易构建,而且涉及到你的核心领域。这是Agile实验项目的理想目标,可视的、高价值的项目,而且没有人做过。本质上来说它们是差异化的。它们有价值,它们是黄金。”

  “然后是右上角,这个象限是白金项目。它们很难做,是核心领域,充满风险而且可能需要和第三方进行交互,非常困难的交互,它们是有价值的差异。”

GOLDPLATINUM
LEADCOPPER

  David Anderson定义了四个商业关注点:商品、差异、节约成本和破坏者。“这是必然的”,我说,“总会有人破坏你的这些差异性-你的黄金和白金项目。他们 会盗用你的创意-不需要承担你所承担的风险,因为他们看到它确实可以使用-然后用更低的成本实现。这就是为什么我们需要敏捷,未来的某一点我们必然要改 变,来创建新的差异。”

  Dan笑着说:“Chris Matts认为,构建软件只有三个原因:赚钱、省钱、捂钱,这第三个原因非常有意思。LastMinute.com是一个典型的例子,他们通过与供应商签 署排它性协议赢得了所有的市场-剧院、休闲以及任何他们认为具有最后期限,而且人们可以在到期之前取消的东西。回想起来,LastMinute的想法是显 而易见的,但当所有人都来分一杯羹时,逐渐缩小的投资回报导致只有很少一部分人能够坚持下来。

  “当然,白金项目成本会比较高,因为他们很复杂,但从这个角度看,它比黄金项目更有价值。”

  “好的”,我说,“因此,理想情况下,我们应该每周或每两周就发布新的软件版本,我们需要快速响应商业需求。当然,我们知道有些人会破坏我们的东西。因此 为了保护我们的钱,我们需要有一个最小商业特性集,它要能使复制的成本非常高昂。而且,必要的复杂度实际上是好事,它能使我们保持不同……至少在某段时间 内不同。创建一些差异,然后保持这些差异,这就是我们的工作范围。”

  现在,我们知道了如何识别重要的目标和它的范围,下面我们该看看如何实现它了。

  愿景促使干系人创建特性集

  一旦识别出愿景,最初的干系人会通过思考所有需要参与的人,来确定项目其他的干系人。然后干系人会考虑他们需要哪些东西来实现愿景。我们通常是用这个模版:

  作为……

  我希望……

  于是……

  我记得Guardian的编辑们使用这种格式,业务分析师们将之称为“讨要功能”。Chris Matts发现了这个问题,“你将干系人放在了最前面,所以他们会考虑那些能证明他们的东西。换一种方式,我们可以将愿景放在前面。这样人们就不会添加和 愿景无关的东西,有助于减少需求范围的蔓延。事情本来就应如此……”。我将他的建议记了下来:

  为了……

  作为……

  我希望……

  特性集对愿景的依赖与开发人员将依赖注入到代码中的方式很相似,并不是因为它是个好主意,而是因为它是必须的,因此有了这个词-“特性注入”。

  有时我们发现,将愿景分割成一些小的目标很有用,它们定义了一个终点,而且总是可以回溯到大的愿景。

  除此之外,那些提出story的干系人并不总是最后会使用它们的人。Captchas-使用难以识别的图形字母来做图灵测试-就是一个例子。“作为 一个用户,我希望有一个captcha,于是……等等,我不想要captcha,这是浪费我的时间”。我们使用模版来写这个story:

  为了……

  作为……

  我希望……

  例如:

  为了防止机器人给我的网站添乱

  作为论坛的管理员

  我希望用户必须要回答captcha才能写注释。

  有些特性甚至跟软件没关系!可能我们的story会包含如培训、物流、网络管理、法律等东西。干系人通常都会有软件解决不了的,或者不用软件解决更好的东西,例如LastMinute.com的排他性合同。当我们考虑愿景时,也需要考虑这些。

  这些故事通常会很大,以至于开发团队无法处理或估算。Mike Cohn将之称为“themes”,而特性驱动团队称之为“特性集”,我们也这样称呼它们。

  每个特性集的输出-例如,别让机器人来烦我-可能不能只依赖一个特性或者一个干系人来实现,我们会在过程中发现,其他的特性集可以实现或帮助同一个产出。当这种情况发生时,我们会再次审视一下我们的特性集。

  特性集促使BA(业务分析师)创建用户故事

  Chris Matts有一个理论。“你知道人们想要什么么?”

  “想要什么?”我问道。

  “他们向你要求的。你知道他们不想要什么么?”

  “不想要什么?”

  “你希望他们要的。你知道还有什么么?”

  “还有什么?”

  “一旦他们得到了他们想要的,他们就会要的更多。”

  从多年尝试瀑布模型的经验中我们得出,我们很少能够事先预知所有的事,试图在一开始就做对是不完美的。干系人想要一些不同的东西,当我们终于将事情做对了,他们又开始要更多的东西了。

  通常,我们在用户故事和特性集上做决定时所处的环境,会随着时间而改变,特别是在项目的生命周期内。唯一能让我们知道我们对项目的理解是否正确的方 式就是尽早得到反馈。得到反馈最好的方式,是给干系人一些他们可以实际操作的东西,他们可以体会用户或其他消费者的体验,并调整他们最初的想法。

  为了达到这个目的,我们可以先拿掉与愿景实质上不想干的东西,即时它是发布商品或者保护差异的最小特性集的一部分。例如,对于购物车我们只有固定的送货费。修改送货选项或者大宗商品折扣可以放到以后的story中。

  考虑大多数在线商店都会有类似的特性集:

  为了能销售更多的商品

  作为网络销售的头

  我希望消费者能够在线订购商品,并能收到商品

  它可以被分解为多个用户故事:

  为了能销售更多的商品

  作为网络销售的头

  我希望消费者能够订购商品

  为了能销售更多的商品

  作为网络销售的头

  我希望消费者能够将商品放在篮子里而且能够订购篮子(里的商品)

  为了能销售更多的商品

  作为网络销售的头

  我希望消费者可以修改送货选项

  为了能销售更多的商品

  作为网络销售的头

  我希望当(消费者的)订单超过一个最小值时,提供免费送货

原文转自:http://www.ltesting.net