企业敏捷变革所面临的三个核心问题: Product Owner, 既有思维, 软件架构

企业进行敏捷变革, 走向敏捷开发 “一定” 会提升产品开发的效率与质量。

然而，团队一定要先……

找到有意愿，有能力投入到产品，投入到团队成员的 Product Owner。

有些人的思维、行为是我所一直无法理解的: 总是找尽各种方法，找尽各种说词，誏自己当上 Product Owner。这么爱当 Product Owner, 当真正当上了 Product Owner 时，却一不关心团队成员的现况、问题，二不思考、学习，如何提升团队成员开发产品上的效率与质量。唯一常做的便总是在领导面前, 表现得很忙，表现得很会解决线上问题。更不可思议的是，大家都认为这样的人，才是真正的 Product Owner。

“团队找不到或找错人当 Product Owner, 那即使我们已找到了真正高效的敏捷工程实践，团队即使花上一百年搞敏捷，也绝不可能提升团队在产品开发上的效率与质量的。”

当团队在敏捷开发上，成功的踏出第一步: 找到了有意愿，有能力的 Product Owner 后，团队接着便要克服因 “思维” 所形成的致命伤害……

过往的这么多年，许多人都坚信只要证明自己是 “对” 的，就是在产品开发上唯一要做的事。

所以，即使在产品级敏捷中，我们已找到用视觉化，轻量级的工程实践，而能在第一时间内，便能识别出在架构上、需求上、开发上、测试上的风险与不足。但，遗憾的是，团队成员还是将产品级敏捷上的输出件，当成是 “模板”，当成是 “证明自己是对的” 一项工具。

“产品开发的过程中，团队成员不愿、不能思考问题，还都只是用手，不用脑的在做 copy、paste, 那即使团队采用了迭代，采用了敏捷，等到版本发布的那一天，大家还是会惊吓到不知所措的……”

在有意愿，有能力的 Product Owner 与肯思考问题的团队成员，组成一敏捷团队后，团队便必需诚实的面对产品核心的关键问题……软件架构。

软件架构是个既古老，却一直做不好，搞不定的课题。最大的问题在于: 大家一谈到软件架构，便只知关注: 什么是服务? 什么是微服务? 什么是组件? 服务 （组件）如何管理? 如何实现? 其实，只关注这些面向的问题，至多只能帮助我们搞出 “好的架构”，却往往无法誏我们能构建出 “可自适应变化” 的软件架构。

“在产品级敏捷下，构建一可拉通使用者，BA, SA, 架构师，开发人员与测试人员的统一语言。借由此统一语言，使团队中各个不同的角色，可相互的协作；依照业务场景的不同、业务变化的趋势，制定 “服务”、制定服务间同步或异步整合的机制、 各服务内的业务实体间生成与隔离的方式（机制） 、描述业务实体的方式 （机制）。

唯有有效的结合业务领域专家、 架构师，团队各骨干的成员，才能构建出一 “可自适应变化” 的敏捷服务软件架构； 而不是一个中看不中用的 “好架构”。