微服务架构设计 第六步: 微服务的 User Stories 的分析、设计与定义完成

2016.9.12, 深圳, Ken Fang

特性负责人, 说服开发与测试人员, 能认同微服务中的 User Story 的价值, 并使开发与测试人员能从产品外部的视角, 清楚的明白: 外部使用者、系统、设备或事件所期望的微服务中的 User Story 完成的定义或标准为何后…

I.       开发人员与测试人员便必需协作, 藉由 “Story 场景树”, 针对微服务中的每个 User Stories, 共同的完成:

         1. 从产品外部的视角, 分析出 User Story 最佳的易用性业务流活动步骤。

         2. 分析出 User Story 每个业务流的活动步骤, 对外依赖的接口, 数据库或端口。

         3. 分析出 User Story 每个业务流活动步骤完成后, 其所产出的实体。

         4. 设计出关键的纬度, 经由这些关键的纬度, 便能校验出 User Story 每个业务流活动步骤完成后, 其所产出的实体是正确、不正确、合法或不合法。

         5. 由步骤三, 所设计出的关键的纬度, 设计出 User Story 每个业务流活动步骤的表格式测试用例; 经由此表格式测试用例, 便可定义出: User Story 每个业务流活动步骤, 其 “开发完成” 的定义。

II.      开发人员, 架构师, UX工程师与 Product Owner, 也必需协作, 藉由 “Story 场景树”, 针对微服务中的每个 User Stories, 共同的完成下列的设计:

         1. User Story 是属于哪一个版本的微服务? 或是属于新产生的微服务?

         2. User Story 将开发在那个模块? 那个类或文件内?

         3. User Story 所需的数据表结构。

         4. User Story 所需的使用者介面。

更重要的是: Product Owner 可藉由 “Story 场景树”, 确认开发人员已清楚的知道:

1. User Story 开发完成的定义为何?

2. User Story 该如何进行开发者测试?

3. User Story 最佳易用性的行为为何?

Product Owner 应坚持: 确认开发人员能经由 “Story 场景树”, 清楚的知道, 上述的三件事后, 才允许开发人员, 进行开发 User Story。

因为, 唯有如此, 才能确保微服务交付时的质量与易用性。

假如，某个开发人员没办法清楚且具体的定义出，自己所负责开发的 Story，什么是完成？那可以预见的是，这个开发人员，便只是会在我们微服务的产品中，不断的制造问题单罢了…

 

 

 

Save Save