移动互联网时代敏捷系列产品级敏捷Word格式文档下载.docx
《移动互联网时代敏捷系列产品级敏捷Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《移动互联网时代敏捷系列产品级敏捷Word格式文档下载.docx（9页珍藏版）》请在冰豆网上搜索。
使得开发人员与测试人员,
认同
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。
HR
是经由数据库整合;
Payroll
共用
Employee
数据表。
会调用
Recruitment
的
RESTAPI。
]
III.
StoryWall
（故事墙）:
测试人员,
资深测试人员,
经由协作,
完成了:
1.
特性业务场景切片的分析。
2.
特性架构上的依赖分析。
所以,
接下来特性负责人便可:
∙将特性内部的业务场景切片,
依场景或功能点,
拆分成一个或多个
UserStories。
∙将特性会与其他特性产生交互的场景,
需针对每一个
UserStories,
提供以下的信息给开发人员与测试人员:
∙会与
直接产生交互的外部使用者、系统、设备或事件。
∙外部使用者、系统、设备或事件,
和
直接产生交互的目的。
外部使用者、系统、设备或事件,
直接产生交互的主要场景。
∙UserStory
完成标准
（验收条件）:
∙使用性:
外部使用者、系统、设备或事件是经由何种方式;
浏览器,
手机,
接口,
端口或某事件类型;
UserStory直接产生交互。
∙性能
∙可靠性
∙安全性
不应只是传递特性的需求,
而应该是:
∙要能说服开发与测试人员,
能认同
的价值。
∙并使开发与测试人员能从产品外部的视角,
清楚明白:
外部使用者、系统、设备或事件所期望
完成的定义或标准为何?
对于没被我们说服的这些开发、测试人员，我们怎能相信这些开发、测试人员，能为我们产出高质量的特性？
假如，我们自己都不把说服开发、测试人员，这么重要的事，当成是一回事，那只能再度的证明：
我们自己也都是抱着一种做事的心态；
只要开发、测试人员听我的命令在做事就行了。
做产品和做事最大的差别，不在于做事的内容，而在于心态与文化；
一种懂得尊重他人，说服他人能交心，又能严守原则与是非的心态与文化。
产品的特性负责人，对于自己所负责的特性，都无法从外部的视角，明确且清楚的定义出，什么是特性开发完成的条件时，这样的特性负责人，除了只会使团队交付永远没有市场竞争力、永远无法使客户满意的产品外，其他什么事也没法做…
[图三:
StoryWall]
IV.
ScenarioTree
说服开发与测试人员,
能认同特性中的
并使开发与测试人员能从产品外部的视角,清楚的明白:
外部使用者、系统、设备或事件所期望的特性中的
完成的定义或标准为何后,
开发人员与测试人员便必需协作,
藉由“ScenarioTree”,
针对特性中的每个
共同的完成:
∙从产品外部的视角,
分析出
最佳的易用性业务流活动步骤。
∙分析出
每个业务流的活动步骤,
对外依赖的接口,
数据库或端口。
每个业务流活动步骤完成后,
其所产出的实体。
∙设计出每个实体的关键的纬度,
经由这些关键的纬度,
便能校验出
其所产出的实体是正确、不正确、合法或不合法。
∙由每个实体的关键纬度,
设计出
每个业务流活动步骤的表格式测试用例;
经由此表格式测试用例,
便可定义出:
每个业务流活动步骤,
其
”开发完成”
的定义。
开发人员,
架构师,UX
工程师与
ProductOwner,
也必需协作,
藉由“ScenarioTree”
共同的完成下列的设计:
是属于哪一个版本的特性?
或是属于新产生的特性?
将开发在那个模块?
那个类或文件内?
所需的数据表结构。
所需的使用者介面。
更重要的是:
ProductOwner
可藉由“ScenarioTree”,
确认开发人员已清楚的知道:
开发完成的定义为何?
该如何进行开发者测试?
最佳易用性的行为为何?
ProductOwner
应坚持:
确认开发人员能经由“ScenarioTree”,
清楚的知道,
上述的三件事后,
才允许开发人员,
进行
的开发。
因为,
唯有如此,
才能确保特性交付时的质量与易用性。
假如，某个开发人员没办法清楚且具体的定义出，自己所负责开发的
UserStory，什么是完成？
那可以预见的是，这个开发人员，便只是会在我们的产品中，不断的制造问题单罢了…
[图四:
ScenarioTree:
业务流活动步骤:
获取客户租
CD
数据,
将会调用一
RESTAPI,
并产生一实体:
客户租
数据。
验证实体:
是,
否正确的关键纬度是:
CustomerID,CD
数,CDID,RentalDate。
V.
FeatureAPI
每个特性依照场景或功能点,
分解成一到多个的
每个
经过开发人员与测试人员的协作,藉由“ScenarioTree”,
分析出特性中包含哪些“实体”
?
每一个特性中的实体应能只明确代表特性中的某个单一的业务概念;
同样的,
特性中的某个业务概念应也只能由特性中某个单一的实体所代表。
在特性中的
假如,
识别出有一个以上的实体;
名称不同,
但这些实体所代表的业务概念,
却是同一个的业务概念;
则开发人员与测试人员,
便应该将这些代表相同业务概念的实体,
合并为单一的实体。
当开发人员与测试人员可从特性中的
ScenarioTree
将特性中的实体都能明确的对映到某个单一的业务概念后,
开发人员与测试人员便可轻松的从
依照实体所对映的活动,
而分析出每个实体对外需提供的方法
（API）。
最后,
开发与测试人员再将所有实体对外需提供的方法
（API）
集成,
便成为特性对外需提供的方法
[图五:
Orders
OrderStatus
虽是不同的实体,
但,
却代表著同一个业务概念;
Orders。
将实体Orders
与实体OrderStatus
合并。
VI.
组合团队自身所需的核心工程实践:
团队往往面对不同类型的需求
（特性）
开发;
只需演示的需求
（特性）,
在既有架构上,
需快速交付的需求
新的需求
的开发…等等。
团队针对这些不同类型需求
的开发,
应该有不同的核心工程实践的组合。
例如:
建议:
只需
SliceBoard,StoryWall,ScenarioTree
的组合;
便可快速的产出最少的场景,
却能吸引客户最多的关注。
SliceBoard
ArchitectureMap
StoryWall
ScenarioTree
FeatureAPI
只需演示的需求（特性）
V
需快速交付的需求（特性）
（特性）的开发
[表一:
针对不同类型的需求
开发,
建议所需的核心工程实践组合]
VII.
结论：
产品级敏捷使得市场行销、产品管理与研发团队之间,有了共通的语言,而可共同的面向外部的客户与市场;
以最少的产出,对客户产生最大的影响。
更重要的是,藉由产品级敏捷,企业将能打造一以人为本,内聚力强,强调协作互助,完全自主当责的全功能幸福团队。
产品级敏捷期待著你的参与!
升级会员 