“春天工程”项目组是应用开发二部最早采用敏捷模式的项目组，项目组在项目推进过程中使用Scrum框架，结合“看板+站会”形式，积极探索项目推进新措施。结合TFS工具逐步实现了电子工具与物理看板的有机融合，并在过程管理、版本管理、交付质量三大方面取得了突破。
物理看板作为“春天工程”项目组日常管理的核心工具，实现了从“影响地图”出发的需求研制与分析，利用“用户故事地图”将需求拆分成用户故事及任务，以两周一迭代的频度交付产品。
截至目前，项目组已完成15轮迭代。“春天工程”团队依据自身特点，逐步摸索形成更加合理的团队组织结构，并明确了Scrum 主管、产品负责人（PO）、产品设计负责人、开发团队负责人（TL）等角色的职责定义。
敏捷宣言中有这样一句话：“个体和互动高于流程和工具”。物理看板有助于团队的互动和协作，有助于褒优贬劣，营造竞争氛围。将物理看板置于工作区内，所有人高度可见，以清晰把控和推进工作进度。尤其在试点初期，项目组基于项目具体情况，对看板系统作出变化调整。项目组在敏捷试点中深刻体会到物理看板的强大优势。
为进一步节约人力成本，沉淀历史数据，项目组不断摸索，结合TFS工具提供的强大功能，逐步实现了电子工具与物理看板的有机融合，在工作项、拉入请求、部署工作流等方面持续研究实践，最终通过七项措施，在过程管理、版本管理、交付质量三大方面取得了新的突破。
成果一：TFS工作项与物理看板相结合，使过程管理变得更加容易
物理看板具有易于实施、直观灵活、沟通快捷等特点，但也存在一些不便：
1.从物理看板上无法清晰看到用户故事与实施任务的层级对应关系
2.已完成的需求和故事归档后，在需要复盘时查找起来比较费时
3.过程数据的收集比较困难，需要人工整理便签并手动归档
4.每轮迭代交付版本时，代码与故事的对应关系不够清晰
为了改进上述问题，充分发挥物理看板的优势，项目组启用了TFS工作项来管理需求和用户故事，在需求、用户故事和代码间建立了清晰的关联，过程数据的收集也变得更加容易。
措施一：通过TFS工作项管理需求和用户故事
使用TFS工作项管理需求和用户故事后，在积压工作中，可以清晰的展现需求与故事的对应关系。通过累积流图，可以清晰的统计出需求与故事的交付情况，便于及时发现问题，精准把控迭代进度。
每日站会时，PO会根据物理看板上需求和故事的完成情况，拖动电子看板上对应工作项，及时更新工作项状态。PO只需在TFS中建立简单的查询，迭代评审回顾会时便可及时统计出迭代故事的完成情况，无需再进行人工统计。
需要对用户故事复盘时，可以直接按迭代序号，查找出要复盘的需求和故事，操作简单、且清晰明了。
措施二：通过TFS工作项实现代码关联
通过TFS工作项维护需求和用户故事以后，开发人员只需输入工作项ID选择关联工作项，便可实现用户故事和代码的关联。在构建程序版本进行分支合并时，也能够清晰地知道本次提交的代码实现了哪些需求及用户故事。
成果二：使用代码库和拉取请求，让版本管理变的清晰有效
项目组前期使用git库进行代码管理，遇到以下瓶颈：
1.因项目包含的模块众多，开发过程中测试版本的匹配相对模糊
2.多人开发的情况下，缺乏便捷的代码评审机制，评审后难以追溯代码的修改情况
为了解决上述瓶颈，项目组做了以下实践。
措施三：通过代码库拆分，实现代码隔离
项目组按模块对代码库进行了拆分，将原来的一个git库拆分为17个独立的git库，实现了不同模块代码的隔离，便于各模块独立更新代码，易于版本匹配。同时，基于Master分支分离出测试分支，实现开发、测试、投产代码的全隔离。
措施四：设置TFS分支策略，保证代码评审简单有效
项目组在dev与rel，rel与Master分支间分别设置TFS拉取请求，在迭代中使用拉取请求的diff功能进行代码评审。代码经过评审并完成集成测试后合并至rel测试分支，进而完成部署版本的构建。
以dev分支为例，当开发人员提交本地代码至dev分支时，在拉入请求中可以清晰的看到上次合并以来所有的分支提交情况。同时，拉取请求还为代码评审工作提供了清晰的对比界面，在界面中评审人员可以直接在代码中添加评审意见，并设置意见的状态。代码的作者或其他评审人员可以直接对意见进行回复。程序作者可以根据实际情况把评审问题的状态置为“已解决”、“不是问题”、“已关闭”等。
结合TFS分支策略，强制要求代码经过评审且审阅者批准后才能完成拉取请求，进行分支合并操作，保证了代码的质量。
措施五：建立BUG分支，通过拉取请求实现问题修复
在测试过程中遇到问题时，项目组会基于测试分支（rel分支）新建一个BUG分支，BUG修复完成后提交至测试分支时创建一个拉取请求，通过拉取请求将修复后的代码提交至REL分支。代码归并至rel分支后，通过diff将完成修复的代码回退至dev分支，保证各环境代码版本的准确无误。
成果三：利用TFS部署工作流，提高交付质量和频率
在部署过程中，项目组陆续发现了以下不便：
1、开发、测试和投产代码构建缺乏隔离机制，可能会将开发中未经测试的代码带入生成分支；
2、项目组前期采用的是IDE手动构建WAR包，部署三个模块耗时较多，影响项目组的开发效率。
措施六：先隔离再归并，持续集成，实现部署过程自动化
为优化部署流程，项目各模块在自己的git库中通过拉取请求将迭代完成的代码匹配成正确的版本，归并至rel分支，同时触发自动构建和自动部署，持续集成，保证了发布版本的正确性。部署过程自动化，释放了人力成本，保证了版本正确，提高了部署效率。
措施七：利用仪表盘功能，便于查看每日构建及部署完成情况
项目组rel分支自动构建和部署的基础上，对dev分支配置了每日构建和部署，并在项目首页添加了构建情况一览，可以清晰的看到每日构建的完成情况。
总结
通过上述七项措施，春天工程项目组实现了需求和用户故事的的电子化跟踪，结合物理看板的使用，项目进度有了清晰的把控，度量数据的收集变得更加容易。通过代码库的拆分、需求及故事同代码的关联、TFS拉取请求及分支策略的运用，项目组建立了代码版本管理机制。通过自动构建及部署流水线的运用，提高了团队的持续集成和交付能力。
项目管理办公室与应用开发二部密切协作，持续深化产品经理思维，努力实现任务驱动型团队向自组织团队转变。目前应用开发二部敏捷试点项目已推广至8个，每个项目根据自身特点，增加电子看板试点，结合影响地图、用户故事地图、TFS、AXURE等一系列方法和工具，不断探索改进，团队分工更加明确，组织结构更加合理，研发效率稳步提升。
我们将会继续探索实践，坚持总结分享，希望所有试点团队能够少走弯路，尽快找到适合自己的敏捷模式。
