整体上来说，这次活动的收获还是很大的。有些问题能让我从更高的维度进行思考，虽然暂时可能没有答案，但至少埋下了种子，能够为我日后的工作提供一些参考和思路。当我们低头干活时，也需要时不时地抬头看路，避免走错路，不要用行为的勤奋掩盖思考上的懒惰。今年由于疫情的原因，很多大会都没有去参加。到目前只参加了两个，一个是5月份的GOPS全球大会，作为嘉宾分享了《测试一体化平台助力企业效能提升》。另一个就是12月4日的中国DevOps社区深圳峰会，收获还是非常多的。从个人来说，我还是很喜欢多出去看看，听听别人在做什么，整个测试行业的趋势在哪里，有哪些新的技术。虽然技术比较菜，不可能完全吸收和实践，但还是能得到不少启发，也有助于个人的视野提升及职业发展。
这张图是姚冬老师开展演讲里提到的一张PPT，《内在动机》在很早之前我也看过，当时没什么感受。现在回想自己的职业成长历程，兴趣果然是成长最好的动力。当年连续2年没有周末的学习，是什么让自己坚持下来呢？肯定有金钱的因素，但更多的还是超出团队期望的那份满足感吧。还有一句让我印象比较深的是“自我设限是生活最大的监狱”。自我设限是让自己呆在舒适区最大的借口。我不适合做这个，不适合干那个，最终，只剩下这也不会那也不会。接下来是路宁老师分享的《DevOps度量与改进》。关于度量与效能，今年有太多的大神进行了分享和论证。但更多的是从技术层面来分析和总结。路宁老师先是从不同的视角来看待度量。从下面那张PPT可以看到，从技术层面来改进度量，对产品或者业务的影响并没有我们想象得那么大。软件研本质上还是智力劳动，生产力决定生产关系。好的架构和设计，能从根本上提升研发效能。最近在跟几位敏捷顾问的学习中，也慢慢地体会到了这些信息，当我们从源头（需求）开始治理时，往往会比只在研发阶段去提升和改进技能，效果会来得更明显。“Devops技术能力建设对北极星指标影响不大”。但这并不影响我对技术的追求，毕竟这是我安身立命的资本，是不是有点矛盾？可能是因为格局慢慢打开了？
关于度量本身，路宁老师提到的：动机决定改进的目标和抓手。在所有的度量开展之前，我们需要想好我们为什么会启动度量，领导的动机是什么，我们的改进目标在哪里。如果只是简单的照搬别人的指标，那你度量什么，终将会被反噬。从技术层面来说，我们可以度量的指标可以非常的详细，但是从应用层面来说，哪些指标应该给谁看，就很有意思了，每个团队会有不同的想法。我们是否不应该过分追求统一的指标来评估所有团队呢？毕竟团队间面临的问题和急需改进的痛点并不一样。在后续的度量平台研发过程中，会再继续思考这些内容。上午场的后续分享就没有再听，跑去面基了。见到了伟丹老师，简单地聊了下。然后和福建DevOps社区的负责人较瘦（嗯，没打错，不是教授）聊了一会，很久没见面了。
中场休息
下午基本上就泡在敏捷赋能专场，因为自己后续的工作内容主要也在这方面，所以就想着看看有没新的收获。第一场的分享是美的的老师分享了美的在敏捷转型过程中遇到的问题。这个和我目前的工作契合度较高，整体听下来，总的感觉就是累，需要较长的时间才能有所收获。美的从2016年开始启动敏捷变革，到2020能才完成了推广。在这期间，需要不停的深入团队去做指导，与业务团队朝夕相处。过程虽有经验和技巧，但整体上还是按试点团队验证、经验总结并开展培训、多团队推广，最终完成整体的转型。给我最大的触动有两点：1. 在试点团队的实践过程中，我们不能以顾问的心态去处理问题。我们需要有与团队共存亡的当担，真正去解决团队的痛点和问题。2. 看到了更多的实业集团在往敏捷方向上做转型，看到了更多的成功案例，也让自己对当下的选择更加坚信。第二场是禅道创始人王春生的分享，主题是敏捷与阿米巴。在听到这个话题之前，我还特地去查了个什么是阿米巴，嗯，果然是当下的我考虑不到的事。那是企业一把手需要考虑的事（自我设限了吧）。很好奇这个会和敏捷有什么关系。但是在开场没多久，我就感受到了灵魂拷问。他提了一个问题：我们总是在告诉研发团队应当要实施敏捷，但是从来没告诉他们能收获什么。他举了个例子：公司提供节能，晚上要随手关灯，这事本身肯定是对的，但是节省下来的能源和我有什么关系？我节不节能，好像并没有太多的区别，最多只是道德上的谴责（好像都到不了这个高度）。敏捷、DevOps的实施，能给研发团队成员带来什么？好像除了工作能力的提升，也没什么其他的东西了。我想了很久，以至于后面的分享都没细听了。因为一直没想明白这个问题。
最终，我只能说服自己：需要精进自己的技术能力，用更科学的方式进行工作和生产，提高自己价值和能力，能在未来的危机中，不至于是最快被淘汰的那批人。卷吧！接着是百度的美女讲师武亚雪。她分享的话题是《产品创新思维》。关于创新与敏捷，我之前也写过一篇文章（当测试遇上微创新）。所以这部分的时间基本上就是听美女讲故事，由于没有茶歇，这个就当放松了。老师分享的氛围还是很轻松活泼的。最后听的是云大的《DevOps下的质量内建意识构建》，关于质量内建，也有看过很多相关性的文章，自己也在团队中一直在实践质量内建，更多的聚焦的是技术层面对于业务的支持。这个分享给我印象比较深的有几点：
这张图在学DOM时，经常被反复提起。但是关于质量，我们确实忽略了一些东西，例如JKK，JKK的概念是一种完美状态：在你所处在的工作流程中不要作低质量的工作，不接受流程早期就出现错误的输出，不把糟糕的情形输出到下一个流程。对于研发生产过程中的每个环节，我们是否做到了持续反馈，尽可能地让每个环节都高质量地完成呢？关于持续反馈，在技术层面，我自己画了个图：
关于自动化本身的质量问题，我们如何让别人或者自己相信自动化的执行结果，可以参考 你写的接口脚本合理么 这个文章。第二个点是关于需求实例化的必要性：我们的汉字博大精深，每个人对同一个词的理解会产生各种不一样的解读。如何确保每个人对需求的正确理解，其实是蛮难了（需求：会员充值8折优惠，实现：充100到账80。笑死我了）。所以在前期我们就需要对齐，需求实例化是一个较好的方法。但是对团队的要求较高，个人在实践中一般采用的是编写DOD来对齐需求。当我们能够确认需求的完成标准时，大概率上，我们也就对结果有了较为清晰的认知。第三点是关于去QA的讨论。当只有你失去某个东西时，才有可能有发现它的真实价值。作为测试人，做了半天的质量内建，结果是把自己干没了。也挺幽默的。短时间内，我们还是安全的。至少研发团队对测试的依赖还是蛮强的（方便甩锅？）。我们希望团队减少对职位的依赖，更多的提升对职能的要求，解决质量问题，不能只靠QA，毕竟QA不生产BUG，对吧。后续的分享因为时间的关系，就没有再听了。整体上来说，这次活动的收获还是很大的。有些问题能让我从更高的维护进行思考，虽然暂时可能没有答案，但至少埋下了种子，能够为我日后的工作提供一些参考和思路。当我们低头干活时，也需要时不时地抬头看路，避免走错路，不要用行为的勤奋掩盖思考上的懒惰。
