agile-development-management.md

1　价值交付管理

价值交付管理包括需求工件、需求活动两部分内容，体现需求管理过程中的分析、测试、验收三个阶段。价值交付管理主要体现在各个环节中使用敏捷方法探寻用户（客户）问题和诉求、业务价值、并定义有效产品功能的能力，适应需求变化的能力，快速验证反馈的能力。

1.1　需求工件

需求工件是指对需求和用例的管理，是产品经理和开发团队将用户故事的验收标准和需求测试用例进行关联、验收产品功能是否满足用户故事要求的过程。主要由以下四个部分组成：

1）需求内容与形式：需求内容的分析是探索问题核心相关事项的过程，这一过程需要形成足够小的需求条目，如：用户故事。用户故事是一种有效的需求形式，它描述用户的业务场景及用户在场景中的活动。可以在开发过程中对其进行评估、不断细化；

2）需求测试用例编写：编写需求验收标准，形成测试用例的过程；

3）需求测试用例验证：需求测试用例指导需求开发，验证产品功能的过程；

4）需求测试用例管理：建立需求与测试用例的统一管理库，持续的使用和优化。

敏捷开发管理中的需求与工件环节，根据以上四个部分所能达到的不同成熟程度，可分为以下5个等级，如表2所示。

表1　需求工件

级别	需求内容和形式	需求****测试用例编写	需求测试用例验证	需求测试用例管理
1	需求分析形成需求文档，作为需求提出方和实施方之间的契约。（有需求）	测试用例与需求相互独立，测试用例在设计结束、代码开发阶段完成。	无。	测试用例在需求功能测试完成后没有做归档，无法重用。
2	同上，需求文档有明确的格式和规范要求，便于各方理解。（规范化）	同上，且建立测试用例与需求之间的关联，测试用例在需求分析结束，设计阶段完成。	同上，且测试用例在发布线上环境前全部验证通过。	同上。
3	同上，有清晰的层级关系（史诗-特性-用户故事），且有分类管理（功能需求，非功能需求，性能需求）。用户故事符合INVEST标准：a) 用户故事是独立完整的；b) 用户故事是可协商并细化的；c) 用户故事是有业务价值的，能做价值评估；d) 用户故事是能评估工作量和优先级的；e) 用户故事是足够小的，例如：在1-2日内能完成；f) 用户故事是可测试的。（可管理）	同上，且产品需求在最初始阶段能进行实例化、形成验收标准，成为测试用例的依据。测试能和开发并行工作，形成测试用例。	同上，且开发能通过测试用例进行自测，有部分自动化测试。	同上，且测试用例作为软件资产管理，所有测试用例验证通过后，方可进行线上功能发布。
4	同上，且有挖掘和分析需求价值的敏捷活动。例如：典型角色分析、影响地图、用户故事的层级化拆分等。（价值探索）	同上，建立测试用例评审机制，确保测试用例的质量	同上，自动化测试程度较高。	a) 同上，且测试用例在产品迭代更新中一直保持完整和准确。b) 所有的功能上线都以测试通过用例验证为目标，每次迭代上线都必须执行沉淀下的所有的测试用例，直到验证和修复通过才可上线。c) 需求测试用例无需重建就能为产品功能回归验收时使用。
5	同上，且有用户反馈收集渠道持续优化需求价值。（持续优化）	同上，建立测试用例优化机制，不断完善测试用例	同上，且建立机制优化测试过程	a) 同上，且应建立企业级可视化便捷的平台，管理包含测试用例的需求文档，可以通过需求文档查看产品的全貌。b) 需求提出人、最终使用人、产品经理、开发运维人员可依托平台进行更好的沟通和协作。

1.1.1　需求活动

需求活动包括需求分析、需求验收两个部分，需求分析主要是指需求提出方和产品经理之间明确产品需求的活动，是产品研发运营一体化的初始阶段，把产品需求具象化，形成待办事项列表的过程。需求验收是指产品经理、需求提出者和最终用户对产品的功能验收，要求能对需求进行快速测试、快速确认、快速反馈、快速优化。本节的需求验收，仅是指功能验收，非功能测试不在本节的范围内。需求活动包括以下五个方面的工作：

1）需求分析协作：需求分析是各个角色沟通协作形成需求用例或用户故事，并细化的过程，协作过程中各角色深入持续参与；

2）需求管理方式：需求分析后的用户故事应包括用户需求所涉及的所有事项，统一管理并按照业务价值由高到低排定优先级，并依据其形成产品研发路线图；

3）需求验收的频率：指不同角色对需求功能验收的频率，频率越高效果越好；

4）需求验收的范围：指需求验收应尽量具备有业务价值的端到端的验收；

5）需求验收的反馈效率：指需求验收的结果准确、快速的反馈到开发团队的过程的效率。

敏捷开发管理中，需求活动根据以上五个方面所能达到的不同程度分为以下5个等级，如表3所示：

表2　需求活动

级别	需求分析协作	需求管理方式	需求****验收频率	需求验收范围	需求验收反馈效率
1	a) 需求提出方、需求分析人员在完成需求文档的编写后离场，开发团队按照文档进行设计开发。b) 有变更流程，需求提出方、需求分析人员可以通过流程变更需求内容。	需求有归口统一管理。	在项目过程中，有多次验收测试。	项目最终上线后，需求提出者或最终用户应对全量功能进行验收。	有验收测试流程，能把结果反馈到产品经理和开发团队。
2	同上，且在用户故事进入开发周期前，由产品经理、需求提出方、开发团队一起细化用户故事。	同上，且产品经理使用产品待办列表统一管理用户故事，通过用户故事优先级排入发布计划。	同上，且产品研发有稳定的迭代和有计划的交付，每次交付都应有验收。	同上，且在每次交付验收时，产品经理应对团队的交付成果进行验收。	同上。
3	a) 同上，且在需求收集、分析、开发、上线运营的任何阶段，需求提出方、产品经理、团队成员、运营人员、使用者等各角色都可随时对用户故事进行细化。b) 当发生规模型产品研发情况，各个团队各角色能共同参与用户故事细化。	同上，且产品待办列表应符合DEEP原则：1）适当的详细描述的，优先级越高越详细明确；2）用故事点进行估算过大小的；3）随着产品演进不断涌现和变化的；4）优先级从高到低排序的。当发生规模型产品研发情况，应建立跨团队的产品待办列表，迭代待办列表。	同上，在跨团队产品里，有跨团队的产品验收，并要求在每个交付周期都须进行。	同上，且需求提出者、最终用户或用户代表应能在每次交付进行验收。	同上，且对验收测试应有快速的反馈和优化流程，保障反馈能在进入产品待办列表，且根据优先级进入研发。
4	同上，且应建立改进需求分析协作的机制：a) 应建立特性型的端到端产品研发运营团队，减少跨组织协作的必要性。b) 应建立产品级回顾改进机制。例如，建立运营驱动需求的体系，在产品演进过程中，不断涌现需求，能不断优化和调整待办列表的顺序。c) 当发生跨团队的产品研发情况，应建立需求分析协作机制，可跨团队进行需求拆解细化。	a) 同上，且产品经理对提出的需求在产品演进过程中持续细化和演进，形成场景化驱动和价值驱动的发布规划（如用户故事地图），以保持产品待办列表的价值最大化。例如，采用精益产品的方法、影响地图、MVP等敏捷方法。有协作型用户故事沟通工具、产品待办列表管理工具。b) 有数据收集和大数据分析需求价值和评估的工具，例如：能收集用户交互操作的工具。	同上，建立分层快速验收机制1）产品经理及时验收，在开发完成功能后，提交测试前；2）迭代验收；3）小范围用户验收；4）企业内众测；5）外部灰度/众测。	同上，且在迭代过程中，应有通过原型确认、AB测试、灰度测试等方法进行验收测试，提升验收效果。	a) 同上，且建立产品级的业务价值验收反馈流程，在产品推向市场后，能快速响应用户反馈。b) 通过反馈发现迭代中的沟通、设计等问题，并进行持续改进。应有快速的反馈和优化流程和工具，能收集验收结果，并且能快速转化为迭代需求。
5	同上。	同上，且应建立需求与企业级活动关联，把企业战略和目标通过愿景、目标、关键结果、任务、评估、反馈等环节进行分解，实现企业、团队、个人三个层次对齐，达到需求的业务价值最大化。	同上。	同上。	同上，且应建立企业级大数据分析工具，能抓取用户行为数据，通过大数据分析，在用户功能验收和用户体验时作为辅助决策依据，持续优化改进。

2　敏捷过程管理

敏捷过程管理是产品经理、研发团队以及与产品相关的干系人围绕业务价值交付进行的软件研发过程，包括价值流、仪式活动两个部分，要求产品经理、团队以及与产品相关的干系人建立以尽早和持续地交付有价值的软件为目标，通过高效的沟通方式、高效的可视化的工作流程、有效的度量和快速反馈机制，实现软件研发业务价值最大化。

2.1　价值流

价值流是指产品经理、研发团队在软件研发过程中将软件产品转化为业务价值的能力，包括按照用户故事地图按需交付可用的软件，交付的软件能准确反映需求提出者的诉求，软件质量、用户体验能让使用者满意，软件运行结果能快速反馈并持续优化提升，如表4所示。

价值流主要包括以下四项内容：

1）交付与需求：指价值交付过程中提升交付节奏和效率的措施。

2）交付质量：指产品价值交付的过程中，需要控制价值交付质量。

3）交付反馈与度量：指建立了对价值交付的反馈机制。

4）价值流动：从产品价值交付角度，通过交付速度、频率等度量指标的优化，不断提升交付的效率，实现开发任务的拉动式管理。

表3　价值流

级别	交付与需求	交付质量	交付反馈与度量	价值流动
1	研发团队的软件交付以符合需求文档内容为基准，允许产品经理在项目全部交付前变更需求。	软件验收方和研发团队有约定软件质量指标。	有交付验收测试流程，能把结果反馈到产品经理和开发团队。	在职能团队间通过契约的方式交付上下游间的交付物。
2	同上，且产品经理、研发团队采用敏捷的方法提升交付价值：a）采用用户故事编写需求，提升需求的业务价值；b）产品经理、研发团队在交付迭代中持续沟通并细化用户故事，例如：召开需求澄清会；c）产品经理在迭代交付上线前进行需求验收，保障交付符合需求要求。	同上，且软件质量指标包括过程质量指标、结果质量指标。	同上，且需求提出者、使用者或使用者代表都参与验收。	a) 同上，且建立团队工作进展可视化的工具，能通过工具展示产品需求提出到开发交付的全开发流程，可视化用户价值，可视化瓶颈问题。b) 团队进行用户故事规模估算，具备各团队交付速度的参考值。
3	a) 同上，且有稳定的交付节奏，根据产品待办列表的优先级持续交付。b) 当发生规模型产品研发情况，所有团队的需求和交付计划都是统一协同的。	同上，软件质量内建到了软件开发过程中。	同上。	同时，且具备工具支撑计划安排活动，能自动识别任务间的依赖，支持团队间依赖管理，能实现任务的自动流转等,对于需要进行团队对齐的情况，能自动实现团队的对齐。
4	a) 同上，且有提升需求价值的敏捷活动。例如：典型角色分析、影响地图等。b) 有提升交付优先级的价值最大化的敏捷活动。例如：精益产品的方法、用户故事地图、MVP等。	同上，且建立产品级回顾改进机制，在每次交付迭代都开展回顾改进活动，包括根据交付质量优化软件研发过程。	同上，且建立产品级回顾改进机制，在每次交付迭代都开展回顾改进活动，包括根据用户反馈优化软件研发过程。应具备支撑软件交付质量、交付速度的度量评估工具。	同上，且通过平台能可视化交付速度等度量指标，对发现阻碍问题，团队能通过措施进行改进，并能形成标准化的团队协议或流程将改进成果固化，做到持续改进。
5	同上，且软件交付节奏是根据业务的需求持续部署，按需发布。	同上，且有工具对改进措施进行跟踪，并能形成标准化的团队协议或流程将改进成果固化，做到持续改进。	同上，且有工具对改进措施进行跟踪，并能形成标准化的团队协议或流程将改进成果固化，做到持续改进。	同上。

2.2　仪式活动

通过建立价值流动的管控机制，可视化地管理价值流动，控制流动节奏，建立反馈机制，不断提升价值交付效率。包括各类计划会议、评审会议等。主要包括以下三项内容：

1）交付计划：是指需求任务和产品增量的实现计划。

2）交付活动：为了能快速有效的交付业务价值，而进行的相关会议、评审等活动。

3）人员组织：是在仪式活动中团队组织的形态要求，合作方式。

根据以上三个方面所能达到的不同程度分为以下5个等级，如表5所示：

表4　仪式活动

级别	交付计划	交付活动	人员组织
1	产品计划按照需求分析、开发、测试、发布上线等划分为不同阶段。需求变更由产品经理和团队商量确定。	零散的采用敏捷相关的活动，能进行多次交付，相关干系人能参与到交付过程中。(初始)	职能型团队
2	a) 同上，且产品待办清单中用户故事内容完备、优先级确定，用户故事间的依赖关系确定。团队能从产品待办列表中根据优先级确定将要开发的内容。b) 产品经理和团队约定计划变更的流程，产品经理提出变更请求后，与团队沟通，共同决定是否进行计划变更。发生需求变更时，团队成员决定可以置换的用户故事。	有明确定义规范化的敏捷交付流程和活动。(定义)	明确了产品经理、敏捷教练、团队三类角色，三者一起工作。
3	同上，且产品经理和团队围绕交付价值共同制定产品需求计划，控制交付的节奏，形成稳定的价值交付速度。	同上，且团队建立灵活应对变化的机制，减少变化带来的影响。(灵活相应)	同上，且建立特性团队，保持业务价值交付的独立性。
4	同上。	同上，且具备跨团队的计划活动，能识别出团队间存在依赖的用户故事，约定用户故事的优先级，对于需要对齐发布周期的团队，进行发布周期的对齐。能通过交付评审会议进行交付结果验收。(规模化)	同上，且通过建立和相关干系人一起工作的机制，变外部沟通为内部沟通，提升协作效率。
5	同上，且通过不断优化改进，实现灵活规划，按需交付。敏捷团队围绕公司战略工作，在产品规划、研发、发布各层面具备灵活反应的能力，可支撑业务价值驱动下灵活的计划变更，建立应对风险的能力。	同上。	同上，且企业采用扁平化的敏捷团队组织架构，赋予团队围绕产品自组织、自管理的权力，包括但不限于产品规划、建设、运营、人力、绩效、核算等。敏捷团队建立以业务价值交付为核心、以运营为驱动的工作模式，企业为团队提供IT基础设施、基础管理等支持。

3　敏捷组织模式

敏捷组织模式是指团队在研发过程中的角色定义、角色能力以及之间的协作，团队结构的工作方式、团队间的协作模式等方面的要求，主要从敏捷角色、团队结构两个方面进行定义，如表6所示。

3.1　敏捷角色

敏捷角色主要是指产品经理、团队、敏捷教练等角色间的职责分工、能力提升、协作方式，角色都能以价值交付为目标，持续提升交付效率。主要包含以下三项内容：

1）角色职责：定义在敏捷团队中的不同角色及职责。

2）角色能力：对团队成员角色能力的要求。

3）角色协作：定义了团队内外不同角色间的工作协作模式和要求。

根据以上三个方面所能达到的不同程度分为以下5个等级，具体如下：

表5　敏捷角色

级别	角色职责	角色能力	角色协作
1	按照开发流程的上下游关系进行分工。	以某项专一的专业技术能力为主。	每个角色关注自身的工作，根据开发流程的上下游关系进行协作。
2	a) 同上，且每种角色职责中包括业务价值和架构价值的内容（例如：开发人员关注需求的最终目的。测试人员在测试过程中关注用户使用的便捷性）。b) 须有产品经理角色。	同上，且每个角色关注自身专业技术之外的角色技能。	a) 角色间的协作有敏捷实践（例如：站会、计划会等）。b) 角色间有跨边界的合作。
3	同上，且须有敏捷教练的角色，该角色可以是全职，也可以兼职。该角色引导团队进行敏捷实践，驱动敏捷实践的运转。	同上，且产品经理能够用敏捷实践进行工作（例如：用户故事、影响地图等）。团队成员，团队内每个角色能在完成自身工作的同时，当其他角色的工作发生瓶颈时，能快速变更角色完成该项工作。	同上，且团队能关注整体交付进度，能快速发现交付瓶颈，能通过各角色协作解决瓶颈问题。
4	a) 同上，且敏捷教练角色弱化，在没有敏捷教练的情况下，团队敏捷实践有效运转。b) 角色分为产品经理和团队成员两种，团队成员角色分工可以有，但是角色职责不再固化，全部都以价值交付为目标进行合作。	同上，且团队成员能力趋于同质化，每个成员有强项，具备跨功能或角色的能力。	同上。
5	同上。	同上	同上，且团队能在协作模式、工作方式等方面形成可以借鉴或推广的经验积累，为其他团队提供指导。

3.2　团队结构

团队结构在研发过程中以最小化的功能团队，以共同的价值观，通过可视化的方式，紧密合作，实现业务价值的快速交付。如表7所示，主要包括以下三项内容：

1）团队组成：定义团队角色组成，核心是强调价值交付的最小实现单元。

2）团队工作模式：用敏捷的工作模式管理团队，形成一致的约定、目标和价值观。

3）团队间协作：重点描述敏捷团队间协作完成价值交付，强调计划对齐和有节奏的交付。

根据以上三个方面所能达到的不同程度分为以下5个等级，具体如下：

表6　团队结构

级别	团队组成	团队工作模式	团队间协作
1	按系统功能模块或专业职责进行划分。	无。	团队间为完成最终目标有相互协调的机制。
2	团队足够小，在10人以下。	a) 团队有达成一致的约定，团队成员能自觉遵守，所有成员能理解团队工作目标。c) 有敏捷实践尝试。	a) 同上，且建立可视化的产品开发过程（如：看板、燃尽图等）。d) 产品经理和团队进行面对面的沟通，随时可以了解研发进度。e) 团队间能通过敏捷实践进行沟通协作（如：跨团队的敏捷计划会议、Scrum of Scrum等）。
3	同上，且组建特性团队，能独立完成价值交付。	同上，且有敏捷教练，敏捷教练引导团队进行敏捷实践，团队成员能熟练使用敏捷实践进行工作，认可团队敏捷价值观。	a) 同上，且产品经理和团队具有共同的交付价值诉求，共同围绕着可交付的软件进行工作。共同遵守团队约定。f) 建立多级产品经理制度，围绕产品价值紧密合作。g) 围绕客户交付价值，交付可工作的软件。客户、用户参加产品验收。
4	同上，且持续提升团队能力，具备跨产品或业务的交付能力。团队成员稳定。	同上，且团队不再需要敏捷教练进行引导，完全自组织、自管理。通过持续改进，消除瓶颈和浪费。	a) 同上，且团队和上下游进行频密良好的协作和沟通。h) 建立团队间的回顾改进制度，并能完成改进。
5	同上，且组建价值交付能力够足够强的团队，通过技术架构的突破，实现组织任何产品或项目能够在尽量少的团队（1-2个团队）团队内实现价值交付。	同上。	同上，且由纵向分割的团队间交付节奏对齐的协作，转变为由能力提供方提供能力给业务研发使用的模式。能力提供足够丰富，使得业务开发能够在独立团队内完成业务价值交付。消除了产品业务跨团队的协作。