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