2017.3.4, 深圳, Ken Fang
前言: 产品开发最危险的一件事便是: 开发人员往往是在无知的情况下, 写代码。
产品开发最不可思议的一件事便是: 开发人员开发汽车; 测试人员测试飞机 。
产品开发最悲催的一件事便是: 天天熬夜加班, 最终发布的版本, 却对客户、对用户, 产生不了任何正面的影响。
产品开发中最郁闷的一件事便是: 来了团队两、三年, 还是没法成为能独当一面的大牛。
产品级敏捷经由团队的高度协作与自主, 建立起一讲求个人价值与责任, 逐步的形成一高效的产品开发生态系统。 在这生态系统中, 团队成员不仅能高效的完成版本开发, 更重要的是能发挥 “集体的智慧” 做出最佳的决策◦ 而使每一轮版本的发布, 都能以最少的产出, 却能对客户、对使用者, 产生最大的影响。
本文: 产品级敏捷是我在 2014年所独立创建的; 是当今在业界唯一能将精益敏捷开发与软件工程, 无缝结合的端到端的产品开发模式。
产品级敏捷: 有著精益敏捷开发的轻量级、可视化、即时发现问题等的特点。
也有著软件工程的系统化与规范化。
更重要且独特的是, 产品级敏捷中的各核心工程实践, 均可根据团队所要开发的需求 (特性) 的不同, 而可任意的 “组合” 成团队所需的工程实践; 使得团队可真正的拥有适合自身的产品开发的工程实践与工作模式, 使得团队不仅是能高效的开发产品, 更能保证产品发布的质量; 对客户、对使用者, 产生最大的影响。
产品级敏捷共有五大核心工程实践: Slice Board (切片板) : 使得每一轮版本的发布, 都能以最少的产出, 却能对客户产生最大的影响。
Architecture Map (架构地图): 轻量级的设计每一轮版本的架构设计, 并识别每一轮版本在架构上的风险。
Story Wall (故事墙): 使得开发人员与测试人员, 认同 User Story 的价值, 并从产品外部的视角, 清楚的明白: User Story完成的定义或标准为何?
Scenario Tree (场景树): 轻量级且可视化的Story的设计与定义完成。
Feature API (特性API): 从外部的视角, 使得特性对外所提供的 API, 均能代表ㄧ有价值的 “业务概念”。
I. Slice Board (切片板): 任何的产品; 不论是与使用者会直接发生互动的应用系统, 或是提供给众多产品使用的平台; 都应该要先有一个完整的产品特性树。 产品特性树将使得我们可以很清楚的知道, 从外部使用者或外部产品的视角, 产品的架构, 最终应提供哪些有价值的服务? 而团队中针对产品特性树中的每一个特性, 都应该要有一个主要的特性负责人; 每一个特性都会有一个主要的特性负责人负责, 每一个特性负责人, 都将负责多个特性。 在产品级敏捷中, 特性负责人的主要责任便是: 经由与团队中各不同领域的成员; 架构师, 开发骨干人员, 测试经理, 资深测试人员; 共同具体分析出每个特性的业务场景。 特性负责人与团队成员协作, 分析每个特性业务场景的主要步骤如下: 步骤-1: 特性负责人, 分析特性是由哪些业务活动所构成的? 步骤-2: 特性负责人, 针对特性中的某个业务活动, 分析出此业务活动的基本流。 步骤-3: 团队成员, 以特性负责人所分析出的基本流为基础, 分析出相关的 扩展流与异常流。 步骤-4: 特性负责人, 决定团队成员所分析出的扩展流与异常流, 哪些是需在这个版本中, 置入到产品的架构中, 来进行开发的。 步骤-5: 特性负责人, 再选取特性中的其他业务活动, 并重复步骤二至步骤五。直到特性中的所有业务活动均已分析完毕为止。
当特性负责人, 将特性的所有业务活动均分析出, 其各自的基本流, 扩展流与异常流之后, 特性负责人便可经由组合基本流, 扩展流与异常流, 而分析出从外部使用者或外部产品的视角, 有价值的端到端的业务场景切片。
特性负责人经由与团队成员的协作: 团队成员, 分析出扩展流与异常流; 团队成员作加法。 特性负责人, 从团队成员所分析出扩展流与异常流中, 删除不需要置 入产品的架构中, 去进行开发的扩展流与异常流; 特性负责人作减 法。
团队成员作加法, 特性负责人作减法; 此种团队协作的方式, 不仅使团队成员间, 能对需开发的特性场景 (需求), 迅速的达成一致的共识, 并且能使得每个特性, 都能以最少的场景 (需求), 却能对外部使用者或外部产品, 产生最大的正面影响。
[图一：Slice Board使得特性负责人与团队成员协作; 分析对客户、对使用者能产生最大正面影响的业务场景切片]
II. Architecture Map (架构地图): 当特性负责人与架构师, 开发骨干人员, 测试经理, 资深测试人员协作, 而可分析出特性下的所有业务场景切片时, 特性负责人与架构师, 开发骨干人员, 测试经理, 资深测试人员应再持续的协作, 根据由分析特性业务场景切片时, 所获得的知识, 继续分析出特性在架构上的依赖。
这些架构上的依赖, 包括: 特性依赖产品外部的哪些产品? 设备? 特性依赖外部这些产品或设备的哪些接口? 端口? 数据库? 特性依赖自身产品内部的哪些子系统? 特性依赖自身产品内部的这些子系统的哪些接口? 数据库?
当特性负责人与架构师, 开发骨干人员, 测试经理, 资深测试人员分析出特性在架构上的依赖后, 特性负责人便以 “Architecture Map”, 去承载这些特性在架构上的依赖。
特性负责人与架构师, 开发骨干人员, 测试经理, 资深测试人员便可根据特性的 Architecture Map 中, 所体现出的各特性在架构上的依赖, 而识别出: 哪些依赖会存在著风险, 而使特性无法进行集成测试? 或者哪些依赖所造成的风险, 会使特性无法进行独立发布、独立部 署?
特性负责人必需与架构师, 开发骨干人员, 测试经理, 资深测试人员协作, 认真的分析因架构上的依赖, 对特性在执行集成测试或独立发布、独立部署上, 所可能带来的风险为何? 并深度的思考, 应该有怎样的A计划? B计划? 才能消除或降低因为架构上的依赖, 所导致的风险; 这一步真的很关键, 往往会决定产品开发的成功或失败…
[图二: Architecture Map; Payroll 与 Finance 由不同的团队开发, 并且Payroll 依赖著 Finance。Payroll 与 HR 是经由数据库整合; Payroll 与 HR 共用 Employee 数据表。HR 会调用 Recruitment 的 REST API]
III. Story Wall (故事墙): 特性负责人与架构师, 开发骨干人员, 测试人员, 资深测试人员, 经由协作, 完成了: 1. 特性业务场景切片的分析。 2. 特性架构上的依赖分析。 所以, 接下来特性负责人便可: 将特性内部的业务场景切片, 依场景或功能点, 拆分成一个或多个 User Stories。 将特性会与其他特性产生交互的场景, 拆分成一个或多个 User Stories。
特性负责人, 需针对每一个 User Stories, 提供以下的信息给开发人员与测试人员: 会与 User Story 直接产生交互的外部使用者、系统、设备或事件。 外部使用者、系统、设备或事件, 和 User Story 直接产生交互的目的。 外部使用者、系统、设备或事件, 和 User Story 直接产生交互的主要场景。 User Story 完成标准 (验收条件): • 使用性: 外部使用者、系统、设备或事件是经由何种方式; 浏览器, 手机, 接口, 端口或某事件类型; 与 User Story 直接产生交互。 • 性能 • 可靠性 • 安全性
在产品级敏捷中, 特性负责人, 不应只是传递特性的需求, 而应该是: 要能说服开发与测试人员, 能认同 User Story 的价值。 并使开发与测试人员能从产品外部的视角, 清楚明白: 外部使用者、系统、设备或事件所期望 User Story 完成的定义或标准为何?
对于没被我们说服的这些开发、测试人员，我们怎能相信这些开发、测试人员，能为我们产出高质量的特性？ 假如，我们自己都不把说服开发、测试人员，这么重要的事，当成是一回事，那只能再度的证明：我们自己也都是抱着一种做事的心态；只要开发、测试人员听我的命令在做事就行了。 做产品和做事最大的差别，不在于做事的内容，而在于心态与文化；一种懂得尊重他人，说服他人能交心，又能严守原则与是非的心态与文化。 产品的特性负责人，对于自己所负责的特性，都无法从外部的视角，明确且清楚的定义出，什么是特性开发完成的条件时，这样的特性负责人，除了只会使团队交付永远没有市场竞争力、永远无法使客户满意的产品外，其他什么事也没法做…
[图三: Story Wall]
IV. Scenario Tree (场景树): 特性负责人, 说服开发与测试人员, 能认同特性中的 User Story 的价值, 并使开发与测试人员能从产品外部的视角, 清楚的明白: 外部使用者、系统、设备或事件所期望的特性中的 User Story 完成的定义或标准为何后, 开发人员与测试人员便必需协作, 藉由 “Scenario Tree”, 针对特性中的每个 User Stories, 共同的完成: 从产品外部的视角, 分析出 User Story 最佳的易用性业务流活动步骤。 分析出 User Story 每个业务流的活动步骤, 对外依赖的接口, 数据库或端口。 分析出 User Story 每个业务流活动步骤完成后, 其所产出的实体。 设计出每个实体的关键的纬度, 经由这些关键的纬度, 便能校验出 User Story 每个业务流活动步骤完成后, 其所产出的实体是正确、不正确、合法或不合法。 由每个实体的关键纬度, 设计出 User Story 每个业务流活动步骤的表格式测试用例; 经由此表格式测试用例, 便可定义出: • User Story 每个业务流活动步骤, 其 ”开发完成” 的定义。
开发人员, 架构师, UX 工程师与 Product Owner, 也必需协作, 藉由 “Scenario Tree” , 针对特性中的每个 User Stories, 共同的完成下列的设计: User Story 是属于哪一个版本的特性? 或是属于新产生的特性? User Story 将开发在那个模块? 那个类或文件内? User Story 所需的数据表结构。 User Story 所需的使用者介面。
更重要的是: Product Owner 可藉由 “Scenario Tree”, 确认开发人员已清楚的知道: • User Story 开发完成的定义为何? • User Story 该如何进行开发者测试? • User Story 最佳易用性的行为为何?
Product Owner 应坚持: 确认开发人员能经由 “Scenario Tree”, 清楚的知道, 上述的三件事后, 才允许开发人员, 进行 User Story 的开发。
因为, 唯有如此, 才能确保特性交付时的质量与易用性。 假如，某个开发人员没办法清楚且具体的定义出，自己所负责开发的 User Story，什么是完成？那可以预见的是，这个开发人员，便只是会在我们的产品中，不断的制造问题单罢了…
[图四: Scenario Tree: 业务流活动步骤: 获取客户租 CD 数据, 将会调用一 REST API, 并产生一实体: 客户租 CD 数据。验证实体: 客户租 CD 数据, 是, 否正确的关键纬度是: Customer ID, CD 数, CD ID, Rental Date]
V. Feature API (特性 API) 每个特性依照场景或功能点, 分解成一到多个的 User Stories。每个 User Story 经过开发人员与测试人员的协作, 藉由“Scenario Tree”, 分析出特性中包含哪些“实体” ?
代码语言：javascript复制每一个特性中的实体应能只明确代表特性中的某个单一的业务概念; 同样的, 特性中的某个业务概念应也只能由特性中某个单一的实体所代表。
所以, 在特性中的 Scenario Tree 中, 假如, 识别出有一个以上的实体; 名称不同, 但这些实体所代表的业务概念, 却是同一个的业务概念; 则开发人员与测试人员, 便应该将这些代表相同业务概念的实体, 合并为单一的实体。
当开发人员与测试人员可从特性中的 Scenario Tree 中, 将特性中的实体都能明确的对映到某个单一的业务概念后, 开发人员与测试人员便可轻松的从 Scenario Tree 中, 依照实体所对映的活动, 而分析出每个实体对外需提供的方法 (API)。
[图五: Orders 与 Order Status 虽是不同的实体, 但, 却代表著同一个业务概念; Orders。所以, 将 实体Orders 与实体 Order Status 合并]
VI. 组合团队自身所需的核心工程实践: 团队往往面对不同类型的需求 (特性) 开发; 只需演示的需求 (特性), 在既有架构上, 需快速交付的需求 (特性), 新的需求 (特性) 的开发…等等。 团队针对这些不同类型需求 (特性) 的开发, 应该有不同的核心工程实践的组合。 例如: 只需演示的需求 (特性), 建议: 只需 Slice Board, Story Wall, Scenario Tree 的组合; 便可快速的产出最少的场景, 却能吸引客户最多的关注。
[图六: 产品级敏捷的工程实践, 可针对不同类型需求 (特性) 的开发, 而可任意的组合]
结论： 产品级敏捷使得市场行销、产品管理与研发团队之间, 有了共通的语言, 而 可共同的面向外部的客户与市场; 以最少的产出, 对客户产生最大的影响。 更重要的是, 藉由产品级敏捷, 企业将能打造一以人为本, 内聚力强, 强调协作互助, 完全自主当责的全功能幸福团队。 产品级敏捷期待著你的参与!
