常见企业实施敏捷容易范的5个错误

常见企业实施敏捷容易范的5个错误，总结归纳下，有如下几个：

第⼀，建⽴“敏捷IT”不等于可以忽略IT开发中的⼀些基本最佳实践。有些企业⻓期以来缺乏对开发过程管理的重视，加之经常⾯临开发时间短、经费紧等压⼒，为了追求开发速度，往往不够重视需求管理、开发代码质量管理等基本⼯作。在接触到“敏捷IT”的概念后，更是简单错误地认为“敏捷IT”就是“去⽂档化”“开发代码质量问题留给迭代慢慢解决”等。殊不知，敏捷所倡导的“快”并不简单等同于省略关键的⼯作步骤，⽽是要求IT与业务之间增强沟通，以“⼩步快跑”的⽅式来应对业务需求的不确定性，避免因沟通不及时导致IT开发“⼀步跨错”。⽽对于需求管理、代码质量管理等IT本职⼯作，即便在“敏捷IT”模式下，IT部门仍需要“独善其⾝”：需求依然要清晰记录，只不过建议采⽤JIRA等在线协同平台（甚⾄邀请业务⼀同参与到需求发布与更新中），开发代码质量依然重要，甚⾄建议在开发过程中通过程序员配对等⽅式及早发现代码bug等质量问题。

 

第⼆，建⽴“敏捷IT”不仅是引⼊scrum等开发⽅法论及流程，也需要关键的技术赋能。从需求分析到开发测试上线的整条链路要实现敏捷快速，有很多环节需要⾃动化技术的⽀持，⽐如“代码质量监控”（诸如SonarQube等⼯具可⾃动扫描发现代码中空指针等错误）、“⾃动化测试”（TestAutomation，使⽤脚本和仿真测试数据模拟⼤规模、复杂场景的系统操作）和“持续集成”（Continuous Integration，伴随频繁的代码更新进⾏连续⾃动地测试和发布）。对于许多企业来说，真正需要克服的挑战未必是学习这些技术本⾝，⽽是如何使这些技术可以落地并充分发挥其作⽤。例如，有些企业的系统测试环境缺乏良好管理，测试数据常遭到肆意篡改或删除，导致⾃动化测试技术⽆法有效执⾏。

第三，建⽴“敏捷IT”需要在IT开发组织内打造“稳固团队”（stable team）。许多企业习惯了以项⽬制的⽅式来交付业务需求，特别是那些极⼤依赖于外包商进⾏IT开发的企业，久⽽久之，从需求规划、预算编制到⼈员组织等都变成以项⽬为单位来管理。这⼀模式的弊端在于，很难培养熟悉垂直业务领域（如客户关系管理、产品定价）、具有稳定交付速率且拥有从开发到维护端到端责任感的团队，⽽这种植根于垂直业务领域的稳固的开发团队，对于更准确的项⽬交付周期规划，以及以更稳定的⽣产效率进⾏产品快速迭代更新，都是⾄关重要的。建议企业将产品和服务进⾏垂直领域划分，配置聚焦不同领域的开发团队和产品负责⼈（Product Owner），并与该领域的业务侧团队（如营销团队）对接，形成更紧密的沟通和协同机制。

 

第四，建⽴“敏捷IT”不光是IT部门的任务，更需要业务部门共同参与。在传统IT模式中，业务侧在确认了需求⽂档后就很少再介⼊IT开发，直到最后进⾏⽤户验收测试。所以，在很多企业内，“敏捷IT”转型，被认为是IT组织内部的事情，⽽事实上，很多“敏捷IT”转型的失败，恰恰也是因为忽略了业务侧在其中的⾓⾊和责任。真正的“敏捷IT”，要求业务与IT⼀起制订并定期审视IT预算在各个垂直业务领域的分布、规划并定期调整开发维护团队资源的配置，在系统开发过程中，更是要定期（如每周）共同检视阶段性开发成果并讨论下⼀轮开发的需求或优先级变更。成功建⽴“敏捷IT”的企业，⽆不贯彻了“业务共同参与”这⼀关键⽅针，甚⾄在⼀些关键产品开发上，让业务侧负责⼈直接成为“产品负责⼈”，让业务侧意识到，产品开发IT项⽬的成功最终其实是业务的责任，⽽不单单是IT的责任。

 

第五，建⽴“敏捷IT”关键在于开始⾏动。不必苛求⼀步到位的敏捷，也不存在唯⼀的敏捷最终形态。每家企业因其⾃⾝差异及所处⾏业的特异性，总是存在或多或少的局限，与其⽆限制地等待理想条件的产⽣，不如先从引⼊基本的迭代开发等概念开始，逐步加快IT交付的节奏及与业务侧协同的频率，同时提升IT⾃⾝在开发过程管理中的基本功。等到⾃动化测试等技术应⽤到位及业务与IT的信任关系进⼀步增强后，再择机向更敏捷的IT开发及交付模式靠拢。与此同时，企业也应该记住，敏捷本质上是⼀种精

神、⼀种原则，⽽不是⼀种单纯的流程或者⼯具形式。“敏捷IT”的落地必须因地制宜，结合企业实际情况调整适配。