极限编程和精益敏捷开发

1XP极限编程

xp体系

Extreme programming （XP极限编程），是由Kent Beck所发展，XP聚焦在软件开发的最佳实践，其迭代周期通常比Scrum的冲刺周期短，最短为一周，主要运作机制是让团队及客户高度聚集。XP也是使用用户故事描述用户的需求，通常用户故事会有一系列的Acceptance tests（接收测试）与Acceptance criteria（接收原则）。由客户定义接收原则及Test cases（测试用例），再由团队以结对方式编程开发。每一个用户故事代码开发由程序员两两结对一起工作，一个看大方向，一个编程细节，并定期角色互换，以撰写符合测试用例的代码。

季度循环

XP团队一次计划一个季度的工作。即XP按照一个季度进行规划，所以XP团队每个季度召开会议来进行规划和反思。开会并反思过去这个季度发生了什么，讨论全局问题：公司关注什么，团队如何融入其中。计划这个季度的主题（目标），明确其长期目标（主题就是一个总体目标，用来将用户故事分组组织在一起）。计划这个季度的代办列表，为此要与用户和相关方会面，挑出下一个季度最有价值的用户故事，可以从这些故事中选择一些放入到后续的待办事项列表中。

周循环

即一周迭代，XP使用一周迭代，在这个迭代中团队要选择用户故事，并构建这一周结束时“完成的”可用软件。每个循环开始时会召开一个会议，在这个会议上将演示可用的软件，并如下计划他们打算实现的目标：

1、审查到目前为止的进展，并演示他们上一周的工作成果。

2、与客户一起选择这一周的用户故事。

3、将用户故事分解为任务。

虽然也可能会分配任务，但是XP团队自我认领任务为主，周循环是在周二或周三开始。为什么不是在周一开始，因为周一开始周五结束，到周五没完成，会有加班的想法。其目的就是杜绝加班，所有在周二或周三开始，在下周一或二结束，可以给自己激励。

松弛（Slack）

团队创建计划，会增加松弛，即加入少量可选或不太重要的选项，如果将来进度开始落后，可以选择去掉这些工作项。例如：团队可能在周循环中包含“可有可无”的用户故事。一些团队只会加入1-2个松弛项，而且松弛项所占时间很少会超过周循环的20%。

xp价值观

价值观：勇气、尊重、沟通、简单、反馈。

勇气

xp团队有勇气接受挑战。

xp团队有勇气为他们的项目挺身而出。

xp团队有勇气丢弃现有的糟糕代码。

尊重

团队伙伴相互尊重。

团队中的每个人都信任彼此能完成任务。

即使不喜欢，也相信和认可对方的选择。

沟通

xp团队通过信息发射源，让他们的工作可视化，透明化。

xp团队利用渗透式沟通，进行潜移默化。

团队编程是社交性的，不是孤立的活动。

沟通帮助程序员进入“涌流”，而不是绝对安静的环境。

反馈

迭代不是等工作全部做完做大型演示，只是做一小块工作，获得用户反馈。用户会对其需要的东西越来越了解，以便后续不断调整计划。

集成代码，本地代码如果与团队其他人文件版本不同，会带来很大问题，需要经常将你的新代码与团队其他人的代码集成，能得到更早的反馈，集成得越频繁，发现冲突就越早，解决起来就越容易。

队友审查，Linus定律（李纳斯定律）：“足够多的眼睛可以让所有bug无所遁形”。从队友得到反馈可以帮助你发现你的代码问题。帮助队友了解你构建的是什么，以便他们以后处理你的代码。

单元测试，或自动化测试，确保你构建的代码能正常工作，单元测试通常与其余代码一起存储在文件中。对代码做一个修改时，会测试失败，这是你得到的最有价值的反馈。

10分钟构建，团队会维护一个自动构建，该自动构建包括编译代码、运行自动测试以及创建可部署的包。要确保这个自动构建运行时间不超过10分钟。这样能够了解代码是否出现问题，及时得到反馈。如果构建能很快运行，团队中的所有人就会愿意在需要时尽可能多地运行构建。

线框图（Wireframes），线框图是快速描绘产品或解决方案的蓝图设计工具。在软件开发过程中，线框图可以拿来描绘显示页面中不同区块及连接画面的信息流方向，进而确认干系人对于最终产品的功能是否同样的认知。若是认知上有差距，线框图就成为视觉辅助工具，借由不断的讨论与微调，直到干系人达到共识为止。线框图是低写真的模型视觉展现，优点为快速且低成本，可轻易获得反馈的沟通方式，其机动性很强，可以随时进行调整。

图1-线框图样本

使用线框图的目的，就是协助理清干系人心中的Done是长什么样子、怎样才算完成？在投入大量精力前，先确认团队与客户双方的认知是相同的。一个好的线框图特性：

1.议题可以图示化展示以便讨论。

2.可有效沟通双方想法。

3.可确认认知是否一致。

4.能够快速取得客户反馈。

图2

探测（Spike）spike是Risk-based spike的总称，在Agile观点里，Spike都是针对风险的探测。通常在一有限的时间盒（Timebox）期间执行，通常是在迭代之前进行工作或实验，用以获得特定问题的知识或确认解决方案的可行性。XP提及风险探测可以当作是用户故事来管理，但需要小心，因为探测并无法提供客户价值。

若风险探测本身为技术开发的必要条件，则优先做探测（其优先级高于其他的用户故事，因为要确认是否造成项目的Fast failure（快速失败））。但是，若有许多技术方案可选择，其中一个方案有不确定性，需要做探测才能得知是否可行，则我们会选择不做探测，因为风险探测是不得已的最后手段。

图3-快速失败示意图

简单

1、如果一个单元的代码做的事情太多，就会很复杂，要尽量一个单元的代码只做一件事，要降低复杂性，最有效的方法之一是把它分解为更小单元。

2、重构现有代码，代码无法一次就写到最好，不断重构来降低代码复杂性。

3、好习惯比纪律更有效，要养成以上两点的良好习惯。

xp实践

图4

图5

1整个团队（Whole team）

指所有对xp项目有贡献的人，坐在同一个办公室里一起工作。团队包含：客户代表、代码设计师、商业分析师及Quality Analyst（qa品保人员）。xp鼓励通才，避免专人专用，可以工作论调、Pair programming（结对编程）等作法，以达到资讯分享，避免人才流失影响工作或产生断层，xp团队没有指定的角色。

集中式与分布式团队（Co-located and Distributed Teams）

集中式或分布式团队一般是以Physical Location（实际距离）来看，并考量：

1.团队是否有共同工作区域。所谓共同工作区域指的是团队每日工作都是在同一专属空间，又叫War room（作战室）。

2.团队的每个成员是否都集中一起（一般10米之内），实际距离所影响的不仅是团队合作的程度，也会影响信息的分享。敏捷强力推荐集中办公，可以产生以下途径提升沟通效能：

主动式途径Face-to-face communication（面对面沟通）

被动途径Common open area（共同开发空间）

集中式团队（Co-located Teams）

敏捷团队理论的理想状态，为了发挥最大及最好的沟通效果，团队应该是集中在一起工作。何谓一起？实际范围直径是10米，超过10米则为分布式团队。好处1面对面的沟通是常态。2文档的书写量可以减至最低。

集中式团队还能提供两种特别信息分享的模式1.Osmotic communication（渗透式沟通）2.Tacit knowledge convey（隐性知识传递）。集中式团队的挑战：

1.缺乏个人隐私：敏捷建议Caves（私人洞穴）and common（共同空间）以平衡满足团队合作与个人空间的需求。

2.人员数量限制：若是项目的规模大，敏捷建议将团队分割成子团队，以维持各团队的人员数在建议值之内。  

团队空间是完全开放无隐私的，为了保障个人处理私事（例：接听私人电话），敏捷方法建议在团队空间旁边，开设另一个空间，给予团队成员处理个人私务使用，这个模式叫做Caves（洞穴） and Common（公共区）。

左边私人洞穴，右边公共空间

典型XP团队空间分布

渗透式沟通，指团队成员对话中的信息流动，对其他成员来说，就是无意中听到的信息。集中式团队让团队成员彼此的距离缩小到像是一起办公一般，成员间相互流动的信息就成为环境背景噪音。当下渗透式沟通发生时，成员间问与答的信息，在几近零阻隔障碍下，很自然而然在所有成员之间流传及散播。渗透式沟通就像雷达波一样，信息传递有一定距离限制；成员相距越近，效果越显著。

图8

2规划游戏（Planning game）

主要目的是期望将规划效益最大化。XP包含两个主要的Planning games：发布规划及迭代规划。Release（版本发布），是将新的功能或特性发布至正式环境给用户，一个项目通常有一道多个Releases。

3小版本发布（small release）

聚焦在Minimum Marketable Features（MMF；最小可售特性）以降低开发复杂度及提升产出价值。XP鼓励频繁的小版本发布，发布软件给客户使用，让客户更密集的参与版本发布活动。在迭代阶段，可定期展示进度及提升项目对客户的Visibility（透明度），Release阶段，快速的将可正常运作的软件给使用群组。

最小可售功能例子

4客户测试

客户测试演示了客户定义的系统功能。客户测试的好处是，确保有问题时可以随时获得客户的实际反馈。客户测试是定义项目所需功能的重要部分，客户描述一个或更多的测试条件并实际测试，确保软件可正常运行。在XP，客户主要责任：

1.写用户故事。

2.定义用户故事的Acceptance criteria（接收原则）。

5集体代码所有权（collective code ownership）

指在XP实践中，多位开发者同时进行代码设计与开发，共同修改代码质量或提升效能。这代表许多人在修改同一份代码，如此可提升团队的知识及代码的透明度。此做法让更多人看相同的代码，可产生高水准的质量及更快发现缺点。由于Responsibility（执行责任）和Accountability（负责）都已分担给团队，因此团队成员对代码都有责任。可以降低开发者离职所产生的冲击及风险。

6编码标准（Coding standard）

虽然集体代码所有权可以让项目的多位开发者修改同一代码，但也可能因此造成问题。为了降低风险，XP团队需要遵循一致的编码标准，以确保所有的代码看起来都可以让团队中的每一个成员所理解并适时修改。编码标准包含：档案命名、函数命名规则、编排方式、括号原则等。在相同组织里的不同团队，可使用不同的编码标准。只要在开发前团队有共同的认知即可。团队有代码成败的共同责任。

7可持续的步调（Sustainable pace）

XP认为项目的高生产力是由团队在可持续的步调中所达成。虽然长时间的工作可能是必要的。但持续的长时间工作，会导致质量不稳定及成员生产力降低，更可能进一步造成员工生活失衡而离职。可持续的步调是在项目开发过程中保持团队可接受的一致的工作负载与生产能力，此作法可持续提供最佳的长期价值给客户。

8隐喻（比喻）Metaphor

XP使用比喻来解说系统设计及分享技术愿景。这些描述可让不懂技术的干系人易于了解系统如何运作。例：将Server load balancing （服务器负载平衡），比喻为大型超市的多台收银机，可有许多人排队，以避免大排长龙及等待时间过久。可以使用通用或常见的名词以表达不同的元素。例：Chickens（鸡；说话的人）、Pigs（猪；做事情的人）等比喻名词。

9持续集成（Continuous Integration）

是将不同开发者所撰写的代码整合在一起，确保软件可被汇编及正常运作。XP实施持续集成，开发者通常将代码放入Code repository（代码仓库），每次将新功能整合进系统，整个系统会自动执行所有测试。可能一天执行好几次。可在更多的代码或设计不相容之前，将问题浮现在台面上，即时通知开发者修正，减少bug与产品缺陷。

持续集成-验证与确认。利用自动化系统（版本控制系统）。将新增或修改的代码编译，融入既有的代码库。持续集成通常应用在开发者Check in（检查） 新代码的时候，后每隔一段非常短的时间自动执行。好处是可以在不同人员撰写代码及Check in（检查）时，降低彼此代码相容性问题的发生，是一种提供代码开发者及早发现与解决问题的机制。

持续集成带来优点如下：

1.提供保护机制，可让代码设计人员不畏惧进行编程，系统随时可以恢复到Last known bug free（最后无缺陷）的状态，让开发者可以尽情发挥，不会绑手绑脚。

2.提供立即反馈，指出问题点在哪?让团队可以尽早修正，降低变更成本曲线。

3.确保代码库保持在最新状态且经过测试验证。

4.收敛技术债务，避免在版本（发布）前才手忙脚乱处理代码缺陷。

缺点如下：

1.需要主机设备以及设定持续集成软件的时间，这些工作通常在Iteration0（0迭代）的阶段完成。

2.需要采购主机服务器的成本，通常是一台专用主机。

10测试驱动开发（Test-driven development）

测试驱动开发（TDD）是XP方法论的关键实践，确保良好的测试涵盖范围，让问题可以在代码发展初期及早发现。此做法中，团队把测试条件先写好，在写代码。当通过测试，则代表代码编写正确，此作法可以缩短测试的周期反馈时间。

先把测试用例与测试代码写好，在进行代码编程的循环开发方法。详细步骤如下：

1.Add tests（撰写测试），针对开发的产品特性先写测试代码。

2.Run tests（执行测试），此时测试结果一定是Fail，因为产品代码尚未开始撰写。

3.Write code and run tests （编写代码并执行测试），执行所编写的代码，直到通过所有测试的检测为止。

4.Refactor（重构），最后在不更改原有功能的前提下，将通过测试的代码重构优化。

图9

优点如下：

1.直接面对需求保持单纯。

2.提早侦测代码缺陷。

3.应用多元小型可测试的单位，组成更有弹性的系统。可提前理清功能性问题，进而控制设计的单纯性，提高客户满意度。

4.执行强化重构的基础，能够有效提升产品质量。

TDD强调Red、Green与Clean（红、绿、净）的先后顺序，以下为重构的判断标准：在无代码的情况下，写下的测试，测试结果为失败：红灯。

持续撰写及修改代码，一直到通过测试为止：绿色。

此时开发者开始重构优化已通过测试的代码：净化。

测试驱动开发过程

11重构

Refactoring（重构），是在不改变代码原有功能的前提下重组代码，提升现有代码的质量与运行效率，让后续代码设计的新增或变更可更容易实施。重构聚焦于移除不必要的代码、简化代码的复杂度、降低代码的Coupling（耦合度）及提升Cohesion（内聚度）。

技术债务（technical debt）

又称为Design debt，是项目团队为了短期利益，而降低产品质量所造成的质量负担。技术债务如同贷款一般，越早还债，就越容易解决，越晚处理，问题就像滚雪球越来越大，成本也越高。积累的原因：

1.Making poor design decisions 不良的设计决策

2.Making decisions too quickly 太快做决定

3.Not fixing errors right away 没有即时修正错误

4.Making code changes for the moment rather for moment为解决当下问题而修改代码

12简单设计（simple design）

Simple design（简单设计），XP遵循一个审慎的设计哲学，偏向于“What is the simplest thing that could work？”（什么是最简单有效而又能运作的产品？）每一个迭代重新检查增量成品，确保目前的交付产出扔符合简单设计原则。简单的设计除了可以有效降低风险之外，也可实现更快速变更的目标，提升开发效率。

敏捷原则第10条就是合乎简单设计的定义：Simplicity-the art of maximizing the amount of work not done -is essential（简单是美，如何将不需要的工作项目数量最大化是重要的）针对设计，敏捷方法会问：在能够运作的前提下，最简单的产品是长什么样子？为了要满足全方位的需求，而打造复杂且多功能的产品特性，不是敏捷认同的设计理念。在简单设计的原则下，产品设计要定期审视，尽量降低复杂度以确保设计合适。

Complex Design （复杂设计），是指当专注在打造非现今必要特性功能的设计，常会造成以下缺点：

1、增加项目负面风险。

2、增加未来变更的成本花费，且降低产品弹性。

3、增加产品维护与支援的成本花费。

4、减少可用在优先发展特性的资源。

5、产生追加假性功能需求的恶性循环。

研究指出，高达80%的软件功能极少或根本没人使用。

13结对编程（Pair programming）

结对编程，XP强调代码是由两两一组的开发者所设计出来的，一个写代码，另一个对代码进行即时审查。这个做法看起来很浪费人力，但是XP提倡，如此做法反而能减少更多开发时间，因为可在长期发现问题，且平时两人建立知识分享，可以避免当有人离开团队时所造成的冲击。在项目执行过程中，配对的开发者，不一定是固定的，也可与其他组别互换人员。

XP极限编程的最佳实践要求包括以下三点：

1.两位代码设计师坐在一起，共用一台工作站。

2.一个人编写代码，另一个人担任观察者。观察者的责任是立即审视刚写出来的代码。

3.两人频繁的互换角色。

这种一人注意代码细节，另一个人注意逻辑全貌的方式，需2者功力相当，目的是要立即的检查并纠正项目产出。

例子 -左边司机右边领航员

结对编程好处：

1、Better designs 较佳设计

2、fewer defects 较少缺陷

3、More accurate details 细节较正确

4、Real-time code reviews 立即代码审查

5、Reduced technical debt 减少技术债务

2精益敏捷开发

精益思维

Lean Software Development（LSD；精益软件开发）是以制造业Lean manufacturing（精益生产）法则延伸而来的，精益体系提倡》ean portfolio management（精益项目组合管理）与精益的七大原则。精益是一种思想，而不是一个方法论，精益项目组合管理的主要精神是：

1、聚焦能够快速完成的工作，故所挑选的项目越小越好。

2、透过将WIP（在制品，正在制作当中的产品）最优化以消除工作瓶颈，提升开发速度，降低产能的浪费。

TPS思想

自働化（Jidoka）：创建自动化方法，只要检测到问题就停止生产。在TPS中，流程中的每道工序都有自动化检查，确保一旦发现问题就在当前位置修正，而不会推到下一个工序。

看板（Kanban）：发出信号的卡片。TPS制造系统中使用看板卡片知识流程中的一个工序已经准备好接受更多库存。

拉动系统（Pull System）：流程中的每个工序在零部件消耗完时指示上游工序的一个工序需要更多库存。通过这种方式，可以按最高效的拉动系统，而不会变得不均衡或者需要应急储备。

根本原因分析（Root cause analysis）：明确导致某种情况发生的“深层”原因。Taiichi Ohno（丰田生产方式的创始人大野耐一）采用5问法，来找出根本原因。

改善（Kaizen）：持续改善。只有当团队注意到工作流中发生了什么并提出改进建议时，加入改善日常功能的活动才是有意义的。

精益思维工具（查找浪费、价值流程图、排队论、拉动系统、选项思维、延迟成本、度量）

排队论

精益团队使用排队论来确保人们不会工作负荷过重，使人们有足够的时间并且采取正确的方式工作。软件开发中往往有一些需要优化的队列，如产品待办事项列表，往往先进入的任务也是最先完成的。精益思维要求团队的工作列是共有的，要让其成为决策流程的中心，帮助团队更快地交付工作。精益团队经常使用排队论尝试在系统中增加队列，以均衡系统中的工作流。

拉动系统

团队使用代办列表组织所有的工作，开发人员完成了一个任务时在选择一个新任务，这就是在使用拉动系统。待办列表不是由用户、经理或PO向团队推送任务、特性或请求，而是将请求加入队列，团队在拉取需求。拉动系统要求保证一次只处理一个工作，有人空闲下来可以处理新工作时才会把工作拉入流程的下一个阶段。如此人们可以尽其所能地完成好他们承担的各个任务，在强调质量和效率的前提下构建产品。

选项思维

团队在决定下一个版本要包含哪些特性时，实际上只是确定团队可以选择哪些选项，从而为每个发布交付价值，而不是与用户的承诺。

Scrum团队不会花时间描述和跟踪任务之间的依赖关系，实际上，在每日站会上，团队可以在任务板上自由地增加和去除任务，这些任务是选项，而不是承诺。这些任务没有截止日期，不会有所谓“落后的”任务导致项目的其余部分错过最后期限。团队将工作计划想象成选项，就能在需要时做出调整，确保他们尽其所能地完成产品工作，而不会过度承诺。

延迟成本

延迟一项任务所付出的成本，高风险任务比低风险任务的延迟成本高，低风险任务即使在规定时间盒内没有完成也不会有太大影响。团队需要了解队列中各个任务的延迟成本以便进行决策。精益团队会为发布新特性建立交付节奏，并不是承诺按一个特定的时间表交付一组特性，只承诺尽其所能地交付最大的价值。

最小可售特性（Minimum Marketable Feature）

（MMF；最小可售特性）由客户或PO所定义，是最小产品群组功能，可提供用户价值。此MMF是已经可让用户使用或进入市场销售。（例如：1投影机要能投影及连接电脑功能，两个功能若少其一，对用户是不完整的。故齐全才能让用户使用投影机简报。2手机要能接听电话及拨打电话。3数字相机要能拍照、预览照片及汇出照片）

若比较MMF和Backbone（骨干）及Walking skeleton（可行走的骨架）：MMF指产品对客户有价值。产品上市时，若客户会买单，就代表达到MMF的需求。骨干是产品必要的元件（一定要有）例车子的引擎、刹车、排气系统等。Walking skeleton是产品能够基本运作的元件。例车体、方向盘、刹车、电路及传动系统等。换句话说，MMF是从客户的角度来看，而骨干和可行走的骨架是从开发团队技术角度来看。

最基本可运行产品（Minimum Viable Product）

概念就是：在最精简的投入下产出的产品，并且能得到反馈的价值是最佳话的。MVP要能够满足最基本的功能需求，而且是立即可以使用，完全没有额外多余的特性。

MMF vs MVP

精益项目管理的优点

1、speed and quality（兼顾速度和质量）

2、Line of sight to business needs（调整与营运需要同步）

3、Minimize work in progress（最小化WIP-在制品）

4、Minimize interruptions（降低干扰及中断次数）

精益原则

精益7大原则

（1）消除浪费

就是相对的增加或提高价值。任何不能够带来价值的资源投入，就是浪费。如何消除浪费？

1、See the waste（识别浪费）

2、使用Value stream analysis（价值流分析），可将整个Process flow建立起来后，针对识别的浪费，发展对策使其消除或减轻。

TPS三大浪费来源

1Muda（浪费）：指一切不为顾客创造价值但却消耗资源的活动，这表示“无价值、无用、闲散、过剩、浪费、废物、资源浪费等”。

2Mura（不均衡）：指生产运作的不平衡，这表示：“不平均、不规则、不统一、无统一性、不均等”。

3Muri（负荷过重）：指超载的设备或是超负荷的工人，这表示“非理性、不可能、超出某人能力、过于困难、被强制、过量、无节制”。

根据这三类浪费，精益软件开发衍生出7大浪费。

精益原则的7大浪费

价值流程图（Value Stream Mapping）

 

是一种精益的系统性方法。借由透过图示化分析目前过程的价值、找出浪费，改善过程效率；如下图

价值流图例子

价值流改善对象可以是特定的产品、服务或是一系统产品的组合，可让我们改善产品生产力的过程，已提供改进的策略及提高竞争优势。相同的过程，套用的不同对象时，会有不同的过程循环效率。例：母亲带小孩去买ps5游戏机，30分钟游说小孩不要过度沉迷，20分钟挑选，10分钟结账。对小孩有意义的只是后面30分钟，对妈妈则是60分钟。

（2）强化学习

是在迭代结束前，借由持续不断地反馈机制，改善下一个迭代的作法。将产品展示给客户，以强化及修正对产品的认知。以内部的回顾会议来改善过程的效率。最有效的学习是短周期的学习循环，故迭代的回顾会议是典型强化学习的作法。比长期之后发现问题，再学习来得好。

（3）尽可能晚做决策

针对产品方向及未来目标的不确定性，强调任何重大的决策，越晚做决定越佳。信息越晚越明确，越晚做决策，可挑选的决策选项就越少了，确保决策的准确性。可大幅度降低因太早做决策，而造成晚期大量变更所带来的风险。最晚的决策点是“The last responsible moment（最晚回应时刻）”，在这个时刻之后，就没有必要再做决定了。

（4）尽肯能快交付

以增量方式提早交付产品，可获得下列利益：

1、确认开发方向是正确的。

2、提早让客户实现产品能够带来的价值。

3、提早发现问题并修正。

（5）授权团队

让团队成员自己做工作相关的决策，管理者仅适时领导。采用Pull systems（拉式系统），让团队自行挑选该迭代所要完成的工作事项。工作不是由管理者指派，而是由开发团队成员主要决定。

（6）内建质量

强调产品的质量，应是项目过程中，与客户建立一致的质量认知与观念。在开发产品过程中，将质量做出来，并持续的维持质量水准，而不是靠后期的检查与确认，来发现产品缺陷。借由不同程度持续测试机制，如：持续集成、小版本发布及重构，以确保整个产品的质量。

（7）纵观全局

看到以下四个方面全貌：

1、在团队方面，注重团队整体的表现。

2、中项目方面，同步调整许多项目的目标使之一致。

3、在跨职能团队方面，强调整体运作的和谐。

4、在对外谈谈方面，聚焦在创造双赢局面，像是签订双赢合同。例：Change for free合同，若客户参与过程的开发，则可让客户在迭代之间，免费调整优先级。

看板体系

看板（Kanban Board）

Kanban在日文代表看板、布告栏的意思。版本来自Toyota制造系统，其概念是设计一个生产管理系统，将零件的仓储水准控制在最低点，当需要的时候才以Just in time （JIT；即时产生）的方式拉动生产。应用看板可形成Pull-driven flow（拉动向导）机制，即在有需要的时候才开始生产，避免囤积多余产出的风险。（例：大量产出才发现缺陷，需返工数量太多）Kanban的三个简单原则：

1、Make work visible（让工作视觉化）

2、Limit WIP（限制进行中的工作）

3、Help the work flow（促进工作顺畅进行）

Kanban将项目的工作状态，贴在明显的信息发射源，以逐步完善目前工作排程，当做是项目绩效的主要测量工具。Kanban是属于Low-tech、High-touch（低科技高感触）工具，可使团队共同规划及维护项目的状态。

看板可明显看出WIP的任务量有多少，可有效限制WIP的数量，这也可以当作是Agile项目的控制界限。限制WIP的数量是为了最佳化工作流量，使工作不塞车，而非将资源（人员）的使用率最大化。为确保Cycle time（循环时间，周期时间）的最小化，团队通常会在看板上的用户故事卡片写上开始日期及结束日期。看板与任务版最大差异在于看板上的用户故事或任务在每一次迭代都不重新清零。

任务版和看板区别

任务版和看板对比

在制品限制（WIP Limited）

WIP是Work in progress，指过程中工作，代表已经开始执行但尚未完成的工作。太多的WIP会有以下问题：

1、绑死资源，但看不到价值的产出。

2、会隐藏工作瓶颈（想象只有1项进行中的工作，若做不出来，是很容易看出瓶颈？若同时有10项工作进行中，则不容易看出哪项工作造成瓶颈）

3、若此时出现变更，大量正在进行中的工作会变成没有必要的工作，而且需要返工。

对比图

看板的核心实践步骤

1、可视化工作流：为当前使用的流程图创建一个示意图。

2、限制WIP：观察工作项在系统中如何流动，并尝试限制每个步骤中的工作项数，直到工作能均衡流动。

3、管理流动：度量交付时间，查看哪些WIP限制使得向客户交付特性的时间最短。试着保持稳定的交付速度。

4、显示化流程策略：找出知道团队做决策的未成文规则，并记录这些规则。

5、实现反馈回路：对流程中的每个步骤，建立一个检查来确保流程是可行的。度量交付时间和周期时间，确保流程没有减慢。

6、协作式改进：分享你收集的所有度量结果，并鼓励团队提出建议继续进行试验。

看板进度情况

周期时间【循环时间】（Cycle Time）

是指要花多久的时间把特定的事情完成。如：一个用户故事从团队开始进行开发，直到完成普通的测试，称为循环时间。

Project cycle time（项目循环时间）是指项目所有工作的循环时间平均值，而不是所有工作的循环时间总和。

Worker in progress（WIP；过程中工作）是指任务已经开始执行，但是未完成测试验收的状况。WIP与循环时间息息相关。

团队在单位时间内完成的工作量叫做Througput（生产率）和循环时间及WIP三者之间的关系为，WIP/Througput = Cycle time

例如工厂生产率为1000组/天，WIP为2000组故意循环时间=WIP/Througput=2000/1000=2天

敏捷项目与传统项目最大的不同在于敏捷手法强调最佳化WIP，就能降低循环时间,并以追寻最佳循环时间为目标。

交付时间【交付周期】（Lead Time）

交付时间是指从客户下单到接受产品所需的时间。在软件开发领域，则只从客户提出需求到需求上线所需的时间。应用看板管理方法，测量项目进度方法是使用，交付时间而非速度，其项目绩效聚焦于降低交付时间，而不是增加团队的速度。

交付时间（Lead time）和周期时间（Cycle time）不同。交付时间站在用户观点，即从形成用户故事，到用户故事实际上线所需的时间。周期时间站在开发者观点，即开始开发用户故事到完成用户故事所需的时间。

交付时间（Lead time）和周期时间（Cycle time）区别

交付时间（Lead time）和周期时间（Cycle time）比较

积累流图（Cumulative Flow Diagrams）

累积流图（CFD）可用以追踪及预测项目进度，协助找出项目的问题。

循环时间【周期时间】是工作或产品的制作时间（完成时间-开始时间）

可以使用Goldratt’s Theory of Constrains（TOC；限制理论）找出工作的瓶颈限制。如下图

积累流图

当某一工作的WIP越来越宽，下面那一层即为工作瓶颈，为避免过程限制，尽量不要专人专职，而是一人多功相互支援。

团队工作协议（Team Working Agreements）

又称为Ground rules（基本规则）是一种团队的项目运作规则。由团队共同提案、共同讨论、共同决议，作为日后共同遵守的工作原则，是团队运作更有效率及效能。团队工作协议可与每个迭代结束前的回顾会议时修正。团队工作协议通常贴在信息发射员让团队都可以看到。

团队工作协议模板

团队章程（Team Charter）

敏捷项目需要有章程，团队组建也需要有章程。将团队组建产出的共识给予书面化，可赋予团队良好的心理建设。团队章程由团队共同讨论以下项目：

1、Core Values （核心价值）

2、Strengths （团队优势）

3、Logistics（后期支援）

4、Team Working Agreements（团队工作协议）