敏捷项目管理
组建Scrum团队
本文将以一个示例项目为对象，介绍如何进行敏捷项目管理，示例项目背景如下：
凤凰商城示例项目介绍 【凤凰商城】示例项目是耗时数月所开发的汽车零部件配件电子商城。项目采用 Scrum模式 进行迭代开发，每个迭代周期为“两周”，前3个迭代已经完成“凤凰商城1.0” 版本的开发，当前正在进行 “迭代4” 的规划。
在开始项目规划之前，我们首先要组建团队，并确定团队的运作模式。而在这个客户需求不断变化，交付周期不断压缩的时代，敏捷开发模式无疑是各个开发团队的首选。
CodeArts提供了多种项目管理模式，其中就有基于Scrum框架的项目类型。因此，我们将以Scrum框架为例，并在此简单对Scrum进行介绍。
- Scrum的定义
Scrum（名词）：Scrum是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付可能最高价值的产品。
Scrum是：
- 轻量的
- 易于理解的
- 难以精通的
Scrum并不是一种过程、技术或决定性方法，而是一个框架，在此框架中您可以使用各种不同的过程和技术。 Scrum让您的产品管理和工作技术的相对成效更加清晰地显现出来，以便您可以持续改进产品、团队和工作环境。
Scrum框架由Scrum团队以及与之相关的角色、事件、工件和规则组成。框架中的每个部分都有其特定的目的，其对于Scrum的成功与使用是至关重要的。Scrum的规则把角色、事件和工件组织在一起，管理它们之间的关系和交互。
- Scrum团队
在开始介绍Scrum的组织架构之前，让我们先看一个小故事。
一天，一头猪和一只鸡在路上散步。鸡对猪说：“嗨，我们合伙开一家餐馆怎么样？”猪回头看了一下鸡说：“好主意，那你准备给餐馆起什么名字呢？”鸡想了想说：“叫‘火腿和鸡蛋’怎么样？”“那可不行。”猪说：“我把自己全搭进去了，而你只是参与而已。”
这则故事应用在敏捷开发中，用来说明不同角色的职责。在Scrum过程中，“猪”是在Scrum过程中全身投入项目的各种角色，他们在项目中承担实际工作；“鸡”并不是实际Scrum过程中全身投入的一部分，但是必须考虑他们。
Scrum团队由一名产品负责人、开发团队和一名Scrum Master组成。Scrum团队是跨职能的自组织团队。自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来指导。跨职能团队拥有完成工作所需的全部技能，不需要依赖团队之外的人。
以上关于Scrum概念以及团队角色职责部分内容描述，摘自《2017 Scrum Guide》。
关于Scrum的更多详细信息，以及管理实践方法，可参考《Scrum Guide》。
- 使用CodeArts添加项目成员，并配置成员角色
简单了解Scrum框架以后，我们就可以开始组建项目团队了。
在CodeArts中，每个项目中有多个项目成员，但由于每个成员在项目中担任的职责不同，需要通过成员角色给予区分，并在操作权限上做出相应的体现。
- 单击。
项目的基本信息列出了项目名称，项目描述，项目类型，创建时间，创建人。
项目描述可以根据情况进行修改。
- 单击，可以添加新的用户到这个项目中。
CodeArts提供以下两种添加用户的方式：
添加方式
说明
添加成员
添加本企业租户下的成员，如果成员不存在可以为其创建子用户。
通过链接邀请
邀请非本企业租户下的成员。
- 添加进项目中的成员，可以点击成员信息右侧的操作按钮，对成员角色进行编辑。
- 项目角色一共有6种，分别对应不同的操作权限，项目的管理人员可以根据项目实际情况对成员角色进行分配。
- 单击。
规划项目并管理需求
- 项目情景
刚刚接到业务部门的最后通牒，要求月底必须上线 【门店网络查询功能】，可以在凤凰商城中查询各个门店的相关信息。
应该如何对此功能模块进行规划呢？
首先让我们看看在敏捷的项目中，应该如何进行项目规划以及需求的制定。
- 如何拆分需求
需求通常以“Epic>Feature>Story”进行层级拆分：
- Epic通常是公司重要战略举措或者巨大的需求，例如“凤凰商城”对于“无极限零部件公司”是一个与企业生存攸关的关键战略措施，就是一个Epic。
- Feature通常是在Epic之下，对用户有价值的功能，用户可以通过使用特性满足他们的需求。比如“凤凰商城”的 “门店网络查询功能”，特性通常会通过多个迭代持续交付。
- Story通常是对一个功能进行用户场景细分，并且能在一个迭代内完成。Story通常需要满足INVEST原则：
- Independent（独立的）
- Neogotiable（可讨论的）
- Valuable（对客户/用户有价值的）
- Estimable（可估计的）
- Small（小的）
- Testable（可测试的）。
- Story又可以继续拆成Task。Task是实现层面的，例如准备环境，准备测试用例等，都可以是完成Story的细分任务。Task无需遵循INVEST原则。
战略、功能、需求、任务等的在具体项目中很难进行归类，也可以简单的按月、周、日、小时为单位进行判断，通常一个Epic可能会跨多个Release交付，Feature跨多个Sprint，Story需要在一个Sprint中完成，而Task通常是更短小以小时至多以天计。
- 使用Scrum项目模板进行项目规划，并管理Epic和Feature
在CodeArts中，可以使用提供的“需求规划”功能以思维导图的模式完成需求从“Epic > Feature > Story > Task”的创建以及管理。
- 需求规划
- 打开凤凰商城项目，单击，项目规划视图以树形结构列出了需求从“Epic > Feature > Story > Task”的逐级关系。
- 创建新的Feature， 在凤凰商城Epic上单击“插入子主题”。输入标题“门店网络”，回车保存。
- 按照同样的方式，完成Story“作为用户应该可以查看、查询所有门店网络”的创建。
- 项目规划折叠
为了更清晰的展示规划视图，不同用户角色可以根据实际需求，展开/折叠对应级别的列表。
例如，某用户角色只关心Feature级别的列表，单击“Feature”旁边的
完成折叠。
- 导出项目规划
CodeArts还支持将项目规划导出到Excel，以“条目化”的方式查看以及管理。单击页面右上角“导出”完成。
- 需求规划
- 需求描述：以用户故事来描述需求
维基百科上说，用户故事的目的在于以更快的速度、更少的消耗来应对现实世界需求的快速变化。
在CodeArts，我们以用户故事的形式来记录需求。华为以往也用需求规格说明书以及用例的形式，但这样的方式非常乏味、容易出错、编写耗时，而且说真心话没人愿意去读。
采用用户故事的好处在于：
- 用户故事强调对话而不是书面沟通。
- 故事更容易被客户和开发人员理解。
- 用户故事大小适中，适合做迭代计划。
- 用户故事鼓励重要的事情先做。
- 鼓励推迟决策，延迟考虑细节。
- 支持随需求而变的开发。
用户故事将重点从以往的文档转换到了更实用的对话。面面俱到的文档看上去固然很美，但费时费力而且还没人去看。用户故事取而代之，以通过与客户沟通来获取需求，通过与用户协作来澄清需求，通过频繁的发布来确认需求。
用户故事通常按照如下的格式来表达：- As a <Role>, I want to <Activity>, so that <Business Value>.
作为一个<角色>，我想要<活动>，以便于<商业价值>。
三段式的用户故事，核心是从用户角度出发描述问题，站在用户的立场思考问题。
好的用户故事讨论的是为谁做和为什么做，而不仅仅是做什么。作为Who，我想要What，以便于Why。有了Who、Why、What的信息，How就变得呼之欲出了。
以往我们上来就写需求的，往往注意到的是What（干什么），却忽略了Who（为谁做）以及Why（为什么做）。
而Who>Why>How>What的逻辑模式，恰好也是影响地图的结构。有关影响地图，请阅读文章《影响地图》。
- CodeArts需求编辑操作
在CodeArts中，我们可以通过工作项管理模块，进入每一个工作项中，单独编辑该工作项的详细信息，并可对工作项进行详细的用户故事内容描述。
- 单击，单击待编辑的Story名称。
- 修改Story描述信息、开始日期、结束日期、预计工时、优先级、重要程度字段信息，单击“保存”按钮完成修改。
此外，CodeArts支持工作项模板，在中，可以看到如何将用户故事的三段式预置在Story的工作项模板中，也可以根据需要自行定义描述信息。
同时，CodeArts也遵循3C原则。卡片是用户故事的展现形式，用户可以切换到迭代视图的卡片模式，通过拖动卡片完成状态更新。
制定计划
在对项目的需求进行简单的规划后，我们就要进入具体的开发环节。而在开发之前，当然需要对即将开展的工作进行计划。
那么，在敏捷的开发模式中，计划是如何制定的呢？
让我们以CodeArts这个产品为例，一起来看看CodeArts作为一款产品是如何制定它的开发计划的。
- 两级项目计划
计划是演进的，试图在项目一开始制定“完备”的甚至是“完美”的计划是不现实的。做计划的目的之一是减少风险，但在信息最少的项目初期阶段做出最重要的决定是不切实际并且风险巨大的。
敏捷计划的模式是渐进式的，一开始只规划一个大的方向，并制定最近1-2个迭代需要构建什么以及何时完成的计划。随着项目的进展，新特性不断的增加并交付给客户，团队不断的获取有关产品、技术、市场、用户相关的信息，新的迭代计划也在不断的演进，但依然是经济并且现实的只规划最近的1-2个迭代。在此过程中，通过不断的交付价值与沟通反馈，建立团队内部彼此之间以及团队与客户之间的沟通、信任与信心。
在CodeArts中，计划是分为两级的，第一级是大的发布计划，以月度、季度、年度为粒度，我们称之为路标；第二级是具体的迭代计划，以周或双周为粒度，这是团队开发及交付的节奏和心跳。
针对Product Backlog进行分层，近期要做的拆分到Story级别，例如2-3个迭代内的；中期要做的拆分到Feature级别，例如3个月之内的；长期待定的就留成Epic，例如3个月以上的。
- 产品发布计划
CodeArts整体是一个DevOps平台，包括需求管理、代码托管、流水线、代码检查、编译构建、部署、测试计划、发布等多个服务，每个服务每周固定都会有一个上线版本，特殊情况可以做到按天的发布周期。在此情况下，将相关的新功能放在一个发布计划中依然是有必要的，发布计划就是产品的Roadmap路线图，在华为我们称之为路标。
我们会以年为单位制定大的路标进行对齐，同时拆分到每个季度，路标代表我们产品演进的方向和关注的重点，是中长期的目标。目标一定会发生变化，所以路标会定期进行调整，体现了我们对市场变化的判断以及对客户反馈的响应。
目前在版本历程中，我们以双周为单位定期发布产品的Release Notes。Release Notes很重要，是产品新特性的发布公告，是一种事后的告知方式。
还有一种事先的预告，即Release Plan产品路标，可以让客户有所预期甚至提前获得反馈。
计划是一个承诺，是一个目标，计划的目的是为了更好的响应变化；制定计划很重要，但盲目遵循计划就没必要了；更重要的是做计划的过程，而不是计划本身。
敏捷也好，DevOps也好，都是为了应对快速的市场变化，以及更好的响应需求的变化。产品的发布计划也是如此，没必要盲目依从，也不会100%都达成（这种情况只能说明目标太没野心了），路标需要定期检查与调整；路标的发布同时也是一种获取反馈的机制，客户可以提出反馈意见，例如对在规划发布的一个功能非常喜欢或是非常不喜欢，都可以通过意见反馈系统进行反馈，产品会基于反馈信息进行判断进而调整发布计划。
- 迭代计划
一个发布由多个迭代组成，每一个迭代都要有具体的目标，迭代过程需要度量迭代速率，团队要根据自己的速率以及工程能力确定迭代长度。
CodeArts目前的迭代长度为一周，由于设计与开发的依赖关系，所以我们的设计迭代与开发迭代会有一个错位，UCD设计会超前一周完成低保真及高保真设计，随后开发会进行前后端的开发工作。
在迭代计划会议上，产品经理PD对高优先级需求进行串讲，团队提出问题，并充实或调整产品Backlog的优先级，进而设定Sprint目标。根据团队速率，选择进行Sprint Backlog填充。以目前一周的迭代长度而言，这一过程大概会进行1-2小时。
通过CodeArts提供的迭代管理，可以帮助您快速的制定迭代计划、管理和追踪相关工作进度。
- 迭代创建以及管理
- 单击，进入迭代管理视图。
- 单击“新建迭代”，输入迭代名称，根据实际情况设置迭代日期，单击“新建”按钮。
- 迭代规划
- 打开，系统将列出所有未计划的工作项列表。
- 用鼠标拖动Story到迭代中。
- 任务分配
- 单击Story名称，在右侧画出窗口中选择“子工作项”页签。
- 输入工作项标题，单击“确定”按钮。
- 迭代创建以及管理
