你被敏捷“祸害”过吗？
背景：
在这个充满不确定的VUCA时代下“变才是永恒的不变”，企业为了更好更快的是满足用户需求和适应市场的变化，获取更多用户的认可及市场占有率，就需要主动拥抱变化，敏捷转型已是必然趋势。但在转型过程中会遇到层层阻碍、各种挑战和误区，很可能导致企业只学到了敏捷的“形”，并没有领会其精髓，花费了高昂的代价并没有达到预期效果，团队在执行过程中非常痛苦，加班填坑已是常态；而转型成功的企业或团队，形成了“自我组织”形态，使得团队能快速高质量的交付需求或产品。
为什么说会被“敏捷”祸害？
1、传统到敏捷转型的痛
交付时效痛点：传统从上到下设计的瀑布研发模式，变更代价大，交付周期漫长，难实时响应市场变化，但敏捷开发模式可以通过小批量交付，缩短交付时效。
交付内容痛点：
该痛点往往是交付时效太长，导致需求澄清重要细节的损耗，或因交付过程太长，期间出现需求变更。采用敏捷实践后，基于频繁的沟通与持续的交付，让业务有机会不断校准需求细节，促进交付内容更符合业务目标。
交付质量痛点：
传统瀑布模式的质量意识是测试在研发末端进行介入，并做系统质量最后的兜底，而测试时间常被压缩的情况下就很难保证系统质量。在采用敏捷方式后，并落地测试左移、开发Showcase 等实践，每次交付的内容能得到更充分的测试与验证，版本质量有所改善。同时由于每次交付的“容量”降低，问题定位与修复将更快。
过程黑盒痛点：
瀑布模式中每个阶段都有各自的角色和分工，各自只关心自己的任务。采用敏捷方式后，可实现持续沟通、双层看板都将向业务透明进展与实际情况。
创新痛点：
业务的产品创设与创新，本身有业务敏捷的实践。落地时都需要研发具备持续交付与快速实验能力，这都是研发敏捷实践可以辅助的内容。
2、技术债
很多应用软件多年来一直在膨胀的数据库和升级补丁，已经让许多公司的技术架构失去了灵活性。大多数公司，在提供给用户的应用软件都是在更科学的设计架构（如微服务架构）出现前开发完成的，饱受刚性架构之苦，太多的功能都被耦合在一起，如果想要对其中某一段代码进行变更，产生的影响可能如同雪崩。这样的情形下，开展“小步快跑”的敏捷转型无疑会掉进巨坑里面，可能先对系统进行科学的技术架构改造，带来的效益更加明显。
3、人才梯队建设不健全
人才是数字化运营模式中的核心，企业也很清楚要招聘能够负担得起的最优秀人才，从近几年来看，想要招到对的人来提升IT企业的敏捷性难度很大。
加之进行技术外包形式，一定程度上也加剧了技术人才缺失的问题。企业还可能过于依赖这种方式，内部的人才大多数时间都在将任务接洽给承包商，他们自己的技能不断退化。这导致技术承包商垄断了大量的人才资源与创新能力，形成了强大的市场竞争力。在这样的情况下，倘若公司里一半的人都不是内部员工，怎么能指望科技企业进行敏捷变革呢？强行上马敏捷，很可能产生许多研发同学抱怨，加班比之前严重了，实际效果还不好，仿佛敏捷成为了管理者剥削研发人员的高级手段的假象。
4、组织职责不明确
公司内部权责模式不明确，如：产品的构建和维护的过程中，如果出现问题该由谁负责。许多企业将产品的开发和运维区分开来，因为这样便于将产品后续的运维支持外包给第三方。如果大半夜的软件出现了问题，到底应该找谁解决问题呢？是写代码的人还是负责运维的人？在敏捷团队中整合开发、运营和维护，能够解决不必要的职责纠纷，建立明确的端对端问责机制，这也是敏捷转型的核心要义。
5、缺乏产品思维
传统的项目导向、瀑布开发等模式不够灵活，对于市场和客户的响应不足，采用的非产品导向型开发模式，产品经理渐渐的形成思维固化。项目制导向下，开发团队会不停的组成又解散，不利于业务和文档的传承、沉淀。敏捷方式的产品导向队伍在整个产品的生命周期中都将延续和沉淀，团队的稳定性能让队伍更加高效，快速反应。
如何落地“敏捷”转型
1、前期准备
1.1、心理准备
管理层面，通过各种方式充分营造团队积极、开放、协同的环境文化氛围，评估高层对试错的风险承受力，鼓励并支持团队甩掉心理包袱，勇敢面对转型带来的挑战。
团队层面，敏捷教练除了给团队进行前期敏捷思维、思想的培训及引入，还要引导团队充分评估敏捷转型中要调整的工作方式与当前工作方式的差异，制订符合团队实际要求及切实可行的过渡方案。如：针对进行中的项目开展第一次敏捷迭代，先尝试主动参与任务分析，并自行按优先级领取任务，最终实现承诺。
1.2、行动准备
第一步，明确各个敏捷角色的“主”职责。从瀑布方式转型为敏捷方式中，一个最难的环节是团队成员的角色转变。如：敏捷框架中产品负责人负责确定需求及需求的优先级；敏捷教练负责引入敏捷，及作为领航员给团队指明方向，帮助团队扫清障碍；团队成员负责项目的增量产品交付，并对交付产品失败负直接责任。事实上，任何一个角色在转型过程中都需要与其他角色相互合作、主动协同。
第二步，信息透明化。在瀑布型项目中每个人都是流水线上的一个节点，工作成果完全依赖节点的个人能效，一旦某个节点成为瓶颈，就很容易导致项目延期。若采用敏捷方式，团队首先要梳理和明确工作流程，把之前按节点交付转化为按迭代增量产品交付，再根据团队产能评估每个迭代可以完成的故事点，借助“看板”将故事和任务在组织中透明化。迭代过程中，可以通过每日站会和实时看板，快速找到团队瓶颈并移除障碍，从而高效地交付增量产品。在落地敏捷转型初期就可以看到明显效果，这就是信息透明化给组织带来的好处。
第三步，复盘。组织中任何一个改变都源于对问题的深刻思考与行动，在敏捷转型过程中，会出现各种水土不服的情况。例如，产品负责人无法描绘出好的用户故事，敏捷转型提倡的客户/业务参与成为空谈，迭代目标一再被改变。不论现状如何糟糕，都要允许团队在失败的教训中站起来，即使团队现在做得不够好，也不能轻易否认团队的付出。失败的教训是走向成功的必经之路，也是一笔宝贵的财富，只要团队能达成共识，敏捷转型这条看似艰辛的道路会越走越宽，越走越清晰。
2、怎么落地敏捷转型
敏捷转型之路并非一条康庄大道，其实是一条充满荆棘和未知困难的道路，只有真正的去落地实施，才能领略到过程中的痛苦与幸福。从“了解敏捷”到“落地敏捷”，可以从以下四方面进行实践落地。
- 打好地基
敏捷转型真正落地起来，会发现最大的阻力来自团队内部。因为团队成员对敏捷的理解不够系统深刻，可能会出现很多干扰的声音，这时专业敏捷教练的引导尤其重要，他会根据项目特点为团队导入敏捷的价值观和理念，确保各个层次相关角色的理解和支持，当团队成员出现理解偏差时，及时把团队带到正确的轨道上来。
- 建立稳固框架
敏捷转型有很多好的方法和实践，找到适合团队的转型方法很关键，设计敏捷导入的步骤和阶段，如：引入devops工具链实现持续集成，“工具+流程”形成“看板+早站会”团队，并结合项目实际不断改进就变成团队推行敏捷的龙骨。
- 搭建整体结构
地基打好了，框架稳固了，剩下的就是执行到位。敏捷提倡自组织，通过敏捷教练对自组织的导入及培训，让团队找到敏捷转型对个人和组织的意义所在，自组织就变得更容易，敏捷转型就变得更接地气。
- 加强固化
从“了解”到“落地”最有效的方法就是“重复”，转换到团队上就是反复迭代，团队通过每次迭代后自我复盘找到问题点，每次改进一点，长期积累下来就会让团队在不知不觉领略到敏捷转型的好处了。
敏捷开发是创造价值的有效方法，仅光有敏捷是不够的，不过许多企业都在努力地获取敏捷开发带来的技术、人才和产品管理上的优势。解决架构刚性、人才紧缺的问题，采取产品导向型的开发模式，需要企业领导及技术领袖承担足够的责任，并持续付出努力。现如今看来，这些方法本质上就是决定商业目标与技术目标之间的优先级，只有真正愿意且努力让企业更好地走向敏捷开发的公司，才能够享受到不断积累起来的收益，不会被“敏捷”祸害。
作者介绍：ID丝滑Tester，30人质量团队负责人，CCTalk成员
往期回顾：
腾讯云开发者
