新書推薦：
《
不被他人左右：基于阿德勒心理学的无压力工作法
》
售價：NT$
301.0
《
SDGSAT-1卫星热红外影像图集
》
售價：NT$
2030.0
《
股市趋势技术分析（原书第11版）
》
售價：NT$
1010.0
《
汉匈战争全史
》
售價：NT$
454.0
《
恶的哲学研究（社会思想丛书）
》
售價：NT$
500.0
《
当你沉默时（悬疑推理 反PUA 反家暴 女性独立小说，揭秘情感PUA的真相，女性自我救赎的文学典范）
》
售價：NT$
255.0
《
不止江湖
》
售價：NT$
449.0
《
天才留步！——从文艺复兴到新艺术运动（一本关于艺术天才的鲜活故事集，聚焦艺术史的高光时刻！）
》
售價：NT$
704.0
|
| 編輯推薦： |
本书作者从事软件开发多年，善于吸取敏捷和精益这两种开发方法的精髓，对看板的理解和应用具有实用而丰富的经验。他在本书中依托精益开发中的主流工具，介绍了看板的概念、遵循的基本原则、看板的适用范围和具体使用等。
精益软件开发是当下软件开发项目的主流。看板可以使得精益理念落实并贯穿于整个开发流程，从而提高应变能力、减少无谓的资源及时间浪费、完全发挥团队的开发效能。本书适合所有软件从业人员（从项目经理到工程师）阅读，可以帮助他们从容应对千变万化的客户需求。
|
| 內容簡介： |
本书作者从事软件开发多年，善于吸取敏捷和精益这两种开发方法的精髓，对看板的理解和应用具有实用而丰富的经验。他在本书中依托精益开发中的主流工具，介绍了看板的概念、遵循的基本原则、看板的适用范围和具体使用等。
精益软件开发是当下软件开发项目的主流。看板可以使得精益理念落实并贯穿于整个开发流程，从而提高应变能力、减少无谓的资源及时间浪费、完全发挥团队的开发效能。本书适合所有软件从业人员（从项目经理到工程师）阅读，可以帮助他们从容应对千变万化的客户需求。
|
| 目錄：
|
目 录
第1章 精益软件开发1
1-1 精益的由来2
1-2 精益软件开发3
1-3 精益软件开发七大原则5
1-3-1 消除浪费（Eliminate waste）5
1-3-2 增强学习（Amplify learning）11
1-3-3 尽量延迟决策（Decide as late as possible）14
1-3-4 尽快交付（Deliver as fast as possible）17
1-3-5 授权团队（Empower the team）20
1-3-6 嵌入完整性（Build integrity in）22
1-3-7 着眼整体（See the whole）25
1-4 结论27
第2章 看板方法29
2-1 看板的由来30
2-2 何为“看板方法”30
2-3 看板方法四大基本原则（Foundational Principles）32
2-3-1 原则1：从既有的流程开始32
2-3-2 原则2：同意持续增量、渐进的变化34
2-3-3 原则3：尊重当前的流程、角色、职责和头衔36
2-3-4 原则4：鼓励在各个层级上发挥务实性领导行为37
2-3-5 四大基本原则的意义38
2-4 为何要使用看板方法39
2-5 哪些地方可以运用看板方法45
2-6 结论48
第3章 看板方法的六大核心实践49
3-1 可视化目前的工作流程50
3-2 限制半成品（WIP）数量58
3-2-1 利特尔法则59
3-2-2 多任务是不好的？看板方法如何处理多任务61
3-2-3 怎么样的数值才会让人满意呢63
3-2-4 根据请求的多寡分配产能64
3-3 管理工作流程65
3-4 让规则明确69
3-5 落实反馈循环71
3-6 由协作改善，经实验演进72
3-7 结论75
第4章 如何实施看板方法79
4-1 看板墙的设计80
4-1-1 三个基本元素80
4-1-2 顺序处理状态 VS. 并行处理状态81
4-1-3 工作项目的属性84
4-1-4 加入 WIP 限额86
4-2 Scrum 运作模式的看板墙设计91
4-2-1 将看板方法融入 Scrum 的开发过程91
4-2-2 在 Scrum 中运用看板92
4-3 看板一日游94
4-3-1 看板一日游 112 说明94
4-3-2 看板一日游 212 说明96
4-3-3 看板一日游 312 说明98
4-3-4 看板一日游 412 说明99
4-3-5 看板一日游 512 说明99
4-3-6 看板一日游 612 说明100
4-3-7 看板一日游 712 说明101
4-3-8 看板一日游 812 说明102
4-3-9 看板一日游 912 说明103
4-3-10 看板一日游 1012 说明103
4-3-11 看板一日游 1112 说明104
4-3-12 看板一日游 1212 说明105
4-4 运行看板方法的简单规范106
4-5 结论111
第5章 个人看板：类项目管理113
5-1 个人看板114
5-2 制作第一个个人看板115
5-2-1 可视化116
5-2-2 设定 WIP 限额119
5-2-3 看板管理：开始运行拉动系统120
5-3 个人看板与软件开发：类项目管理124
5-3-1 项目的范围124
5-3-2 建立个人看板125
5-3-3 个人看板一日游127
5-3-4 另类的个人看板137
5-4 结论140
第6章 个人看板与生活：让生活与工作相得益彰143
6-1 开始使用看板144
6-2 生活与效能148
6-2-1 消除浪费149
6-2-2 梦想与目标150
6-3 个人看板进阶156
6-4 结论157
第7章 预测未来：减少变异性，增加可预测度161
7-1 系统思考163
7-2 内部变异167
7-3 外部变异174
7-4 结论177
第8章 持续改进179
8-1 看板方法的问题管理181
8-2 运用看板方法自然形成简单的团体规范183
8-3 没有银弹（No Silver Bullet）186
附录189
附录A 精益咖啡190
附录B Scrum But 和 Kanban But194
附录C 用户故事图谱：对付需求模糊的好帮手199
附录D 敏捷开发需要哪些文件203
|
| 內容試閱：
|
第1章
精益软件开发
1-1 精益的由来
“精益”（Lean）这个词汇是约翰?克拉夫西克（John Krafcik）1988年在他的一篇文章 里率先提出来的，但他所称的精益制造（Lean production），指的是制造业的精益理论，而软件界的精益（Lean）则称为精益软件开发（Lean Software Development），它源自于波彭迪克夫妇（Mary Poppendieck 和 Tom Poppendieck）在 2003 年的著作《精益软件开发工具》（Lean Software Development：An Agile Toolkit），书中阐述了精益软件开发的七大原则，精益属于敏捷开发的成员之一。
敏捷软件开发（Agile software development）是从 1990 年代开始逐渐取代传统开发方法的一些新型软件开发方法，是一种应对快速变化需求的软件开发能力。相对于传统开发方法，敏捷软件开发最大的差异在采用迭代式的开发模式，而不是一次定江山的瀑布式开发模式，以及接受客户对需求合理的变更（让客户对需求做出不同优先等级的区分，并尽力去满足它）。
敏捷（Agile）一词起源于 2001 年初，敏捷方法发起者和实践者在美国犹他州雪鸟滑雪圣地的一次聚会，有 17 位当代软件代表人物共同签署了敏捷宣言，并成立了敏捷联盟。但在此之前，早在 1991 年麻省理工学院出版的“改变世界的机器”（The Machine That Changed the World）研究报告中，就已经把日本丰田公司的丰田生产方式系统（TPS）归纳成为一套精益生产（Lean Production）方法。
严格来说，精益（Lean）比敏捷（Agile）要早诞生许多年，但现在拥戴精益的人士也已经加入了敏捷联盟的阵营（见图1-1），虽然他们依然遵循着精益精神的七大原则而不是敏捷的四大宣言和十二项原则，但实质上他们都共同拥护敏捷式的开发方法及精益精神，二者并无抵触。
图1-1 敏捷伞下的两大阵营
1-2 精益软件开发
精益软件开发并没有具体的开发方法或步骤，而是一堆原则，原因是它认为没有所谓的最佳实践。“原则”具有较广泛的普遍性，能指导对某一学科的思考和领悟，而“实践”则是为执行原则而采取的实际措施，需要针对某一领域进行调整，尤其必须考虑到具体实施的环境。精益软件开发是由软件开发领导者，例如软件开发部经理、项目经理和技术领导者，而不是一般程序开发人员所创设的思想工具。
因为精益软件开发没有具体的实行方法，这会让你觉得它只是一些原则和教条，执行起来应该是最简单的，影响也不大，即便做错了也是无害。如果这么想的话就错了，因为“原则”所影响的是企业的文化层面，比起单纯的开发方法影响大得多了。
依照图1-2的区分，右边第二位隶属于精益开发体系下的看板方法（Kanban），是距离胡作非为（Do Whatever，“胡来”，也就是完全没有规范）最接近的敏捷开发方法。越往右侧的开发方法就表示规范越少，我们称为轻量级（light weight）的软件开发方法，越往左边的开发方法则是规范越多，相对于轻量级的开发方法有较多的约束，我们称为重量级（heavy weight）的开发方法，例如RUP（Rational Unified Process，统一软件开发过程）。
本章的主旨在于阐述如何将精益的精神由原则转换为适用于特定环境下的敏捷实践。说得更精确些，就是针对七大原则加以实践的诠释，目标是看板系统，尤其是依靠经验法则换来的经验知识 。
图1-2 依照规范的多寡由左至右排列各种开发方法
图1-3 在精益网络的时代，充斥着各式各样的对象
如图1-3所示，在没有使用过之前，实在很难判断是不是用错了组件？
1-3 精益软件开发七大原则
以下为精益软件开发的七大原则：
1. 消除浪费（Eliminate waste）
2. 增强学习（Amplify learning）
3. 尽量延迟决策（Decide as late as possible）
4. 尽快交付（Deliver as fast as possible）
5. 授权团队（Empower the team）
6. 嵌入完整性（Build integrity in）
7. 着眼整体（See the whole）
乍看之下，你可能觉得这些原则感觉上像口号一样，真的有用吗？让我告诉你，当你在绘制看板时（也就是将你的工作流程放到看板上成为一个或多个垂直字段时），你所依据的便是对这几条原则的了解程度。如果你觉得很陌生的话，下次改变看板外观时，一边看着这些行列一边思索是否需要改善哪里？改的原因是什么？想达成哪一条原则？多练习几次就熟了。记得一次只改善一个地方就好，这样比较容易看出是哪个异动所造成的结果，这一点跟改 bug 是一样的，一次同时修改好几个地方，就搞不清楚谁才是真正的元凶！
1-3-1 消除浪费（Eliminate waste）
何谓浪费？凡是对客户或产品不具备提升任何价值的行为，基本上都是一种浪费！
Bug 是第一大浪费
程序开发人员最大的浪费，便是在开发工作时制造一大堆 bug，然后再费尽心力把它解决掉。有趣的是，解决这些 bug 之后还能获得相当的充实感！反倒是很少有人会回过头来检讨这些 bug 实际上都是自己所造成的。会有这些 bug 产生，其实是软件的复杂性所造成的，是我们把程序写复杂了。而如何减少 bug 呢？就是想办法把程序写简单一点，只有很简单的程序，bug 才会相对减少。如果程序复杂了，最后便只能靠测试来守住质量，这一点也间接说明开发和测试实际上是一体两面，开发者必须负起减少 bug 的第一线任务，因为它才是最大的浪费。
现在的程序开发工作太复杂了
开发软件最重要的是知道要做什么，然后去做，就这样简单！
但经过岁月不断的累积之后，我们把这个过程变复杂了。是那些有智慧的学者不断地把经验奉献出来，针对各种不同问题提出解答（设计模式便是这样诞生的），智者怕我们重蹈覆辙便想办法把经验积累下来，原意是为了照顾后进，结果却是把开发工作越弄越复杂（HTML 的演进史就是这个缩影）。十年前的软件开发项目，经过十年后规格并没有太大改变，但我们却可以把它弄得越来越有学问，看起来越专业，专业到必须有相当的学习过程才足以开发十年前就能做到的事！程序在执行速度上变快了，但是在质量这一点上却始终没有太大的提升，原因是我们把自己弄复杂了，我们一再地把开发程序的门槛弄高了，而复杂所带来的最大罪恶便是浪费，所以消除浪费便成为近代工程师要学习的第一要务。
“简单”是对付 bug 的有效法则
想要减少 bug，就是把程序弄简单些让自己随时都能看得懂。开发软件时，bug 总是自动在过程中被隐含进来。通常，一知半解写程序是制造bug的最大元凶，这种 bug 最难以检测出来，再来则是逻辑思维被打断也是在写程序时很容易产生bug的时候。所以在进行工作分解时，最重要的是“简单化”，简单是减少 bug 的最佳处方。话虽如此，但很多时候软件开发就是这么复杂，该如何是好呢？
“错误的估算”便是一个简单不下来的原因。千万不要在没有做适度的拆解问题（工作项目）下进行时程的预估，因为那完全是在猜猜看！猜是人类最糟糕的预估了，最少也要有参考依据（有参考依据可以让预估准确许多，例如找到可以比较的案例），但是必须经过拆解成为较小的工作单元，参考才足以成立。所以在减少浪费的前提下，“先拆解再简单化”是开工之前（或是进行工时预估前）的必备动作，正确的拆解可以避开那些不必要的复杂性干扰。
项目经理（PM）习惯向开发人员要求预估需要多少开发时间，想借助工程师每个人的预估，然后合计起来，以得到团队的整体开发时程（当然再加上一点自己习惯性的保险时间）。这是一种将项目分解成多个区块，然后针对各个区块进行预估的作法。这样所估出来的工时乍看之下是会比较准确，但是却忽略了工程师本身所估算的数据本来就是基于一种猜测得来的数值，根本上就已经不准确了。所以，虽然已经经过拆解，但这是基于工程师个人的猜测而来，当然就没有太大的意义。
什么样的估算才比较准确呢？老实说，只有进行一段时间，有更深一层的了解后再来估算自然会准确许多。这种较准确的估算通常发生在项目进行五分之一到三分之一之间，这是一件耐人寻味的事，此时工程师对项目的把握度就可以大幅提升，这个时候的预估就可以接近于“承诺”了。
工程师的承诺与预估
项目开始时工程师无从参考比较，此时的工时估算应该只能说是猜测；一旦项目开始进行后，随着对项目的了解增加，通常工程师在开发工作进行到五分之一到三分之一之间，由于对任务越来越熟悉，自然就可以做比较有把握的预估，这个时候的估算就可以称之为“承诺”。
写程序想要减少 bug，专注（Focus）是最有效的良方。这里讨论的专注是指“短时间”的专注，而不是废寝忘食、长时间疯狂做某一件事的专注。短时间指的是 25 分钟的专心工作，这一点请参考蕃茄工作法 。
如何识别浪费？
丰田生产系统的策划人之一新乡重夫（Shigeo Shingo），他首创制造业的七种浪费类型，而波彭迪克夫妇则将它转换成软件业的七大浪费类型，对照如下表所示。
制造业七大浪费软件业七大浪费
1库存半成品、部分完成的工作（Partially Done Work）
2额外过程额外过程（Extra Processes）
3生产过剩多余功能（Extra Features）
4运输任务调换（Task Switching）
5等待等待（Waiting）
6移动移动（Motion）
7缺陷缺陷（Defects）
判别是否浪费十分重要，它是你避免浪费的基础。接下来的说明虽然看起来冗长，但请务必读完，每个项目的最后会括号说明相对于看板方法的运用手法，譬如你不知道该如何建立看板的垂直字段或调整 WIP（半成品）值，即可参考以下的几条原则，将它们作为依据。
?部分完成的工作
“半成品”的英文是 Work-In-Process（WIP），虽然翻译成“在制品”看起来比较贴切，但我偏好采用“半成品”这个字眼。所谓“部分完成的工作”，它是一种赌博，一个随时可能会失效的功能，因为它有可能还没上场就被换掉了（原因是你提前做了）。另外是太早做可靠度就差一些，虽然你可能用单元测试来保证它的输入和输出值，但在还没有经过整合之前，没有人可以保证它是好的，所以就投资报酬率而言，它是最不理想的半成品。在团队开发流程中，尝试把半成品控制在最小范围内是最理想的状态，也是减少浪费的好方法。（对看板方法而言，可以用来限制WIP值，产生盈余时间 或是看到瓶颈所在，这一点可以通过累积流程图来进行观察）
?额外过程
文档工作是一种最有争议的额外过程，它会消耗资源，降低反应速度，还会隐藏风险；但相对的它可以让客户签字表态，或是取得变更许可，或是便于追踪。几乎所有的软件交接都需要文件，但是基本上它是不会产生增值的，所以也是一种浪费，但若是基于需求上的工作，则可以把它视为是一种增值。请注意，好文件应该保持简洁、具有概念性、便于做交接。（盈余时间最适合用来写文档，工程师要学会把文件交给自己做）
?多余功能
有句古老的名言：“当你新增功能时，也同时新增了 bug”，意思是尽量减少不必要的功能！一般的程序设计师总以为突发奇想的功能是一个不错的想法，为了未雨绸缪就自作主张把它加进来了，老实告诉你这是最不好的做法，记得，只有在有必要的时候才新增功能，任何一段不需要的程序代码都是一种浪费，千万要懂得抵抗自以为能够有先知卓见这种未雨绸缪能力的诱惑。（额外的程序代码将会挤占半成品的数量限制，通过累积流程图可以很清楚地界定它的影响）
?任务调换
多任务是一种浪费 ，给员工同时间分配多种工作是项目产生浪费的一个根源。软件开发人员每次在转换工作时都会浪费大量的调换时间，因为他必须调整思路以便投入新的任务流程。当然，若是你同时参与多个开发团队，自然会造成更多的停顿，从而引起更多的任务调换而浪费更多时间。（限制WIP值就是为了减少这种浪费）
?等待
在团队进行协同开发时最浪费的可能就是等待。有时候等待上级或第三方的响应，例如：等待电子邮件的回函或通知，这种必然存在而且无法改变的过程，就是一种浪费。（这种必然的等待可以在看板上增加一个垂直字段特别来处理它，如此可以让我们更明确知道现在的状态？）
?移动
当开发人员遭遇无法立刻处理的问题而需要他人协助时，他需要移动多少距离才能找到问题的答案？是立即就能得到解答？还是需要继续移动到其他房间要求其他人的协助呢？这就是一种浪费。当然人不是唯一会移动的，各类文件也会移动，尤其是测试文件的流程，也可能造成庞大的浪费。（这种事务型的开销，在看板上面表现得越明显，就越容易被纳入解决方案的考量）
?缺陷
缺陷也常常被翻译成漏洞，是指在软件执行中因为程序本身有错误而造成的功能不正常、宕机、数据丢失、非正常中断等现象。缺陷（bug）所造成的影响，取决于它被发现的时间和它的大小，越早找到缺陷越好，在写需求的阶段就被测试人员发觉，是最好不过的。（文件审核有时可以帮助尽早找到缺陷）
能够尽早处理掉问题绝对胜于交给客户之后才发现，因此就有人发明，从一开始写程序就开始做测试的方法，称为“测试驱动开发（Test Driven Development，简称TDD），就是希望能尽早找到缺陷并即刻修复。类似的方法（ATDD、BDD等）大部分也都有自己的价值，也都在市场上占有一定的比重，但是软件界尚未找到一种足以被大部分程序设计人员完全接受的开发方法。所以借助频繁集成及发布是一种较容易受到客户肯定的行为，也是避免重大浪费的必要小浪费。
软件开发是一门艺术还是一门科学呢？由程序诞生的方式到我们除错解决缺陷的方式看来，艺术的成分还真是占据蛮大的比例，因此软件开发是一门工艺是目前比较被接受的一种说法。也就是说，我们很难完全不靠经验来开发软件，丰田式的生产方式对软件界而言仍是一种梦想，而我们也只能在类似的精益原则上尽量多学习和借鉴。
看到浪费
浪费只要看见了就容易改善。通过识别哪些行为是浪费，它们是如何造成浪费，可以让我们更容易看到真正的问题所在，也就能“消除浪费”。看板方法能让问题成为大家都知道并都看得见的事，如此便可以通过改善的方式（行为）来避免不必要的浪费，这是精益软件开发法的第一个原则。不浪费本来就很合理，但在运用上，由于软件开发有别于制造业，因此受争议之处特别多，宜视环境时时调整。图1-4是一个游戏开发公司的开发流程图，我们把大的开发步骤以及这些步骤所花的工作时间用时间轴画出来，就可以很容易看出对开发工作没有增值的部分，也就是浪费的地方。
图下方有两条时间轴表示浪费及增加价值的时间数值。上面一条是明确的时间值，下面一条则是指标式的示意图（图中用了两种不同的图示，目的在阐述数字大小代表的只是一个粗略值，在某些时候用比例来区分可能更合适些）。整个流程的统计结果显示在右侧，浪费的时间为 21.3 m（月），而真正拿来增值的工作是3.5 m（月），二个数字相除以后得到产出率为 14%。一旦通过分析让人们看见浪费的根源，通常就会开始产生一种想要改善的冲动，这便是可视化后的一种催化效益。
图1-4 游戏开发工作的流程图
软件是知识型的开发活动，对于浪费的界定比制造业复杂许多，所以请先判断它是“直接的浪费”或是“间接的浪费”。所谓“直接的浪费”指的是没有其他效益的活动，它纯粹就是浪费工时，我们很直觉地可以判断的浪费行为。“间接的浪费”是除了产生活动还有其他效益的活动，例如增加团队沟通协作的活动，我们便可以称它为间接浪费的工时。因此在我们考虑消除浪费的时候，间接浪费应该被排在最后，属于非必要时无须消除的范围，因为一旦消除间接的浪费活动，也就失去了它相对所产生的效益。
1-3-2 增强学习（Amplify learning）
软件开发是一种学习的过程。也就是说，开发人员学得越快越好，写的程序才可能越正确，对客户也越有利。因此程序设计人员从一开始就要下定决心把事情学好，然后再运用学会的专业知识来辅助写出正确的程序。
有趣的是，开发过程也是一种发现的过程，我们经常在创作的过程中有了全新的体验，所以写程序不全然是一种学习。很多时候，经验可以帮助我们学得更快更好，但创作则不只要依靠经验，专注力可能是最不可或缺的。
科学方法尤其适用在解决复杂的问题
科学方法是通过观察、建立假设、设计实验、进行实验、然后得到结果。有趣的是，如果假设越正确，你就不会学到太多东西。当失败率达到 50% 时，你会得到最多的信息，也就是学到最多。
工程师写程序时不也是如此？如果一次就做对了，可能表明完全没学到任何东西，只是在工作而已。传统的开发方式正是要求大家通过审慎的态度一次做对，而敏捷开发则是鼓励通过尝试、测试、修正的短周期来开发程序，所以自然学到最多。
我们写文章时，常常要修改个几回才能成章，何不让写程序也如此呢？！
其实写文章比起写程序要难上许多，但有一个最大的差别，文章的 bug（错字）很容易发现，但程序的缺陷却很难找到。就价值观而言，我们可以很容易以程序的应用范围来衡量其价值，但相对的写文章就很难评价了。二者在抽象的程度上很不相同，一个是越明确，我们认为越好，另一个则是越抽象，反而越是让人觉得受用无穷。
最小的成本产生最多的知识
既然程序开发是一个学习的过程，那么为了得到好的成果，学习善用最小的成本获得最大的学习效果，应该是程序设计人员不可缺少的技能。例如：如果测试成本很高，就多花些时间仔细思考，审慎检查后再动手，如果实验的成本很低，那它就是最有效的方法！
短暂的学习周期是最高效的学习过程
周期性的重构，一边开发系统的同时也在进行改善设计方案，这是我们产生知识的最好途径之一。衍生式的设计方式又称为浮现式设计（Emergent Design），它是架构设计师在采用敏捷式开发法时所遭遇的最大困难（因为不能做太多的预先设计，必须有问题做对应时才能做相对的设计），既然我们不能一口气就把架构设计完毕，那只有通过堆栈的方式，让问题来引导架构的途径。但千万别单让问题来引导架构，因为设计模式正是为了解答那些重复出现的问题而诞生的最佳解答。（其实是没有最佳解答的，说穿了应该只是最佳参考罢了，因为没有银弹，所以必须在研究清楚环境之后自己来，这也正是所谓高效学习的过程。）
测试是最好的反馈
传统一次性通过开发方式（single-pass model），是假设一开始便可以把开发的细节想清楚，针对每一个需求都一视同仁，一样重要，按部就班把所有的需求都做完，所以也就不会有太多的反馈，也失去了反复调整的机会。传统开发反而害怕反馈所带来的学习会破坏原先预定的计划。
这种思维造成学习被迫后延，直到最终测试的时候才出现，只可惜为时已晚，只能期待下一次的项目能够完全一样，这个学习的所得能派上用场。所以按照道理应该增加反馈，因为反馈是处理软件开发上遭遇问题时最有效的方法之一。以下是增加反馈的几点原则。
?实时反馈，在写完一段程序代码后立刻进行测试。
?运用单元测试来核对程序代码，而不是用文件来记录程序逻辑的细节。
?通过向客户展示来收集反馈和变更的需求。
团队同步学习
短的迭代循环是团队共同学习的最佳方式。同步是团队开发非常重要的一个步调，尤其当有一些项目出现测试失败后，遗留下来待解决的bug经常会让共同开发的同仁产生不同步的紊乱感觉，彼此之间误以为需要等待才能继续下去，造成学习中断的浪费。而迭代让大家有一个共同的起点，能够促使团队不断诞生新的学习机会，因此维持同步与采用短周期的迭代是团队学习的基本需求。
善用共同开发工具
一定要善用数字信息。无论是微软的 TFS 或是 Open Source 的 Git，在网络的运用上都具有绝佳的协同合作特性，这一点让程序代码不再是一个人的私人收藏，而是属于团队共同拥有的资产，大家都能通过信息相互学习。通过这些好的数字工具，不论是代码审查（code review）或是程序代码的签入签出（check inout）都成为公开的行为，这样的同步性可以导致更有效率的集体学习行为。
拜移动设备普及所赐，信息传递总是超乎想象的快捷，大大改善了工作流程上的事件前置时间（Lead Time），使得运用流程来提升团队效能成为这一代最重要的课题，因此能否善用数字学习也变成分辨优劣的关键因素之一。
愉快的心情是改善学习环境的重要因素，对于个人是如此，对于团队更见效益！没有比在心情好的时候更能充分吸收知识的了，保持愉悦是成功学习的秘诀之一，所以在每日站立会议时有鼓舞士气、提升团队和谐的行为，对一天的工作绝对有提升，应该尝试看看！相对的，心情低落是学习的一大障碍，管理者应该立刻给予关注才是。
1-3-3 尽量延迟决策（Decide as late as possible）
对流程而言：
等到真正需要做改变的时候再做决策，
提前的变更只会增加无形的成本。
对人而言：
等到做决策所需要的信息较充分后，
再来做判断会比较正确。
适当等待是做出好决策时不可缺少的行为
敏捷开发为了处理需求的不断变更，鼓励把决策的下达延到最后可以容忍的时间点再做决定。例如，打印机厂商因出货国家的电源种类不同所产生不同的库存种类以至于无法善用库存而伤透脑筋，如果采用最利于生产线的方式，便是根据运往地点直接配备相应的电源线。但如果采用决策的下达延到最后的概念，就是等货到了该国之后再由销售门市依客户的选择把电源线加上去，就可以避开这个复杂的出货问题了。
对个人而言，延迟决策是为了避免在早期信息还不够清楚的状况下就迅速做出决定或是进行评估，这是一种浪费，因为可能有很多东西之后还需要修改或是重做。
并行开发（Concurrent Software Development）
为了同步我们可能需要等待，而等待所换来的则是“顺序性”的同步工作。工作原本就可以采用异步、并行的方式完成，我们之所以没有采用是因为太复杂了，就为了让工作可以在同步与异步之间做切换，仅仅在处理那种复杂机制所损失掉的力量可能就会大过并行工作所能取得的收获！但那是多年前的说法，多核 CPU 创造了新的并行开发程序语法，而简易的语法造就了更快速的运算效能。
敏捷开发采用短周期迭代的方式来降低风险，就如同异步的语法也仅仅是在小范围的相同理论上运作一般，虽然多任务碍事（Multitasking is evil），但在受控制的小范围内实施却是利多于弊的。因此决策的时间往往需要参考并行工作的结果，所以尽量将决策延迟到信息较明确的状态再下达是一种较高效的做法。
最后负责时刻
最后负责时刻（The last Responsible Moment，LRM）并不等于尽量延迟决策。这是丰田精神转换到软件开发上较有争议的一个地方，“尽量延迟决策”针对生产在线的决策关键时间有相当积极的意义，并无争议，但对应到“最后负责时刻”这个并不是那么正面的用词，就让人十分迷惑。
最后负责时刻是指，当你再不做出“决策时，不做决策的成本就会高于做出决策的成本时，就称之为“最后负责时刻”。
很明显，最后负责时刻是针对在工作上可以获得较高的灵活性。这个词汇最初是由精益建筑协会（www.leanstruction.org）所提出，并在敏捷开发上经常被引用来处理尚不明确的需求，建议决策宜延迟到最后一刻，也就是状态较明朗的时候再做决策。延迟时间，让决策者有较高的灵活性处理其他事情。
谈决策：先深入或是先广度
在处理人工智能的程序里，总是会遇到这种应该先深入问题的探讨还是先广泛搜集更多类似问题再逐一深入探讨的决策性问题。举例子来说，假设我们要寻找一把放在大楼某个房间里头的手枪，只知道它被放在一栋四层楼高、每层有 5 个房间的建筑里，试问你要怎么寻找它？是先把一层楼都找完之后再换楼层呢？还是找一个房间后就换一个楼层？如何设计这个逻辑决策呢？
图1-5 处理人工智能的程序思考
深度优先（Depth-First）的做法就好比将一个楼层都找完再换另一个楼层，它的优点是简单，你可以很早就下定决策，接着照着做就是了，它可以迅速降低问题的复杂性。缺点是它会过早缩小各种可能性的研究，例如先探讨每个楼层会有几个楼梯？每隔几个房间就有一个楼梯之类的解题参考。
广度优先（Breadth-First）则会延迟决策，当搜寻到有多个楼梯在楼层与楼层之间时，就有机会再拟定新的寻找策略。初学者通常会采用先纵深的方式，等到熟悉后有经验后再做其他尝试。先纵深或是先广度并没有绝对的对或错，经过学习后的再进化才是重点。但不论采用哪一种策略，先搜集相关的专业知识都是不可缺少的（参考上面找枪的例子，设计者通常都会留下一些蛛丝马迹，让有经验的搜寻者做判断的依据，目的当然是让用户能够迅速通过学习来累积经验，期待下一次会有更好的表现）。
直觉式的决策
最后我们来谈一下相对于延迟决策的快速决策：直觉式的决策，这是一种类似“急诊室的分类法”，先做简易分类后立刻做决策（括号中是处理等候的时间）：
?第一级：复苏急救（须立即急救；例如车祸大量出血、意识不清）
?第二级：危急（10 分钟；例如车祸出血，但生命稳定）
?第三级：紧急（30 分钟；例如轻度呼吸窘迫、呼吸困难）
?第四级：次紧急（60 分钟）
?第五级：非紧急（120 分钟）
TIPS
进入急诊室后，请向医护人员询问您属于第几级伤病？需要等候多久？
通常，救护人员和消防人员很少做决策，他们直觉地依据守则（通常是经验）走，而非理性决策过程！理性决策会先做分解问题、移除上下文、应用分析技术、进行讨论等步骤，这种理性的过程会在有意无意间忽视人们的经验，而经验正是敏捷开发最有利的参考。如果能依靠理性分析指出什么地方存在不一致，什么地方忽略了关键因素，固然很好，但他远远不如直觉来得有用，因为理性分析移除了上下文之间的关系，所以不太可能观察到严重的失误，这就是经验最有价值的地方。培养经验最有效的方式就是通过阅读，把别人的经验变成自己的知识。
1-3-4 尽快交付（Deliver as fast as possible）
在制造业中交付产品越快的公司必定越受客户青睐，软件业也是如此。但在制造业里对手很快就能掌握到你快速生产的秘诀，所有的厂商都会开始模仿，一下子大家都学会了，你的优势很快就没有了，而软件业就很难做到这一点！这是一种最富有价值的优势！
为什么要快速交付？
客户喜欢快速交付。因为快速可以让他拥有更多的准备时间，也就是延迟决策的机会（你一定想到了，尽快交付原则正是对尽量延迟决策原则的补充，当你能够越快交付，可以得到延迟决策的时间就越长）。对于一些客户而言，快速交付也意味着更快的客户满意。对软件业而言，能带来业务上更高的灵活性，更容易受到客户的信赖，当然也就间接获得客户更高的配合度。
老板、客户都喜欢快速交付，但工程师如何处理呢？如果你一向单打独斗的话，为了做到快速交付，可能必须花上一番功夫来设定一套较完整的交付流程，这是可行的做法，也是很好的练习，但太辛苦了！而且这么做只是治标，对工程师而言是好的练习，但很辛苦（维护就更辛苦了）。如果能从开发方法的角度来看这个问题，实行治本的理论远比治标划算多了，以下便是精益软件开发的做法：采用看板方法来实践拉动系统。
拉动系统（Pull System）
拉动系统是一种通过只补充已消耗的资源来达到控制资源流动的生产管理系统。著名的限制理论（Theory of Constraints，TOC）中的“鼓-缓冲-绳”（Drum-Buffer-Rope）正是拉动系统的最好范例，所以也常常被称为缓冲管理法（Buffer Management），看板方法正是依据拉动系统所设计出来的流程控制法。拉动系统是一种“自动交付”的工作方式，你可以将需求规划成一种事件，由事件来“拉动”工作。而“被动交付”则是一种运用排定日期的工作方式，时间到了就被“推动”去工作的方式，因此被称为推动系统（Push System）。Scrum 的任务板（Scrumban）也是一种拉动系统，只是它并不强调流程的管控。
Windows用户应该十分熟悉这种事件的处理方式，让事件去触发相对应的行为方式称为事件驱动模式，是一种实时性（JIT）的处理方式，系统可以省去一个一个轮流查看是否有工作要处理所耗掉的时间以及 CPU 浪费的效能。在制造业里，由看板来作为启动 JIT 实时生产的自动化机制，这便是看板又被称为信号板（Signal Board）的原因，当有信号进来时就去拉动下一个工作的项目，而无需由工头做决策，下达命令指挥工人该做什么。也就是说，管理者不必吩咐工人该做什么，工作本身就能起到引导作用。复杂的软件开发工作也存在同样的基本问题，项目经理（PM）所依靠的“日常进度表”很难描述许多细微的工作分配，此时拉动系统无疑是最有效的安排，这也是让团队成员自己有效安排时间的好方法。
TIPS
员工知道在上班时间如何有效安排自己的时间表吗？
复杂的软件开发无法像制造业一般采用细粒度的排班表，但对知识工作者而言，在办公时能够采用“自我引导”（自觉）应该是最有效的方法。员工在自我管理的情境下容易为自己的行为负责，也就能主动负责，对项目而言这是达到成功的最佳保障。运用看板实施拉动系统是最能做到这种直观式管理的方法之一，看板上有大家的工作状态，团队工作的进度、效能及瓶颈，每个流程状态大家都一目了然，这样的透明度最适合自我引导的状态。
善用排队理论（Queueing Theory）——看板方法寻找瓶颈的基本技巧
缺人手！你可能缺少分析人员或是找不到人手来帮忙测试……，当资源出现短缺的现象时，排队的状况便会自然发生。它是最浪费时间的东西，看起来是单纯的资源不足所造成的现象，但不容易改进。排队理论的出现是表示有许多地方可以进行改善的一种征兆（资源一定出现了存在有不足的地方），事实上它是我们在运用看板上发现问题跟解决问题的最佳机会。
拿饮水机的例子来做说明。在饮水机前排队去水。排队当然是按照每一个人到达的时间顺序，而不是每一个人口渴程度来调整，所以当散步过来喝水的人排在刚跑完步的人前面时，若依照需要水的程度高低来定义服务的效能，便可以定义它是低效能的，反之则是高效能；这时候当我们考虑增加效能时，就可以让跑步的人先排到前面来。简单的区分可以让服务满足真正的需求，这就是看板想要做到的事：暴露需求或者瓶颈所在，然后修正它来达成真正的需求。（具体作法是，依照对水分补充的急切性，适当的分成二列的排队取水队伍，急需水分的队伍每次可取水二名或调整成更多名的数量，如此便可以用管制数量的方式来协调急需性）
另外要补充的是，在排队时，你总是希望能够尽量缩短等待的时间，毕竟，加入排队是为了达成某种目的。无法让你达到目的的唯一原因是，达到目的所要的资源有限（也就是资源不足），因此便形成排队的现象，增加了时间的浪费。所以资源的限制才是最主要的原因，但有时候也可能是设计者为了保护系统资源而做的限制设计（常见于云端应用程序的设计）。
强调优化组织的最佳途径是强调组织的吞吐量，因为它是获利的关键，而增加吞吐量的方法便是找到阻碍工作进展的瓶颈，并对它进行修正，这一点在网络时代更是明显，因此我们可以预见云端将是这个时代企业的必然战场所在。（看板方法受到限制理论极大的影响，安德森（David J. Anderson）原先把自己的理论称为“鼓-缓冲-绳（Drum-Buffer-Rope）”，直到在微软的项目试行这个理论的成功并逐渐发展出自己的架构后，才改称为“看板方法”。）
是否值得投资购买新的开发工具
篮球赛的抄截快攻是翻转战局最佳的方法，原因是这一来一往的差距是 4 分不是 2 分。
开发人员可能会提出采购一种新的开发工具，因为他们认为可以加速开发的速度，而你会估算一下省下来的开发时间是否值得购买这个工具。这种经济模式的决策，往往都容易忽略无形的、超过成本效益的影响；较正确的做法是，采用风险管理的概念，将不购买新的开发工具所可能造成的延误成本加到损益表内进行评估，这样做更为合理。
投资购买新开发工具的价值，绝对不是它表面上的金额大小，而是它对开发团队的影响，这才是真正的价值所在。
1-3-5 授权团队（Empower the team）
精益理论有以下两个假设。
1. 成熟的组织关注的是整体的系统，它不会专注于优化分散的部分。
2. 成熟的组织强调的是有效学习，它会授权予工作人员制定决策的权力。
弗雷德?布鲁克斯（Fred Brooks）在《人月神话》中引述了 IBM 软件业务负责人伊尔?惠勒（Earl Wheeler）的一番话：“（近年来）关键性的驱动力是权力下放，这简直太妙了！质量、生产力和士气都得到了提高。”
一群积极创造增值的人员才是组织真正的核心
上面那番话已经有 40 多年的历史了！每每在企业内部讲到敏捷开发（Scrum）让团队自我管理的时候，还是经常接触到主管们疑惑的眼神。这些专业软件开发人员天天都在学习，他们不断地改进自己的工作方式，而组织的责任则是提供时间和设备，让他们圆满完成工作的。从管理学的角度来看，让团队自我管理可以在工作上获得最佳的效益，所以管理者真正该做的事是采取措施使团队能够增值。
我的团队会自我管理吗？
管理者难免担心，并且容易怀疑自己的团队是否能做到自我管理。我可以放心让他们管理自己吗？这是十分正常的，就好比你担心孩子们没有自己在身旁时他们早上会爬不起来、上课会迟到……等一样。这里有一个简单的方法教给你，就是帮他们制定简单的规则，然后把你的担心换成信心。
让团队自我管理一直是一个让主管头痛的课题，到底什么是简单的规则？多简单才够呢？
简单规则法
管理学上有许多简单法则可以借鉴，这里我采用弗里德曼教授在货币控制上发明的“简单规则法”，他认为：“假使每种情况都根据它本身的处境加以考虑，那么，在大部分事例中就可能做出错误的决定。因为决策者仅在一个有限范围内进行考察，而没有办法照顾到政策的全面后果，也就是说，你无法面面俱到，考虑得丝毫无错！另一方面，如果我们对一组合并在一起的情况采用一般性的规则，那么，规则的存在本身就会对人们的态度、信念和希望产生有利的影响，而这些影响是在对一系列个别情况采用完全相同的政策时考虑不到的。”
同样的方法适用于让团队自我管理的法则，管理者应该只专注于一些可以合并考虑的情境下采用一般性的规则来管理，目的是让工程师可以专注在他的工作上，使其有所发挥。因此管理者只要专注在一些较明确且需要注意的规范上，并运用一些基本规则来处理，便可以称之为简单规则法。
举例来说，请假的规定，许多新创公司都相当放任员工，完全没有明确规范在一年内一个人可以请假多少天，理由很正当，因为公司在意的是你的产出而不是你上班的时数。然而，没有明确的规范反而会让员工无所适从！可以任意请假本来是一件好事，但在团队一同开发的协同工作时，协调与妥协的范围很容易因为假日计划问题而复杂化。过去因为受限于一年的休假日不多，所以容易规划，但现在几乎一整年、时时都能包含在内，考虑的范围变大了。现在必须考虑到公司与家庭或家庭与家庭之间的配合问题，在这里人们很容易为了不伤害大家感情的前提下而产生所谓的相怨，相怨是一种假性的和谐，对团队的协作是一种浪费的行为应该避免，因为人们会为此而互相礼让，从而使工作出现闲置的状态。
一个绝佳的范例，是制定简单规则让团队来遵守，团队很快就能依此而产生效能的好例子，那就是实行精益咖啡（Lean Coffee），详情请参考附录。
简单规则的另一个好范例就是台北捷运局。它仅仅制定一条规则，就让所有搭乘捷运的乘客都能遵守：“搭乘电扶梯请站右侧，左侧让给急着赶路的人走”，这一条简单的规则非常成功，甚至影响到全台北市及来台的观光客。
简单的规则让团队显得一致，而一致的目标让团队更加团结，混乱与充满相怨的环境只会让团队失去内在成长的动机。
越优秀的团队越适用简单的管理规则，但那是在他们表现优秀的时候。
你的团队优秀吗？许多新创公司通过到处挖角的方式聚集了一群优秀的工程人员，给他们最好的环境和足以满足他们的开发设备，但是却迟迟无法使他们做出卓越的产品。
原因当然很多，但基本上在他们尚未表现优秀以前，简单的规范与束缚反倒让他们能够发挥所长！让他跳脱困境只是证明他是优秀的，这时候便可以逐渐取消束缚，让管理的规则越简单越好，因为他们已经可以工作得很好了。
你做过 Scrum 了，但是没看到效果，接着采用 Kanban，听说效能可以提升一倍以上，但这件事始终没发生，现在你开始放任技术好的工程师来担任领导（这种做法叫 Technical Lead，谷歌就是这么做的），接下来呢？
很明显，你的问题并不在于采用哪种敏捷法则，而是在于管理，即如何正确管理团队。
1-3-6 嵌入完整性（Build integrity in）
没错！这正是我需要的东西。
——客户
这是一个多变的时代，许多东西的定义也跟着一直在变。例如 App 的好坏改变了质量的定义，当你安装了一个让你恨不得立刻推荐给所有朋友的 App 时，不管它有多少缺点，你在推荐的当时一个都不会提到，因为它已经满足你真正的需求了，所以你只会注意到它做了些什么，而不会在乎它的缺陷，也就是所谓的“情人眼里出西施”，此时的质量就是西施。
如何造就这样的产品呢？
波彭迪克夫妇将上面这种感知区分为感知完整性（Perceived Integrity）和概念完整性（Conceptual Integrity）。
你一定也有过这种感觉，例如常常用谷歌来搜信息，谷歌的搜索引擎就是最典型的感知完整性的例子。当你要寻找数据时，就一定先打开谷歌，原因可能是它很快，让你觉得找东西一点也不烦，还有就是打错字了它也照样找给你，就是这些特征让大家持续使用它。换句话说，就是谷歌打动了人心，这种特征也称为外部完整性。
另一个例子来自微软办公系列的 OneNote 产品，它兼具感知完整性和概念完整性（又可称为内部完整性）。不论你在哪一个办公应用产品中做 PPT，或是在 Word和Excel 工作，只要想到要把数据记录下来，你就会点击任务栏上的OneNote图示，启动它来做笔记，原因是它什么都可以记，没有特定格式限制。不管放进去的东西是什么格式，放进去就对了，太符合人类想储存东西时的想法，你不会想先做分类再来记录的。因为方便使用（外部完整性），而它又能融合办公应用多种工具存取能力的一致性（内部完整性），所以OneNote就成了办公应用中最受欢迎的工具程序。
根据波彭迪克夫妇的论点，认为要构建具有高度感知完整性和概念完整性的系统，应该在客户与开发团队之间以及开发团队的上下游过程之间形成出色的信息流（information flow），而此信息流必须考虑到系统当前和潜在的用途。具体怎么做呢？
?增加全体开发人员在应用领域方面的知识。
?接受变更，并将变更看成是一件正常的过程和容纳新设计及决策的能力。
?营造提高沟通能力的环境，以便对人员、工具和信息进行整合。
成就感知（外部）完整性
每天都能持续把客户的价值观变换成细节设计给开发团队，不断积累开发部门在感知完整性方面的决策能力。但是容忍过多的变化容易让开发团队不断在做返工的动作，成本也会不断增加，如何是好？这一点可以参考 Scrum 的迭代开发模式，也就是冲刺（Sprint）的做法。
在一个短的开发周期内尽量让开发人员不受干扰，全力开发产品直到 Sprint 结束时再对客户进行展示，并运用这个时间点来接受客户的反馈，将其纳入未来的开发工作。
成就概念（内部）完整性
概念完整性表示系统的核心概念是否能稳定内聚而发挥整体效用。这是架构性的问题，它牵扯到各个组件之间是否匹配并且可以发挥作用，也就是说，架构是否能够有足够的灵活性、可维护性、有效性和响应的平衡能力，说穿了就是能有效响应客户需求的架构设计。这是赋予概念完整性的能力，它有着一种天生的复杂性，为了让团队能够克服其中的复杂性，必须建立良好及有效的沟通机制来适度降低复杂性，这可以依靠一种看似重复工作但又像是设计的行为来实现，我们称之为“重构”。
重构（Refactoring）
改进不只是为了满足客户需求，改进之所以必要，是因为复杂系统的某些效果在设计时未能受到充分理解。重构是一种按部就班的设计方式，就是先设计让它能起作用，了解它的缺点，然后再对设计加以改进，这便是重构式的设计。
重构式设计属于浮现式设计。一般的工程师只是把重构当成重新整理程序，在重整的过程中尽量让输出输入的结果不变，只改善程序代码的正确性与简洁度。这是基于测试驱动开发的理论所发展出来的重构方式，其目的与基于浮现式设计所做的重构是不同的，后者是用来改善设计的。
如果是基于测试驱动开发重构，第一个重构动作应该是重新命名变量或函数。如果是基于设计的重构，第一个重构的动作应该是拿解决的问题套用现有的设计模式，看看是否能找到合用的模式，然后进行延伸式的套用让模式融入到现有环境中。
有以下两种不同目的的重构。
?为了解决程序稳定性及增加可维护性的重构。
?基于浮现式设计所做的重构。
一般而言，在采用敏捷迭代开发方式时，都会害怕这种增量式开发方法会把架构设计弄得支离破碎，许多设计一直被需求变更弄得失去效用或成为累赘。请注意一点，出色的设计本来就应该随着时间的改变而能持续演进，因此重构式设计正好能够符合这个现象。
重构不是一种浪费，当我们在向客户提供商业价值时，重构反倒是避免浪费的方法之一。
1-3-7 着眼整体（See the whole）
一个系统的好坏不是由单一组件来决定的，也不是各部分的总和，还要加上各部分相互的协作能力。
── 玛丽汤姆?波彭迪克
这一段话拿来描述由人所组成的开发团队也十分适用，一个产能好的开发团队需要的不只是几个出色的工程师，团队的协作能力也是效能的一大因素。
局部优化易造成舍本逐末
开发团队需要注重全局，要避免局部优化！这里所谓的“局部优化”，是指单位与单位之间或公司与公司之间协作开发时，会刻意夸大自己在合作事件上的重要性，这种做法会让自己做的那一部分增加被重视的比例而失去凝聚整个系统的重要性。当然，这种想法也适用于开发团队，大家都强调自己开发这部分的重要性，也一样会造成局部性能的受重视，而失去兼顾全体的性能。同样也会发生在个人身上，如果人们在开发一个系统时，处处都优先考虑自己的专业兴趣而忽略整体性的考虑，则产品就会出现局部优化，导致共同利益受到损害。
在开发上过度注意细节、在的执行上也都可能会发生局部优化。
?因为过度注意细节而容易产生局部优化
运用连续目标来修正短视可能是最有效的方式。为团队制定一系列目标，可以让团队不过度注重于细节，能够自动克服这种容易让人不能自拔的陷阱。举例来说，移动设备 UI 显示的重要性是不容忽视的，当大家对显示画面都有意见的时候（人的审美观是很难一致的），团队就很容易落入一改再改的现象而耽误进度；如果能紧守目标，让网页真正要表达的意图能够明确传达给用户，目的就可以算达成了，也就不会因为局部因素而耽搁进度。
在敏捷迭代开发所采取的方式是，让细节被较短的循环所约束。每一个迭代之间以达成既定目标为前提，就不怕过于注重细节而产生局部优化的现象。运用目标来驱动实操，可以避免过于关心细节而造成局部优化的问题。
?因为考绩的因素而容易产生局部优化
2014年日本索尼企业的巨大亏损，该公司宣称是因为不正确的考绩方式所造成的，而这已经不是第一起因为考绩方式而导致企业失去竞争力的公司了（外传微软总裁鲍默尔也是因为不正确的考绩方式而导致微软战斗力下滑）。管理学上著名的霍桑效应（Hawthorne Effect）是指由于受到额外的关注而引起努力或绩效提升的情况，正好可以说明员工因为考绩方式而造成员工为了求得好的考绩刻意去做有利于考绩却无助于生产力的工作。
?因为合约的因素而容易产生局部优化
签约的目的是保证一方能够相信另一方会履行合约的内容。签约的方式可能是固定价格的合约、可能是多阶段的合约或是目标成本的合约，但考虑只有一个，即交付完整的产品。
其实客户需要的不是软件，他们要的是解决他们的问题。
但合约的内容将牵引着双方走向合约上可以确认的项目去做开发。在项目的时限结束时，客户会得到合约上验收项目的组合，而不是一个完整的、用来解决他们问题的系统软件。这就是跟着合约走的问题，到最后你只会依据验收的项目一股脑儿完成项目，完成的部分就只有验收项目的部分，合约会带你局部优化软件。
那敏捷又能如何处理合约呢？敏捷式合约，当客户尝试过第一次与敏捷开发团队的合同之后，在下一次签约时，对签约的内容就变得不是那么在意，真正重要的是如何把需求描述完整。因为我们把开发工作切分成一个个的小周期，而每一个周期的产出客户都看得见，而且还可以就展示的结果反馈意见，让产品适当加入真正需要的功能或者是变更设计。用来配合一个一个迭代开发的是指定需求（Product Backlog）的优先级别。
让需求有优先级别，彻底瓦解局部优化
很多正在学习 Scrum 的人士都容易忽略确定需求优先级别的重要性。将这些需求积累起来一个一个做下去，每每做完一些需求客户就可以看到成果，满意的话，就继续做下去，不满意，就变更需求。这样做下去的结果应该预期到，那就是还没来得及把需求全部做完，客户大概已经急着要求先上线，因为你已经解决了他的问题！
1-4 结论
当你站在战情室（War Room）的屏幕或是团队的工作看板前面时，大量的信息充斥着整个房间，待决定的事项一条跟着一条等着你来定夺，到底如何做决策呢？这个时候任何拖延都可能导致最后失败的因素，应该依据什么来做决定呢？前面提到的“精益七大原则”正是用来协助决策的。我知道，你可能根本没有郭台铭才有的上面这种排场，你可能只是站在为数不多的团队流程看板前，只有少数几个人等着你的决定，不用怀疑，同样的“精益七大原则”在这里也一样适用。
从哪里开始呢？先从消除浪费原则开始，凡是没有增值的工时就是浪费的，但是请先判断它是属于直接的浪费或是间接的浪费活动，在非必要的情形下不要消除间接的浪费活动，因为删除它也将连带失去它所带来的间接效益，而这些效益通常都是无形而难以衡量的。
七种浪费的类别（部分完成的工作、额外过程、多余功能、任务切换、等待、移动、缺陷）是我最常拿来解读看板方法的依据，每每在设计看板形式时，总会想办法把这些特性直接包含进去，让它能够自然发生，只要有所遗漏就赶紧贴上一张贴纸或是加上特殊注记，就为了避免遗漏。但是缺失偏偏就是不小心才会发生的事，所以熟背这些原则，在解读看板时可以帮助你不容易遗漏缺失。把它背下来吧！把它们熟记下来吧！如果实在记不住，做个标语把它放在看板旁边也成。
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
