需求分析：SEAi需求分析法（用户故事拆分），需求实例化

估算计划：敏捷功能点与故事点估算，QAP量化敏捷计划

日常跟踪：每日例会，看板，DevOpsBan

技术管理：QAC量化敏捷编码/重构，QAT量化敏捷测试，DevOps流水线

敏捷度量：QAM量化敏捷度量

扩展模块：Scrum进阶，敏捷教练进阶，SAFe规模化敏捷框架，用QAD实现CMMI4/5

课程特色与思路 

传统敏捷开发培训课程一直存在以下问题：

1. 不同角色分别上课，难以形成企业级敏捷框架
项目管理者学习Scrum和看板，研发人员学习DDD、微服务、重构、编码规范，测试人员学习自动化测试，教练学习教练技术……

2. 体系互不兼容，重复工作量大
Scrum中的backlogitem和看板纸片是不是一个东西？DDD的分析结果可以用来当用户故事吗？史诗故事和用户故事变成了代码中的什么？给定20个用户故事应该写多少测试用例？又应该测试出多少缺陷？

3. 学习成本高昂
上述课程每个都按2天计算，需要数十天的学习成本

QAD量化敏捷开发的思路则是：

所有团队角色参加一个培训，使用各自团队的实际产品做贯穿练习
沿着以下脉络，每个团队使用同一个产品的需求贯穿始终，依次学习和练习以下内容（下划线后的数字是练习个数[1]）：
（产品线）需求拆分3
＞（管理线）>整体规模估算1>用户故事地图1 ＞ MVP规划1 ＞ 迭代计划1>DevOps看板1

＞ Scrum的四个会议 ＞ 敏捷度量1＞ 敏捷成熟度评估1
＞（技术线）微服务划分1 ＞ 从需求到代码 ＞ 从需求到测试用例1

1.  前后步骤衔接，概念复用，使得跨角色的工作互相支撑，减少重复劳动
（产品线）需求拆分为四层（S场景，E实体代替史诗故事，A行为代替用户故事，i需求实例）
＞（管理线）>E实体用于整体规模估算1
>SEA三层自动转换为用户故事地图的三层结构＞ 并用于划分MVP
＞ 使用A行为进行迭代计划>A行为作为DevOps看板上的纸片
>每个A行为=5.4FP（功能点）进行敏捷度量＞ 基于功能点的6个核心指标完成敏捷成熟度评估
＞（技术线）微服务划分为三类：场景微服务，实体微服务，行为微服务
＞ 编码时，E实体=数据库表/实体类/Controller，A行为=接口或页面
>测试时，一个i需求实例=1测试用例

2.  同时降低学习和工作成本
2天讲完练完20天课程 ≈ 2天干完20天实际工作

课程范围 

QAD量化敏捷开发是一系列课程/咨询的集合，整个体系前后连贯，覆盖需求、管理、技术的各方各面，建议核心人员完整参加。

课程对象 

以下角色可以在QAD系列课程中受益（因参与人员职务、比例的差异，可以定向定制课程内容）：

产品经理：

● 以SEAi需求分析法拆分用户故事为主

● 包括从自然语言的简单需求描述，转变为场景、实体、行为、实例，并最终形成MVP，使用DevOpsBan进行管理；用需求实例化产生验收测试用例

● 核心收益：需求条目的量化，能满足横向、纵向对比

项目经理：

● 以QAD管理流程（QAP量化敏捷计划，快速估算，DevOpsBan，QAM量化敏捷度量）为主

● 包括需求条目化，用户故事地图，整体计划，迭代计划，每日立会，DevOpsBan看板，全程量化管理

● 核心收益：仅基于需求条目数，就能完成工作量、工期、成本、代码行数、测试用例数、测试缺陷数、发布缺陷数估算

开发经理/开发骨干：

● 以QAC量化敏捷编码为主

● 包括理解SEAi需求条目与代码的对应关系，控制代码量以提升可维护性

● 核心收益：能利用编码消耗率LLOC/FP来整体把控编码的简洁性水平

测试经理：

● 以QAT量化敏捷测试为主

● 包括测试驱动开发，自动化测试，持续集成，持续发布（含少量版本管理）的计划、跟踪等管理活动

● 核心收益：能利用功能点，合理评价产品的质量；能利用功能点测试密度的概念，评价测试本身的工作完成情况

敏捷教练：

● 以理解和推动完整量化敏捷开发流程为主

● 包括跟踪团队实战并深入理解敏捷开发的完整步骤和具体做法，敏捷转型中的主要困难，如何度量敏捷团队的绩效，以及评价转型的成功与否

● 敏捷教练的软技能部分另有《06-2-09-02 高级敏捷教练培训课程（主推★★★★★）》课程覆盖

   《高级教练》课程授课对象是敏捷教练，主要以团队建设、自组织团队原理、敏捷转型规划、绩效管理、团队不同角色的职业生涯规划等为主，甚至会涉及到相关的心理学、经济学内容。

典型应用场景  

QAD量化敏捷开发可用于多种不同的场景，例如：

1. 替代Scrum（2001年）、看板（2005年）作为敏捷开发导入培训

2. 大型企业进行多团队的敏捷转型（150+研发人员，20+研发团队）

3. 大型新开发项目或重构项目的全程管理、监理（50+研发人员，50万+行代码）

4. 敏捷转型 +CMMI/GJB5000A的4~5级（量化管理、持续优化）

课程大纲 

以下是最常见的2天课程的简要大纲正常授课6小时/天，第一天7小时，第二天5小时

● 学员按实际项目分组，每个组必须有一个产品经理，以提供一个实际产品需求

●  以组为单位，以实际产品需求（最佳选择是正在开发中的需求和马上要开发的需求）为练习目标

培训效果与实际项目数据

QAD系列课程的目标设计

    ● QAD系列课程的需求建模课程，可以仅通过短期课程培训达到远高于业界平均水平的效果。

    ● QAD系列课程的自动化测试目标设定数值极高，除了少数学员外，几乎不可能仅仅通过培训达到，需要辅以咨询。

    ● QAD系列课程关注实际应用的情况，而非培训效果本身，从而避免了培训课堂气氛热烈，实际工作中无法推广的情况。

QAD系列课程的验证项

    ● 课堂练习的验证

    ● 课间实战训练的验证

以下是QAD系列课程的量化效果：QAD只以量化指标评价研发水平，因此也只用量化指标来评价课程/咨询效果

需求建模与实际项目偏差

    ● 实际项目中，讲师建模结果与产品完成时偏差：约5%（建模34个页面，完成时实际36个页面）页面≈用例

    ● 课堂练习中，学员讲师偏差：约10~14%即讲师只发现10~14%的页面级元素存在问题，需要增加、修改、拆分等。2020年培训普遍偏差只有10%左右，部分学员可达到3%

需求建模速度

    ● 讲师大会分享中

        ○ 可在10~15分钟左右，对随机听众的随机需求（一般在6~12个月工作量）完成用例级建模

        ○ 分享30分钟可完成：建模，估算，用户故事地图，看板

    ● 课堂练习中

        ○ 学员可在约20分钟左右不包括分组、推选组长、选择产品的额外约5~10分钟时间，完成约100~240人天真实需求的场景、实体、行为建模

    ● 实际项目中

       ○ 讲师可在1小时内使用QUML完成4个人月需求的建模

       ○ 广州某学员在培训后10日内，耗时3天完成了960人天（约4人年）的需求建模，且对需求进行了额外的描述

       ○ 讲师带领两位熟悉需求的学员，耗时2.5小时左右，对已经完成的15人年项目 30人团队，15程序员，已开发6个月完成了需求逆向工程，重建了实体级别的需求模型，并与编码、工作量、测试用例、测试缺陷等数据对比后确认无误

编码/重构

    ● 课程培训中

        ○ 可在60分钟左右，对随机听众的随机需求进行编码，形成主观分100分级别的主框架，必要时包括自动化测试代码以展示代码运行情况

    ● 实际咨询中

        ○ 一天内将2000行代码重构为140行

        ○ 某客户定期讲述需求中的难点 经统计共12个，讲师为客户完成实际代码框架

        ○ 协助客户将25万行代码中的约14万行通过减半

        ○ 通过使用“编码整洁指数”，在9个月将11个团队的平均分从1.5提升到3.3分 满分5分

项目管理能力

    ● 实际项目中

        ○ 在完成两天导入培训后，经过3轮次迭代，4~10个团队能完成以下数据的填报：功能点数，功能点生产率，工期，测试用例密度，测试缺陷密度

        ○ 生产率P75-P25稳定性可达-20~+30%之间

        ○ 缺陷密度P75-P25稳定性可达-21~+68%之间

自动化测试能力

    ● 实际项目中

        ○ 讲师第一次在实际项目中使用Web自动化测试，就进行了Mars封装，约10个工作日完成了173个自动化测试用例，生产率约为15~20自动用例/测试人天，远高于实际需要数值（6）

        ○ 北京某学员仅学习1天，即在周末耗时1天，完成了粗略的零编码自动化测试框架

        ○ 北京某学员仅学习1天，即使用讲师的零编码策略，在约15工作日后完成其RobotFramework的改造，生产率高达24自动用例/测试人天，团队已有余力完成过去欠缺的测试用例

        ○ 北京某客户在8天自动化页面测试咨询后，2个测试人员1.5个月完成了1830测试用例的编写，生产率高达30自动用例/测试人天，并为MarsJava框架贡献了约1000行封装代码 此客户在此前曾经接受了14天的原始selenium培训，但无法实际使用