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