您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 项目/工程管理 > 敏捷开发技术最佳实践(统一敏捷开发过程)
敏捷开发技术最佳实践(统一敏捷开发过程)钟玮军2016-04•现任:–北京车网互联科技股份有限公司(资深架构师&研发中心副总经理)•历任:–卓望科技股份有限公司(飞信系统架构师)–诺基亚西门子科技股份有限公司(开发工程师&团队Leader)–中国电信(网络运行管理工程师)•专注于:–研发管理、产品流程–敏捷开发、需求分析、系统架构、领域驱动开发•感兴趣:–企业架构方法、企业管理•联系:–zhongweijuncn@hotmail.com关于作者目录Contents背景介绍基础知识统一敏捷开发过程总结思考与答疑背景介绍流行软件开发流程框架比较影响敏捷开发过程成败的关键因素1、团队目标(Whattodo)2、团队文化(Whywetogether)3、管理制度(Howtosupport)4、团队能力(Howtoachieve)6、技术和工具(Howtobeefficient)敏捷开发流程实施的技术能力障碍•流程框架本身缺乏对需求、分析、设计、实现等各阶段工作的方法性指导;•书籍和文献往往侧重于单一阶段工作的方法性描述,但难以形成体系;•没有经验的开发团队难以落地;AUnifiedProcess?培训目标•借鉴当前敏捷开发技术最佳实践,形成贯穿软件研发各阶段的统一敏捷开发过程框架,为敏捷团队顺利实施敏捷项目研发提供技术性指导。基础知识(一)UML•UML(UnifiedModelingLanguage)是什么?–可视化的建模语言;–是在Booch、OMT、OOSE等面向对象的方法及其它许多方法与资料的基础上发展起来的,通用的建模语言,有效的消除了各种建模语言之间不必要的差异。•UML不是什么?–不是一个开发过程;–仅掌握UML表示方法,实际建模中仍会感到力不从心。UML2.xDiagramsRUP4+1视图逻辑视图:-层/子系统划分-类/对象静态结构及关联关系-包图、类/对象图、状态图是常用图形实现/开发视图:-关注配置管理以及开发环境中实际软件模块的组织结构-组件图/包图是常用的图形过程视图:-非功能性需求如性能、扩展性和吞吐量等;体现了并发、分布式和容错需求;-系统间对象的交互接口和模式部署/物理视图:-指出系统硬件拓扑的节点-关注分布、通讯和配置-部署图是常用的图形UseCase图/活动图针对不同研发角色的不同关注点来组织视图。侧重于模型如何组织用以描述系统,仍缺乏模型开发过程的指导。(二)ICONIX过程方法需求设计实现ICONIXProcessisausecase–drivenanalysisanddesignmethodology.Itsmainfocusisonhowtogetreliablyfromusecasestocodeinasfewstepsaspossible.分析•简洁:–UseCases、RobustnessDiagrams、SequenceDiagram、ClassDiagram–少数几个步骤就可以完成从用例到代码的建模•严谨:–贯穿需求、分析、设计、实现,是一个UnifiedProcess(统一过程)–满足最终交付物与业务需求的一致性•充实敏捷流程框架,指导敏捷在项目中落地。为什么推荐使用ICONIX过程?ICONIX与UML模型视图DescribeAnalyze用例图注:-系统用例指系统外部可见的一个系统功能单元,一般用动词短语简述系统的功能-在标准RUP流程中,通常与用例描述结合使用,说明“BasicFlow”&“AlternativeFlows”,在敏捷方法中,可以用UserStory+Storyboard+Wireframes辅以部分说明性文字代替。-对系统用例而言,用例体现系统提供给用户的价值即可,不需要“过度建模”。(适可而止比废寝忘食更难)-关联表示参与者与用例之间的交互,通信途径,任何一方都可发送或接受消息,箭头指向消息接收方-泛化关系是一般和特殊的关系,就是通常理解的继承关系-包含关系用来把一个较复杂用例所表示功能分解成较小的步骤-扩展关系是指用例功能的延伸,相当于为基础用例提供一个附加功能。参与者是指在系统外部与系统直接交互的人或事物类图类之间的几种关系类名类属性类操作类关系类图,在需求阶段主要用作领域模型的建模,在设计阶段,主要用作系统类结构设计。采用Model-Driven-Development方法,类结构模型通常可以直接转为代码,从而降低人工编码成本。序列图注:-时序图体现了系统内部实现的设计。-时序图各单元之间的交互消息命名,应反应双方对于职责的约定。-时序图各单元之间的交互消息,会转化为消息接收方的一个接口方法。-采用“Boundary-Control-Entity”三元素表示的的序列图建模,可以很快映射到领域驱动模型设计中的Service接口、Service接口实现和Entity的设计,并且该建模方式可以避免生成“贫血”的领域对象模型。鲁棒图鲁棒图目的:-健全性检查(Sanitycheck)-完整性检查(Completenesscheck)-识别对象(ObjectIdentification)-初步设计(PreliminaryDesign)鲁棒图的规则鲁棒图的语法BoundaryControllerEntity鲁棒图的作用鲁棒图图例(三)领域驱动设计领域驱动设计(DomainDrivenDesign)是一种软件开发方法,目的是让软件系统在实现时准确的基于对真实业务过程的建模并根据真实业务过程的调整而调整。通用语言•领域专家和开发者建立并使用通用语言(UBIQUITOUSLANGUAGE)是领域驱动设计的核心思想,却又往往不被开发团队重视。•领域驱动设计的一个核心思想就是基于模型的共同语言。使用模型作为语言的核心骨架,要求团队在进行所有的交流都是使用一致的语言,在代码中也是这样。在共享知识和推敲模型时,团队会使用语言、文字和图形。这儿需要确保团队使用的语言在所有的交流形式中看上去都是一致的,这种语言被称为“通用语言(UbiquitousLanguage)”•领域专家和开发者应该共同维护一个通用语言的词汇表,保证模型内部的一致性,每个术语都不会有摸棱两可的意义(避免重复的概念和假同源),也不会有规则冲突。除非模型在逻辑上是一致的,否则它就没有意义。领域模型的切分在理想的世界中,我们可以有一种把整个企业领域包含进来的单一模型;这个模型将是统一的,没有任何相互矛盾或相互重叠的术语定义;每个有关领域的逻辑声明都将是一致的。但大型系统开发并不是这样理想,常常需要对领域进行切分。大型系统领域模型的完全统一是不可行的,也不是一种经济有效的做法。我们可以采用限界上下文(BoundedContext)定义每个模型的应用范围,采用上下文映射(ContextMap)给出项目上下文以及它们之间关系的总体视图。领域系统的集成在以领域模型为核心的六边形架构中,建议通过适配器与其他领域系统进行集成,以避免领域系统之间存在紧耦合关系。领域驱动设计架构风格领域驱动设计是OOAD的一个扩展和延伸,DDD基于面向对象分析与设计技术,对技术框架进行了分层规划,同时对每个类进行了策略和类型的划分。分层规划面向对象策略和类型划分领域驱动设计分层架构模型DDD是分层架构模型。DDD架构风格可以与SOA架构风格实现完美融合。领域驱动设计CQRS架构风格ClientCommandsCommandBusSendsCommandHandlersModifyRepositoriesReadWriteDatastoreEventBusCommandServicesEventHandlersEventsReadstoreQueryHandlersQueryResultsQueriesQueryServicesEventsDomain领域驱动设计与模型驱动开发由于对每个类进行了策略和类型的划分,针对不同策略和类型的类提取重复出现的相似代码,也为模型驱动开发的自动化代码生成提供基础。参考文献与资料网站资料:-ICONIX:::统一敏捷开发过程(一)需求分析•需求是指:–用户解决问题或达到目标所需条件或能力;–系统或系统部件要满足合同、规范或其它正式规定文档所需具有的条件或能力;–一种反映上述所描述的条件和能力的文档说明,是以一种清晰、一致且无二义性的方式对目标系统各个有意义方面陈述的一个集合。•需求和需求管理的目的:–客户确认,确保我们正在做正确的产品;–验证测试,确保我们做出的产品是正确的。需求的层次业务分析业务需求(Epics)用户需求(Stories)功能需求(Functional)设计构建软件需求的层次需求类型描述业务需求(Epics)描述发起项目的原因、需达到的业务目标、以及衡量该项目是否成功的业务指标。用户需求(Stories)描述所涉不同用户与系统接触的方式、以及他们期望协助系统所能完成的任务和目标。功能需求(Conversations)是系统对于用户需求的具体实现,它定义了系统计算、数据的操作处理、用户与应用的接口和交互,以及其它能体现用户需求如何被满足的特殊功能。非功能需求指的是信息系统中保证性能、可靠性、易用性、维护性、扩展性、移植性和安全性等各类与系统运行状态有关,但与功能需求无关的需求。需求的层次(续)需求分析方法需求捕获:访谈小组会议问卷调查其它:∙现场观摩∙文档考古(分析客户/用户已有的业务、信息建设的文档)∙原系统研究(现在的系统问题、改进要求)∙分析同类软件产品特性(文档或试用软件分析)需求建模方法业务用例图业务用例时序图用户需求UserStory描述UX设计(故事板)系统用例图系统分析鲁棒图愿景领域概念模型(1)愿景•什么是愿景:–在“老大”看来,引进这个系统的目的是什么?•为什么要明确愿景:–缺乏清晰、共享的愿景往往是项目失败的主要原因。参考:《软件方法–业务建模和需求》,潘加宇source:internet愿景的明确•寻找“老大”–“老大”就是为项目拍板签字买单的人;–系统改善哪个组织的流程?“老大”就是该组织的负责人;–系统好坏的度量指标应该藏在“老大”的大脑里。–做产品而不是项目时,老大就是产品所定位的具体组织和人群。愿景的明确(续)•明确可度量的目标–愿景是改善组织的指标(从而获取竞争优势),不是做某事;–不要把系统的功能当作愿景,而应回答这个系统对购买系统的组织有什么好处;–采用恰当的愿景描述的粒度,不要把组织的目标当作系统的目标;–必要的时候,需要揣摩“老大”的目标,并对目标排序。•关注系统最重要涉众的利益,但不要盲从涉众的利益(2)业务建模•业务建模的目的–从组织的角度来定位系统应该提供的价值;–缺乏系统的业务建模过程、拍脑袋需求是引起“需求容易变化”的根源之一。业务建模的核心概念•业务参与者(BusinessActor)–业务活动的服务对象–在组织之外和组织交互的人群或组织•业务工人(BusinessWorker)–在组织内部承担一系列职责,为业务执行者实现业务服务的人–也包括替代人工作的内部IT系统,即AutomatedBusinessWorker•业务实体(BusinessEntity)–代表业务执行者在进行业务活动时使用或产生的事物,在表现形式上可以是一个文档,或者是一个物品的一部分。餐厅中的菜单、汉堡等都是业务实体。–业务实体设计的主要工作包括找出业务实体,确定业务实体的属性和行为。要确定业务实体,首先必须确定业务参与者,并从业务参与者的行为找出业务实体。业务建模的核心概念(续)•业务用例(BusinessUseCase)–业务用例是指业务参与者希望通过
本文标题:敏捷开发技术最佳实践(统一敏捷开发过程)
链接地址:https://www.777doc.com/doc-5089940 .html