• [热门活动] 【一行代码秒上云应用开发实训营】邀请好友完成上云实践反馈帖
    *学习敏捷上云开发要点,提升就业机会**体验Java,Node.JS,C#真实应用上云开发案例**收获华为无线耳机、拍立得、机械键盘、京东卡等丰富好礼* △适合人群:对敏捷DevOps开发有转型需求,渴望提升云上研发能力的开发者△活动时间:2022.5.16-2022.6.30△活动参与方式: 报名活动:点此链接,填写报名表即完成报名,点此了解活动详细规则;加入学习社群:完成本报名后请务必扫码进入学习群,专家全程跟踪辅导,伙伴比肩共同进步; 完成学习任务,赢取积分奖励本帖为邀请好友完成上云实践截图反馈帖。邀请好友在三个代码上云实践中任选一个,完成至部署成功,请好友按要求截图回复至本帖中。回复要求:好友华为云账号+邀请人华为云账号+截图(截图中包含部署成功界面且需露出好友本人的华为云账号)每增加一个好友的有效回复,可增加10积分每个好友在三个实践中选择任一个完成即可,每个好友只记一次积分,多次完成、多次回复不重复计入积分。加油~~ 
  • [问题求助] scrum删除工作项能不能恢复?
    scrum项目误删的工作项能不能恢复?
  • [云运维] 【案例】正浩创新:多云多资产,实现敏捷云上运维
    深圳市正浩创新科技股份有限公司,品牌名”正浩EcoFlow“,是一家专注于移动储能和清洁能源领域的国家高新技术企业,是移动储能与清洁能源技术的全球行业领跑者,入选《时代》杂志评选的Time Best Inventions 2021,由红杉资本中国基金、高瓴创投、中金公司投资。作为一家国家高新技术企业,正浩创新在创办之初就已将云计算引入公司的数字化创新体系内,用以支撑公司的产品研发和销售工作。公司线上电商业务发展势头强劲,目前形成了AWS+腾讯云为矩阵的多云、多资产云上环境,综合云上资产600+台,每个云VPC网络环境拥有各类主机、数据库、应用等资源,如要敏捷管控云上庞大计算资产,传统软硬件堡垒机已不合时宜。正浩创新面临以下3点运维管理问题:IT业务环境求变,传统堡垒机不可用在没接触行云管家之前,正浩创新的IT团队拥有使用杭州某龙头堡垒机品牌的经验,通过对比发现,该品牌软硬一体的堡垒机已无法满足公司对运维能力和运维效率的诉求,面对不同云厂商的资源访问差异、资源模型差异、使用方式差异,以及复杂的vpc网络环境,云资源的导入及管理显得力不从心。云上多资产,如何实现设备的批量调度操作正浩创新绝大部分的管理系统、业务应用都部署在云上,并广泛分布在AWS以及腾讯云的不同VPC网络环境中,在之前如要操作云上资源,需分别对AWS、腾讯云进行远程访问、密码/凭证登录、文件上传/下载、系统升级/打补丁等操作,且两个云厂商的云资源无法协同使用。云上运维既要敏捷,还要安全合规面对600+的云上综合资产,不仅需要敏捷管控以应对公司线上电商业务的快速开展,同时,正浩创新的IT团队也十分注重运维过程中的安全合规,并希望所有的运维操作都能被追溯和审计,取得效率和安全之间的运维平衡。解决方案部署行云管家,将互联网的敏捷带入云上运维新一代云堡垒机,更便捷的云资源导入行云管家是一款完全云化的产品,具备云计算高并发、海量存储的云原生特性,可统一纳管公有云、私有云、局域网主机/服务器、vCenter以及OpenStack虚拟机、其他网关设备等。借助行云管家,正浩创新IT团队正因此只需通过AccessKey录入、IP扫描、Excel批量导入等方式,完成云资源的一键导入和vpc网络拓补架构的直接映射,通过屏蔽AWS、腾讯云云厂商的平台操作差异,实现对云资源最直观的管理。快速统一访问入口,批量操作自动化进行现在,正浩创新在登录AWS、腾讯云等云平台时不用担心账号、密码/凭证分散在各类远程访问工具,行云管家为用户提供了云主机访问的统一入口。正浩创新在导入云资源时,行云管家就已为正浩创新分别创建了AWS云账户、腾讯云云账户,每个云账户都包含了已购买的云主机、对象存储、CDN等云资源,同时将每个云厂商下的主机资源都进行了分类展示,并提供了Web桌面访问、本地工具访问、登录凭证访问、公有云厂商管理终端直接访问的访问方式,继而实现一个控制台快速登录不同云厂商的不同云主机。在应对大批量的运维操作,通过行云管家集成的SaltStack/ansible运维工具库,正浩创新能够批量对主机执行脚本、命令,以及将文件批量分发至目标主机、批量从多台主机采集文件,实现对多台主机的各种批量运维操作。符合等保2.0相关规范的运维审计系统不仅是一款运维效率产品,也是一款运维安全产品,行云管家内置了云堡垒机模块,为正浩创新提供了“事前授权、事中监管、事后审计”的运维审计能力,确保了公司IT团队操作云资源的合规性,也同时满足了等保2.0评测合规性的要求,全面保障公司IT资产的安全运维、合规审计。价值总结云上600+的主机、数据库、企业应用等综合资产,AWS+腾讯云的多云局面,在以往,如果借助传统堡垒机根本无法实现以上云资源统一运维的目标,现在,正浩创新IT团队通过部署行云管家不仅实现了多云多资产的敏捷运维,还为公司业务的长足发展奠定了强大的IT资源支撑能力。
  • [新手课堂] 资讯 | 云端一条生产线,让软件开发更敏捷、更安全
    Gartner报告显示,至2025年,全球需要构建5亿个新应用,新增需求超过交付能力5倍。以软件高速迭代为特征的数字化竞争时代已经到来。面对用户需求的爆炸式增长、市场环境的瞬息万变、开发落后延迟应用安全落地问题的日益凹显,企业对研发效能的期望越来越高。应用之所以赋能业务发展,背后依赖着卓越的软件交付技术。选择一个开发更敏捷,过程更安全的软件开发模式,已成为企业考量的关键。在软件开发的奔涌发展中,DevOps通过让开发、运维、测试协同作战,提高研发效率,实现高效交付,已经成为企业软件研发的主流,被众多企业所采用。在这样的背景下,基于华为30余年深厚积累和跨领域实践考验的华为云软件开发生产线DevCloud脱颖而出,为开发者提供从需求规划、到编译、发布、构建、部署全生命周期的软件工具服务,帮助研发团队完成研发知识的沉淀,助力企业专注业务创新。什么是软件开发生产线DevCloud华为云DevCloud把华为全流程软件开发经验放到华为云上,提供给开发者使用。提供全代码、轻代码、低代码等各种开发模式,支持10多种主流开发语言,集成300多个工具,内置15000多代码检查规则。研发环节全云化:开发、测试、部署、运维、运营等一系列研发活动都在云中完成,全面支撑各类型研发企业落地DevOps。目前已经商用13个服务,3个行业解决方案,支持Web开发、移动应用开发、微服务开发和Cloud Native应用开发等多种开发场景。作为一站式全流程安全可信的智能化DevSecOps平台,华为云DevCloud目前已服务于华为内部所有的产品线。随着“十四五”规划提出要强化基础组件供给,大力发展云计算/大数据/人工智能/区块链等技术,信创产业生态已成为国家“新基建”的重要内容。紧跟国家政策,响应客户需求,华为云DevCloud在软件开发过程中,通过生产要素、生产工具、实现过程的攻关和替代,最终保障“软件产品”的可靠与可信。开发更敏捷软件开发生产线效率提升6个“1”为了更好的帮助企业和开发者提高软件开发效率,华为不断加大对软件工程&IT工具的投入。通过构建云原生的DevCloud平台,带来了构建效率10倍提升、测试管理容量10倍提升、测试效率50倍提升、代码仓性能5倍提升,大幅缩短研发周期,加快软件产品的落地发布。其中,编译构建会影响开发、测试团队之间的衔接速度,是影响研发效率的重要环节。华为云 DevCloud提供多级分层级大规模构建加速:• 实践四级构建优秀机制,编译结果快速反馈,构建质量逐层看护,从个人、门禁、版本、全量分层看护质量和效率• 具备40万+CPU核大规模构建计算资源调度能力,支撑华为10万+开发人员每天100万+次构建• 构筑精准的极速构建技术,基于编译原理,实现构建依赖自动分析、精准增量和分布式构建,1亿行代码1小时可构建完成• 建设构建过程可追溯体系,覆盖构建活动全过程,包括构建数据源、构建环境、执行过程、构建结果,支撑华为ICT全球发布的产品实现源码安全认证在华为云DevCloud支撑华为内部研发人员工作场景中,研发效能达到了6个1目标:1分钟故障到恢复、1分钟代码提交到构建、10分钟代码提交到测试、1小时自动化测试到部署、1周迭代周期、1月需求到闭环。过程更安全安全“左移”的软件开发模式Sonatype《2021年软件供应链状况报告》指出,全球软件攻击同比增长650%,软件供应链攻击事件频发,企业的安全风险敞口加大。DevOps集成安全控件、工具和流程,使软件交付的每个阶段启用自动安全检查,确保安全能够融入每个开发阶段和节点。安全建设重心从 "运行时防护 " 转向 "安全前置 ",从外部安全建设转向内生安全,使安全成为软件自身的基本属性。即是 " 安全左移 "。华为作为首个提出可信软件工程能力概念的企业,推出的华为云DevCloud平台,将华为多年积累的安全可信能力进行深度融合,通过解决方案让安全顺利左移,确保应用在出生的过程中就是安全的、可信的,从而让安全能够敏捷落地于应用的生产、交付、运行过程中。通过代码安全检查、软件成分分析、Web和主机安全漏扫、终端应用安全测试四大安全服务,打造SecDev统一安全可信入口。以终端应用中的移动应用安全测试为例,软件开发生产线提供一站式移动应用安全检测服务,快速对应用的隐私声明和APP真正执行的动作做对比检测,确保产品整体规划、行为内容符合各国家法规隐私合规要求;不仅如此,DevCloud的服务合规检测能力与华为应用市场同源,能大幅提升企业APP应用上架效率。华为云软件开发生产线在传统行业的落地实践德邦快递基于华为云软件开发生产线提供的全流程敏捷、安全可信的DevCloud交付能力,提升德邦快递CICD业务流程。目前,双方已完成了80+系统上云工作。在效率提升层面:为德邦快递提供单项目、多项目软件,应用开发全生命周期的敏捷协同管理,满足了德邦快递跨团队管理、可视化的全景规划、多维度的度量统计等需求。在质量优化层面:华为云从无到有,提供了精细化的用户管理方案,不仅能快速复用,还有15+维度测试指标度量,支撑企业全方位决策;优化测试设计,提升测试流程线上化程度,实现需求、用例、缺陷、报告整体可追溯;同时提供代码检查门禁,在代码开发阶段对代码质量和安全问题进行自动化检查。在安全可信层面:德邦快递依托华为云软件开发生产线提供的代码安全、数据安全、服务安全保障,德邦快递搭建了全面加固的一站式软件持续交付生产线,保障产品的需求、设计、代码、测试、缺陷等核心要素端到端可追溯,消除高可用及备份威胁,提升平台韧性,支持误删除等场景及时恢复,全面有效降低安全风险。在组织认知和运作层面:提供了敏捷的项目管理,专业标准的敏捷Scrum项目协作和看板流程,支持多项目组合管理,从会用到用好,在企业运营的工具、业务、文化三大方面持续深化运营DevOps。通过华为云软件开发生产线,德邦快递实现了总体成本下降15%,暴力分拣行为减少50%,快递破损同比下降14.3%。从2020年到2021年,德邦快递的快递员日均收派效率从52件/天提升到了61件/天,中转站的分拣产能也提升了足足22.5%之多。最后软件开发生产线通过提供研发工具服务,让软件开发过程更加简单、高效。开发周期将在软件开发生产线模式下持续缩短,开发效能将在测试、运维领域取得更多突破。开发人员能够大规模开发更安全、更有韧性的软件系统,开发和协作的潜力就得到进一步释放,这是华为云软件开发生产线DevCloud为企业数字化转型贡献的独特价值,华为云希望通过更敏捷、更安全的软件开发生产线,帮助企业带来业务上的“提质增效”。转自华为开发者社区
  • [高校开发者专区] 学习心得
           整个学习材料了解到从敏捷起源--敏捷思维-敏捷宣言-敏捷原则-敏捷较传统模式更符合软件开发规律-敏捷与瀑布的外在区别;进而引入华为DevCloud的一站式开发平台,集华为研发实践、前沿研发理念、先进研发工具为一体,面向开发者提供研发工具服务,让软件开发简单高效。DevOps是目前最流行的开发模式,重视软件开发人员和运维人员的沟通合作,通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。DevCloud基于华为研发云的成功实践经验,通过云服务的方式提供一站式云端DevOps平台。开发团队基于云服务的模式按需使用,在云端进行项目管理、配置管理、代码检查、编译、构建、测试、部署、发布等。在云端进行项目管理、配置管理、代码检查、编译、构建、测试、部署、发布等。
  • [高校开发者专区] 学习心得
    通过这次HCSD集训营活动,我了解到DevOps这种开发模式能够通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。DevStar服务的“智能OCR图像文字识别”模板一站式生成应用代码并部署到函数工作流FunctionGraph,实现识别指定图片中的文字信息并显示在页面上,极大方便了我们地工作。VSS一键自动化扫描软件包/固件,能够快速排查其中的开源软件、安全配置等风险,使产品安全现状清晰明了。华为云DevCloud整个实验流程很顺利,在本次实验中使用了弹性云服务器,多种购买方式,多种计费方式适应了不同目标人群。在平台中添加服务器检查及代码检查功能十分便利,部署和构建时具有灵活的可视化操作。流水线的构建大大减少修改代码所需成本,节约人力与时间。通过本次实验,我对服务器建立,维护有了更深的了解。整个学习材料了解到从敏捷起源--敏捷思维-敏捷宣言-敏捷原则-敏捷较传统模式更符合软件开发规律-敏捷与瀑布的外在区别;进而引入华为DevCloud的一站式开发平台,集华为研发实践、前沿研发理念、先进研发工具为一体,面向开发者提供研发工具服务,让软件开发简单高效
  • [高校开发者专区] 学习心得
    通过这次HCSD集训营活动,我了解到DevOps这种开发模式能够通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。DevStar服务的“智能OCR图像文字识别”模板一站式生成应用代码并部署到函数工作流FunctionGraph,实现识别指定图片中的文字信息并显示在页面上,极大方便了我们地工作。VSS一键自动化扫描软件包/固件,能够快速排查其中的开源软件、安全配置等风险,使产品安全现状清晰明了。华为云DevCloud整个实验流程很顺利,在本次实验中使用了弹性云服务器,多种购买方式,多种计费方式适应了不同目标人群。在平台中添加服务器检查及代码检查功能十分便利,部署和构建时具有灵活的可视化操作。流水线的构建大大减少修改代码所需成本,节约人力与时间。通过本次实验,我对服务器建立,维护有了更深的了解。整个学习材料了解到从敏捷起源--敏捷思维-敏捷宣言-敏捷原则-敏捷较传统模式更符合软件开发规律-敏捷与瀑布的外在区别;进而引入华为DevCloud的一站式开发平台,集华为研发实践、前沿研发理念、先进研发工具为一体,面向开发者提供研发工具服务,让软件开发简单高效
  • [高校开发者专区] f
    然后对于打卡一的实验智能增值税发票识别,体验过后,感觉到的是顺应市场需求,发票拍照识别系统可以解放财务的双手,自动采集发票上的会计要素,自动对票据建立索引并归档,提高凭证信息查阅的一致性与准确性,与传统的会计人工录入数据方案相比,可以减少90%的工作量,提升了其工作效率。      最后是打卡实验三“使用华为云DevCloud实现20分钟一行代码上云”; 因为在之前参加其他活动,所以这次我就借助于加入的课程购买了“基于华为云DevCloud的托马斯商城”,以及通过实验手册进行了实验练习,并学习完成,以85分通过了该微认证。   整个学习材料了解到从敏捷起源--敏捷思维-敏捷宣言-敏捷原则-敏捷较传统模式更符合软件开发规律-敏捷与瀑布的外在区别;进而引入华为DevCloud的一站式开发平台,集华为研发实践、前沿研发理念、先进研发工具为一体,面向开发者提供研发工具服务,让软件开发简单高效
  • [热门活动] 【一行代码秒上云应用开发实训营】一站式学习路径,领官方证书,赢无线耳机、拍立得、机械键盘、京东卡等丰富好礼!
    阶段性积分公布截止6月24日,活动积分详情如下,如有任何疑问请进入学习社群联系小助手进行解答和核实,活动将于6月30日结束,小伙伴们加油冲刺吧~~*学习敏捷上云开发要点,提升就业机会**体验Java,Node.JS,C#真实应用上云开发案例**收获华为无线耳机、拍立得、机械键盘、京东卡等丰富好礼* △适合人群:对敏捷DevOps开发有转型需求,渴望提升云上研发能力的开发者△活动时间:2022.5.16-2022.6.30△活动参与方式:报名活动:点此链接,填写报名表即完成报名;加入学习社群:完成本报名后请务必扫码进入学习群,专家全程跟踪辅导,伙伴比肩共同进步;完成学习任务,赢取积分奖励:点此链接,GET全部学习任务入口NO.积分项积分任务积分奖励任务入口回复地址1学习在线课程完成指定在线课程学习,学习进度100%即代表完成本课程学习。回复要求:无需回帖,只需使用华为云账号登录学习平台完成学习,后台可记录学习完成度。10积分学习课程任务入口/2代码上云实践按照实验手册完成指定实践内容,并按实验手册要求对完成的步骤进行截图(含创建项目、代码托管、编译构建、部署成功),如实验顺利完成,只提交部署成功的截图即可,截图右上角露出华为云账号,将截图回复至指定帖子中。如无法完成实验,做到哪一步提交哪一步的截图即可,将根据实验完成进度奖励积分。实验过程中遇到任何问题、有任何意见或建议,可跟随截图一起回复至帖子中,将为您尽快解决。回复要求:华为云账号+截图根据实验完成进度奖励积分完成至创建项目 10积分/实践完成至代码托管 15积分/实践完成至编译构建 20积分/实践完成至部署成功 30积分/实践如一个实验部署成功,默认前序步骤已全部完成,则奖励30积分,三个实验全部完成将获得90积分奖励。如无法完成实验,将根据提交的截图,按实验完成进度奖励积分。回帖中反馈实验遇到的问题、意见或建议   10积分/有效反馈Java实验入口Node.js实验入口C#实验入口Java项目上云实验反馈帖 Node.JS项目上云实验反馈帖C#项目上云实验反馈帖3参加评测考试根据在线课程学习成果,完成指定考试内容,根据考试得分不同,获得不同积分。回复要求:无需回帖,只需使用华为云账号登录考试系统完成答题,后台会记录考试分数。考试前请务必完成实名认证,否则证书无法显示真实姓名,只显示用户名代码哦!0<考试得分≤60,奖励10积分60<考试得分≤80,奖励15积分80<考试得分≤100,奖励20积分评测考试入口/4发布代码上云对比评测根据用户在代码上云实践中的体验,与使用非云端部署做对比,可在使用的工具、搭建的环境、需要的资源、用时长短等维度进行对比,以博客形式发送至华为云开发者社区。回复要求:华为云账号+博客链接发布有效评测,奖励30积分评选为优秀评测,奖励50积分/评测文章反馈帖5邀请好友报名活动邀请好友报名活动(系统自动统计,无需回复)邀请报名人数≥10人,奖励10积分;邀请人数每增加10人,给邀请者增加5个积分,以此类推,增量不满10人则不追加积分奖励邀请入口/6邀请好友完成上云实践邀请好友在三个代码上云实践中任选一个,完成至部署成功,请好友按要求截图回复至指定帖子中。回复要求:好友华为云账号+邀请人华为云账号+截图(截图中包含部署成功界面且需露出好友本人的华为云账号)每增加一个好友的有效回复,可增加10积分每个好友在三个实践中选择任一个完成即可,每个好友只记一次积分,多次完成、多次回复不重复计入积分。10积分/好友有效回复好友有效回复指好友完成任一实验的部署步骤,即部署成功,截图右上角露出好友华为云账号,将好友华为云账号+邀请人华为云账号+截图回复至指定帖子中。/邀请好友完成上云实践反馈帖7参加满意度调研完成活动满意度调查问卷回复要求:无需回帖,只需使用华为云账号登录问卷系统完成调查问卷。10积分调研入口/本活动上云实践需使用华为云代金券购买ECS RDS等云产品,代金券将由活动主办方提供,请按实验手册完成指定操作后,按示例截图并将截图反馈至指定帖子中。截图需包含右上角华为云账号,戳此进入代金券领取帖回复要求:华为云账号+截图小助手将在收到截图后为您尽快发放代金券兑换码,发放时间为每天11点和每天3点2个时间段,未收到代金券的小伙伴可在社群中@小助手加急处理哦。△活动奖励:积分排名奖品活动期间总积分排名第1名攻城狮豪华大礼包(含富士拍立得1个,雷柏机械键盘1个,无线鼠标1个,华为手环1个,定制双肩包1个)活动期间总积分排名第2-3名雷柏机械键盘1个活动期间总积分排名第4-10名攻城狮精致礼包(含定制鼠标垫1个,定制水杯1个,定制T恤1件)活动期间总积分排名第11-30名攻城狮实用礼包(含三合一数据线1个,定制水杯1个,定制T恤1件)邀请好友参与活动,赢取升级奖励邀请条件奖品名称抽奖名额完成上云实践的有效邀请人数≥50HUAWEI FreeBuds 3 无线耳机 有线充版(陶瓷白)1完成上云实践的有效邀请人数≥30荣耀FlyPods青春版 真无线耳机(铃兰白)2完成上云实践的有效邀请人数≥10100元京东卡3完成上云实践的有效邀请人数≥550元京东卡5邀请条件奖品名称抽奖名额完成报名活动的有效邀请人数≥50150元京东卡2完成报名活动的有效邀请人数≥30100元京东卡3完成报名活动的有效邀请人数≥1050元京东卡5如何邀请好友?第一步:点击报名 一行代码秒上云应用开发实训营>>>第二步:点击分享有礼第三步:通过任意方式分享给好友第四步:好友报名活动,在三个代码上云实践中任选一个,完成至部署成功,请好友按要求截图回复至指定帖子中。△奖品发放说明:活动期间,同一用户不得重复获奖,以所获最高奖励为准进行发放。本次活动抽奖将采用巨公摇号平台(https://www.jugong.wang/random-portal/)进行抽取,将对抽奖过程做录屏公示,如您对评奖方式有异议,请勿参加本次活动。每位参加活动的用户理解并同意,为联系获奖用户以及奖品发放的需要,用户须在参与活动之时提供诸如姓名、联系方式、电子邮箱、通讯地址等真实个人信息,活动主办方将仅为前述目的以及适用法律规定的最小限度内收集和使用用户的个人信息,本次活动所收集的个人信息将在活动结束后删除。(用户在向华为云提交个人信息之前,应阅读、了解华为云《隐私政策声明》;用户参加本活动视为理解并同意华为云《隐私政策声明》,华为云《隐私政策声明》网页地址如下:https://www.huaweicloud.com/declaration/sa_prp.html)。获奖用户在领奖界面填写获奖信息,活动结束且用户填写完整领奖信息后14个工作日内,将统一发出奖品,不额外收取任何费用。由于获奖用户自身原因(包括但不限于提供的联系方式有误、身份不符或者通知领奖后超过30天未领取等)造成奖品无法发送的,视为获奖用户放弃领奖。为保证活动的公平公正,华为云有权对恶意刷活动资源(“恶意”是指为获取资源而异常注册账号等破坏活动公平性的行为),利用资源从事违法违规行为的用户收回抽奖及奖励资格。本活动规则由华为云在法律规定范围内进行解释。华为云保留不时更新、修改或删除本活动规则的权利。所有参加本活动的用户,均视为认可并同意遵守《华为云用户协议》,包括以援引方式纳入《华为云用户协议》的《可接受的使用政策》、《法律声明》、《隐私政策声明》、相关服务等级协议(SLA),以及华为云服务网站规定的其他协议和政策(统称为“云服务协议”)的约束。云服务协议链接的网址:https://www.huaweicloud.com/declaration/sa_cua.html 如果您不同意本活动规则和云服务协议的条款,请勿参加本活动。
  • [技术干货] 我们距离DataOps还有多远?
    一、起源2014年:Lenny Liebmann提出DataOps的概念,在《3 reasons why DataOps is essential for big data success》这篇文章中,Lenny提出DataOps是优化数据科学和运营团队之间协作的一些实践集。2015年:Andy Palmer将这个理念发扬光大,提出了DataOps的四个关键构成,数据工程、数据集成、数据安全和数据质量。2017年:Nexla的Jarah Euston把DataOps的核心定义为从数据到价值。这个是首次把DataOps和业务价值关联起来的定义。2018年: Gartner将其纳入到数据管理的技术成熟度曲线,标志着DataOps正式被业界所接纳并推广起来。 DataOps的概念自2014年提出至今已有8年之久。Gartner在2018年将DataOps纳入数据管理技术成熟度曲线,预计未来5-10年能达到成熟的水平。然而在2021年的报告中,DataOps仍然处于技术的“萌芽期”,预计未来2-5年可能达到成熟水平。现在看,留给DataOps的时间可是不多啦。二、定义IBM:IBM将DataOps定义为DataOps是人员、流程和技术的有机结合,用于快速向数据公民提供可信的高质量数据。Gartner:DataOps是一种协作性的数据管理实践,专注于改善整个组织的数据管理者和消费者之间的沟通、整合和数据流的自动化。Wikipedia:DataOps是一套实践、流程和技术,它将综合的、面向流程的数据观点与敏捷软件工程中的自动化和方法相结合,以提高质量、速度和协作,促进数据分析领域的持续改进文化。中国信通院:数据研发运营一体化(DataOps)是一种面向数据全生命周期,以价值最大化为目标的最佳实践。聚焦于协同从数据需求输入到交付物输出的全过程。明确研发运营目的,细化实施步骤,在价值运营、系统工具、组织模式、安全风险管理的支撑下,实现数据研发运营的一体化、敏捷化、精益化、自动化、智能化、价值显性化理念。三、现状从定义上来看,国外的一些机构纷纷给出自己的一些定义和理解,强调了DataOps的实践、敏捷、协同等特点。普遍认为DataOps是一种先进的数据分析、开发、管理理念。2022年,中国信通院联合各行业组织机构对DataOps定义为一种由价值运营、工具、组织管理和安全加持下的最佳实践,并突出了一体化、敏捷化、精益化、自动化、智能化和价值显性化的特征。从实施上来看,尽管Gartner的预测与实际发展变化难以完全契合,但从2018~2021年连续的报告上来看,DataOps长期处于“萌芽期”的位置,这也一定程度上反映了国内外组织对DataOps的实践还依然处于摸索尝试的阶段,鲜有组织明确的宣传自己的“成功”案例。整体上来看,组织对DataOps的实践状态一直处于雾里看花、盲人摸象的阶段。虽然我们注意到越来越多的企业开始了对DataOps实践的尝试,越来越多的厂商试图开发适应DataOps理念的工具,但是“我们好像实践了DataOps,但又好像没有”,这句话很好地描述出了不少企业的现状。2022年4月,中国信通院联合工商银行、招商银行、农业银行、平安银行、浦发银行、南京银行、阿里云、腾讯云、新炬网络、深算院等20余家单位对DataOps的定义、标准框架、能力特征等细节进行了深入的交流和探讨并达成了一致。未来我们将结合中国的数据发展情况,打造一套适合我国数据行业发展的DataOps体系。来源:中国信通院云大所
  • [技术行业前沿] 三问三答,解传统企业敏捷转型担忧
    本文分享自华为云社区《[传统企业敏捷转型常见3大疑虑及解答](https://bbs.huaweicloud.com/blogs/346712?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=paas&utm_content=content)》,作者:敏捷小智 。全球经济已经进入数字化和VUCA时代,充满变化和不确定性,敏捷方法—Scrum以其能够快速响应市场变化,提升研发效率等特点逐渐成为主流研发管理模式,越来越多的传统企业认识到改革的必要性,并开始准备引入敏捷的概念用于软件开发团队的管理。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/22/1650610138173718047.png)但是转型就意味着一场变革,变革就意味着阵痛,转型过程中肯定会遇到一定的阻力和问题。那么敏捷转型是否需要先决条件呢?当在这些条件不能满足时,是否就不能完成敏捷转型呢?如果敏捷转型如何获取外部支持?本文将对敏捷转型常见的担忧和疑虑进行分析和解答。# 1. 敏捷转型是否需要先决条件?有些传统企业,在决定进行敏捷转型之前,通常会存在这样的疑虑,敏捷转型是否需要先决条件?也就是我们常说的敏捷基因,答案是肯定的,下面总结敏捷转型的6个关键因素帮助您的转型有个正确的开始。## - Scrum团队敏捷开发有着清晰的管理逻辑和规范,它需要建立在Scrum团队之上,团队成员需充分理解和认可敏捷开发,并能在工作中实际落实敏捷开发理念。Scrum团队具有以下几个特点:• 团队规模小:5~9人,小于5人生产力下降,多于9人则增加协调和沟通成本。• 跨职能团队:完全具备交付产品增量的各项技能。• 自组织团队:团队被授权自己管理自己的工作过程和进度,并自己决定如何完成工作。• 全职工作:保证项目成员专注于单个项目。• 集中办公:便于面对面交流,消灭信息孤岛,信息通畅。## - 一个明确的指标在开始敏捷转型之前,团队需要知道转型成功会是什么样的。管理层和团队都需就将要采取的措施达成共识,以确认新工作方式是否确实有效。这个指标不应该从某个职能角色,比如测试人员、开发人员等出发,而应该从项目管理全局,比如说用户的满意度,从版本的交付频率等角度去考虑敏捷开发带来的绩效优化。## - 合适的Scrum MasterScrum Master的专业度、情商、控制力、逻辑思维能力和计划策略执行力、业务熟悉度、IT专业知识储备度、部门权限等,都是决定敏捷转型是否成功的关键因素。优秀的Scrum Master是敏捷项目的推动人,在促进敏捷活动开展,方向把控,保持进度,调节团队氛围,获取外在支持等方面都起着重要的作用。## - 合适的产品负责人产品负责人(PO)是敏捷开发中至关重要的角色 ,是团队和敏捷转型的关键。产品负责人可以有效激励团队,对团队有强烈的信任。他清楚的知道团队的愿景和目标,以及需要做什么,怎么做能够带领团队达成这个愿景和目标。产品负责人一定是全职的,每个团队一个PO并不能保证敏捷转型成功,但多个团队一个PO无疑是一场灾难。## - 外在的支持度来自企业内部高层、客户、跨职能部门的支持,支持的力度越大意味着我们在敏捷转型过程中提出的诉求会得以满足,保证敏捷活动的正常开展,甚至能够得到试错和经验积累的机会。## - 研发流程的自动化敏捷开发每个迭代就要交付一个可运行的产品增量,也就是说理论上至少在每个迭代结束之前需要集成和发布一次应用,而在实际敏捷开发过程中为保证产品是可集成可交付的,其实是每天一次,甚至是每天多次的去集成和发布,就要求具备端到端无缝集成,实现源代码的自动拉取构建、代码自动扫描检查、测试环境的自动部署、API测试自动化等去保证高频率的交付。# 2. 组织文化如果没有敏捷基因的话,那这个组织是否适合继续推进敏捷转型?还是应该放弃?“没有一个时代像现在这样,变化如此之快,转型升级已不再是选择,而是必须。在这个飞快向前的时代,每个人、每个组织只有超越外部变化的速度,才有可能在这个时代致胜未来。”——拉姆·查兰在8月9日《哈佛商业评论》中文版举办的第四届“人才经济论坛”上如是说。当你在了解并想尝试敏捷转型的时候,是不是就意味着你所在组织的研发模式已经跟不上瞬息万变的市场需求了呢?不管是企业、组织还是个人都需要与时俱进,才不会被时代淘汰,拥抱变化、响应变化才是应万变的诀窍。那么有人就会提出这样的质疑,上面说了敏捷转型时需要前提条件的,我们的组织不具备这样的条件,如何实现敏捷转型?一般来说,不具备敏捷转型条件的组织不适合大刀阔斧的去转型,一切盲目的行动大部分都不会有好的效果。首先我们意识到敏捷转型的必要性,在不确定的情况下,可以尝试选择一个项目、一个业务做试点,或者组建一个团队,实现新的运营及决策机制,这是非常重要的探索尝试敏捷开发的方法。这么做的一个原因是小范围试点比较灵活可控,敏捷环境比较好搭建,即便不成功,造成的伤害也比较少。另一个原因是小范围尝试成功后可由点及面循序渐进的辐射到整个组织内部的开发中去,这也正符合了敏捷小步快跑交付的思想理念。组建敏捷团队时如果内部人员Scrum经验不足,目前业内有丰富的敏捷支持服务可供选择,在专业的敏捷指导下进行敏捷试点落地,学习业界标准做法、获取实践经验,从而可以和企业实际情况和需要结合,以便制定更有针对性、更适合企业自身的下一步的推广和落地方案。# 3. 如何获取团队或部门的支持?还有另外一个大家比较关心的问题是,推动敏捷过程中遇到团队或部门的抵触要如何处理?!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/22/1650610249098789389.png)一般来说抵触敏捷开发转型的人都对敏捷存在错误看法或观念,比如:• 敏捷没有过程控制。• 敏捷意味着不确定性,不可预估,存在风险。• 敏捷团队不做计划,因此无法对客户做出承诺。• 敏捷对于简单的项目是可行的,但我们的系统过于复杂不适合敏捷开发。同时,对敏捷存在误解的领导可能会认为敏捷团队是自组织团队,敏捷转型后自己将无事可做;对敏捷存在误解的成员可能不喜欢变化,对新的工作方式缺乏安全感,觉得如果有人告诉我该做什么,会更有安全感。基于以上问题,我们在引入敏捷开发要预见性的抵触问题,而避免用领导者的权力蛮横改革。我们可以采用包括但不限于以下措施:• 运行一个试点项目,团队包括抵触敏捷开发人员,让他们参与新过程的设计中,这是减少抵触的一个不错方法。• 确保试点项目之外的人员能够看到采取敏捷开发的效果。• 提供培训,讲述Scrum成功故事,通过参加讨论会或区域间的敏捷兴趣小组等。• 改变团队人员组成。• 鼓励正确行为,树立模范。• 找到真正阻碍,判断个体抵触Scrum的深层原因最后,要知道即便你能证明自己是正确的,赢得别人的支持也是比较困难的,尽管当前的开发环境存在很多问题,但是在真正相信有更好的方法可以替代之前,大多数人是不愿做出改变的,给团队足够的耐心,了解他们的担忧和顾虑,帮助解决问题,消除顾虑。价值高的事情总是需要花大量时间的。以上解答了敏捷转型中的担忧和疑虑,希望对您的转型之路有所帮助,但是没有一条成功的道路是可以完全复刻的,我们就要结合自身的公司文化、管理层以及人员本身等情况探索自己的转型成功之路。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/22/1650610270257494871.png)本文由DevSecOps专家服务团队出品,前往 专家服务 ,获取更多DevSecOps工程方法、工具平台、最佳实践等干货。
  • [技术干货] 敏捷建模“杀”入企业数字化【转载】
    作为DDDChina的发起者之一,看着越来越多的技术人员加入到领域驱动设计(Domain Driven Design,DDD)社区,分享经验、总结实践、甚至于辩论观点,确实十分高兴。然而,有些忧心的是并未看到很多非技术人员参与其中,这与当初力推DDD的目的仿佛渐行渐远 —— 我们一直认为DDD是促进业务和技术在系统架构上逐步达成共同认知的一种好方法。只有共同认知才能共同演进,才有能够避免一次又一次上演的遗留系统惨剧。也许是疫情给了我们更多独立思考的时间,我们也清晰地认识到没有能够吸引更多的非技术专业人员加入,应该说并非是我们声音不够大,更重要是DDD所涉及的方法仅仅瞄准了整个企业架构建模过程的一个阶段,对于我们希望吸引的非技术群体,他们有着自己更需要参与并负责的阶段。 这促使我开始从整个企业的视角去考虑架构建模问题,目标也不仅仅局限于让系统架构能够跟随业务需求的变化而持续演进。面对这个数字化时代,企业的数字化底座成为了核心基石,而这个底座的架构是高质量可持续发展的关键。我希望去解决当下很多人都已经看到的传统企业架构方法带来的问题,从不同的视角去尝试新的方法,找到破局之路。1.从静态走向动态“Be water, my friend.” - Bruce Lee(李小龙) 随着数字化进程的持续深化,企业越来越依赖于自身的信息化和数字化系统,甚至很多新兴业务的诞生就源自于技术的发展,比如现在大家习以为常的人脸识别认证方式,正是由于机器学习技术在近5年的快速突破才得以实现。这样的依赖性一方面激励着企业在信息和数字化系统研发方面持续加大投入,另一方面也让系统的全局复杂度快速攀升。过去从企业内部运营视角出发形成的简单通用信息系统划分,如ERP、CRM等,已经完全不能满足数字化时代企业的需要了。于是我们也看到阿里这样的互联网巨头提出了业务强绑定的“中台”系统概念。移动互联给我们展现了数字化业务的潜力,而未来的元宇宙、Web3.0将有可能带来更多的创新、甚至颠覆性的业务。由此企业所依托的信息化和数字化系统必然会要求很大程度上的“定制化”,这也让针对全局设计的企业架构(Enterprise Architecture,EA)工作变得越来越重要。然而,已有的企业架构方法,如TOGAF、Zachman,更多关注的是企业架构治理的流程和参考内容模型,希望从一个抽象层面指导企业产出适合于当前业务的企业架构全局视图。为了驾驭日益复杂的业务场景,往往需要将设计和实施步骤越来越细化,从而能够调动不同的的专业细分人员来完成固定事项。在企业实际应用过程中,这样的企业架构方法带来了两个比较显著的问题:产出的架构模型及组件划分更多是以确定性的“静态”视图呈现,每个阶段的产出往往是通过特定人群“翻译”上一个阶段模型而得出的,这样的工作模式有违软件需求的基本特征,即需求的澄清实际是通过可工作的软件交付来迭代完成的;对于未来业务的变化和创新“设计”不足,往往只能将感觉变化比较快的领域,如移动互联网应用,划到产出的架构模型之外,美其名曰“非模型”需求。不少企业架构专家提出信息化系统在一些行业的主干业务上应该是比较清晰的,由此,类似TOGAF方法的“静态”产出应该是适合的。然而,我们需要看到,这样的假设实则非常危险:在通信行业,从2G、3G到4G的连续发展,给了大家类似的预期;然而5G的到来,很大程度上颠覆了过去十几年积累的系统模块划分,于是全球各大运营商纷纷开始高喊数字化转型,其中很大一部分工作就是要改变过去的信息化系统架构。国内不少大型银行都在实施基于Zachman方法的企业架构,希望通过统一的业务模型和IT模型来驱动新一代信息化系统建设,从而能够支撑未来的数字化业务发展。然而即使如清算这样看似稳定的底座,真的就已经业务上明确了吗?数字货币和区块链技术应该说才刚刚崭露头角,未来的具体影响还不得而知。我们更应该尊重这个科技时代的客观规律,不能一边高喊着“主动求变”,一边却在为系统的演进设定“确定性”的障碍。这样一时的大力而为,埋下的是未来的诸多隐患,苦的是为了业务连续性而需要持续开发和维护系统的研发团队。由此,我们希望用动态的“建模”,来替代大家习以为常静态的“架构”。我们希望推动一系列针对企业价值定位的、可持续的、可落地的建模活动,来促进整个企业的系统体系得以持续的演进,从而能够通过持续提升组织的整体架构认知,完成对业务发展的支撑和创新的使能。2.针对软件开发本质去建模软件带来的新产品形态在这个数字化时代被越来越多的人认知。作为程序员,我们曾经很难向业务同事解释为什么之前加一个按钮一天完成,现在加一个类似按钮需要三天。而现在大家都知道软件从第一行代码开始就是会被持续修改的,是否易于修改成为了开发效率的基础。真正的难点是如何让软件在面对未来源源不断新需求时,持续保持较低的修改成本。这件事情对于一个单体软件已经是非常困难的事情,而在我们的企业架构上下文里,面对的是一个成百上千软件组成的系统,这件事情就更是难上加难。在这样的环境中,我们没有办法预测未来的需求,只能通过持续提升团队对于“好修改”的认知,并落实到大家的日常工作实践中来应对。显然,在过去的企业架构方法中,我们鲜有看到对软件这个本质属性的关注。更像是今朝有酒今朝醉,明日问题归别人的视而不见。在总结这套方法的同时,很欣喜地发现在不同企业架构阶段的建模活动设计上,早有全球专家意识到了过去这些静态架构方法的危害。比如已经提出近20年的领域驱动设计(Domain Driven Design,DDD),目前在云原生的微服务时代被很多组织引入,作为系统和平台设计的方法,其精髓就在持续地构建广泛的、跨业务和技术层面的“统一语言”,减少翻译工作,从而能够让系统的架构随着业务的变化快速持续演进。 最近两年行业内从“逆康威定律”出发,转换了在服务组件和技术架构设计上的单一视角,从组织和团队划分出发,明确组件设计目标带来的对应团队特征的不同,并能够从持续发展的视角来设计团队的动态划分和演进。这种团队拓扑(Team Topologies)的思想,实际上已经为我们提供了在技术实现层面上的持续建模活动蓝本。站在这些新思想和方法之上,让我们一起来定义针对数字化企业的建模方法:我们认可业务和应用架构的重要性,但更重要的是持续价值建模,任何业务和应用架构只是实现预期商业价值的一种支撑;我们认可系统和平台架构的重要性,但更重要的是持续领域建模,任何系统和平台架构只是应对复杂问题分治的一种结果;我们认可服务和技术架构的重要性,但更重要的是持续组织建模,任何服务和技术架构只是高效实现组织划分的一种映射(康威定律)。在以上的定义中,业务架构阶段指明确架构所需满足的业务目标的定义过程,由于越来越多的数字原生业务,技术和业务的高度融合造成不少企业直接采用应用的说法。系统架构阶段,或云时代越来越多的平台型架构,明确相关软件程序和数据的各方面设计原则及高阶架构。技术架构阶段,或服务化架构下,主要是明确技术实现框架、组件(服务)划分等落地细则。随着市场和用户需求的持续变化,以上建模方法中的活动也应该持续迭代进行。更由于这些变化不可预期,我们更应该关注建模活动带来的相关人员和团队认知的提升,不同视角的架构视图是阶段性共识的可视化呈现。对于架构视图,我们推荐大家采用类似C4(https://c4model.com/)这样的轻量级可视化工具,重要的是关键人群之间的沟通、论证和确认。一言以蔽之,我们更关注产生企业架构的建模协作活动和实践工艺,而采用轻量级治理流程和过程文档。我们认为这样的建模方法符合于《敏捷宣言》所倡导的工作方式,因为:更强调人通过互动协作的认知提升,而不拘泥于每个活动的专业对口;更强调建模工作的迭代演进,而不拘泥于追求某一个时刻的绝对明确;更强调价值驱动,而不拘泥于现有业务的框架;更强调持续响应变化,而不拘泥于繁琐的流程和文档。任何方法都存在局限性,从数字化企业的视角,这套方法不包含两个重要方面:商业模式和组织文化。前者不能脱离各行业背景,在这个产业互联的时代,行业的重塑、整合、创造不断发生,着实很难抽象出相对能够广泛应用的方法。文化则是一个需要更多阅历的领域,就现在的个人经历来总结组织文化的方法,难免贻笑大方。 下文中我们将整体介绍这个敏捷建模方法框架的含义,三个建模过程和两大运营闭环的细节,将在后续的文章中进一步展开。3.三个建模过程从业务架构设计到最后的技术架构落地,我们抽象了三个高阶建模过程域,分别是:价值建模、领域建模和组织建模。通过这三大过程域帮助企业明确端到端的建模活动,从而能够高效组织不同角色协同完成整个企业架构的设计。建模过程中应该遵循“共识大于正确性”的原则:企业架构每个阶段的产出是相关角色或团队协作过程中形成的共识,而不是某个专业角色或团队的单独交付物。在任何一个时间点,都应该坦诚认知的局限性,通过保持协作的开放性来兼收并蓄。一、价值建模:面向商业成功业务架构一直以来被认为是企业架构的起点,然而面对这个数字化时代,真正的起点应该是我们的客户/用户,这点已经成为了企业管理者们的普遍共识 —— 只有持续创造客户/用户价值,才能够实现企业的持续发展。 由此,我们认为针对客户/用户的价值建模是数字化企业的必然起点。企业需要针对自身的行业及客群定位,确定相关的价值模型,作为不同专业背景角色同事们共识的基础。在很多企业中,我们看到业务和技术的融合都被提升到了组织战略层面,但由于没有从价值建模出发,在实际的执行过程中没有建立起来统一语言,造成客观上难以融合的困局。 招商银行采纳的价值三角模型,让组织能够围绕客户价值来行动。来源于TWLive 2021年分享:https://insights.thoughtworks.cn/cmb-value-driven-lean-transformation/我们也要正视数字化技术带来越来越多元化的价值创造可能性,一家企业可能同时经营非常不同的业务模式,比如不少互联网2C服务起家的企业希望抓住下一波企业2B服务的浪潮,这样的场景下,应该有针对性的不同价值模型。而不应该由于是一家企业,所以就强制性只能有一套价值模型或一套企业架构。驾驭这种多元化是数字化企业未来的核心竞争力。在共识的价值模型下,首先还是需要从产品/服务组合的视角去明确优先级,切忌搞大而全,时刻保持对变化的敬畏心。敏捷宣言签署者之一的Jim Highsmith老先生为此提供了一套比较完整的方法框架EDGE,在《EDGE:价值驱动的数字化转型》一书中有比较完整的介绍。其中的关键实践精益价值树(Lean Value Tree,LVT)在亢江妹老师的《轻量级规划实践方法——精益价值树》也有了具体的介绍。 明确了企业级的价值定位,产出业务架构的方法和实践已经有不少的积累。比如服务设计(Service Design)方法,从关键的用户旅程切入,通过端到端的用户场景来明确用户触点及前后台的支撑系统。服务设计方法下的用户场景化梳理,从用户行为出发,明确能力支撑及前、后台的业务服务设计。具体推荐的方法和实践我们将在后续专门的系列文章中展开。这里值得提醒企业的管理者们:价值建模是业技融合的起点,也是一个组织是否真正践行客户为中心的标志。希望大家时刻不忘“客户价值”这个数字化时代的北极星指标!在一些相对信息化积累比较好的行业,如银行业,也可以采用类似付晓岩老师在《企业级业务架构设计:方法论与实践》一书中介绍的工序比较明确的方法。但仍然需要注意定期审视用户价值随着市场变化而发生的迁移。二、领域建模:面向统一语言软件行业几十年的积淀形成了一个共识原则:关注点分离(Separation of concerns,SOC)—— 在复杂场景中,把不同的关注点分离开来,分别处理,以应对复杂性。这个原则最早由图灵奖获得者,荷兰计算机科学家埃格斯·迪克斯特拉(Edsger W. Dijkstra)在上世纪70年代提出,而后成为了我们在计算机建模领域及系统设计领域的底层范式。时下我们的系统和平台架构某种意义上是其支撑的复杂业务的一种映射,所以我们在这个阶段处理的问题是比产生业务架构更为挑战的。在此基础上,需要再次提醒大家对于变化的预期,即使当下再完美的业务架构也会在未来某个时刻变得不合时宜的,所以系统和平台架构必然需要考虑面向未来持续修改的灵活性。 这是一个很难解决的命题,要求更深层次的业务和技术人员的融合,背后是我们需要在企业里建立一套业务和技术人员都能够理解的“普通话”。2003年提出的领域驱动设计(Domain Driven Design,DDD)无疑给我们提供了统一语言的落地思路。很多人认为2015年开始流行的微服务带火了DDD,但实际上是由于越来越多的企业感受到了在系统架构这个层面日益膨胀的复杂度,同时之前依靠外部购买系统套件搭建起来的信息化系统开始成为新数字化业务发展的障碍。DDD思路下的具体方法,类似事件风暴Event Storming,实质上就是在促进业务和技术人员统一语言的建立。在领域建模阶段,我们仍然还有很长的路要走。在走访不少采用了DDD的企业会发现大多数都是技术人员在关注DDD战术层面的模型应用,讨论最多的是具体的模型如何映射到分层的架构实现。很多企业的研发团队对于和业务建立统一语言这件事情感到失望,甚至于从思想上放弃了这方面的努力。我认为企业架构这个话题在近两年的崛起,是我们解决业务人员加入系统和平台设计阶段的契机。在这个领域建模的过程中,我们需要注意以下两点:1. 建立业务和技术都能够理解的简单语言体系。在这一点上事件风暴Event Storming方法给我们呈现了一个简单有效的实例。当然由于各企业所经营业务的多元化,我们还需要更多的方法和实践。2. 划分领域时综合考虑业务和技术的不同约束条件。争论领域到底是业务的、还是技术的是毫无意义的,我们产出的系统或平台领域划分是综合考虑企业经营情况的结果,这里面既有我们对业务相关性的考虑,也有我们对于底层运算平台特性的利用。基于以上两点,我们认为一个良好的领域建模过程首先要让大家明确使用的语言体系,即不论是业务还是技术,都需要学会普通话。然后是一套行之有效的协作流程和实践,能够保证大家在正向约束的条件下进行领域建模,产出系统和平台架构。最后,在这个阶段不少组织存在对于产出物的纠结。业务侧认为需要看到具体的UI才踏实,技术侧觉得没有代码框架都是虚幻。我们并不否定一些界面视图或技术原型可能在确认共识方面的必要性,但重要的是达成共识的协作过程。即使这些细节的文档材料对于不同的个体来说也是有不同理解的,而过于细节的材料反而容易造成未参与研讨过程的文档读者迷失在不必要的细节关注里。三、组织建模:面向团队演进长久以来,在具体的软件架构上,我们更多还是从技术范式和框架的视角在设计,从简单的MVC架构Web应用,到时下SaaS、PaaS、IaaS的分层模型。被忽略的一个客观事实是:软件开发仍然是强依赖于人的行业,流程、架构和工具某种意义上都必须围绕如何让软件开发个体和团队更高效作为出发点。在软件行业里,我们也逐步形成了对于康威定律的共识 —— 组织形态决定产品形态。Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.- Melvin Conway (1967)简要翻译:组织设计的产品/服务等价于这个组织的沟通结构。这个定律对于持续变化的市场和客户需求来说是非常不利的,即我们目前的组织结构会随着未来的变化而变得不合时宜。这种不合时宜会反映出组织交付的产品和服务不能够满足市场和客户的需求。在这个时代,运营超过三年的研发组织或多或少都经历了这样的痛苦,很多的“遗留系统”实际上就是这样产生的。这背后的核心原因是我们的组织结构并没有随着外界的变化而变化,大家过多地期望仅仅是从技术的角度去调整架构,让各个组件更为灵活,但却忽略了组织结构才是长期的制约因素。每次识别出的技术架构问题,往往在最后落地时没有了组织支撑,成为了空中楼阁。 由此,我们希望直接从组织结构视角去建模,通过组织的划分及交流沟通结构的确立来表达对应的服务和技术架构。从这个视角出发,团队拓扑Team Topologies已经给我们提供了非常好的方法,弥补了过去我们在组织视角的两大盲点:1. 组织内部团队的划分没有明确的目的驱动。针对技术本身的复杂度,组织划分成小团队是一种常态,这不仅仅是开发效率上的考量,也是出于不同目的性的考虑。比如在功能开发团队之上,我们往往会有跨功能的平台团队存在,解决一些共性的能力封装问题;2. 团队和团队之间的沟通互动没有明确的设计。多个团队的协同问题在各个研发组织里十分普遍,经常有不同的角色抱怨“会多”。大家并没有刻意去规划团队和团队之间合理的互动模式,在具体协作过程中自然也无法明确哪些会议是合理的,哪些是由于某个团队工作不到位造成的。通过团队拓扑来完成组织建模对于我们“逆康威定律”的帮助是巨大的,业务和系统架构的变化直接就会映射到团队结构的变化上,而团队的变化自然会驱动技术架构的改变。当一个简单MVC架构的web应用随着市场拓展而越来越复杂的时候,这种变化展现在组织建模上很可能的结果是前、后端团队的分离,这种团队的分离自然而然牵引了架构上的前后端分离。 值得一提的是,在云原生和微服务为主导的技术架构时代,大家更容易忽视组织结构的问题。由于单个微服务对比传统架构的代码量少很多,对应的开发团队自然小很多,无形中给了大家组织已经是灵活小团队的假象。然而,不能忽视的是业务的复杂度依旧,多个微服务的集群才能真正实现业务,小团队组织结构下可能增加我们的沟通互动成本,并且组织结构可能形成“静态小团队膨胀”,即当一个新需求出现时,团队不是去考虑是否应该改变现在的微服务,而是默认增加新服务。长此以往,微服务的个数越来越多,小团队之间的沟通越来越繁琐,开发的效率越来越低。所以考虑团队划分的演进是我们保持高效组织生态的必然。4.两大运营闭环面对持续的变化,我们拥抱敏捷的工作方式,由此也产生了在保证数字化业务持续经营的两大运营闭环,分别是:“顺时针”的市场驱动,和“逆时针”的创新驱动。我们认为在企业架构中明确这样的持续运营闭环是保证大家采用“动态”视角来看待持续建模工作的关键。这正如任何成功的数字化产品和服务,上线面客仅仅是开端,真正的客户价值创造关键是后续的持续运营和迭代演进。这也是为什么我们在企业架构设计过程中,需要从“建模”活动视角来强调这种可持续性。第一环:“顺时针”市场驱动科学应变不论是业务架构还是最后落地的微服务,都是服务于我们在价值建模过程中认定的商业机会。根据企业经营的情况,初始的价值认定会得到验证,而根据验证结果我们就有必要进行业务架构、系统架构的调整,最终驱动技术落地上的迭代。这样的市场驱动也适用于持续的新机会发现,包括一些新技术驱动下的业务可能性的探索。需要强调这并不意味着我们只有一套大而全的业务模型涵盖所有可能业务,相反由于这些新产品和服务的持续探索,一家企业很可能在这些新领域采用独立的、更为轻量级的架构模型,从而能够保持在投资上的灵活性。在落实这样的运营闭环时,我们应该有相关的管理部门或赋能团队来保证闭环的持续运作,特别是在一些拥有上千人研发队伍的大型组织里。EDGE首次提出的“价值实现团队”(Value Realization Team,VRT)就可以作为一个很好的参考,帮助组织推动这个顺时针运营闭环的持续落地。第二环:“逆时针”创新驱动主动求变在这个充满挑战和机遇的市场环境下,创新正成为一家企业的生存必备能力,但大部分组织在如何有效进行创新上却存在很大困惑,更不要说建立支持持续创新的架构。 虽然商业创新很多时候可以从商业模式的打造上切入,很多企业的高管也在强化自身的战略投资能力。但不可否认让企业内部的团队,甚至个体,发挥自身的创新能力,已经成为一家企业是否建立数字化基因的基本衡量之一。由此我们需要在建模活动中支持团队主动发起变化,不少的企业都在利用虚拟团队进行跨产品和服务的整合创新,而过去数年全球在学习型组织方面的研究,也为我们提供了基于实践社区CoP(Community of Practice)持续运营方式。CoP围绕着一群有共同关注或热情的人,定期展开互动学习和创新尝试,比如基于自动化技术RPA的CoP,或者人工智能方面的算法CoP。这种机制的重要性在于保持团队对于市场和技术发展的开放性,通过持续多点尝试来主动发起改变。不少企业在激发自身产品和服务一线创新的组织机制上,采取了成立内部或联合外部的孵化器模式,允许来自于不同团队的员工自由组队,提出基于企业赛道或能力平台的创新想法,并提供必要的落地支撑。这种模式短期可能取得不错的效果,但需要持续推进长效机制的建立,避免成为赶时髦的昙花一现。5.甄别借鉴,与时俱进 开篇对比了TOGAF和Zachman这样的经典企业架构方法,帮助大家明确我们为什么从“建模”的视角来切入现代数字化企业架构。但这些经典方法仍然是值得肯定的,它们的提出也是源自于一些先进企业之前数十年推进信息化工作的提炼和总结。 对于很多企业来说,信息化仍然是数字化的重要支撑,没有良好的信息化系统,数字化业务就无从谈起。从这点出发,我们需要对这些方法的思路和实践进行甄别和借鉴,比如TOGAF针对组织架构能力建立的框架Architecture Capability Framework,就是比较好的帮助组织建立架构治理能力全局视野的可行方法。当然在一些领域,如架构变更管理Architecture Change Management,和我们这里提出的敏捷建模,就是截然不同的思考。很多研发组织在实践敏捷开发方法时经常会陷入一个“非标准化”误区,即认为敏捷开发都是提倡个人匠艺,团队层面则不存在什么约束。事实上敏捷开发方法面向的是规模化的软件工程,对比传统强流程管控的方法(如CMMi),在轻量化流程的基础上,实质是增强了对于个人工艺纪律性方面的要求,比如经典的测试驱动开发TDD,就要求开发者遵循先设计自动化验收测试、再进行功能实现编码的纪律。同样的思路应用到企业架构设计上,我们认可一些主流方法在“流程和工具”方面的积累,我们希望从轻量化的视角去选择性采用。而我们的敏捷建模方法更关注的是协作和工艺上的实践,强调在企业架构设计中“人和互动”带来的组织级认知的持续提升。改变的道路从来都是充满挑战的,在企业架构重要性日益凸显的数字化时代,我们希望通过这个敏捷建模方法DEAM(Digital Enterprise Agile Modelling)的提炼,帮助更多的人意识到软件研发的本质,并能够更多从组织持续成长的动态视角来构建企业架构的能力,从而奠定数字化时代高质量可持续发展的核心组织支撑。原文链接:https://blog.csdn.net/csdnnews/article/details/124161797
  • [行业资讯] 我们正在迈向“精益智造”的时代
    我们看到资本如何在时代浪潮中,获得生命的延续。我们看到不可知的市场需求,从大公司到创业公司,以及中小创业公司所带来的机会。我们看到创新和科技不断推动人类生活向前迈进。但是当下大多数人似乎还没有意识到,我们已经过上一个更好的时代。我们正在以飞一般的速度推动公司和科技生态系统的发展和进步。随着社交媒体用户总量翻番,人们认为我们正在过上一个数字化的时代。但事实并非总是如此,我们正在过一个基于手机和社交媒体的时代,而不是真正数字化的时代。这篇文章将帮你更深入地了解今天科技生态系统的变化,以及它对于下一代生意的意义。我们将从最初的科技生态系统的兴起说起。如今,基于物联网和大数据的新型数字生态系统已经在生产效率、透明度和治理方面取得显著进展。大多数人似乎还不知道的是,我们正在迈向“精益智造”的时代。这一精益智造是围绕如何最小化成本、最大化产出、高品质生产和满足用户需求等主题的实践。这也是我和团队在我们最新专注于的领域。我们正在探索这一变革的潜力,更快、更智能、更便捷,以使我们的生活更便宜、更快速。物联网是第9次工业革命,它正在帮我们构建一个生态系统。首先,我们将研究物联网的前世今生。物联网(iot)最早出现20世纪在20世纪80年代早期,如果人们想要控制汽车,他们需要通过一系列可靠而高效的单品控制器来进入数据中心,使得互联网与其匹配。当iot出现后,所有物理设备都可以联网,其中包含大量传感器,可以对生产设备的每一个位置,以及从何处开始制造物料进行感知,从而进行远程操控。物联网的核心是感知和数据收集。因为感知和收集的需要,这一感知过程被称为物联网(iot)。其次,iot和各种智能设备的发展,包括智能可穿戴设备和各种智能家居设备都将在整个智能产业链中起到关键性作用。智能设备的不断发展,将更快速地对社交媒体、移动互联网和物联网的发展速度造成冲击。它们将成为企业的核心竞争力,并推动整个产业变得更快、更智能和更便捷。最后,通过基础设施和服务进行移动连接,物联网产业使得数百亿甚至数千亿的工业设备联网。为了把物联网这个主题带入主流文化,我们将研究“精益智造”(leaninnovation)。精益智造(leanor)是以产出作为目标,通过产出实现经济成功或企业价值。如果要实现这个目标,关键是提高供应链和生产系统的效率。在供应链方面,制造商应该将产量快速调整到可持续或健康状态,尽可能提高产能,以提升产品的可靠性或精确度。
  • [知识分享] 当心,你搞的Scrum可能是小瀑布
    本文分享自华为云社区《[当心,你搞的Scrum可能是小瀑布](https://bbs.huaweicloud.com/blogs/344133?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)》,作者:敏捷小智。为了更好的拥抱变化,很多团队选择使用敏捷去管理组织或者团队的研发过程,Scrum作为最常用的敏捷框架之一,备受青睐。使用Scrum的团队叫做Scrum Team,Scrum Team(以下简称团队)按迭代进行交付,在一个迭代中,团队要完成需求的规划设计认领、编码、测试以及部署上线工作。有的团队刚接触Scrum,一个问题令他们很困扰:迭代初期开发人员的工作较多,测试人员闲着;迭代末期开发人员闲着,测试人员的工作比较多,怎么解决资源等待的问题呢?# 问题分析造成以上问题的原因大致有以下几种:# 团队搞的Scrum其实是小瀑布团队搞的不是真正的Scrum,而是披着Scrum“皮”的小瀑布——团队有SM、PO,需求使用用户故事记录,迭代中的活动比如每日站会、评审会议等一个不落的开展,但是,团队在迭代中依然按照瀑布模型进行运作——认领完需求进行开发,开发全部完成,交付测试,测试完成,项目上线,整个流程走下来,就造成资源等待。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649384123998350297.png)# 需求拆分不够细需求粒度偏大且没有做进一步拆分,这种情况导致开发人员完成需求的编码工作,就已经到了迭代末期,迭代前期测试人员设计完测试用例,就只能等待了。# 开发和测试之间缺乏沟通开发人员完成了某个新需求编码,没有告诉测试人员;测试人员也没有主动且频繁的向开发人员询问是否有已完成的新需求需要测试,直到迭代末期,开发人员才将所有开发完成的需求一并交给测试人员,造成了资源等待。# 解决方法## 让团队了解真正的Scrum工作方式小瀑布相比于传统瀑布,应对变化的能力可能有所提升,但小瀑布的运作方式和Scrum所倡导的做法还有差距。Scrum使用“Increment”(增量)来表示每一个即将交付的需求,作为Scrum的三大工件之一,Increment有两个重要特性:满足DoD、随时都可以发布,Increment这两大特性为敏捷应对频繁变化提供了保障。反观小瀑布——迭代前期开发、迭代后期测试,如果迭代过程中,突然要发布新需求,那显然是有风险的——因为代码没有经过测试。Scrum中,迭代运作过程更像下图,每个需求完成编码,都直接交给测试人员,测试通过即可准备上线(就绪即可,不是必须上线),在这种情况下,资源等待的问题就会被解决。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649384148431480089.png)究其原因,还是团队对Scrum的理解不够深入,很多团队接到组织安排要进行敏捷转型,就将Scrum角色和流程搬进来,但团队不了解Scrum是什么,为什么,这样转型往往换汤不换药,也许有效果,但一定没有真正的Scrum运作效果好。想改变这种情况,Scrum Master和Product Owner应该对敏捷有深刻的理解,这样才能影响团队甚至向上影响到组织高层,让高层也从根本上了解Scrum过程以及Scrum带来的好处,而不是关注有几个团队用了Scrum。另外,聘请外部教练来帮忙做Scrum导入也是不错的选择,首先外部教练通常具备专业性,更了解Scrum的运作流程,Ta会帮助团队运作Scrum,并对各个角色进行Scrum相关知识的辅导,避免团队因为对Scrum理解不到位,而走弯路。而且,中国有句俗话“外来的和尚好念经”,不管对于团队,还是对于高层,外部教练相比于内部教练可能更容易说上话,提出的建议也更容易被听取。## 对需求进行拆分当需求太大时,团队可以和Product Owner一起,将需求拆分、细化——一方面可以更好的提炼产品价值,另一方面可以更好的划分工作量。需求拆分有很多方法,详情可以参考《[ 【 DevCloud · 敏捷智库】 如何拆分用户故事](https://bbs.huaweicloud.com/forum/thread-50136-1-1.html)》 。加强团队成员之间的沟通团队成员之间缺乏沟通,表面上看可能是由于成员之间业务、分工不同,实际也是由于对敏捷理解的不到位,敏捷宣言提到“个体和互动胜过流程和工具”,团队成员之间应该频繁沟通,就像DevOps打破开发、运维的壁垒一样,在Scrum Team中开发、测试之间也不应该有隔阂。Scrum Master应该积极组织每日站会,通过站会让团队成员了解项目进度——哪些需求正在开发、哪些已经开发完成等待测试。如果站会效果不理想,团队可以尝试使用电子或物理看板来记录需求及需求的价值流动,这样哪些需求待测试一目了然。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649384190107463774.png)# 培养多面手除了以上三种方法,还有一种方法可以解决资源等待问题,那就是培养多面手,比如开发人员既可以做开发,也可以对自己实现的功能进行测试。实际上,Scrum确实提倡这么做,Scrum Guide中提到:“Scrum Team 是跨职能的(cross-functional),这意味着团队成员具有在每个Sprint中创造价值而所需的全部技能”,团队能力允许的情况下,培养多面手不单能够解决资源等待问题,还可以让团队更好的践行Scrum。总结本来想搞Scrum,结果却搞成了小瀑布,而不自知,这是造成资源等待问题的最主要原因,只有加强对敏捷理念的理解,才能让团队真正从Scrum中受益,想知道你的团队到底有多Scrum么?快来[华为云Dev SecOps专家服务——Scrum成熟度评估 ](https://devcloud.huaweicloud.com/expert/enterprise/assessment)测一测吧~
  • [行业资讯] 远程、敏捷的硬件物联网工程——如何成功
    在 Very,我们从一开始就是一个远程优先的组织。随着时间推移,我们已经形成了一种远程文化,使我们能够一起构建软件和硬件,而不会陷入消磨时间的陷阱。通过授权工程师、实施敏捷策略和定义明确的职责,我们为远程物联网工程团队的蓬勃发展扫清了道路。领先于远程工作挑战随着公司希望在竞争激烈的招聘市场中招聘到最优秀的人才,对远程工作的需求继续上升。并且,随着混合工作模式的增加,远程工作已从奢侈品转变为依赖顶尖技术人才的公司的必需品。虽然远程工作人员是一个明显的竞争优势,但也存在一些风险,如失去可见性、责任感和清晰沟通等风险。对于一个软件团队来说,克服这些挑战本来已经足够困难,何况在一个号称“硬件很难”的行业里。那么,如何与构建连网设备的硬件团队合作呢?在 Very,我们创建了一种远程文化来解决围绕分布式工作的主要问题,这使我们在构建分布式硬件团队方面处于领先地位。优化分布式、敏捷物联网硬件工程的 3 个关键流程策略作为咨询公司,时间是我们最宝贵的资源,而且对我们和我们的客户来说,时间就是金钱。如果硬件工程师被耽误,或者软件团队被硬件团队耽误,那么这对我们业务和客户来说都是代价高昂的。这就是为什么我们的流程非常注重节省时间的原因所在。我们对这些流程的思考方式可以分为三类:授权工程师、敏捷流程和明确职责。1、 授权工程师赋予工程师权力使他们能够在没有第三方瓶颈或繁文缛节的情况下自行解决问题。为所有工程师提供一个资源充足的家庭实验室如果工程师不得不从团队成员那里借用工具,其中一些人可能远在 1000 公里之外,那么您将面临不必要的延误。为了避免这种情况出现,我们让工程团队成员从置办一个家庭实验室开始,在其家里配备我们认为能够满足物联网工程开发的工具。不要拖延小额支出该领域另一个节省时间的方法是自动批准购买工具、耗材和运输的小额费用。工程师花在等待一些新的专用硬件或补充常见用品上的时间可能会使团队陷入瘫痪,因此每个硬件和固件工程师都有一张公司信用卡,如果他们需要的话,可以自由购买最高 200 美元的商品,以便为客户进行交付。简化大宗采购除了自动批准小额费用外,硬件团队还具有一份更昂贵设备的活动清单,他们可以根据需要在未经批准的情况下购买这些设备。对于确实需要临时批准的大型订单,我们也有适当的流程,使我们能够以最少的繁文缛节快速审查和批准它们。2、 敏捷流程敏捷开发方法在软件领域已经存在了相当长一段时间,但硬件工程领域并没有很快采用它。尽管缺乏普遍性,但我们发现敏捷方法对于我们的物联网工程团队(包括硬件工程)来说是一个非常有用的开发流程。更有效地利用时间我们在 Very 使用敏捷开发,因为它有效地优先考虑了我们最宝贵的资源——时间。 对于 Very,敏捷开发最重要的原则是:▲不断为最终用户提供价值。▲在迁移到新功能之前,确保功能已准备就绪。▲尽早并经常测试。更快地构建有用的组件敏捷原则在我们硬件团队构建原型的方法中最为明显。如果遵循传统的行业路径,你将从一份完整的详细产品需求清单开始,然后开始一个长期的“数字工程”,在那里,设计是在计算机辅助设计(CAD)工具中创建和完善的。这个阶段可能要持续数月,并且通常会进行多次设计审查,在此期间,整个团队和其他关键利益相关方坐在一个房间里审查设计文件。最后,在项目几乎完成后,构建并测试一个原型。这种方法(也称为瀑布法)会导致较长的设计周期,并且在面对不断变化的需求或原型中发现意外设计问题时很脆弱。相反,我们将设计周期的重点放在构建能够提供用户价值的原型上。这意味着我们不是从详细的需求列表开始,而是从描述我们想要给用户带来的价值的列表开始。我们使用该列表来制定一个原型计划,该原型将开始提供一些价值。我们快速完成周期中的“数字设计”部分,并构建了一个初始原型,通常在项目开始后的一两周内完成。接下来,我们测试原型并开始计划下一个。这种快速、不断的原型开发循环会一直持续下去,直到我们拥有一个能够为用户提供必要价值的设备,并且在现实世界中功能齐全并经过测试。这是最小可行产品(MVP)。通过遵循这种方法,我们可以比传统的瀑布开发更快地获得MVP,并且风险更小。3、 明确职责通过清晰地定义职责,我们确保团队成员知道他们的职责是什么,以及当他们发现不属于他们的工作时该去找谁。对于硬件团队来说,这在集成工程师的角色中体现得最为明显。Very的集成工程师有望跨越电气工程和机械工程之间的界限,他们是将项目结合在一起的粘合剂。职责包括原型设计、提供设计反馈以及帮助指导项目走向生产。这使电气和机械工程师能够专注于设计,并从原型制作过程中获得有关其设计的高效、真实反馈。为了让团队成员以最有效的方式工作,团队在构建测试计划上进行协作,该计划清楚地记录了工程师在设置和测试原型时应采取的步骤。这可以防止不必要地干扰他人的工作,以回答如何设置测试硬件的问题。此外,我们将敏捷计划板上的所有工单分解为小块工作,并将每项任务分配给责任方。明确的职责定义确保时间不会浪费在重复工作上。持续改进即使我们成功地采用了基于经验的方法,我们仍然会发现需要改进的空间,并不断完善我们的流程,为我们的团队消除障碍。通过不断改进远程工作方法,我们远程物联网工程团队提供的速度和价值震惊了客户和同行。(作者:Bill Flaherty;编译:iothome)
总条数:271 到第
上滑加载中