背景

当前，敏捷已经成为了2018的热词，执行敏捷研发模式的项目多数都是从瀑布模型转型过来的，瀑布模型是一套根深蒂固的传统流程，如果硬着陆的话，很容易折翼。笔者在各类项目敏捷实施过程中，总结了一些接地气、可操作的经验，思考如何让敏捷软着陆，给大家提供参考。

作者：付云攀 陈炯 赵亚莉

中国农业银行软件开发中心

因地制宜

纵观目前正在实施的敏捷实践，成功案例有一个共同的特点，就是“因地制宜”。敏捷实践有很多种，看板站会、持续集成、单一主干、测试前移、影响地图、测试驱动、结对编程、Scrum、故事地图等等，在敏捷的实施中没有所谓的最佳实践，只有更合适，更有效的实践。团队在透彻理解敏捷理念的基础上，能够结合自己的项目情况灵活应用敏捷，才是真正的敏捷。

案例一：A项目已成功引入业务人员参与，打通了敏捷的前端，达到从市场需求到研发过程的“业技融合”的状态。

案例二：B项目与测试部门合作，将测试环节前移，用TDD优化代码设计，提高代码可测试性，同时“测研结对”促进交付速率的提升。

案例三：C项目需求分批次下达，团队上下对Scrum敏捷框架有一致的见解，项目在开发侧开展Scrum实践，推进项目追求卓越的技术、良好的设计、高效的沟通。

案例四：D项目建设的系统需求稳定，属于核心类系统，使用传统瀑布式研发方法相当顺畅，应遵从实际继续沿用传统模式，可借鉴敏捷思想中的看板、站会等管理实践，促进沟通与协作。

问题驱动

敏捷并不是万能的，不能听说别人用了敏捷之后，效率提高了百分之多少，成本降低了百分之几等等，就盲目地去追赶这股“敏捷风”。

不同的业务条线，项目情况各异，还是应该由问题驱动、对症下药，先收集当前的研发模式有哪些问题，分析一下，到底是人的问题、技术的问题、还是流程的问题，如果真的是流程问题，那就再看，是需要全盘替换，还是仅仅吸取敏捷里的若干特色工具或方法即可。举两个案例。

案例一：某系统在建设过程中，项目经理面临项目规模大、项目进度把控难、团队沟通不顺畅的问题。如果项目全盘引入Scrum的全套流程，前期就需要投入大成本在学习和磨合上，同时交付也会下降，这是项目团队无法容忍的结果。项目组从最迫切的沟通问题出发，先期引入了Scrum的“看板”和“每日站会”，让整个项目进度变得直观透明，同时让沟通更及时快捷，其他流程保持不动，这种对于项目组成员来说，学习成本最低，基本不会影响交付。项目组在实施一段时间后，反馈的确解决了他们的实际问题。

案例二：项目人员技能参差不齐，初级人员总是成为交付的瓶颈，项目组希望引入敏捷来提升交付速度。首先，项目组对敏捷的概念认识是有误区的，敏捷≠快速交付，它强调对需求的快速响应能力，敏捷不是一颗灵丹妙药，吃了就可以日行八百里。其次，敏捷团队，强调的是自组织，自管理，对每个人的要求都相对较高，但是从实际角度出发，不可能每个敏捷团队的人员配比都是高级人员，所以建议在初期组建时，以老带新，慢慢来，通过若干个迭代的打磨和成长，让整个团队都能达到自组织和自管理的“理想”状态。

所以敏捷的引入，一定要切合实际要解决什么问题，而不要为了敏捷而敏捷。

基本要求

来点实在的，笔者不得不说一些基本的硬件要求，那就是首先要有一块板子。哈哈，不开玩笑，说的是真的，下面的几点搭建了最基础的着陆跑道，为着手尝试敏捷的项目提供参考：

1.  看板一开始最好是物理看板，不需要追求漂亮完整，只追求简单。

2.  物理看板的话，需要白板纸、木纹胶带、各种颜色和形状的便签。

3.  指定专人关注看板改进，把握三个核心：可视化价值流、显示化流程规则、控制在制品数量。

4.  改进看板，改进不一定是成功的，但是提出改进是职责。思考流程是否顺畅，内容是否上板。

5.  建立每日站会习惯，每天固定时间固定地点，设立奖惩制度推进每日站会，促进团队沟通协调，及时暴露问题。

6. 所有要求和规则显示化。

7. 三个角色，Scrum Master（SM）、Product Owner（PO）、Team。SM需要有较高的软技能，对技术要求不高。可以由有能力、熟知Scrum人轮流担任。PO对技术要求比较强，熟知需求，负责产品价值最大化。Team包括团队中的设计、实现、管理人员，负责实现产品需求。

敏捷源于多种实践方法，大家都在不断的尝试、实践、发展敏捷研发方法和技术，并引入工具探索实践。综上，在团队对敏捷思想达成共识，“因地制宜”制定适合自己的敏捷实施策略，从“问题驱动”来思考敏捷切入点，同时建立敏捷实施的基本规则，后续根据每个迭代总结回顾，优化流程，践行Scrum的核心理念：持续改进。

原文地址: https://mp.weixin.qq.com/s/wMM09-ECSLnxHRQD9NhdHA

---

.NET社区新闻，深度好文，欢迎访问公众号文章汇总 http://www.csharpkit.com