我们真正该关注的应该是产品开发的效率与质量, 而不是工程实践或敏捷的价值

2017.5.12, 深圳, Ken Fang

2014 年, 我设计了产品级敏捷。
2015 年, 我设计了微服务产品级敏捷。

有人问我: 产品级敏捷、微服务产品级敏捷的价值如何的被度量?

我想, 全世界没有在度量工程实践价值的这件事, 而都是在度量产品开发的效率与质量。

当然，提升产品开发效率与质量的方法或工程实践有无限多个。

所以，我所要做的事是：
1. 能为团队 “设计” 出团队所需要的工程实践；而不是要求团队去执行，去照单全收，某一个或某一些的工程实践。
2. 从所设计的工程实践背后的思维、产品架构、产品测试、程序语言、IT 技术，使团队能理解我所设计的工程实践。
3. 实际带着团队做，与团队面对面的讨论，就会充分且实际的证明所设计的工程实践对团队的影响为何？我这再强调ㄧ下：我不是要去证明所设计的工程实践对团队有没有价值？而是要能掌握所设计的工程实践，对团队的影响，而要能持续的去改善。

我所辅导的团队, 用了产品级敏捷中的可视化的架构上下文地图板、集成测试用例板后，一直再持续的改善, 产品集成测试用例的广度、深度, 与持续的在思考如何能持续的改善, 产品架构上的弱点与风险; 这就是在做产品的本质。

我真正要思考的是：如何能持续改善？如何能设计出更多的工程实践，去服务团队。

当然，团队会不会持续的使用, 对团队真正有帮助的工程实践，那就涉及到企业、团队的文化、人员对产品的责任感⋯等等。而与工程实践的本身是无关的；

也就是说，耗费宝贵的时间与精力，去度量工程实践的价值，而期望能借由所谓工程实践的价值，使团队能持续的使用工程实践，是一点意义都没有的。

我们为何一定要要求团队ㄧ定要如何？产品会变、技术会变、人心会变⋯为何团队所使用的工程实践不能变？

我期望团队能从我所设计的工程实践中受益。但，我更期望的是，日后团队能在不用我所设计的工程实践，却也能持续的提升产品开发的效率与质量；这样我就可以向团队去学习，我自己也就能持续的成长。

我很感谢某些团队能将产品级敏捷, 微服务产品级敏捷做到如此的到位。而我更感谢某些的团队，提供了一个极度混乱、脱序的场景，使我能从中的去深思、去学习。

所以，任何的一个团队，都是我的老师；都在教导着我所不会的、我所恐惧的，却又是我所必需去面对的事。我所设计出的每一个工程实践，都是这么来的。

团队只要能不停的为产品思考，产品的质量就ㄧ定能不断的持续改善，团队开发的效率也一样的能持续的提升；即使过程中会出现些偏差，但，团队只要能不停的去思考，就一定能很快的就走回到正确的轨道上。

所以，产品级敏捷、微服务产品级敏捷最主要的目的是期望: 团队能不断的去思考；而不是制式化的去做某个或某些的工程实践。