本敏捷规范是在现有正在运行的敏捷实践上的体系化，重点明确项目过程各阶段的动作细节，让整个团队的敏捷管理动作标准化，提升团队敏捷开发的能力.
笔记原文

第一、问题识别

当前敏捷管理重点关注的问题是：

  1. 信息对称问题
  2. 项目节奏的把控问题

在项目管理的各个阶段都要重点关注这两个问题，这也是很多过程动作设置的初衷。

第二、敏捷项目过程

一、需求及架构评审：

1.目的：

  1. 需求是否满足准入要求；
  2. 进行架构及关键技术方案的设计、把控；
  3. 项目团队组建

2.领域负责人划分：

智慧治理类：张三、里斯.
千人千面-任务引擎：张思、木刊.
考培：庞贝、姚策.
业务生成平台：甘泉、木刊.

3.动作清单：

  • 需求质量评审:
    核心规则是否完备;
    Axure 原型必要的交互是否进行了实现
  • 技术风险点，及对应的方案
  • 明确项目经理、项目组成员
  • 架构设计：组件图、实体图、前端架构设计；

4.其他说明：

  • 产品架构体系、技术难点的识别、协调处理，有该过程负责，不强调项目组的架构掌控能力；
  • 希望有更多的，有架构能力的团队加入的该过程。
  • 能力要求：熟悉对应产品、技术体系；有架构设计能力；能用 UML 进行架构描述；

二、项目启动会

参加人员：项目经理组织，项目全员参与；目的：明确项目相关信息及规则动作清单:
组织会议，明确项目相关信息;
微信确认，项目经理把相关信息按模板要求发布到项目官方群中，项目成员确认;

项目相关信息，按模板要求填写，初稿如下:
项目沟通微信群：二维码.
相关文档存放目录：xxxxxxxxxxxxxxxxxx.
项目周期时间 ：08 月 15 号 到 08 月 30 号.
项目组成员：AAA(产品经理)、BBBB(项目经理)，CCC(后端开发)、DDD(测试人员)….;
集成联调时间点：08 月 22 号（全天）介绍集成测试.
送测时间点：08 月 23 号（全天）.
发布时间点：08 月 30 号.
（可选）上下游对应关系：未华提供组织 xxxx 接口（08 月 17 号）；培伟提供 xxxx 接口（08 月 16 号）

项目规则:
发布日，全员共进退.
需求规则调整，第一更新规格文档；第二，发到微信群里每人确认。需求调整完，产品经理一定要再微信群里通知到全员，全员必须再群里回复收到；

按照模板填写内容，启动会上宣贯，会后发到项目微信群里，项目全员回复收到检查方式：项目结束提供项目启动的，基于模板任容的微信消息截图

三、需求评审

参加人员：项目全员参与；对应的业务架构团队；方式：产品经理讲需求；

四、业务架构讲解

参加人员：项目全员参与；对应的业务架构团队；方式：业务架构师介绍架构思路

五、需求反讲

参加人员：项目全员参加；备注：需求返讲，已经让团队对需求的理解达成了共识，测试用例返讲不作为必做动作。

六、模块设计

先做好接口设计前端:xxxxxxxxx
规范要求定义包括：接口命名，入参、返回值展现形式：必须以文档的方式，放入 TFS\SVN\GitLab;
维护：持续维护，接口变动，要更新文档，并通知到各方

七、站立会议

频次：每日必开；站立会议产品经理可以不参加动作清单：内容：协调，不断强调规则、项目节奏的时间点等；

备注：集成测试、送测、发布当天晨会一定要开：安排集成测试（开发自测）；要明确送测、发布的规则、明确这个节点项目全员一定要共进退；晨会下来一定通知到上下游的配合同事也都共进退；检查内容：项目结束，提供微信让大家开站立会议的消息截图项目总结里要有，对站立会议实践的经验、教训总结，要结合项目细节。

八、回顾会议

1-3 个迭代做一次；这个由部门级领导组织、或者推动由回顾负责人整理回顾总结

备注：公司级的，上线流程、规范不变

敏捷管理 7 原则

  1. 产品需求变化信息要对称
    1. （产品经理一定要更新需求规格文档，并通知到全员，确保全员已知、并回复确认。）
  2. 集成测试一定要专项去做
    1. （要单独留出至少半天的时间，上下游的团队也要通知到位），是说开发把最新版本发到测试环境（没有开发环境）上的自测、联调；
    2. 集成测试的输出：程序的部署包、数据库更新脚本等
  3. 打包发布要规范
    1. 服务端不能直接从开发环境打包更新生产和预上线，一定按开发环境打包，该包依次按顺序部署验证：照测试-》灰度-》生产
  4. 非功能性需求要关注
    1. 压测工作的安排
    2. 手机兼容性测试的安排
  5. 送测日、发布日整个团队共进退
  6. 协调好项目的上下游
    1. 接口！接口！！接口！！！
    2. 明确联调、送测、发布时间点
  7. 风险点有没有？

培训的目的：
1、人才梯队建设;
2、团队规模越大；规范越重要；团队内部要形成自己的技术、项目语言;
3、规范是为了支撑目标，目标是研发效能在项目阶段的提升，规范可以调整；目标是部门团队的目标，要着眼于更高的层次思考;

其他问题：

  1. 对于过程的检查大家有什么建议？
  2. 从部门、技术栈的维度组织代码走查，各部门技术栈自己组织，频次 2 次/月 以上
  3. 对于项目计划，各部门负责把控一下，2周迭代的项目要做下评审；（任务工作量估算；项目关键的三个节点集成测试、送测、发布是否都有；）
  4. 明天对各部门的项目经理进行培训；下个迭代开始实践；9月份过渡；10 月份正式实施；

研发能力模型建设：

  • 敏捷项目管理能力；
  • 架构设计能力; 大家开始学习 UML：S1（用例、时序、组件）；S2（活动）
  • 基于云的问题分析的能力；
  • 对前端/服务端架构体系的掌握整理；
  • 压测、追踪脚本的能力；