摘要：在软件业界,敏捷开发及项目管理方法已成为很多团队高效运作的有力武器。在项目的启动环节中引入QuickStart方法，帮助快速确立项目目标，统一理解，发掘用户需求，使用各种流程建模和分析技术，产生交付计划。之后项目团队就可以立即投入迭代开发工作。该方法是一种可以有效推动软件项目快速启动的敏捷项目管理方法。
【关键词】敏捷项目管理 敏捷软件开发 快速启动 QuickStart 用户模型 场景模型用户故事 交付计划
1.敏捷开发及项目管理方法体系
1.1敏捷方法介绍
敏捷方法诞生于2001年初，当时，由于看到开发团队陷入越来越沉重的软件过程当中。业界专家们总结出了一套使团队具有快速工作、响应变化能力的价值观和原则。基于这一套价值观和原则的软件开发方法，被称为敏捷软件开发方法（Agile Software Develop-ment），而这类方法也发展出相应的敏捷项目管理体系（Agile Project Management）。敏捷开发方法及项目管理体系统称为敏捷方法（Agile）。
1.2敏捷方法的优点
敏捷方法是一种以人为核心、迭代、循序渐进的开发及项目管理方法。该方法使用了迭代、增量等方法来优化可预见性并控制风险。它灵活、高效、可持续，可以帮助软件开发团队有效地应对复杂的适应性问题。
该方法受到拥护和流行是因为采用了该方法后，团队得到的收益：据统计,敏捷方法可以让团队的效率提升3~10倍；软件的质量也更有保障；团队成员有良好的发展机会；技术能力和团队协作也得到了提高。
2.敏捷项目的快速启动
2.1什么是快速启动?
敏捷软件开发项目通常会通过1~4周的快速启动（QuickStart）工作，制定出迭代开发计划，然后在开发过程中逐渐完善需求。QuickStart是一种高效的项目启动方式，主要用以在项目开始之前识别关键的驱动因素，这种方式能够让关键干系人认可并理解即将交付的产品。如图1所示。
3.QuickStart的前期准备
3.1邀请相关参与人员
QuickStart过程中需要邀请参与的人员包括：核心团队、领域专家及用户代表、关键干系人（受益人、高层领导等）。核心团队一般包括产品负责人、需求分析人员、项目负责人及核心团队成员。这些人需要全程参与整个QuickStart，他们是成果的主要贡献者。领域专家及用户代表主要在用户建模、场景建模等环节为团队提供专业的意见和建议。他们可以在某些阶段时参与到QuickStart中来。关键干系人主要参与QuickStart的启动和展示汇报的环节，并对产出成果进行确认，特别是需要对产品目标和发布计划进行确认和授权。
3.2拟定QuickStart的计划
在QuickStart正式开始之前，项目负责人和产品负责人需要拟定QuickStart的整体计划。以一个2周的QuickStart为例，整个QuickStart计划可以这样安排：
QuickStart启动及业务目标识别（0.5~1天）
参与人员包括：核心团队、领域专家及用户代表、项目领导
产出物：产品目标
识别主要角色及场景（3~5天）
参与人员包括：核心团队、领域专家及用户代表、项目领导
产出物：主要用户角色列表、核心场景及流程、页面设计及原型
需求列表梳理（1~2天）
参与人员包括：核心团队、领域专家及用户代表
产出物：用户故事清单
规模及成本估算（0.5~1天）
参与人员包括：核心团队
产出物：估算结果
迭代/发布计划制定（0.5~1天）
参与人员包括：核心团队
产出物：迭代/发布计划
QuickStart的成果汇报（0.5天）
参与人员包括：全体团队成员
产出物：成果汇报材料
4.引入的各种流程建模及分析技术
4.1识别业务目标及愿景
业务目标的识别和确定需要符合SMART原则；需要了解问题的背景及上下文信息；需要定义验证问题成功的标准；需要界定问题的范围，例如规模指的是数量还是金额，或者单品规模；需要明确并逐步完善关键干系人信息；需要明确关键资源，例如领域专家或者关键信息等等；还需要明确该问题的各种约束条件。
4.2识别角色及主要场景
用户识别从头脑风暴的形式开始，尽可能识别出更多的用户，然后挑选出主要的用户和角色，并且为用户进行用户画像，并建立用户模型。通过理解用户的目标需求和痛点，梳理出更多的细分用户场景，之后对用户场景进行优先级排序、分析，以发现其中的问题或隐含的机会。
对问题和机会进行结构化的分析可以通过这几个方面来进行：
（1）进行问题/机会的原始描述；
（2）通过事例来说明问题/机会的现象；
（3）对问题/机会进行定量的分析；
（4）对问题/机会进行定义并明确对于问题解决的期望；
（5）将问题和机会的相关分析及描述标识在用户场景描述的周围。
业务流程梳理的过程中可以将之前识别出来的用户场景在进行串联。较高层级的业务流程将各个场景串联起来之后，就可以在场景中进行场景流程的细化和展开，分析出流程步骤和各个步骤的细节。业务流程场景中的步骤细节需要包含这些信息：场景名称、场景入口的背景说明，本场景中需要跟进解决的问题，场景中事件步骤，某个步骤的细节说明，还需要有场景的出口目标。
4.3产出Product backlog
根据上一环节中梳理出来的用户模型、场景模型、业务流程以及场景细节，开始进行用户故事的梳理，并建立用户故事列表。用户故事是为了方便与用户沟通而记录的信息，它不是需求文档，它需要以用户能理解的方式来进行描述。它的目的是要将用户的关注点从“写”转移到“交流”上，让开发团队做用户真正需要的东西，而不是用户写的东西。
一个用户故事的描述样例是：“作为一个<角色>，我想要<活动>，以便于<商业价值>”。一个用户故事是否成功可以从以下几点（INVEST）来判断：是不是独立的（Independent），是不是可协商的（Negotiable），是不是有价值的（Valuable），是不是可以估算的（Estimable），是不是大小合适、粒度相似的（Sized appropriately），是不是测试能够测试、业务能够验收的（Testable）。
4.4梳理依赖、估算及优先级排序
核心开发人员对已经梳理出来的用户故事进行初步的技术解决方案分析，确定用户故事的技术实现可行性和一些可能的实现方案。然后从逻辑层面和技术实现层面，对用户故事列表中的故事进行一次检视，对于一些无法避免的用户故事之间的相互依赖，需要在故事卡片上标识出来。对已经梳理出来的用户故事进行估算，估算内容包括故事规模估算、工作量估算等。
估算完成后可以根据用户故事的价值、重要程度、依赖等信息进行用户故事优先级排序。排序的原则是优先考虑那些最有价值的故事、最关键的故事、被其他关键故事依赖最多的故事。
4.5制定交付计划
经过以上各个环节，团队已经得到了了一份标识了优先级、依赖关系、工作量估算等信息的用户故事列表，此时可以开始来制定交付/发布计划了。根据已经排序的优先级选择并整理每个迭代/版本需要完成的用户故事，使用每个故事上之前已经完成的规模或工作量估算，加上功能联调和集成可能增加投入量的buffer值，整理并安排出整个交付计划。
对于最近的一个交付周期的安排是团队应该投入最多时间进去分析和做进一步估算的。确保第一个交付周期的所有用户故事清晰且被团队理解，并且该周期中的所有用户故事都已经有较明确的技术实现方案，可以在QuickStart结束之后马上进入开发实现。如图2所示。
4.6汇报QuickStart的成果
QuickStart的最后一个环节是召开QuickStart成果汇报的会议，该会议的邀请人员包括项目团队全体成员、项目领导、相关干系人。会议上向项目相关人员汇报QuickStart的成果产出，包括确定项目产品目标及愿景、需求列表及交付计划。在展示项目团队QuickStart成果的同时也获取相关领导及干系人对成果的认可和支持，统一项目团队人员的认识，为汇报结束后立刻投入到需求的开发实现奠定基石。
5.结束语
敏捷项目中的QuickStart是一种高效的项目启动方法，帮助项目快速确立目标、梳理需求并排定计划。它是一种敏捷的项目管理方式，强调共享、合作与包容，业务与IT关键干系人全程共同参与，注重群体决策。它是一种经过反复实践验证，效果较好的项目快速启动方法。(本文2017年发表于《电子技术与软件工程》)
