实例化需求，软件外包质量管理的神器
作者简介：
Ruddy Lee（李智桦）老师
DevOpsDays北京站金牌讲师，台湾著名精益布道师，敏捷专家，著有《精益开发与看板方法 》。
一个经常被问到的问题：「实行敏捷，遇到大量委外开发（外包）时，怎么办？」
实际上，你唯一能作的就是持续的做验收测试，用来保证厂商所交付的功能是否仍然符合你的需求？
但是，当你运用“实例化需求”的解决方法时，你将会变成努力的在维护文件系统与程序的同步性，并依靠一个由文件触发的自动化测试系统，来持续的验证并维护这个活文件的系统（一般而言，我会建议采用FitNesse来维护你的活文件系统）。
注：明确描述的文档与程序同步，即活文件 living document
采用「实例化需求」的最大好处，就是能够持续做到自动化测试，并明确的运用文件上可自动化验收的测试用例数据，做到测试与文件同步的效果。
运用活文件来守住委外厂商所交付的功能程序还是不是好的？ 是否还能够正常工作请参考“ 实例化需求”（注1）一书第三章一开始的说明：
“一般认为实例化需求说明的过程和工具有二种流行的模型。以验收测试为中心的模型及以系统行为规范为主导的模型。
以验收测试为中心的模型，就是A-TDD也就是验收测试驱动开发 ，侧重于自动化测试。并把它作为实例化需要说明的一部分。他的主要优点是使开发目标更为明确，并且可以防止功能退化。
以系统行为规范为主导的模型，通常称为行为驱动开发 ，也就是BDD。其侧重于制定系统行为的场景。它的主要工作是透过协作与需求澄清，在项目干系人和交付团队之间建立共识“。
因此如果企业拥有大量的委外开发商的话，一个好的持续进行验收测试的方法，就是实行A-TDD（注2）就是验收测试驱动开发，让公司内部的人员守住文件的正确性，并让它能够与厂商开发的程序持续同步，你能够运用的方法正是由ward Cunningham所创创的FitNesse（它们在http://www.fitnesse.org/ ），目前的维护者 49 30306 49 14987 0 0 1796 0 0:00:16 0:00:08 0:00:08 3133 49 30306 49 14987 0 0 1542 0 0:00:19 0:00:09 0:00:10 2978 49 30306 49 14987 0 0 1398 0 0:00:21 0:00:10 0:00:11 3229 49 30306 49 14987 0 0 1279 0 0:00:23 0:00:11 0:00:12 2860 49 30306 49 14987 0 0 1178 0 0:00:25 0:00:12 0:00:13 2927 49 30306 49 14987 0 0 1125 0 0:00:26 0:00:13 0:00:13 0著名的Robert C. Martin ，Micah D. Martin，Patrick Wilson-Welsh等。
我每隔几年就会与它相遇一次，同样是采用SBE（Specification By Examples，实例化需求），但我总是会采用验收测试的FIT架构，而没有使用更适合内部开发采用的BDD（Behavior Driven Development行为驱动开发），这一点并非我有所偏好。实质上是我碰巧都遇到处理委外的问题所致。实质上，该采用那一种解题法呢？ 就要依照要解决的问题种类来作判断了。这二种方法要用对场合了，才容易有功效。因为它们都有相对需要付出的维护作业负荷。
FitNesse的 架构（参考自www.fitnesse.org）
指的是我们持续维护的活文件系统 （ 一个Wiki Pages系统 ） 。
指的是委外厂商所开发的系统。
是让我们可以定制化用来诠释实例化表格的方式，以及要调用到的功能名称的界面程序，称为Fixture。
中间核心的部分，分成上半段的 FIT（ 旧有的整合测试功能引擎 ） 及下半段的 SLIM（Simple List Invocation Method新开发的引擎 ） ，网站上有描述旧有的整合测试功能引擎 FIT 因为复杂性较高，维护的负荷逐渐变大，才有新引擎的出现。
而你要做的工作，便是把文件写在Wiki Pages上，然后把测试用来加进来，并运用指定Fixture的方式来指定要测试的程序的功能名称，并预先把调用此功能的参数及预设回传值设定在测试案例的表格里接着;就可以持续进行自动化验收测试了（ 请参考http://www.fitnesse.org/的范例 ）。
图的下半部是一个Fixture的范例。
所谓「简化」意味着团队一开始就应该采用一种刚好足够（勉强足够）的方法。
实例化之前一定要制定「简单化 」的守则
采用实例化需求之前的共识，团队需要拥有「简单化」的共识。因为文件这个东西，往往会因为撰写人的追求完备性而慢慢的走向于越来越复杂的不归路上。
我推广“实例化需求”时最常听到的一句话， 就是「我们的文件系统要比你所展示的文件复杂太多了，如果再把测试的案例，还有那些表格加进来，那还得了... 」。
是的，如果要实行实例化需求的活文件系统的话，首先要订的策略就是尽量的维持简单化。
这一点，就好比维护单元测试的程序一样，如果测试程序多到需要相当的维护负荷时，就有可能会产生喧宾夺主的情形，也就是维护测试程序的负荷要重于维护主程序的现象，这时候当然就应该要丢弃测试程序的时候了。
为了要避免这种情形，简单化就是最需要遵行的法则，才不会白忙一场。
结语
虽然大家都知道，要建立与委外厂商之间的共识才是重点。是的，建立互信是合作关系的基础，但有趣的是，信任往往是由不信任开始的。
第一次合作的厂商一定是建立在不信任之上，慢慢的由于越来越多的接触，彼此开始产生了解而逐渐建立互信的立场，实例化需求可以成为互信的一个开始。
过往的经验里，厂商往往在获知你即将采用FitNesse的验收测试系统时，会主动的在自己的开发环境里也建立这样一个系统，并要求经常跟你的文件系统进行同步，这是一个负责的厂商往往会透过实例化需求的过程来建立与客户之间的互信立场。
因此实例化需求往往不只换来可靠的测试系统，更容易的是可以看出协作厂商的可信任度。
注1。 实例化需求Specification by Example:How Successful Teams Deliver the Right Software为2012年JLOT震撼奖的得奖作品，作者是Gojko Adzic，为塞尔维亚人。
《实例化需求：团队如何交付正确的软件》是在世界各地调查了多个团队软件交付过程后的经验总结。
它介绍了这些团队如何在很短的周期内说明需求、开发软件、并交付正确的、无缺陷的产品；为团队在实施产生实体需求说明时使用的模式，想法和工件创建了一致的语言;展示了案例中的团队用来实现产生实体需求说明原则的关键性实践;并在案例分析部分展示了一些团队实施产生实体需求说明的历程。
适合与项目管理、开发、测试、交付有关的人员阅读。
注2。 ATDD所指的是验收测试驱动开发，一般所谓的TDD实际上可以加注为UTDD。 U是UNIT的意思，它明确的指向进行单元测试驱动开发，但很少人这么用。
您在外包（委外）管理中遇到过什么问题？欢迎留言，大神和你一起来解决。