精华内容
下载资源
问答
  • 项目交付体系

    千次阅读 2020-08-05 13:56:46
    项目是为了提供独特产品或服务而暂时承担的任务,项目的特征是临时性和唯一性。伴随公司的逐步发展尤其是产品型软件公司,企业的产品逐步趋于精品及完善,但如何能够提高项目交付速率...建立项目交付体系,提升项目交付

    项目是为了提供独特产品或服务而暂时承担的任务,项目的特征是临时性和唯一性。伴随公司的逐步发展尤其是产品型软件公司,企业的产品逐步趋于精品及完善,但如何能够提高项目交付速率,将项目交付批量化、产品交付成熟化、产量化,实现此过程的前置条件有哪些,距离当前的目标还需要做哪些事情,本文将从道(目标、战略、远景)、法(制度、规范、保障机制)、术(方式、方法以及熟练度)、器(环境、工具、产品)、人(意识、心态、欲望、人性)五个层面分别阐述说明。

    明以道

    道是根本,是规则、自然法则,上乘。建立项目交付体系,提升项目交付率,实现项目交付批量化的顶层构建依赖于“道”。“道”类于产品架构设计属于顶层规划设置,在“道”里提下“势”、顺势而为,在国际、国家、行业整体大趋势下决定公司的发展方式与方向,顺大势而行软件行业经由无纸化办公至信息化整合乃至现在更为广泛的产业互联网、5G、云物移大智等。道与势结合,在道的规划结合势的辅助更可将事情事半功倍,取得更好的成果。

    1.行业聚焦

    人的精力是有限的同样公司的精力也是有限的,作为公司的运营及发展同样需要聚焦行业,作为公司的运营能够“广撒网多捕鱼”固然有一定成效,但是“专精”才是公司的立身之本。在公司有广泛涉猎的同时需要聚焦行业,深耕行业,了解行业的发展历程、趋势、特点,结合客户的业务特点丰富、完善平台的功能及交互模式。如:地产行业下主数据管理是围绕地产项目为全生命周期管控的,而过程中可能还会涉及基础数据与项目间的关联如房源、期、栋等;业财集成过程中会涉及到成本对接、四费回写(开发间接费、营销费、管理费、规费类)。

    2.项目筛选

    在公司当前阶段不是力求“广而杂”,而是需要“专而精”,主要聚焦于集成领域,意在为企业尤其是集团性企业搭建“一站式”整合平台,构建柔性IT架构,公司战略层面明确公司的专业的领域,当前公司主要精力在集成开发、开发集成两大类项目,致力于公司整理的运营方向及发展方向,公司主力的营业范畴,包含数据治理、统一身份认证、数据治理分析、统一门户集成、统一流程集成几个方向,主要行业在于制造业、建筑业、房地产等多以项目制度为管理方式的行业领域。在商机落地、项目承接选择阶段需要甄别项目是否符合公司发展且是否能够为公司带来价值。

    如公司目前主营对接方案ESB、IDM+ESB、MDM+ESB、ESB+MDM、MDM+ESB+DAP的主要承接侧重要点如下:

    1. ESB应用对接:主要解决客户有3~5套系统间的表单数据对接,服务开发提供的情况;
    2. IDM+ESB统一用户管理:实现客户信息化系统用户统一、认证统一、权限统一、审计统一的4A管控,实现用户账户密码统一无需在系统间返回切换登录,提供工作效率;
    3. MDM+ESB基础数据治理:实现客户主数据治理及规范,建立基础数据管理体系,保障数据的一致性、完整性、准确性,为客户应用集成及数据分析结果的准确性提供坚实的基础支撑;
    4. ESB+MDM应用集成对接:实现客户信息化系统集成,结合主数据时间系统数据映射的管理,为后续数据治理规范奠定基础;
    5. MDM+ESB+DAP数据治理分析:沉淀企业业务数据建立企业自身数据仓库,挖掘企业内部数据价值,将数据可视化、趋势化、价值化。

    3.方案匹配

    匹配公司主营领域及主要行业领域对应项目类型均需要匹配对应的落地方案给予支撑,方案不仅限定于售前沟通方案、项目落地解决方案及同行业案例分享等。

    1. 售前沟通方案:方案主要体现在几个层面如:项目领域的意义与价值,项目主要背景需求,解决客户问题及痛点分析,典型落地方式及优劣比较,同行业对应的案例类比分析。
    2. 落地解决方案:侧重体现结合客户的实际情况针对客户的痛点如何落地解决,通过什么方式解决哪些问题,预计带来什么效果,需要哪些投入及能够输出哪些产出。
    3. 同行业案例分享:主要体现当前案例的背景,痛点,解决方案及实施效果,侧面印证、体现同行业其他公司确实由此方案受益颇多。

    行尊法

    法是措施方法,是实现价值的方式及方法,项目交付过程中仅依赖于框架的体系理论同时对于项目人员思维意识,思维转变也是重中之重,由程序思维转变为用户思维,用户思维转化为产品思维,产品思维晋级为商业思维,只有这样才能很好的实现产品有自己用向友商用及面向用户的交付。同时加快交付、成体系的交付、实现项目做好、做快、做规范、做批量。

    1.体系支撑

    “没有规矩不成方圆”,公司层面关于整体管理体系需要不断的充实、完善,对于公司运营的全生命周期的管控均需要建立完善体系制度,如:商务体系,售前体系,人员体系,项目管理体系,实施体系,奖惩体系。

    1. 商务体系:明晰内部商务、外部商务之间的衔接关系,促进商务与客户间的对接,提升商机的落地促成的几率。
    2. 售前体系:明晰售前沟通、汇报、交流、跟进的各周期的工作内容及工作边界,配合商务促进商机的成单率。
    3. 人员体系:对于人员培养,意识、方法、工作方式、沟通、汇报、学习、管理等多方面全方位系统化培养模式;
    4. 项目管理:项目全生命周期管理,需求、设计、开发、测试、上线、交付、验收、运维,8位一体的全生命周期管理,各里程碑注意事项等;
    5. 实施体系:项目现场交付注意事项,沟通机制、汇报机制的明晰与管理,与客户不卑不亢,与友商化敌为友,与伙伴共进同退;
    6. 奖惩体系:明晰项目的奖惩管理,以奖励促进成员的积极性,更加助力于项目推动及交付。

    2.绩效考核

    公司员工潜能的开发需要鼓励与鞭策并存,在鼓励的同时与压力并存,在压力的临界点伴随鼓励共同推进,一方面有压力驱动员工向前推进,一方面有鼓励增加推进项目工作的动力。建立项目绩效考核体系,有奖励有惩罚双管齐下,同时不仅面向项目交付团队,对项目管理人员,销售人员均需要具有全面的考核体制,管理人员关心KPI才会关注项目实际推进情况,销售人员具备考核指标能有效保证项目相关动作的推进,交付团队明细目标才能够保证项目的交付。

    • 项目管理制度

    1. 阶段划分:不同阶段的侧重点、工作内容、交付输出物的明确与规范且需要输出样例文档;
    2. 需求明确:项目调研过程中明确客户需求,不要含糊而过,将自己的理解与客户确认,框定项目的需求范围。
    3. 设计细致:结合项目需求进行可落地的详尽设计,明确功能约束,技术要点,设计需要详细明确出相关功能的涉及到的基于预研、落地实现。 
    4. 计划精细:项目计划需要明确到人、详细到人天,同一项工作不能有多人同时负责,如果是多人负责则需要把工作进行再次拆分直至明确至个人,计划在实施过程中需要不断完善、精细,周计划明确至人、天,日计划细粒度至少0.5人\天。
    5. 人员分配:不同角色的职责划分,什么人什么时间应该做什么事情;
    6. 汇报管理:按风险、日、周、月、里程碑不同粒度对项目负责人、销售同步项目情况,保证消息的对称性;
    • 绩效考核制度
    1. 考核指标:规范考核指标,考核与绩效挂钩,不同完成度的奖励及惩罚机制,成体系落地执行;
    2. 节点考核:对项目各里程碑节点、收款节点、工作完结阶段需要明确标记出来,以各环节节点倒逼工作管理,输出工作审查情况;
    • 人员晋升制度:分角色、分岗位的晋升制度,不同岗位有明确的职业规划方向,员工可选择自身的规划及发展方向,明确对应T级的晋升制度;

    3.人员培训

    建立员工培训体系,除平台基础操作外需要模拟项目实际进行内部演练,保证新员工对项目整体过程及不同类型项目有整体的意识及交付的概念,明确什么是好的什么是不正确的。

    1. 公司认知:公司为平台产品的提供商及技术解决方案的提供商,对于普遍的承接项目研发公司存在着本质性的不同,对于公司员工需要明晰公司的立身之本,公司的盈利项及公司的发展方向。
    2. 项目认知:作为项目交付需要明晰项目验收是项目完成的基本盘,而项目衍生二次商机,项目运维服务盈利才是项目的本质目标,而实现目标的前提则是为项目提供友好的服务为客户解决实际问题。
    3. 意识方法:项目交付过程中需要具备团队意识、敏感度、责任心,遇见问题暴露问题,解决问题而不是等着事态爆发,一发不可收拾的状态。
    4. 职责明晰:项目交付过程明细各岗位职责,项目经理对项目整体进度负责,把控项风险;技术经理对项目过程中技术问题支持,保证项目技术落地;技术顾问保证自己负责项目工作的进度,同时熟悉项目整体流程及注意事项。
    5. 策略技巧:无论是哪一类型的项目最终都是需要与人打交道,在此过程中不要与客户发生矛盾,与客户关键人建立友好的沟通渠道,权衡其中关系,更好的推进项目。

    精于术

    术是体现,是具体手段。通过法具备方向的指导,结合术的手段落地,项目交付过程中在建立规范的同时需要能够对规范实现落地而不是“空中楼阁”遥不可及。在落地实践的过程中进一步完善、夯实整体的体系,将概念转变为认知,认知转变为下意识。

    1.项目管理

    项目管理主要是实现项目时间、成本、质量的管理,在有限的时间保证项目高质量的交付控制项目成本实现项目质量好、服务好、成本低、满意度高的最优交付。

    1. 需求管理:项目实施推进过程中,客户需求出现变更/增加是常态,从项目管控来说需求变更是不可避免,而对于项目交付而言需要尽量收口项目过程中的变化,引导用户收口或者下期推进,避免整体项目需求跑偏。
    2. 进度管理:项目推进过程中各里程碑节点的管控,以节点倒逼工作进度是否存在跑偏的情况,实时跟进项目进度,进行项目推演,及时暴露问题,避免问题的发生,而不是事后补偿。
    3. 团队管理:需要明确失败的团队没有成功的个人,需要明晰团队成员的动向,团结一心推进项目的工作,在项目中增加团队成员的配合度及默契,出现问题快速解决而不是互相推诿。
    4. 资源管理:领导也是资源,或者说领导是更为有效的资源,销售同样被视为资源的一种,项目最终是以结果论成败,项目管理人员需要以项目风险为优先级,协调各类资源保障项目的平稳推进。

    2.规范落地

    建立项目管理规范后续要进行规范落地,而不是仅有规范而不切合实际,更多时候人更倾向于自己信服的事实。可能规范总结的经验教训但员工自身没有体会其中奥妙没有转化为自己的下意识。而由知识转变为技能,技能转变为下意识的过程因人而异,各有不同。需要在项目实战过程中不断淬炼,增加个人的认知及能力模型的丰富,如:

    规范说明

    枚举说明

    售前管控

    售前人员熟悉方案,沟通前内部演练模拟客户沟通情况,将方案演绎、产品演示划分分别进行,输出各产品的演示关键点、演示方案

    项目管控

    建立文档标准、里程碑标准、考核标准、汇报标准、沟通标准、结算标准

    实施体系

    项目实施过程中建立项目管控体系,项目日汇报、周总结,计划滚动更新;暴露问题解决问题,项目进展极端推演,控制项目需求范围,把控项目各工作进度节点

    测试体系

    内部产品、公司项目均需要遵循测试体系进行详尽测试,按照不同角色、人员从使用、操作、维护角度进行测试,从安全、性能、功能层面进行自动化脚本测试,生成测试报告,交付对应的负责人员

    运维体系

    项目交付后进行内部交接,遵循项目运维体系,明确项目内容、背景等信息,对项目中遗留问题解决,产品层面问题反馈至研发部门进行解决,客户反馈问题及时响应,提升客户的信任度

    3.模拟演练

    建立规范的同时是纸面的通知,而真实的“触感”需要来源于一线的直观认知。而在员工并不具备实际项目参与的能力是时,可通过公司内部项目实现实际项目过程的模拟演练。感受项目整体流程,项目各里程碑是什么情况,与理论的认知有什么不同。

    1. 项目生命周期:6个周期节点从项目售前、合同签订、项目立项、蓝图确认、项目上线、项目验收,各阶段的关注事宜及输出产物。
    2. 项目沟通技巧:与客户、与伙伴、与领导、与商务面向不同群体的沟通方式及技巧,如何推动才能让同事更好的助力项目的推进,不同层面的工作人员的关注点,言简意赅保证工作推进。
    3. 项目封闭标准:项目在实施阶段的目的是验收,将项目封闭实现项目闭环,项目封闭后标志当前项目节点闭环,进入运维工作及二期推动工作。
    4. 项目意义价值:项目不同层面对项目的意义价值有自己的理解,项目追踪需要作为项目案例资源,项目结束后需要明晰项目的价值及意义,客户的价值及公司的价值以及团队的价值。
    5. POC搭建演练:以公司自有业务为需求原型,模拟不同方案下项目的实施方式,一方面作为技术人员的培训,提升员工对项目的熟悉度,另一方面也可演练验证产品的完备性,提升产品的质量。

    利其器

    器是用具提高效率将复查的问题简单化,经过公司对主营的行业领域及主营的范畴细后,项目甄别当前能不能做,而器有效的提升如何将项目做好,如何提高项目交付率,如何将项目交付批量化的工具。通过产品+管理结合,提升盈利;从产品层面考量,面向用户级别产品,打造“无脑式”产品线;项目交付层面:统一、标准、体系、积累、夯实;

    1.成熟产品

    公司本身为产品型公司,想要项目批量化交付则需要产品不仅能为公司员工使用同时需要能够面向伙伴、面向用户都具备较好的交互操作能力。对于平台的安全、稳定、扩展、交互均需要具有极佳的用户体验,且除平台技术能力本身的保障外,对于依赖于产品的方案,使用手册、维护手册、项目典型方案、应用场景及对应场景的落地方案标准文档均需要不断的完善和充实。

    产品名称

    应用场景

    ESB企业服务总线

    做企业服务总线ESB来实现异构系统的对接;

    在数据整合/数据中心项目中,作为综合数据交换平台负责业务数据上传、汇聚,基础数据(主数据)的下发、分发;

    综合集成项目实现跨系统业务流程重组;平台协作及支撑

    MDM主数据管理平台

    主数据管理的用户是各业务系统、数据集成系统、应用集成系统、业务流程再造系统、BI智能决策分析系统。通过主数据管理,改变企业数据利用的现状,从而更好地为企业全方位的信息整合做好铺垫。

    BPM流程集成平台

    流程集成平台一般用于跨异构系统的流程集成,或者实现业务流程间相互调用;也可以做工作流系统来用,为特定业务系统做为工作流引擎提供用户与流程信息交互的接口,实现诸如完成、挂起、加签、回退、签收等改变引擎流转的操作

    IDM身份管理平台

    搭建统一用户中心实现用户统一、认证统一、权限统一、审计统一的四位一体的统一管控,建立统一管理体系

    DAP数据分析平台

    挖掘企业数据价值,将企业沉淀数据可视化、资产化,建立企业自身的数据管理体系及数据存储模型

    Portal门户集成平台

    搭建单一的信息门户、知识门户、数据门户、应用门户、移动门户、开发社区及综合办公门户,通常及到AEAI ESB应用集成平台来协作,用于提供数据服务或者进行相关的数据加工汇总;

    2.管理系统

    项目管理同样需要信息化进行支撑,建立项目管理制度的同时匹配对应的项目管理系统,支持项目管理标准的落地,结合系统有效的对项目风险进行评估及展现,避免人为性掩盖事实。结合系统的统计情况真实、有效、实际的展示项目当前的进展状态,风险评估状态,项目里程碑节点,项目收款节点,项目当前进展状态及后续推进计划。

    • 如典型项目管理系统功能:
    1. 项目信息管理:项目管理可以看到项目信息和项目计划,用于创建项目的基本信息,比如项目的成员,周期成本合同周期等等,项目计划为每个人分配的任务,具体每天都要干哪些功能,进行一个统一的管理;
    2. 项目过程管理:对于项目周计划、日计划的滚动管理,项目计划填写完毕后并且总监对计划也进行确认,确认后项目经理就可以进行项目周报的填写,项目开发人员完善项目日报;

    3.办公环境

    工欲善其事必先利其器,生活的周边环境也是一种器的体现,大到欢愉的公司氛围,办公环境,网络带宽,小到使用的电脑、手机甚至是居住环境均会影响个人的思绪和心情进而影响办公的效率及积极性。这些环境因素往往是对办公情绪影响最大的但却是最容易解决的,如:居住环境在外出出差实施项目租赁房屋时选择比较符合心意的房子,一方面提升居住的舒适感,另一方面舒适的环境也是缓解工作的疲劳和压力的有效途径。

    常见的办公环境因素如下:

    环境说明

    匹配优选

    公司氛围

    • 公司氛围一定程度决定公司发展,选择公司氛围融洽,专心做事、敢打敢拼、全攻全守、

    生活环境

    • 居住环境:项目租赁房屋可优选居住舒适度较好的房屋,提升居住舒适度,缓解异地负面情绪
    • 网络环境:优先选择可控带宽的运营商,提升办公速率

    办公工具

    • 电脑:在经济允许的情况下选择性价比高的办公电脑,便携、速度是重要考核指标

    交通环境

    • 可控范围内选择便捷的交通环境,如公司选择在是地铁周边,交通便捷的地方,方便员工的出行

    皆由人

    “尺有所短寸有所长”无论是对公司还是对于个人而言均是广泛涉猎的同时需要有自身立足的根本需要具备深度的挖掘,呈T字型发展趋势。对于公司而言在具备广泛产品系列的同时需要有自己的深耕行业及“明星”产品,一方面在这一领域各类瓶颈了如指掌,另一方面通过产品切身实际的解决用户问题。对于个人而言,人的精力是有限的需要做好个人的“精力”管理,有自己的专业领域在专业领域内不断深入,提升自身的竞争力。

    1.自我约束

    历览前贤国与家,成由勤俭败由奢,懒惰的所有人的天性,而自我约束才是能够提升自我,超越非凡的本质。不以恶小而为之不以善小而不为虽是表述是非之道,从自我约束的角度来看也是同样的道理不要因为事情繁琐就拖延,不要因为工作简单就推进。自我约束管理,越忙越要整理计划,梳理工作项目;越慢越要倒逼原因找出本质而不是得过且过,不求有功但求无过的蜗牛心态。

    1. 时间管理:利用闲散时间总结规划当天的工作项及对应工作的完成情况,哪些工作需要协调哪些资源,预计需要多少时间;
    2. 心态建立:责任心、主动性、积极性需要化被动为主动,积极迎接变化,面对问题解决问题,不断积累形成正向循环;
    3. 习惯培养:主动汇报、积极涉猎,带着好奇心工作,对工作涉猎的知识点及周边知识点进行学习,由点到线,由线到面搭建知识体系。

    2.洞察人性

    无论是售前、实施、运维最终都是与人在打交道,在不同阶段与不同的人员沟通交互,每个人都有着自身的性格标签,需要结合个人性格特点有分别的进行交流。

    1. 与客户:与客户不同层面的人沟通时需要注意,有人风风火火,有人沉稳冷静,有人内敛涵养,面对不同性格的人需要建立良好的沟通渠道,保证工作推进的顺利;
    2. 与伙伴:与伙伴交流的过程中注意不同人承担的角色,销售辅助推进配合,交付并肩推进,管理明晰工作;
    3. 与领导:与领导需要言简意赅,明晰工作进度,问题点及潜在的风险点,不要盲目乐观,报喜不报忧导致问题爆发;
    4. 与团队:与团队成员建立并肩作战的情谊,失败的团队没有成功的个人,明晰整体团队的目标齐头并进。

    3.一往无前

    置之死地而后生,只有摒弃后路方可一往无前,每个人都有无限的潜力等待被激发,在成年人的世界没有永远的敌人只有永远的利益,不同的人可以为共同的目标一起努力,而在团队管理的过程中需要激发团队成员的欲望,激励成员的斗志,保持清醒的战意。向目标齐头并进为实现一往无前。

    对于员工而言更多的不是惧怕吃苦受累,而是没有目标和方向。作为管理者需要帮助员工明确公司未来发展方向及个人发展规划,为员工制定目标,将员工目标、公司目标相互融合,使得个人收益与员工收益互相联系。激发员工由被动接收转变为主动进取,且匹配对应的考核奖励制度。实现员工有盼头、得甜头、足劲头进而形成正面良性的体系。

    ​​​​​​​4.厚积薄发

    仅仅依靠任务的关系去维系项目推进是不足以作为项目推进支撑的,项目实施的本质还是要落地项目中客户的需求,消除客户使用的痛点,提升客户的使用满意度。本质上还是需要以实力取得客户的信任,提高客户对公司、平台、团队的信任感,而对于个人而言需要不断累积自身的实力,没有量的积累很难实现质的飞跃。在此过程中个人需要不断提升自我认知,提升个人能力,将硬实力与软实力结合,保证项目交付。

    道法术器人思想虽然源自历史长河,但内涵精髓却经久不衰,其理论方法被不断延续用于现代企业的管理,道:是方向、理念、价值观;法:是组织架构、经营模式、管理体系、规章制度;术:是策略、技能;器:是工具(硬件、软件等),人:是基本元素、成败关键。五者结合,以道义来承载智术,“术”要符合“法”,“法”要基于“道”,道法术,通过最好的技术和工具,人是“道、发、术、器”的承载着,五者兼备做出最好的策略。

    展开全文
  • 做持续交付就是提升整个研发体系效率的关键。 持续交付代表着从从业务需求开始到交付上线之后的端到端的过程。 业务/产品——开发——测试——运维:持续交付 开发——测试:持续集成 开发——运维:DevOps ...

    16 | 持续交付知易行难,想做成这事你要理解这几个关键点

    什么是持续交付

    首先要把持续交付做好。

    做持续交付就是提升整个研发体系效率的关键。

    持续交付代表着从从业务需求开始到交付上线之后的端到端的过程。

    业务/产品——开发——测试——运维:持续交付
    开发——测试:持续集成
    开发——运维:DevOps
    业务/产品——测试

    持续交付的关键点

    1. 配置管理
      标准化是一个持续的过程
    2. 需求拆解
    3. 提交管理
    4. 构建打包
    5. 自动化测试
    6. 部署发布

    17 | 持续交付的第一关键点:配置管理

    • 版本控制

      举例:svn & git

    • 依赖配置

      举例:Maven, Ant

      • 仓库管理
      • 依赖管理
      • 构建打包
    • 软件配置

      • 代码配置:代码配置是跟代码运行时业务逻辑相关的。

      • 应用配置:应用配置就是应用这个对象的属性和关系信息。

        • 应用构建时配置:编程语言,git地址,构建方式
        • 应用部署时配置:源代码目录,应用日志目录,web日志目录,临时目录,脚本目录
        • 应用的运行配置:应用启停,服务上下线方式,健康监测方式等
        • 应用运行时与基础组件的关联关系:比如依赖的DB、缓存、消息以及存储的IP地址、域名、端口、用户名或Token等。
      • 两者区别:代码配置和业务或代码逻辑相关,应用配置和业务和代码配置无关。

    • 环境配置

      不同环境中的应用配置管理。

    18 | 如何做好持续交付中的多环境配置管理?

    多环境问题

    • 开发环境
    • 集成环境
    • 预发环境
    • Beta环境
    • 线上环境

    不同环境下的应用配置管理

    • 应用属性信息
    • 应用对基础组件的依赖关系

    环境配置管理主要是针对应用对基础设施和基础服务依赖关系的配置管理

    环境配置管理解决方案

    • 方案一:多个配置文件,构建时替换
    • 方案二: 占位符(PlaceHolder)模板模式
    • 方案三: AutoConfig方案

    推荐的解决方案:基于AutoConfig做一下二次开发,将配置项做到一个管理平台中,针对不同环境进行不同值的管理,然后根据AutoConfig的规则,在变更后生成对应不同环境的配置文件,然后再结合AutoConfig针对配置管理文件的能力,这样就可以很方便地做多环境的软件包构建了。

    19 | 开发和测试争抢环境?是时候进行多环境建设了

    环境分类

    • 线下环境
    • 线上环境

    线下环境分类建设

    • 线下环境区域内,建设的第一个环境是集成测试环境。
    • 线下的第二套环境:开发测试环境。
    • 解决冲突,第三套环境:项目环境。

    环境建设上的关键技术点

    维护工作量大。

    • 网段规划
    • 服务化框架的单元化调用
    • 环境的域名访问策略
    • 自动化管理

    20 | 线上环境建设,要扛得住真刀真枪的考验

    生产环境

    即使有影响,也要把它控制在小范围内,或者是在萌芽状态时就发现。这样就可以提前处理,而不是全量发布到生产环境后才发现问题,影响全局。

    Beta环境

    模拟真实。

    预发环境

    办公网生产环境

    展开全文
  • 1. 前序对于工程团队来说,构建一套具有可持续性的、多方面质量保证的交付体系建设,能够为业务价值的快速交付搭建起高速公路,也能为交付过程中的质量起到保驾护航的作用。本文为大家介绍持续交付体系在高德的演进...

    1.  前序

    对于工程团队来说,构建一套具有可持续性的、多方面质量保证的交付体系建设,能够为业务价值的快速交付搭建起高速公路,也能为交付过程中的质量起到保驾护航的作用。本文为大家介绍持续交付体系在高德的演进与落地。

    2. 持续交付

    正如前序中所总结的,我们需要构建一套持续交付体系,从而保证在质量不下降的前提下,在业务价值交付上有更进一步的突破。那么我们先了解一下什么是持续交付以及集团在持续交付的建设上有哪些指引。

    2.1 持续交付概念

    引用Martin Fowler大师在2013年时发表的文章,对于持续交付的概念有如下的解释:Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.

    在上述文中,可以提取几个关键词:

    1. 软件开发的标准化准则

    2. 可以做到随时随地的发布

    什么情况下就可以算是团队达到了持续发布的状态呢?Martin Fowler大师也给出了标准的答案:

    1. Your software is deployable throughout its lifecycle

    2. Your team prioritizes keeping the software deployable over working on new features

    3. Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them

    4. You can perform push-button deployments of any version of the software to any environment on demand

    那么基于以上的观点,我们在建立自身的持续交付体系时,需要抓住以下几个重点:

    1. 标准化流程流转

    2. 当有变更进入时,能够快速、准确且自动的得到反馈

    3. 解决部署问题的优先级高于功能开发

    4. 一键发布

    2.2 集团的持续交付建设

    从理论基础上对于持续交付有了初步了解后,我们从集团层面了解一下是如何定义持续交付的能力,并且对于持续交付提出了哪些效能改进目标,参见阿里技术公众号的文章 如何衡量研发效能?阿里资深技术专家提出了5组指标

    文章中将持续价值交付的能力拆分为3个层面的5组指标,从不同角度对持续价值交付能力进行了衡量。

    有了上面专业层面的衡量指标,那我们是如何定义一个优秀的持续交付衡量目标呢?

    管理学之父德鲁克说:“如果你不能度量它,就无法改进它”。度量帮助我们更深刻认识研发效能,设定改进方向,并衡量改进效果,所以想要进行效能提升的前提是先能够识别交付过程中的质效瓶颈。

    因此,集团在基于部分BU的优秀实践下提出了2-1-1的愿景。

    • 1小时的发布前置时间是对于基础设施能力的要求,需要保证当达到交付标准后,通过交付流水线能够达到1小时内的打包、部署和验证的能力;

    • 1周的开发周期涉及产品需求拆分、研发QA协作能力、持续测试以及快速反馈能力方面提出了挑战;

    • 2周的需求交付周期是以前两项为基础,不仅是涉及到产研测三方,还包括其他协同部门的通力合作才能保证业务价值的快速交付。

    3. 持续交付在高德

    在基于集团愿景的指导下,反观现有高德服务端的交付流程,我们发现在整个流程中,存在很多效率上的竖井,这些效率问题汇总起来,便会成为整个交付流程上的效能瓶颈,进而影响业务价值的尽早交付。

    我们先从一个整体的Milestone来回顾一下整个持续交付所经过的一些重要时间节点:

    • 2018/08 构思与工程能力建设:项目启动阶段,工程效率团队与业务线明确了持续交付的目标,并启动了工程能力建设

    • 2018/12 初步落地与试点:项目试点阶段,完成了初步的持续交付流程搭建,并在一个项目中验证流程卡点以及质量标准的基础能力验证。最终建立了基础的质量标准以及降低流程中的耗时

    • 2019/04 推进接入与平台优化:项目推进阶段,持续交付项目质量项优化并在高德的服务端的6条业务线中进行推广,在9月份完成6条业务线以及11个应用的持续交付落地

    • 2019/09 复盘与展望:项目推进总结,对整个推进过程进行复盘与后续持续交付如何落地进行复盘与展望,整体产出业务推进中出现的问题以及改进方法

    • 未来:在交付流程上进行贴合业务线的微创新,并对效能瓶颈点进行纵深挖掘。结合各纵向平台进行纵深挖掘,例如:覆盖率与精准回归、云歌Case平台、代码扫描平台等

    通过milestone的展示,对于高德持续交付体系的演进有了大致的了解后,下面对于落地的过程以及改进的内容进行一下详细的梳理。

    3.1 接入持续交付前的交付流程

    首先先介绍一下在接入持续交付体系之前,高德的服务端是如何进行迭代的开发与上线的。

    与大部分互联网公司一样,我们将软件的交付拆分为多个周期,进行迭代式的交付,以便增量式的进行用户价值的交付。上图描述了一个正常迭代周期内的研发、测试以及发布的流程,我们可以拆分为以下几个方面:

    1. 迭代周期起始于代码库的变更

    2. 在功能开发完成后,研发通过CI系统进行冒烟测试验证,保证服务可以正常启动以及基础功能可用

    3. 在规定的提测时间前,研发将Feature分支通过CR和MR合并到迭代分支,部署到日常环境进行提测

    4. QA在收到提测邮件后,参与到日常环境的测试中

    5. 当日常环境测试完成后,QA会进行测试报告的产出,并确认日常环境测试通过,可以发布到预发环境

    6. 部署到预发环境后,会进行流量回放等测试,并最终通过线上的灰度验证,最终发布到正式环境

    通过上述的图片和描述,我们可以看到在看似完善的软件交付过程中,却仍然存在如下一些质量、效率问题:

    1. 需求堆积提测、发布:

    目前高德服务端大部分服务采用的是固定迭代周期进行需求发布,规划到迭代周期内的需求,无论需求大小,均需要等到迭代提测时间点进行提测,在迭代的发布窗口进行发布上线。在这种模式下,好的一点是有固定的版本节奏,整体迭代规划性比较强。但是由于提测、发布窗口固定,从而也带来了整体业务价值交付上的等待。因此,需要通过需求拆分来降低需求内部的耦合性,通过改变研发、QA的开发测试模式来降低需求提测中间的竖井等待,从而提升业务价值交付的效率。

         2. 质量标准不透明,无法及时反馈:

    从代码提交一直到最终产品发布,一般情况下,会经历日常、预发、灰度、正式发布几个阶段,每个阶段均有每个阶段需要重点解决的问题以及对质量上的要求也不尽然相同。目前结果的收集汇总和通知都是通过跟版人进行人工收集和统计,并邮件通知项目成员。这样所有的标准控制都是有每个版本的跟版人进行把控,存在信息不透明,反馈不及时的问题。通过质量项标准的建立,以及大盘结果透明和及时的通知,能够解决沟通层面的低效以及在传递过程中信息损耗,从而提升沟通效率,并且避免沟通中的误解。在解决了当前透明化和及时通知的问题后,我们需要进一步从以下两方面进行优化:

    • 将通知进行分类以及优先级处理,降低通知带来的负面影响

    • 通过信息内容优化,辅助业务进行问题的快速定位与排查

       3.部署与流程流转过程需要人工参与:

    对于持续发布流程来说,有人工参与的地方势必会影响到其中的效率。所以我们将部署和阶段流转拆分为两个方面看:

    • 阶段流转:结合上述的阶段标准,通过程序来计算是否能够满足当前的质量情况是否可以进行阶段的流转,从而排除人为因素以及在阶段流转中的耗时,做到准确

    • 部署:提取相应环境的配置信息,结合Docker化,将打包、部署、健康检查等一些列活动转换为机器的标准化执行,通过标准化来避免人为参与所造成的误差或部署失败的问题

         4.多机房正式发布验证人工监督:

    目前在应用的正式发布流程中,由于涉及的机房和机器数量较多,业务上会进行分批验证,每发布完成一批机器,研发会通知QA进行这批机器中部分机器的抽检(部分自动化测试),在这其中也存在着效率上的问题。所以如何节约每次上线过程中的人力损耗,也是在追求效能极致上需要解决的问题。

    上述的每个细节的问题,都在我们通往快速业务价值交付的道路上设置了障碍。因此,为了达成更早(快)的交付业务价值的目标下,我们必须要在交付效率、质量标准以及结果快速反馈这几方面的进行优化。

    3.2 持续交付在高德的落地

    基于上节拆分出来的4方面的问题,从工程角度来说,由于迭代的排期,需求的分解与拆分需要进行长期的实践与规划,并且依赖于产、研、测、项乃至于其他部门的支撑,是一个需要进行逐步探索和调整的过程。所以我们将着眼点放到后3方面的建设上,期望在短期内先建立起快速发布的能力,清除在交付过程中效率低下的点。

    那么在解决效率问题的建设上,借助于集团提供的发布流程以及较好的部署能力,我们将目前拆解为如下几个维度的抓手:

    1. 依托于集团的发布流程,在持续交付体系中建立与集团发布流程对应的标准化流程流转机制

    2. 建立服务端质量标准体系,拉通质量标准,去人工化

    3. 打通各环节的快速反馈机制,并对发布流程进行管控,让变更结果随时可见

    4. 降低发布过程中的人为参与,让整个发布流程做到全程无人值守

    通过下面持续交付流程图,我们通过接入后的流程图中看一下以上4个抓手是如何串联起整体高德持续交付流程,并且这几项是如何在高德服务端交付流程中进行落地的。

    • 建立标准化的流程流转机制

    FY19高德服务端发生的线上问题中,其中由于变更或发布引发的问题占比约12%。通过这组数据,我们期望能够通过建立一套完整的交付流转流程,实现对于变更的控制和管理,降低或避免此类问题的发生。

    基于以上立论,我们结合当前服务端交付特点,首先先确立以集团标准发布流程为试点,打通整体持续交付流程;其次,针对各应用中不同的需求,例如:需要性能环境、覆盖率环境等,结合流水线配置,将整个持续交付的流程流转进行优化;最终沉淀为各服务的标准化流程流转机制。通过这种先僵化,后优化,再固化的方式,最终在服务端落地了多套标准的交付流程,避免了在交付环节上的遗漏,以及不规范的操作。

    • 拉通并落地服务端质量体系标准

    在高德现有的交付流程中,整体的质量保障手段大部分是在日常阶段进行的,在迭代交付的过程中,各项质量保障手段执行了哪些,执行结果是什么,目前还是通过QA人员进行人工问题收集与汇总,并判定阶段结果的通过与否。在这种情况下,会出现由于跟版人交替导致的质量项遗漏,以及质量标准难以把控的情况。

    所以基于这几方面的问题,我们希望通过用机器把控替代原有的人工把控的方式,通过建立标准化的质量模板,来避免整体执行标准不透明,执行结果无沉淀的情况。并且,通过拉通标准,也进一步的规避掉了非重点服务质量检查点遗漏的情况。

    通过与业务团队的沟通,我们在第一阶段将现有服务端的质量保证手段进行拆分,提取了在不同阶段中相对重要的12项质量项,通过机器监督替代原有的人为统计的方式。具体覆盖了如下几个维度:

    • 代码维度

      • 静态扫描

      • 安全扫描

    • 测试维度

      • 冒烟结果

      • 新功能结果

      • 回归结果

      • Fuzz测试结果

      • 流量回放结果

      • 兼容性测试结果

      • 压测结果

    • 监控

      • 预发、线上监控

    • 需求/Bug管理平台关联

      • 当前版本需求进展

      • 当前版本Bug情况

    • 打通各环节的快速反馈机制,并对发布流程进行管控,让变更结果随时可见

    当建立起有效的质量体系后,在各阶段有了质量要求以及准入准出标准,解决了信息收集方面的问题,那么接下来我们要思考的就是如何将收集上来的各种信息,有效的反馈到项目中的各个干系人,以便进行后续的决策支撑,并且当未达到阶段准出标准时,有效的控制项目的阶段流转。

    我们将问题拆解为两方面看,一是有效反馈、决策支撑,二是流程流转的管控。

    从有效反馈、决策支撑方面看:

    • 在接入持续交付之前,各业务线的针对不同类型的自动化测试任务,大部分都有通过Jenkins或测试用例工程反馈结果的通知。但是此类反馈有一个致命的问题,就是通过单项反馈无法纵观全局,不足以支撑后续的决策。

    • 在接入持续交付后,除了原有业务上的反馈机制,平台提供能针对当期版本的整体状态全览,可以通过平台随时观测到当前版本是否达到可发布的状态或者仍然存在哪些不足。将两者结合起来后,针对项目执行人仍然可以通过原有反馈机制了解到单点的质量结果;对于跟版人、一线、二线管理者这类需要纵观全局的角色来说,通过质量大盘,可以有效且明确的知道当前版本与待发布状态的差距,并支撑后续决策以及调整关注的重点

    从流程管控方面看:

    • 在接入持续交付之前,可部署的产物无论是否经过阶段验证,都可人为的部署到任意环境下,虽然灵活性比较高,但是也存在一定的质量风险。

    • 在设计持续交付流程时,对于灵活性以及规范性的取舍方面,我们也与业务同学进行了讨论。从全局看,为了避免流程不规范引起漏测或其它线上事故,最终确定在初版时先保证流程流转的规范性,从而降低灵活部署上所带来质量上的风险。平台通过集团实验室插件与集团的部署发布系统打通,当阶段中存在质量项尚未达标的情况下,阻止发布流程进入到下一阶段(环节)。

    • 当基础的持续交付流程落地后,为了满足业务上对灵活性的要求,目前我们也在尝试通过自定义流水线来进行多环境的分发与部署,从而在保证主要阶段流转有管控的同时,增加部署的灵活性,以适应不同的业务形态。

    • 降低流程发布过程中的人为参与,让整个流程做到全程无人值守

    我们知道,线上环境部署的复杂程度要远高于在日常和预发环境的部署。由于部分业务线,线上的机器数量众多,且分布在不同机房,为了保证部署时的服务可用性,线上部署时会将上千台机器拆分为多批次进行部署。

    • 在接入持续交付前,为了保证部署后服务的可用性以及对质量上的高标准要求,在每批次部署完成后,QA都需要针对当前批次进行全批次验证或抽测验证,当验证通过后,再进行下一批次的发布以及后续验证。虽然验证本身是通过自动化脚本进行验证,但由于机器和批次比较多,整个发布和验证流程会持续数小时,存在较大的效率问题。

    • 在了解到业务上此效率瓶颈后,通过打通上下游系统,集团标准流程、集团发布系统以及原有业务的线上验证工程,针对不同业务的发布场景,进行发布验证策略的配置化。通过感知部署时的消息,获取当批次部署的机器列表,依据各业务的验证策略配置进行自动化的验证。并且结合线上阶段的报警监控,当某批次发布验证出现问题后,系统可以第一时间定位到具体是哪一批次中的哪台机器发布出现问题,帮助业务进行部署问题的快速定位。

    • 持续交付体系的业务架构

    4.  落地效果

    整个持续交付体系建设,目前在高德服务端落地已经有一段时间了,截止到目前为止:

    • 业务线覆盖:整个持续交付体系已经覆盖了高德服务端大部分重点业务

    • 各阶段质量项建设:12项

    • 正式发布阶提效:50%~90%

    在获得以上成果的同时,除了上述量化指标外,更有价值的是隐含在背后的研发、测试习惯上的变化。从研发、QA和项目主动发起的缩短项目周期,到QA对于质量项上提出更多的诉求等等,无一不感知到大家对于尽早且高质量的交付业务价值这件事情的重视。当然对于更早(快)的交付业务价值这个目标还有一定的差距,这个也是后续我们与业务线需要共同解决的问题。

    5. 持续交付的未来

    有人将持续交付形容为在价值交付上的高速公路,持续交付的落地,标志着价值交付到用户的快速路已经建立完成。但是最终是否能做到更早(快)的交付业务价值,还取决于在这条快速路上行驶的车辆。

    根据这个理论,我们除了要保证这条高速公路上不出现坑洼的同时,还要兼顾车辆本身的能力,以及车辆的性能。因此,在车辆出发前,我们更需要通过对车辆的车况进行检查,保证在高速路上行驶的车辆不会因为自身的原因提不起速度。

    5.1 车况检查

    目前,已有的持续集成系统,仅能够保证车辆在这条路上是能开起来的,车况的检查都是在上了高速后才开始的(大部分的质量保证手段是部署到日常环境后才开始)。所以基于上面描述的指导方针,我们需要尽早的做检查,并且需要做更全面的检查(质量保障手段左移)。

    基于这个目标以及结合集团内其他BU的优秀实践,后续我们希望能通过代码门禁的手段,尽早落地这类全面的检查。若要将代码门禁落地,无论是对于工程效率团队亦或是业务研发与QA团队,都有着不小的挑战,我们需要做到以下的转变:

    • QA

      • 质量保证的同期化能力建设

      • 质量保证的稳定性与耗时优化

    • RD

      • 研发提交代码流程的改变

      • 单元测试能力的建设

      • Code Review的常态化落地以及规范总结

    • 能力支撑

      • 代码覆盖率,业务场景覆盖率的支撑

      • 代码合并的门禁管控能力

      • 代码扫描结合CodeReview的总结的落地

    当逐步完成以上任务的落地后,能够消除批量交付业务价值交付中相互等待的时间,并且也能够保证车辆在持续交付这条高速路上行驶得更快更稳定。

    5.2 车辆性能提升

    前面车辆检查可以说是在车辆上路之前的检查与保障,将质量保证手段左移到研发阶段。相对的,我们希望通过车辆性能提升的方法,在车辆上路后,能够让车辆行驶提速更快,拉高速度的上限。

    • 纵向测试能力提升

      • 精准回归:通过感知代码的变化,推导出代码变动所影响的Case,让质量保障更为精准且耗时更少

      • 场景覆盖:结合线上流量回放,通过代码覆盖、场景覆盖进行查缺补漏,让质量保障更完整

      • 问题定位:结合失败用例,快速的进行问题定位与反馈

      • 同期化能力:结合云歌Case平台,通过接口定义进行测试代码与研发代码同期化编写能力的加强,以及降低Case编写和维护成本方面的探索

      • 降低数据干扰:基于高频、隔离和用完即抛的理论实践,降低日常环境的数据干扰,让质量保证更有效

    • 与线上数据挖掘结合

      • 大数据分析:

        • 利用线上日志分析,产出线上真实场景模型,降低压测平台语料准备耗时,场景筛选上做到精确、高效

      • 大数据运用:

        • 结合线上真实场景以及场景覆盖率,构造线下回归Case集,降低业务回归Case维护成本,提升Case有效率,并且能够快速定位问题

        • 利用场景回放,以及记录回放中间产物,解决在单测时场景构造问题

    随着持续交付快速通道的搭建完成,期望通过以持续交付体系为契机,在多个纵向维度进行深入挖掘,并完善整个持续交付体系,最终在更早(快)的交付业务价值的前提下,能够有更高的质量以及更低的人工成本,保证市场竞争的先机,让高德在激烈的竞争中优势更为明显。

    编辑:黎露(实习生)


    相关阅读

    高德全链路压测平台TestPG的架构与实践

    觉得好看,请点这里 ↓ ↓ ↓ 

    展开全文
  • 再谈软件研发管理体系建设

    千次阅读 热门讨论 2019-09-24 08:10:31
    在前面的文章中,我曾和大家分享了软件研发管理体系建设的一些见解,其中涉及对软件研发管理体系的一些概念认知、什么样的软件研发管理体系适合我们的发展以及构建我们的软件研发管理体系应包含哪些内容。...

    在前面的文章中,我曾和大家分享了软件研发管理体系建设的一些见解,其中涉及对软件研发管理体系的一些概念认知、什么样的软件研发管理体系适合我们的发展以及构建我们的软件研发管理体系应包含哪些内容。结合最近一段时间的思考,今天再次和各位朋友探讨一下软件研发管理体系建设这个话题。今天要谈的这个话题主要包括以下几点: 1、研发体系框架 2、人员组织能力 3、项目管理能力 4、技术研发能力 5、持续交付能力 6、运维服务能力 7、安全可控能力 8、资源建设能力
    在正式探讨该话题之前,简要谈谈最近的一些思考和想法,首要一点是社会的发展、业务的变化、技术的进步促进了研发模式的转变,同时也促进了研发内容的转变,例如从以往的单体架构向云化架构演变、从以往的PC端应用向多终端应用演变、从以往的传统应用向智能化应用演变,另一方面项目交付的发展方向也是发生了重大转变,从以前的注重过程标准、流程可控、需求明确和面面俱到向关注交付价值、交付效率、安全保密和过程可视的方向转变。 正是基于对上述这些认知和理解,让我对软件研发管理体系的建设有了一些新的思考,为此和大家一起分享交流。

    一、研发体系框架
    在个人看来,研发体系主要从标准方法体系、技术能力、组织架构、交付模式、服务客户等方面去分解考虑,并在中间通过人员组织能力、项目管理能力、技术研发能力、持续交付能力、运维服务能力、安全可控能力和资源建设能力等贯穿。研发体系框架示意如下图所示:
    在这里插入图片描述
    二、人员组织能力
    在人员组织能力方面,需要建立组织岗位体系框架,包括岗位标准库、培训规范、岗位胜任能力标准、岗位认证流程、岗位等级认证、岗位发展通道等。在岗位体系建设方面,可以考虑按职能类(如部门总经理、部门副总经理、行政助理等)、项目类(如项目总监、高级项目经理、项目经理、项目工程师等)、专业类(如技术总监、技术经理、开发经理、系统架构师、开发工程师、测试工程师、实施工程师等)的方式进行分类设置。同时,明确相应的岗位发展通道。
    关于组织岗位体系框架的建立,通常需要在公司层面来统筹考虑,因此需要和HR部门等诸多部门进行协同落实。 此外还需要建立绩效考核评价方法,针对研发人员的绩效考核评价方法在会对各岗位人员个人技能、综合素质及工作任务进行持续跟踪,并根据人员考核计划开展绩效面谈辅导,帮助全员改进工作方法、提升工作技能和工作质效。 培训作为人员组织能力的有机组成部分,需要强化培训和知识共享,通过建立内部培训体系,内部培训与外部培训相结合,多样化培训形式,将技术认证、培训积分等纳入技术序列晋升考评条件,强调培训的结果。

    三、项目管理能力
    项目管理能力方面,需要在标准化项目管理与敏捷迭代之间融合升华并逐步形成满足未来发展需要的敏捷项目管理能力,促进管理与工程维度相结合,应用最佳实践,从而快速、高质量交付可工作的软件。 除了项目管理体系方面的内容之外,还需要关注设计评审规范、应用开发规范、质量管理、配置管理等方面的内容。 对于涉及评审规范,需要针对需求、概要设计、数据库设计、详细设计、原型设计、界面设计等制定相应的评审规范,同时要对测试计划、测试用例等进行评审,除此之外,还需要有代码评审和发布评审等方面的规范约束。 对于应用开发规范,可以重点关注架构规范、设计规范、UI规范、编码规范、测试规范等。其中,架构规范方面是通过规范架构设计,来管控软件的技术合规性;对设计进行规范,包括如统一文档格式规范、功能设计要素、DFX设计规范、数据库设计规范等;UI规范是为避免使用者对不同系统进行多次学习、操作思维不连贯,从而提升操作效率;代码规范是为了代码能被更好的维护、扩展和更高的质量。包括代码编写规范和代码质量管理规范;测试规范则是规范测试过程,包括测试步骤、测试方法、测试工具、用例规范等。通过对测试进行合规性管控,提高产品质量。

    四、技术研发能力
    技术研发能力主要从应用开发能力、平台研发能力和技术创新能力三个维度考虑。
    在这里插入图片描述
    应用开发能力着重于考虑对各类业务应用的前后端开发支撑能力;平台研发能力着重于考虑对基础平台、公共组件、套件、工具等的研发提炼并让软件开发逐步具备搭积木能力;技术创新能力着重于紧跟前沿技术,特别是云大移物智方面的相关新技术的研发突破,以便于更好地为业务服务。 在技术研发方面,需要持续增强基础开发能力,并在平台化、产品化方面深入研发,拓展云计算、物联网、移动互联网、大数据、人工智能等方面的技术能力。

    五、持续交付能力
    在持续交付能力方面,不同阶段会有不同的做法。个人认为,在构建持续交付体系框架的初期,可以考虑从两个方面出发,一是统一软件开发平台,二是推行CI/CD。 统一软件开发平台,主要目标是把基础服务平台化、软件架构标准化,从而进行快速的开发和迭代,提高整个应用开发域的自主可控能力。
    推行CI/CD方面,主要是通过搭建自动化工具平台,构建持续交付流水线,实现端到端无缝集成。这里面可快速运用的实践包括代码构建自动化、静态代码扫描自动化、API接口测试自动化等。有关这方面的一些实践会在后续计划分享的敏捷和DevOps转型实践的有关文章中探讨。

    六、运维服务能力
    在运维服务方面,有两方面的考虑。首先是对于软件开发项目的生产运维,这方面可能会涉及到持续部署等方面的内容,更多会牵涉到DevOps中有关Ops的部分内容。另外一方面是针对常规性的IT运维服务及管理,这方面需要围绕提升IT服务交付质量打造以流程、规范制度、技术人才和工具共同支撑的运维服务管理体系。

    七、安全可控能力
    在安全可控方面,着重于将安全问题摆在凸显问题。这里面既有应用安全,也有过程安全,同时也需要考虑本质安全。应用层安全包括应用安全、内容安全、工控安全等。过程安全包括物理层安全、设备层安全和数据层安全,其中设备层安全包括物理安全、环境安全、设备安全等,系统层安全包括网络安全、软件安全等,数据层安全包括数据安全、身份安全、隐私保护等。

    八、资源建设能力
    资源建设能力方面着重于持续积累组织过程资产,包括持续积累在研发过程中所获得的经验和教训,其中包含显性知识(文字档案),隐性知识(员工脑子中的思想、经验)。组织资产积累除了显性知识,更重要的是把隐性知识显性化。
    在这里插入图片描述
    同时还需要持续构建知识库,推行各项制度、标准、规范、流程。

    以上是本次针对软件研发管理体系建设的进一步思考,欢迎各位朋友广泛提建议,可以做进一步交流、探讨。

    展开全文
  • 软件研发管理体系建设

    千次阅读 2019-09-11 23:30:51
    最近一段时间,我一直在反复思考一个问题:我们的软件研发管理体系应该是怎样的?在不断思考的过程中,结合对公司近几年在软件研发方面的主要做法,逐步有一些粗浅的认识,在此将这些认识记录成文字,并期待能够与更...
  • 0.1、总则:采用质量管理体系是组织的一项战略决策,能够对组织的长远发展带来帮助;组织可以获得潜在巨大的好处(满足顾客,是顾客满意,应对风险与机遇等);标准没有强制完全按照体系的要求执行,可以灵活变通,...
  • 浅谈软件研发管理体系建设

    万次阅读 多人点赞 2018-12-08 21:40:52
    最近一段时间,我一直在反复思考一个问题:我们的软件研发管理体系应该是怎样的?在不断思考的过程中,逐步有一些粗浅的认识,在此将这些认识记录成文字,并期待能够与更多的伙伴碰撞,进一步完善这种认识,并逐步...
  • 信息安全管理体系ISO27001

    千次阅读 2019-06-21 23:27:15
    信息安全ISO27001等ISO27000系列包含下列标准 ... ISO 27001 信息安全管理体系—要求 ISMS Requirements (以BS 7799-2为基础)  ISO 27002 信息技术—安全技术—信息安全管理实践规范 (ISO/IEC 17799:2005) ...
  • 交付团队管理 开始于:为什么需要构建软件? (Begin With: Why Do You Need To Build Software?) There are a many reasons why an organization needs to build and deliver software. Some examples might be: ...
  • 产品研发管理体系和敏捷体系 当您问产品所有者敏捷工具是否适合他们时,您会得到混合的,有时是负面的答复。 敏捷工具确实可以为敏捷团队提供帮助,但是它们不能提供产品所有者完成其工作所需的所有功能。 同样,...
  • 敏捷软件交付项目管理及相关工具

    千次阅读 2011-04-02 16:47:00
    软件交付项目管理的特殊性在于其管理对象是软件交付,虽然其基本管理思想和管理方法都跳不出通用项目管理范畴,但其面临的全球化、复杂性和治理等方面的独特问题,迫使相关人员不断地去思考和创新软件交付方法和...
  • 如何做到项目准时交付之需求管理

    千次阅读 2018-12-02 12:10:16
    很多人可能都还不明白需求分析和需求管理之间的区别,通常我们说起来最多的都是需求沟通和需求分析,开会都是讨论需求如何如何做,这其实是需求分析的过程如何如何,而与需求有关的其他活动提及的比较少。...
  • 分布式网络管理体系

    千次阅读 2011-05-17 20:28:00
    摘要: 随着网络规模的不断扩大,网络结构的日趋复杂,对网络管理提出了新的需求,传统的集中式网络管理体系结构不能有效地适用于大型网络的管理,而分布式的网络管理技术的发展为满足这种需求提供了新的思路....
  • “互联网+”时代,软件产品要想满足快速增长的用户需求,高效、快速的迭代转型必不可少,面对时刻发生改变的互联网及业务模式需求,搭建高效的交付流水线更是势在必行。那么,如何构建一套能快速交付、保质又少风险...
  • 线上有上万个应用,上亿的用户即时在线,每天有几百个应用在线上更新,就像在时速200公里的高速公路上横穿马路维修栅栏一样,时刻保持着心惊胆战,而保护这个过程的体系就是阿里巴巴持续交付工具与实践。 现代开发...
  • 运维服务能力管理体系应建立的几种能力包括:1.运维业务战略设计与规划能力:企业应具备有对运维业务的定位、发展战略、新型运维业务发展进行规划分析的能力,能够规划出与战略相匹配的运维业务方向、业务的管理策略...
  • 本文来自于:零缺陷文化中心 零缺陷读后感:本文写的非常清晰到位,重点介绍了华为公司质量管理前后的发展历程,同时也给我们一些质量管理的思路和指引。希望感兴趣的同学能够领悟下质量管理的精髓。从2000年开始,...
  • 建立三权分立的运维服务组织管理框架、采用螺旋迭代式项目实施策略,对 IT 运维服务监督管理及其咨询项目的成功实施具有一定的积极作用。PPMTC 运维服务管理实施框架和四维一体运维服务绩效管理模型是 IT ...
  • 线上有上万个应用,上亿的用户即时在线,每天有几百个应用在线上更新,就像在时速200公里的高速公路上横穿马路维修栅栏一样,时刻保持着心惊胆战,而保护这个过程的体系就是阿里巴巴持续交付工具与实践。现代开发...
  • 8000字干货:那些很厉害的人是怎么构建知识体系

    万次阅读 多人点赞 2019-09-29 11:18:27
    分辨知识和知识体系的差别 理解如何用八大问发现知识的连接点; 掌握致用类知识体系的构建方法; 能够应用甜蜜区模型找到特定领域来构建知识体系。 1. 知识体系?有必要吗? 小张准备通过跑步锻炼身体,可因为之前...
  • 在编码后修改软件缺陷的成本是编码前的10倍,在产品交付后修改软件缺陷的成本是交付前的10倍;软件质量越高,软件发布后的维护费用越低。另外,根据对国际著名IT企业的统计,它们的软件测试费用占整个软件工程所有...
  • ERP项目管理——项目阶段及交付

    千次阅读 2016-12-23 14:00:28
    ERP项目管理分为四个阶段:准备、资料流程培训、模拟并行、提高验收。每个阶段都有相应的交付物,在绩效点到达前,这些交付物必须上传。   项目阶段及交付物 项目实施分为四大阶段:准备、资料流程培训、模拟...
  • 点击上方蓝字关注我们 面向价值实现的数据资产管理体系构建李雨霏1,刘海燕2,闫树11中国信息通信研究院,北京 1001912平安国际融资租赁有限公司科技驱动部,上海 201...
  • 敏捷管理认证体系大起底

    千次阅读 2018-03-05 19:06:28
    敏捷管理认证体系大起底本人专注于敏捷开发实践,在IT软件开发和项目管理方面有丰富工作经验。目前获得PMP,下一步致力于敏捷实践与敏捷认证。这段时间不断有小伙伴在问从事敏捷相关的工作都有哪些培训和认证,趁着...
  • 1.5:业界领先的研发管理体系简介 2 12. 《产品及生命周期优化法》(简称PACE——Product And Cycle-time Excellence) 12.1. 七个相关要素 13. 集成产品开发(Integrated Product Development...
  • 赵成的运维体系管理课视频教程

    千次阅读 2018-05-18 17:36:27
    专栏模块专栏共三个月,36 期,围绕以应用...这一模块是运维价值的体现,将围绕持续交付和稳定性建设两个方面,分享如何打造不需要任何运维参与的端到端交付过程,以及如何在实践中锤炼出稳定性保障体系等内容。云计...
  • 以下笔者各用一句话概括项目管理知识体系42个过程: 启动过程组: (1)制定项目章程:诞生项目,并为项目经理“正名”; (2)识别干系人:搞清楚谁与项目相关; 规划过程组: (3)制定项目管理计划:...
  •   启动过程组: (1)制定项目章程:诞生项目,并为项目经理“正名”; (2)识别干系人:搞清楚谁与项目相关;...(3)制定项目管理计划:编制项目执行的蓝图;...(6)创建工作分解结构:细化交付
  • 三大国际主流项目管理体系

    千次阅读 2016-11-07 09:20:11
    IPMP国际项目管理资质认证 PMP项目管理专业人员 颁证机构 英国政府商务部(OGC) 国际项目管理协会(IPMA) 项目管理协会(PMI) 官方标准 英国、澳大利亚和联合国标准 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 49,273
精华内容 19,709
关键字:

交付管理体系