Scrum在民航IT研发应用实践

◆李圣霞 刘盼 夏侯康 罗军 程宇

（广东机场白云信息科技有限公司 广东 510470）

1 研究背景

随着社会的进步和管理水平的日益提高，软件开发与各个行业和领域都密不可分，民航单位作为运输行业的一大重点，日常运营管理越来越精细化，对信息化的程度要求越来越高。第一，用户迫切需要信息化的管理软件，来帮助自己梳理和记录日常业务流程，提高自身管理水平；第二，用户对软件不熟悉，对系统的需求是模糊的、不明确的，只有在软件研发的过程中，才能逐渐明确下一步的需求计划；第三，因为民航业务的特殊性，对安全和质量的要求很高，软件系统的质量问题，对日常业务影响较大，且一般影响范围较广。

在这种情况下，传统的瀑布模型已经无法适应不断变动的需求，因为需求变更在瀑布开发模型中，尤其是开发后期带来的成本是高昂的，不确定的需求也会导致开发过程中工期、成本、质量的多重风险，并最终导致项目的失败。

2 敏捷及Scrum简介

敏捷是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。敏捷软件开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。

敏捷开发遵循十二条基本原则，如下：

第一，我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。

第二，欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

第三，经常地交付可工作的软件，相隔几个星期或一两个月，倾向于采取较短的周期。

第四，业务人员和开发人员必须相互合作，项目中的每一天都不例外。

第五，激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

第六，不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

第七，可工作的软件是进度的首要度量标准。

第八，敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

第九，坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

第十，以简洁为本，它是极力减少不必要工作量的艺术。

第十一，最好的架构、需求和设计出自自组织团队。

第十二，团队定期地反思如何能提高成效，并依此调整自身的行为表现。

Scrum是敏捷开发的一种最基本框架，也是最流行的一种框架，尤其是对于初次进行敏捷开发的企业尤其适用。Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。传统的“接力式”的开发模式已经不能满足快速灵活的市场需求，而整体或“橄榄球式”的方法——团队作为一个整体前进，在团队的内部传球并保持前进，这也许可以更好地满足当前激烈的市场竞争。

Scrum框架包括3个角色（Product Owner、Scrum Master、开发团队）、3个工件（Product Backlog、Sprint Backlog、产品增量）、5个事件（Sprint、Sprint计划会议、“每日站会”、Sprint评审会议、Sprint回顾会议）、5个价值（承诺、专注、开放、尊重、勇气）。

3 Scrum应用实践中的问题和解决方案

在民航系统管理软件的开发过程中，采用传统瀑布模型，因为客户需求的不确定性、各单位部门之间沟通协调的复杂性、对接其他系统数据的困难性等各种因素，往往前期需求调研阶段特别长，因为工期紧张容易造成延期问题，并带来质量的隐患，容易导致客户满意度的降低。

采用敏捷开发方法中的Scrum，可以有效地解决以上问题，把客户需要的大的功能划分为一个一个小的迭代，采用增量发布的方式，每次只需要确认当前迭代的功能，使客户需求渐进明细，目前已成为我们研发的主要模式。

Scrum主要有5个事件：Sprint、Sprint计划会议、“每日站会”、Sprint评审会议、Sprint回顾会议。下面分别一一讲述：

（1）Sprint：每个Sprint就是一个迭代，按照敏捷开发原则是迭代周期越短越好，因为这样可以使客户更早看到系统并进行试用，也能更早反馈意见。但鉴于民航管理系统的复杂性，太小的功能点完成对客户来说是没有意义的，机场是7*24小时在运转的，客户因为其自身业务工作的繁忙，也很难进行深入的试用，因此，迭代周期太短，无法取得预期的效果，而迭代周期太长，则无法按照敏捷开发模式推进，经综合评估，我们确立了1个月的迭代周期长度，9人的开发团队，基本可以完成80人天左右的开发工作量，预留测试和修复bug时间。经过近三个迭代的实践，目前这是比较合适的一个工作安排。

（2）Sprint计划会议：计划会议主要用来确定本次迭代要完成的功能，产品经理在前一个迭代开发过程中，就开始与客户沟通确认下一迭代的功能，因此，在计划会议上，产品经理确认好本次迭代的功能点，做详细地介绍，每个迭代的计划会议时间盒为8小时，产品经理按功能点对客户业务需求和需求实现方式进行详细地讲解，开发团队一起进行讨论，对需求错误点和遗漏点直接指出，每个功能点讲解完成后，立即进行开发任务分配，由开发工程师，利用敏捷估算扑克，对详细功能点进行估算。传统模式下，开发工程师在需求评审时基本不提意见，开发过程中经常按照自己的理解去开发，到测试环节后才发现实现与需求不符；而敏捷开发模式当场估算的方式，无形中让开发工程师尽可能地去了解需求，及时提出可能遇到的问题，给出相对准确的估算，这也是Scrum核心价值观中的“承诺”。

（3）“每日站会”：“每日站会”是Scrum的经典应用，体现核心价值观中的“开放”。“每日站会”我们采用最简单的手工看板+便利贴，把开发、测试任务细化到个人，每人有一行来标识自己的任务和进度，每日约定9点10分为站会的时间，到时间点大家自动在看板前聚集成半圆，不用每日通知，也不用安排专人召集，按顺序发言，回答三个问题：1）昨天我做了哪些工作；2）今日我打算做什么工作；3）遇到的困难和障碍。全部完成后，大家散开回去开始今天的工作，敏捷教练记录下所有的困难和障碍，和对应成员讨论并解决。一方面，“每日站会”提供了一个沟通交流的平台，让大家有机会了解团队整体的工作进展，一个系统内部总是互相关联的，对整体的把握有助于对部分的设计完善；另一方面，“每日站会”从心理学角度分析，虽然敏捷团队更注重整体的进度，但每日汇报进度时，个体总是会想要展示自己更好的一面，从其他人赞赏的眼光中，获得一种满足感，因此，敏捷开发团队无形中会有更高的工作热情，以在每日的站会中有更好的表现，这便是核心价值观中的“尊重”。

（4）Sprint评审会议：每个Sprint，我们仍然保留瀑布模型中的重要环节，召开几次评审会议：需求评审、设计评审、代码评审、发布评审，需求评审一般在计划会议之后召开，设计评审，则在设计完成后进行，代码评审每周进行一次，发布评审则在每次迭代功能测试完成时进行。需求、设计、发布评审一般是会议形式，代码评审则一般在工位电脑前进行，不必拘泥于何种形式，有问题也不必拘泥在什么时间提出，一般在发现问题时，我们鼓励立即提出，不让可能的缺陷或问题流入下一个环节，这也是精益思想的一种体现。一旦发现问题变成一种鼓励，每个人都感觉到提出问题是安全的，团队中的每个人都会放下戒心，更多的问题被提出，才能被尽早解决，而越早解决问题，越能减少修复问题的成本，也越能带来产品质量的提升，这是Scrum核心价值观中的“勇气”的体现。

（5）Sprint回顾会议：每次迭代结束后，在发布评审会议后，我们会立即召开回顾会议。回顾会议在各种参考书籍中有很多推荐形式，但核心思想就是要让团队全员都参与进来。敏捷团队中犯错误是被允许的，一般不会在回顾会议上对犯错误的人或事进行批斗，但必须要做的事情是，我们哪些地方做得不好，我们可以做什么来避免错误的再次发生。这些要采取的行动，就变为下一迭代的改进任务，和其他任务一起粘贴在白板上。做这些事情的，不是上级领导，不是敏捷教练，而是开发团队中的每个人，一般来说，让大家说的效果没有写下来的效果更好，我们经常制定5分钟的时间盒，让大家去思考，并把问题或者改进措施写下来，完成后再一起进行讨论，也尝试过大家坐在一个会议室里面轮流发言，首先发言的过程中很容易被打断，再就是可能前面的人说过的问题，后面的人觉得差不多就不会再提了。

最后，再谈谈Scrum核心价值观中的“专注”，专注是指让团队成员尽可能地不受外界干扰，把全部精力都投入到目前的工作中。现实的工作中，绝对的不受干扰是不存在的，比如一个开发工程师，正在进行A项目的开发工作，此时，正好有一个之前参与的B项目，客户有一些疑问，几分钟时间可以解答的问题，难道一定要推开吗，从公司的角度来看，一定不会希望产生这样的情况，从敏捷团队角度，这样的打扰太多，也会造成一定的困扰。因此，敏捷教练在其中要起一定的作用，把握好度，既不能牺牲客户的满意度，也不能影响当前的工作。

4 结束语

综上，Scrum在提升效率、提高质量方面为我们的研发工作做出了积极的贡献，在使用过程中，我们严格遵守它的核心价值观，遵循敏捷的十二条基本原则，但并没有拘泥于固有的形式，和原有的瀑布模型也进行了一定的整合，在一些项目应用上取得成效之后，后续也将应用到其他民航IT研发项目中。