《A++ 敏捷开发》-1 如何改善
1 如何改善
敏捷开发过程改进案例
5月
A公司一直专门为某电信公司提供针对客服、线上播放等业务。
张工是公司的中层管理者，管理好几个开发团队，有5位项目经理向他汇报。
他听说老同学的团队都开始用敏捷开发，很感兴趣，便参加了几次敏捷交流会，觉得可以解决很多开发团队的问题，尤其是可以快速交付给客户。
他便提建议给部门经理推动敏捷开发，找咨询公司做相关培训，例如SCRUM Master 内部培训，然后全面开展实施。
开始时，部门经理有些怀疑，问：“听起来很吸引，但后面那些工程文档都不做，会不会影响质量和交付？客户都是专业做电信的，不缺钱，但是对质量要求很高。”
张工解释说：“只要利用敏捷把过程变成迭代，快速交付、改善工程的问题不难，主要是人的问题。”
部门经理听到敏捷可以比以前更快速交付，因之前客户经常抱怨项目延误，他也希望可以改变，就答应了。
8月
开发组长王工，三十出头，毕业后一直做开发，一年前晋升为组长。周五下班后与朋友喝酒，很开心地说： “太兴奋了。我们团队刚参加了两天SCRUM 培训，并指出我们以前按传统瀑布式开发的种种问题。我们会两周一次迭代并割接上线，还会与用户代表定期交流，不再会像以前几个月交付后才发现开发出来的功能不合需求。
现在团队合作不像以前只按工种工作，也会跟产品经理、业务方面更充分合作，给客户带来更高价值。
工作方式也会改变，以前要写需求、规格说明书，现在简单化成用户故事和产品需求卡片，以前我们要做详细项目计划和甘特图。现在会改成用燃烧图和看板。 每天用便利贴去谢要开发什么内容贴在白板上面，我们会改成叫SCRUM Team。工作区周围都有SCRUM 的海报，提醒我们SCRUM的重点。我们也没项目经理了，自己管理自己。部门经理会变成产品负责人，敏捷开发方式让我们团队自己做决策，不仅仅是技术方面，项目相关的也由我们项目组一起讨论决定。”
9月
王工的朋友老杨周五晚喝酒时问他：”你们团队使用敏捷SCRUM后，效果如何？”
王工立马面露笑容，充满自信地跟大家说：“我们培训后就使用SCRUM的方法，每两周一个冲刺，每次冲刺前都会用故事点来估算每个功能多大，然后按本次冲刺的资源，估计可以完成多少功能。然后用看板来监控模块完成的情况，哪些正在开发中？哪些已经完成？团队和管理者都可以一目了然，不用像以前......。”
“听你这样说，我也要尽快提议领导引入敏捷开发。”
“我还未说完，我们每天早上也按照SCRUM的规定站立会议，每人说自己完成了哪些任务，今天做什么......。”
10月
喝酒时老杨问王工：“你们项目如何？”
王工听完，没有立马回应，把注意力放在窗外的大街上，想了一下，然后说：“我们本应上周要完成一次冲刺后的割接上线，但被推到下次了。”
“为什么？”
王工说：“我们按培训学到的做冲刺计划会议，按照产品的待办事项列表，团队利用扑克牌一起估算每一事项所需要的时间。我们总共8位开发人员，其中有一半是刚毕业不久，但大家刚上完培训，很有信心，虽然技术主管张工对我们的估算有些顾虑，觉得我们太理想，但大家刚培训完敏捷，张工也希望让部门经理尽快看到敏捷开发可以加快速度，我们就按这‘进取式’估算开展两周冲刺。但因新人多，编码水平有限，虽然大家已经尽快把开发出来的代码交给系统测试人员手工测试，依据测试发现的缺陷修正再测试，但割接上线期限前4天还有很多Bug没改好，最后3天，基本是天天加班，最终到上线期限仍然有不少问题，最终割接前测试，还是不能达到客户要求的水平，没办法上线。大家确实都尽力冲刺了，但未能达到我们本来希望的结果。”
“你们开发人员在提交代码到系统测试之前，有没有自己先自测？”
王工说：“我们敏捷开发每天早上站立会议上都用看板，记录每个模块的进度完成情况，开发编码人员都说自测过。”
“如果开发人员能自己把握好交付代码的质量。不应该等到系统测试才发现这么多问题要解决。你们团是怎么做自测？有记录吗？”
王工说：“这我就没有详细问了，因为我们学完SCRUM后，大家更关注开发速度，用看板保证按计划的进度，不延误。但没想到后面缺陷会这么多。而且有些问题改完以后还会导致另外一些Bug发生。到了最后，因为赶时间，大家对修改Bug已经麻木了。”
“你们之前不是都有代码评审和扫描的习惯吗？”
王工说：“之前我们确实比较多评审，除了评审核心设计和代码，我们还要求组长抽查新人开发的代码，并且要求提交代码前必须通过扫描。但我们为加快速度，没有硬性要求必须先通过扫描。经你一问，我想这也可能是出现很多Bug的原因之一。”
“你们有没有事后迭代复盘？复盘可以帮团队分析之前有哪些不足，后面改进。”
王工说：“我们都交付不了，哪里有心情来做回顾、复盘。最后几天冲刺，大家每天都没睡好，大家都只想回去好好睡一觉。”
11月
部门经理之前收到客户总监电话，投诉一些技术缺陷，导致好几次不能按计划上线，问为什么正在交付的软件质量变差了？
张工被问到是什么原因时无法回答，只能说立马回去探索原因，尽快汇报。
张工从部门经理办公室出来后，找其中一位项目经理李工喝茶，问他对今次敏捷改革的意见。
两人都赞同敏捷开发应能帮助团队提升，当张工问李工有什么可以改善的地方，李工说：“让团队自主是件好事，但因为我们专注做这块业务已经很多年了，本来业务的变化不多，只是一些功能微调，所以开发人员尽量不去修改核心代码，怕改动了反而会影响投产，无法切割。为了不触及原始代码，新代码都只能在核心的外围去写，但这种做法效率很低，无法有效长久维持，到时会被迫重写整个产品。而且懂老代码的开发人员大部分都离开了，代码维护越来越困难。
敏捷教练强调团队自主管理，给团队空间发挥。但SCRUM的教练缺乏软件工程的基础，只懂项目管理过程。所以他们也解决不了软件相关的问题。只是把精益管理怎么做迭代、怎么做回顾这些基本过程再解读一下，解决不了实际问题。”
张工说：“很赞同，这是必须要解决的问题。但现在燃眉之急是要解决主管提出的客户投诉不能按时交付这紧急问题。不然我们以后也不敢再提敏捷开发了。”
无论张工或李工也没有能去总结出什么好的解决方案。现在推行敏捷才刚刚3个月，绝不能打退堂鼓，回到本来的状态。但应怎么解决敏捷带来的问题，挽回部门经理与客户的信心呢？
= = =
从上面的SCRUM案例看到，本来管理层希望利用敏捷开发，加快软件开发的交付、减少延误、令客户更满意。但因为只注重项目进度是否延误，但团队没注意如何改善软件开发本身的质量，也因为团队成员能力不足，开发出来的软件缺陷比以往还多，导致后面大量返工，恶性循环，后面更导致延误和客户投诉。
因为软件本身设计有问题，导致软件难以修改，开发人员都不敢改动任何代码，怕可能会引起系统崩溃。
怎样可以确保开发出来软件的质量？
敏捷开发有很多种方法(SCRUM只是其一）,因为目的不仅仅是管好项目进度，也要确保软件产品的质量。所以SCRUM只包括项目管理部分，不全面。反过来，例如极限编程(XP eXtreme Programming),因它的发明者Kent Beck 本身是一位精通面向对象的编程员，所以XP不仅仅关注项目管理，也包含编程的最佳实践。下图是Ron Jeffery 把XP的重点画成从外到内3层：
SCRUM只包含了外层的部分，缺乏中间和内层元素。 按XP的12实践（详见附件）都做到了便可以解决张工的问题吗？
如何改善
既然SCRUM方法有不足，XP方法能解决开发质量问题，是否团队学好XP便能帮助团队做好敏捷开发？ 怎样才能不断完善？
先问你以下关于汽车公司的问题：
T公司在60年代，在销售、生产成本都远远不如G公司，但它每年生产率都一直提升。请猜猜T和G是那家公司？ （提示：两家都是世界级汽车公司，现在你还能买到它们生产的汽车。）
= = = = = = = = = = = =
G 是美国通用,T是日本丰田。
为什么丰田从一家战后小公司能提升为世界最大(#)的汽车公司？
(# : 2023年底，总收入可能是大众第一、丰田第二，但丰田销售数量世界第一。）
丰田故事
二战后50年代,丰田汽车规模很小，经营很困难，在破产边缘。 但丰田创始人喜一郎先生明白美国生产线的弊端，意识到未来的汽车生产必须是Just-In-Time：
- 每一辆都是按客人订单订制：例如颜色、配置、左右钛等。
- 从钢材原料开始，整个生产线零等待、零浪费。
每个工作步骤所需配件按生产需要到达（不晚到也不早到），把生产过程中的配件降到零。
喜一郎先生安排总工大野耐一去美国汽车公司考察。
喜一郎
大野耐一
| 为什么福特Model-T出名？ 它是第一辆一般人买得起的汽车。首辆现代汽车是由德国奔驰(Benz)于1885制作，但是这些第一代汽车都非常昂贵。
|
Federick Taylor 与科学管理(Scientific Management)
| 十九世纪末美国很多工业快速扩张,Taylor先生发现当时很多工厂生产力很低，例如钢铁厂。他是很落地、实干的人，就想有什么好方法可以让提高生产力，工人也多赚些钱。他发现很多工作都未设计好，未能好好利用工人，他针对工作本身做很多科学研究，测量每个工作应该多长时间，怎么做最好，然后按他的最佳设计把工作细分，也同时要求公司提高员工的奖励，希望工人看到因科学管理，提高生产，个人也受益。1890年，他加入了Bethlehem Steel——钢铁业的大公司，帮它设计了很多奖励制度，也设定了一些叫工业工程师(Industrial engineers)岗，发现生产力可以提升30-40%。后来公司被收购，他也被辞退，便去做顾问。当时都没有顾问这个职业，他可算是全球首位工程顾问。 |
总工大野耐一先生从美国的超市（非汽车公司）得到如何做Just-In-Time的启发，回国后就开始在丰田全力推动。开始时，很多人都觉得Just-In-Time 这个愿景好像是远不可及的梦想。而到了今天，现代汽车生产都基本做到了当年喜一郎先生和大野耐一先生的梦想。（详见附件）
水面下的管理思路
为什么丰田能成功地把汽车生产做到 Just-In-Time ，超越西方的巨头，使日本汽车制造过程成为世界“标准”？
但我们不能单从表面看这“系统”的方法和技巧，例如大家都熟悉的看板管理（他的竞争对手通用、福特肯定都学过），更重要是了解背后的管理思路。我们看看下面丰田七个习惯，开始了解水面下的“系统”:
- 容易实现的目标不是好目标
- 不以“我们公司”作主语
- 重复五遍“为什么”
- 持续改善没有停止
- 成长比成功更重要
- 以忙碌为耻
- 从心里相信“大家的力量”
容易实现的目标不是好目标
不是“削减一成”，而是通过“取消一个零”来发现浪费
“如何把原先需要3小时的工作，改用3分钟完成”
如果听到上司以上要求，你该怎么回答呢?如你回答：“这太强人所难了”、“绝对做不到”，请读以下丰田案例。
| “单分换模(Single Minute Exchange of Die)”例子： 1965年，丰田汽车在推行丰田生产方式时遭遇到瓶颈：装置更换时间太长，其中特别是500吨冲压机和1000吨冲压机的模具，更换时间长达2~4小时。如果不缩短这两个模具的更换时间，就不可能实现多品种少量生产方式。 要缩短时间，把内部装置更换和外部装置更换清楚地分开来是关键。能在外部装置替换作业中进行的工作，就全部在外部装置替换过程中实施。同时，分别对内部装置替换和外部装置替换进行改善。通过这种方法，装置更换时间缩短为一个半小时。 改变汽车生产的单分换模的秘密 |
标杆管理 (Benchmarking)
很多公司都会用百分比来设定改善目标，但改善了百分比，不一定代表质量有改善，例如某快递公司去年送包裹未按时送达占8%，今年是6%，好像已经改善了2%。但去年托运的数量是500万件，所以8%是40000件。今年的数量是750万件，所以今年的6%就是45000千件。
所以今年包裹延误增加了5000，这样非但没有任何改善，反而服务变得更差了。所以更重要是看数字本身。容易达到的目标，不是好目标。所以丰田一般会选行业里最强的对手作为基准（标杆）。
1965年，美国通用汽车公司是世界顶尖。例如销售额的规模，丰田与通用是1:60，完全不在同一个层次上。成本上丰田对通用是1:0.5，成本是通用的两倍。
丰田把当时顶尖的通用公司当成了自己进行标杆管理的对象。
如果丰田某零件的成本价格是1000日元，通用是400日元。丰田会把通用的400日元，作为基准成本价，把原料价定为400日元，把差额600作为“不必要花费”，让团队立马改善，尽早达到标杆。
丰田（如下图）很注重各种标杆，例如内部标杆、竞争性标杆等。软件开发也应该同样利用数据来制订量化目标。
| 某家专门开发金融软件产品的公司： 研发总监问我“你接触这么多国内的企业，觉得有哪家优秀的，可以作为我们的标杆？ 我们尝试寻找，但还未找到。有些优秀的公司，但它们业务跟我们不同，我们产品是面对企业，也非嵌入式软件（我们不生产硬件）。” |
从以上对话看到越来越多高水平开始用标杆管理，但标杆必须是比自己高很多才有作用。
不以“我们公司”作主语
- 不是从“专业”的角度，而是从“顾客”的角度生产产品。
创业大忌——闭门造车,所以丰田的原则，对客户有用就一定做出来，但对客户无用或者不想要，就绝不生产。
要创新必须从“顾客”的角度看，不单从工程师的视角看不仅适用于丰田和汽车制造：
| 征服太空，踏上月球。六七十年代，美国开始阿波罗太空计划。首批宇航员强烈要求工程师加上窗户、逃生门、可人手控制等（现代我们会觉得这些是太空船 (spacecraft) 基本要求, 但当时是闻所未闻）。 1980年，一位NASA工程师回顾当时工程部的想法：“你们又不是火箭专家、航天专家，只是飞行员。希望可以在火箭驾驶舱人工控制火箭飞行，开玩笑！你们可不了解成本多高，我们应可以很轻易用工程的理由拒绝。” |
重复五遍“为什么”(5 Why)
最重要的不是追究责任而是找出根因。
五个“为什么”是一种找根因的方法，实例可详见附件：
- 不停留在“原因”上，而要找出“真因”，彻底改善。
- 不追究责任，而是追究原因。
丰田要求检查人员不仅仅检查过程与结果，做统计报告，交给负责的工程师，也必须分析产生不合格的原因，使同类的问题不再发生。 检查人员不仅仅是“考官”，也作为“内部教练”，指导生产的持续改善。
反过来，如果下属因出错，导致失败，立马被上司骂，觉得很难受，就会从反省变为排斥。 如果公司有这种“责难，追究责任”的风气，坏消息就会被隐瞒。所以丰田有一条原则是“Hard news first （先说坏消息）”。
当工程师找出了问题就必须要求他查找原因、提供数据，但很多时候这个工作并不简单，但大野耐一先生决不放弃，必须找到根因。他说：做到一半是不行的，只有一个期限——“到完成为止”。
持续改善没有停止
| A公司用丰田方式进行了两年多的生产改革，高层觉得成果令人瞩目，举办改善报告会，邀请集团内其他公司高层来参加。 在参观工厂时，A公司的负责人利用图表展示如何成功地缩短了零件替换时间。C公司高层听了说明后问：“你说把90分钟缩短到30分钟,最初的一年半,你们确实一口气实现了时间的缩短,但是,看一下这半年,你们好像只缩短了几分钟。对于这点，你是怎样考虑的呢？” |
能否坚持下去是能否成功的关键因素。
成长比成功更重要
- 要培养人才，“改变体制”比“改变人”更有效。
有些工厂只依赖张贴标语、海报，希望可以减少工地的事故发生率，但丰田不注重喊口号，而是动手干实事，包括机械保安、设备保安等。
所谓5S 指的是：整理、整顿、清扫、清洁及修养。无法做到这些基本原则的企业及个人是生产不出优质产品。
在这些基本原则中,丰田尤其注重“整理和整顿”。
“处理掉不需要的东西是整理。使得任何时候都能把想要的东西拿出来的叫整顿。只是把东西放整齐的则叫做排列。我们要求在生产现场必须要做好整理和整顿。”
实例：
| B 先生受命去子公司A公司实施重建工作。当他第一天到达工厂的时候,他看到的是一副脏得无法形容的情景。机器上布满了油和灰尘,地板和墙壁上沾满污渍。飞散开来的机油上又落了灰尘,积成厚厚的一层。半成品和零件随便地东一堆西一堆地放着，工具扔得到处都是。工厂里想找块站的地方都很困难。这样的状态不用说也会降低丰田的“开动率”。仓库里也是堆满了零件和产品,但看那样子就知道,若要问起某个东西在哪里的话是不会有人知道的。 他在晨会上问大家: “你们想带自己的家人或恋人来这个工厂吗?” “心情”改变工作 在B先生听来,这些理由中其实就蕴含了“改善的线索”。 |
大野耐一在他的《现场经营》中写过：
| 如果仅仅觉得(机器人)用起来很方便,或是能代替我去工作,那就说明根本还没有能够有效地使用机器人。如果引进机器人,就要从引进的那一刻起对机器人进行改善,或者要使自己的做法能和机器人合拍。 如果公司有人误以为买个机器人回来就成了,不明白目前的情况下有没有比引进机器人更好的方法,只想着如果不买机器人,改善就不可能进行得下去,这家企业就糟糕了。首先要弄清楚目前企业里的机器能做到哪一步,或是为了使现在的机器能发挥更大的作用,而先充分地去使用现在的机器。这样当以后有先进的机器引进来的时候,就可以依靠其获得“基于智慧的+α”（注）了。丰田最终决定要在最后的组装工序中引进机器人也是经过了一段很长的准备期的。 （注：α指不仅要以现在的技术、价格、服务等为基准进行标杆管理,还必须预想一个包含了将来的变化的“现在+α”，作为标杆管理的对象。 ） |
第一个例子，说明工作环境的重要性，主管通过逐步改善工厂的环境，团队的士气与生产率都提升了。
从第二个例子看到成长不是仅仅按既定方向去做，必须思考动脑筋，并了解背后的目的才能真正取得效果。
这些丰田的成长故事也适用于软件开发团队，例如，有些软件开发团队盲目地想推自动化测试，却没有想好哪一类测试应自动化，哪一类更合适手工测试，最后因效果与投入不匹配，以失败告终。
以忙碌为耻
- 不吝惜智慧，但要吝惜汗水
| 把“动作”转变为 “工作” 当大家批评某机关的工资太高时,职员会以上班时间很长, “一直在努力工作”为由来反驳人们的批评。这其实是一种对于“有动作”和“在工作”的混淆。不管上班时间有多长, 如果没能够创造出利润,那么就不能称之为工作, 也不能称之为一直在努力。 |
| 二战后，日本经济萎缩,丰田辞退了不少员工。1950年，朝鲜战争爆发，需要大量增产，但丰田选择了只增加设备，而不增加人手，大野先生也借这机会，完善丰田生产方式，成功找到了以不增加人手为前提的增产办法。 |
从心里相信“大家的力量”
- 不是靠“一个不平凡的人”，而是依靠“一百个平凡人”来创造亮眼的成绩。
- 生产产品就是培养人才。
有一位丰田员工被问到“丰田生产方式到底是什么”的时候,这样回答: “就是在人的智慧建起的基础上,立起了自动化和及时生产这两根支柱。”
他所说的“人的智慧”是指“在一线工作人员的智慧”。
| 人了不起的智慧 所谓丰田生产方式其实就是要建立起一种体制，把“人了不起的智慧”引导出来,使得这些智慧能在生产一线得到充分发挥。所以说“丰田生产方式源自人的智慧”。 |
企业相信员工的智慧提升以后，员工们的干劲、使命感、责任感都会随之而生,最重要的是,员工们会因此逐渐对工作抱有自豪感。一旦员工们的意识改变了,理所当然地,企业的竞争力也将获得很大的提高。
大野耐一先生说：“改良是指通过投入资金使情况变好， 改善是指通过动脑筋使情况变好。”
| 带诚意去赢得协作 B先生所在的A公司曾以丰田生产方式为基础进行了生产改革。 |
改善质量
质量大师裘兰博士(Dr Juran)用财务管理比喻质量管理，同样也有策划、控制和改进，然后基于这大框架再细分：如何制订质量目标、如何来制订度量等。
质量策划包括：
- 设定目标，包括外部和内部目标。
- 识别内部需求。
- 依据客户需求制订产品的功能特征。
- 制订产品和过程的目标。
- 设计过程来达到这些目标，并验证过程能力。
质量控制和质量改进
下图的左面是在过程之前的策划部分，例如发现缺陷比率为20%，这就是过程的能力，这是策划的时候已经定好的，过程控制没有什么可以做，只是当缺陷有变化，比如特别高的时候，需要做一些纠正措施。例如希望把缺陷从20%降到3%，这就必须驱动一系列的改进计划。改进计划也必须按项目管理方法推行与监控，没有其他办法。
所以如果希望敏捷开发有效，不仅仅是走迭代过程，确保进度没偏差，还要确保软件产品质量，也应该用裘兰博士的质量管理思路去看敏捷过程，才能更全面了解如何确保软件开发的质量，控制交付工期。
最佳实践，如果没有质量目标、度量衡量和策划，都只是空想，对长远提升公司文化、团队成员的习惯没有任何帮助。
例如我们想改善团队的策划和估算。首先要识别客户，哪些是主要干系人——甲方有什么要求、内部部门经理有什么要求。然后从他们的诉求变成过程的功能和特征，但如果特征只是描述，没有数字也没有意义，所以要配合可衡量的度量单位，和用什么方式去收集那些数字，然后依据目标定过程要怎么去做，怎样改。例如：
- 是否应该从本来的瀑布策划方式制定大的总计划，改用精益的思路，分成迭代？
- 每次估算应该怎么做、如何监控等？
- 然后改进过程要不断从实验中优化。
- 最后还要用数字证明有显著改善，然后在其他团队推广。
不是单纯“空降”某敏捷流程（例如SCRUM），便能加快团队的发布速度。
所以虽然极限编程里每一条实践都是最佳实践，也必须配合质量策划和监控改进才会有效果。
乔布斯85年离开苹果，自己开创NEXT公司,他很注重质量，便邀请了裘兰博士(Dr Juran)从美国东岸飞到西岸，帮他们公司做辅导、改进过程。以下是节录他接受访谈时，对美国企业、质量和裘兰博士的观点：
| 美国已经富裕了很多年。很多企业都忘记要获得成功，还是要关注基本功，包括教育。现在我们美国很多企业面临困难，处处感觉被日本领先了。其实不是日本针对我们，而是我们作为美国企业家应反思一下，为什么我们的战略比日本差，为什么我们的策划不如日本？我们知道裘兰博士多次去日本，帮助日本企业提升质量。现在他回到美国，希望把他的经验带到美国企业，提升竞争力，可以再一次成为世界第一。 我觉得裘兰博士很实在，不是泛泛而谈。我们的工程师也深受他这种风格影响。无论我们之中谁问他问题，总裁还是工程师，他都会全心全意用自己的知识解答。所以工程师和我都很希望用他那套方法来做提升。质量提升的道理其实很简单，是一个重复的过程，然后我们需要不断去看，有哪些无效的环节要省略，哪部分要重新设计，不断试验、提升，就这么简单。重点是所有的提升都应该是科学化的，有数据而不是泛泛而谈。 |
结束语
按质量大师裘兰博士定义，质量包括两部分：
- 满足客户需要（包括外部客户和内部客户）
- 没有缺陷
这定义不仅仅适合于制造业，也适用于服务业、IT业。
丰田生产方式是TQM (Total Quality Management全面质量管理)的最佳例子，TQM强调专注客户、持续改进、以数据说话、员工参与等，丰田生产方式覆盖了TQM原则的七项(除了战略)。
从以上丰田故事看到丰田方式如何帮公司培养知识工作者，发挥人的无限智慧， 为公司增值。
丰田汽车，从50年代开始，沿用裘兰博士的质量管理思路，成为世界最大的汽车企业。
针对软件开发，如何基于以上质量管理、精益管理思路，配合敏捷开发最佳实践，提升产品质量与团队竞争力?
团队（包括组长与组员）的能力是过程改进的基础，不仅仅依赖领导。
虽然XP比SCRUM更全面列出敏捷团队的最佳实践，但还必须依赖团队持续改善才会有效果。
下一部分，我们探索“团队与自我改善基本功”与成功要素。
附件
现代汽车生产
今天Just-In-Time已成为汽车制造的主流，例如：日产在英国牛津郡(Oxfordshire)专门生产mini车的工厂便能做到：
- 从钢材原料到生产出汽车只需要24小时。
- 整个生产线没有任何中间等候，每68秒出一辆。
- 每天生产1000辆车。
挑战：每一辆汽车都不同——颜色、设备、左右驾驶座等
- 生产线上每一辆汽车都按照客户需求订制。
- 组件不早不晚按需求准时到达生产线。
- 这便需要信息化系统把客户订单转换成生产信息。
例如生产线上每一辆的颜色都可以不同：
XP
编码实践（Coding Practices）
CP1:简单地编码和设计（Code and Design Simply ）
- To produce software that is easy to change 使软件易于更改
CP2:无情地重构 （Refactor Mercilessly）
- To find the code’s optimal design 找到代码的最佳设计
CP3:制订编码标准 （Develop Coding Standards）
- To communicate ideas clearly through code 通过代码清晰地传达想法
CP4:共同的词汇 （Develop a Common Vocabulary）
- To communicate ideas about code clearly 清楚传达软件设计的想法
开发实践（ Develop Practices）
DP1:测试驱动开发TDD （Test-Driven-Development ）
- To prove that code works as it should 来证明软件正常工作:
- Test-first programming(prim practice#)
DP2:结对编程 （Pair Programming）
- To spread knowledge, experience and ideas 传播知识、经验和想法:
- Pair Programming(prim practice#)
DP3:集体负责写好代码(vs 只顾虑自己的代码) Collective Code Ownership (vs individual own code)
- To spread the responsibility for the code to the whole team 将写好代码的责任扩展到整个团队:
- Whole team(prim practice#)
- Share code(corollary practice#)
DP4:持续集成（ Integrate Continually）
- To reduce the impact of adding new features 降低添加新功能的影响:
- Incremental Design(prim practice#)
- Single code base(corollary practice#)
- Ten-minute Build(prim practice#)
- Continuous Integration(prim practice#)
商务实践 （Business Practices）
BP1:将客户添加进团队（ Add a Customer to the Team ）
- To address business concerns accurately and directly 准确、直接地解决业务问题:
- Real Customer involvement(corollary practice#)
BP2:计划游戏 （Play the Planning Game）
- To schedule the most important work 安排最重要的工作:
- Weekly cycle ; Quarterly cycle ; Slack (prim practice#)
BP3:定期发布 （Release Regularly）
- To return the customer’s investment often 尽早交付，让客户看到投资回报:
- Incremental Deployment(corollary practice#)
- Daily Deployment(corollary practice#)
BP4:以可持久的速度工作 （Work at a Sustainable Pace）
- To go home tired, but not exhausted 回家时虽然很累，但不筋疲力尽:
- Slack (prim practice#)
“ 5 Why ”实例
大野耐一先生见到生产线上的机器总是停转，虽然修过多次但仍不见好转，便上前询问现场的工作人员。
(1-Why)问：“为什么机器停了？” 答：“因为超过了负荷，保险丝就断了。”
(2-Why)问：“为什么超负荷呢？” 答：“因为轴承的润滑不够。”
(3-Why)问：“为什么润滑不够？” 答: “因为润滑泵吸不上油来。”
(4-Why)问：“为什么吸不上油来?”答: “因为油泵轴磨损、松动了。”
(5-Why)问: “为什么磨损了呢?” 答: “因为机器打磨金属零件，空气混进了铁屑等杂质，并掉进机器油缸里。”
经过连续5次不停地问“为什么”，找到问题的真正原因（润滑油里面混进了杂质）和真正的解决方案（安装过滤器）。由现象推其本质，因此找到永久性解决问题的方案，这就是5 Why。
5S法
本来5S是用于工业生产，例如日本的生产工厂很注重洁净，东西要放在容易找到的固定位置。其实这对生产线员工有很重要的心理作用。如果整个环境都很脏，必然会影响人工做好的动力，如果东西乱放，也容易找不到。5S也不仅仅是用于制造业，业适用于服务业，每件东西必须放在固定位置；这也可以用于个人管理，我以前常常在出差去客户现场时，经常忘记把一些东西，如鼠标或插头。但后面我固定了每件东西都应放哪里，临走收拾时就确保那些东西不会遗漏掉。平常工作有一个洁净的环境，也能降低工作压力，提高工作效率。
参考 References
- 若松义人. 《为什么是丰田：成为第一的方法和7个习惯》