写点什么
创作场景
- 记录自己日常工作的实践、心得
- 发表对生活和职场的感悟
- 针对感兴趣的事件发表随笔或者杂谈
- 从 0 到 1 详细介绍你掌握的一门语言、一个技术,或者一个兴趣、爱好
- 或者,就直接把你的个人博客、公众号直接搬到这里
登录/注册
收录了 价值交付 频道下的 50 篇内容
敏捷宣言的第一条原则就是关于向客户交付有价值的软件,因此,许多敏捷从业者都在软件开发周期的每个阶段不断地思考价值。但计算产品特性的业务价值并并是简单地得出一串数字。
敏捷被赋予了太多的含义,甚至承载了利益,有时还让人迷惑。本文并不试图去定义敏捷。但,我们会分别从外部(业务视角)和内部(开发模式及组织视角)观察正在发生的敏捷,并提交观察报告。

如何解决企业数字化转型面对的难题?
上一篇文章《深入思考软件工程,开启 DevOps 之旅》,详细阐述了我们对软件工程和 DevOps 的理解,并且明确 DevOps 已是软件工程领域集大成者的结论。

软件交付是一个非常复杂的过程和体系,需要保障好每个阶段的质量和效率才能保障最终的质量和效率。本文将尝试从需求交付的前、中、后三个环节来阐述一下如何做高效高质量的价值交付。


随着软件行业的快速发展,高效的研发效能已成为企业竞争力的关键因素。尤其对于具有一定人数规模的敏捷研发团队,如何在复杂的项目环境中客观衡量研发效能,更是团队和管理者面临的重要课题。这不仅关系到项目的质量、交付速度,更直接影响到企业的市场地位和

11月中旬,作者在 TOP 100 案例和人人都是产品经理的两次大会上分别进行了两场关于价值交付的分享
用“价值点(Value Points)”技术来确定任意软件项目的交付价值。
如何让中间层转型成为带动整个企业业务敏捷的中坚力量?从项目管理办公室(PMO)转型到价值管理办公室(VMO)。
企业敏捷转型的策略,面临一个关键的问题:如何具体应对组织中间层级的人群,包括HR, PMO, 中层管理者等。如果处理不好,会成为我们转型的障碍和阻力。

企业敏捷转型的策略,面临一个关键的问题:如何具体应对组织中间层级的人群,包括HR, PMO, 中层管理者等。如果处理不好,会成为我们转型的障碍和阻力。没有中间层的参与和支持,高管和领导者设计的企业转型愿景和预期,成为空中楼阁......

在产品开发中,很多管理者往往关注的是各环节的产出以及工程师的忙碌程度,阿里资深技术专家何勉认为,这些局部的优化往往是研发效能改进过程中最大的坑。产品开发的核心问题从来不是停滞的资源(工程师),而是停滞的价值项(用户需求)。如果仅仅关注“停滞的工程师”,我们总有办法让各个资源环节忙起来,至少看上去忙起来,但它往往只是掩盖了问题。停滞的需求才是影响研发效能的关键所在。

我至今记得几年前参与的一个园区数字孪生项目验收会。甲方领导站在那块数十平米的巨幅屏幕前,看着流光溢彩的三维城市模型、实时跳动的数据洪流,以及精准到每棵树的昼夜光影变化,当场说了句“赏心悦目”。然而话音未落,负责运维的工程师就凑过来私下抱怨:
在本次采访中,Ralph Jocham讨论了如何与敏捷团队一起交付价值,Scrum master和产品负责人应该具备的最重要的技能,如何知道你交付的软件质量是正确的,以及如果团队希望交付更多的价值,团队可以点什么。

用“通用型”架构设计方法做个人规划。

务必将软件平台看成是产品,而不仅仅是代码。 在哥本哈根 GOTO 大会上,Abby Bangser 在题为“平台即产品”的演讲中指出,要想取得成功,必须在工程、设计、易用性、安全性以及为内部客户和组织创造价值之间取得平衡。


8月6日~8日,由用友主办的 2026 全球商业创新大会(GBIC·2026)在南京隆重召开。

AI 时代创造者的全新生存法则。