检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
织拥有非凡的稳定性和产生惊人的新颖性。 由T型技能的员工组成 T型技能的意思是既要有深度又要有广度。 团队成员拥有适合的技能,覆盖各个专业领域,并且总体上技能有一些重叠,团队有额外的灵活性。有深度的专家型的员工,可以分配到数量合理的产品团队中,但不能让他们成为瓶颈(接力棒掉地)。
CodeArts前端DevOps实践 本文主要以CodeArts产品自身为背景,简要介绍一些在前端性能优化方面的优秀实践方法和常见问题。 在开始本文的内容之前,先简单介绍一下华为云CodeArts。CodeArts是华为云一站式云端DevOps平台。简单来说,就是在云端提供了从需
DevOps的3大核心基础架构 由于近年DevOps概念的火热,加之DevOps的涵盖面非常广,因此有很多文章和技术都在和DevOps强行关联,使很多想要了解学习DevOps的开发者迷惑不解。 其实,DevOps的知识体系如果从顶层上来分解,可大分为2部分:方法论和工具链。 方法论这部分,因为Dev
敏捷项目管理 组建Scrum团队 本文将以一个示例项目为对象,介绍如何进行敏捷项目管理,示例项目背景如下: 凤凰商城示例项目介绍 【凤凰商城】示例项目是耗时数月所开发的汽车零部件配件电子商城。项目采用 Scrum模式 进行迭代开发,每个迭代周期为“两周”,前3个迭代已经完成“凤凰商城1
Online快速开发、发布WeLink应用 基于CodeArts IDE Online、TensorFlow和Jupyter Notebook开发深度学习模型 CodeArts IDE 使用 CodeArts IDE for C/C++ 开发OpenGl示例工程 使用 CodeArts IDE
实验项目推进、综合实训缺少统一规范化的流程与平台。 推荐搭配 需求管理、代码托管、代码检查、编译构建、测试计划、部署。 实现结果 在实践中学习软件开发,用实践项目培养人才。
方案概述 背景信息 CodeArts结合多年研发经验与业界先进的实践提出了一套可操作可落地的敏捷开发方法论:HE2E DevOps实施框架。 图1 HE2E DevOps实施框架 规划和设计 步骤①和②是业务(或者是客户)与技术之间进行产品规划,梳理产品整体脉络,以及进行产品规划实施设计,并控制需求粒度与拆分的过程。
P极限编程的很多实践,半数以上在DevOps里都能找到。 能力成长模型,除了持续交付,还包括精益领导力、精益产品开发、精益管理、组织文化与学习氛围。DevOps已远远不是CI/CD那么简单,CALMS原则也横跨了文化、管理、精益与技术。 敏捷宣言的十二条原则、SAFe的九大原则、
捷是向整体团队运作的方向努力,但是不可避免的是每个成员都有出于他自己的背景,尤其是团队组建初期。不同背景的成员给团队带来的既有不好的地方也有好处,例如对自身角色的定位不清楚、成员之间沟通不顺畅。好处是不同背景的成员往往有着互补的思维,尤其对于测试人员来说,在敏捷团队的测试人员会感
整体性:连接目标和具体交付物之间的树状逻辑图谱。 协作性:利益相关人一起沟通讨论协作,把隐藏在个人头脑中的默认的思维逻辑挖掘共享出来。 动态性:动态调整、迭代演进、经验证的学习。 可视化:统一共享的视图,结构清晰易读。 影响地图将各个部门/角色不同的视角、不同的思维逻辑、不同的前提假设,通过可视化和协作的方式进行
华为基于CodeArts的研发体系,包含从软件的需求到代码托管编译构建到发布的全过程,十年前这些所有的过程都分散在不同的团队、不同的个体人去完成的,十年后,如果你是一个深度DevOps的践行者,一个人就可以完成,就是新的工具、新的IT系统给大家提供这样的变化。云的最大特点就是自服务,可以通过自服务提供方方面面
必须通过量化方式指导产品决策,在产品规模化推广之前搭建数据分析系统,如果在之后做会非常痛苦。 DevOps实施的第三步:建立高度信任的持续学习和实验的文化。文化看似虚无缥缈,实则非常重要。实际上文化并不是做DevOps转型就能建立的,文化是这个企业自带的基因,文化是企业创始人个人
来容易,做起来很难。 用户故事编写工作坊是捕获需求最有效的方式,原则是:数量优先而不是质量优先,鼓励大家输出,而不要去评判某个故事的好坏;深度优先而不是广度优先,先把一条路走通,而不要中途跳到岔路上。用户最可能做什么?可能会犯什么错误?会有什么困惑?会需要什么信息?在工作坊里最好
让听得到炮声的人做出决策,而不是远离一线的管理者。 Build Quality In,所有人都有责。 测试与架构相关,包括技术架构,以及组织架构。 测试的过程,是从失败中学习的过程。 自动化,自动化,自动化,尽可能的自动化一切该自动化的,但又不要过度的依赖于自动化,不要过度追求自动化。 下图是测试金字塔,核心是
除基础语言外,支持多种常用开发语言,如C#、CSS、Go、HTML、PHP等。 × √ √ √ 叠加代码安全检查增强包 允许叠加购买代码安全检查增强包,增加用户深度检查代码安全类隐患的能力(例如跨文件跨函数、污点分析、语义分析能力)。 × × √ √ 缺陷扫描 及时发现代码中潜藏的质量类(包括风格类)、安全类的代码缺陷。
在什么情况下Scrum并不适用? Scrum模式并不适用于所有的团队,特别当团队规模很大(几十上百上千)的时候,我们无法在整个团队范围内实施Scrum,而必须将团队分割成5-10人的小团队,并在团队间进行Scrum of Scrum 的实施。 Scrum也不适合跨部门、跨职能的协作,如果团队成员分散于不同
通过项目经理驾驶舱查看项目状况及项目工作负荷 背景说明 作为项目经理,需要及时掌握项目的整体运作情况,能够及时跟踪项目在所选时间段内需求交付和缺陷修复的进度、资源分配和风险。 而且项目经理经常遇到的问题是项目成员的工作饱和度不能直观的展现,特别是当成员跨项目时,做两个以上项目的任务,更增加了识别难度。
Principle matters...Method doesn't. 敏捷的方法有很多,讲了很多年也还任重道远。 丰田TPS被各大车企学习了30年,没有哪家能学到真经的。有人说,丰田生产模式,最重要的是背后的KATA,即丰田套路,如何使得改善和提高适应性成为组织日常工作的一部
验证问题,DevOps并不能解决问题,它只是让你快速失败,If you fail,fail fast。(所以在DevOps里,失败原本就是学习的一种方式) 通过频繁、快速的生产环境部署,保证稳定可重复的自动化部署。 通过Feature Toggle(功能开关/特性开关)、Dark
的拆分,即由大到小的细节展现。其中最关键的部分是产品的构思框架,贯穿整个产品的发布地图,可以帮助团队以可视化方式展示依赖关系。此外,更多的背景信息可以摆放在地图的周边,例如产品目标、客户信息等,这几乎就是用户故事的全部了。这也恰好是用户故事地图的魅力所在,好的东西通常都很简单而有效。