打造敏捷的自组织团队

敏捷思想的出现让咱们看到了新的曙光——以更低的风险、更高的效率开发出更具质量的软件产品。正因如此，敏捷方法获得了业内足够的重视并使各路团队相拥实践。然而，即使咱们对于各类敏捷原则、范式、方法和流程了如指掌，仍会发现其所给组织带来的改善远达不到咱们的预期。这到底是为何？形成这种困境的根源并不是咱们学得不精，而是实践不到位。

在我看来，敏捷宣言过于简单（好吧，是宣言总得简单一点！），以致于足以让人对之产生误解。好比：“能够工做的软件赛过面面俱到的文档”容易让人忽视对必要文档的重视；“个体和交互赛过过程和工具”容易让人误觉得有了面对面的沟通就能够忽视适宜的过程和易用的工具所带来的巨大正面做用。就个人观察，只要软件开发活动中忽视了必要（言简意赅）的文档、适宜的过程及易用的工具就必定“敏捷不起来”，由于它们是塑造训练有素的个体所需的重要素材，而个体正是敏捷原则中所提到的自组织（开发）团队的组成单位。团队是否作到自组织是检验敏捷思想是否真正落地的重要断定依据。然而，团队要真正作到自组织却面临很大的挑战，让咱们分别从几个方面加以探讨。

首先，从项目管理层面加以审视。最近面试了一个项目经理，他在华为和腾讯两家公司都干过，从与之的交谈中很明显地看出他对于敏捷软件开发有着良好的实战经验，也对实践中所碰到的困境有着本身独特的思考。然而，当我问他“实施敏捷软件开发的最大挑战是什么”时，他的回答倒是“项目难以如期完成”。得知他的这一回答后，我当即告诉他“尽管你谈起敏捷时头头是道，但你心里深处并无真正拥抱和理解敏捷”。在告知他我为什么得出该结论后，他抱以微笑并对个人观点加以承认。我估计与他有一样想法的项目项目管理者大有人在！

“响应变化赛过遵循计划”这条宣言告诉咱们，软件项目的评估是为了适应变化而非为了遵循计划。更深一层的含义是，项目计划应当保持必定的弹性（指计划时间能够常常适时地调整，项目管理也得敏捷！），即如期完成项目计划并不是是敏捷所倡导的，她所倡导的应是持续地以更高的效率完成高质的软件开发工做。然而，受传统项目管理思想的影响，咱们大部分管理者仍然以项目是否如期完成做为一个重要的考核指标。其实，对项目计划要求越是精确（这里的“精确”是指计划一旦制定就得严格如期执行，或者咱们说项目计划很具“钢性”），实现自组织团队的困难就越大。为何？

事实上，不论软件开发工程师的经验多么丰富，要真正精确评估实现一个软件功能的时间在不少情形下几乎没有可能。固然，现实中存在另外一种“精确”，即经过更大的时间冗余使评估显得“精确”。这所致使的直观结果就是，最终单从项目计划上就能一眼看出“根本不敏捷”。项目计划一旦不具必定的弹性，所产生的另外一个问题是开发工程师在实现功能时根本没法将一个功能作到让本身满意，由于将时间评估得偏少这类事总在发生。缘由在于不少工程师迫于管理层的压力，不会将时间评估得保守，而是报着“我加加班应当能够搞定”的心态。最终的结果就是，工程师为了按计划完成工做只能“缺斤少两”地作事。

让项目计划保持必定的弹性会让不少管理者（包括项目经理本身）提出一个问题，即“那我如何知道项目是否进展顺利呢？”事实上，项目是否真正进展顺利并不能简单地从计划的执行状况看出，由于软件的真正质量和开发效率并不是体如今项目计划的钢性上，管理者在这种情形下能作的除了信任团队外，去了解更多的团队情况、技术细节或许有助于平复本身的焦虑情绪。千万别忘记，没有信任就没有敏捷！也千万别忘记，敏捷意味着更高的开发效率和软件质量，而项目计划是否如期执行根本没有彻底表明这两个诉求！

值得一提的是，我并不是主张管理层该盲目、简单地信任团队，在以前必定要确保开发团队中存在合适的人可能让团队自组织起来。但管理层必定须要意识到的是，即便团队中存在那样的人，也要配合适当的管理方法才能让那些人真正将团队带向自组织。

其次，从基层技术管理的角度加以剖析。技术管理的核心内容是提升团队技能（参见《技术管理的核心内容——提升团队技能》），但很多基层技术管理者从技术走向技术管理岗位后，将（绝）大部分精力投入到项目管理事务中，忽视本身所应承担的团队管理责任。更为可怕的是，这类人很容易将团队的自组织能力放在一边，既听不进团队发出的声音，也不会去刻意培养，这种管理模式形成咱们永远得不到真正自组织的团队。

我在《如何作好基层技术管理工做？》一文中谈及了动机与方法两大方面，在本文讨论的主题下需作一些补充。当团队还不具有自组织能力时，基层技术管理者起到相当重要的做用。第一，重视工做安排策略。大多状况下，因为项目的时间压力，基层技术管理者很容易采起根据工程师的技能安排他作最能得到效率的工做这一策略。然而，长期采用这一策略将致使工程师所熟悉的模块趋于单一化，结果致使工做安排缺少弹性，变成“每一个萝卜都挪不了坑”。这种境况很不利于团队技能的发展，也使得团队很难进入自组织的状态。更为合适的作法是，在每次迭代中安排少数几个工程师作他们不擅长的。屡次迭代下来，工程师所涉功能面将更广，这就为项目计划时的人员安排带来了更大的弹性，也使得各功能模块的代码能在多个工程师的视线范围内，从而更容易落实质量。第二，若是不能营造一种让工程师畅所欲言的团队文化，则一样没有将团队带入自组织状态的可能。在我看来，只要是一名管理者，若是你的下属不肯向你吐露工做中的心声，那证实你已失败！第三，在制定开发计划时，基层技术管理者必定要持续地将一只眼睛盯住改善部分，而不能只关注新功能开发。不断改善的目的，是为了防止技术债高筑而使得程序变动缺少弹性。第四，团队在走向自组织的道路上，必定存在很多对既定目标作适当变动的情形，此时基层技术管理者必定要作好上下间的沟通工做，让团队的工做状态对高层管理者更加透明。信息的透明化有助于管理高层真实了解团队的现状，为信任提供良好的支撑，让他们不至于过于关注项目计划的钢性。第五，确保软件设计质量与编码质量落实到位。换句话说，确保在团队中落实概要设计评审和代码审查等工做流程。

我相信不少基层技术管理者想将团队带好，但很多人受能力、惰性和胸襟所限，根本不理解什么是自组织团队，也不肯意学习与自我改善，还放不下本身是“领导”的架子。然而，这类人正是自组织团队要“消灭”的。因而，咱们面临这样一个悖论——“为了本身不被‘消灭’，这类人必定带不出自组织的团队”。不难发现，合适的基层技术管理者是打造自组织团队关键中的关键！

再次，咱们从工程师的角度给予考量。自组织团队对于工程师来讲究竟意味着什么？第一，技能多样化。技能过于单一每每会形成项目计划的实施瓶颈在于某我的无可替代地处于项目的关键路径上，这使得项目的人员安排缺少弹性。要实现技能的多样化首先要从管理着手，即须要基层技术管理者有意识地经过工做安排加以培养，这一点咱们前面已谈及。另外一方面，工程师也得有意识自我培养，千万不要将本身的工做锚定在很窄的范围。为了不出现这种境况，工程师对本身的工做内容应经过编写言简意赅的文档（好比概要设计、指南等）的方式让他人能够方便地接手。显然，文档的编写能力也涵盖于技能多样化之中。第二，律己和律他。“自组织”这个词从表面就向咱们传达了“纪律”，纪律意味着质量与效率。工程师个体首先需有良好的自律能力，对于团队所达成的各类共识（规范、流程等）努力实施到位，对于已存在的好方法、好习惯积极地模仿并跟随，而不是简单地打破并自立门户。除了良好地律己咱们还得关注律他，经过指出他人不足并给予帮助的方式让整个团队维持良好的工做纪律。第三，良好的方向感。这种方向感源于清楚地知道产品的定位与战略，并基于此而造成的、清晰的软件开发策略。良好的方向感使得工程师清楚地知道技术的真正价值在于为产品的核心竞争力提供强有力的支持，并努力在产品与技术之间得到平衡。在我看来，简单地偏向产品或技术，从长远来看对于整个团队都会是一种灾难。第四，主动承担责任。面对责任，与“主动承担”相反的方式是“防护”或“逃避”。自组织团队必定不会惧怕责任，当出现问题时工程师会主动承担责任或帮助他人解决，呈现的是一种互帮互助的良好协做氛围。第五，自发地持续改善。在具备良好方向感的自组织团队中，工程师会时刻关注开发工做中的点滴改善，经过持续改善的方式从技术层面不断地将产品推向更高的品质。

从项目管理、技术管理和工程师三个纬度的分析能够看出，真正的敏捷自组织团队须要从上到下、各工种的理解与配合才有可能打造出来。“敏捷”所强调的更多的是“弹性”，由于具备良好弹性的团队在面对各类压力时才具韧性。试想一想，若是个体被桎梏于只能容下身体的空间中，那么咱们有可能作到（伸手）“敏捷”吗？

真正的敏捷不是形式，而是团队的文化与能力。若是不注重从文化与能力上去塑造，不管咱们对于敏捷之形多么在乎和刻意临摹，咱们永远只能游离于表面。