敏捷效能提升的五大要素与误区
敏捷项目管理中效能提升的五大要素
项目管理作为牵动和维系产品交付全流程的重要工作，其效率对研发效能的增益是极为显著的。敏捷项目管理简化了烦琐的流程和文档管理，主张面对面地进行沟通和交流，倡导拥抱变化、快速反应、价值优先，在面临时刻变化的市场需求的情况下，能够保证短时间内交付可靠的产品。那么究竟有哪些要素，使敏捷项目管理方式给效能的提升带来如此重要的帮助呢？我们将在这篇文章中一探究竟。
自组织是指一个系统在内在机制的驱动下，自行从简单向复杂、从粗糙向细致方向发展，不断地提高自身的复杂度和精细度的过程。敏捷项目管理倡导自组织团队，这对于大部分未曾实践过敏捷的团队来说可能有点天马行空，因为传统组织的特征是层级制的结构，用权力与管理来维持运作，每个个体完成专项工作，对结果负责。而敏捷所倡导的自组织，则是用责任和目标作引导，建立自己的团队标准和规则，它是基于承诺的，而非基于管理和监督的。
自组织团队并不是虚无缥缈的概念，早在1986年，The New New Product Development Game一文中就写道：“一个群体具备三个条件时拥有自组织能力：自治、自我超越、正向交互。在我们对多个新产品开发团队的研究中，都发现他们具备这三个条件。”在互联网产品快速更迭的当下，跨领域的自组织团队在各大公司的实践和反思也屡见不鲜。
自组织团队的方式对研发效能的提升体现在多个方面。首先，团队成员可以在迭代过程中选择自己擅长的任务，而非硬性分配，在这种自适应的过程中，团队很容易形成更优的分工安排，这有助于发挥每个人的力量，达成全局效率最优。其次，自组织团队倡导人人有责，弱化职级和职位，每个人都要提升自我，为组织出力，形成正向交互。最后，自组织团队天然的自由氛围，为团队的每个人提供了充分发表意见和想法的机会，这往往会带来更好的解决方案，促进效能的提升。
根据ISO9001质量管理体系对持续改进的定义，持续改进是指关注与不断增加组织有效性和效率的过程，以实现组织的方针和目标。敏捷项目管理倡导每个个体的高度参与和及时反思，比如，在每个迭代周期结尾，都会安排回顾会议，讨论哪些工作做得较好，哪些工作需要批评和改进。这种主动思考并寻求解决的做法，比起被动地等待外部方或客户反馈，能极大地降低风险，减少对效能的影响。
持续改进也是一个团队自驱力和先进性的表现，鼓励团队花时间反思，并勇于抛出问题，能够有效避免当前迭代中已经发生的问题流入下一个迭代周期，从长远的角度看，这样持续改进的团队一定会成为一个高效的团队。
03 频繁交付
在传统软件开发过程中，无论是软件开发人员还是客户，可能都要等待一个较长的周期才能获得反馈，这造成了信息割裂的局面，严重影响效能。而敏捷管理则不再如此，团队需要高频交付通过测试的产品版本，以便项目的所有干系人能够及时获悉项目进度，识别风险并应对变化。
当然，频繁交付不是那么容易做到的。一方面，团队需要转变观念，摒弃以自我为中心的思考方式；另一方面，要做好迭代周期的管理、任务的拆解等工作。我们要意识到，虽然频繁交付在一定程度上增加了一些成本，但是能降低风险并及时应对变化，从而为产品交付带来更大的效能提升。
04 消除对立
对立的情况在互联网公司并不少见，测试人员时常抱怨开发人员提测质量差，开发人员时常抱怨产品需求变动频繁，等等，由此产生的调侃段子也层出不穷。从某种程度上说，这种相互对立起源于工作的“移交”，产品负责人确定需求和排期后，认为自己的工作已经完成了，将需求移交给研发人员进行编码；研发人员写完代码后，同样认为自己的工作结束了，将代码移交给测试人员。每个人都将自己的工作范围划分得清清楚楚，殊不知，产品交付的质量和效率，取决于整个项目周期的所有角色。
敏捷团队的所有角色需要朝着共同的目标前进，荣辱与共。在实践上，尽量避免针对不同的角色制定可能会产生冲突的KPI，比如，对测试人员制定Bug数量的KPI，针对研发人员则制定相反（解决Bug数量）的KPI。我们甚至建议对整个项目的参与人员制定共同的KPI，如果项目失败或延期，那么整个团队都应该为此负责，并持续改进。
05 未雨绸缪
唯一不变的就是变化，在之前的章节中我们不止一次提到，敏捷管理模式是拥抱变化的，其中一项重要的特点就是风险管控，提高对项目有利的事件发生的可能性及其影响力，同时减少对项目不利的事件发生的可能性，并尽可能减少其负面效应。在没有下雨的时候，先把房子修补好。
每日站会提供了一个很好的途径，它不仅能让团队成员互相了解各自的工作概况，还能够通过这种沟通机制将隐藏的风险及时暴露出来，以做预防。在敏捷团队的所有成员面对共同的目标时，主动暴露问题，积极寻求解决，能够更好地促进风险的消化。
虽然敏捷宣言主张个体和互动高于流程和工具，但适当的工具依然能够给我们带来帮助，诸如看板、燃尽图、缺陷跟踪系统等也能帮助我们更早地发现风险，及时做出应对。
敏捷项目管理中的常见误区
敏捷作为一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力，具备高度的实践性和创造性，这样的特性在赋予敏捷强大适配度的同时，也给落地造成了困难，正所谓“道理都懂，实践难行”。切实有效地落实敏捷思想，真正为效能提升服务，是每个敏捷项目工作者都需要努力的方向。本节将介绍敏捷项目实践中的一些常见误区，以便使读者触类旁通，少走弯路。
01 敏捷开发就是快速开发
敏捷这个词很容易让人联想到快速、迅速等字眼，继而认为敏捷开发就是单纯追求速度的开发方式。但如果我们回过头重新阅读一下敏捷宣言，就会发现敏捷开发最大的关注点其实是价值交付，而价值交付最核心的一点就是质量。因此，敏捷项目中的快速是以保证交付质量为前提的。
质量和效率也不是互斥的关系，相反，高效的流程和快速的变化响应能够极大地减轻人的心智负担，遇到变化也能更及时地调整项目策略，这些都能促进质量的提升。因此，笔者认为，在敏捷项目中，“快”和“好”是“既要、也要”的关系。
02 敏捷开发应当抛弃文档
敏捷宣言中提到，工作的软件高于详尽的文档，但并不提倡完全地无文档化。我们需要认识到，文档只是人类传递信息的一种手段，我们曾提到信息熵的概念，文档传递的信息熵一般比语音沟通更高，因此文字是一种非常好的信息传输介质。但同时，文档作为一种持久化的媒体，需要进行同步和维护，这些隐性的代价也是需要重视的。
在敏捷项目管理中，提倡撰写必要的文档，不拘泥于格式，而是以提供清晰、易读的信息为目标。让文档成为沟通协作的有力补充，避免为写文档而写文档，这才是对“工作的软件高于详尽的文档”这句话的正确理解。
03 敏捷开发只适合小微团队
秉承这一观点的人们所持有的最大论据就是所谓的两个披萨原则，这一原则是由亚马逊CEO贝索斯提出的，他认为如果两个披萨不足以喂饱一个项目团队，那么这个团队可能就显得太大了。Scrum指南建议敏捷团队的人数在3～9人为宜，也遵循了这一原则。
这套理论本身是很有建设性的，甚至其背后有数学原理的佐证。如果将敏捷团队的每个人视为一个点，而将人与人之间的联系视为关系，那么随着团队人数的增长，关系将呈现更大的增长趋势，这意味着沟通成本和协作成本将大幅上升。
但这并不意味着敏捷开发只适合小微团队，大型团队可以通过合理的组织拆分，建立多个负责相对独立功能模块的Scrum团队，达成全局敏捷的目标。虽然这项拆分工作有诸多挑战，但众多互联网一线公司的实践经验表明，将敏捷实践应用于大型的、复杂的项目是完全可以的。
04 敏捷开发沦为小瀑布开发
在一些团队的敏捷实践中，能够将项目拆分为若干可交付的迭代周期，但在每个迭代周期内，依然还是遵循瀑布模型的开发方式，我们将这种表面敏捷、实则瀑布的模式称为“小瀑布”模式。小瀑布模式在项目需求稳定的情况下，其表现也许和敏捷模式没有太大区别，但是一旦需求频繁变化，差异点就会明显体现，团队成员也会变得异常忙碌。究其原因，虽然应用了敏捷理念，缩短了迭代周期，但还是在按照瀑布模型的习惯和工作方式在工作，并没有思考敏捷的核心价值。
图3.3是一个比较典型的小瀑布模式案例，虽然也切分了若干短迭代，也有相关的站会、评审会议等内容，但各角色间的协作方式依然是以瀑布模型中的契约形式进行维系的，以文档做驱动。而测试的角色定位仍然在项目后期，没有参与到项目全周期的工作中，可以想象，当需求变化频繁时，后期介入的角色就会疲于奔命、频繁加班，最终导致产品交付急促，质量低下。
图3.3 “小瀑布”模式
05 敏捷是没有约束的
既然敏捷开发提倡拥抱变化和快速响应，那么是不是随机应变就可以了？甚至有开玩笑的说法：“你们搞敏捷，那以后改需求就方便了，随机应变嘛，如果需求改了，那么快速反应就好了”。
敏捷方法有一个核心元素——“时间盒”。它的意思是，在一个迭代周期内，团队只负责完成当前迭代计划的任务，如果有其他任务加进来，比如需求变更，只能延迟到下一个迭代周期。更宽松一些的做法是，在可接受的范围内（人员增减、资源缩放等）接纳需求并重排优先级，以顺应需求的变化。但无论哪种做法，约定和规则都是必需的，敏捷开发并不是无序和随意的，而是团队自主形成规则和处事方式的统一。
* 本文节选自《软件研发效能提升之美》一书，欢迎阅读此书了解更多内容！
交付，是技术团队的核心职责之一，如何持续地提升技术团队的交付效能，是每一个技术管理者必须考虑的问题。
感谢吴骏龙、茹炳晟两位老师的新作，能够帮助大家系统性地了解从组织、管理、流程、工具、研发体系、质量体系、运维体系中提升效能的方法。建议所有软件研发人员和技术管理者都读一读本书，一定会受益匪浅。
往期推荐