体系化敏捷管理架构（二）

二、概述

         敏捷（Agile）是一个方法论，可以适用于生活中的方方面面。而2000年前的荀子在《劝学篇》中也论述了相关的问题。个人认为《劝学篇》所阐述的深度远大于敏捷方法论。

1、下面先说一下体系化敏捷管理的架构原则

1）独立性原则

　　这是一套提出问题、分析问题并解决问题的做事方法，和公司的人事制度、管理制度等没有直接关系。和质量管理体系等也没有横向关系。和做事的内容没有关系。

2）结果重要原则

　　做事必须要有结果，没有可归档文档及实物等于没有做或没有做完。

3）弱规划原则

　　若规划并不是指不要做事先的计划，而是不要做没有实际基础的规划以及无法现在做出的规划上浪费时间。这有两层含义，一、是指可以利用以往的经验和架构做大致规划。二、等完成了部分目标有了基础再规划下一步细节。对需求的拆分不需要一次性拆解完毕，一般逐步拆解。

4）需求不得随意灭失原则

　　在确定要做一件事后，需要对原需求评估拆分，原需求仍存在，与拆分后的需求共存，称为“需求挂起”。拆分后的需求流转后需要继续拆分的，则父拆分的需求和子拆分需求共存。需求不能再拆分后，成为需求终端，满足需求后，可以灭失。所有子需求满足后，父需求才能灭失。

5）及时变更原则

　　无法完成的需求终端，需及时关闭，并提交原因报告进行评审。评审后，由父需求诞生新的需求终端继续完成、由父需求诞生新的需求终端并改变需求内容或由父需求诞生新的需求终端先解决关闭原因。这个过程称为“需求变更”。

如关闭父需求必须，从关闭子需求开始。可见父需求不得随意关闭，一般建议选择变更需求。

6）评审退让原则

　　当一个需求不能完全或完美实现（大部分情况），采取评审退让原则，关闭该需求，并可诞生新需求用于补充原先的不足。新需求可以是原父需求的子需求，也可以和原父需求无关。评审退让以让其他阻塞需求得以尽快实现为主要目的。

7）不可退回原则

　　需求流转或指派后不得退回需求方，必须执行。如需求不明确或缺乏实现基础，处理人需积极应对，以书面文档方式，提交结案评审；或可以以此需求为父需求诞生子需求要求相关方（可以是父需求提出方）完成缺失的实现基础。

8）评审准入原则

　　原生需求（没有父需求）诞生，需经过评审，批准后才能流转。

9）需求方最大原则

　　需求提出方不得被排除在评审外，并有评审一票否决权。非原生需求的父需求持有方（需求实现人）拥有对下属所有子需求的最高变更权。

 2、体系化敏捷管理的流程

         1）总流程

 

 

         　　总流程图中说明了原生需求与其他流程之间的关系。原生需求是一个比较特殊的需求，特殊在它是一切的开始，在完成需求前需要进行立项评审，是唯一种需要立项和结案两种评审的需求。

         2）原生需求审批流程

 

　　3）拆分需求流程

 

 

　　　　所有子需求终结或调离，才能关闭父需求。子需求调离指子需求成为原生需求，这种情况出现在产品迭代的情况下，子需求按需要升级 为原生需求。

         4）需求变更流程

　　　　　子需求变更，需要回到父需求，由父需求执行者提交该子需求终结原因，如需要从父需求拆分出新的子需求流转。新子需求的内容可以与被终结的子需求相同（重新流转给执行人），也可以是其他内容（新方案、替代方案等）。

         5）满足需求流程

                   正常情况下，通过评审后需求得到满足。

                   如父需求强制要求结束子需求，子需求仍需提供评审报告，进行评审，无论需求完成度是多少。

                   发现子需求无法完成，子需求仍需提供评审报告，进行评审，无论需求完成度是多少。

                   子需求无法完成走变更流程的，向父需求提供变更要求，同样需要供评审报告，进行评审。特殊情况下因为父需求有对子需求的一票决定权，可简化评审流程，对需求进行变更。