敏捷，把纪律留下

在很多人看来，实施了敏捷，似乎就等于纵容程序员，允许他们不把纪律放在眼里。事实是这样子么？

 

 文／金明

 

在软件行业，大部分经理们都希望自己率领的团队能像军队一样具有铁的纪律性。在一次敏捷培训中，我们与众多来自国内软件公司的项目经理们讨论了敏捷，以及他们现在各自的开发方法和问题。闲谈中，一位学员冒出一句，“开发团队应该像军队，不仅要整体阵法严密，而且每个兵都要纪律分明。”这次培训主要是介绍敏捷的技术实践，比如测试驱动开发、持续集成、用户故事等，该学员认为这些敏捷实践不仅可以提高员工的技战术，还可以塑造团队成员的纪律性。如果这些敏捷实践在日常开发中都能落在实处，势必将提高团队成员的“战斗素养”和“战术素养”。一言以蔽之，相较于其他软件开发模式，敏捷方法对团队成员的纪律性提出了更高的要求，鼓励团队成员成长为项目经理心中的“合格军人”。

其实，抛开敏捷方法，哪一种软件开发方法又何尝不强调团队成员的纪律性？计划驱动的传统型开发方法给软件过程制定了严格的计划书和检验标准，希望能提高团队的纪律性。它们的出发点是对的，但因为缺少了具体的技术实践导致计划书并不能匹配团队的真实状态；检验标准大多是着眼于与最终交付软件无关的中间文档，这些都使得成员在工作中对项目开发的约束力感受不深。比如，很多项目里面的规范说明书、WBS表和甘特图都画得非常详细，但大多数时候这些东西与项目真实情况的落差太大，很难指导督促成员的日常开发工作。而且，这些文档与需要交付的软件产品的关联性不强，也很难能让成员和其他人通过这些文档建立对软件交付的信心。长期看到团队的表现与计划的不相符，项目经理们往往会感叹团队的纪律性不行。那么， 为什么说敏捷方法能相对一定有效地提升团队成员的纪律性呢？我们先来看看纪律的定义。

 

纪律

一般来说，纪律有三种基本涵义：1. 纪律是指惩罚；2. 纪律是指通过施加外部约束达到纠正行为目的的手段；3. 纪律是指对自身行为起作用的内在约束力。这三层意思概括了纪律的基本内涵，同时也反映出良好纪律的形成过程是一个由外在的强迫纪律逐步过渡到内在自律的过程。从纪律的含义来看，达到自律是最终的目标，也是施加外部约束的目的所在。通过奖惩来达到一定的纪律性，比如程序员开发过程中的bug 率等等，这是生活中最常见的一种形式。这种方法因为检查的结果与具体生产过程差得太远，而且评判标准还是比较粗放，所以应该是最低级的方式。施加外部约束，比如检查列表，指导产品的具体生产，可以评判成员的各个环节是否符合标准，应该算中级方式。只有自律，真正让成员把纪律的观念贯穿在生产的每个环节，主动改进，从而改善生产。而这，也是纪律性的高级方式。

对比这个标准，我们可以看到：计划驱动型的软件方法学强调更多的是奖惩，也涉及到一些外部约束（代码复审等），这也是为什么它们在培养团队成员纪律性上难度比较大。而敏捷方法，通过强调承诺，强调每个成员都是“理性人”的事实，借助于成员的自律性来达到严明的纪律性。国内知名技术网站InfoQ，除了有限的几位全职员工，大部分中文编辑都是社区活跃分子，他们走到一起，通过之间的承诺和信任维持着日常工作。撇开具体项目团队而言，这就是敏捷团队最好的写照。但是，我们也应该看到，InfoQ类型的团队是可遇不可求的。现实中，大部分的开发团队还是良莠不齐，项目经理们很难去完全授权给手下的员工。为什么敏捷方法又能有效地提升成员纪律性呢？答案在于敏捷方法不仅仅强调承诺，也包含了丰富的技术实践：不仅给个人带来更短更频繁的反馈，也给团队和组织带来了多层次较全面的反馈。而反馈的频繁程度，则是外部约束发挥作用的重要基础，也即提升纪律性的重要手段。

 

戴明环（PDCA）

我们来看看被认为是组织或团队改进或解决质量问题的基本准则——戴明环。戴明环（PDCA）由美国质量管理博士戴明在20 世纪50 年代提出，PDCA是英语单词Plan（计划）、Do（执行）、Check（检查）和Action（行动）的第一个字母，该循环按照“计划－执行－检查－行动”的顺序进行，并且循环不止地进行下去，是一个立体多层级的螺旋式演化过程。PDCA循环最开始是用在质量管理领域，但实际上它是有效进行任何一项工作的合乎逻辑的工作程序，是放之四海而皆准的指导性原则。下面我们就用它来说明外部约束对纪律养成是如何影响。

PDCA 循环里面的Action 是一个循环的关键，对Check 结果进行处理，成功经验加以肯定并适当推广、标准化；失败的教训加以总结，未解决的问题放到下一个PDCA循环里，但它必须以上一环节的Check 结果为基础。如果Check 不到位，不能具体到实际工作，Action的正确性和出发依据就很值得商榷。软件开发是一个以不确定性为主要特征，强调知识的活动。为了采取的Action具有较高的正确几率，更需要强调开发过程的Check 比较频繁、具体，不断给团队提出直接的反馈，这样才能减少不断累积的不确定性最后带来成不可控制的后果。如此来看，短而频繁的反馈对外来约束真正施加到个人的效果是非常重要的。

PDCA循环还有一个特点是多层级性：各层级质量管理都有一个PDCA循环，形成一个大环套小环，一环扣一环，互相制约，互为补充的有机整体。软件开发通常会把个人、团队和组织都牵扯进来：个人完成功能的开发，团队完成软件的开发，组织负责完成客户需求的完成。传统的软件开发方法更多的是强调团队、组织层级的计划、图表等文档，关注于团队与组织层级的反馈。对于真正创造产品质量的日常开发环节，则缺少必要的检查和反馈。与之相反，支撑敏捷方法的敏捷实践，就从“个人－团队－组织”的几个层面都提供了相应的反馈：低层次的反馈，为上一层次的反馈提供了依据，同时也作为上一层次反馈的落实和具体。

 

敏捷实践

我们从“个人－团队－组织”等的不同层次选取几个突出实践简要解释它们是如何提供频繁、直接的反馈。

• 个人层级

测试驱动开发能给开发人员提供最直接也是最快捷的反馈：先写测试，再用最简单的方式实现，再重构代码以符合简单设计的原则。如此短间隔的反馈能很快地告诉开发人员刚才增加的代码是否破坏了已有的功能。而且，已完成test case 的列表能很清晰地告诉其他人开发任务的完成情况。对比着用户故事的验收条件，开发人员很容易评估剩余的工作量，并不至于破坏已有的功能。

• 团队层级

敏捷实践中的持续集成，强调尽可能快尽可能频繁地提交代码，与系统的其他部分进行集成。在提交新代码之前，必须保证本地的构建过程是成功无误的。谁提交代码使得持续集成服务器构建失败，必须立即停下手中的活，负责修复构建直到成功。下班之前必须要保证持续集成服务器上的集成构建状态是成功的。这样，开发人员和团队很容易检查新功能与其他模块的集成，另外也把未来的集成风险降到最低。

• 组织层级

用户故事是开发团队与客户之间讨论需求的基础。用户故事必须对客户有真实可见的业务价值，并且必须包含对该需求完成的验收条件。用户故事作为业务分析人员、测试人员、项目经理与客户一起确定的用户需求，具有经过验证的确切性。开发人员开发故事之前，必须和业务分析人员、测试人员沟通理解需求；开发完故事之后，必须要由业务分析人员与测试人员根据验收条件进行验收。组织和客户之间可以针对达成共识的故事列表来分析项目状态，从而验证或者修改项目计划。

总之，敏捷众多实践就像一张全面立体的安全网，时时刻刻从各个角度给项目成员、团队，以及组织提供短周期的反馈，帮助团队成员不仅感受到开发过程中的同伴约束，而且也可以感受到来自整个团队的约束，甚至是来自组织之间的约束。这些外来约束也像是缠绕在个人周围的催化剂，纠正或改善个人的行为，达到提升个人的纪律性。

 

 作者简介：

金明，ThoughtWorks咨询师，InfoQ中文社区编辑，SCJP，系统分析师。他在机械模具、数字安全证书，以及海洋航运等行业拥有超过4年的企业应用开发经验。他对敏捷方法学，特别是敏捷咨询和项目管理，以及面向对象分析和架构设计等方面有浓厚的兴趣。

（本文来自《程序员》杂志0906期）

《程序员》杂志官方网站：http://www.programmer.com.cn/