业务解决方案的敏捷性

早在2017年北京敏捷之旅上，我曾经分享了对“规模化敏捷的挑战”的思考，用三驾马车来比喻规模化敏捷的挑战，今天重温这些文字和配图仍然没有过时！我所定义的三驾马车代表了“DevOps”、“架构敏捷”、“业务敏捷”，其中“业务敏捷”是根本也是最大的挑战，为什么最难呢？我翻译了当年发布的《The Business Agility Manifesto》里面的一节“业务解决方案的敏捷性”：

---

---

---

---

---

---

---

---

---

业务解决方案的敏捷性

1. 更快地开发软件本身对于生存和发展来说是不够的，因为一旦投入运行，这种软件很可能会很难在没有意外后果的情况下持续快速地更改。

2. 敏捷的业务解决方案的真正衡量标准是有多少业务知识被配置到其中，以及这些知识被更改或重新配置的容易程度。

3. 将业务知识部署到业务流程和产品中应及时、有效、有选择性、可重复、有普遍性、可跟踪和可伸缩。

英文原文见：https://busagilitymanifesto.org/

---

---

---

---

---

---

---

同时，我也寻找了度量业务敏捷性的平衡计分卡：

三年过去了，直到今天我们并没有度量业务解决方案敏捷性的普遍方法。全球IT工作者主要使用各种DevOps指标度量交付效率和质量。

那么，业务部门关心的指标通常会是什么呢？下面这四项指标是我当前项目的业务干系人提出的业务指标，如何量化度量？如何取到这些度量数据？当前数值是多少？未来的目标数值是多少？新的业务解决方案是否能够满足这些指标？这些正是我当前研究的问题，并正在酝酿实验的方法

我想，当我找到度量业务解决方案敏捷性的方法，并实施有效的量化度量手段时，也是真正实现业务敏捷性的时候！摇滚吧，少年！