• 作者简介:Raja SP,亚马逊云科技(AWS)资深架构师,干过十年传统软件工程,从手敲汇编到敏捷开发再到如今跟AI抢键盘,他亲历了软件开发从“马车时代”到“电动车革命”的全过程。 最近他憋了个大招,不叫“增强版Scrum”,也不叫“智能敏捷2.0
  • 深入探讨“对齐式自主”(Aligned Autonomy)这一现代工程管理哲学:抓权还是放权?——论工程团队如何在‘有方向的自由’中活得更久、更爽、更高效第一章:老板,你到底是想管我,还是想让我管你?——现代工程团队的“精神分裂”日常<
  • 什么是Vibe编程? - 这是一种全新的编程方式,你可以完全沉浸在编程的感觉中(Andrej Karpathy说的) - 让AI帮你写95%以 icon
  • 为什么故事比大道理更洗脑?因为人类从原始人开始就天天八卦,而讲逻辑才是最近几百年才流行的“高科技”! 故事像追剧,让你自动代入角色,边看边学;道理像老妈唠叨,硬塞进你耳朵,左耳进右耳出。(柏拉图早就说过:“强迫学的东西,灵魂根本记不住!”) icon
  • 作者在文章中提出了三个因素,用以解释软件的特性,并对软件开发中遇到的困难进行了深入的思考。 以下是文章的主要内容概述: 三个因素(Triad) icon
  • 敏捷在大型企业中的受欢迎程度正在下降 - 开发人员倦怠是一个关键因素。 一份新报告称,采用敏捷开发实践的公司在开发人员倦怠、人工智能等新世界中“难以适应” 随着科技行业经历一波变革,包括开发人员倦怠、工作 icon
  • 每个敏捷团队都需要知道如何创建、使用和阅读故事地图。故事地图可以帮助团队及其产品所有者发现用户需求、找到实现用户目标的其他方法、帮助整理产品待办事项、沟通功能如何组合在一起、确定开发人员下一步工作的优先级等等。  什么是故事地图? icon
  • 通过反复交谈,比尔·卡普托让我确信了一件非常令人惊讶的事情。这件事改变了我看待世界的方式,也改变了我做事的方式。 根本不存在软件生产力这样的东西。 icon
  • AI编程加速了代码生成,却颠倒了“先思考后编码”的开发本质,导致后期理解与维护成本剧增。唯有将AI视为需引导的“高速初级工程师”,并将其纳入涵盖需求、设计、测试、运维的全周期工程实践,才能避免陷阱,实现真正可持续的效率提升。 你见过一个程序员“写代码”的样 icon
  • 故事要从一个苦逼程序员(就是我)的吐槽开始—— 【第一幕:站着开会开到腿麻】想象一下:14个程序员每天像电线杆似的杵着开晨会,有人打哈欠打到下巴脱臼,有人偷偷掐大腿保持清醒。为啥?因为90%的内容都跟自己无关!(摔)我们甚至发明了"时间到" icon
  • 一次性代码和持久代码 之间存在着重要区别,这对我们如何使用人工智能产生了影响。 一次性代码和持久代码之间的区别并不在于代码是由人工智能生成还是由人类编写,甚至也不在于编写难度有多大。 成本取决于你构建代码 icon
  • 产品团队经常因为早期过度设计造成的混乱而陷入困境。 一旦团队壮大,以前微不足道的事情突然需要很长时间才能完成。最终 icon
  • 仅仅“敏捷”是不够的。公司需要拥有一个敏捷架构,该架构应随业务发展、与目标保持一致并由团队负责。组织需要采用量身定制的方法构建自己的敏捷架构能力,以推动灵活性和稳健性。 1、从一开始就选择合适的团队敏捷架构需要的不 icon
  • 最近,我注意到越来越多的公司正在采用敏捷实践来跟上快速的市场变化。与此同时,这也给架构师带来了挑战:如何在支持灵活性的同时保持结构和长期规划? 我遇到过一些旨在扩展敏捷实践的工具,例如 Leading SAFe Course,但我很好奇——它们在实 icon
  • 故事点是一种非常简单的工具,旨在简化发明者不相信的流程(估算),或者也许更确切地说, 故事点更看重交付而不是预测。 故事点的目的是提供对完成某项工作所需努力的快速(强调是快速)、不紧不慢的衡量标准。 icon
  • 元回顾促进了协作并在团队和利益相关者之间建立了对全局的共同理解。 元回顾是一种很好的练习,可以促进扩展团队内的协作,对大局达成共识,并立即创建有价值的行动项目。它由一个或多个产品团队的团队成员(或其中的代表)和利益相关者组成。利益相关者方面的参与者既包括业 icon
  • 本文作者叫雅各布·克拉克,是英国一家叫“超动科技”(Hyperact)的咨询公司合伙人,这家公司专门帮科技团队和企业解决“明明技术很牛、工具很先进,但项目就是做不好”的老大难问题。 雅各布自己就是从一线工程师干起来的,经历过敏捷开发的黄金年代,也踩 icon
  • 服务水平指标(SLI)与关键绩效指标(KPI)相同吗? 视情况而定! 它们有很多相似之处,但也有一些重要的细微差别,本文将深入探讨。 区分这两者真的很重要吗?嗯 icon