本文目录导航：
制造业产品开发中运行矫捷Scrum的思索 （下篇）
上篇作者作为一名机械制造业的从业者，繁难引见了矫捷Scrum，并分享了一些对Scrum理念的了解。
下篇以制造业产品开发中运行矫捷Scrum的思索启动了一系列的分享。
点击链接浏览：矫捷Scrum理念的面前—写给机械制造行业同仁（上篇） 作者 : Sven Fang 房世庆 Scrum配件及制造业专家 德国杜伊斯堡艾森大学机电工程专业博士 似乎IT行业，制造业也面临着越来越严格的应战，市场要求企业能够做到更快的产品降级，更低的老本和更高的品质。
在IT行业日益获取推行的矫捷Scrum框架给制造业的产品开发带来许多启示。
不少企业曾经开局尝试扭转传统的瀑布式产品开发形式，运行矫捷Scrum框架以极速顺应市场变动，控制危险和提高客户满意度。
本文在思索国际制造业特点和目前状况基础上，就如何运行Scrum框架和理念表白作者的一点高见。
这里假定读者曾经领有矫捷理念和Scrum框架的基本常识。
1制造业产品开发的运作方式 图1普遍驳回的产品开发名目流程 这里所说的制造业是狭义的制造业，区别于软件业，以“物理”对象为产品，如机械，仪器，仪表，工具，汽车业，家电等等。
在软件业，习气把一切非程序类产品称作“配件”。
为防止和PCB板之类的配件电子产品混杂，咱们这里没有用“配件”一词。
制造业悠久的开展历史，沉淀了百年的阅历，很多商定俗成的理念和方法源远流长。
“现代”产品开发的运作方式受泰勒（Frederick Taylor）和法约尔（HenriFayol）的思想的影响，驳回“瀑布”(或称 “串行”)式的方式，高度注重方案、分工、职权和控制。
其实产品开发的理念及流程和改革前的软件行业没有实质区别。
以汽车零部件行业为例，产品开发是一个方案性环节控制，普通产品开发都以名目方式治理，名目经理对名目的老本、进展以及交付担任。
在产品开发前，客户和企业就产品需求以合同的方式固定上去，从明白的需求开局，制订开发方案，分工开发组件，集成后测试，解冻设计，模具监禁，工艺方案设计及实施，样件，最后批量消费。
（如图1所示）。
关于产品换代缓慢，大规模消费的时代，这是最适宜的方式。
当天的环球曾经不是昨天的环球了，为谋求更高利润，单纯地扩展规模以降落老本曾经不够，市场竞争压力越来越向产品开发部门转移。
传统的基于方案的开发理念和运转方式关于那些必定开发复杂产品（复杂产品未必结构复杂）以提高市场溢价权的企业来说，很或者造成企业的消退。
面对更多不确定性的当下环球，大家都看法到下列疑问必定处置： -部分优化是不够的，必定以系统思想开发产品 -仅有开售部门面向客户是不够的，必定面向客户开发产品 -再完善的开发方案都赶不上变动，必定拥抱变动 -再专业的名目经理都是不够的，必定要团队协作 -等等矫捷理念下的Scrum框架，驳回跨职能团队、迭代增量、继续可交付产品等方法为咱们提供了这种改革的一种或者。
2矫捷Scrum在制造业的通常 这里要提到的是，其实机械制造行业很早就接触并运行了矫捷理念。
作者以为，大家相熟的“精益消费”理念其实就是矫捷理念的源头，甚至矫捷理念下Scrum的构思也来源于制造业 [Kenneth S. Rubin, 2012]。
从“精益消费”理念扩展而来的“产品生命周期治理”（PLM）、“并行工程”(Concurrent Engineering) 曾经被一些企业自觉或不自觉地运用到产品开发中[熊光楞主编，2011]。
所谓“并行工程”旨在整个开发上班都着眼于整个环节和产品指标，防止传统的“串行”开发形式带来的弊病，其中不少中央如“跨职能团队”，“产品导向”都能看到和矫捷Scrum相似的宗旨和方法。
矫捷理念下的Scrum框架繁难，有其独到性，这也是为什么在软件界获取迅速的认可和遍及。
虽然传统制造行业的产品开发和软件行业有所不同，但Scrum在软件行业运行的成功使得配件及制造业的治理者们开局尝试在本行业的运行。
走在前面的是那些蕴含嵌入式软件的供应商以及一些仪器设施供应商们。
而后缓缓加长到纯机械制造行业。
正如Rubin提到的：虽然 Scrum 最罕用于开发软件产品, 但 Scrum 的中心价值和准则可以而且正在被用于开发不同类型的产品或组织不同类型的上班流程。
例如, 我曾与成功经常使用 Scrum 的组织协作, 以组织和治理与配件开发、营销方案和开售方案相关的上班。
[Kneneth S. Rubin, 2012]这里咱们罗列两个业界的例子，可以说是基于矫捷Scrum框架启动的产品开发。
2.1波音777的研发 波音公司从1990年概念设计开局到1995年5月在联结航空投入商业经营，在6年里成功成功了一个50亿美金的新产品波音777开发名目，介入员工达1万多人。
名目担任人 Alan Mulally翻新地运用的“一同上班”形式其实表现了矫捷理念。
Mulally组织起了约250个多配置团队DBT（DesignBuild Team），每个DBT团队担任一个配置模块。
每个DBT都由综合多样的人员组成，可以成功从概念到制造和保养。
团队中有设计，制造，模具人员，财务，资料，保养，分包合同代表，客户代表。
一切DBT每周进展例会保证团队之间的沟通协调，为进一步做到透明开明的沟通，他将波音777的一切个员工每个季度都会集到西雅图，开为期两天的all-team meeting！这样的会议在30个月里开 了9次（见图2）。
匪夷所思！ 图2. 波音777及西雅图大会。
Source:关于那些小的日常的变动，DBT多配置团队会来处置新涌现的消息，并在制造和设计工程师之间构成极速的反应循环。
需求变卦以往要求消耗几周，然而在DBT团队一天就可以搞定了。
当你可以极速协作，应答变动就会变得更容易。
777是简直齐全经常使用三维CAD软件替代二维图纸设计的第一架飞机。
在建造第一个原型之前，3D CAD模型就可以组合在一同启动实时验证。
这就放慢了反应闭环的构成，增量的品质也有必定的优化，从而能够更早更好地获取反应。
波音经过许多动作让客户介入到开发中来，并强和谐客户的协作高于一切。
由于客户的介入，客户极速反应，团队可以及时照应变动而非无条件遵照方案。
在这里Scrum框架的跨职能团队、迭代增量等均有表现。
较详细资料请参见“Agile at Boeing in 1990s – the 777 Program” 链接：以及唐怡佳的“配件矫捷先驱——波音777案例剖析”；链接：2.2Wikispeed 图3. Scrum in Wikispeed, Source:提到矫捷Scrum在制造业的运行，大家都情愿拿Wikispeed举例。
Wikispeed 是一个汽车制造组织，它经常使用面向环球开源（OpenSource）的方式制造有上路容许证的节能汽车。
它的员工由散布在全环球20多个国度的近200个被迫者组成，用户可以在网上订购从环球不同中央消费的9个模块组件组装成定制的汽车，目前，可选汽油机或电动机为能源。
Wikispeed曾经运用Scrum框架在3个月内开发并制造出一辆原型车。
Wikispeed 的开发特点可以总结以下三点[Shantam Shukla,2013]：-开源设计 如咱们以前熟知的Linux系统的开发，Wikispeed的团队开明资源，吸引全环球的造车喜好者参与到开明中，被迫者们大多应用闲余期间介入团队并成功部分上班。
-模块化及测试驱动开发 Wikispeed团队将整个汽车分红8个模块，每个模块由来自环球各地的一个或多个团队被迫者担任开发，成员普通是该畛域的技术专家或喜好者。
为了成功开发和组装的灵敏性，为每个模块定义了“通用”接口，以成功即插即用的理想。
虽然模块化设计造成模块内的冗余，或者会造成部分老本的参与，但思索到客户的多样性和灵敏性的要求，以及Wikispeed 开发组织的特点，从系统角度思索，这是个理智的选用。
关于每个模块的开发, 团队最开局先构建了关键的测试要求。
例如， 一个从事底盘设计的团队可以以任何方式开发它, 直到它满足最后的测试要求。
-Scrum框架组织开发 动员人JoeJustice是软件工程师出身，用闲余期间开发并制造一辆汽车关于他和他的团队来说是充溢不确定性和应战的名目。
由于是开源的方式，为了治理和协调来自不同地域、始终壮大的志愿者团队，他和Wikispeed的其余成员经常使用Scrum的准则协调散布式虚构环境中的开发。
开发团队承当Sprint的义务, 并尝试在7天内成功预期结果。
Sprint的义务由团队中的产品担任人（Product Owner）定义，并担任定义正在开发的模块测试的要求和参数。
不同的Sprint或者有不同的产品担任人被迫担任，他往往是该Sprint义务畛域最专业的人士。
由于是被迫、开源的方式，团队中没有主管, 也没有说由PO来确定团队义务的优先级。
图 source：[Shantam Shukla,2013]3制造业运行矫捷Scrum启动产品开发的一些疑问 “如何在机械制造行业成功地运行Scrum？”，这个话题太大，触及到的方面太多，一本书的篇幅也很难论述分明,咱们或容许以把疑问分红两类：一方面其实是制造业的人文疑问，另一方面是技术疑问。
所谓人文疑问，是制造业积重难返的传统理念，和许多固化的思索及行为方式。
所谓技术疑问是指：制造行业的产品对象为“物理”实体，在开发环节中会遇到很多和软件业不同的疑问。
但必定抵赖， 有时刻很难辨别是人文还是技术疑问，有时刻外表上看似是技术疑问，其实是人文疑问。
在制造行业运行矫捷Scrum，首先要求深化了解企业，从产品、以后的组织治理架构、组织文明、人员状况等多维度，思索能否适宜驳回Scrum框架以及实施的节拍。
不是每个组织都适宜驳回矫捷Scrum，也不是每个企业的Scrum都是如出一辙的。
3.1运行矫捷Scrum的人文疑问和思索 组织文明 Scrum的成功要求文明机制来保证。
“试图扭转一个组织的文明是愚昧的，它总是以失败告终。
人的行为（文明）是制度的产物； 当制度扭转时人们的行为才会随之而变。
”[Craig larman and Bas Vodde，2016] 而扭转机制要求扭转一个基本的观念：对“人”的观念。
矫捷理念是建设在“如何应用人的后劲”这个基础上的：假设给与时机，人类宽泛具备构想力，发明力；人们会为自己所认可并承诺的指标做出致力，承当责任。
而传统的治理形式是基于假定：人们回避责任，没有主意，本色懈怠。
麦格雷戈在他的《企业的兽性面》中把建设在这两种假定上的治理通常和通常称为Y-X通常。
对“人”的积重难返观念受文明和教育的影响很难扭转，直到当天，咱们国际学校还在按传统的假定（X假定）造就咱们的下一代。
可想而知，矫捷理念的实施和落地在国际将遇到多少艰巨。
传统的对“人”的观念，曾经渗入咱们传统行业每个治理者和被治理者的骨髓。
在驳回Scrum通常中，治理者往往有剧烈的改革看法，宿愿推进Scrum，但他们习气的不经意的“控制”行为往往阻碍Scrum的成功，团体绩效是个“控制”的例子。
从组织治理角度，重构机制，降落治理者的“控制欲”，使治理者成为疏导，教练型角色，给与集体奉献潜能的空间，作者以为是Scrum成功的条件。
矫捷Scrum的驳回提供了改革的工具，但假设没无机制造为保证，只能带来凌乱 （自己也是X假定下造就进去的）。
构想一下，敞开团体绩效取而代之的是团队的绩效，由团队自己选择收益调配，仅仅就是这一点机制的扭转，在国际制造业的人文环境下就很难成功。
由于有各种人文阻力要比软件业更大，Scrum的驳回步骤和规模值得留意。
虽然咱们有波音777的大规模研发中经常使用矫捷理念成功的案例，但团体还是倡议墨守成规地在机械制造行业驳回Scrum。
经过小规模地驳回Scrum，顺应新的思想和行为规范， 最关键的是实验新的文明机制。
Scrum只提供了一个框架，在许多方面它没有提供明白答案，而其余没有说明的，如文明机制却选择了其实效性。
实施Scrum的详细倡议见在章节3.2。
成员状况 对比软件业，咱们不能不抵赖，制造业研发从业人员的平均年龄都偏高，由于各种要素，看待新事物的态度偏激进。
在配件及制造行业，专业化很强。
开发人员往往只具备某项专业技艺，要求多年的上班阅历成为某专业的专家，一专多能较难成功。
在开发中，对这样的专家依赖重大。
这样的状况有时是产品自身特点形成的，有时是传统组织架构常年累积的结果。
在通常Scrum前，一个关键预备是要求企业外部各个层面及集体对矫捷理念，Scrum框架以及其面前宗旨的深入了解。
在此基础上才或者灵敏运用矫捷Scrum以到达目的。
另一方面，在组织中自上而下的推进，自下而上的实施成功率要高些，由于Scrum应战很多传统的思想和行为，会触及到团体或组织阶级的固无利益（非公司利益）。
3.2运行Scrum的技术疑问和详细倡议 探讨了运行Scrum的人文方面的疑问后，上方探讨普遍存在的所谓技术疑问。
产品开发的复杂度 Rubin在他的Essential Scrum 一书里把要处置的疑问分红了5种，并非一切疑问都适宜Scrum框架。
Scrum框架普通较适宜于处置较复杂的、不确定性强的开发，尤其是有很强的探求性开发。
一个以委外加工为主，设计图纸又由客户提供的公司，Scrum很难带来大的扭转。
不少畛域的上班经常使用Kanban可视化治理就能收到很好的效果。
产品的测试环节要求较大的资金投入，并且预备期间及制造周期长 由于产品对象是“物理”实体，相比软件业，制造行业产品开发有如其不凡性。
很多产品的样件往往要求模具，虽然可以经常使用 “软模具”，但依然老本很高。
漫长的制造期间往往成了名目开发周期的瓶颈。
除此之外，模具及样件往往由外部供应商提供，有时还要求思索洽购部门的选用定点期间。
样件制造是名目经理最头疼的一件事。
以汽车零部件企业为例，为了小规模驳回Scrum来提高企业应答市场灵敏才干，介绍在企业的预研发（pre-development）环节先通常Scrum框架。
普通来说， 预研发产品开发是制造企业对前沿技术或工艺做钻研性或探求性的尝试，经过一系列配置等实验验证，并依据客户（也或者是公司外部客户）或市场需求制造出样品，在展览会或指标客户处展现，测试市场反响。
预研产品代表了公司或行业的最前沿技术水平，在获取订单后进一步开发成批量产品。
由于预研产品开发交付的产品是样件，触及的中心职能团队相对较少，比拟容易组织起跨职能团队，普通由设计，仿真，测试等组成即可，产品担任人（PO）可由该产品畛域业务单元客户组成员担任。
这样的规模对企业全体组织的变卦度起码，阻力也相对较小，同时提高了企业新产品的降级换代速度。
在Scrum实施取得成效后，扩展“产品”定义或“产品交付”的定义，组织改革的范围也随之扩展，整个企业的灵敏性，发明力随之加大。
最终做到整个系统的矫捷：从研发到批量供货。
在制造业产品开发中，应用虚构仿真工具增加对实物测实验证的依赖是殊途同归。
咱们前面举的两个例子来说，假设波音公司没有在研发中经常使用 3DCAD 制图，很难尽早发现设计的一些疑问并启动迭代。
现代的技术手腕为矫捷开发提供了更多的“物理”或者性。
3D打印技术，3D扫描技术，各种仿真技术等都提供了强有力的允许（虚构事实技术的实践运用还要等一等）。
目前还存在着仿真的建模期间较长，仿真结果的可信度等疑问影响开发迭代周期，但这都不是制造业拒绝Scrum的借口。
例如，十几年前就有国外汽车零部件企业不借助商业软件成功了3DCAD模型到多体仿真模型的智能建模，将建模期间从数周增加到数小时。
产品的配置触及很多组件，并与其它配置相互交织，配置之间的接口不易定义分明 机械产品中每个配置都或者会影响到一切其余配置。
配置间耦合度高。
而在软件开发中，可以从几个配置和一个繁难的产品开局, 而后再陆续颁布新的配置和降级产品。
这关于机械开发是不易成功的。
外表上或者会给产品待办列表（Product Backlog）的拆分以及各Scrum团队的协作带来艰巨。
实践上，这是个研发思绪疑问，是设计理念疑问。
只要对某个钻研对象能启动充沛的“解耦”，咱们才干说了解了这个对象。
假设咱们设计的产品系统难以被“解耦”，说明最终产品的某种“强健性”（robust）会有疑问。
这点和软件设计开发没有实质区别。
处置这个疑问要求工程通常，在首次驳回Scrum框架时，会破费团队意想不到的的期间去定义Sprint的义务和测试方法，这很反常，由于咱们如今经常使用不同的思绪和角度去了解产品， 如今咱们不再是以产品自身配置成功的角度，而是以面向客户、产品价值的角度扫视咱们的产品。
产品开发要求的外部协作较多，共享资源多，接口多 实体对象的开发要求洽购，核算，样件，测试，物流，品质，消费等部门以及外部供应商们的协作。
各职能部门由于人员，设施的限度，资源由各开发名目共享。
你的名目义务是公共职能部门手里泛滥名目中的一个，灵敏性遭到限度。
如图5所示，是汽车零部件企业典型的组织架构。
图5.以后普遍的组织架构 其实，大型软件开发也会遇到雷同的疑问。
不同的是制造业设施资源等投资大，要求思索共享。
但软件行业不少用于开发的商用软件多少钱也不菲。
共享部门的允许，外部协作无法防止。
如何处置是详细方法疑问而非Scrum框架疑问。
制造业齐全可以自创软件行业的阅历，做些顺应性调整。
假设很难做到真正的跨职能团队，必定经常使用公共资源的时刻，可以思索软件业经常使用的“打桩”（mock-up）的方法，在迭代中尽量降落依赖度。
制造业也经常经常使用所谓的“Dummy”降临时替代还没有成功的部分，以保证研发的继续，随着其余部门上班的推进，增加被设置 Dummy的部分的规模，直到彻底敞开。
团队他乡协作 Scrum强调团队要在同地点上班以繁难随时沟通，但如今跨国协作启动产品开发很普遍，这在软件行业也十分经常出现，但在机械制造行业他乡团队协作的难度更大。
通常阅历通知咱们，假设一个Scrum团队有他乡成员，普通Sprint的长度不易定义偏短，虽然有视频会议，联结开发平台的允许，用于沟通的期间要大幅参与。
有时实物他乡运输期间也要思索在内。
4总结 为了提高企业的市场竞争力，制造业的产品开发齐全可以运用矫捷Scrum框架以扭转由来已久的传统形式。
通常Scrum要求结合自身的详细状况，在深入了解矫捷理念的基础上灵敏地做探求性的调整。
在通常中，最大的阻力是组织内的传统理念，从业人员的理念，而非其余技术性疑问， 至上而下的推进是必要的。
作者以为，组织的机制是选择矫捷Scrum成败的关键。
作者倡议首先在产品先期研发名目上通常矫捷Scrum，而后逐渐推行到整个产品开发。
由于制造业开发的对象是“实体”，消费最终产品的代价高，因此更要求在资金大投入前应用Scrum框架下的迭代增量的方法充沛验证产品的市场价值，加大虚构，极速成型等手腕在研发阶段的应使劲度。
在虚构仿真和极速成型技术日益成熟的当天，机械产品开发和软件开发的差异越来越小。
参考文献 1.熊光楞主编. 并行工程的通常与通常. 2012. 清华大学出版社 Shukla, Wikispeed. Institute of Management, Ahmedabad, India, prepared this case study as part of his doctoral dissertation. () Larman and Bas Vodde. 2016. Large-Scale Scrum: More with LeSS 大规模Scrum大规模矫捷组织的设计. 肖冰 译.2018. . 2012. Essential Scrum -A practical guide to the most popular agile process. Addison-Wesley. 文章查看：Jim Wang王军版权一切，推戴剽窃，欢迎转发。
在软件开发中，精益和矫捷是什么相关？
矫捷给软件企业（以及软件开发者团体）带来的好处终究在哪里？这个疑问有很多不同的答案。
例如“注重团体和交换”，软件开发者青睐这样的态度，这是毫无不懂的。
例如“注重可上班的软件”，它的价值是显而易见的。
但在这一切的面前，矫捷的中心是什么？时下盛行的观念是：矫捷就是软件行业里的精益（lean）消费，它的中心是消弭糜费。
ThoughtWorks中国公司的上层在近日接受采访时明白指出了这一点。
首先思索品质疑问。
一些软件企业为了降落老本而漠视品质，但品质低下的软件会形成返工的糜费，反而提高老本。
雷同，在日常上班中投入更多的精神来保证品质，反而能够为企业浪费老本。
ThoughtWorks中国公司技术总监Michael Robinson用软件工程的经典通常来剖析这个疑问：任何一本软件工程教材都会通知你：假定在剖析阶段找到并解 决一个失误的老本为1，在设计阶段处置同一个失误的老本就变成10，在成功阶段就变成100，在保养阶段就变成1000。
矫捷软件开发中的泛滥通常正是为 了防止低品质和返工的糜费。
虽然它们一开局看起来似乎有些费事，但它们带来的收益是实真实在的。
另一种经常出现的糜费则是“为未来预备的投资”。
例如为了接待未来或者出现的需求变动而提早引入的灵敏设计，假设需求没有出现变动，这些灵敏设计就会成为糜费：不只糜费了将它设计进去的老本，而且糜费了继续保养它的老本。
制造业为了降落库存老本而发明出“Just In Time”的消费和决策方法，ThoughtWorks中国公司总经理郭晓以为这些方法雷同适用于软件行业：如何消弭预测失误的糜费？防止预测失误的 基本方法就是推延决策：决策下得越晚，就越不容易由于预测失准而形成糜费。
当然也不能晚到错过了机遇、耽误了上班才下决策，这就像丰田制造的Just In Time，决策也要Just In Time。
过早的、含有太多预测成分的决策也会形成糜费，其危害丝毫不亚于过晚的决策。
在最近的两篇Blog里，我谈到了一些从更深档次思索矫捷的心得。
在我看来，矫捷的、精益的、适用主义的决策往往是合乎中庸之道的：它们往往是各种要素、选用权衡之后的结果。
矫捷方法极其注重优化客户价值，为了到达这个指标而采取的手腕通常都无法能是极其的。
中庸之道经常有效的深层要素是边沿成效递减律：对一个方面的物品注重到必定水平以后，再参与更多的注重，收到的边沿成效递减；雷同的注重度放到另一个方面上，能够收到更大的边沿成效。
让每一分投入收到最大的报答，尽或者地消弭糜费，这是精益的谋求。
在另一篇Blog里我谈到了如何启动精益设计。
设计方案的选用说究竟应该是一次性老本与收益的计算，而不是团体审美取向的权衡——当然，低劣的程序员能够把这种计算变成天性，我以为这就是“软件开发的艺术”所在。
矫捷方法强调“繁难设计”，雷同是经过计算的结果。
在面对一个复杂并且灵敏的设计时，首先要权衡的不是成功它的收益，而是“如今成功它”与“未来成功它”之间老本的差额。
不论一个灵敏的设计的收益和老本如何，只需这个差额十分小——等到未来成功它也没有什么额外的艰巨，就应该毫不犹疑地推延决策，等到真正要求的时刻再引入灵敏的设计。
感谢现代化的IDEs，很多时刻咱们探讨的这个老本差额确实十分小，这是矫捷设计通常取简单方案的要素所在。
值得留意的是，随时启动这种老本与收益的计算并不是一件大海捞针的事。
计算自身也有老本。
这是最佳通常和工具允许存在的意义所在：你可以用较低的老本获取先人积攒的常识。
例如ThoughtWorks在引见其名目治理工具Mingle时特意指出其中融汇了该公司多年从事矫捷软件开发的阅历：Mingle是一个矫捷名目治理工具。
它为整个团队在软件交付环节中提供“一站”式服务，并经过有10年矫捷名目开发阅历的ThoughtWorks公司提供的开发框架共享一切的名目成绩。
咱们带来了矫捷开发方法，同时Mingle将会允许和推进这一切上班。
疏通的消息渠道，明晰的老本/收益核算，片面消弭糜费，这是精益制造的中心所在，也是矫捷软件开发的中心所在。
TDD是什么文件？用什么工具关上？
1：测试驱动开发(TDD)是矫捷开发中的一项中心通常和技术，也是一种设计方法论。
TDD的原理是在开发配置代码之前，先编写单元测试用例代码，测试代码确定要求编写什么产品代码。
TDD虽是矫捷方法的中心通常，但不只适用于XP（Extreme Programming），雷同可以适用于其余开发方法和环节。
2：TDD的基本思绪就是经过测试来推进整个开发的启动，但测试驱动开发并不只是单纯的测试上班，而是把需求剖析，设计，品质控制量化的环节。
3：TDD的关键目的不只仅是测试软件，测试上班保证代码品质仅仅是其中一部分，而且是在开发环节中协助客户和程序员去除模棱两可的需求。
4：TDD首先思索经常使用需求（对象、配置、环节、接口等），关键是编写测试用例框架对配置的环节和接口启动设计，而测试框架可以继续启动验证。
