2016.9.29, 深圳, Ken Fang
微服务产品级敏捷，设计的初衷, 绝不是肤浅的快速交付。而是要能使团队可持续改善，打造ㄧ永远幸福的团队文化与永远世界第一的产品。
刚结束北京的路由器团队的产品级敏捷的辅导。在从北京飞往深圳的航班上，我不停的在思考着一个问题；持续改善。
微服务产品级敏捷已成功的将敏捷开发与软件工程无缝的结合，使得团队可相当容易的就学会，开发产品所需要的软件工程实践，并可经由协作完成产品版本的交付。
然而，对团队而言，微服务产品级敏捷最大的挑战，仍然是许多人误解了当初设计微服务产品级敏捷的初衷与背后的思维。
我想，全世界没有任何ㄧ个敏捷开发的框架、方法或者是软件工程的实践，其设计的初衷与背后的思维，只是要开发与测试人员快速的交付版本。为何？
因为，任何一个敏捷开发的框架、方法或者是软件工程的实践，都是要团队能不断的持续改善。唯有经由不断的持续改善，才能不断的体现出敏捷或软件工程实践的价值与意义。
但是，假如，我们只是将敏捷、软件工程，当成是驱动开发与测试人员快速交付版本的工具。试问，当开发与测试人员发现自己，只是个被不断要求快速交付版本的机器时，开发与测试人员除了抗拒外，怎么可能还跟着我们做持续改善？
所以，微服务产品级敏捷设计的初衷与背后的思维，绝不是要将开发与测试人员当成是快速交付版本的工具。而是要让开发与测试人员深深的明白：你写的每一行代码、测的每一个用例、产品所交付的日期，将会对客户产生什么样的影响？也就是说，微服务产品级敏捷真正要驱动开发与测试人员的，绝不是交付的速度，而是要驱动开发与测试人员，能懂得客户，能懂得为客户负责，更懂得要能有所追求；只有那追求世界第一的渴望。
唯有我们懂得如何带领着开发与测试人员，能为客户负责、能有追求极致的渴望，开发与测试人员才会有意愿、才会有能力，愿意跟着我们做持续改善；使得产品开发的效率得到永无止尽的提升，产品的质量达到永远世界第一的保证，而最终才能体现出微服务产品级敏捷，真正的价值与意义。
附注: 图中是北京路由器的产品团队, 结合软件工程与敏捷开发, 运用整合领域驱动设计与表格式测试用例的 Story 场景树, 集体协作完成 Story 分析, 设计, Story 测试用例设计, 制定 Story 开发完成的定义。
SaveSaveSaveSaveSaveSaveSaveSave
