敏捷项目管理-如何破解敏捷实践中的三大难题

        敏捷是一种实践，只有在落地才能取得真正的价值。而实践中每一步的进展都是通过解决问题而得到的。但是源源不断的问题，也会让敏捷团队内部产生危机。

       以软件开发为例子，常见的内部危机，包括因与重要关系人沟通不畅导致发生矛盾、研发节奏出现问题，技术团队内部对方案的理解偏差较大、敏捷实施对研发团队成长促进慢等等导致成员对敏捷导入的怀疑等等。对于敏捷教练介入项目后，应先与成员进行沟通，收集到核心问题，然后按优先级等级进行逐个击破，用一句话说就是“先救命再治病，恢复常态后进行日常保健”。在笔者掌握到的敏捷案例中，一般有三大难题是每个敏捷团队leader必须去破解的。

        一、敏捷实施的三大问题

       问题一：如何解决与重要关系人沟通不畅导致的矛盾问题？

       重要关系人对敏捷团队的影响深远，根据pmp的关系人矩阵的描述，业务领导是最重要的关系人，但是往往矛盾与这位最重要的关系人身上，如业务领导不满功能上线的时间为什么拖着这么差，因为商机是有时间窗口的，错过了上线也没有意义，而且还有很多bug。而敏捷研发团队人员则认为需求经历需求澄清、系统设计、研发以及测试，在这么多时间内上上去已经非常给力了。

       造成双方的看法矛盾，主要在沟通不透明的情况下，各方的判断前提有差异导致结论不同。业务领导这个idea也许是通过一个月的市场调研得到的，其理解的是这个过程是一个月+迭代周期（一般是两周），一共6周时间。而技术团队，理解的过程就是迭代周期里面这两周，而且这两周里面还包括了对需求的确认，有时需求价值也没有明确传递到团队中，其实总感觉到好像这需求是拍脑袋的事情，经常又急又没有价值，纯粹试错而已。归纳起来就是沟通缺乏透明。

       破解方法就是找到最核心的问题，透明出来，并促进互信和理解一致。案例中提供两个方法：业务看板以及每周业务站会。

1. 业务看板主要是对需求

       进行粗粒度的整理，分为需求落地状态、上线计划期望以及需求清晰度。

        需求落地状态标识各个需求（未分解成用户故事）处于idea、构思、待拆WIS、设计研发以及已上线，这个子看板，让业务领导的需求从闪现到上线的过程，全体成员都能及时识别到。

       上线计划期望子看板，则明确在近2-3个月份中各个冲刺sprint的重点内容。

       需求清晰度子看板，则对PO的需求准入进行了限制，让需求更明确得到研发团队的理解。

这个业务看板，建议放在业务领导和PO必经之处，让业务领导随时可以了解项目的进展，减少了信息的不对称。

 

        2、每周业务站会

        每周业务站会为技术负责人与业务领导创造直接沟通和澄清问题的机会，之前靠PO中转信息，现在增加了一条直接沟通的渠道，让问题透明出来，促进互信和理解。一般建议会议不涉及太多细节，流程中PO先简述业务和需求的情况，业务领导或者运营可以进行补充和提新需求，然后技术负责人进行研发进度通报。

解决了与重要关系人矛盾问题，让项目团队得到了生存下来的机会。也进行就是把命救下来。

        问题二：如何减少浪费和衰减，提升质量？

        这个问题，很多时候表现在团队频繁加班导致效率衰减，研发团队内部对技术方案的理解差异导致技术方案变更，测试时间被压缩等。其奥中原因主要是并行工作出现在跨迭代周期里面，导致缺乏专注。

        很多时候，我们会把上述情况归因为业务方要求快速上线，导致需求还不够清晰的情况下仓促开始设计研发。没错，业务方肯定希望快速上线，来取得市场的反馈，从而验证需求。但是经过对问题一的解决后，业务方更希望项目能以稳定的节奏推进，能得到预期的功能，而且功能的质量是有保证的。

       既然明确了业务方的核心诉求，那么们的解决方法就建平稳的timebox以及组织回顾会。

        1、平稳的timebox

        如果现有的迭代周期无法消除跨周期的并行工作，那么我们就改变研发工作安排，干掉所有跨迭代的并行工作，从而建立平稳的研发节奏。也就是我们把timebox给定出来了。Timebox是敏捷团队提升的基础，并为团队争取到提高质量争取到时间。

 （调整前）

（调整后） 

       2、回顾会

       真实有效的组织回顾会，检视出真正的问题，建立有效的标准，统一认知，解决好协同问题。案例介绍回顾会可以让团队投票把最需要解决的问题选出来，确定责任人、解决时间，以及方案，并通过告示板公示出来。

       问题三：如何让成员拥抱敏捷，走行自管理？

       团队成员自我管理是敏捷的一个目标，但是如果才能让经历、性格和能力各异的成员去主动拥抱敏捷，走向自管理呢？这个问题作为敏捷教练也必须深思。

       对于团队leader来说，内容交付、团队成长、个人成长等三方面的共赢是敏捷实践的目标。很多时候，我们无法在金钱上进行激励的时候，我们可以通过激励个人成长去完成这点。主要方法：1、轮值迭代牵头人，2、路线图优化

1. 轮值迭代牵头人

       这个是对骨干进行培养的方法，重在发挥他们主观能动性。可以选择有一定经验的骨干，轮流迭代中担任牵头人，进行需求对接、任务拆分、结对设计，然后技术负责人组织评审，这样让骨干去感受高于他们岗位之能的工作，体验一把充当团队leader。经过这样一个过程，骨干得到了成长，更容易理解作为leader的艰辛之处，也对敏捷的优点有了深入的理解，在工作中发挥更大的主观能动性。

 

       1、路线图优化

       在开始的敏捷开发流程中（经常是小瀑布的流程），产品在构思下一个迭代的需求，研发在开发本迭代的功能，而测试则在测试上一迭代的代码。一般需要上个迭代周期才能上线功能。 好一点的，则是产品在探索新需求，而上个版本需求正在本迭代中开发和测试。

       但是这里就存在一个问题，那就是开发和测试对需求探索的价值没时间掌握，也在新需求价值的传入上大打折扣。如果研发和测试同时进行，实现自动化测试，那么就缩短了回归测试的压力，整个团队对新需求探索过程投入大，对交付的质量就更有保证。

       诚然，需求探索、功能研发和测试三者如果能同时进行，那么则最吻合敏捷的要求，但是一般条件下，达到第三步已经非常不易。

二、三大难题的通用解决流程

   经过对上述三大难题的逐一破解，我们得到了对应的解决之道。接着我们把这些难题解决流程串联起来，为大家提供一个通用的解决方案

1. 先解决生存问题。一般是与重要关系人有关，其中最重要的是业务领导。
2. 推动透明。关键人员建立直接沟通的通道
3. 形成Timebox。在Timebox实现专注。
4. 发动大家解决问题。在回顾会中让团队自己发现问题和解决问题。
5. 激发团队。激发团队自管理，并看到需求的价值。
6. 问题不断涌现，做好心理准备。

       

       三、结语

      对抗层出不同的问题，最好的应对方法就是建立自己的敏捷思考系统。作为leader，首先要从组织实施的目的入手，因为敏捷实践是建立在特定的组织文化中oqi的，脱离了这土壤因素，实施的价值则丧失。而组织导入敏捷的目的，主要是更好地交付、提升能力、更有价值的交付、带领团队成长以及提升个人能力。

 

       到达技术团队leader层面，应该是基于组织的目的，实践的目标就是更有价值的交付、带领团队成长以及提升自身的能力。其中人因素的部分，最为复杂。更需要我们通过内驱因素，如职场进阶、自我实现等方面进行思考和引导，方可让团队和个人在敏捷的实施中持续地得到收益。

         最后，文中除了脑图外 ，其他图片素材来自杨大鹏老师，在此深表感谢。