追求卓越

在行业数字化转型加速的今天，精益敏捷、DevOps等已成为软件研发团队经常提起的热点词汇。对于软件研发而言，效率、质量是永恒的主题，提升软件研发效能的关键是要提升持续交付能力，而要构建持续交付能力，走好敏捷转型实践之路是其中非常重要的选择。然而，不同于互联网企业或产品型企业的软件研发团队，对于类似我们以项目型为主导的传统软件研发团队而言，敏捷转型这条道路并不那么好走，况且不同企业不同团队的实际情况也迥然不同，很难有可复制、可照搬的敏捷转型经验，更多时候需要结合自身实际进行持续探索并不断总结经验。之所以.

企业进行数字化转型，需要提升软件研发效能，效率、质量是永恒的主题，提升软件研发效能的关键是要提升持续交付能力。软件研发效能是我们关注的重要指标，主要从交付效率（实现端到端快速交付、及早交付）、交付质量（实现端到端高质量交付）、交付能力（打造卓越工程能力，持续交付）三个维度体现。在研发体系建设的过程中，我们的目标是要提升持续交付能力、系统架构能力、产品和流程能力、精益管理和监控能力并促进组织文化转型。为推进持续交付体系框架落地，我们需要管理维度与工程维度的相互结合，应用最佳实践。从管理维度来看，着重于规模

本篇是内部敏捷教练培训的第五篇，升华篇。本篇为部分内容的节选。本篇要点：认清敏捷教练的参与周期及发力方向，导入敏捷并指导团队实践，持续观察、思考、反馈及调整， 理解系统思考与持续改进带来的价值，以追求高绩效为基本目标，学习如何成为一名好教练。...

本篇是内部敏捷教练培训的第四篇，实战篇。主要以模拟实践Scrum及看板方法，并采用工作坊的方式进行实战模拟训练，从训练中进一步体会和领悟敏捷价值观、原则及相关思想。

本篇是内部敏捷教练培训的第三篇，教导篇。在实际培训中可以穿插相应的小游戏。本篇要点：了解敏捷教练在帮助团队成长过程中如何发挥作用，掌握敏捷教练的六种角色（导师、协助者、老师、问题解决者、冲突领航员、协作指挥者），结合实际讲解每一种角色如何做。...

本篇是内部敏捷教练培训的第二篇，基础篇，由于内容比较多，本章仅分享部分内容，对于敏捷宣言、敏捷相关原则、Scrum框架有关介绍等内容均不列入。本篇要点：理解精益思想，理解敏捷思想、价值观、原则及若干实践，熟悉掌握Scrum框架，理解Scrum中存在的模式、探索出来的模式及反模式，熟悉掌握看板方法及其运用。...

分享一下今年给团队做的内部敏捷教练培训，本篇为认知篇：认识敏捷教练，摆正角色认知。本篇的主要要点：认识敏捷教练，理清项目经理、Scrum Master与敏捷教练的关系，认清敏捷教练的主要职责，认清敏捷教练的失败模式、从失败中如何恢复及成功模式，了解敏捷教练的成长进阶之路。...

在敏捷转型的推进过程中，抓好内部敏捷教练的培养是敏捷转型成功的基本保证，也是敏捷转型的源源不断的动力所在。《敏捷教练》一书的作者之一，瑞秋·戴维斯（Rachel Davies）对敏捷教练的观点：概括地说，敏捷教练帮助团队在工作中应用敏捷实践，从而帮助团队发展的更健壮。接受这些变化需要时间，所以没法通过“点到即止”的方法立即让它们生效。你需要与团队长时间呆在一起，并帮他们，让他们更加关注工作流程、关注如何更有效地协作。你对团队的目标是在你离开后，让他们能“自我指导”并且擅长应用敏捷。这样不会限制敏捷教练

在敏捷转型推进的过程中，工具链的建设有利于将敏捷转型成果流程化和可视化。通常，需要结合项目团队的需要，从公司或研发部门层面搭建自动化工具平台，逐步构建持续交付流水线，实现端到端无缝集成，实现源代码的自动拉取构建、代码自动扫描检查、测试环境的自动部署、API测试自动化等。下图是持续交付流水线相关工具的一个示例：通常，我们在工具链的建设过程中，需要考虑项目管理/协作/需求管理工具、代码托管/编译构建/打包工具、测试工具、发布/运维工具等几类工具。在项目管理/协作/需求管理工具方面，不少团队都会引入JIR

用户故事实践作为敏捷转型推进过程中的关键一环，既对需求的管理和输出方式产生影响，也会对迭代方式和执行产生影响，对敏捷实践而言具有非常重要的作用，实践的效果也直接或间接地影响着敏捷实践的效果。关于用户故事的定义，一般是这样描述：用户故事（UserStory）是一段简单的功能描述，以用户或者使用者的角度，写下有价值的功能（Functionality／Feature）。与其说它是规格文件（Documentation），不如说它代表客户的一个需求而已。用户故事描述了客户或用户如何使用产品，它从用户的角度进

前面我们提到看板搭建、价值流分析，本文谈谈敏捷转型之Scrum框架实践。从我们的敏捷转型之旅来看，我们的试点团队是从看板方法及每日站会搞了一阵子之后，才开始实践Scrum框架的。究其原因，主要是两个方面：一是我们的团队之前的开发模式是典型的瀑布型模式，对敏捷的理解和认识非常粗浅；二是我们对用户故事、Scrum框架等的实践方法需要时间消化，需要预留一定的缓冲期。所以我们选择了从搭建看板和每日站会开始。谈到Scrum，首先还是老调重弹地说说有关概念、方法论等方面的东西。从概念上来说，Scrum是跨职能团队

一个采用瀑布模型开发的传统团队进行敏捷转型应该从哪里开始？怎么开始？除了前期的相关准备工作（包括敏捷松土、导入敏捷培训、价值流分析等等），在我的实践经验中，我认为最好的做法是直接从看板开始。将工作中的各项事情搬到看板上，让事情在团队内充分可见，有利于更好地协作。其实在前面的价值流分析工作中，就已经涉及到看板的搭建问题，今天这里针对看板方法的起源、建模及相关核心实践等简单聊聊。1、看板方法的起源看板方法（Kanban）源自丰田的“及时生产”（JIT=just-in-time）系统。尽管生产软件是一项创造

价值流分析是敏捷转型前期非常重要的一环，也是最基础的一项必做工作。关于价值流，百度百科中这样定义：价值流是指从原材料转变为成品、并给它赋予价值的全部活动，包括从供应商处购买的原材料到达企业，企业对其进行加工后转变为成品再交付客户的全过程，企业内以及企业与供应商、客户之间的信息沟通形成的信息流也是价值流的一部分。一个完整的价值流包括增值和非增值活动，如供应链成员间的沟通，物料的运输，生产计划的...

对于毫无任何敏捷开发经验的团队而言，在经历前期的初始学习了解后，要想快速地迈上敏捷转型的道路，仍然少不了要引入外部培训，通过导入课程让转型团队逐步建立精益-敏捷的思维方式，较为深刻地理解敏捷的价值观和原则，熟悉并掌握Scrum、Kanban、User Story、CI等主流敏捷实践，从而有利于指导后续试点团队的敏捷转型工作顺利开展。相信不少传统项目型公司，在正式迈入敏捷转型的过程中，定然会遇到不...

从今年2月份开始，本人所在的研发部门打算启动敏捷&DevOps转型，对于我们这样的传统项目型公司而言，目标是什么、道路怎么走、从哪里开始、具体如何做等等问题都会一一摆在我们的面前。为了记录我们在敏捷&DevOps转型之路上的具体实践和所碰到的各种问题，本人准备将敏捷&DevOps转型的一些行动方案、心得体会等记录下来形成敏捷&DevOps转型笔记，并分享给有需要的朋...