产品级敏捷
产品级敏捷
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”, 分析出特性中包含哪些“实体” ?
每一个特性中的实体应能只明确代表特性中的某个单一的业务概念; 同样的, 特性中的某个业务概念应也只能由特性中某个单一的实体所代表。
所以, 在特性中的 Scenario Tree 中, 假如, 识别出有一个以上的实体; 名称不同, 但这些实体所代表的业务概念, 却是同一个的业务概念; 则开发人员与测试人员, 便应该将这些代表相同业务概念的实体, 合并为单一的实体。
当开发人员与测试人员可从特性中的 Scenario Tree 中, 将特性中的实体都能明确的对映到某个单一的业务概念后, 开发人员与测试人员便可轻松的从 Scenario Tree 中, 依照实体所对映的活动, 而分析出每个实体对外需提供的方法 (API)。
[图五: Orders 与 Order Status 虽是不同的实体, 但, 却代表著同一个业务概念; Orders。所以, 将 实体Orders 与实体 Order Status 合并]
VI. 组合团队自身所需的核心工程实践: 团队往往面对不同类型的需求 (特性) 开发; 只需演示的需求 (特性), 在既有架构上, 需快速交付的需求 (特性), 新的需求 (特性) 的开发…等等。 团队针对这些不同类型需求 (特性) 的开发, 应该有不同的核心工程实践的组合。 例如: 只需演示的需求 (特性), 建议: 只需 Slice Board, Story Wall, Scenario Tree 的组合; 便可快速的产出最少的场景, 却能吸引客户最多的关注。
[图六: 产品级敏捷的工程实践, 可针对不同类型需求 (特性) 的开发, 而可任意的组合]
结论： 产品级敏捷使得市场行销、产品管理与研发团队之间, 有了共通的语言, 而 可共同的面向外部的客户与市场; 以最少的产出, 对客户产生最大的影响。 更重要的是, 藉由产品级敏捷, 企业将能打造一以人为本, 内聚力强, 强调协作互助, 完全自主当责的全功能幸福团队。 产品级敏捷期待著你的参与!