传统软件开发团队敏捷转型策略

1敏捷开发方法的出现

软件工程是20世纪70年代提出来的概念。传统的软件开发方法有瀑布模型、螺旋模型、喷泉模型、RUP4类，它们注重文档的完整、程序的易读性、结构的完整性，属于重型软件开发方法。在过去的一段时间，传统软件工程的方法很好地适应了软件开发的需求，其不仅关注软件构造方式的完美型，同时也注重总体的可预测性，以文档为驱动，按照需求分析、概要设计、详细设计、编码、测试、软件交付的流程来进行开发。在软件产业不是很发达、软件开发人员稀少的过去，这样严格的开发流程无疑是很适用的［1］。随着市场环境的变化，传统软件开发方法面临着严重的挑战。一方面是用户需求的多样性、个性化和快速变化，另一方面则是来自激烈的市场竞争对软件的质量和价值提出了更高的要求［2-3］。这就要求软件开发需要以更灵活的手段来应对不断变化的需求，用更短的时间和更低廉的代价将产品推向市场满足用户需要，由此人们开始对软件开发过程的本质重新进行思考和探索，在20世纪90年代，一系列轻量级开发方法相继被很多软件大师提出。2001年2月在美国犹他州的雪鸟滑雪场召开了软件开发大会，本次会议发布了“敏捷宣言”，包括4个核心价值观和12条基本原则，这标志着敏捷开发的诞生。相对于传统软件工程，敏捷开发主要有3个重要特点：（1）敏捷开发是“适应性”而非“预设性”的，传统软件工程试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依据计划进行开发，这类方法在计划制定完成后拒绝变化，而敏捷开发欢迎变化，甚至允许改变自身过程来适应变化；（2）敏捷开发是“面向人”的而非“面向过程”的，它们试图使软件开发工作能够利用人的特点，充分发挥人的创造力和主动性；（3）敏捷开发是“产品驱动”而非“文档驱动”，开发过程只需要较少的过程文档，在软件的迭代开发过程中，一直保持软件产品的可用状态，以产品的增量来衡量进度的实际状态。敏捷开发的诸多优点吸引了越来越多的软件企业研究敏捷开发，积极实施敏捷转型。

2敏捷转型的反模式

尽管敏捷开发方法已经提出多年，但实施过程中还是出现大量的疑问和难点，在传统型软件企业里面还大量存在敏捷转型的失败案例。这些失败案例可以总结为6条失败教训，即敏捷转型的反模式。

2.1缺少管理层支持

敏捷宣言告诉我们，“围绕被激励起来的个人来构建项目，给他们提供所需要的环境和支持，并且信任他们能够完成工作。”在转型过程中，同样要求管理层需要关注团队成员的状态，为转型工作提供足够的资源保障。

2.2转型目的缺失或不明确

管理层必须明确希望从敏捷得到什么，如果对要解决的问题都不清楚，那么努力的效果就会大打折扣或无功而返。“别的公司或别的项目那样做”并不足以成为自己采用的理由。所以敏捷转型必须紧盯自己的问题，弄清楚为什么希望做出改变，进而再启动敏捷转型。

2.3组织结构与角色和敏捷不相容

敏捷宣言提到“最好的架构、需求和设计出自于自组织的团队”。在传统软件企业中需求分析、编码开发和测试常常分属不同的行政部门，这样的组织架构容易阻碍自组织团队建立，让敏捷团队的成员感觉仅仅能够做局部优化。

2.4指导不足

敏捷转型过程中，需要向团队成员讲述敏捷的思想和方法，过少的培训甚至没有培训，将让团队感到迷茫。在实践过程中，还会存在很多疑问或误区，还需要有经验的敏捷教练现场一对一指导。

2.5将敏捷等价为Scrum

敏捷的范畴比Scrum要大得多。Scrum本身并不涉及工程卓越、业务目标、大型团队扩展或者技术发展等。在转型过程中，需要从改善工程实践入手。否则，团队初期的Scrum的活动显得很热闹，但因为代码问题迟迟无法解决，质量和效率没有得到根本的改善，发布过程依然痛苦。

2.6对工程实践缺乏足够认识

工程实践对于解决代码问题具有直接的帮助，但每一种工程实践都有其门槛，需要付出学习成本才能掌握。不加选择的实施，将会带给团队难以承受的压力，而导致成员的抵制。这些问题都会导致敏捷转型的失败。而失败又会带来连锁反应，一方面让转型的软件开发团队大大降低对敏捷的热情和信心；另一方面，也会给其他周边的团队带来负面影响，使其充满疑虑、裹足不前。

3敏捷转型策略

针对敏捷转型的反模式，就可以有针对性地制定转型策略。

3.1宽松环境

敏捷转型是在项目交付过程中实施的，团队成员需要付出额外的工作和努力。改进活动需要时间、资金、办公环境的支持，甚至改进过程中会遇到挫折和失败。团队的管理层对此有清晰的认识，保持关注、积极支持、容忍失败，建立一种宽松的转型氛围。

3.2转型小组

敏捷教练通常对于敏捷价值观有深刻的理解，对敏捷管理实践或技术实践有非常好的掌握，并且具备一定的沟通和引导技能。这种角色对于传统团队的转型是非常关键的，起到引导实践、转变思想的作用。在传统团队内部通常难以独立培养敏捷教练，需要从外部引入，帮助团队转型。以教练为核心加上团队内部骨干建立转型小组，可以帮助转型工作顺利开展。

3.3痛点驱动

传统团队在研发过程中通常受制于自身的能力和外部的压力，遇到各种问题。常见的问题包括：（1）维护代码规模大，遗留故障多，团队陷于质量的焦油坑；（2）用户需求多、变化快，驱使团队过于追求进度，却无法充分理解用户需求；（3）分工壁垒严重，开发人员和测试人员之间对抗造成大量浪费活动；（4）团队成员技能提升缓慢，加班过多，士气低落。转型小组一起分析团队现有问题，再与团队成员开诚布公地探讨，通常会得到强烈的共鸣。不以引入新概念、新模式为目的，而以痛点驱动的态度面对问题，敏捷开发的起步就容易得到支持。

3.4实践选择

经过多年的业界探讨和尝试，敏捷方法论层面Scrum，XP和精益看板得到了广泛认同。但即使这样，从这几个方法论里面挑选合适的敏捷实践仍然不是件容易的事情，先做什么后做什么同样也是难以抉择的事情。盲目的实施实践只会加重团队的负担，而难以获得期望的效果，并将开发团队陷于交付和改进的双重压力中。而转型的初衷是在短期内付出可以接受的学习成本，提升过程能力从而获得长期的交付能力提升，因此，短期内的改进必须要获得可见的成果。通过多个项目的探索和实践，总结出敏捷转型初期的3个关键实践：Scrum、用户故事、持续集成。从管理、价值、交付3个关键方面可以帮助团队在短期内以较小的成本奠定敏捷开发的模式的基础，并可以在此基础上持续自我提升。Scrum是一种轻量化的敏捷软件开发管理框架，每隔1~4周，每个人都能看到能实际工作的软件，并且据此决定是发布这个版本还是继续开发以加强其功能，这样将原先的长周期的开发过程切割成若干个小段，用户反馈速度大大提升。有了轻量化的管理框架，团队的基本的工作模式、协作方式就会发生明显变化。用户故事（UserStory，US）是从用户的角度来描述用户渴望得到的功能，能把一个功能像讲故事一样叙述出来，不仅描述了产品需求、业务价值，同时还包含了一系列验收标准。一个好的用户故事包括3个要素：（1）角色，谁要使用这个功能；（2）活动，需要完成什么样的功能；（3）商业价值，为什么需要这个功能，这个功能带来什么样的价值。通过使用用户故事，可以增进开发人员与业务人员的沟通，帮助开发人员充分理解需求含义，并确保每个迭代都能关注用户期望的高优先级需求。没有用户故事就难以有真正意义上的迭代，也无法做到敏捷开发所倡导的快速反馈、快速学习和快速价值交付。持续集成是极限编程里面的重要实践。采用完全的自动化构建过程，使得一个开发团队在一天中多次构建并测试软件。持续集成鼓励软件开发项目团队在一天内多次提交代码，同时保证每次签入操作都不会损害已经通过的构建。这样做的目的就是为了快速反馈，使得缺陷及早被发现，并能以可视化手段快速反馈。有了持续集成作为质量安全网，团队的缺陷可以快速反馈和解决，作为工作产品的软件版本就可以一直保持在可工作状态。

3.5敏捷培训

要让团队正确实施敏捷实践，转型小组需要实施多层次多类型的培训。给团队的敏捷培训可以分为3个类型：（1）敏捷价值观的导入培训，向所有团队成员解释敏捷从哪里来的，它是什么、不是什么，与传统软件开发的异同点及其背后的原理，这样可以让团队成员能够在理论层面理解敏捷；（2）敏捷实践方法的培训，有针对性地向各角色介绍敏捷实践方法的要领；（3）本地化敏捷管理要求的培训，即为了使敏捷方法在团队落地而制定的各种管理要求，需要宣贯给团队成员，例如Scrum的活动计划和执行要求、用户故事书写规范、持续集成纪律等。通过一系列培训及时准确地传递敏捷的思路与各种要求，促进团队建立共识，提升实践能力。

3.6迭代改进

敏捷转型不是一蹴而就的，转型小组的改进工作需要按照敏捷开发的模式迭代前行。每个阶段制定切实可行的目标、范围和计划，定期组织回顾总结。通过透明化的成果展示获得管理层支持，及时发现风险改进工作安排，保证转型工作始终在平稳和可控的轨道上。

4结语

敏捷开发是一系列轻量级方法论的集合，具有共同的价值观。敏捷转型行为是由策划的敏捷方法引入到传统开发团队中，合理应用可以显著提升团队交付的效率、质量及个人能力。敏捷多种方法论及其实践都有其特点和学习成本，这就给敏捷转型带来了诸多风险和难点。本文在大量实践的基础上，针对转型中的反模式，提出了系统化的敏捷转型策略以帮助传统团队成功转型。需要注意的是，短期的敏捷转型任务完后，转型小组中应该能培养出内部教练，以便有能力引入更多的方法实践，帮助团队向更卓越的目标前行，而团队需要保持敏捷的意识和习惯，形成持续改进的良性循环。