开发者学堂课程【研发效能提升和敏捷实施36计：基于业务场景、组织和规划】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/615/detail/9382
基于业务场景、组织和规划
内容目录
一.总体体系
二.回顾前两次课程
三.基于业务场景、组织和规划
四. 在问题域拆分需求：建立敏捷和持续交付的基础
五. 按业务场景组织需求：做到既见树木也见树林
六. 依据业务价值规划交付：迭代的交付价值，而非增量
七.总结
一.总体体系
研发效能提升和敏捷实施36计一共分为五大模块：精益创新实践；精益敏捷需求管理；精益和敏捷协作；持续交付实践；设计和代码实践。
第二个模块精益敏捷需求管理是整个研发效能最核心的的一个部分。
精益创新实践中包含了目标管理和业务规划；产品方案和MVP设计；业务验证和数据分析。
精益敏捷需求管理中包含了价值和业务分析；需求设计和迭代规则；需求分析和澄清。
精益和敏捷协作中包含了端到端拉通和可视化；过程和价值流通管理；度量反馈和持续改进。
持续交付实践中包含了测试守护；环境及基础设施；持续集成及部署；安全、运维。
设计和代码实践中包含了代码技术实践；代码资产评价和优化；领域驱动设计及微服务。
其中精益敏捷需求管理；精益和敏捷协作；持续交付实践；设计和代码实践这四个模块直接影响了流动效率，资源效率和质量保障，保证其顺畅高质量交付，从而再间接影响利润，用户增长，客户满意度和口碑，运营效率。
流动效率，资源效率和质量保障指研发效能；利润，用户增长，客户满意度和口碑，运营效率指组织效能。
精益创新实践是直接影响了组织效能。
精益敏捷需求篇分为五次课程：1.用户问题出发，设计产品和服务。
2.用户问题出发，设计产品和服务。
3.聚焦业务目标，挖掘产品需求
4.以终为始，高效分析和澄清需求。
第五次课程就是对前面四次课程的一次总结。
服务于用户和业务目标，良好拆分，组织和规划，并被有效分析和澄清的高质量需求。
二.回顾前两次课程
第一次课程讲了怎么从用户目标和用户问题出发去设计产品与服务。第二次课程讲了光用户目标还不够，需要有一个完整业务的一个模式，所以聚焦业务目标，挖掘产品需求。第三讲的内容就是指有了这些需求，怎么去拆分它、组织它、解决它。
第一次课程讲从用户目标出发，这个产品究竟要解决用户什么问题，引入了一个概念，叫 JTBD，指用户在特定的角色，特定场景下雇佣产品是要完成什么工作，解决什么样的问题。
定义了这个目标以后，从组织的角度来讲，就要设计产品的服务的一个蓝图；从用户的角度来看，需要给用户一个怎样的体验，怎么样的一个旅程来实现目标，这是产品设计的一个基准。基于这样的目标，就需要知道产品要做什么样的功能，这个旅程要提供怎样的差异化，比如说终值和峰值的体验，准备从用户出发来设计用户的体验旅程和服务蓝图。基于体验旅程和服务蓝图的差异化和目标来设计产品的功能。
用户旅程及体验等级和步骤如下图所示：
第二次课程讲了一个重要的概念和重要的工具，影响地图只是一个工具，因为是从精益创业循环做起的。就是说构建一个东西，一定要去不断的探索，开发一个东西去测量它然后认知它。为了做到这一点，要知道测量什么，就要找到正确的业务目标，所以就有了个模型，叫做关隘模型。
关隘模型就是指产品不同阶段要聚焦于不同的目标，比如说一开始是聚焦于共情和粘性，即用户认不认同这个产品；后面再聚焦收入，最后才会考虑规模化。这些就是不同的阶段要关注不同的目标，尤其是对于不同的业务模型，比如说双边模型还是电商模型或者是做内容的，它们在不同的阶段都有不同的目标，所以要聚焦于正确的目标。
基于这个阶段以及产品模型找到需要关注的目标，然后再基于这个目标去设计产品。为了设计这个产品，首先要找到实现目标的抓手，这个抓手往往就是对于怎样去影响用户的行为和认知，为此提供了一些行为模型，这些模型帮助去找到抓手，但这些模型只是模型，要切合业务实际的特征，才能设计正确的产品。基于这些抓手再去设计产品的功能，所以引入了 Why、 Who、 How、 What 这样一个称之为影响地图的概念。它背后的假设是通过影响用户的行为来实现目标，为了实现这样的影响，就要做这样的功能，所以功能是 What、影响是 Who 和 How、目标是Why。这样来帮助构建一个影响地图，这个影响地图仍然可以看到先做什么后做什么。先找到需求，做完了以后回到第一步精益创业循环去看这个目标实现了没有，验证影响有没有达成，目标有没有实现。不断的循环，不断的探索。关于精益创业循环或者说开发，测量，认知的的情况会在创新的部分来重点的讲。具体流程图图如下：
三.基于业务场景、组织和规划
上一讲的内容定义了产品的功能，这些功能可能有些大，也有可能是相对于零散的。今天就是学习怎么去组织这些功能，做成一个合理的产品发布规划。必须要基于业务场景或者用户的场景来组织和规划场景需求。今天会讲到一个工具，叫故事地图。如果对敏捷开发熟悉的话就已经有深刻印象了。
从三个方面来讲这次课程：
1. 一定要在问题域去拆分需求，它才能建立敏捷和持续交付的基础。
2. 按业务场景组织需求：做到既见树木也见树林。树木就是一个一个的具体的需求，森林是一个完整的场景。
3. 有了前面两个的基础，依据业务价值规划交付：迭代的交付价值，而非增量。
四. 在问题域拆分需求：建立敏捷和持续交付的基础
1.这是一个抽象性的概念，任何产品开发，不管是敏捷的模式，精益的模式还是传统的模式，其抽象的程度都是一样的。即用户有一个问题，需要给他一个实现的方案，这个实现方案往往是由产品来承载的。但是传统的方式和精益敏捷的方式是不一样的。就是这个过程是不同的，也就是说它们问题域到实现域映射的过程不同。
2.在软件开发中，一定会拆分，给一个大问题，一定要去分割它然后再去解决它。因为用户提供的往往是一个大的问题，但在传统开发里面，给一个命题：要做一个版本，要解决用户的问题，该如何去做呢？答案肯定是要先对这个问题进行分解，往往是在实现域进行分解的。想想做计划的过程。
来看看传统的方式的怎么样的，如下图所示：
为了做这个版本，为了做这个产品，需要影响哪些模块，就是图中写着M的小方块，其实就是软件模块，它们这些软件模块之间是有关联的，不是单独存在的。
分解完模块就要把这些模块分配给不同的人去做，比如：前端，后端，算法，交易，支付等等。这就是开发这些模块。开发完了这些模块之后不能直接去做功能测试，因为模块是一个技术的概念，单独的模块是不能承载功能的。开发完这些模块后要先进行集成，最后再去测试，然后再去交付所有的东西。因为在中间模块是不能单独交付的。
回顾整个开发模式的过程：在问题域先进行需求分析，然后进行构架设计，再进行软件开发，最后进行集成测试。这样的模式就是一个从上面往下流的模式，即瀑布开发模式。
如上图可以看出，这是一个从上到下流动的模式，这就是瀑布开发模式。瀑布开发模式的本质不在于阶段，而在于批量。 就是说，要批量的把需求分到各个模块，批量把这些它们完成以后，批量的开发和集成。
瀑布开发模式的问题是它的价值都集中在最后交付了，中间没有反馈。这些都能理解，还有最重要的问题就是：在这里面，开发人员看到的是局部，看到的是一个个的模块和代码。它们不能和用户建立心智连接。很难去理解用户问题。所看到的是后端的算法，交易和支付的过程，它们心智连接是打断的。
但对于互联网产品，不管是过去的互联网产品还是今天讲的产业互联网，跟用户建立心智连接，真正理解用户的问题是做出一个好的产品体验的基本前提。即使产品设计得很好，如果看不到用户的问题，那么体验就很难做到很好。
总结：如果在实现域去分解问题，就会发现其开发模式必然是瀑布开发模式。
3.如下图所示：
很容易看出，精益敏捷开发模式的解决方案就是在问题域分解问题。即：理解问题的需求，把需求进行拆分并且分批，然后把这些需求直接交付给一个完整的团队，一个跨功能的团队。这个团队不在于它是虚拟的还是实际存在的团队。它可能是说希望把这个团队变成一个长期存在的团队，它是跨功能和跨职能的团队。跨功能是指所有的能，就是说前端和后端所有的能；跨职能就是测试，开发都能跨。但是现实中这种有一些困难。这些团队面对的需求，当团队做完一波需求以后，可以有一个可交付的、可上线的、可运行的一个系统。再交付一个需求的话，这个系统就会变得更大，如此往复，不断的迭代的去演进这个系统。
在这里面就可以看出其必然是一个迭代交付价值。开发者和用户之间建立的心智连接，面对的是用户的问题，不管是内部用户还是外部用户，他们的心智连接是被打通的，称之为迭代交付价值。
总结：在问题域拆分需求，是敏捷和持续交付（迭代交付）的基础。需求的拆分方式很大程度上会决定精益敏捷的效果和研发模式。这是非常重要的一个基础和前提。
1. 拆分需求带来的挑战
（1）如何合理地拆分需求:以支持迭代的交付和反馈?
（2）如何有序组织拆分后的需求:看到需求的整体和关联?
(3)如何规划需求交付过程: 以确保合理的构建路径?
（4）如何确保架构的一致性:以降低技术风险?
（5）如何分析和澄清需求:以理清业务规则并达成一致理解?
在后面会解决上述问题。
五.按业务场景组织需求：做到既见树木也见树林
1.组织需求不仅仅是组织，也包括拆分。树木即需求；森林即需求之间的关系。
2.本次课程引入一个新的工具：故事地图。最重要的不是故事地图本身，而是其后面承载的内容。
如上图所示：
假设：需求已经拆分好了，图中带蓝色的卡片是一些需求，把它们扔在桌子上，应该怎么去组织它才能让它们与需求的关系更加清晰的展现出来。（此桌子指一个需求列表，列表是线性的）。在X,Y轴上怎么排列才能看得清楚。
X轴：业务流程，用户使用的过程。图中黄色的部分从左到右就是流程的步骤。
Y轴：优先级别。
3.有了这些基础，就可以对这些需求进行水平的切割。如下图所示：
第一部分是最基础的，它是一个可运行骨架，就是说我做完这个以后，产品的框架和结构就出来了。其作用就是驱动架构的选型，模块的划分，并且模块之间的关系和通信方式就显示出来了，称之为可运行的骨架。
第二部分就是按照业务场景来规划发布。比如：
第一个发布目标：内部上线，受控业务跑通，内部试用一下。
第二个发布目标：外部上线，支持完整实物交易链路。
注意：故事地图既是一个拆分需求的工具，也是一个组织的工具。
实例：
在这个地图里面，在线上提现这条线里面，只有一个需求：第二条线叫二级结算，它有多个需求，两者看上去很不平衡。一个需求少一个需求多。这是为什么？
答案：线上提现里面只有一个招商银行代付一个需求。这个系统是一个分销管理系统，就是说线上提现以前可能需要人工去打款，现在只需要做一个事情：招商银行代付。它就可以实现线上完整业务的流程。
二级结算很容易理解：除了和分销商，也可以和分销商的代理商去结算，所以账户系统交易，分销方式，计算配置都要改，所以需求就有很多个。
总结：每个横线上都应该是一个完整的业务场景。业务场景指能在特定场景下帮用户完成特定目标。业务场景的下面才是业务需求。场景在驱动需求。
比如：控制红绿灯是一个需求；做一个朝夕车道是一个场景。通过智能调控给特定车辆更高的路权是一个场景。注意：每个场景下面都需要一系列的需求。所以说是目标驱动。
如图，被框起来的是交易部分，在此之前还有更复杂的系统服务，运营支撑和店铺管理。面对这样一个复杂的产品就需要进行横向扩展，扩展完了以后再用一个层次转换。
六.依据业务价值规划交付：迭代的交付价值，而非增量
划分版本的方式有两种，一种是上面的图纵向切，按照步骤切；一种是下面的图横向切，按照一个一个的完整业务流程切。可以看出，第二种的方法比较好。
如图，从横向按照业务流程分为两个层次的。纵向的构成了一个交付规划。当把一些需求串起来的时候，一定是按照一个完整的场景来串的，这样的交付才是有意义的。而且从左到右按照业务流程组织，也更可能按照业务场景来组织它。在图的最下面可以看到，不同的部分对应着不同的团队，两个团队是相对于场景来划分的，这个团队之间是有关联的。所以既见树木也见森林是非常重要的。
七.总结
1.故事地图本身不是很重要，重要的是其后面承载的内容。
2.拆分需求很重要，在问题域拆分需求是持续交付和敏捷精益的根本和基础。按照业务流程，重要级别，优先级别来拆分。
3.一定要做一个可运行骨架，最关键的是它一定可运行，另一个是把基本的架构驱动出来。
4.按业务流程和优先级来分类和排列需求：既见树木也见森林。
5.按业务场景规划需求的交付：迭代交付价值，及时获取反馈。
