介绍 Sonar是一个代码质量管理的开源平台，基于Java开发的,用于管理源代码的质量，通过插件形式，可以支持包括java、C#、JavaScript等二十余种编程语言的代码质量管理与检测。 它具有免费的社区版本和其他付费版本。 SonarQube之采购选型参考 利用SonarQube的主要好处是：
最近在经历的一些事情，让我突发灵感，觉得要写点关于DevOps体系建设过程中的“流程规范”，记录下来。 如何解读"流程规范" 谈到DevOps落地，无一例外都会提“流程规范“，我想没有人会反对，甚至会”不放在眼里“，因为概念本身没有什么晦涩难懂。可是一到落地，好像就是另外一番场景，“一地鸡毛”，“形
1024，祝每个程序员小哥哥小姐姐节日快乐。 因为在研发效能部门，我支持过几次 1024 程序员节的活动，所以经常有朋友问我1024 程序员节怎么做，本篇就是简单介绍下我的思路，希望对你有用。 1024程序员节的由来 俄罗斯把每年第256(=2^8）天，即平年9月13日或闰年9月12日定为国际程序员
今天一个小伙伴问我，如何「快速提升」一个团队的软件开发成熟度？我犯难了。我个人理解一个团队的软件开发成熟度涉及的东西很多，但最简单最直接的方法就是发钱涨工资，可是估计很多公司不愿意，那就只有扣了。 快速提升的目标 短期制度解决 如果想短期快速提升，那就直接梳理好最关键点，制定规章制度，然后通过奖惩制
之前的一篇文章《从特拉斯辞职风波到研发效能中的荒唐事》中关于企业内源的内容在研发效能群内引起了大家的热烈讨论。有的小伙伴不同意，有的小伙伴非常不同意，我觉得这都是非常正常的反馈，话不说不透，理不辩不明，我还是特别希望能和大家一起把这个问题弄明白。这篇文章就是那篇文章的后续，本文主要讨论开源社区、开源
框架类是否适合企业内源？ 框架类都由公司早期来的一些大佬们负责（相当于技术委员会），更新频率非常低。给框架类提MR的人，多数本身就在技术委员会。 如果公司的人员众多，类似BAT级别，几万人使用的框架，大家一起添砖加瓦也许是合适的，尤其适合那些公司本来已经开源到开源社区的框架。但做之前肯定有大量的学习
有人说研发效能是老板工程。不是的，研发效能不是老板工程，它不直接服务于老板(虽然老板可能看一些报表)，反而是服务于广大产研运（产品+研发+质量+运维）的同学，所以有的公司也把研发效能叫做基础中台，平台工程，开发者服务团队，或者叫开发者服务平台。做好研发效能，做好开发者中台，就容易把公司的各种中后台能
现在很多公司都在做或者计划做研发效能，也知道研发效能工作很重要，能提高产研运同学的协同效率，提高员工的工作效率和质量，提高业务交付效率和交付质量，但是价值有多大？效率又有多高呢？因为不容易说清楚，所以经常碰到一些质疑和灵魂拷问。 如何衡量研发效能的效果？ 如何衡量研发效能的作用？ 如何说清楚研发效能
国内公司普遍不注重基础设施建设，这也是可以理解的。吃饭都吃不饱，就别提什么荤素搭配，两菜一汤了。但也不能全说是这样，还是有很多公司投入大量的人力物力去做好公司的基建，比如很多阿里和美团的小伙伴对公司的基建还是很认可的。 为什么工程师都很在意公司的基建 有人说再好的磨盘也只是提升了驴拉磨的效率，便宜了
之所以写这篇是因为有朋友私下让我完善下基建建设的标准和四个阶梯划分，然后让我一定要把腾讯和百度加到基建建设的排名中(看热闹不嫌事大）。 基建infra建设四个考察维度 1)工具链完整性：该有的工具是否都有了 2)功能完备性和易用性：工具该具备的功能是否都有了，是否容易使用 3)支持和服务：是否有人持
我特别反感那些不顾公司现状一上来就想要做研发效能度量的人，尤其是想把研发效能度量当成锤子四处去敲打螺丝钉的人。 没几个人的小公司上来就做研发效能度量，就如同普通人一上来直接问媒婆怎么能娶到迪丽热巴。解决办法无非把大象装冰箱里的那三步。套用一下，公司想要做好研发效能度量也有标准的三步：长时间对研发效能
之前写过一篇文章《devops｜中小公司不要做研发效能度量》，主要是从基础设施方向考虑，因为很多条件都不具备，贸然高投入去做研发效能度量可能达不到我们的预期效果，给出的建议是先做好当下打好基础。今天想到一个好例子，可以类比下。 两个人小家庭 1）人少 2）收入清晰 3）支出清晰，买了什么东西，花了多
AGI 的出现，给了我们一个新视角去审视我们做过的系统，尤其是研发效能平台。研发效能平台作为一个工具平台，本质就是提高公司整体产研的效率。AGI 的快速进步大家已经有目共睹，本文就是在项目协同，代码管理、测试、AIOps等方面来探讨 AGI 可以给研发效能平台带来的巨大变化效率提升。拥抱 AGI，吸
项目经理(PMO)对于大组织、跨团队高效协同有着不可替代的作用。跳出组织架构的束缚，横向推动公司级别的大项目向前推进，跟进进展和拿到结果，PMO的小伙伴有着独特的优势。 我之前写过小团队如何高效协作的一篇文章《 高效能敏捷交付团队反思：特性团队(FeatureTeam)+Scrum》，还写过一篇关于
昨天一个小伙伴和我讨论了一下OKR和绩效管理，所以这次想简单明了地说下在中国怎么做比较合适，很多高大上的理论无法落地也是空中楼阁。 首先说一些，我个人的理解 道德品质和能力素质决定了一个人的职位行为 职位行为决定了业务结果 不同级别/工作性质的人员，绩效考核应该有不同权重组合 团队管理者的绩效不得高
近日一则腾讯TEG CDC整个部门解散的消息在很多群里炸了锅，有的唱衰互联网行业，有的唉声叹气，还有的甩锅到 AGI 的发展。总体上来说，这个事情的确已经发生了，我想从组织架构和整体效能这两方面来分析下这次组织变化。 腾讯TEG CDC解散 6月28日，网传腾讯TEG CDC整体解散，人员涉及设计师
研发过程中有各种需求的评审、审批流和质量卡点，有的是为了质量把关，有的是为了彰显权力，还有一些是为了信息告知。本文主要讨论在软件开发过程中涉及的评审、审批和质量卡点三种情况，同时探讨对研发流程的影响，在这过程中如何去提效。 同团队内部评审 同团队之间的评审包括产品团队内部的PRD评审，RD团队内部的
欢迎加入我们的「研发效能DevOps」微信群。 - 我的文章主要首发在微信公众号 scmroad - 主要关注领域 {研发效能、研发工具链、持续集成、交付、DevOps、效能度量、微服务治理、容器、云原生} - 欢迎添加我的微信( xueliuan)入群，添加微信请备注公司、职位
麻广广@码猿外 研发效能这个词近几年火遍全网，各大企业都加入了研发效能治理的行列，开始梳理企业内部各个团队的研发流程，以期望找到企业降本增效的方向。 抛开政治因素，研发效能治理我们到底是在谈什么呢？从企业高管的视角出发，一定是看到了一些问题，才会有研发效能治理这个话题。从实施者的视角出发，研发效能治
朱晋君@君哥聊技术 我自己为了消化里边的内容，整理了一个脑图，希望对你有帮助。 凌晨四点被公司的监控告警叫醒了，告警的原因是生产环境跑批任务发生故障。即刻起床处理故障，但还是花了不少时间才解决。 这次故障是一次数据校验的跑批任务，校验前面跑批任务的数据是否正确。幸运的是，之前的核心任务已经完成，并没
