Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
敏捷开发技术最佳实践
(统一敏捷开发过程)
钟玮军
2016-04
• 现任:
– 北京车网互联科技股份有限公司
(资深架构师&研发中心副总经理)
• 历任:
– 卓望科技股份有限公司(飞信系统架构师)
– 诺基亚西门子科技股份有限公司(开发工程师&团队Leader)
– 中国电信(网络运行管理工程师)
• 专...
目 录 Contents
背景介绍
基础知识
统一敏捷开发过程
总结
思考与答疑
背景介绍
流行软件开发流程框架比较
影响敏捷开发过程成败的关键因素
1、团队目标
(What to do)
2、团队文化
(Why we together)
3、管理制度
(How to support)
4、团队能力
(How to achieve)
6、技术和工具
(How ...
敏捷开发流程实施的技术能力障碍
• 流程框架本身缺乏对需求、分析、设计、实现等各阶段工作的方法性指导;
• 书籍和文献往往侧重于单一阶段工作的方法性描述,但难以形成体系;
• 没有经验的开发团队难以落地;
A Unified Process?
培训目标
• 借鉴当前敏捷开发技术最佳实践,形成贯穿软件研发
各阶段的统一敏捷开发过程框架,为敏捷团队顺利实
施敏捷项目研发提供技术性指导。
基础知识
(一)UML
• UML(Unified Modeling Language)是什么?
– 可视化的建模语言;
– 是在Booch、OMT、OOSE等面向对象的方法及其它许
多方法与资料的基础上发展起来的,通用的建模语言,
有效的消除了各种建模...
UML 2.x Diagrams
RUP 4+1视图
逻辑视图:
- 层/子系统划分
- 类/对象静态结构及关联关系
- 包图、类/对象图、状态图是
常用图形
实现/开发视图:
- 关注配置管理以及开发环境中
实际软件模块的组织结构
- 组件图/包图是常用的图形
过程视图:
-...
(二)ICONIX过程方法
需求 设计 实现ICONIX Process is a use
case–driven analysis and
design methodology. Its
main focus is on how to get...
• 简洁:
– Use Cases、Robustness Diagrams、Sequence Diagram、Class Diagram
– 少数几个步骤就可以完成从用例到代码的建模
• 严谨:
– 贯穿需求、分析、设计、实现,是一个Unifi...
ICONIX与UML模型视图
Describe
Analyze
用例图
注:
- 系统用例指系统外部可见的一个系
统功能单元,一般用动词短语简述
系统的功能
- 在标准RUP流程中,通常与用例描述
结合使用,说明“Basic
Flow”&“Alternative Flows”,在敏
捷方法中,可以用User...
类图
http://creately.com/blog/diagrams/class-diagram-relationships/
类之间的几种关系
类名
类属性
类操作
类关系
类图,在需求阶段主要用作领域模型的建模,在设计阶段,
主要用作系...
序列图
注:
- 时序图体现了系统内部实现的设
计。
- 时序图各单元之间的交互消息命
名,应反应双方对于职责的约定。
- 时序图各单元之间的交互消息,
会转化为消息接收方的一个接口
方法。
- 采用“Boundary-Control-Enti...
鲁棒图
鲁棒图目的:
- 健全性检查(Sanity check)
- 完整性检查(Completeness check)
- 识别对象(Object Identification)
- 初步设计(Preliminary Design)
鲁棒图的...
(三)领域驱动设计
领域驱动设计(Domain Driven Design)是一种软件开发方法,目的是让
软件系统在实现时准确的基于对真实业务过程的建模并根据真实业务过程
的调整而调整。
通用语言
• 领域专家和开发者建立并使用通用语言(UBIQUITOUS
LANGUAGE)是领域驱动设计的核心思想,却又往往不被开
发团队重视。
• 领域驱动设计的一个核心思想就是基于模型的共同语言。
使用模型作为语言的核心骨架,要求团队在进行...
领域模型的切分
 在理想的世界中,我们可以有一种
把整个企业领域包含进来的单一模
型;这个模型将是统一的,没有任
何相互矛盾或相互重叠的术语定义;
每个有关领域的逻辑声明都将是一
致的。但大型系统开发并不是这样
理想,常常需要对领域进行切分。...
领域系统的集成
在以领域模型为核心的六边形架构中,建议通过适配器与其他领域系统进
行集成,以避免领域系统之间存在紧耦合关系。
领域驱动设计架构风格
领域驱动设计是OOAD的一个扩展和延伸,DDD基于面向对象分析与设
计技术,对技术框架进行了分层规划,同时对每个类进行了策略和类型的
划分。
分层规划 面向对象 策略和类型划分
领域驱动设计分层架构模型
DDD是分层架构模型。DDD架构风格可以与SOA架构风格实现完美融合。
领域驱动设计CQRS架构风格
Client
Commands
Command
Bus
Sends
Command
Handlers
Modify
Repositories
Read Write
Data
store
Event
Bus
Comm...
领域驱动设计与模型驱动开发
由于对每个类进行了策略和类型的划分,针对不同策略和类型的类提取重
复出现的相似代码,也为模型驱动开发的自动化代码生成提供基础。
参考文献与资料
网站资料:
- ICONIX:http://www.iconixsw.com
- UML:http://www.uml.org
- Domain Driven Design:http://www.domaindrivendesi...
统一敏捷开发过程
(一)需求分析
• 需求是指:
– 用户解决问题或达到目标所需条件或能力;
– 系统或系统部件要满足合同、规范或其它正式规定文档所需
具有的条件或能力;
– 一种反映上述所描述的条件和能力的文档说明,是以一种清
晰、一致且无二义性的方式对目标系...
需求的层次
业务分析
业务需求
(Epics)
用户需求
(Stories)
功能需求
(Functional)
设计 构建
软件需求的层次
需求类型 描述
业务需求
(Epics)
描述发起项目的原因、需达到的业务目标、以及衡量该项目是否成功...
需求的层次(续)
需求分析方法
需求捕获:
 访谈
 小组会议
 问卷调查
 其它:
∙ 现场观摩
∙ 文档考古(分析客户/用户已有的业务、信息建设的文档)
∙ 原系统研究(现在的系统问题、改进要求)
∙ 分析同类软件产品特性(文档或试用软件分析)
需求建模方法
业务用例
图
业务用例
时序图
用户需求
User Story
描述
UX设计 (故
事板)
系统用例
图
系统分析
鲁棒图
愿景
领域概念
模型
(1) 愿景
• 什么是愿景:
– 在“老大”
看来,引进
这个系统的
目的是什么?
• 为什么要明
确愿景:
– 缺乏清晰、
共享的愿景
往往是项目
失败的主要
原因。
参考:《软件方法 – 业务建模和需求》,潘加宇
source: inte...
愿景的明确
• 寻找“老大”
– “老大”就是为项目拍板签字买单的人;
– 系统改善哪个组织的流程?“老大”就是该组织的负责人;
– 系统好坏的度量指标应该藏在“老大”的大脑里。
– 做产品而不是项目时,老大就是产品所定位的具体组织和人
群。
愿景的明确(续)
• 明确可度量的目标
– 愿景是改善组织的指标(从而获取竞争优势),不是做某事;
– 不要把系统的功能当作愿景,而应回答这个系统对购买系统
的组织有什么好处;
– 采用恰当的愿景描述的粒度,不要把组织的目标当作系统的
目标;
...
(2) 业务建模
• 业务建模的目
的
– 从组织的角度
来定位系统应
该提供的价值;
– 缺乏系统的业
务建模过程、
拍脑袋需求是
引起“需求容
易变化”的根
源之一。
http://www.enterpriseunifiedprocess....
业务建模的核心概念
• 业务参与者(Business Actor)
– 业务活动的服务对象
– 在组织之外和组织交互的人群或组织
• 业务工人(Business Worker)
– 在组织内部承担一系列职责,为业务执行者实现业务服务的人
– 也...
业务建模的核心概念(续)
• 业务用例(Business Use Case)
– 业务用例是指业务参与者希望通过和组织交互达到的,而且组织能提供
的价值。
– 业务用例代表组织的本质价值,很难变化,改变的是业务用例的实现。
– 是对组织内部流程...
业务建模步骤
• 发现业务用例并建模(业务用例图/业务描述)
– 业务用例是指业务参与者希望通过和组织交互达到的,而且组织
能提供的价值;
– 选定要改进的组织(选定组织的范围要合适)
– 寻找业务参与者(对准组织的边界)
– 识别业务用例的两...
业务建模示例:业务用例建模
• 正确地划定边界
– 思考的边界在哪
儿?
– 识别业务参与者
和业务工人
• 统一用例粒度
– 价值而非实现
• 用例描述
– 描述目的是什么
(What)而不是怎么
实现(How)
业务建模示例:业务用例分解
业
务
流
程
解
耦
/
分
解
业务建模示例:业务用例分解(续)
业务建模示例:业务用例+用例描述
• Basic Flow for Prepare Tender
– This business use case begins when the End User Department requires add...
业务建模示例:业务实现建模 – 时序图
sd Interaction
«business actor»
End User Manager IT Project Manager Enterprise
Architect
Legal Officer...
业务建模示例:业务实现建模 – 时序图(续)
• 业务实现优化
– 引入自动化业务
工人(信息系统)
后的时序图变化
– 物流改成信息流
– 信息流改善
– 封装领域逻辑
sd Interaction2
«business actor»
End...
业务建模示例:业务实现建模-活动图
• 可选,实现更
细粒度的业务
流程建模
业务用例示例:业务实现建模-活动图(续)
• 可在活动图中添加业
务实体
业务建模示例:业务实现建模-BPMN图
Pool
Lane
Start
Event
End
Event
Activity
Gateway
Sequence
Flow
Message
Flow
Event
• 与UML活动图功能
作用相似,建模时...
业务建模示例:业务实体/对象协作关系
• 通过用例描述发
现识别业务对象
和业务实体
• 可以使用协作图
对业务对象和业
务实体之间的协
作关系进行建模,
从而进一步发现
业务实体关系
sd Interaction-Communication
...
(2)系统需求
• IT系统的本质是
将企业(或现实
生活)现有流程
全部或部分自动
化,从而达到优
化企业流程(或
用户体验)的目
的
• 图中展示了从对
流程改进想法落
实到IT系统建设
需求的一般过程
系统需求:思考边界转换
• 研究对象从研究组织,转变为研究系统
系统需求示例:用户需求建模-系统用例图
• 区分系统需求与
系统需求实现的
区别
• 建模的用例粒度
控制到“系统对
用户提供的价
值”,即用户需
求层次,不需要
过细。
uc Prepare Tender Document
TenderSys...
系统需求示例:用例描述
• Basic Flow
– This use case begins when the End-User Manager wants to review a tender document after being
no...
系统需求示例:交互流程设计-活动图
图例选自 http://pattydavididportfolio.weebly.com/samples.html
• 现阶段关注交互
流程,而非页面
布局
• 涉及多角色协作
完成的业务流程,
宜使用业务流...
系统需求示例:交互流程设计-活动图(续)
• 涉及多角色协作
完成的业务流程,
可以采用泳道活
动图(或BPMN图)
作为界面交互的
辅助设计手段;
• 泳道活动图(或
BPMN图)可以
帮助同时展现线
上线下工作。
系统需求示例:交互流程设计-鲁棒图
• 涉及多角色协作完
成的复杂业务流程,
鲁棒图能清晰展示
业务全貌(交互功
能需求-角色职责
逻辑-业务实体单
元)
• 鲁棒图
“Boundary-
Controller-Entities”
式结构方式,...
系统需求示例:交互流程设计-线框图
图例选自 http://www.creativeuxdirector.com/casestudy.html#
系统需求示例:领域模型建模
class DomainModels
TenderDocumentPreparingProcessInstance TenderDocumentPreparingTask TaskAssignee
TenderDoc...
系统需求示例:领域模型建模(续)
• 除了领域对象之间的关系,领域对象自身状态转换的动态
行为也非常重要,可以采用状态迁移图来对此进行建模。
(3)敏捷需求方法
• 敏捷的需求原则
– Satisfy the Customer / Excellent at Quality
– Welcome Change / Deliver Frequently / Maintain Constan...
敏捷需求方法:战略工具-寻找商机
寻找商机:
- 移情:理解你
的用户
- 定义:识别问
题
- 构思:头脑风
暴,形成思路
- 原型:用线框
图或代码快速
搭建原型
- 验证:验证并
优化
敏捷需求方法:战略工具-商业模式设计
商业模式描述了企
业如何创造价值、
传递价值和获取价
值的基本原理。
商业模式画布是一
种用来描述商业模
式、可视化商业模
式、评估商业模式
以及改变商业模式
的通用语言。
参考:《商业模式
新生代》
敏捷需求方法:战略工具-产品战略
精益画布是从商
业模式画布改编
而来的,具有制
作迅速、内容紧
凑、方便携带的
特点,便于创业
者记录和交流自
己的商业模式。
我们可以把新产
品开发当作一次
创业来看待。
参考:《精益创
业实战》
敏捷需求方法:战略工具-产品战略(续)
http://blog.vsharing.com/zhoujg/A1790490.html
精益画布的拓
展版,增加了
更多商业计划
的元素,使产
品战略更具可
执行性。
敏捷需求方法:战略工具-产品定位
• 价值主张画布模型
https://strategyzer.com/books/value-proposition-design
敏捷需求方法:需求调查-客户角色模型
• 收集和评估所有已有的关于用户的知识,找出知识差距,创建客户角色模型。一
个客户角色模型,应当完整的描述出客户使用你产品/服务的目的和行为。
http://thepathforward.io/the-im...
敏捷需求方法:需求调查-绘制客户旅程
• Customer Journey Map(客户旅程地图),描述客户在使用产品或者服务时的体验、
主观反应和感受,发现客户每一阶段的痛点,以及客户在这个阶段想要什么。
http://thepathforw...
敏捷需求方法:需求管理-描述
• 用户故事
As a <USER ROLE>,
I want a <FUNCTIONALITY>
So that I can get
<BUSINESS VALUE>.
基于目标和场景驱
动,体现业务价值
敏捷需求方法:需求管理-描述(续)
http://www.slideshare.net/AgileLietuva/viktor-kisko-discover-to-deliver-agile-product-planning-
and-anal...
敏捷需求方法:需求管理-粒度
• 需求满足的2/8原则,
以迭代的方式进行需
求分析
• 按照业务优先级次序,
将大粒度的用户需求
(用户故事)拆解为小
粒度的用户需求(用
户故事),并依次经
过评估后安排进入
Release计划和Sprint...
敏捷需求方法:需求管理-粒度(续)
敏捷需求方法:需求管理-工具
敏捷需求方法:产品规划-影响地图
• 对产品开发和运营组
织,影响地图(Impact
map)是一个简单却又
十分高效的范围管理、
战略规划和协作方法。
它在产品目标和范围
之间建立了清晰、完
整和动态映射关系;
以此为基础有效地规
划和沟通产...
敏捷需求方法:产品规划-影响地图(续)
敏捷需求方法:产品规划-版本计划
• 用户故事地图
(User Story
mapping)
– 决定构建优先级
– 鼓励迭代开发
– 确定项目范围
– 制定版本计划
– 排序和梳理
Backlog
– 可视化项目进度
User Activit...
敏捷需求方法:产品规划-版本计划(续)
• 从影响地图(Impact mapping)到用户故事地图(User Story Mapping)
– 每一个版本都应当有明确的商业意图,形成合力
– 通过KPI指标对结果进行监控,评测产品版本
Our...
敏捷需求方法:产品规划-版本计划(续2)
敏捷需求方法:版本计划-MVP
• 到目前为止,上述所有的想法(包括你对于用户痛点的解决方案)都
是假设,这些假设都需要通过构建产品原型找到真实客户进行验证。
I tested my MVP with
real customers –
now ...
敏捷需求方法:版本计划-MVP(续)
• 也可以通过线框图
产品设计原型的方
式验证用户需求,
但往往不能代替真
正可运行的产品所
起到的验证效果
• MVP(Minimum
Viable Product,最
简化可视性产品) 的
功用就是让你...
敏捷需求方法:版本计划-MVP(续2)
• 确定MVP
– 客户调查
– 确定功能的四
象限
• 值得注意的是,
随着时间推移,
曾经属于加分
项的功能需求
可能慢慢变为
用户的基本需
求
– 壁垒
Delighters
• Things
cu...
敏捷需求方法-成果评估
• 通过数字化方法进行结果评估而不是仅凭“感觉”
– 避免主观偏见、错误判断
http://www.slideshare.net/dan_o/product-management-by-numbers-using-met...
敏捷需求方法:成果评估(续)
• 营销漏斗与KPI指标设定
敏捷需求方法:成果评估(续2)
• 采用A/B测试技
术评估更好的用
户体验交互设计
(二)系统设计
• 系统设计的任务是:
– 综合考虑客户需求、业务目标和技术代价等各方面的因素
– 根据需求分析阶段对系统的逻辑功能的要求,并考虑到经济、
技术和运行环境等方面的条件,确定系统的总体结构和系统
各组成部分的技术方案,合理选择计算...
系统设计:八项内容
System Design
1. Identify Design Goals
Additional NFRs
Trade-offs
2. Subsystem Decomposition
Layers vs Partition...
(1)系统设计目标
• 可靠性
• 可修改性
• 可维护性
• 易理解性
• 适用性
• 可重用性
• 高效性
• 可移植性
• 需求可追踪性
• 容错性
• 向后兼容性
• 高性价比
• 健壮性
• 高性能
• 良好的文档
• 良好定义的接口...
系统设计:设计目标(续)
便宜
提高工作效率
向后兼容
需求可追踪
快速开发
灵活性
运行态高效
可靠性
功能性
用户友好性
可用性
易学性
容错性
健壮性
可移植性
良好的文档
最少错误
可修改性、可读性
可重用性、灵活性
良好定义的接口
客...
(2)系统分解-子系统/组件划分
重用性
可读性
扩展性
可测性
可变性
并行开发
高内聚低耦合
系统分解-原则和方法
《一线架构师实践指南》,温昱
系统分解-分层与分区
• 分层(Layer):
– 一个分层只能依赖比它更低的分层所提供的服务
– 一个分层不应该知道比它更高的分层的相关知识
• 分区(Partition):
– 某一分层可以被垂直划分为几个独立的子系统
– 分区可以向同一分...
系统分解-分层结构
pkg Component Model
Infrastructure(Frameworks)
Presentation Infra
Infrastructure(Common Utilities)
Application A...
系统分解-分区结构
Sales
Product
SKU
Name
Price
Quantity Ordered
…
Inventory Service (SAP)
Product
SKU
QOH
Location Code
…
Pricing ...
系统分解-CQRS架构
• 将Command和Query模型进行分离,有利于子系统解耦。
系统分解-模型方法
• 使用组件图
说明应用开
发框架视图
的示例(侧重
于重用)
系统分解-模型方法
• 使用框图说
明系统应用
架构的示例
(侧重于领域
分区)
系统分解-模型方法
• 借助用例图进行领域服务上下文映射(Context Map)的示例
系统分解-模型方法(续)
• 借助鲁棒图进行领域模型上下文映射(Context Map)的示例
鲁棒图中控制对象的数
量不超过5个,该条定
律是否必须要遵守?
答案当然是否定的。鲁
棒图及其它UML图形建
模的要点在于,首先定
义该图想要向读者...
系统分解-模型方法(续)
• 使用组件图
说组件组成
和子系统间
接口关系的
示例
(3)并发设计
• 系统并发进程/线程在同一时刻变更同一对象状态,可能导致该
对象内部状态的不一致,引起系统执行结果的错误。
– Restful:无状态
– 强一致性(数据库事务控制)
– 最终一致性/跟踪单据(根据业务场景选择解决方案)
(4)物理架构设计 - 软件/硬件映射
• 部署架构视图着重考虑运行软
件的计算机、网络、硬件设施
等情况,还包括如何将软件包
部署(如果是嵌入式系统则是
烧写)到这些硬件资源上,以
及它们运行时的配置情况。
• 物理架构还要考虑软件系统和
包...
物理架构设计-模型方法
• 使用部署图表
示系统和组件
与物理设备之
间的部署关系
示例。
物理架构设计-模型方法
• 网络设计的逻
辑拓扑和物理
拓扑示例
(5)数据存储设计
• 用例驱动结合鲁棒图分析方法持续更新领域模型
• 根据数据存取特点(如应用场景、事务一致性要求、数据
容量、数据增长、结构特点、存取频率、性能要求、安全
需求、成本控制等)选择数据存储和容灾备份方案
– 关系型数据库/非关...
(6)系统安全设计
技术安全
管理安全
安全信息系统(技术+管理)
物理安全 网络安全 主机安全 应用安全 数据安全
管理机构 管理制度 人员管理 系统建设 运维管理
电磁防护
防潮温湿度
防雷放火
访问控制
物理位置
入侵防范
网络设备
网络...
Web Server
系统安全设计–WEB网站安全技术
• WEB网站安全通用技术措施
Firewall
Apps
Host
Firewall
Application Server
Apps
Host
Database Server
Host
...
系统安全设计-WEB网站安全技术(续2)
• WEB网站安全通用技术措施列表检查项示例
(7)算法控制模型
• 根据软件逻辑算
法要求,选择合
理的算法控制模
型。
– Implicit Control:
多见于知识系统
– Decentralized
Control:多见于
依赖大量计算资
源的复杂计算
– Centralize...
(8)异常处理
• 系统设计应能预见到系统可能发生的致命错误,并提
供处理机制
– 初始化
• 系统从一个未初始化的状态转化到稳定状态
– 终止运行
• 系统资源应被释放,相关系统应得到通知
– 错误
• Bugs, Errors, Exter...
(9)敏捷设计方法
• 敏捷的设计原则
– 总体技术架构选型
• 应具备超前性(开发框架、集成方案)
– 子系统/组件的设计
• Keep it Simple(不过度设计)
• Evolve Designs(小步迭代)
– 文档/模型
• 良好...
(三)系统实现与交付
• 敏捷的系统实现最佳实践
– Model-Driven-Development
– Continuous Integration
– Non-stop Redeployment
模型驱动开发
DDD+MDSD工具实例:sculptorgenerator
http://sculptorgenerator.org/
模型驱动开发技术概览:
模型驱动开发优点:
• 开发更快速、开发成本更低
• 架构更强壮,提高开发质量,支持...
持续集成技术
http://www.slideshare.net/SonatypeCorp/nexus-and-continuous-delivery
持续集成技术:
• 代码提交与版
本管理
• 自动编译
• 自动部署
• 自动测试
– UT...
不停服务升级
• 利用SOA或其它
分布式框架的服
务版本管理特性,
实现不停服务系
统升级
总结
总结
愿景/战略:
- 愿景
- 机会模式画布
- 商业模式画布
- 精益画布
- 价值主张画布
- 企业架构方法
需求:
- 客户角色分析
- 客户旅程地图
- 需求描述方法
- 用户故事切分
- 需求管理工具
- 业务建模方法
- 需求建模...
答疑
敏捷开发技术最佳实践(统一敏捷开发过程)
Upcoming SlideShare
Loading in …5
×

敏捷开发技术最佳实践(统一敏捷开发过程)

1,069 views

Published on

敏捷开发技术最佳实践的介绍

Published in: Technology
  • Be the first to comment

敏捷开发技术最佳实践(统一敏捷开发过程)

  1. 1. 敏捷开发技术最佳实践 (统一敏捷开发过程) 钟玮军 2016-04
  2. 2. • 现任: – 北京车网互联科技股份有限公司 (资深架构师&研发中心副总经理) • 历任: – 卓望科技股份有限公司(飞信系统架构师) – 诺基亚西门子科技股份有限公司(开发工程师&团队Leader) – 中国电信(网络运行管理工程师) • 专注于: – 研发管理、产品流程 – 敏捷开发、需求分析、系统架构、领域驱动开发 • 感兴趣: – 企业架构方法、企业管理 • 联系: – zhongweijuncn@hotmail.com 关于作者
  3. 3. 目 录 Contents 背景介绍 基础知识 统一敏捷开发过程 总结 思考与答疑
  4. 4. 背景介绍
  5. 5. 流行软件开发流程框架比较
  6. 6. 影响敏捷开发过程成败的关键因素 1、团队目标 (What to do) 2、团队文化 (Why we together) 3、管理制度 (How to support) 4、团队能力 (How to achieve) 6、技术和工具 (How to be efficient)
  7. 7. 敏捷开发流程实施的技术能力障碍 • 流程框架本身缺乏对需求、分析、设计、实现等各阶段工作的方法性指导; • 书籍和文献往往侧重于单一阶段工作的方法性描述,但难以形成体系; • 没有经验的开发团队难以落地; A Unified Process?
  8. 8. 培训目标 • 借鉴当前敏捷开发技术最佳实践,形成贯穿软件研发 各阶段的统一敏捷开发过程框架,为敏捷团队顺利实 施敏捷项目研发提供技术性指导。
  9. 9. 基础知识
  10. 10. (一)UML • UML(Unified Modeling Language)是什么? – 可视化的建模语言; – 是在Booch、OMT、OOSE等面向对象的方法及其它许 多方法与资料的基础上发展起来的,通用的建模语言, 有效的消除了各种建模语言之间不必要的差异。 • UML不是什么? – 不是一个开发过程; – 仅掌握UML表示方法,实际建模中仍会感到力不从心。
  11. 11. UML 2.x Diagrams
  12. 12. RUP 4+1视图 逻辑视图: - 层/子系统划分 - 类/对象静态结构及关联关系 - 包图、类/对象图、状态图是 常用图形 实现/开发视图: - 关注配置管理以及开发环境中 实际软件模块的组织结构 - 组件图/包图是常用的图形 过程视图: - 非功能性需求如性能、扩展性 和吞吐量等;体现了并发、分 布式和容错需求; - 系统间对象的交互接口和模式 部署/物理视图: - 指出系统硬件拓扑的节点 - 关注分布、通讯和配置 - 部署图是常用的图形 Use Case图 / 活动图 针对不同研发角 色的不同关注点 来组织视图。 侧重于模型如何 组织用以描述系 统,仍缺乏模型 开发过程的指导。
  13. 13. (二)ICONIX过程方法 需求 设计 实现ICONIX Process is a use case–driven analysis and design methodology. Its main focus is on how to get reliably from use cases to code in as few steps as possible. 分析
  14. 14. • 简洁: – Use Cases、Robustness Diagrams、Sequence Diagram、Class Diagram – 少数几个步骤就可以完成从用例到代码的建模 • 严谨: – 贯穿需求、分析、设计、实现,是一个Unified Process(统一过程) – 满足最终交付物与业务需求的一致性 • 充实敏捷流程框架,指导敏捷在项目中落地。 为什么推荐使用ICONIX过程?
  15. 15. ICONIX与UML模型视图 Describe Analyze
  16. 16. 用例图 注: - 系统用例指系统外部可见的一个系 统功能单元,一般用动词短语简述 系统的功能 - 在标准RUP流程中,通常与用例描述 结合使用,说明“Basic Flow”&“Alternative Flows”,在敏 捷方法中,可以用User Story + Storyboard + Wireframes辅以部分说 明性文字代替。 - 对系统用例而言,用例体现系统提 供给用户的价值即可,不需要“过 度建模”。(适可而止比废寝忘食 更难) - 关联表示参与者与用例之间的交互,通信途径,任何一方都可发送或接受消息,箭头指向消 息接收方 - 泛化关系是一般和特殊的关系,就是通常理解的继承关系 - 包含关系用来把一个较复杂用例所表示功能分解成较小的步骤 - 扩展关系是指用例功能的延伸,相当于为基础用例提供一个附加功能。 参与者是指在系统 外部与系统直接交 互的人或事物
  17. 17. 类图 http://creately.com/blog/diagrams/class-diagram-relationships/ 类之间的几种关系 类名 类属性 类操作 类关系 类图,在需求阶段主要用作领域模型的建模,在设计阶段, 主要用作系统类结构设计。 采用Model-Driven-Development方法,类结构模型通常可以 直接转为代码,从而降低人工编码成本。
  18. 18. 序列图 注: - 时序图体现了系统内部实现的设 计。 - 时序图各单元之间的交互消息命 名,应反应双方对于职责的约定。 - 时序图各单元之间的交互消息, 会转化为消息接收方的一个接口 方法。 - 采用“Boundary-Control-Entity” 三元素表示的的序列图建模,可 以很快映射到领域驱动模型设计 中的Service接口、Service接口实 现和Entity的设计,并且该建模方 式可以避免生成“贫血”的领域 对象模型。
  19. 19. 鲁棒图 鲁棒图目的: - 健全性检查(Sanity check) - 完整性检查(Completeness check) - 识别对象(Object Identification) - 初步设计(Preliminary Design) 鲁棒图的规则 鲁棒图的语法 Boundary Controller Entity 鲁棒图的作用 鲁棒图图例
  20. 20. (三)领域驱动设计 领域驱动设计(Domain Driven Design)是一种软件开发方法,目的是让 软件系统在实现时准确的基于对真实业务过程的建模并根据真实业务过程 的调整而调整。
  21. 21. 通用语言 • 领域专家和开发者建立并使用通用语言(UBIQUITOUS LANGUAGE)是领域驱动设计的核心思想,却又往往不被开 发团队重视。 • 领域驱动设计的一个核心思想就是基于模型的共同语言。 使用模型作为语言的核心骨架,要求团队在进行所有的交 流都是使用一致的语言,在代码中也是这样。在共享知识 和推敲模型时,团队会使用语言、文字和图形。这儿需要 确保团队使用的语言在所有的交流形式中看上去都是一致 的,这种语言被称为“通用语言(Ubiquitous Language)” • 领域专家和开发者应该共同维护一个通用语言的词汇表, 保证模型内部的一致性,每个术语都不会有摸棱两可的意 义(避免重复的概念和假同源),也不会有规则冲突。除 非模型在逻辑上是一致的,否则它就没有意义。
  22. 22. 领域模型的切分  在理想的世界中,我们可以有一种 把整个企业领域包含进来的单一模 型;这个模型将是统一的,没有任 何相互矛盾或相互重叠的术语定义; 每个有关领域的逻辑声明都将是一 致的。但大型系统开发并不是这样 理想,常常需要对领域进行切分。  大型系统领域模型的完全统一是不 可行的,也不是一种经济有效的做 法。我们可以采用限界上下文 (Bounded Context)定义每个模型 的应用范围,采用上下文映射 (Context Map)给出项目上下文以 及它们之间关系的总体视图。
  23. 23. 领域系统的集成 在以领域模型为核心的六边形架构中,建议通过适配器与其他领域系统进 行集成,以避免领域系统之间存在紧耦合关系。
  24. 24. 领域驱动设计架构风格 领域驱动设计是OOAD的一个扩展和延伸,DDD基于面向对象分析与设 计技术,对技术框架进行了分层规划,同时对每个类进行了策略和类型的 划分。 分层规划 面向对象 策略和类型划分
  25. 25. 领域驱动设计分层架构模型 DDD是分层架构模型。DDD架构风格可以与SOA架构风格实现完美融合。
  26. 26. 领域驱动设计CQRS架构风格 Client Commands Command Bus Sends Command Handlers Modify Repositories Read Write Data store Event Bus Command Services Event Handlers Events Read store Query HandlersQuery Results Queries Query Services Events Domain
  27. 27. 领域驱动设计与模型驱动开发 由于对每个类进行了策略和类型的划分,针对不同策略和类型的类提取重 复出现的相似代码,也为模型驱动开发的自动化代码生成提供基础。
  28. 28. 参考文献与资料 网站资料: - ICONIX:http://www.iconixsw.com - UML:http://www.uml.org - Domain Driven Design:http://www.domaindrivendesign.org
  29. 29. 统一敏捷开发过程
  30. 30. (一)需求分析 • 需求是指: – 用户解决问题或达到目标所需条件或能力; – 系统或系统部件要满足合同、规范或其它正式规定文档所需 具有的条件或能力; – 一种反映上述所描述的条件和能力的文档说明,是以一种清 晰、一致且无二义性的方式对目标系统各个有意义方面陈述 的一个集合。 • 需求和需求管理的目的: – 客户确认,确保我们正在做正确的产品; – 验证测试,确保我们做出的产品是正确的。
  31. 31. 需求的层次 业务分析 业务需求 (Epics) 用户需求 (Stories) 功能需求 (Functional) 设计 构建 软件需求的层次 需求类型 描述 业务需求 (Epics) 描述发起项目的原因、需达到的业务目标、以及衡量该项目是否成功的业务指标。 用户需求 (Stories) 描述所涉不同用户与系统接触的方式、以及他们期望协助系统所能完成的任务和目标。 功能需求 (Conversations) 是系统对于用户需求的具体实现,它定义了系统计算、数据的操作处理、用户与应用 的接口和交互,以及其它能体现用户需求如何被满足的特殊功能。 非功能需求 指的是信息系统中保证性能、可靠性、易用性、维护性、扩展性、移植性和安全性等 各类与系统运行状态有关,但与功能需求无关的需求。
  32. 32. 需求的层次(续)
  33. 33. 需求分析方法 需求捕获:  访谈  小组会议  问卷调查  其它: ∙ 现场观摩 ∙ 文档考古(分析客户/用户已有的业务、信息建设的文档) ∙ 原系统研究(现在的系统问题、改进要求) ∙ 分析同类软件产品特性(文档或试用软件分析)
  34. 34. 需求建模方法 业务用例 图 业务用例 时序图 用户需求 User Story 描述 UX设计 (故 事板) 系统用例 图 系统分析 鲁棒图 愿景 领域概念 模型
  35. 35. (1) 愿景 • 什么是愿景: – 在“老大” 看来,引进 这个系统的 目的是什么? • 为什么要明 确愿景: – 缺乏清晰、 共享的愿景 往往是项目 失败的主要 原因。 参考:《软件方法 – 业务建模和需求》,潘加宇 source: internet
  36. 36. 愿景的明确 • 寻找“老大” – “老大”就是为项目拍板签字买单的人; – 系统改善哪个组织的流程?“老大”就是该组织的负责人; – 系统好坏的度量指标应该藏在“老大”的大脑里。 – 做产品而不是项目时,老大就是产品所定位的具体组织和人 群。
  37. 37. 愿景的明确(续) • 明确可度量的目标 – 愿景是改善组织的指标(从而获取竞争优势),不是做某事; – 不要把系统的功能当作愿景,而应回答这个系统对购买系统 的组织有什么好处; – 采用恰当的愿景描述的粒度,不要把组织的目标当作系统的 目标; – 必要的时候,需要揣摩“老大”的目标,并对目标排序。 • 关注系统最重要涉众的利益,但不要盲从涉众的利益
  38. 38. (2) 业务建模 • 业务建模的目 的 – 从组织的角度 来定位系统应 该提供的价值; – 缺乏系统的业 务建模过程、 拍脑袋需求是 引起“需求容 易变化”的根 源之一。 http://www.enterpriseunifiedprocess.com/
  39. 39. 业务建模的核心概念 • 业务参与者(Business Actor) – 业务活动的服务对象 – 在组织之外和组织交互的人群或组织 • 业务工人(Business Worker) – 在组织内部承担一系列职责,为业务执行者实现业务服务的人 – 也包括替代人工作的内部IT系统,即Automated Business Worker • 业务实体(Business Entity) – 代表业务执行者在进行业务活动时使用或产生的事物,在表现形式上可 以是一个文档,或者是一个物品的一部分。餐厅中的菜单、汉堡等都是 业务实体。 – 业务实体设计的主要工作包括找出业务实体,确定业务实体的属性和行 为。要确定业务实体,首先必须确定业务参与者,并从业务参与者的行 为找出业务实体。
  40. 40. 业务建模的核心概念(续) • 业务用例(Business Use Case) – 业务用例是指业务参与者希望通过和组织交互达到的,而且组织能提供 的价值。 – 业务用例代表组织的本质价值,很难变化,改变的是业务用例的实现。 – 是对组织内部流程的说明,它定义一组业务用例实例。 • 业务用例实例(Business Use-Case Instance) – 业务用例实例是指业务用例的一次执行,在业务中执行的一系列动作, 这些动作为业务的个体主角产生具有可见价值的结果。 – 多个不同业务用例的实例,以及一个业务用例的实例,通常能够并行执 行;每个业务用例实例的执行,有时候可能存在不同的业务执行路径; 我们通常以工作流的方式描述这些执行路径。 – 举例:点餐是一个业务用例,而客户的某次点汉堡、点薯条就是相对应 的业务用例实例。
  41. 41. 业务建模步骤 • 发现业务用例并建模(业务用例图/业务描述) – 业务用例是指业务参与者希望通过和组织交互达到的,而且组织 能提供的价值; – 选定要改进的组织(选定组织的范围要合适) – 寻找业务参与者(对准组织的边界) – 识别业务用例的两条路线: • 一条是从业务参与者开始,思考业务参与者和组织打交道的目的(主要路 线)。 • 另一条是通过观察组织的内部活动,一直问为什么,外推到组织外部的某 个业务执行者(补漏路线) • 对业务实现现状进行建模(时序图/活动图/BPMN图) • 改进业务实现(流程自动化/精化业务流程/精化角色职责) • 开发领域模型
  42. 42. 业务建模示例:业务用例建模 • 正确地划定边界 – 思考的边界在哪 儿? – 识别业务参与者 和业务工人 • 统一用例粒度 – 价值而非实现 • 用例描述 – 描述目的是什么 (What)而不是怎么 实现(How)
  43. 43. 业务建模示例:业务用例分解 业 务 流 程 解 耦 / 分 解
  44. 44. 业务建模示例:业务用例分解(续)
  45. 45. 业务建模示例:业务用例+用例描述 • Basic Flow for Prepare Tender – This business use case begins when the End User Department requires additional automation to improve operations. The goal is to finalize a tender document that can be issued to candidate vendors. – 1. Designation of End User Manager. The procurement department designates an End-User Manager for the entire acquisition process. – 2. Prepare System Specifications. The End-User Manager prepares and submits specifications to the IT department. – 3. Prepare Tender Document. The IT department reviews submitted specifications and prepares a tender document, augmenting the submitted specifications with contractual requirements. – 4. Approval of Tender Document. The End-User Manager reviews and approves the tender document. The use case then terminates. • Alternate Flows – 1. System Specifications Invalid. In Step 3, if the IT department finds the system specifications are too vague or unfeasible, the End-User Manager needs to rework the specifications. The business use case then either resumes at Step 2 or terminates if the End-User Manager does not wish to continue. – 2. System Already Exists. In Step 3, if the IT department finds that the desired system is very similar to an existing system in another department, then the IT department refers the End-User Manager to that department. If the End-User Manager wishes to proceed with acquiring the "new" system, he or she must put the differentiating features in the system specifications, resubmit the specifications, and continue at Step 2. The business use case terminates if the End-User Manager does not wish to continue. – 3. Tender Document Discrepancies. In Step 4, if the End-User Manager notices discrepancies in the Tender Document, it is rejected, and the IT department must rework it. The business use case continues at Step 3. class Business Use Cases «business actor» End User Manager Prepare Tender Select Vendor «business actor» Vendor Manager
  46. 46. 业务建模示例:业务实现建模 – 时序图 sd Interaction «business actor» End User Manager IT Project Manager Enterprise Architect Legal Officer Supplement Tender with Legal Terms() Review Tender Document() Prepare System Specification() Prepare Tender Document() Review and Supplement System Specification() • 关注工作流程 • 重点在于区分职 责而非信息流 典型错误:
  47. 47. 业务建模示例:业务实现建模 – 时序图(续) • 业务实现优化 – 引入自动化业务 工人(信息系统) 后的时序图变化 – 物流改成信息流 – 信息流改善 – 封装领域逻辑 sd Interaction2 «business actor» End User Manager IT Project Manager Enterprise Architect Legal Officer Tender Management System Contract Management System Review and Supplement System Specification() Prepare System Specification() Supplement Tender with Legal Terms() Prepare Tender Document() Review Tender Document() Search Contracts()
  48. 48. 业务建模示例:业务实现建模-活动图 • 可选,实现更 细粒度的业务 流程建模
  49. 49. 业务用例示例:业务实现建模-活动图(续) • 可在活动图中添加业 务实体
  50. 50. 业务建模示例:业务实现建模-BPMN图 Pool Lane Start Event End Event Activity Gateway Sequence Flow Message Flow Event • 与UML活动图功能 作用相似,建模时 可以互相替代 • 可以直接输出到工 作流引擎,完成流 程实现
  51. 51. 业务建模示例:业务实体/对象协作关系 • 通过用例描述发 现识别业务对象 和业务实体 • 可以使用协作图 对业务对象和业 务实体之间的协 作关系进行建模, 从而进一步发现 业务实体关系 sd Interaction-Communication :End User Manager Contract Legal Terms Tender DocumentSystem Specifications IT Project Manager Enterprise Architect Legal Officer 1: Prepare System Specifications() 2: Prepare Tender Document() 3: Review and Supplement System Specifications() 3.1: Supplement System Specifications() 4: Review and Supplement with Legal Terms() 4.1: Search Contract() 4.2: Update Legal Terms()
  52. 52. (2)系统需求 • IT系统的本质是 将企业(或现实 生活)现有流程 全部或部分自动 化,从而达到优 化企业流程(或 用户体验)的目 的 • 图中展示了从对 流程改进想法落 实到IT系统建设 需求的一般过程
  53. 53. 系统需求:思考边界转换 • 研究对象从研究组织,转变为研究系统
  54. 54. 系统需求示例:用户需求建模-系统用例图 • 区分系统需求与 系统需求实现的 区别 • 建模的用例粒度 控制到“系统对 用户提供的价 值”,即用户需 求层次,不需要 过细。 uc Prepare Tender Document TenderSystem End User Manager Enterprise Architect IT Project Manager Legal Officer Contract System Prepare System Specification Rev iew Tender Document Supplement Tender with Legal Terms Prepare Tender Document Rev iew and Supplement System Specifications
  55. 55. 系统需求示例:用例描述 • Basic Flow – This use case begins when the End-User Manager wants to review a tender document after being notified by the IT Project Manager that the document has been completed. – 1. List Tender Documents. The system retrieves and displays a summary list of Tender Documents for the End-User Department, showing their status. – 2. Open Tender Document. The End-User Manager selects a Tender Document. The system retrieves and displays it. – 3. Review Tender Document. The End-User Manager reviews the system specifications and legal terms. – 4. Tender Document Acceptable. If the End-User Manager accepts the contents, she or he approves the document. The system notes the decision, and the IT department can now open the tender for bidding. The use case terminates. • Alternate Flows – 1. Legal Terms Unacceptable. If in Step 3 of the Basic Flow the End-User Manager finds the Legal Terms unacceptable, the reasons for rejecting them is noted. The system notifies both the IT Project Manager and the Legal Officer of the rejection. The use case terminates. – 2. System Specifications Unacceptable. If in Step 3 of the Basic Flow the End-User Manager finds the System pecifications unacceptable, the reasons for rejecting it are noted. The system notifies both the IT Project Manager and the Enterprise Architect of the rejection. The use case terminates. Review Tender Document用例描述:
  56. 56. 系统需求示例:交互流程设计-活动图 图例选自 http://pattydavididportfolio.weebly.com/samples.html • 现阶段关注交互 流程,而非页面 布局 • 涉及多角色协作 完成的业务流程, 宜使用业务流程 图(BPMN图例 或UML序列图例 或泳道活动图)、 鲁棒图作为建模 手段或辅助设计 手段
  57. 57. 系统需求示例:交互流程设计-活动图(续) • 涉及多角色协作 完成的业务流程, 可以采用泳道活 动图(或BPMN图) 作为界面交互的 辅助设计手段; • 泳道活动图(或 BPMN图)可以 帮助同时展现线 上线下工作。
  58. 58. 系统需求示例:交互流程设计-鲁棒图 • 涉及多角色协作完 成的复杂业务流程, 鲁棒图能清晰展示 业务全貌(交互功 能需求-角色职责 逻辑-业务实体单 元) • 鲁棒图 “Boundary- Controller-Entities” 式结构方式,契合 交互层的MVC设计 模式,易于衔接前 端开发 sd Prepare Tender Document :End User Manager TenderDocumentManagementUI Dispaly New Tender Page New Tender Page PrepareTenderDocumentUI CreateTenderDocumentPreparingProcessInstance TenderDocumentPreparingProcessInstance NotifyAssignees :IT Project Manager PrepareTenderDocument TenderDocument DisplayTenderDocumentPreparingProcessInstance TenderDocumentPrepareingProcessInstanceUpdated :Enterprise Architect :Legal Officer RequiredSystemSpecifications ReviewAndSupplementSystemSpecificationsUISupplementSystemSpecifications ReviewAndSupplementLegalTerms SystemSpecifications ReviewTenderDocumentPage SupplementLegalTerms Assignee LegalTerms Search Contract SearchContractInterface:Contract System ApproveOrRejectOrCancel TenderDocumentPreparingTasks NewTenderButton SubmitTaskButton
  59. 59. 系统需求示例:交互流程设计-线框图 图例选自 http://www.creativeuxdirector.com/casestudy.html#
  60. 60. 系统需求示例:领域模型建模 class DomainModels TenderDocumentPreparingProcessInstance TenderDocumentPreparingTask TaskAssignee TenderDocument + New() + UpdateSystemSpecifications() + CompleteSystemSpecificationsSupplement(): void + UpdateLegalTerms() + CompleteLegalTermsSupplement(): void + AcceptTenderDocument() + RejectTenderDocument(): void RequiredSystemSpecifications + update() SystemSpecifications + update() LegalTerms + update() Contract User Role +related 0..*1 1..* • 领域模型是对领域内的 概念或现实世界中对象 的可视化表示。领域对 象拥有足以满足不同用 例要求的关系、属性和 操作。 • 领域模型建模通常不是 一次完成,而是围绕用 例分析不断迭代精化。 • 领域模型建模可以考虑 采用支持模型驱动开发 的工具和语言实现完成, 便于后期依据模型自动 化生成代码框架。
  61. 61. 系统需求示例:领域模型建模(续) • 除了领域对象之间的关系,领域对象自身状态转换的动态 行为也非常重要,可以采用状态迁移图来对此进行建模。
  62. 62. (3)敏捷需求方法 • 敏捷的需求原则 – Satisfy the Customer / Excellent at Quality – Welcome Change / Deliver Frequently / Maintain Constant Pace – Measure Working Software – Keep it Simple
  63. 63. 敏捷需求方法:战略工具-寻找商机 寻找商机: - 移情:理解你 的用户 - 定义:识别问 题 - 构思:头脑风 暴,形成思路 - 原型:用线框 图或代码快速 搭建原型 - 验证:验证并 优化
  64. 64. 敏捷需求方法:战略工具-商业模式设计 商业模式描述了企 业如何创造价值、 传递价值和获取价 值的基本原理。 商业模式画布是一 种用来描述商业模 式、可视化商业模 式、评估商业模式 以及改变商业模式 的通用语言。 参考:《商业模式 新生代》
  65. 65. 敏捷需求方法:战略工具-产品战略 精益画布是从商 业模式画布改编 而来的,具有制 作迅速、内容紧 凑、方便携带的 特点,便于创业 者记录和交流自 己的商业模式。 我们可以把新产 品开发当作一次 创业来看待。 参考:《精益创 业实战》
  66. 66. 敏捷需求方法:战略工具-产品战略(续) http://blog.vsharing.com/zhoujg/A1790490.html 精益画布的拓 展版,增加了 更多商业计划 的元素,使产 品战略更具可 执行性。
  67. 67. 敏捷需求方法:战略工具-产品定位 • 价值主张画布模型 https://strategyzer.com/books/value-proposition-design
  68. 68. 敏捷需求方法:需求调查-客户角色模型 • 收集和评估所有已有的关于用户的知识,找出知识差距,创建客户角色模型。一 个客户角色模型,应当完整的描述出客户使用你产品/服务的目的和行为。 http://thepathforward.io/the-importance-of-personas-and-user-journeys/
  69. 69. 敏捷需求方法:需求调查-绘制客户旅程 • Customer Journey Map(客户旅程地图),描述客户在使用产品或者服务时的体验、 主观反应和感受,发现客户每一阶段的痛点,以及客户在这个阶段想要什么。 http://thepathforward.io/the-importance-of-personas-and-user-journeys/
  70. 70. 敏捷需求方法:需求管理-描述 • 用户故事 As a <USER ROLE>, I want a <FUNCTIONALITY> So that I can get <BUSINESS VALUE>. 基于目标和场景驱 动,体现业务价值
  71. 71. 敏捷需求方法:需求管理-描述(续) http://www.slideshare.net/AgileLietuva/viktor-kisko-discover-to-deliver-agile-product-planning- and-analysis?qid=034c867c-1117-4e48-a9e4-eea41f99f0a3&v=&b=&from_search=2
  72. 72. 敏捷需求方法:需求管理-粒度 • 需求满足的2/8原则, 以迭代的方式进行需 求分析 • 按照业务优先级次序, 将大粒度的用户需求 (用户故事)拆解为小 粒度的用户需求(用 户故事),并依次经 过评估后安排进入 Release计划和Sprint 计划。影响业务优先 级次序的因素包括: – 业务价值 – 依赖 – 复杂度和成本 – 风险
  73. 73. 敏捷需求方法:需求管理-粒度(续)
  74. 74. 敏捷需求方法:需求管理-工具
  75. 75. 敏捷需求方法:产品规划-影响地图 • 对产品开发和运营组 织,影响地图(Impact map)是一个简单却又 十分高效的范围管理、 战略规划和协作方法。 它在产品目标和范围 之间建立了清晰、完 整和动态映射关系; 以此为基础有效地规 划和沟通产品路线图 和计划,提高组织动 态响应变化能力的同 时,确保功能交付和 业务目标一致。
  76. 76. 敏捷需求方法:产品规划-影响地图(续)
  77. 77. 敏捷需求方法:产品规划-版本计划 • 用户故事地图 (User Story mapping) – 决定构建优先级 – 鼓励迭代开发 – 确定项目范围 – 制定版本计划 – 排序和梳理 Backlog – 可视化项目进度 User Activities (Backbone) User Tasks (Walking Skeleton) User Stories http://www.slideshare.net/SteveRogalsky/user-story-mapping-in-practice
  78. 78. 敏捷需求方法:产品规划-版本计划(续) • 从影响地图(Impact mapping)到用户故事地图(User Story Mapping) – 每一个版本都应当有明确的商业意图,形成合力 – 通过KPI指标对结果进行监控,评测产品版本 Our Job is NOT to develop software, our job is to change the world. - Jeff Patton http://www.slideshare.net/chassa/2014-0618srdimpact-mapsstorymapsen
  79. 79. 敏捷需求方法:产品规划-版本计划(续2)
  80. 80. 敏捷需求方法:版本计划-MVP • 到目前为止,上述所有的想法(包括你对于用户痛点的解决方案)都 是假设,这些假设都需要通过构建产品原型找到真实客户进行验证。 I tested my MVP with real customers – now I know what they want and need
  81. 81. 敏捷需求方法:版本计划-MVP(续) • 也可以通过线框图 产品设计原型的方 式验证用户需求, 但往往不能代替真 正可运行的产品所 起到的验证效果 • MVP(Minimum Viable Product,最 简化可视性产品) 的 功用就是让你拿来 接触客户,从很早 就根据客户的回馈 来改进你的产品。 – Must-have – 正确地“试错”
  82. 82. 敏捷需求方法:版本计划-MVP(续2) • 确定MVP – 客户调查 – 确定功能的四 象限 • 值得注意的是, 随着时间推移, 曾经属于加分 项的功能需求 可能慢慢变为 用户的基本需 求 – 壁垒 Delighters • Things customers are excited about Basic features • Things customers need • “Must Be” Performance Indifferent • More is better • Not needed
  83. 83. 敏捷需求方法-成果评估 • 通过数字化方法进行结果评估而不是仅凭“感觉” – 避免主观偏见、错误判断 http://www.slideshare.net/dan_o/product-management-by-numbers-using-metrics-to-optimize-your-product-by-dan-olsen-presentation
  84. 84. 敏捷需求方法:成果评估(续) • 营销漏斗与KPI指标设定
  85. 85. 敏捷需求方法:成果评估(续2) • 采用A/B测试技 术评估更好的用 户体验交互设计
  86. 86. (二)系统设计 • 系统设计的任务是: – 综合考虑客户需求、业务目标和技术代价等各方面的因素 – 根据需求分析阶段对系统的逻辑功能的要求,并考虑到经济、 技术和运行环境等方面的条件,确定系统的总体结构和系统 各组成部分的技术方案,合理选择计算机和通信的软、硬件 设备,提出系统的实施计划,确保总体目标的实现。
  87. 87. 系统设计:八项内容 System Design 1. Identify Design Goals Additional NFRs Trade-offs 2. Subsystem Decomposition Layers vs Partitions Coherence & Coupling 3. Identify Concurrency Identification of Parallelism (Processes, Threads) 4. Hardware / Software Mapping Identification of Nodes Special Purpose Systems Buy vs Build Network Connectivity 5. Persistent Data Management Identification of Nodes Storing Persistent Objects Filesystem vs Database 6. Global Resource Handling Access Control ACL vs Capabilities Security 7. Software Control Monolithic Event-Driven Conc. Processes 8. Boundary Conditions Initialization Termination Failure
  88. 88. (1)系统设计目标 • 可靠性 • 可修改性 • 可维护性 • 易理解性 • 适用性 • 可重用性 • 高效性 • 可移植性 • 需求可追踪性 • 容错性 • 向后兼容性 • 高性价比 • 健壮性 • 高性能 • 良好的文档 • 良好定义的接口 • 用户友好性 • 组件重用 • 快速开发 • 最少错误 • 可读性 • 易学 • 易记 • 易用 • 提高工作效率 • 低价 • 灵活性 • ……
  89. 89. 系统设计:设计目标(续) 便宜 提高工作效率 向后兼容 需求可追踪 快速开发 灵活性 运行态高效 可靠性 功能性 用户友好性 可用性 易学性 容错性 健壮性 可移植性 良好的文档 最少错误 可修改性、可读性 可重用性、灵活性 良好定义的接口 客户 最终用户 开发/维护人员
  90. 90. (2)系统分解-子系统/组件划分 重用性 可读性 扩展性 可测性 可变性 并行开发 高内聚低耦合
  91. 91. 系统分解-原则和方法 《一线架构师实践指南》,温昱
  92. 92. 系统分解-分层与分区 • 分层(Layer): – 一个分层只能依赖比它更低的分层所提供的服务 – 一个分层不应该知道比它更高的分层的相关知识 • 分区(Partition): – 某一分层可以被垂直划分为几个独立的子系统 – 分区可以向同一分层的其它分区提供服务 – 分区通常也被称为“松耦合”的子系统
  93. 93. 系统分解-分层结构 pkg Component Model Infrastructure(Frameworks) Presentation Infra Infrastructure(Common Utilities) Application Assembly Business Domain Application Infra Domain Model Infra Persistence Infra Cross Cutting Domain Model Domain Repository Impl Application Query Model Distributed Interface Presentation Distributed Infra Web Clients (UI Views, Controllers, etc) Web-Services DTOs Application Services Components(Workflow, etc) DomainServicesDomain Objects (Entities, VOs) RepositoryContracts Result View Objects Queries Data Integration Security(Authentication, Authorization &Auditing) Monitoring (Warning&Alarm, Functional&Performance) diagnosable(Exception, Log&Trace) Integration Services (UI/Service/Data Integartion, extendable) 注:包层次结构的依赖关系 • 按照组件的可重用性进行分层
  94. 94. 系统分解-分区结构 Sales Product SKU Name Price Quantity Ordered … Inventory Service (SAP) Product SKU QOH Location Code … Pricing Service Product SKU Unit Price Promotional Price … Inventory Pricing Sales Customers New SKU Event New SKU Event New SKU Event Order Accepted Event MessageBus Who coordinates the sales process? Online Ordering System Web Shop (Composite UI) • 按照业务领域/服务职责进行分区
  95. 95. 系统分解-CQRS架构 • 将Command和Query模型进行分离,有利于子系统解耦。
  96. 96. 系统分解-模型方法 • 使用组件图 说明应用开 发框架视图 的示例(侧重 于重用)
  97. 97. 系统分解-模型方法 • 使用框图说 明系统应用 架构的示例 (侧重于领域 分区)
  98. 98. 系统分解-模型方法 • 借助用例图进行领域服务上下文映射(Context Map)的示例
  99. 99. 系统分解-模型方法(续) • 借助鲁棒图进行领域模型上下文映射(Context Map)的示例 鲁棒图中控制对象的数 量不超过5个,该条定 律是否必须要遵守? 答案当然是否定的。鲁 棒图及其它UML图形建 模的要点在于,首先定 义该图想要向读者传达 的设计意图,然后设计 粒度控制到足以表达该 意图即可,不可过细。 控制对象2~5个是对初 学者的提示性要求,但 实际运用中可以灵活掌 握。
  100. 100. 系统分解-模型方法(续) • 使用组件图 说组件组成 和子系统间 接口关系的 示例
  101. 101. (3)并发设计 • 系统并发进程/线程在同一时刻变更同一对象状态,可能导致该 对象内部状态的不一致,引起系统执行结果的错误。 – Restful:无状态 – 强一致性(数据库事务控制) – 最终一致性/跟踪单据(根据业务场景选择解决方案)
  102. 102. (4)物理架构设计 - 软件/硬件映射 • 部署架构视图着重考虑运行软 件的计算机、网络、硬件设施 等情况,还包括如何将软件包 部署(如果是嵌入式系统则是 烧写)到这些硬件资源上,以 及它们运行时的配置情况。 • 物理架构还要考虑软件系统和 包括硬件在内的整个IT系统之 间是如何相互影响的,由于一 部分运行质量属性需要硬件或 网络的支持,所以物理架构必 须关注如何配置硬件和网络来 满足软件系统的可靠性、可伸 缩性、持续可用性、性能、安 全性等方面的要求。 《一线架构师实践指南》,温昱
  103. 103. 物理架构设计-模型方法 • 使用部署图表 示系统和组件 与物理设备之 间的部署关系 示例。
  104. 104. 物理架构设计-模型方法 • 网络设计的逻 辑拓扑和物理 拓扑示例
  105. 105. (5)数据存储设计 • 用例驱动结合鲁棒图分析方法持续更新领域模型 • 根据数据存取特点(如应用场景、事务一致性要求、数据 容量、数据增长、结构特点、存取频率、性能要求、安全 需求、成本控制等)选择数据存储和容灾备份方案 – 关系型数据库/非关系型数据库/文件系统/缓存数据库 – 集中式/分布式 – 通用/专用 – 本地/同城/异地 – 商用/开源 – 临时/周期/永久 • 选择ORM框架
  106. 106. (6)系统安全设计 技术安全 管理安全 安全信息系统(技术+管理) 物理安全 网络安全 主机安全 应用安全 数据安全 管理机构 管理制度 人员管理 系统建设 运维管理 电磁防护 防潮温湿度 防雷放火 访问控制 物理位置 入侵防范 网络设备 网络审计 访问控制 网络结构 资源控制 资源保护 安全审计 访问控制 身份鉴别 代码安全 抗抵赖 安全审计 访问控制 身份鉴别 …… 数据恢复 数据备份 数据保密性 数据完整性 审核与检查 沟通与合作 授权和审批 人员配置 岗位设置 审批和修订 制定和发布 管理制度 第三方人员 教育培训 人员考核 人员离岗 人员录用 工程实施 软件开发 产品采购 方案设计 系统定级 应急预案 设备管理 介质管理 资产管理 环境管理 • IT安全总体架构 – 技术安全 • 物理安全 • 网络安全 • 主机安全 • 应用安全 • 数据安全 – 管理安全 • 管理机构 • 管理制度 • 人员管理 • 系统建设 • 运维管理
  107. 107. Web Server 系统安全设计–WEB网站安全技术 • WEB网站安全通用技术措施 Firewall Apps Host Firewall Application Server Apps Host Database Server Host Database Securing the Network Router/Firewall/Switch 网络分区、端口管理、流量监控 和带宽管理、防flood攻击、入侵 检测及入侵检测防御、安全审计 认证、防病毒、防垃圾和病毒邮 件、VPN安全连接、设备账号、 网络冗余、故障恢复等 Securing the Host 系统补丁和系统更新、系统账号权限、文件目录权限、系统服务、网络端口和协议、共享资源、审 计和日志等 Securing the Application 输入验证、用户认证授权、配置安全、敏感数据、会话管理、密 码安全、参数篡改、异常管理、集群部署与负载均衡、故障恢复、 审计和日志等 Securing the Database 用户访问授权、数据加密、、 数据完整性检查、SQL注入 检查、冗余备份方案、故障 恢复
  108. 108. 系统安全设计-WEB网站安全技术(续2) • WEB网站安全通用技术措施列表检查项示例
  109. 109. (7)算法控制模型 • 根据软件逻辑算 法要求,选择合 理的算法控制模 型。 – Implicit Control: 多见于知识系统 – Decentralized Control:多见于 依赖大量计算资 源的复杂计算 – Centralized Control:一般计 算
  110. 110. (8)异常处理 • 系统设计应能预见到系统可能发生的致命错误,并提 供处理机制 – 初始化 • 系统从一个未初始化的状态转化到稳定状态 – 终止运行 • 系统资源应被释放,相关系统应得到通知 – 错误 • Bugs, Errors, External Errors
  111. 111. (9)敏捷设计方法 • 敏捷的设计原则 – 总体技术架构选型 • 应具备超前性(开发框架、集成方案) – 子系统/组件的设计 • Keep it Simple(不过度设计) • Evolve Designs(小步迭代) – 文档/模型 • 良好的文档有助于团队沟通和知识传播 • 控制文档及模型分析设计的描述粒度
  112. 112. (三)系统实现与交付 • 敏捷的系统实现最佳实践 – Model-Driven-Development – Continuous Integration – Non-stop Redeployment
  113. 113. 模型驱动开发 DDD+MDSD工具实例:sculptorgenerator http://sculptorgenerator.org/ 模型驱动开发技术概览: 模型驱动开发优点: • 开发更快速、开发成本更低 • 架构更强壮,提高开发质量,支持有效性验证,出错率更低 • 项目重心放在业务而不是技术,消除业务和IT之间的隔阂 • 有助于优化人力资源使用,解放高阶程序员,使其有更多的机会发挥创造性
  114. 114. 持续集成技术 http://www.slideshare.net/SonatypeCorp/nexus-and-continuous-delivery 持续集成技术: • 代码提交与版 本管理 • 自动编译 • 自动部署 • 自动测试 – UT(领域模型) – BDD(服务层) – 界面测试 • 自动报告
  115. 115. 不停服务升级 • 利用SOA或其它 分布式框架的服 务版本管理特性, 实现不停服务系 统升级
  116. 116. 总结
  117. 117. 总结 愿景/战略: - 愿景 - 机会模式画布 - 商业模式画布 - 精益画布 - 价值主张画布 - 企业架构方法 需求: - 客户角色分析 - 客户旅程地图 - 需求描述方法 - 用户故事切分 - 需求管理工具 - 业务建模方法 - 需求建模方法 - 领域对象建模 反馈: - 数字化评估方法 - AB测试 设计实现交付: - 敏捷架构设计方法 .目标/分解/并发/物理/ 存储/安全/算法控制/异常 .模型化分析和表示方法 - 模型驱动开发技术 - 持续交付技术 - 不停服务系统升级 组织: - 敏捷开发流程框架 - 研发过程管理规范体系建设 - 公司管理制度/组织结构/绩效考核 - 企业/团队文化 产品: - 影响地图(产品规划) - 用户故事地图(产品规划) - MVP版本发布计划 - 线框图产品交互设计
  118. 118. 答疑

×