笔者最近刚刚交付了一场敏捷开发实战工作坊，在结束时，真实工作所需的新自动化测试用例在Jenkins新Job上运行通过，学员们实实在在地把学到的新技能用到了实际工作中。本文来记述下此颇有特色的培训。
概貌
•分析最近20年来敏捷DevOps各类方法的发展，呈现得到的最新理念和原则，融合Scrum和Kanban，以及DevOps。
•以需求分析-自动化测试两条主线来进行实战演练，并且结合持续集成
•目标：建立持续交付流水线
•试图解决的问题：
如何更加针对业务价值，如何更加快速高效的进行需求分析、计划、实施。
如何采用样例来表达需求，并且设置样例数据
如何利用样例数据来让需求运行起来-可运行的需求
如何利用测试来完善需求
大纲
敏捷概述
敏捷需求
实战：收集需求进入禅道
敏捷故事
实战：分解得到故事进入禅道，采用GWT或者事件流，以表格来记述故事
持续集成
实战：建立工作分支上的持续集成Job
实战：开发简单自动化测试用例，进入CI
敏捷DevOps开发
实战：对比测试驱动开发TDD，采用测试驱动调试(另外名字是替代调试的测试-DRT)方式添加自动化测试用例
行为驱动开发
实战：采用BDD开发自动化测试，以Excel为测试数据提供工具
敏捷度量
该工作坊实战要点
敏捷需求
要点：准确捕捉用户的声音，比较选择更有价值的需求，采用简明扼要的语言记录需求标题和说明，这标题和说明最好能够用到发布说明(release notes)当中。
工作坊现场发现：产品经理利用原型图表达需求，但是没有提炼需求进行条目化管理，当前无法统计需求数量，也难以追溯发布版本与需求的关系。
工作坊实战：提炼条目化需求进入到禅道
课后作业（即是改进建议）：把禅道的需求功能用起来，收集跟踪需求。
敏捷故事
要点：验收条件是故事关键细节的载体，验收条件带有样例数据。
工作坊现场发现：直接利用原型图进行开发，没有提炼故事进行条目化管理。
工作坊实战：提炼故事进入到禅道，再同步到Excel文件，存放到Git，成为自动化测试的数据输入。
课后作业（即是改进建议）：考虑到当前团队里面产品经理测试人员等，都具备Git技能，建议直接书写Excel文件，放入Git，暂时先不必在禅道当中记录故事。
持续集成
要点：质量内建，各种手段前移，核心动作有3：code review代码评审， code inspection代码扫描，automation test自动化测试
工作坊现场发现：已经开展了代码评审，约每周一次，直接在版本分支上进行，没有在Gitlab里面留下评审记录。SonarQube已经安装，正在接入Jenkins，自动化测试已经起步，每个模块都有几个样例，但没有大面积启用。
工作坊实战：在Jenkins里面设置CI Job，根据Git库变化自动触发，把既有全部测试用例要么忽略，要么跑起，让CI Job通过。对于工作坊修改代码，进行了代码展示评审。
课后作业（即是改进建议）：
1，利用SonarQube进行代码扫描，并且设置成有bug时，让CI失败，让SonarQube把关。
2，CI运行起来后，执行优先修复原则，甚至可以考虑安装物理指示灯，或者利用现成屏幕显示CI状态，要第1时间修复CI失败。
BDD
要点：这是产品开发测试三方（3位好朋友，3 Amigo）的工作交接面，利用Excel同时表达需求和样例数据（这方法称为ExcelBDD），示意图如下
让三方有地方进行精确的协同：
左侧（上图A列）采用自然语言以GWT范式/输入输出范式或者事件流范式表达需求，这部分是产品经理和开发人员都能书写，所有人都能理解
中间的参数（上图B列）提炼支持中文，结合左侧需求，提炼其中参数，对于开发人员而言，没有困难，其他人也能完全理解
右侧是数据区（上图C·G区域，可以向右扩展），第1组数据由产品经理或者开发人员设置，后面的数据扩展覆盖更多情景，可以归测试人员处理，采用业务分析下的黑盒等价类方法来设置样例数据，进而设计自动化测试用例，无需采用传统单元测试方法去剖析代码而设计测试用例。这样做法能够自然地达到80%以上的测试覆盖率，不比TDD达到的测试覆盖率低，而且这样的覆盖率都是针对业务场景的有效覆盖，不是机械覆盖。
经过自动化测试，该需求+样例数据是可以运行自检，并且无需启动整体应用，自动化测试耗时不多于1分钟。
工作坊现场发现：开发人员已经有开展用代码调试代码，但无法重复运行，也无法交给测试人员继续深化。
工作坊实战：把当前正在开发到需求用Excel表达出来，尤其是变化部分，有个实例如下：该需求是新增按某时间排序，在其输出部分就设置第1个记录是什么。样例数据从现成数据里面挑选，输入数据确定之后，根据新需求，就知道哪个记录是第一个，将其写入Excel输出数据区，然后书写测试，检验查询结果的第一个记录是否符合期望输出。
课后作业（即是改进建议）：
1，开展以上做法，争取每个新变化都得到自动化测试。
2，利用SonarQube观测测试覆盖率，经过前期运行，设立新代码测试覆盖率门槛，也就是说，新代码覆盖率如果不能达到门槛，那么让CI失败，也就是强迫新代码测试覆盖率达到一定数值。这是经过Google等大厂验证有效的做法。
小结
以上记录了本次实战工作坊的要点，回头看起来好像容易，但其实在工作坊之前没有机会看其具体代码工程，在实际工作当中开展新内容的实战工作坊是一个巨大的冒险。对应业界好多培训，并不结合到实际工作，而安排不少游戏，比如折纸飞机，这没有失败的风险，培训难度就小多了。
而结合实际工作的真正实战式培训，趣味性上肯定差些，但是给学员带去的可落地实施的内容就远远多于游戏式培训。
