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：

• 每一辆都是按客人订单订制：例如，颜色，配置，左右钛等。
• 从钢材原料开始，整个生产线零等待、零浪费。

每个工作步骤所需配件按生产需要到达（不晚到也不早到），把生产过程中的配件降到零。

喜一郎先生安排总工大野耐一去美国汽车公司考察。

Federick Taylor 与科学管理(Scientific Management)

总工大野耐一先生从美国的超市（非汽车公司）得到如何做Just-In-Time的启发，回国后就开始在丰田全力推动。开始时，很多人都觉得Just-In-Time 这个愿景好像是远不可及的梦想。而到了今天，现代汽车生产都基本做到了当年喜一郎先生和大野耐一先生的梦想。（详见附件）

水面下的管理思路

为什么丰田能成功地把汽车生产做到 Just-In-Time ，超越西方的巨头，使日本汽车制造过程成为世界“标准”？
但我们不能单从表面看这“系统”的方法和技巧，例如大家都熟悉的看板管理（他的竞争对手通用、福特肯定都学过），更重要是了解背后的管理思路。我们看看下面丰田七个习惯，开始了解水面下的“系统”:

1. 容易实现的目标不是好目标
2. 不以“我们公司”作主语
3. 根因分析
4. 持续改善没有停止
5. 成长比成功更重要
6. 以忙碌为耻
7. 从心里相信“大家的力量”

容易实现的目标不是好目标

不是“削减一成”，而是通过“取消一个零”来发现浪费

“如何把原先需要三小时的工作，改用三分钟完成”
如果听到上司以上要求，你该怎么回答呢?如你回答：“这太强人所难了”、“绝对做不到”，请读以下丰田案例。

标杆管理 (Benchmarking)

很多公司都会用百分比来设定改善目标，但改善了百分比，不一定代表质量有改善，例如某快递公司去年送包裹未按时送达占8%，今年是6%，好像已经改善了2%。但去年托运的数量是500万件，所以8%是4万件。今年的数量是750万件，所以今年的6%就是4万5千件。
所以今年包裹延误增加了5000，这样非但没有任何改善，反而服务变得更差了。所以更重要是看数字本身。容易达到的目标，不是好目标。所以丰田一般会选行业里最强的对手作为基准（标杆）。
1965年，美国通用汽车公司是世界顶尖。例如销售额的规模，丰田与通用是1:60，完全不在同一个层次上。成本上丰田对通用是1:0.5，成本是通用的一倍。
丰田把当时顶尖的通用公司当成了自己进行标杆管理的对象。
如果丰田某零件的成本价格是1000日元，通用是400日元。丰田会把通用的400日元，作为基准成本价，把原料价定为400日元，把差额600作为“不必要花费”，让团队立马改善，尽早达到标杆。
丰田（如下图）很注重各种标杆，例如内部标杆、竞争性标杆等。软件开发也应该同样利用数据来制订量化目标。

从以上对话看到越来越多高水平开始用标杆管理，但标杆必须是比自己高很多才有作用。

不以“我们公司”作主语

• 不是从“专业”的角度，而是从“顾客”的角度生产产品。

创业大忌——闭门造车,所以丰田的原则，对客户有用就一定做出来，但对客户无用或者不想要，就绝不生产。

要创新必须从“顾客”的角度看，不单从工程师的视角看不仅适用于丰田和汽车制造：

重复五遍“为什么”(5 Why)

最重要的不是追究责任而是找出根因。

五个“为什么”是一种找根因的方法，实例可详见附件：

• 不停留在“原因”上，而要找出“真因”，彻底改善。
• 不追究责任，而是追究原因。

丰田要求检查人员不仅仅检查过程与结果，做统计报告，交给负责的工程师，也必须分析产生不合格的原因，使同类的问题不再发生。 检查人员不仅仅是“考官”，也作为“内部教练”，指导生产的持续改善。

反过来，如果下属因出错，导致失败，立马被上司骂，觉得很难受，就会从反省变为排斥。 如果公司有这种“责难，追究责任”的风气，坏消息就会被隐瞒。所以丰田有一条原则是“Hard news first （先说坏消息）”。

当工程师报了有问题就必须要求工程师查找原因、提供数据，但很多时候这个工作并不简单，但大野耐一先生决不放弃，必须找到根因。他说：做到一半是不行的，只有一个期限 ——— “到完成为止”

持续改善没有停止

能否坚持下去是能否成功的关键因素。

成长比成功更重要

• 要培养人才，“改变体制”比“改变人”更有效。

有些工厂只依赖张贴标语、海报，希望可以减少工地的事故发生率，但丰田不注重喊口号，而是动手干实事，包括机械保安、设备保安等。

所谓5S 指的是：整理、整顿、清扫、清洁及修养。无法做到这些基本原则的企业及个人是生产不出好产品。
在这些基本原则中,丰田尤其注重“整理和整顿”。
“处理掉不需要的东西是整理。使得任何时候都能把想要的东西拿出来的叫整顿。只是把东西放整齐的则叫做排列。我们要求在生产现场进行的整理必须要是整理和整顿。”
实例：

大野耐一在他的《现场经营》中写过：

第一个例子，说明工作环境的重要性，主管通过逐步改善工厂的环境，团队的士气与生产率都提升了。
从第二个例子例子看到成长不是仅仅按既定方向做，必须思考动脑筋，并了解背后的目的才能真正取得效果。
这些丰田的成长故事也适用于软件开发团队，例如，有些软件开发团队盲目地想推自动化测试，却没有想好哪一类测试应自动化，哪一类更合适手工测试，最后因效果与投入不匹配，以失败告终。

以忙碌为耻

• 不吝惜智慧，但要吝惜汗水

从心里相信“大家的力量”

• 不是靠“一个不平凡的人”，而是依靠“一百个平凡人”来创造亮眼的成绩。
• 生产产品就是培养人才。

有一位丰田员工被问到“丰田生产方式到底是什么”的时候,这样回答: “就是在人的智慧建起的基础上,立起了自动化和及时生产这两根支柱。”

他所说的“人的智慧”是指“在一线工作人员的智慧”。

企业相信员工的智慧以后，员工们的干劲、使命感、责任感都会随之而生,最重要的是,员工们会因此逐渐对工作抱有自豪感。一旦员工们的意识改变了,理所当然地,企业的竞争力也将获得很大的提高。

大野耐一先生说：“改良是指通过投入资金使情况变好， 改善是指通过动脑筋使情况变好。”

培训ACP（注#）时，我会在第一天借用谷歌2000年时快速成长期的管理思路说明团队敏捷开发的成败依赖于公司文化。

（注# ACP = Agile Certified Professional，是美国PMI的敏捷认证。）

学员下午做互动练习时 便说自己公司里确实有不少“河马”横行。
从以上两故事看到，优秀的公司高层，无论东西方，都理解公司的发展依赖“大家的力量”和各人的智慧，同心协力，“大王”文化会妨碍公司持续改进，难以改善。

改善质量

质量管理，与财务管理类似，同样也有质量策划、质量控制和质量改进，基于这大框架再细分：如何制订质量目标，如何来制订度量等。
质量策划包括：

1. 设定目标，包括外部和内部目标。
2. 识别内部需求。
3. 依据客户需求制订产品的功能特征。
4. 制订产品和过程的目标。
5. 设计过程来达到这些目标，最后验证过程能力。

质量控制和质量改进
下图的左面是在过程之前的策划部分，例如发现缺陷比率为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

1. 若松义人, 《为什么是丰田：成为第一的方法和7个习惯》

代码007普通

打赏 收藏 海报 链接