本节课程为《研发工具链介绍》，我们将主要学习三个工具。项目管理工具—iCafe、代码管理工具—iCode、交付平台—iPipe。
此外我们知道，管理实践具有以下三个特点：①用“精益”指引产品规划；②用“敏捷”加速迭代开发；③用“数据”驱动持续改进。而本节课程学习的这三个工具，就是对管理实践三个特点的完美覆盖。
01 需求管理
需求管理是一个项目的基石。在互联网行业中，因为产品需求迭代快速这一特点，需求管理一直非常令人头疼。所以如何对需求进行更好的管理，更好的做出产品规划对互联网行业的项目来说是一个重要的问题。
传统的需求管理方法有以下几种：
①直接将需求写在文档上面，
②将需求制作成需求卡片，通过这样的方式让研发人员与需求人员保持信息的一致。
③使用Excel进行需求管理和排序。
这三种方法都存在很多的缺点，如撰写文档耗时长、文档编写需求较多人力、文档维护成本高、文档使用过程中沟通不畅等等。文字因为其阅读特性，不方便对任务进行直观的展现。所以在很多项目开发过程中，经常会出现文档交给研发人员后，开发出的产品与文档设计不一致的问题。
互联网的需求管理需要具有需求完整性、沟通高效性、表达准确性，沟通便捷性等特点。
研究表明，不同的沟通方式产生的沟通效果各有不同。在所有的沟通方式中，文档沟通是最低效的沟通方式，而面对面使用白板沟通是最高效的沟通方式。结合多种高效沟通方式，就产生了用户故事地图这种新颖的需求管理、排序的方式。
用户故事地图是敏捷项目管理中一种重要的管理方式。
首先使用卡片在白板上将所有的需求列出来，这样有助于展现产品全貌，而且将需求转化为可视的卡片能更好的根据用户反馈对任务需求进行排序；
然后使用不同的颜色对卡片进行分层。蓝色卡片是第一层，黄色卡片是第二层，白色卡片是第三层。将颗粒度最小的需求放在白色卡片这一层，低颗粒度的需求更容易被研发人员接受。
最后通过横向的分组，把迭代计划每一期的每一版本的需求进行归类分组。这样有利于打通产品视图和研发计划视图。
通过以上步骤可以得到一个较为完整的用户故事地图。
用户故事地图是一种非常高效需求管理方式，目前所有的研发团队都可以在效率云上不受物理条件限制的直接使用它进行需求管理和追踪。
02 迭代计划
在完成产品的版本规划后，研发团队需要制定相应的迭代计划。敏捷、快速、合理地迭代计划能够更高效地促进项目的迭代。
基于用户故事地图，可以在制定迭代计划的过程中中直接对需求进行上下拖拽修改优先级，左右拖拽更改计划。这样可以更清晰的展现迭代计划，使开发团队更好定位到的里程碑，完善整个迭代计划。
03 进度追踪
进度跟踪，有三大法宝，他们分别是：站会、卡片墙、燃尽图。
站会同卡片墙相结合，在站会过程中可以直接通过电子看板共享项目进度和项目问题，提升站会沟通效率。
通过燃尽图和统计数据，团队就能直接得知开发进度及遇到的问题。
04 持续改进
针对持续改进，我们提供了卡片状态时长散点图和卡片状态累积流图这两种工具。
卡片状态时长散点图能够精确展示团队工作速率，从需求提出到需求上线的单个周期时长和平均周期时长，精确的展示团队在每一个状态的工作速率及工作速率的变化。
卡片状态累积流图能够宏观展示项目各流程效率趋势，颜色的色块宽表示该流程积压的需求和任务比较多，色条变窄表明团队状态流动速率提高。
基于这两幅图工具，研发团队可以周期性地进行自检，对过去一段时间的工作进行自我审视，然后持续改进。
iCode是一个代码管理工具，围绕它我们主要讲解两个实践集：工作流和评审。
01 工作流
运转无序，开发混乱是困扰很多团队的一个问题，它严重影响产品的交付。典型的问题有：代码处理随意、bug重复发生、测试不完善、发布版本混乱等。
面对种种问题，我们同时支持两种标准的工作流，用来保障团队有序协作。
（1）基于主干的工作流
在基于主干的工作流中，整个团队维护一条主干分支。为了保证主干分支的质量，需要配套严格的准入机制，变更点在合入前需要经过机器、人工的双重评审，通过后才能合入主干。
需要发布的时候，会基于主干拉取发布分支，这个分支其实是主干特定点的快照，单纯用于发布，如果发布问题过程中发现问题，回到主干修复Bug或进行功能增强，必要时再将主干提交拣选到相应的发布分支上。
分支发布和主干并行不悖，不用担心开发中的功能被带到线上，发布完成后恢复到一条主干的简明模式。
基于主干的工作流优点有：
①主干质量高，随时可以发布。
②模型简单，只有一条主干，节省分支合并的成本。
但是该工作流也有一定的缺点。在开发高质量的工程项目时，团队需要建设完备的测试用例，在提交环节要求提交人保持原子提交，即功能和提交一一对应。
（2）基于分支的工作流
在基于分支的工作流中，主干用于存储线上代码，需要变更时，基于主干最新代码开分支完成功能的开发、测试和发布；分支发布前，需要先同步主干的更新；上线之后，需要将分支合并回主干。
基于分支的工作流的优点有：
①分支并行，独立开发，分支不会相互影响；
②对团队而言，使用门槛低，分支贯穿一个独立功能开发、测试、发布的整个过程，给予团队充分的时间完善测试用例及完成人工测试；
③容易上手，系统会引导开发人员完成新建分支、同步主干、合会主干等全部操作。
但是基于分支的工作流也存在一定的缺点，如：需要花费分支合并的成本、需要不断地同步主干，来发现分支的冲突风险点并提前解决。
02 评审
评审是保证团队工程质量的一个重要的过程。如果不经过评审直接提交代码，可能会污染代码历史，增加后期维护成本，严重时可能还会产生代码质量问题。
在项目开发过程中，可能会出现本地运行正常的代码，在测试环境或者线上环境突然崩溃的情况。针对这样的问题，可以使用质量防护网。质量防护网包括代码扫描、持续集成、人工评审三个层次。
代码扫描能够找出不符合代码规范的地方，在行间距中插入代码评论，同时出具一个风格报告，方便工程师对代码风格问题进行修改。
持续集成会配置一个云端构建，通过云端构建，快速探测出代码初期Bug，帮助开发人员提早修复。
在前两步做好后，团队的资深成员就可以就架构、逻辑、设计等问题进行深入评审。
通过这三步，实现了机器、人工双重评审，层层递进，确保团队的工程质量。
iPipe是一个交付平台，围绕它我们主要讲解三个实践集。
01 固化端到端的交付流程
标准的软件交付的过程包括以下几点：
首先会有一个明确的发布版本的输入，
然后基于这个发布版本，会进行代码提交。
代码提交之后会进行编译、测试。其中测试环节可能包含模块级的测试和系统级的测试。
最后进行发布。发布上线的过程可能会分为预上线、生产灰度、生产全量几个环节。
为了使代码变更流程标准化，需要使用交付流水线的方式来落地。通过标准化交付过程从而达到可靠、可重复的作用。交付流水线是串行执行的，上一个阶段成功执行后，就会触发下一个阶段。执行阶段由任务组成，这些任务可以是穿行的也可是并行的。任务的执行状态决定阶段执行状态。
iPipe这一工具目前包含了标准的交付流水线，用户可以在iPipe中看到流水线的构建情况。在使用交付流水线的过程中，如果当前阶段失败，后面的阶段就不会继续进行，这样可以节省资源并且快速的发现问题，及时修复问题。
02 插件化现有工具和服务
在交付流水线中执行各种任务时需要依赖很多工具和服务，比如maven，docker、jenkins、git等工具和服务。
我们通过一套标准的插件化开发规范将这些工具和服务集成到了流水线中，用户在使用流水线的过程中就可以很方便的使用这些插件和服务。如果流水线中没有想使用的插件、服务或工具，可以根据效率云提供的插件规范，自行扩展以满足项目需求。
03 数据度量驱动过程改进
通过交付流水线，可以快速获取项目所有的数据和信息，如：一个版本从代码提交到交付上线的周期或者一个项目各个阶段发现的缺陷数量等等。
用户可以通过调用API获取数据来进行数据的度量，从而推动交付过程的改进。在后续的发展中，平台会识别项目中关键的数据指标并且自动化的形成更加鲜明的数据报表。这样就可以持续的进行数据度量，给个人及团队提供一个维度丰富的平台。
