XAP 是 Xunlei Acount&Payment 的简称，是帐号支付项目组，通过不断实践探索得出的一套敏捷项目管理方法。此方法根据项目本身的特点，对 XP 和 Scrum 理论选择性吸收和改进，经项目反复实践，验证了其有效性，供参考。
作为基础服务团队，我们的敏捷始于敏捷开发，并延伸到测试。组织内部为平衡矩阵型，5 种角色分属不同的部门或团队。经过 5 年多的尝试和实践，将「快速迭代，小步快跑」的思想贯穿于开发的上下游，逐渐发展为全项目敏捷管理。
虽然敏捷开发 Agile Development 一度被视为 敏捷管理 Agile Managment，但我们认为不完全等同。敏捷开发主要是指从开发到上线，敏捷测试，敏捷产品设计等也应该囊括到整个过程中。所以，我们将敏捷中的代表 Scrum 视为敏捷管理，指导从需求拆分到任务完成的敏捷项目管理流程。
首先介绍一下我们团队角色组成，全文用简称指代：用图代替
PM: Project Manager 项目经理
PD: Product Designer 产品分析师，也是产品经理或产品工程师
SE: Software Engnieer 软件开发工程师，但是 DEV 更常用
QA: Quality Assurance 质量保证工程师，通常也代指测试工程师
文中常用的/表示或，&表示与。
敏捷思想
整体框架如下图
- 需求提出方(PD/DEV )提交需求，PM 按照 2~6 周能完成的工作量拆分为 N 个 milestone/sprint，指定master。
- DEV&QA 在 kanban 中添加 1~2 天工作量能完成的 issue，需求提出方(PD/DEV ) 对 issue 进行排序。
- 任务正式开始后，DEV&QA 移动 issue 更新其状态，并生成实时 burndown。由 mater 负责 daily scrum，问题汇总于 PM。
- 项目完成后，由 master 发起项目总结，并开始执行下一个 milestone/sprint。
项目管理
角色和会议
角色主要有3个「」：Product Owner，Scrum Master，team member。
会议主要有4类[ ]：需求说明会，排期立项会，每日站立会，总结会。
工具有3个{ }：需求池管理，看板，燃尽图。
流程中涉及的角色，工作内容和产出按时间顺序整理如下。
1. 需求提出方 PD「1」
我们的需求提出方自来于两方，PD 和 DEV，因此产品负责人会有两种角色。他们的需求必须提前规划至项目指定版本中，以文档的形式存于需求池中。每个需求的提出遵循「28原则」，首先评估实现最重要的 20% 的需求。提出的需求是经过拆分后的需求，通常是短小的，但同时，也允许大型需求的存在(一般是来自 PD 的需求)。文档的作用是为后续工作提供指导，也是组织过程资产，文档中撰写必要信息，一般 1~2 页，60分钟内可以说清楚，杜绝冗杂长达几十页的需求文档。
2. 团队team「2」
针对以上需求，DEV&QA leader 提前预先了解，派遣执行小伙伴参与，执行团队宜小不宜大，一般为2~7人，以不超过7个人为宜。
3. 需求说明会[1]
需求提出方 PD/DEV 必须发起需求说明会，这也是需求评审会，通常是挑战不合理的需求，增减需求或调整优先级。若有更新，则要求次日更新完毕。
4. 立项排期 schedule[2]
由 PM 发起排期会议，正式会议前 DEV&QA 需要做出预估工时，给出任务预期工时(不需要给出详细的执行日期)。PM 结合优先级，整理工时，给出排期初稿，同时附带资源冲突意见。资源冲突交予 DEV&QA leader 解决后，再重新修正排期。同时，我们需要确认发版的频次。
如果涉及重大技术方案更改，则需要 DEV 单独召开方案讨论会。
DEV 的工时评估包含了方案设计，执行，文档撰写和联调过程；QA 的工时包含了测试用例设计，执行和上线过程。整个周期不超过3天，会面临不断修正和更改。
简单说来就是，预估工时 -> 排期 -> 调整冲突/技术方案 -> 重新排期。
此处，我们并未采用「点数」，即难易程度来估算工时。虽然觉得这种估算方式很巧妙，值得一试，但是同样的，我们不擅于做这样的评估。但是，我们能将任务拆成一个可执行的单元来操作。而这一个单元，可称为一个user story，user 则是自己。
5. 冲刺和负责人 MS&Master「3」
MS 是指 milestone，本质上是 sprint，一个 MS 即为一个 sprint。
一个项目分为一个还是多个 MS，由 PM 决定。一般以 2 ~ 6 周 为一个 MS。少于 2 周的项目统一作为临时项目，不需要以 MS 来进行管理。PM 拆分MS后，随即确认生个 MS 的起止日期。在确定好交付日期后，才能指定 master。
在整个冲刺期间，交付终期是不能变更的。如果出现了需要变更的情况，采取缩减需求或延长工期的方式来应对变更。前者需要 PD 缩减需求，后者需要三方同意才可进行变更，PM 需作好相应记录。
MS 有对应的命名规范，需求-版本号-MS简述 @master
6. 工作透明化 board&burndown {1}{2}
board是一个包含了 backlog，to do ，doing ，close 四种状态的看板。
DEV/QA 将工作量以 issue 的形式提交于已建立的 MS 下面，此时 issue 存于 backlog 中。issue 有固定的命名格式，[优先级-工作量 任务详情]。所有 isse 添加完毕后，可进行上下拖动排序。本周即将做的工作，全部拖入 to do list，在做的任务 拖入 doing，完成的任务拖入 close。
如何添加任务，和拖动任务，制定了专门的操作手册，此处略。
7. 站立会 daily scrum[3]
不同项目采取不同的策略，有些是daily scrum ，有些是 weekly scrum。同样是三个问题：昨天做了什么，遇到什么困难，今天将要做什么。
站立会需要 master 通过现象发现潜在的问题，有些问题未暴露，可能是困难摆在面前，当事不能正确识别出来。
8. 高频上线 push online
通常我们一周会确认一个发版的日期，例如周二，在每周二发一次版本。
9. 总结 summary&next MS[4]
在项目完全上线后，进行一次集体的验收和问题总结，并规划下一次MS。
需求管理
需求池管理{3}
需求用需求池进行管理。至少具备以下功能：
- 能够进行任务指派，接力棒的传递
- 能够支持附件，图片必须能够预览
- 能够有历史记录
- 具有全员参与的条件
- 支持主流编写格式markdown，表格等。
敏捷管理的源头，鼓励需求的提出也是敏捷的，需求以用户故事的方式提交。而我作为 PM 在中间作了一层转化，将需求转化为可执行的，可实现的单元。
PD 提交的需求分为两类，一类是敏捷需求，一类是传统需求。
敏捷需求在 6 周内能完成。而传统需求，工期会在 2 个月以上，甚至一年半载。现行组织结构下，不可避免会有传统需求提出，PM 在将需求拆分为 MS 的过程中，扮演着重要的角色。
对于一个 PD 和 DEV 都会提出需求的团队，如何做好两者之间的版本管理控制？
理想情况，项目的划分应该是与角色无关的，所有人都为共同的项目努力。换个角度讲，我们将这种并存的形态看作两个不同的产品线，相当于有两波人向我们项目组提出需求，那项目形态就是不同的，需要按不同的项目来进行管理。经过梳理，PD 给出了3大产品16 个项目，而 DEV 给出了7大产品17个项目，总共33个项目。两类产品之间有完全不相关的关系，也有相互交叠的关系。根据项目与角色可能存在的一对一，一对多的关系，将版本规范定义如下：
1. 各自为政：P线和D线各自管理自己版本号，双方项目不会出现交叉
2. P线为主：P线主管版本号，D线向P线申请版本号，例如websdk
3. D线为主：D线主管版本号，P线向D线申请版本号，例如熊盾
一对多的项目，则是项目出现交叉之处，需要向版本持有者申请版本号。
- 如何管理出现延期交付的需求，例如v2.1比v2.0先上线？
正确的做法是将需求前移。两份需求重新划分，属于本次上线的就是v2.0，不上线的需求搁置到v2.1
一个D线更新，会影响到多个被应用的产品形态P线时，如何处理？
以最主要的，或最先实施的P线项目的版本为规划起点来规划版本，其余算产品接入。一个P线更新，涉及多个D线更改时，如何处理？
这与上面有所区别，P线的版本号迭代更新，D线对应的版本号需要分别作更新，主要以技术方案更新的方式存于技术需求池。版本号对应为：P线项目-版本 : D线项目-版本。
版本管理
项目内部长年有一个有趣的现象：某项目重构时，都习惯性的称之为新某项目，某新项目。一年之后，在此基础上，又成立一个项目，为新某项目。再过一年，又重构，还是新某项目。几年下来，我们项目换代了多次，大家都搞不清，究竟哪个才是新，哪个才是旧。
版本管理从开始规划到落实，遇到了不少阻碍，前后花了一年半。下面讲一讲我们项目组内的版本进化过程。
项目内版本有3种：产品版本号，代码版本号TAG，文档版本号。产品版本号与代码版本号一定程度上有关联，并非完全一一对应。
代码版本管理
由于环境原因，我们首先推动改进的是代码版本号，利用 gitlab 中的 TAG 功能，对每个上线的版本打上标签。TAG 在概念推广期间遇到阻力，大家都没有这样的习惯，打不打 tag 对工作造成不了任何影响，代码可以照样提交，部署。执行时，大家反而会认为 leader 的一句话增加了工作负担。但是，当逐步推行到将此 TAG 作为代码交付、上线的「唯一标识」时，大家才真在开始普遍运用，因为在 TAG 缺失的情况下，是不可能完发布动作的。我们将此作为一个核心的思想，而围绕此 TAG，我们能精确的做到发布、灰度和回滚。
这里稍提及分支开发的思想：开发时，采用分支开发，多人同时开发时，会拉取不同的分支开发。如果不同分支存在先后版本关系，则测试时，也可以测试分支 branch，不测试 master 版本。最终被测试通过的代码合并到 master，版本则迭代为需求版本号，打 TAG 进行封版，将 TAG 交付于运维推到生产环境。
当某个版本出现 bug 时，则从某版本处重新拉取一个分支修复 bug，而不影响主分支，且最终的 tag 修得也是针对分支打 tag。
TAG 版本是开发过程中对代码做版本管理的一个手段，与需求版本号部分关联，与文档版本号无关。只有将所需要推广的内容作为日常工作中必可少的一部分，才有可能真正全面实施。
有效的解决了开发测试运维之间沟通问题的效率。
需求版本管理
通常，敏捷管理下的产品版本号，并没有传统项目那么好管理，PD 往往忽视提交需求的版本区分，给下游工作带来很大的麻烦。我们需要将各业务线，和与之相关联的业务以版本迭代的形式进行管理。便于下游同事以以版本为基准进行sprint 规划，测试用例建立等。
文档版本管理
文档版本号，一般针对协议文档，需要说明版本迭代的历史与目前的版本号，以便调用方区分线上使用何种协议。
敏捷的一些思考和质疑
我们的过程是敏捷吗？
scrum中典型的几个特点，如点数我们并未采纳，对于工作的评估我们依然是基于时间来的，与scrum中强调的「我们对时间的估算是最不准确的」相悖。
我们角色与角色之间有明显的交付日期，这与冲刺阶段自主工作也是相悖的。哪些是敏捷一定不能有的？
短期看不到效果的项目
我们团队的宗旨「最大限度提升人的自由和创造力」，从何而谈？敏捷没有文档
我们团队的敏捷与传统瀑布V模型的小型瀑布模式有什么区别？
理解一个概念，拥有完整流程的过程，是不是就一定不是敏捷？
同样是要经过完整的需求设计、需求评审、方案评审，到用例设计与评审，最后到执行的环节。
我们所采用的敏捷，是否只是概念上的敏捷，而本质上仍然还是V模型？形似而神不似。什么样的迭代频次可以称得上是敏捷？
敏捷的精髓是否掌握完全？
遇到一个问题一直阻塞不能解时，怎么办？
-
团队目前存在的问题
某个时间段某个 DEV 在做些技术攻坚，PD是否知道需要避开这个时间段提测需求。PM 一个人承担了master的角色，在各个项目中保证流程正常流转，若PM离开，此流程还是否迭代下去？2018-05-29
