微服务架构设计 第五步: 微服务的 User Stories 的拆分与澄清

2016.9.11, 深圳, Ken Fang

特性负责人与架构师, 开发骨干人员, 测试经理, 资深测试人员, 经由协作, 完成了:

1.  微服务边界上下文 (Bounded Context) 的界定。

2.  微服务架构设计; 架构方案的选定。

3.  微服务架构上的依赖分析。

所以, 接下来特性负责人便可:

1.  将微服务内部的业务场景切片, 依场景或功能点, 拆分成一个或多个 User Stories。

2.  将微服务会与其他微服务产生交互的场景, 拆分成一个或多个 User Stories。

特性负责人, 需针对每一个 User Stories, 提供以下的信息给开发人员与测试人员:

1.  会与 User Story 直接产生交互的外部使用者、系统、设备或事件。

2.   外部使用者、系统、设备或事件, 和 User Story 直接产生交互的目的。

3.   外部使用者、系统、设备或事件, 和 User Story 直接产生交互的主要场景。

4.   User Story 完成标准 (验收条件):

       a. 使用性: 外部使用者、系统、设备或事件是经由何种方式; 浏览器, 手机, 接口, 端口或某事件类型; 与 User Story 直接产生交互。

       b. 性能

       c. 可靠性

       d. 安全性

在微服务产品级敏捷中, 特性负责人, 不应只是传递微服务的需求, 而应该是要能说服开发与测试人员, 能认同 User Story 的价值, 并使开发与测试人员能从产品外部的视角, 清楚明白:外部使用者、系统、设备或事件所期望 User Story 完成的定义或标准为何? 

对于没被我们说服的这些开发、测试人员，我们怎能相信这些开发、测试人员，能为我们产出高质量的微服务？假如，我们自己都不把说服开发、测试人员，这么重要的事，当成是一回事，那只能再度的证明：我们自己也都是抱着一种做事的心态；只要开发、测试人员听我的命令在做事就行了。做产品和做事最大的差别，不在于做事的内容，而在于心态与文化；一种懂得尊重他人，说服他人能交心，又能严守原则与是非的心态与文化。

产品的特性负责人，对于自己所负责的特性，都无法从外部的视角，明确且清楚的定义出，什么是微服务开发完成的条件时，这样的特性负责人，除了只会使团队交付永远没有市场竞争力、永远无法使客户满意的产品外，其他什么事也没法做…

SaveSaveSaveSaveSaveSaveSaveSave