在之前的文章我首先讲了1)敏捷的第一步-每日站立会，然后讲了如何2)用看板管理项目或者管理自己的工作待办，今天是第三个主题，讲如何3)在实际项目中做任务拆解、估时和工作指派。

上篇文章中，我讲了敏捷第一步-每日站立会，讲了我们平时是怎么开站立会的，其实15-30分钟就够了，绝对不是时间长得让你想拄拐那种。本文我们开始讲敏捷开发中的看板。没有看板之前，我们真的是在白板上画泳道，写卡片，挪动卡片，在白板前开站立会。现在支持任务看板的产品也越来越多了，大家开站立会也方便了，没必要...

对于研发效能团队建设和组织，本文不再赘述，可以参考之前的文章，已经讲得很透彻了。本文重点讲我们日常是怎么开站立会，怎么让团队跑起来，高效能产出的。每日站立会，15分钟到30分钟，看似非常短的一个会，但是对团队成功、业务发展有着非常重要的作用。

2023年11月12日，阿里云产品因为某些故障，全线都受到影响。是的，双十一的第二天，我的购物车还没清空，阿里云就不让我买了。云产品全面故障，影响之大一个大铁锅都装不下。之所以阿里云故障受到大家这么关注，一方面是阿里云投入多年技术领先，国内 IaaS 领导者，另外一方面是阿里云用户量大影响也大。

源码依赖是指一个软件项目依赖于其他软件项目的源代码。这通常发生在开源软件开发中，一个项目使用了另一个项目的源代码来构建自己的功能。依赖的是另外一个项目的源代码，所以关系更加紧密，代码交织在一起。通常用于较小的依赖或者有需要自定义修改的情况。

学习完了 Scrum，实际使用中，是否遇到/思考过下面的问题？Product Owner的老板是谁、谁来给 Product Owner打绩效、考核的标准是啥？Scrum Master 的老板是谁、谁来给Scrum Master打绩效、考核的标准是啥？Scrum Master 是教练，团队成员表现不好，Scrum Master 是否有权让其下场休息？Scrum Master 是服务型领导，除了...

它不是利润中心，不能给你带来直接收入(研发效能相关工具厂商做咨询、出方案、卖工具除外）。想要解决企业效益问题，依赖于企业战略、业务/产品、组织、运营、创新等其他方面。

找到一个「吃过猪肉，见过猪跑的」，你问他什么是猪，他自然比「没吃过猪肉，没见过猪跑的人」更了解猪。海豚海豚，你知道猪是什么样么？它都没上过陆地，这辈子都没见过猪，它哪知道猪是什么样.

上篇文章《研发效能组织架构：职能独立vs业务闭环》介绍了职能独立型组织架构和业务闭环型组织架构的特点，优劣势。也许有的小伙伴可能对这两种组织架构没有深刻的体会，而本文就是想通过数据说话，想仅仅通过计算这两种组织架构下开会时间这一项，让大家知晓职能型组织架构带来的巨大沟通成本，也让大家清晰看到两个组...

研发效能团队相对于各个公司主营业务规模来说并不是很大，但是在经历的几家公司里主要是有两种组织架构，职能独立型组织架构和业务闭环型组织架构。本文主要讲解这两种组织架构的特点、优劣、劣势。

通常 DevOps 团队是负责开发产研基础设施的团队，反而里面很少有 Ops 工程师，基本上都是产品、开发和运营人员，我们都是当作一个业务团队来运转。

每当研发效能/DevOps业务做规划的时候，有的人就会毫无头绪，不知道如何下手，不知道方向在哪里，价值怎么衡量。本文将介绍如何借助北极星指标这个工具来帮我们完成这项工作，并以此指引团队工作方向，梳理业务重点，聚焦核心指标。这也是我常用的方法，希望对你有用。

​几天前和一个朋友聊到环境、程序的配置变更，SQL变更和整个上线流程。之前我们在这块也做了很多，有做的好的也有做的一般的，借机都总结下来，希望对你有用。

现在国内职业的质量管理都是从 CMMI 和 ISO 质量体系演化过来的，但是能做真正的质量管理的公司很少。质量管理的 QC 偏测试，对最终的产品负责；QA 偏过程，从过程把控质量；QM 偏体系，类似于全面质量管理，建立质量文化。

上面一篇文章《质效提升 ｜ QA不做业务需求测试，你怎么看》主要讨论的是QA 和业务需求测试相关的问题，文章发出后收到了很多小伙伴的反馈，这里把很多有意义的反馈放在下面，希望对你有用。

因为有的小伙伴看到公司的QA不测试业务需求，只搞流程、卡点、规范、技术创新、QA平台，行业洞察，让研发自测、研发担责上线bug和风险，所以问我，你怎么看QA不做业务需求测试这件事。其实我怎么看不重要，这事还是要看公司管理层和QA负责人，我个人倒是可以作为一个业务方来聊一下这件事。

研发过程中有各种需求的评审、审批流和质量卡点，有的是为了质量把关，有的是为了彰显权力，还有一些是为了信息告知。本文主要讨论在软件开发过程中涉及的评审、审批和质量卡点三种情况，同时探讨对研发流程的影响，在这过程中如何去提效。

近日一则腾讯TEG CDC整个部门解散的消息在很多群里炸了锅，有的唱衰互联网行业，有的唉声叹气，还有的甩锅到 AGI 的发展。总体上来说，这个事情的确已经发生了，我想从组织架构和整体效能这两方面来分析下这次组织变化。

昨天一个小伙伴和我讨论了一下OKR和绩效管理，所以这次想简单明了地说下在中国怎么做比较合适，很多高大上的理论无法落地也是空中楼阁。首先说一些，我个人的理解道德品质和能力素质决定了一个人的职位行为职位行为决定了业务结果不同级别/工作性质的人员，绩效考核应该有不同权重组合团队管理者的绩效不得高于团队的绩...

项目经理(PMO)对于大组织、跨团队高效协同有着不可替代的作用。跳出组织架构的束缚，横向推动公司级别的大项目向前推进，跟进进展和拿到结果，PMO的小伙伴有着独特的优势。

之前人工智能发展多年，报道最多的也许就是曾经的李世石大战AlphaGo，现实中的特斯拉自动驾驶，还有波士顿动能放出的机器狗。对于圈外人士来说一般也接触不到这些，仅仅看看而已。但是 ChatGPT 不一样，一声巨响，石头中蹦出一个 ChatGPT，天生具有人类智慧，可以应答人类各种刁钻问题，甚至还可以给他一些资料，让他「...

AGI 的出现，给了我们一个新视角去审视我们做过的系统，尤其是研发效能平台。研发效能平台作为一个工具平台，本质就是提高公司整体产研的效率。AGI 的快速进步大家已经有目共睹，本文就是在项目协同，代码管理、测试、AIOps等方面来探讨 AGI 可以给研发效能平台带来的巨大变化效率提升。拥抱 AGI，吸纳 AGI 来改善和升级...

之前写过一篇文章《devops｜中小公司不要做研发效能度量》，主要是从基础设施方向考虑，因为很多条件都不具备，贸然高投入去做研发效能度量可能达不到我们的预期效果，给出的建议是先做好当下打好基础。今天想到一个好例子，可以类比下。

没几个人的小公司上来就做研发效能度量，就如同普通人一上来直接问媒婆怎么能娶到迪丽热巴。解决办法无非把大象装冰箱里的那三步。套用一下，公司想要做好研发效能度量也有标准的三步：长时间对研发效能业务投入，建设好研发效能工具链，做好效能度量。现实是我们很多公司卡在了第一步上。我们可以边做研发效能平台边做...

1)工具链完整性：该有的工具是否都有了2)功能完备性和易用性：工具该具备的功能是否都有了，是否容易使用3)支持和服务：是否有人持续地维护、支持和服务4)员工满意度：员工是否满意

国内公司普遍不注重基础设施建设，这也是可以理解的。吃饭都吃不饱，就别提什么荤素搭配，两菜一汤了。但也不能全说是这样，还是有很多公司投入大量的人力物力去做好公司的基建，比如很多阿里和美团的小伙伴对公司的基建还是很认可的。

现在很多公司都在做或者计划做研发效能，也知道研发效能工作很重要，能提高产研运同学的协同效率，提高员工的工作效率和质量，提高业务交付效率和交付质量，但是价值有多大？效率又有多高呢？因为不容易说清楚，所以经常碰到一些质疑和灵魂拷问。

有人说研发效能是老板工程。不是的，研发效能不是老板工程，它不直接服务于老板(虽然老板可能看一些报表)，反而是服务于广大产研运（产品+研发+质量+运维）的同学，所以有的公司也把研发效能叫做基础中台，平台工程，开发者服务团队，或者叫开发者服务平台。做好研发效能，做好开发者中台，就容易把公司的各种中后台能力...

想要做好业务，老板们除了要梳理好公司级别的业务目标，公司的组织架构，还要搭个有产出的班子，也就是找负责人、建团队，让组织架构充实起来。搭班子最重要的就是把负责人找到，就是团队1号位的人。本文主要讲团队负责人的主要作用，怎么才能找到，不同背景的优劣势，以及各方面的要求。

找方向、建团队、不用告诉他要做什么，他自己来告诉你该干啥。制定目标、寻找解决路径、评估优先级、带人就能干，干完了干好了还能及时同步。团队在他的启发下螺旋式上升。定战略、重执行、拿结果这才是一个好的 FTO。