分类： 架构师专栏

摘要

本人所在的单位是致力于为铁路和地铁提供技术服务和解决方案的研究机构。近年来由于地铁建设的不断扩张，线网式的管理日益受到了重视，为网络化运营的前提下，应对不同线路运营公司不同专业和不同的承包厂商，多个维度的应用的快速开发和集成，以及持续的进化的难点。需要设计新的适合场景的架构。在这样的背景下，2020年初某某城市地铁公司联合腾讯作为伙伴，一起派出人员组成了联合工作组，在线网智能运维项目中，推行以微服务为主的架构设计，业主同时提出解耦各专业厂商的应用和降低运维成本的要求。本人有幸加入在工作组中，主要负责了穗腾OS的架构设计和负责轨检专业的微服务集成工作。

联合小组最终开发出来的穗腾OS平台，它依托于腾讯云的paas。功能包括：协助各厂商接入智能运维平台，支撑了微服务的全面落地。此外还包括了地铁运维数据总线和算法/组件市场等子系统。本文着重从微服务的角度展开讨论。

正文

2020年某某城市的地铁线网智能运维平台开始建设。它被赋予线网级的综合监控和协调管理。这就面临着去集成既有的、已建设完且正在运营着的地铁线。以前建设此类平台的做法是依赖业主的铁腕，要建设的平台一般在业主的组织下与一家家的专业厂商谈接口协议，再开发调试，串行的去适配各家的单体应用。最后上线的运行效果且不说，耦合紧，工期长，变数多，后期维护成本高。面对这些待解决的痛点，联合小组提出了微服务为主的建设方案，各专业厂商的微服务需要接入穗腾os平台。在本文中首先介绍一下微服务的技术，再介绍微服务在项目中的用武之地—穗腾OS平台，最后结合实践的经历，阐述一下微服务的设计，服务治理和运维以及开发工具链。

首先，微服务是由Martin fowler最早提出的。它是SOA面向服务组件模型的一种实现，但它与同为分布式的esb企业服务总线不同，在微服务中服务提供者(provider)和服务消费者(consumer)之间并无转换和中间层，是去集中化的。同时服务提供者也可能是其它微服务的消费者。它允许各微服务以各自独立的技术栈开发。要加入智能运维平台的各专业厂商要横向拆分功能，以细粒度的组件方式提供。采用轻量级的协议。穗腾OS支持了HTTP/REST和dubbo等。微服务有小独轻松的特点，小不仅指拆分后的微服务灵活和功能单一，还指微服务的开发团体以小规模为佳，一般厂商团队都在5~7人，他们是特性团队，对微服务有着全生命周期的负责，包括设计开发、测试部署和交付。这和敏捷方法所倡导的理念高度契合。除了对团队规模要求不谋而合外，敏捷方法和微服务的初衷都是快速上线，尽早获得用户的反馈。而相信读者也能看出瀑布式的过程模型也由于自身原因很难实现细粒度单元的快速，流畅的交付。独的特点体现在独立的部署和交付，每个微服务也独立运行在各自的进程空间中。轻是指微服务的API无关性和使用HTTP和REST协议。解决了典型的RPC存在的调用者耦合问题。同时能快速搭建访问资源类的应用服务。REST把资源URL标识且在规范的http协议下设计操作（post、delete、put、get）。最后松是指松耦合，易复用。在穗腾OS运行时，提供了一些厂商级的公共微服务，比如身份认证，数据字典查询等。只要厂商提出调用申请，联合工作组开通其权限，厂商通过token凭证等信息即可使用。不然，如果项目中空调、电源、网检、轨检都自己去开发认证鉴权功能，将是极大的浪费，也不符合软件工程的思想。

穗腾os平台是paas，也就是厂商微服务部署和管理平台，智能运维平台应用的支撑环境。为方便厂商的微服务开发人员上手，本人带领联合小组开发了系列的demo模板工程， Java技术栈和GO语言使用的SDK，都能指导厂商接入穗腾os云生态中。同时作为架构师，我在设计架构时，预见到了当微服务接入的服务越来越多时，对某些核心微服务的调用依赖便达到极限时，可能会出现雪崩效应，如果应用间触发链式反应，受其影响的全线智能运维平台可能都会瘫痪。除了在服务治理的容错上设计外，本人提出用专业的消息中间件来作为基础设施向有场景需求的厂商提供，我们梳理了重要的场景，尤其是聚合根或事件源角色的微服务。也规范了中间件的使用制度。小组最终采用了本人的建议选型了kafka作为中间件布设在车辆段（地面中心）和车载的网络中。从厂商应用的角度设计了角色主题的命名规则，也就是topic。以网检的topic为例，18-wangjian-01的格式。18指线路号，拼音指业务分类，最后为专业厂商的业务通道标识。这样消息的订阅者就可以有的放矢地领取消息了，避免了冲突。专业厂商获取专属于自己的业务范围的消息，这也是安全性的角度考虑。

下面从具体专业厂商的角度来讲解微服务实践。探讨微服务的设计或拆分，微服务的治理，开发工具链和运维。在指导轨检专业集成时，本人借鉴了DDD(domain driven design)中一些设计方法。事实上ddd的提出更早于微服务。它主张以业务领域设计来主导整个开发活动，这对领域模型准确性要求非常高。在此基础上，不同的界限上下文中允许出现重复的实体（事实上实体在不同子域中侧重面不同）。DDD是打通问题分析域和解决域的一种创新。正所谓，德不孤，必有邻。DDD和微服务相结合，就像如虎添翼。把单体程序垂直拆分细粒度单元时，识别子域很重要，每个子域内众多微服务围绕着一个聚合根，并由其对外接口。内部业务单一，内部细粒度单元则是职责单一，借鉴了设计类的单一职责原则SRP。轨检专业分车载机检和人工巡检。前者有人工智能算法配合激光相机的帧图采集，后者人工经验比重高，自动化程度偏低，但两个子域分立后有些重叠的部分。在ddd中一般用两种手段再细分，如果重叠部分是一些操作过程，那么抽取出来变成领域服务，一般领域服务命名是动词开头。另外情况就建模为对象。具体是建成实体对象还是值对象。可以再从数据的唯一性角度分析。在项目中，把里程纠正作为是机检和巡检都依赖的领域服务去实施的。

在子域或者说界限上下文中，有地方也分翻译成限界上下文。总之子域内业务是单一的，细粒度单元中职责是单一的，遵循SRP。如果不是这情况，那么的原因就是未达到细粒度的拆分标准，需要重新审视一下，重新分析过程。

在界限上下文中存在上游和下游微服务如何集成问题，这时ddd的建议是用分层的技巧。可以参考某些资料，理解下何为通用协议层和防腐层。一般上游对下游的接口用up通用的协议来设计，比如以rest对外资源接口。而下游去支撑上游业务流程调用时，要开发出防腐层。ACL的建设手段可以应用门面设计模式，或者设计隔离适配层。acl的设计可大可小，用来适配遗留或外部的系统接口。它的作用既保护好自身领域模型免受侵害，又确保不同域在未来保持分离。本人在指导厂商设计微服务时也给出了其他的参考意见。如下：一，根据io的类型是读密集型还是写密集型来分类拆分。二，消除循环依赖和让核心微服务不受非核心微服务的异常影响。即核心不要依赖非核心微服务。三，根据非功能属性拆分服务，比如复用性、资源一致性、部署升级频率、伸缩性等。项目中，轨检中建设加密狗的业务环节时，由于具体需求当时尚未敲定，于是把变动性最高的环节独立设计成微服务，后期时方案成熟即替即用。对于微服务应用中最核心的环节就是服务的治理问题。它包括服务的注册、负载平衡、配置中心、容错。而容错中又细分有限流、超时、隔离和熔断等特性的。在脱离穗腾os平台的生态前提下，最合适的开发工具链则是spring cloud全家桶。它作为Java语言的解决方案，可选的注册工具有euroka和noca（阿里bb开源的）。注册/配置中还有consule。配置中心可选 spring cloud config。方便在测试环境、类生产环境和真正生产环境集中管理，灵活切换各种配置文件。网关建设应用zuul。Ribbon是一种客户端的负载平衡，他和euroka可以配合使用。在容错方案中spring cloud全家桶中的hystrix结合设置阀值的技巧，能帮助微服务在高并发出现时，在核心微服务上包装断路器暂时中断服务，待高峰过去再自动恢复。断路器是用三种状态，有打开、关闭和半开，专门处理线程耗光时的调用问题。同时，也可以设置阈值来保护微服务不被恶意调用。然而在本项目中，穗腾os平台在支持主流的spring cloud微服务生态时，也支持dubbo的RPC协议。厂商的服务如果是基于spring cloud开发的，那么在部署时需要适应性的维护。包括：从euroka注册方式改造到穗腾os的注册方式。这时需要调整的是 pom.xml文件。同时配置中要禁用hystrix，以便让腾讯的容错特性来接管。这些上线前的技术支持，联合工作组都会派出人员悉心的帮助。当部署交付到穗腾OS平台后，厂商团队也渐渐感受到了微服务结合云的一些利好。比如使用穗腾os封装好的调用链追踪，可以图表化展示微服务的运行情况。因为每次对微服务的请求都记录了日志，随时都可以溯源。同时穗腾os还支持容器和虚拟机/集群两方式的部署。如果用docker容器的，推荐仓库式的运维的特性，让用过git的开发工程师立刻解锁新技能。用docker push/pop命令一键部署和拉取云上的容器。而对于运维工程师，也能轻松激活devops的流水线生态中的方案。

就像操作代码仓库一样， 用docker push/pop命令一键部署到云。这些都是降低了运维的成本，也提高了devops的生产力。

项目最终成功上线，应用于某某城市地铁18和22号线上，解决了地铁业主提出的解耦各厂商应用和降低运维成本的两个问题。同时许多优秀的算法和组件在平台上涌现和沉淀。随着穗腾os2.0的商业化推广，新的架构模式在轨道交通行业方案中占有了一席之地，更多的红利会渐渐回馈开发者，开启双赢模式。同时冷静客观的看待微服务技术，还是仍然存在有待改进的地方。比如调用的响应速度，分布式下的事务和数据一致性的方案较复杂，调用链追踪技术还要有待发展。所以说流行的架构也不是万能的，不能脱离场景而选择架构，希望同僚们理性分析需求场景，更希望大家能共同健全微服务的生态。

摘要

本文将主要讨论三种经典的软件架构风格，并且三种风格分别对应三个本人所负责的三个项目。首先是微内核风格是本人在开发自动售票机产品时使用。第二种管道过滤器风格是本人在开发架构地铁线网行车信号监察项目时的实践应用经历。最后再介绍一下微服务风格的架构项目，这是在2020年某某城市地铁智能运维项目中的应用。由于本人所在的单位是为铁路和地铁提供技术服务和解决方案的研究机构，故本人所阐述的项目背景也以轨道交通行业为主。软件架构风格发展到当今已经枝繁叶茂了，这极大的扩展了架构师选择架构风格的范围。本文首先宏观上罗列一下架构风格家族的成员和概念，中间详细讨论一下三种结合实践的软件架构风格。最后小结一下软件架构风格的意义。

正文

掌握软件架构风格的相关知识是每个架构师的必修课，即使不能各个风格都经历和擅长，但通过学习达到能识别或者辨析各种架构风格也是相当必要，为日后架构工作时选择准确的风格来匹配业务场景提供帮助。宏观上由于软件风格不断垂直细分，风格与风格是之间关系也略复杂了。下面梳理一下或相似或隶属的关系。在独立构件架构风格中，包括事件架构风格、进程通信风格。在虚拟机风格中包括解释解析器风格、规则系统风格。仓库风格中包括黑板风格、超文本风格、数据库风格。注意要区分这不是数据流风格，因为数据流风格强调的数据处理的过程流环节，它包括了批处理架构风格、管道过滤器风格，稍后会重点讲。还有调用返回风格也是比较常用的，包括了主程序子程序风格、层次结构风格、面向对象风格，其中层次结构风格，又不同于层次架构风格，在后者中分了B/S，C/S和三层c/s。当两层C/S中独立出了服务器后，业务逻辑就不在与表示层耦合了，这样客户端就变成了瘦客户端。这样风格的程序是比较容易移植和方便客户端部署，增加安全性。尤其是能在某些客户端资源有限或者紧张的场景中使用。其它，还有闭环风格，C2风格以及SOA家族的分布式风格。

软件架构风格，是描述了某一特定领域中系统的组织方式和惯用模式，它定义了一个系统家族，包括体系结构定义，一个词汇表和一组约束。词汇表，包括一些构件和连接件类型。而这组约束指出系统是如何将这些构件和连接件组合起来的。反映了领域中众多系统所共有的结构和语义特性。

以微内核风格为例，通常包括微内核、插件和UI界面。仅是从语义上就很容易理解微内核和插件的约束关系。即插件是插在微内核上，当插件脱离微内核构件，微内核可以支撑程序继续工作。就像是热插拔U盘时并不影响电脑的其它工作和其它硬件。在复杂的应用系统场景中，当插件不可用的时候，可能会出现降级服务，但应用不会崩溃。大家都体验过自动售票机，简称tvm。它包括了出售单程票，充值一卡通，找零。现在的一些更先进设备，还有二维码的扫描器，一般几个硬件配合围绕着一个应用服务。但当不能收硬币时可以收纸币，不能收纸币时可以扫二维码，不能售单凭单程票，tvm就降级，降级服务为充值一卡通，打印机坏了就提醒不要发票，询问用户是否可以接受。这些TVM的应用场景很多人都经历过，本人开发tvm机内软件，就需要把各种软硬件模块抽象成插件。而主控，也就是微内核的角色，他掌握着事件循环，就像大脑来管理协调各种器官一样。tvm的界面与主控的是分离的，通过socket协议通信，所以严格来说这是界面分离式的微内核架构。界面（UI）可以把插件的状态显示，当所有的硬件插件不服务，界面（UI）还是可以查询地铁的线路信息。想必这种风格已经给大家很形象的认识了。

接下来介绍数据流风格的子风格–管道过滤器风格。通常每个构件都有输入和输出，数据在各种环节中处理（批处理风格是顺序处理的）。管道过滤器风格的特点是，在输入未处理完时，组件输出就已经产生了，最后呈现结果给外部或输出给其它构件。而这个构件就是过滤器。在此项目中之所以没有选择相似的批处理风格来架构，是因为信号数据是实时的指令流，而非纯后台作业。并且处理步骤之间并没有清晰的分界。所以，为了不延迟信号的连贯渲染，就只能用管道过滤器风格。同时也未使用管道过滤器可以并发的特性。本人在架构线网行车信号监察项目时的业务场景如下：外部信号承包商有一套信号协议，包括20多条指令，其中包括道岔、信号灯，还有轨道状态，还有其他的一些信号设备状态。而同时本公司内部也存在着一套信号协议和成熟的渲染程序。如果改造渲染程序来适配外部的信号协议将是巨大的工作量，并且伴随风险。而为了快速上线和高可靠性的质量属性要求。本人选用了管道过滤器风格实现了架构。即新开发了协议转换组件，它相当于风格中的过滤器角色。软件工作时，原有的分发数据的通信模块会直接调用新开发的组件，完成过滤转换。软件很快就成功的接入了外部行车信号的数据。为了过滤器转换处理效率提升，本人使用了内存管理算法健全和控制内存api强大的c和c++开发。当然开发中对内存管理稍有不慎时也会碰到，内存随着进程时间运行越久，占用越大，在几分钟之内就可以让进程崩溃。

最后在重点讲一下特别火的新晋的软件架构风格-微服务风格。他属于SOA大风格中。在分布式风格中webservice/ESB是与微服务有着些许类似，但ESB是企业服务总线。一个介于服务提供者和消费者之间的环节，虽然解耦了两端的依赖，但同时也是中心化和集中化了。而微服务是面向轻量级的协议，比如HTTP，还有API无关性。服务可以用各种技术栈来建设，微服务提供者本身也可以是另外一个微服务的消费者。微服务解决了典型的RPC存在的调用者耦合问题。微服务的架构风格说明它是更纯粹的分布式。有着小独轻松的特点。每个微服务功能单一职责，细粒度且灵活。独立部署和交付。微服务也是独立运行在各自的进程空间中。本人在某某城市地铁智能运维项目中，组织研发了以微服务风格为主的架构产品。具体的场景是：地铁业主要求在平台上监察各专业设备的状态，比如车载电源、车载空调轨道的损耗。而各厂商的方案不能串行的调试开发适配，业主要求解耦单体程序且降低运维成本。因为任何的软件和服务难免升级，而且不可控，一旦有耦合关系存在，厂商就要牵着业主的鼻子走。此时应用微服务风格就是好的选择，它具有的特点也有了很大的用武之地。各厂商拆分细粒度的微服务组件，自己业务自治，快速部署和方便管理。交付在业主提供的paas上。解耦的附属好处就是复用，很多公用微服务可以被集中管理，比如很多专业都用到了身份认证和数据字典查询。当一步步的健全微服务的生态时，许多组件可以市场化的。优秀的算法会慢慢的涌现。并且以各种红利的方式来回馈开发者。新的风格引出新的架构模式，促进相关领域的深度融合。

小结并回头来看，梳理出来的架构风格思维导图就像一棵硕果累累的树。它是前人的经验总结。前辈栽树，后人来乘凉，使用成果。

项目一旦选定了软件的架构风格，大家就相当于有了一定的抽象上的共识。现在的软件架构风格俨然成为一种沟通的媒介了。当越来越多的人在使用这个“标准语言”时，作为从业者就更加需要在架构风格上努力来学习和积累经验。更重要的是熟练根据需求的场景来合理的、灵活的选择架构风格。用好一个架构风格是需要不断的实践的。在架构风格比较时要注意，有时即便系统组织风格相同，但约束上不同，就是细分的另外的一种架构风格。当项目的成败也并不代表架构风格的盖棺定论。我们需要不断的论证和优化，吸取其他架构风格的优点，屏蔽架构风格的缺点。因为项目是变化的，一种风格与另一种风格可以混合应用，也并不是互斥的。

总结就是一种创新，这是我们秉持的态度。希望更多的架构师能探索和实践并分享。大家一起互相学习，共同进步。

摘要

敏捷方法是一套关于软件开发的思想方法和工具体系，通过遵循一系列的宣言、价值观和核心原则，并由此演化出来的实践方法和工具，来实现更早的和持续的交付有价值的软件，最终帮助客户最大化投资收益和提高影响力和竞争优势。本人有幸在2017年加入一个践行敏捷方法的项目组，该项目是受某石化的委托开发基于地震数据分析平台来指导石油勘探的项目。需要澄清的是这里所指的地震数据并非自然灾害中的地震，而是通过主动对地放炮。分析后来采集到的地震波数据。项目在零迭代时，就确定使用hadoop来分析hdfs格式的数据，同时应用IBM的RTC来协同完成代码管理和持续构建流水线。敏捷方法在此项目中帮助很大。本人作为高级工程师和敏捷教练的身份带领团队实践了scrum过程管理。文章先会从认知理论入手，再结合项目经历分享心得。

正文

敏捷方法中主要的角色有三类：产品负责人，这是对产品投资收益代表的一类人，通常是甲方， product owner，po。开发团队简称dev。这里说明一下，团队人数应该在5~6人的规模，是以特性团队建立，最好成员中多为全栈工程师。第三类角色就是本人在项目中担当的敏捷教练，简称为sm。敏捷方法区别于其他开发方法有两个关键的判别：第一个就是敏捷是面向人，而非面向过程；第二，敏捷面向事实性、适应性而非预设性。

下面介绍敏捷方法的宣言价值观和部分原则。宣言包括个体和交互高于流程和工具，这是以人为本的体现，强调人与人之间的尊重。在项目中有高工和普通工程师，也有内部和外包等。大家彼此无缝沟通，没有等级的区别，直呼英文名，当工作出现问题时不必汇报上级可直接找到解答者。对于，沟通在一个项目开发过程中的重要作用是不言而喻的。很多人说，项目成功的70%是靠沟通，30%才是靠做任务。第二，敏捷倡导可工作的软件高于详尽的文档。曾几何时，许多项目中，文档在不同的角色中来回变换，改来改去消耗人力和物力，也没有拿出客户满意的结果。可工作的软件成了与客户与沟通的新媒介，及早地暴露风险，好过于项目失败。这一点与微服务的小独轻松的特点有共同之处，通过快速上线来得到用户反馈，降低了风险。客户在看到投资有了实质的反馈，可工作的软件并在迭代中逐渐完善，这是敏捷方法结合原型来改造传统开发方法的关键手段之一。第三点，客户合作高于合同谈判。这一点是体现着客户至上。当客户真正的参与进来，敏捷项目的流产风险才大大降低，负面抱怨慢慢会变成微笑。本人作为敏捷教练，在项目中强调指出：客户必须派驻人员在项目组，按时参加敏捷scrum管控会议。最后在客户理解了敏捷方法的要义后，承诺每周至少有一人常住项目组，确保会议至少有两人参加。一个成功的项目不一定要在合同上咬文嚼字，评审会上面红耳赤，谈判桌上拍案而起，人身攻击。客户也不是主宰的上帝和敌人。斗智斗勇的旧式项目经理也不可取。敏捷中我们不怕检查工作，审核进度。反而怕你作为客户一个月不闻不问，不来项目组。真正优质的客户看完敏捷的理念就立刻茅塞顿开了。紧接着第四点，拥抱变化高于遵循计划。事实上有许多软件按瀑布模型开发或结构化步骤，在开发还没有完成时，软件就已经被淘汰了。因为商界的变化莫测，永远是无法预估的模型。例如：安全软件460宣布永久免费后，一下子瞬间占领了8成的市场，这种例子在互联网圈中举不胜举。变化存在，而开发不响应又何谈为客户投资利益最大化和帮助客户提升竞争优势？在变化出现时，对需求变更做管理是自然必要的，但是不遵循旧计划才是敏捷所倡导的。当需求变化后，大家坐在一起重新审视用户故事，调整后续的迭代和排列product backlog item的优先级，风险共担是解决问题的基础。上面介绍了4个宣言，但注意一下，虽然敏捷倡导宣言左向的价值，但不可忽略右项的重要，流程、文档、合同、计划也是必要的。网上有人发问敏捷要不要写文档的人就走了极端。敏捷还有12条核心原则是对价值观的解释和实践的指导，是敏捷项目得以成功的基石。此处不一一展开原则，举例一下最小工作量原则，原文是：以简洁为本，极力减少不必要的工作量的艺术。它是帮助项目提高效率的指导，以防在开发中画蛇添足的工作浪费项目人员的精力。

敏捷发展到现在有许多流派，他们之间不是明显的分支，而是有共性的。在某石化敏捷项目中借鉴了极限编程XP它其中的tdd。倡导测试先行，每一个开发工程师，都要在提交代码前完成自己的单元测试。虽然编写给这gtest和junit的测试代码会占用开发时间，但每日构建时就能排除低级的错误了。对XP有借鉴的同时也有弃用项。极限编程中提出的结对编程被我主张排除使用，毕竟中国程序员的习惯还是要考虑在内的，否则破坏了团队的氛围有时更为危险。对于scrum的过程管理，在实践时会碰到各种问题，其中有一种较传统的工程师，他不能理解敏捷背后的理念问题，他很机械地执行每日站会，有时无精打采，无话可说，有时又滔滔不绝，超时每人2分钟，他讲4分钟。有一次我们在sprint回顾会议上终于听到了抱怨声音。他认为每日站会是一种监督工作和体罚，怕员工迟到等。这时SM敏捷教练就必须站出来了，于是我开了专题会正面解释。每日站会一般控制在15分钟，每人之所以要回答三个问题：我昨天做了什么，今天要做什么，我需要什么资源。这是在拉平小组内开发情况的信息，信息对称就消除了隐患，及时了解开发速率，就像协调1个车子的4个轮子共同前进。而sprint的评审会，这是将迭代的成果集成，汇总和向客户演示。而sprint的回顾会议更像是对轮子的一种清洁和检修。是要汇总在上一个sprint的过程中出现的制度或团队瓶颈问题，讨论对策和完善规则的。为防止大家对会议多且密有反感，我们在和领导讨论后决定在回顾会议上摆上水果和零食、茶水，这下子让头脑风暴环节的发言率提升了两倍。经过了几次sprint后，大家直接把回顾会议称为了水果会议了。本人作为SM，同时需要考虑到少部分人可能对敏捷知之甚少或没有敏捷团队的经历时，需要慢慢的转变。在实践中，后期加入dev的人员就很难对敏捷的此前细节完全了解。新加入到dev中来，仅简单培训了开发环境就开始干活了。所以，SM要抽时间给他们“补课”。比如，讲解敏捷项目中需求开发中使用3C的标准去采集用户故事，同时用invest来衡量一个好用户故事的标准。在sprint的计划启动会中一般会有两个阶段，第一个阶段解决why。由po来介绍自己排序的pbi，并解释明白哪些是近光灯范围，哪些是远光灯的代办项，所以远光灯暂时并不急于排到下一个sprint的任务中。而第二阶段就需要dev和SM一起研究how。即如何分解任务，如何建立架构模型、算法模型、技术准备等。二阶段时，当对PBI有问题时，可以找来po再解释和协调。在经过了第二阶段后，sprint的计划就会可以输出 sprint待办事件列表了。计划会实现一个由PBI到SBI的分解过程。SBI是sprint backlog item。此时的列表不仅仅是用户故事的分解，还包括许多质量属性（非功能需求的）的或者一些技术工作的任务加入。由于，由于在某石化敏捷项目中开发和交付应用了IBM的RTC协同工具，所以代码管理，定时抽取，每日构建都是自动化的。所以提交sprint的成果并不用占用一条sbi。所以在敏捷方法指导项目开发前需要准备好 devops的工具链，这样能让项目事半功倍。有人把这种技术选型、创建工程、基础设施的准备和自动化部署结合统称为零迭代。有句话说得好，磨刀不误砍柴工。同样在实践时如果估计不出团队的速率，可以牺牲第一次迭代来投石问路，这样为以后准确地制定计划提供了参考。

某石化敏捷项目最终上线受到了客户的好评，帮助了地震数据指导石油勘探方向上许多创新的探索。纵观目前的众多开发方法，能在客户、研发团队和公司管理层之间游刃有余，协调资源到位的方法非敏捷方法不可。在未来也希望更多的项目应用敏捷或借鉴其中优秀的特性，本人仅以个人经历和项目场景为探讨契机，提出观点供大家参考。下面就列出一些文中提到的术语解释。