模板
教程
环境
性能
功能
管理
一种新的软件生命周期模型
拉动的力量：一种新的软件生命周期
IT项目的起因很多，但是只有一部分软件能够带来真正的改变。软件开发是昂贵的，在预算紧张时，把钱花在刀刃上就变得异常重要。
在这篇文章中，我们将要看到如何把来自精益方法的看板，与来自行为驱动开发的特性注入模版结合在一起，来帮助我们识别最重要的软件，在开发的各个阶段中消除不必要的浪费，用最少的产出来完成目标。
下面的图显示了本文所讲述的新的软件生命周期。这些产出物给每个角色发出信号，促使他们创建更多的产出物，直到完成目标并获得商业价值。
最有价值的软件是还没有写出来的软件
Dan North将软件与金属进行了比较。“生成报告”，他说，“就像铅。很容易得到，还很便宜。但同时也很重，没什么价值，还会拖你的后腿。开发人员耗费大量 时间编写报告软件。为什么不直接买一个、安装上、做一点修改，这样不是也行么?或者使用Excel。除非你是一家销售这些软件的公司，否则不要花钱来构建 报告软件。
“还有些软件是比较难做的，需要配置并与第三方交互，但你还是可以购买。这就像铜”。他谈到了子域(subdomains)支持，这个词来自于Eric Evans的《领域驱动开发》。这就好比一个核心业务是寻找石油的公司，“他们需要GPS系统。虽然不是每个人都需要这样的系统，但是他们需要，而且还有 很多人也需要。那么你可以购买GPS系统，然后集成到你的系统中”。
“因此”，我建议，“如果你有类似的需求，而且这种需求对谁都是一样的，但是还没有人卖，那么你或许希望能有人帮你做一个这样的产品。”
“当然。”他在卡片上写道：
| LEAD | COPPER |
Dan说：“这个是铅。我跟CIO们谈谈，问问他们花了多少钱在这上。太多了!”
“那么上面是什么?”我问道。
“上面(左上角)是能快速带来价值的东西。我们有一些软件，它们很容易构建，而且涉及到你的核心领域。这是Agile实验项目的理想目标，可视的、高价值的项目，而且没有人做过。本质上来说它们是差异化的。它们有价值，它们是黄金。”
“然后是右上角，这个象限是白金项目。它们很难做，是核心领域，充满风险而且可能需要和第三方进行交互，非常困难的交互，它们是有价值的差异。”
| GOLD | PLATINUM |
| LEAD | COPPER |
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中。
考虑大多数在线商店都会有类似的特性集：
为了能销售更多的商品
作为网络销售的头
我希望消费者能够在线订购商品，并能收到商品
它可以被分解为多个用户故事：
为了能销售更多的商品
作为网络销售的头
我希望消费者能够订购商品
为了能销售更多的商品
作为网络销售的头
我希望消费者能够将商品放在篮子里而且能够订购篮子(里的商品)
为了能销售更多的商品
作为网络销售的头
我希望消费者可以修改送货选项
为了能销售更多的商品
作为网络销售的头
我希望当(消费者的)订单超过一个最小值时，提供免费送货
