题记：不论是做动画、游戏、应用还是企业级产品，大大小小项目走过来，本质其实都是一句话：“让一票人一起协作完成一个共同的目标”

一，划边界

柳传志总结过3句企业要素，“搭班子、定战略、带队伍”，其中两大要素就是和人有关：搭班子和带队伍，知易行难，是科学更是艺术。实践中每个人对事的理解不一，例如项目的目标和结算在老板和员工心目中也是不一样的，管理者看结果，专业的事情留给实践者，而引导员工如何落地就一定要重过程。

整理一下，启动一个项目的第一步就是立项，如何确定产品的方向和目标，如何把控项目进度，如何驱动产品迭代，以及如何调动团队积极性等。去年在团队上最深刻的反思，就是“和程序作斗争，而不要和程序员作斗争”。

3大要素也适用于过程，立项是基于产品去明确目标，而落地则是基于时间来考虑过程，同样包含5 个关键步骤：选方向、定目标、控进度、带团队和排干扰。

1，方向

6年前从加入初创公司踏入了创业之路，那时我们的模式很原始很作坊，一切立项都是几个人坐下来各自描述心中的想法，当一个点子获得认可，大家一拍脑袋，“我靠这事靠谱！做出来一定呲皮！”，紧接着就挽起袖子开干。

那时手机游戏没现在这么复杂，4个人1个月就能做出一款3D游戏，完成后上传商店，默默的盼望点击和下载量爆涨，大部分结果最后都证明草率的立项只会是大家的一厢情愿，心中的那股情怀也在这种不断被现实打脸的过程中消失殆尽。

15年开始再做产品时，我们总结了之前的经验，开始尝试花掉6个月的时间去调研和思考方向，其中3个月会做各种各样的Demo，一切妥当之后才会搭弓上箭，3个月做出第一版，上线验证开始迭代。所以，方向成为了整个项目中最重要的一件事，无论是基于产品，还是基于过程。

为产品定方向，基本上是在考验创业的领导人和你对合伙人的认识，无论是经典常用的SWOT还是5W2H分析，产品定方向是启动一切之前最大的赌注。这里我不做展开，先将视角回归在过程，起码需要团队坐下来讨论并同步这么几个事情：

• 方向和愿景：用最简单通俗的语言描述产品的价值
• 机会和趋势：不管市场是红还是蓝，了解对手甚至BAT为什么做或者为什么不做，明白了缝在哪，然后才知道怎么去拼
• 用户画像和用户需求：针对用户谈价值需求，例如聊天记录可以同步到云能方便用户切换使用场景，不一定提商业价值，例如用户可以加入会员提升同步上限
• 已知的解决方案和机会：我们和隔壁的公司和隔壁的隔壁的公司都在做这件事，那么优势是什么
• 团队的利益点：明确大家的优势和做完之后收获的成长和利益，不仅仅包括分钱
• 团队的弱点：提出问题和困难，预估一些需要众人去啃的硬骨头
• 时间结点：市场和资源的时间结点在哪，决定了大家手上的船票登上的是艘大船还是小船，还是自己划水跟着船前进
• 上线计划：对游戏有封测、内测和公测，对APP呢，比如开个发布会
• 核心衡量指标：成不成总要有个依据来支撑项目前进，用户量？流水？企业估值？

2，目标

也许是和外企的经历有关，以前我对目标的认识就是KPI（Key Performance Indicator/关键绩效指标），可完整可量化的业绩指标（基于SMART）。在实践中，我不断思考以何种形式来将目标量化，例如代码质量是否可量化，内存调优是否可量化，兼容性测试是否可量化，美术资源压缩优化是否可量化，这个思维影响了我很长一段时间，回顾看看，发现自己一直奔波在过度依赖理性数据来执行判断。

几个月前和HR聊到目标时，他给了我另外一个思路，PBC（Personal Business Commitment/个人事业承诺），相比KPI，更适用于一些难以量化的场景，特别是针对研发这样输出价值难以量化的对象。前者是自上而下的目标分解，而后者是在理解目标之后自下而上的主动承诺。当一件事呈现双向性的时候，不管你在团队中处于什么样的角色，信息都能实现同步的传达，一线工程师不会和产品总监的当前工作计划产生隔离，团队就不会那么容易产生跑偏和脱节。

换而言之，实现目标达成的最佳工具和手段，就是去掉沟通的障碍，降低通达的成本。有个验证团队是否拥有一致目标的方法，你问一个团队负责人他某一个下属的工作职责是什么，不多不少就3条，他说完后你记下来，接着你去问这位下属，你的工作职责是什么，也是3条，完了两边一对，如果内容不一致，那么团队的沟通在目标达成上一定存在问题。这个方法我屡试不爽。

这种继承式目标加关键结果导向的方式，实际上刚好匹配了Google的OKR（Objectives and Key Results/目标与关键成果）模式，它驱动了Google从40人发展到40000人，且大而有序。

3，控进度

以前做单机游戏，左手边坐的策划，右手边坐的主程，3个人有问题随时转头。当后来开始牵头网游项目，团队从3个人一下扩张到20人，算上运营和客服，小30个人的团队，此刻传统的沟通方式和协同就出现了大量的问题。信息不同步，需求和缺陷的杂糅，版本管理混乱到无法回滚，根源其实就是进度的失控。

复杂庞大的项目执行起来最重要的一环就是控制进度，借助SCRUM思路来指导，实践中采用包括将单Sprint细分为2周，每天强调沟通的站立会，目标都是在确保每个环节都能可控，但信息流是庞大的，一旦有产品上线，在研版本和在线版本，反馈需求和运营需求，产品计划和市场计划，客服追踪和巡检测试，如果一切都需要靠手动和人脑去关联，会崩溃的。

流程中因为有了阶段划分，就一定会有检查点，不论是里程碑的发布，还是研发阶段性接入进入调优阶段，持续和梯度改进才能体现迭代的意义。

4，带团队

我曾尝试去这样假设，如果一个项目团队是因为发起人或者精神领袖的个人光环而凝聚在一起，一旦这个人离去，这个项目会怎么办？

为了验证，我实践了这个假设，对于一个初创型的团队，完全去中心化真的是作死。我尝试用规则来稳定和平衡，但事实证明，相同的价值观和缘分是让团队凝聚起来的首要前提，否则小团队这般，未来如何才能大而有序？

SCRUM中强调的一点是主动和自觉，包括任务都应该是自由领取而非强制指派，构建小而美的团队不能仅仅只靠核心团队，否则这是在人为的在团队中划成了两派，一派核心成员为了理想和目标奋斗，一派成员就是打工心态，这样的团队很难成事。

团队的成员结构也造就了团队的独特，在初创阶段还不可能使用大规模团队的管理方式，所以需要结合实际情况找到最佳的迭代节奏，先慢后快，还是先紧后松，一切都需要根据实际情况来调整。

当前几个迭代跑动顺利之后，项目的权限就需要开始逐步下放，例如项目经理就需要成长为Scrum Master，产品经理细分到产品甚至成为模块的Owner，团队成员从team member到team leader的成长，需求的拆分由技术主管交棒给团队成员，至于之前提到的考核，也可以化零为整，调整为团队的共进退，而不是个人的独立考核。

敏捷不提倡单兵英雄主义，但一定需要给到团队反馈和信心，所以有几个会议需要在过程中强调议程和参与者，包括站立沟通会，需求完成后的演示会议，复盘总结会，提高团队的参与感和成就感。

5，排干扰

干扰来自于各方面，包括：优先且紧急，不优先且紧急，优先且不紧急，不优先不紧急。当发现团队忙的昏天黑地，但成绩却十分缓慢或者依然存在大量延期，大可回头看看规划过程时，是不是在将有限的兵力去实现无意义或者并不是最重要的任务。

举个栗子，老板有一天走过来，说我需要做个什么巴拉巴拉，你看这么重要的事情，尽快完成！有时这种指令的传达会出现多头管理，那就是其实本来大家都清楚时间不够了，但因为这是老板说的，所以研发人员有时会自告奋勇地表现一下，没问题可以加！然后偷偷调整了开发计划。项目经理听到就不干了，说这样计划就不对了，但员工说这是老板要求的，项目经理就去找老板理论，老板说既然你来了那就你来安排吧，项目经理说做可以，请等待N周，老板不干了说你太不重视我需求了！吵着吵着，项目经理离职了，挣了表现的员工因为项目延期也没捞到什么好处。别笑，这栗子还真事，成都某幼教产品团队，老板和产品经理是夫妻，项目经理干的里外不是人，库房里产品堆积如山，据说2016年的目标是响应国家号召：去库存。

元旦前我面试了一位应聘者，她在某财务软件公司任职期间负责研发团队的QA工作，她有个思路我很赞同，那就是将需求的价值和人力的投入估算出研发的ROI（Return On Investment/投资回报率），用于评估研发的性价比，当然参数还包括了时间成本等。之前她就发现团队效率特别低，之后开始找原因，发现产品需求来源于深圳公司，人员协同靠远程，因为成都这边只是研发团队，上一个需求还没消化，下一个需求又来了，有时需求专业度较高，还得从深圳派行业专家过来给程序员培训！当初选择在成都建研发中心是理解这边人员成本低，可是纳入公式后发现，同样的成本去深圳少雇佣几个贵的程序员，研发周期反而更短，最终成研所在ROI面前完败，整体部门被裁掉。

这两个小例子，其实都是希望证明一点，小而美的团队需要更紧密的协作和更一致高效的步伐，管理者的心态需要转变为服务者，需求的归口和权利的下方应该提前约定。敏捷不是不接受变更和插入，而是需要协调一个共同认可的方式进行。一个项目经理最厉害的时候就是这个团队不需要你了，作为Scrum Master应发挥的是教练角色，而不是保姆角色，这样才能构建一个有自我组织的团队。

二，实施

敏捷开发宣言告示了我们将思路付诸实践的重点：

我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，
我们更重视左项的价值。

部署实施敏捷其实有很多方式，借助部署指南，最传统的方式是卡片和看板，借助沟通来完善项目燃尽，评估方式还有打估算扑克这种神器。选定方案前摸索了大量工具，我试用过worktile，project，redmine，灰狐协作，Jira（最难用没有之一），tower，最终选择了禅道。

接下来，就分享下经历了3年反复修订的敏捷实践吧（终于可以祭出这张图了 ¯\_(ツ)_/¯）。

 

1. 概述

1.1.      目的

产品在开发过程中需要考虑的项目管理流程，包括立项计划，需求分析，项目排期安排，里程碑版本分拆，发布计划，项目中的任务分解，版本出包管理，出包与测试配合，冻结功能后版本协同，基于版本和测试用例的测试任务协同，开发与运维的版本协同，配置文件的管理。敏捷对上述流程的拆分大致如下：

1. 需求规划和分期
2. 需求评审
3. 需求讲解
4. 方案评审
5. 每日晨会
6. 自研测试
7. Code Review
8. 回归测试
9. 线上Bug修改

1.2.      定义/缩写

1. PRODUCT – 产品
2. PROJECT – 项目
3. S – STORY – 需求
4. T – TASK任务
5. TC – TEST CASE – 测试用例
6. TT – TTEST TASK – 测试任务
7. BUG – 缺陷
8. BUILD – 版本
9. DEBUG – 开发中的测试版本
10. RC – RELEASE CANDIDATE - 待发布版本
11. TRUNK – 最后的发布线上版本
12. QA – QUALITY ASSURANCE - 品质保证
13. QC – QUALITY CONTROL – 品质控制

2. 命名规范

在开发阶段和上线阶段，版本的命名应该有所区别。

2.1.      语言命名规范

对于不同语言，版本定义不受影响，唯一的变化是命名中的语言标示符，例如ARDCN_DEBUG_20130324表示安卓中文版，而对应具有相同功能的英文版本命名则为ARDEN_DEBUG_20130324。

2.2.      打包命名规范

对于处于开发阶段，包命名基于项目，以打包时间来定义包名，并附加DEBUG作为开发版本标示，用日期为数字结尾。例如ARDCN_DEBUG_20130324_01表示在2013年3月24日打的第1个安卓中文开发包。当开发完成打包操作后，禅道需要建立对应的项目版本，并关联该包完成开发的需求，或者已经解决的BUG。

如果即将进入上线阶段，版本开发已经封闭功能，不再增加新的功能而只是修改BUG和调优，那么版本命名将修改为RC版本。例如ARDCN_RC_20130324_02，表示为在2013年3月24日打的第2个安卓中文待发布包。这里的包开发进度会进入快速迭代的状态，直到版本稳定可用于提交发布。

3. 开发流程和周期

3.1.      开发流程

当DEBUG在研版本通过测试可以上线后，那么该项目的最终BUILD版本将作为TRUNK版本建立在产品的里程碑上，构建为在线版本。具体开发路线基于敏捷开发（SCRUM）设计，总流程如下图：

3.2.      开发周期

开发周期（SPRINT）按照需求上线状态分为未上线开发期和在线版本开发期，如果按照需求完成度来分，则以里程碑阶段来划分开发期。

在未上线阶段，可以使用快速迭代的开发方式，以2周为单位，在进入上线阶段后，可以设置使用长期项目做需求维护（不使用燃尽图），建议不超过4周，解决线上发布的已知问题和相关优化，再继续就得考虑是否需要再此基础上做迭代。

3.3.      短期迭代中的版本管理

在短期迭代中，禅道项目以小标示为主要开发节奏，例如1.1.0和1.1.1，这个阶段的版本适用于功能更新、BUG修复和代码优化，如果处于优化迭代，可能项目中会出现只有RC版本而没有DEBUG版本的情况。

3.4.     长期项目中的版本管理

对于大版本开发，禅道项目以大功能为开发节点分期划分项目，跳版本号的时间可以以上线计划为标准，例如1.1.2到1.2.0，期间但项目结束不等于必须发布，项目应以部分需求分期完成为准。这里的Bug将以导入的方式新增至下一个项目，因为一个需求可能需要在多项目之间完成开发和调试，测试不需要约束在单一项目阶段内。

4. 项目角色

基于禅道对项目负责人的责任划分，包括以下几种

全称	角色	职责描述
PRODUCT OWNER	产品主管	产品负责人，定义需求和开发计划BREAK DOWN（分解），为产品方向和发布负责
PRODUCT MANAGER	产品经理	确定产品的功能和优先级，拆分需求，给团队讲清楚需求，为功能合理性负责，不为产品进度负责，不是研发的保姆
PROJECT MANAGER	项目经理	项目负责人，为进度负责，可调度人员和加班权限
SCRUM MASTER	敏捷教练	项目管理者，负责流程控制（一般由项目经理兼任）
TEAM LEADER	研发主管	小组的负责人，参与需求评审和任务拆分，提出验收标准，负责提交测试和BUILD，根据进度调整任务，为研发风险负责
TTEAM MEMBER	研发	开发人员，完成功能开发和测试，主动自测可能的缺陷和性能问题，及时反馈进度风险，确保需求理解正确，代码可维护，交叉Code Review
TEST MEMBER	测试	测试人员，完成测试用例和测试任务，关联执行用例并提BUG，完成边界测试和回归测试，配合线上反馈验证缺陷

5. 版本管理

版本的管理统一归口项目经理，统一整理版本号和命名规范，并在打包前将配置更新至SVN，产品和研发需配合，同时告知研发主管对打包复核。

5.1.      开发计划和版本的建立

版本由产品主管和产品经理讨论后，确定开发计划（PLAN）和开发版本（PROJECT）的关联，确定优先级，开发计划和项目的关系如下图。

而其中，每个版本的开发需求也将会由产品经理和项目经理，根据需求文档和技术评估，参考工作量和版本计划，分别关联在对应的版本中。

这里计划应该先于版本创建，所以当为指定版本关联需求的时候，需求将自动关联至计划中。

5.2.      里程碑版本的建立

当一个项目阶段完成后，需要创建里程碑版本（RELEASE），其中包含客户端、服务器端和资源包。版本的打包控制和存包控制主要由服务器端主程执行，其中文件名规范同文件命名，由产品经理和项目经理确认复核。配置目录范例详见下表：

日期	产品类型	版本号	客户端（文件夹名）	服务器（文件夹名）	备注
2014/1/2	安卓中文	ARDCN_CB1.0.0	C_20140102_all	S_20140102_all
2014/1/7	安卓中文	ARDCN_CB1.0.1	C_20140106_all	S_20140106_all
2014/3/24	安卓中文	ARDCN_CB1.1.0	C_20140324_all	S_20140324_all

6. 需求管理

需求（USER STORY）的创建和关联由产品经理负责，全部需求统称为产品的需求集（PRODUCT BACKLOG）。当产品经理完成对需求的整理后，需要将具体需求的补充和文档描述提交评审，由产品主管主持，和研发主管一起对细节作出评判，一旦产品主管在各方完整评审得出结论后，评审通过该需求设计，该需求将被关联至对应项目中，成为该项目的需求集（SPRINT BACKLOG），产品经理需要对该需求的每个细节做进一步细化，完成文档。

6.1.      需求的创建

1. 基于单个项目周期的需求
2. 基于多个项目周期的需求
3. 基于BUG反馈后新增的需求
4. 基于临时功能调整后变更的需求

这里，前两种需求均为固定设计的需求，在产品设计的初期就已经完成了创建，并且可以根据项目的版本计划做排期关联。

6.2.      需求的状态

需求基于产品的设计和版本计划，所以在创建需求的时候不需要考虑具体实现细节，所有的需求在根据计划和版本录入完毕后，再进入需求的设计和指派。需求的创建具体流程如下。

汇总需求的状态总共有四种状态，分别是草稿（DRAFT）、激活（ACTIVE）、已变更（CHANGED）和已关闭（CLOSED）。对应为需求的流程操作共有：创建（CREATE）、变更（CHANGE）、评审（REVIEW）、关闭（CLOSE）、激活（ACTIVE）。其中，如果拒绝需求的评审，需要说明理由或是否满足以下情况

1. 不是BUG
2. 已完成
3. 已细分
4. 重复
5. 延期
6. 不做
7. 取消
8. 设计如此

最终，流程图如下：

6.3.      需求的阶段

需求的阶段属性是用于描述需求的关联关系，它可以被手动修改的，但是除了验收阶段需要手动操作，其他阶段内状态都会根据关联情况自动更新的。其中

阶段	描述
未开始/WAIT	需求刚被评审后，需求的阶段会自动更新为“未开始”
已计划/PLANNED	需求被关联到某个计划中，需求的阶段会自动更新为“已计划”
已立项/PROJECTED	需求被关联到某个项目中，需求的阶段会自动更新为“已立项”
研发中/DEVELOPING	需求被分解任务后，需求的阶段会自动更新为“研发中”
研发完毕/DEVELOPED	需求分解的任务，都完成后，需求的阶段会自动更新为“研发完毕”
测试中/TESTING	需求分解的任务中有测试类型的任务，需求的阶段会自动更新为“测试中”
测试完毕/TESTED	需求分解的测试类型的任务完成后，需求的阶段会自动更新为“测试完毕”
已验收/VERIFIED	需求需要由产品经理验收后，手动修改为“已验收”
已发布/RELEASED	需求被关联到某个发布中，需求的阶段会自动更新为“已发布”
关闭/CLOSE	需求发布完成后，产品经理根据发布日志关闭需求

需求的阶段主要用于辅助项目经理对不同阶段下需求的复核状态做确认，所以总的来说，需求的完整流程如下（这里计划不是必选项，因为计划是选择性创建的）

6.4.      需求的变更

需求如果在经过评审后需要做变更，那么需求的状态将会被修改为草稿，只有当需求评审再次通过之后，才能被激活进入开发阶段。但是需求变更会影响基于需求创建的任务和用例，变更流程如下

6.5.      需求的编写

需求描述可以参考INVEST原则，具体为INDEPENDENT, NEGOTIABLE, VALUABLE, ESTIMABLE, SMALL, TESTABLE，其中：

• 独立性（INDEPENDENT）： 要尽可能的让一个需求独立于其他的需求。需求之间的依赖使得制定计划、确定优先级、工作量估算都变得很困难。通常可以通过组合需求和分期需求来减少依赖性。
• 可协商性（NEGOTIABLE）： 一个需求的内容要是可以协商的，需求不是合同。一个需求在系统上只是一个简短的描述，不包括太多的细节。具体的细节在产品设计阶段产出。如果一个需求在刚提出时就包含太多的细节，实际上提高了沟通成本。
• 有价值（VALUABLE）： 每个需求必须对用户具有价值（无论是用户还是购买方），一个让需求有价值的好方法是解决一个用户的使用场景。
• 可以估算性（ESTIMABLE）：开发团队需要去估计一个需求以便确定工作量并安排计划。但是让开发者难以估计需求的问题来自：对于技术和专业领域知识的缺乏，或者需求太大了（这时需要把需求切分成小些的）。
• 短小（SMALL）： 一个好的需求在工作量上要尽量短小，最好不要超过1周的工作量，至少要确保的是在一个迭代中能够完成。需求越大，在安排计划，工作量估算等方面的风险就会越大。
• 可测试性（TESTABLE）：一个需求要是可以测试的，以便于确认它是可以完成的。如果一个需求不能够测试，那么你就无法知道它什么时候可以完成。

7. 项目管理

当需求被分拆至项目之后，项目经理包括开发团队需要和产品经理一同进入需求的细分和项目的开发，这里的团队参与很重要，切勿由产品经理代做需求拆分。

7.1.      需求拆分为任务

当需求已经和项目关联完成后，项目经理主持，由产品经理和项目团队开展需求澄清会（由需求发起者对需求做说明），让研发主管和研发人员做工作量评估，评估完成后即可对需求进行任务的拆分。需求拆分中，需要考虑以下几个方面：

1. 任务的分解按照任务类型来分解，例如开发、测试、UX甚至部署环境等。
2. 同类型的任务分解以可指派到单人完成为准。
3. 分解任务尽量保证可以在8个小时内完成，方便次日追踪。
4. 分解任务时，需要基本确定开发周期，以及需要协调的资源。

任务拆分和参与流程如下：

7.2.      任务的分派和完成

当进入任务流程中，项目经理需要配合开发人员完成任务的开发，同时给出需求的复核反馈。其中，任务在创建至结束的状态流程如下

这里的CODE REVIEW可以是研发成员之间的交叉审核，也可交给主管审核，版本提交和测试提交分别详见后面的描述。

8. 版本管理

8.1.      项目阶段性版本

在阶段开发完成后，需要打包建立版本之前，由项目经理提交该版本的需求发布方案（RELEASE NOTE），由负责对应需求的产品经理确认完成情况，创建第一个版本（BUILD）。这里的打包内容包含已经完成的需求（如果需求分解的任务全部完成，则需求状态将自动更新为已完成）和在该版本中修改的BUG。

当开发打出项目的第一个版本时，禅道上需要建立对应项目中的版本，该版本仅用于关联该版本在此项目中完成的需求。在后面的版本中，需要关联该版本包已经解决的BUG，包括测试已经确认和未测试（需要通过对打出的APK包验证后才能确认）。作为项目的第一个版本，在开发中是不会产生BUG的，那么打包流程包含如下：

其中，已完成的需求将自动被关联至BUILD页面中，而部分完成的需求可以手动选择关联，但未完成的需求，则不应该关联至打包BUILD中。

建立版本之后，需要将该版本提交测试进行测试用例的关联和测试，测试人员需要将发现的全部BUG汇报在对应的测试用例上，并且关联对应的BUG、需求和任务。开发人员在接到BUG反馈后，可以快速定位开发阶段内的代码COMMIT时间，进入BUG修复阶段。例如已经打出的版本是ARDCN_DEBUG_20130324_01，那么测试的BUG需要全部关联在这个版本上。

当提交测试执行BUG修复，或者增加新的需求之后，DEBUG_BUILD02在打包的过程中，除了需要包含之前存在BUG的需求，还需要包含基于BUILD01的BUG。这里包的命名需要根据时间递增做调整，如果是当天的多个包，那么命名即为ARDCN_DEBUG_20130324_02。该版本将作为下一个测试任务提交测试。打包流程如下：

其中，已经完成并且复核无BUG的需求，就不需要关联到当前DEBUG版本中了，如果在上一个需求中报出的BUG已经被修复，那么就需要关联至当前BUILD中做测试验证。当DEBUG已经结束全部需求开发后，版本将更改为RC版本，主要针对发布前的BUG修复，其中，打包流程如下：

当版本作为TRUNK结束此阶段的项目开发后，测试需要将新增的BUG报到下一个项目中，并且将版本指派给TRUNK。

8.2.      产品里程碑版本

产品的里程碑版本是指某一个项目阶段性结束，或者是以新版本发布为时间点所建立的版本。以禅道为例，该版本直接建立在产品视图下，以对应完成项目中得最后一个版本为基础版本，使用选择调用的方式，将其作为阶段性的TRUNK版本。

其中，所有在V1.0.1开发过程中产生的BUG都不会作为发布项关联至最终产品的发布版本。同时所有已发布的需求将在建立发布之后，自动修改状态为已发布。

需求是否需要关闭由产品经理在版本发布后，手动执行关闭操作即可。同时，在完成里程碑版本建立之后，项目经理需要创建并启动下一个阶段的开发项目，同时在开发端需要对代码做标签固化备份。

9. 测试管理

测试人员（TEST）即QC的主要工作是协助产品根据需求文档撰写测试用例，并验证开发提交的结果是否符合产品的设计预期，而品控人员（QA）则集中在最终的品质，以维护规范和指标为重要工作依据，那么将两者做对比如下：

QA	TEST/QC
关注过程，对提交时间点和里程碑版本做监督	关注产品，对开发中产生的结果进行检查复核
以公司的标准定义为依据	以产品和设计需求为依据
以评审和验收为主要手段	以功能测试和场景模拟为主要手段
重在发现和提出过程中出现的问题	重在发现开发产生的缺陷和偏离
重在预防和规范统一	重在发现和纠正

与开发相结合的主要为QC测试人员，QA流程另行规范。

9.1.      用例管理

在需求被创建之后，测试人员就需要为对应的需求创建测试用例。其中测试用例的依据是需求文档，用例的创建流程如下

其中，只有当需求通过评审后，才能创建测试用例，用例直接基于需求做分解。

9.2.      测试任务管理

在项目创建第一个版本后，项目经理需要将其以测试任务（TEST TASK）的方式提交测试，测试人员接到测试任务之后，除了关联对应需求的测试用例（TEST CASE）至该测试任务之外，还需要关联或者创建新的专项测试用例，用于完成测试任务中的额外需求描述。

其中，测试人员在得到测试任务后，除了选择对应需求和对应需求产生BUG的测试用例关联外，还需要考虑其他特殊的测试用例，例如为单独BUG创建的测试用例，以及用于性能适配等创建的特殊用例。

当测试任务创建完成之后，测试人员将启动测试任务，并逐条执行测试用例，其中测试用例的执行流程如下：

其中，用例执行的三种结果

1. 通过：用例执行后结果和期望相符，保存用例结果即可。
2. 阻塞：当用例执行的前提条件无法满足时，用例无法继续执行，则需要标记为阻塞。
3. 失败：用例执行后结果和期望不符，需要在结果中提交对应的错误描述，保存后再页面上给出具体问题描述。

当全部用例均执行结束后，测试人员则填写对应备注然后关闭测试任务即可。

9.3.      BUG管理

在测试人员按照测试用例做测试验收的时候，如果测试结果和预期不符，那么测试需要将其作为BUG报给项目，并关联对应的需求或任务。由于测试任务和需求以及BUG都事先做了关联，那么在填写BUG内容时，需要手动补充完善的内容包括：

1. 模块名称：用于定位BUG位于产品的具体位置
2. 当前指派者：BUG统一指派给项目经理
3. 标题填写：标题使用如下模板【版本号】需求标题-问题描述，例如【1.0】发布商城数据-完成后返回错误页面
4. 重现步骤补充：如果重现步骤和测试用例的描述有区别，这里需要做步骤的补充，同时给出必要的截图
5. 相关任务：可选补充，关联对应需求下分解的任务
6. 类型和严重程度：BUG类型包括代码错误、界面错误、设计缺陷、配置相关、部署问题、安全问题、性能问题、适配问题等，严重程度；

如果提出的BUG不是基于测试用例，那么需要在填写BUG详情的时候手动补充全部关联信息。提交BUG后的解决流程如下：

其中，测试需要先提交给研发主管做确认和指派，如果属于可修复BUG则在BUG上点击确认，并指派给对应的研发，由研发做修复，自测通过后提交计划至下一个BUILD中回归。如果该BUG属于新的功能需求，或者不能使用修复的方式解决，则执行转需求操作，并交由项目经历转交产品经理进行提新需求的流程。如果不属于BUG，那么项目经理将给出设计如此的反馈说明，指派回测试人员即可。

如果该BUG需要新的测试角度进行专项测试，那么在BUG指派开发的同时，则需要项目经理通知测试撰写对应的专项测试用例，这里建立的过程将自动关联BUG本身。

在BUG被修复后，开发人员需要在自测后手动标示状态为解决，并指派回测试人员，填写为解决该BUG所创建的版本号（该BUILD可以提前创建但是不做内容关联，这里的版本创建流程禅道可能会在未来做一定调整），以及该对应的解决方案，其中包括：

1. 设计如此：该缺陷或问题属于设计范围，解决确认由研发主管和产品经理在确认BUG前给出并反馈。
2. 重复BUG：可能存在多名测试人员报出同样问题的BUG，那么关闭的同时需要给出重复BUG的ID。
3. 外部原因：例如在测试期间由于断电断网等外部原因导致的BUG，如果设计者认为这属于非开发可解决的问题，那么可以选择该理由解决BUG，并且以新的需求等方式提出解决方案。
4. 已解决：通用的解决方案，需要注明大致的解决方案。
5. 无法重现：在测试的描述不清等情况下，开发人员无法通过重现步骤复现该BUG，那么可以选择该解决方案理由将BUG指派给提出该BUG的测试人员，由测试人员重新提交复现步骤。
6. 延期处理：如果该BUG不属于该项目内可解决的范围，或者属于下一个版本的开发计划，可以选择该方案回复。该BUG将在未来创建项目的时候，以导入的方式成为新项目的开发任务。
7. 不予解决：如果研发评估该BUG不需要做修复，甚至包括修复成本过高，设计上处于可接受范畴等情况，可以选择不予解决的方案回复。

那么当全部BUG都被标识解决之后，新的版本将会被执行打包发布，测试人员基于该新版本对BUG做回归验证测试，如果已经完全修复，测试人员即可选择关闭该BUG，否则打回开发人员重新修复，流程如下：

其中，在创建版本的时候，需要复核所有基于上一个版本提出的BUG修复状态，这样回归测试才能在新创建的版本上做有效验证，复测完成后关闭相关BUG，如果测试未通过，则需要激活并指派回项目经理。

10.    未完成任务和BUG管理

当一个版本完成开发之后，可能会依然存在没有完成的任务或者暂时没有修复的BUG，那么在项目经理创建下一个项目的时候，则需要将这些未完成任务和BUG重新导入至新的项目中，并由系统自动将对应的需求也关联在一起。

三，THE GOOD THE BAD THE UGLY

篇幅有限，还有很多细节没能在这里一一描述，需要明确的一点就是，敏捷实施一定是根据团队来定制的，没有一招鲜吃遍天的玩法。

工具是有成本的，当团队只有几个人的时候，这样做的意义并不大，反而会过度使用流程和规范，通讯靠吼反而是最高效的协作形式。一旦人数达到几十，即使拆掉隔板也无法解决沟通快速通达和理解到位，此时工具的成本（学习成本和跑通的时间成本）被人数分担下来才是最划算的。

同样，在一个团队中去推广观念部署一个一套系统，没有足够的行政力和上级的支持，也就不要指望去执行以上规范。可以参考14年和春哥聊到早期在团队中的实施之路：如何有效控制项目的风险和成本。当时是完整启用禅道的第一个项目，5个月，4个产品，5个计划，平均8个项目平行进行，11个Release，304个需求，开发时间偏差率29.89%，1357个测试用例，用例通过率56%，1117个Bug，提交有效率73.23%，线上运营1次版本事故，还是因为SVN导致的。

敏捷不是万能的，如果项目和团队本身出了问题解决不了，敏捷也解决不了，更不要寄希望于一个工具来解决问题。如果问题出在人身上，是能力还是态度，一定要去发现去解决，这才是解决问题的根本。看待问题需要去看待本质，如果单纯寄希望于工具来解决问题，是一种惰性思维。

所以，人的因素永远是第一位的，首先要有共同的价值观和共同的目标。敏捷的实践不是一朝一夕就能一蹴而就的，从少到多，从易到难，每一个Sprint其实都是一个小瀑布，不过是一次少做一点，做好一点。

值得欣慰的是，目前团队的伙伴还是能够认可我的三观，有意愿和能力把事情做的更好的人。新的一年伴着新的业务悄无声息的来了，希望今年也能招到靠谱的人。

所以，这篇敏捷实践最终被我写成招聘贴！

我们想要什么样的小伙伴：

产品经理（可实习）

岗位职责：

1. 负责管理来自用户和公司内部的业务需求，完成需求分析，并最终形成产品设计，进行可行性分析及设计，撰写产品功能需求文档；
2. 制定项目计划（敏捷开发），负责与UX设计、研发、测试、运营、客服等团队的沟通，主导完成产品的界面、功能、流程设计；
3. 持续跟踪产品上线后的效果，分析日常运营数据与转化率等核心指标，提出更新和优化方案，提升产品的用户体验和用户活跃度；
4. 研究市场，定期对自身产品，整体行业，竞争对手等进行数据分析并评估，并提出产品改善计划；

岗位要求：

1. 本科及以上学历，专业不限，全职要求3年以上产品经理工作经验，至少主导过3个以上或参与过5个以上APP产品的规划、迭代、上线、日常运营;
2. 熟悉iOS、Android操作系统特性及交互规范，喜欢研究各类移动端产品，深刻理解如何构建产品的机制，非常熟悉产品的生产研发流程；
3. 具备良好的业务和产品规划能力，良好的需求分析和产品设计能力，优秀的数据分析能力和商业意识；
4. 掌握用户调研、需求确认、产品定位分析、产品原型及PRD的撰写，产品上线后的部分测试工作、BUG处理、用户反馈等；
5. 熟练使用Axure、MindManager、Visio等软件，面试时可以带一份以前自己编写的需求文档和原型图；

项目经理

岗位职责：

1. 负责项目管理工作，根据产品战略规划制定项目版本目标并监督实施，确立质量标准并严格推进、跟踪、协调；
2. 推动项目节点，跟进各项目进度需求和团队日常管理工作，包括任务安排和阶段汇报，对项目执行质量和进度负责；
3. 部门间的横向配合推动，有效平衡产品、研发和测试进度的需求，对流程进行优化，带领项目团队实现设定的预期目标；
4. 对整个项目团队的开发效能进行监控，及时发现并处理各项潜在问题；

任职要求：

1. 本科以上学历，5年以上工作经验，3年以上项目管理经验；
2. 熟悉禅道，具有完整的项目管理经验，熟练掌握敏捷管理知识；
3. 有开发技术背景，跟进过产品的研发周期进度，熟悉从立项到开发全流程管理把控；
4. 思维严密细致，具有良好的处理人际关系的能力，善于树立个人威望及领导力；
5. 具备独立工作能力，有较强团队合作精神及抗压能力，主动性强，有责任心；
6. 善于归纳总结，能够推动团队效率不断提升；
7. 有一线公司开发项目管理经验、成功项目经验经验优先；

Android研发工程师

岗位职责：

1. 独挡一面，负责Android客户端的开发和优化；
2. 与各类工程师一起研讨技术、制定优秀的解决方案，开发核心模块；
3. 编写相关技术文档等工作;

任职要求：

1. 本科及以上学历，计算机或相关专业；
2. 3年以上Android开发经验，精通Java开发语言；
3. 烂熟Android体系结构，熟悉进程间通信；
4. 紧追Android前沿技术，并熟悉国内主流品牌安卓手机的特点；
5. 熟悉安卓性能优化的基本概念，熟练使用安卓平台性能优化工具；
6. 个性开朗，善于与产品，UI，测试团队沟通合作；

iOS研发工程师

岗位职责：

1. 负责iOS客户端产品的设计、开发、文档撰写；
2. 负责优化客户端软件的模块结构和流程逻辑；
3. 负责优化客户端软件及升级维护；

任职要求：

1. 本科以上学历，计算机或相关专业；
2. 3年以上iOS开发经验，精通Objective-C，掌握Swift开发语言；
3. 烂熟iOS SDK中的UI、网络、数据库、XML/JSON解析等开发技巧；
4. 紧追常用软件架构模式，熟悉各种算法与数据结构，多线程，网络编程；
5. 熟悉App Store发布流程和审核要求；
6. 精通iOS开发工具和相关开发测试工具的使用，熟悉各个不同版本iOS的特点；

联系方式

直接扫描加我的微信（ congcong009）

当然，如果你喜欢本文，欢迎随手打赏下呢