台湾资深老专家：你实施敏捷的路子对吗？
作者简介：
Ruddy Lee（李智桦）老师，DevOpsDays北京站金牌讲师，台湾著名精益布道师，敏捷专家，著有《精益开发与看板方法 》。
台湾敏捷大师李智桦老师手把手教你怎么在团队中实施敏捷，大师系统性地梳理了多年敏捷实施的经验，敏捷实施路线图、注意事项、敏捷关键实践一览无余。
实施过程
给自己一个月的时间，设定二个星期为一个Sprint，也就是说任何Scrum的实践你都有二次演练的机会。
为什么要二次呢?因为第二次一定会做得更好，还因为Scrum没有它表面上看起来的简单。
编者注：以上这张图是李智桦老师采用敏捷顾问模式在团队中实施敏捷的整个框架，分为三层：
流程与角色
严格按照Scrum 的过程进行，清楚的告知团队具体流程、角色和产出
时期
说明的是要实施的内容的优先顺序，最开始要导入敏捷理念，再逐步优化，前期的重点都在需求的质量提升
时间表
以1月为期，分两个Sprint，说明具体敏捷顾问（教练）要导入的内容
建议将此大图和下文中的详细解释对照着阅读
持续改善
第二次一定会比第一次做得更好，这叫做「持续改善」。 它是敏捷开发的终极目标，原因是变化来的太快。 所以最好的应对方法便是：
针对眼前的问题来思考如何解题；
放弃「事情会一层不变的想法」；
尽量减少预设立场的思维，也就是要客观；
先做一遍然后看着结果依靠得到的数据再来持续改善它。
实施顾问模式解析
流程与角色
教会PO与团队运用「 用户故事地图」来讨论每一个Sprint的目标是一个巨大的挑战，也是随后团队开发速度的关键，因此一开始就把重点放在这里。
它的影响也十分深远，是整个开发过程是否顺利的重要因素。 而随之而来的DOR 与DOD时期也都是朝向需求的优化而来。 目的就是为了正确的开发方向及飞快的开发速度而努力。
团队开发的流程与角色
时期
前置时期
敏捷不只是一种开发方法，更是一种观念。
要做好敏捷开发就应该先从建立团队的观念开始。
敏捷化的基础就由「 前置时期 」开始，它发生在二个Sprint循环之前的时间，是一段建立统一观念的时期。 在这段时间里我会努力地进行同步的动作。 同步什么呢? 例如: 团队对Scrum、Kanban的观念和做法上的同步，主管与Scrum Master之间默契的建立。 并借助好的教科书及实际案例等让大家可以在观念上有一致的看法。
DOR
Definition Of Ready需求是否备妥的定义。
编者注：DOR在很多团队实施敏捷的过程中被忽略了，导致需求质量不足，影响开发与测试进行理解和验收。比如在需求上可以注明Acceptance Condition即验收条件，或者增加原型对需求进行补充描述
DOD
Definition Of Done完成的定义.
编者注：在第二个Sprint中，敏捷教练会开始进行流程优化，使用看板可视化工作流，并进行优化
时间表
这是为期一个月的敏捷顾问模式时间表。 后面的二个冲刺sprint循环是标准的Scrum式的迭代开发模式。 比较特殊的是：
运用看板方法来调整开发流程的速度
加入必要的重点项目
以加入看板栏位来强制改变开发流程。例如:第一个Sprint将强调单元测试，第二个Sprint则强调自动化及维护文件)。
实施顾问模式的时间表
附赠绘图小技巧
谈完实施顾问模式的四个步骤之后，该来说明最上面的那张图了（敏捷顾问模式图）。 它是依据Alignment Diagram 的观念制作成的。 中间是价值的部分，他是上下两层的衔接部分，Alignment 的意义就是指在上下二层的对等价值所在。
Alignment Diagram 排列图(注4 Mapping Experiences)
Alignment Diagram 适合用于表达经验，其分成三部分，上半部:流程与角色，下半部:是执行的时间表，中间则是价值的部分我用「时期」来作区分，每个时期都有它的目标及所希望达到的成果，也就是价值 。
顾问模式的四个步骤
实施顾问模式的四个步骤，运用精益观念来充实敏捷开发的实施过程
敏捷不只是一种开发方法，更是一种观念。
要做好敏捷开发就应该先从建立团队的观念开始。
这四个步骤其实是针对敏捷顾问/教练们一直以来常面对的问题，所提出来的对策。
以下是来自一位敏捷顾问的感概 :
一开始，发现都是一些技术知识的问题，
然后，马上进入到系统架构方面的问题，
当再解决架构问题的时候，我发现，已经是软件工程的问题，
而软件工程问题的后面，又是公司管理上的问题，
而公司管理的问题，结果又到了人的问题上，
而人的问题，又到了公司文化的问题……
解决之道：
1. 增强学习
来补足工程师或团队专业能力的不足。 将求知欲带入团队，激发鼓舞团队上进心。 (这么做之前，还是得先运用看板方法帮工程师找出盈余时间来，有了多余的时间就更容易激发他们的求知欲望)。 让工程师处在用功学习的状态时，这是他稳定性最高的时候，也是最值得珍惜的时刻。
2. 品质与纪律
让团队开始自我管理，怎么做呢?就从纪律开始，也就是开始严格要求品质。
3. 衍生式设计 Emergency design
让团队学习敏捷开发在进行设计时的精随-衍生式设计(注2.)。 这一关很抽象很难明确，要适度就好。
由需求（也就是用户故事）开始最洽当，容易掌握又可以看到成果（用户故事地图）。 至于运用在架构或系统的设计上，那就要依靠工程师的素质了。
4. 敏捷价值观
将正确的敏捷价值观推广到管理阶层，让上下之间有着一致的认知。
最后才是，让管理及规划部门清楚自己的任务其实是在「 塑造团队的敏捷文化」。
哈哈！ 用说的总是比较容易。
由 「 增强学习 」 开始
Hatching 孵化，我喜欢用孵化来比喻教开发团队学习敏捷开发的过程。
一开始总是由增加知识及专业技能开始，让工程师们尽量地看见学习的路径(光有目标还不够，要看到如何学习才是重点)，让他们自己去选择学习的途径，由充实专业技能的欲望带领着他们去成长，我发现这是最好的开始，人们在学习、吸取新知识的过程里，总是拥有最佳的稳定性(没人喊着要离职或加薪)。
这是我习惯的开始方式，也就是步骤一、「增强学习」Amplify learning它也是精益开发的原则(注1. 精益开发原则)。
品质与纪律
关注品质是为了改善程式的质量，而程式在质量上的提升意味着缺陷bug的减少，缺陷减少了自然就省下不少修复缺陷时所需要的时间（返工），工程师少了返工修复缺陷时所花的时间，自然也就作到了消除浪费的目的。
因为花太多时间在修复缺陷是软件开发上最大的浪费。 我这么做的目的是用消除浪费来替工程师们赚取更多可以运用的时间，我们称之为「盈余时间」。 有了时间之后工程师才可能放开心胸去接受新的知识、新的技能然后做到持续成长。
同时，提升软件品质真是好处多多，好的品质能带来团队的相互信任与合作，会让人带着愉快的心情去上班。 无形间建立了团队的纪律，当然同时也会换来外界的好名声，真是最值得的投资。 而且好的品质能够换来纪律，它们是一体的二面。
衍生设计
敏捷最有趣的地方就是不能一口气设计太多东西，你必须懂得「 适可而止 」这句话，做到恰恰好的设计，尤其是在架构设计上。
在前几个步骤里，我们努力的让团队增强专业能力，但很快地你就会发现真正约束团队开发能力的是架构层面上的问题，我们必须运用软件工程上许多的模式Pattern来解题。 这要感谢一些软件前辈在物件开发或设计模式上的贡献，我们今天才有这项工具来时实施所谓的「 衍生式设计 」 Emergent design(注2.参考《浮现式设计》一书，作者: Scott L. Bain)。
敏捷价值观
很多人都以为开发团队是否优秀是决定实施敏捷开发是否成功的最大因素。 确实，拥有一个极为优秀开发团队是获取成功的重要的环节。
但我做顾问这么多年以来，我一直以为，工程师最重要的不一定是优秀，尤其是你的团队实在很难都是由极端优秀的工程师所组成。 反之，只要有几个优秀的工程师在团队中便能让团队变得更优秀。 原因就在工程师是否拥有正确的价值观。 (注3. Scrum 价值观)
结语
目的是降低改革所造成的团队恐慌
为了减少恐慌，让团队能够清楚了解整个的敏捷实施过程，因为了解，就不会大惊小怪。 用「看得见」来磨灭疑虑跟猜测，尽量让团队不要因为即将来临的改革而恐慌并产生莫名的抗拒。
要知道所谓的顾问!其实就是老板请来帮你的那个人罢了，是来帮你忙的，有问题就尽量找他不用担心什么。
上面这张图是我习惯运行的顾问模式，采用一个月二次迭代的方式，目的是让团队能够有一次反覆练习的机会，所以会设计成二轮迭代。
同时也是担心自己顾问的时间一到便必须离开，而学员会因为不够熟练而有半途而废的事情发生(第二次机会，就是要让他们多做一次时能体会出持续改善的意义)。
这个模式实际执行起来，最有趣的是很少有团队可以在一个月内做完所有动作的(当然是因为我害怕遗漏而放太多进来了，这些个功能要求理当视团队的现状来作取舍），而实际上最长的实施纪录是一整年。
附注
注1.精益开发原则
七大原则: 消除浪费Eliminate waste、增强学习Amplify learning、尽量延迟决策Decide as late as possible、尽快交付Deliver as fast as possible、授权团队Empower the team、内建完整性Build integrity、着眼整体See the whole。
参考: 《 精益开发与看板方法 》第一章精益软件开发。
注2. 《浮现式设计》作者: Scott L. Bain 。
作者把当今最重要的开发原则汇集成了一个统一的、流线化的、实用的软件开发方法，他汲取了模式、重构和测试驱动开发的精华，阐述了如何在整个软件生命周期中高效地开发、管理变更以及持续交付健壮、可靠且经济高效的系统。
注3. Scrum价值观
专注Focus、勇气Courage、公开Openness、承诺Commitment、尊重Respect。
注4. Mapping Experiences ，作者: Jim Kalback的名著
很棒的图示法，原意是用在UX的设计表达上，用来作为个人与组织互动的影响说明。 但运用在经验模式的说明上也很适用。
原文链接：http://t.cn/RKJ3HAO
近期好文：
没看过瘾？
没关系
李智桦老师将在 DevOpsDays 上海站带来更精彩的演讲👇
《敏捷的系统思维》
点击“阅读原文”，关注 DevOpsDays上海站