然而，即便我们对于各种敏捷原则、范式、方法和流程了如指掌，仍会发现其所给组织带来的改善远达不到我们的预期。这到底是为什么？造成这样的困境的根源并不是我们学得不精。而是实践不到位。
在我看来。敏捷宣言过于简单（好吧。是宣言总得简单一点！），以至于足以让人对之产生误解。比方：“能够工作的软件胜过面面俱到的文档”easy让人忽视对必要文档的重视。“个体和交互胜过过程和工具”easy让人误以为有了面对面的沟通就能够忽视适宜的过程和易用的工具所带来的巨大正面作用。就我的观察。仅仅要软件开发活动中忽视了必要（言简意赅）的文档、适宜的过程及易用的工具就一定“敏捷不起来”，由于它们是塑造训练有素的个体所需的重要素材，而个体正是敏捷原则中所提到的自组织（开发）团队的组成单位。团队是否做到自组织是检验敏捷思想是否真正落地的重要判定根据。然而。团队要真正做到自组织却面临非常大的挑战，让我们分别从几个方面加以探讨。
首先，从项目管理层面加以审视。近期面试了一个项目经理，他在华为和腾讯两家公司都干过，从与之的交谈中非常明显地看出他对于敏捷软件开发有着良好的实战经验，也对实践中所碰到的困境有着自己独特的思考。
然而，当我问他“实施敏捷软件开发的最大挑战是什么”时，他的回答却是“项目难以如期完毕”。得知他的这一回答后，我马上告诉他“虽然你谈起敏捷时头头是道。但你内心深处并没有真正拥抱和理解敏捷”。
在告知他我为何得出该结论后。他抱以微笑并对我的观点加以认可。
我预计与他有相同想法的项目项目管理者大有人在！
“响应变化胜过遵循计划”这条宣言告诉我们。软件项目的评估是为了适应变化而非为了遵循计划。更深一层的含义是，项目计划应当保持一定的弹性（指计划时间能够常常适时地调整，项目管理也得敏捷！
），即如期完毕项目计划并不是是敏捷所倡导的。她所倡导的应是持续地以更高的效率完毕高质的软件开发工作。
然而，受传统项目管理思想的影响。我们大部分管理者仍然以项目是否如期完毕作为一个重要的考核指标。
其实。对项目计划要求越是精确（这里的“精确”是指计划一旦制定就得严格如期运行，或者我们说项目计划非常具“钢性”），实现自组织团队的困难就越大。为什么？
其实，不论软件开发project师的经验多么丰富，要真正精确评估实现一个软件功能的时间在非常多情形下差点儿没有可能。当然，现实中存在还有一种“精确”。即通过更大的时间冗余使评估显得“精确”。这所导致的直观结果就是，终于单从项目计划上就能一眼看出“根本不敏捷”。
项目计划一旦不具一定的弹性，所产生的还有一个问题是开发project师在实现功能时根本无法将一个功能做到让自己惬意，由于将时间评估得偏少这类事总在发生。
原因在于非常多project师迫于管理层的压力，不会将时间评估得保守。而是报着“我加加班应当能够搞定”的心态。终于的结果就是，project师为了按计划完毕工作仅仅能“缺斤少两”地做事。
让项目计划保持一定的弹性会让非常多管理者（包含项目经理自己）提出一个问题，即“那我怎样知道项目是否进展顺利呢？”其实。项目是否真正进展顺利并不能简单地从计划的运行情况看出，由于软件的真正质量和开发效率并不是体如今项目计划的钢性上。管理者在这样的情形下能做的除了信任团队外，去了解很多其它的团队状况、技术细节也许有助于平复自己的焦虑情绪。千万别忘记，没有信任就没有敏捷！也千万别忘记，敏捷意味着更高的开发效率和软件质量，而项目计划是否如期运行根本没有全然代表这两个诉求！
值得一提的是，我并不是主张管理层该盲目、简单地信任团队，在之前一定要确保开发团队中存在合适的人可能让团队自组织起来。但管理层一定须要意识到的是。即使团队中存在那样的人，也要配合适当的管理方法才干让那些人真正将团队带向自组织。
其次，从基层技术管理的角度加以剖析。
技术管理的核心内容是提高团队技能（參见《技术管理的核心内容——提高团队技能》），但不少基层技术管理者从技术走向技术管理岗位后，将（绝）大部分精力投入到项目管理事务中。忽视自己所应承担的团队管理责任。
更为可怕的是，这类人非常easy将团队的自组织能力放在一边，既听不进团队发出的声音，也不会去刻意培养，这样的管理模式造成我们永远得不到真正自组织的团队。
我在《怎样做好基层技术管理工作？》一文中谈及了动机与方法两慷慨面。在本文讨论的主题下需做一些补充。
当团队还不具备自组织能力时。基层技术管理者起到至关关键的数据。第一，重视工作安排策略。
大多情况下。由于项目的时间压力，基层技术管理者非常easy採取根据project师的技能安排他做最能获得效率的工作这一策略。然而。长期採用这一策略将导致project师所熟悉的模块趋于单一化，结果导致工作安排缺乏弹性，变成“每一个萝卜都挪不了坑”。这样的境况非常不利于团队技能的发展，也使得团队非常难进入自组织的状态。更为合适的做法是，在每次迭代中安排少数几个project师做他们不擅长的。多次迭代下来。project师所涉功能面将更广。这就为项目计划时的人员安排带来了更大的弹性，也使得各功能模块的代码能在多个project师的视线范围内。从而更easy落实质量。第二。假设不能营造一种让project师畅所欲言的团队文化，则相同没有将团队带入自组织状态的可能。在我看来，仅仅要是一名管理者，假设你的下属不愿向你吐露工作中的心声，那证明你已失败！第三，在制定开发计划时，基层技术管理者一定要持续地将一仅仅眼睛盯住改善部分。而不能仅仅关注新功能开发。不断改善的目的，是为了防止技术债高筑而使得程序变更缺乏弹性。
第四，团队在走向自组织的道路上。一定存在不少对既定目标做适当变更的情形，此时基层技术管理者一定要做好上下间的沟通工作，让团队的工作状态对高层管理者更加透明。信息的透明化有助于管理高层真实了解团队的现状，为信任提供良好的支撑。让他们不至于过于关注项目计划的钢性。第五，确保软件设计质量与编码质量落实到位。换句话说，确保在团队中落实概要设计评审和代码审查等工作流程。
我相信非常多基层技术管理者想将团队带好，但不少人受能力、惰性和胸襟所限，根本不理解什么是自组织团队。也不愿意学习与自我改善，还放不下自己是“领导”的架子。然而，这类人正是自组织团队要“消灭”的。于是。我们面临这样一个悖论——“为了自己不被‘消灭’，这类人一定带不出自组织的团队”。不难发现，合适的基层技术管理者是打造自组织团队关键中的关键！
再次。我们从project师的角度给予考量。
自组织团队对于project师来说到底意味着什么？第一。技能多样化。
技能过于单一往往会造成项目计划的实施瓶颈在于某个人无可替代地处于项目的关键路径上。这使得项目的人员安排缺乏弹性。
要实现技能的多样化首先要从管理着手，即须要基层技术管理者有意识地通过工作安排加以培养，这一点我们前面已谈及。还有一方面，project师也得有意识自我培养。千万不要将自己的工作锚定在非常窄的范围。为了避免出现这样的境况，project师对自己的工作内容应通过编写言简意赅的文档（比方概要设计、指南等）的方式让他人能够方便地接手。显然。文档的编写能力也涵盖于技能多样化之中。第二，律己和律他。“自组织”这个词从表面就向我们传达了“纪律”，纪律意味着质量与效率。project师个体首先需有良好的自律能力。对于团队所达成的各种共识（规范、流程等）努力实施到位，对于已存在的好方法、好习惯积极地模仿并尾随，而不是简单地打破并自立门户。除了良好地律己我们还得关注律他，通过指出他人不足并给予帮助的方式让整个团队维持良好的工作纪律。第三。良好的方向感。
这样的方向感源于清楚地知道产品的定位与战略，并基于此而形成的、清楚的软件开发策略。良好的方向感使得project师清楚地知道技术的真正价值在于为产品的核心竞争力提供强有力的支持，并努力在产品与技术之间获得平衡。在我看来，简单地偏向产品或技术，从长远来看对于整个团队都会是一种灾难。第四，主动承担责任。
面对责任。与“主动承担”相反的方式是“防御”或“逃避”。
自组织团队一定不会害怕责任，当出现故障时project师会主动承担责任或帮助他人解决，呈现的是一种互帮互助的良好协作氛围。第五，自发地持续改善。在具有良好方向感的自组织团队中，project师会时刻关注开发工作中的点滴改善，通过持续改善的方式从技术层面不断地将产品推向更高的品质。
从项目管理、技术管理和project师三个纬度的分析能够看出。真正的敏捷自组织团队须要从上到下、各工种的理解与配合才有可能打造出来。“敏捷”所强调的很多其它的是“弹性”，由于具有良好弹性的团队在面对各种压力时才具韧性。试想想。假设个体被桎梏于仅仅能容下身体的空间中，那么我们有可能做到（伸手）“敏捷”吗？
真正的敏捷不是形式。而是团队的文化与能力。假设不注重从文化与能力上去塑造。不管我们对于敏捷之形多么在意和刻意临摹，我们永远仅仅能游离于表面。