微服务产品级敏捷: 重新定义平台开发的需求管理

2016.11.9, 深圳, Ken Fang

微服务平台往往需要为多类不同的产品提供服务。

当多类不同的产品, 向微服务平台涌入海量的需求时, 微服务平台的需求分析人员, 便常常会为了如何为多类不同产品的需求, 进行优先级排序, 而耗费大量的时间、人力与物力; 顺了姑意, 却违了嫂意。

针对微服务平台在需求管理上所面临的严峻的挑战, 建议微服务平台在需求管理上, 应遵循下列的原则:

1. 避免产品的市场人员, 产品管理人员, 微服务平台的研发人员总是为了所谓的需求优先级, 工作量, 微服务平台的人力管道… 等等的议题, 而耗费大量的时间、人力, 彼此间进行著无谓的争吵。

因此, 市场、产品管理的负责人, 微服务平台的架构师, 应负起责任; 从产品市场与微服务平台架构的面向, 制订微服务平台需求管理的规则。

2. 微服务平台在需求管理决策上所需的面向 (纬度) , 应要能尽量的精简; 简单而不简化。以使微服务平台的需求管理决策, 能高效且精准的完成。使得微服务平台可高效且精准的决策, 快速的开发、部署, 快速的获得反馈, 快速的修正决策, 快速的持续改善。

3. 微服务平台的研发人员应更专注于各产品所提的需求的场景分析; 需求深度的挖掘。使得自身的微服务平台, 能以最少的工作量, 却能对各产品发生最大的正面影响。

基于微服务平台在需求管理上的原则, 微服务平台在需求管理上的作法, 建议如下:

1. 市场、产品管理的负责人在每个版本, 需制订各类产品的重要性权重。

例如: 共有 “A, B,C, D, E”, 5 类产品, 同时会在某版本中, 对某个微服务平台提出需求。

市场、产品管理的负责人, 便需依照市场的路标, 制订各类产品在某版本中的重要性权重。

	A类产品	B类产品	C类产品	D类产品	E类产品
重要性权重	3	2	5	1	2

5: 最重要  1:最不重要

2. 微服务平台架构师在每个版本, 需制订各架构质量属性的重要性权重。

例如: 微服务平台架构师依照微服务平台的架构路标、架构质量现况与市场所需的产品竞争力, 制订架构各质量属性的重要性权重。

	可靠性	性能	安全性	易用性
重要性权重	2	4	3	1

4: 最重要  1:最不重要

3. 微服务平台需求分析人员, 依照各类产品在某版本中的重要性权重与架构各质量属性的重要性权重, 计算出各类产品所提需求的重要性。

各类产品需求的重要性 = Σ各类产品在某版本中的重要性权重 * 架构各质量属性的重要性权重

	A类产品	B类产品	C类产品	D类产品	E类产品	可靠性	性能	安全性	易用性	各类产品需求的重要性累计
重要性权重	3	2	5	1	2	2	4	3	1
R0001	V								V	3*1=3
R0002			V				V			5*4=20
R0003		V					V	V		2*4+2*3=14
R0004				V			V	V	V	1*4+1*3+1*1=13
R0005					V			V	V	2*3+2*1=8

 

 

 

 

 

 

 

 

4.  微服务平台需求分析人员, 便可将计算完重要性的各类产品需求, 依所算得的重要性, 依序放入到Program Backlog 中; 此时便完成了版本中需求的 “广度” 的定义。

5.  微服务平台需求分析人员, 再运用微服务产品级敏捷中的 “场景分析” 的工程实践, 与微服务平台的骨干人员, 举行 “价值业务场景切片” Workshop; 识别各类产品需求中 “有价值” 的 “业务场景切片”。

6.  微服务平台需求分析人员, 将由 “价值业务场景切片” Workshop , 所识别出的各类产品需求中 “有价值” 的 “业务场景切片”, 与市场、产品管理的负责人、架构师做再度的澄清与确认; 此时便完成了版本中需求的 “深度” 的定义。

7.  当版本中需求的 ”广度” 与“深度” 都已定义完成后, 微服务平台需求分析人员, 便可将各类产品需求中 “有价值” 的 “业务场景切片”, 从 Program Backlog依序放入到 Team Backlogs 中。此时, 团队便可正式进入微服务版本开发准备的阶段…