关于30岁以后程序员应该做什么是个讨论度很高的问题，转做研发管理，项目管理，可能是比较高频的选择。实际上任何人都不会随着经验的增长自动的具备某个方面的能力，因为不仅仅是技术在变化，软研领域的协作方式也在悄悄发生变化。
VUCA时代对我们最大的挑战在于，如果我们只关心流程控制，不关注其对目标的影响，那么这种方法可能是无效的。比如迭代是成功的，任务是按期完成的，但业务价值没有彰显。
一直以来我有一个困惑，一方面大规模软研需要协作，则必然需要规范和规则，另一方面，随着组织变大目标感层层损耗，规则使得职务行为流于表面，官僚主义盛行。SCRUM倡导的价值观固然好，但如何落地成为leader的头疼。
敏捷做久了的感觉就是，凡是能做的敏捷动作，大多没什么效果；比如系统-组织的现状造成同一职能团队天然割裂，没办法简单从端到端提速。开发团队加上测试一起开站会该解决不了的还是解决不了。季度末一盘点，每个迭代都是成功的，每个迭代有多少意义？反之，感觉有效果的东西都是来自leader控制不了的事情。比如：关联方慢，需求不断调整造成资源浪费，又或者组织结构上不敏捷，再或应该招募素质高的人才来适宜敏捷。作为leader，一旦问题归为这些难以触碰的东西，就会走上无解的死路，敏捷效果很难体现。
ACT相信领导力小组在组织中的持续效应，而不将敏捷变成某个岗位or角色的职能。在培训过程中很多知识点是围绕人的意识-行为，在对行为的定义上更清晰。比如在常见的SCRUM模式中，SCRUM MASTER到底是谁？是产品经理还是开发负责人或者是项目经理？再或者组织招募或外聘顾问？这个人是敏捷活动的唯一负责人嘛？他离开后组织还能继续保持敏捷方式运作吗？解开这些问题可能并不是SCRUM MASTER的一个人的工作，导入和赋能更重要。
从以下ACT价值观可以看到，这是一个注重实操的工具箱。实际上在ACT方法中主要的结构都是动作和反馈。毕竟，可用的资源是我们自己，最好的方法应该就在我们自己手上，我们应该持续的在建立-打破中寻找平衡。
犀利观点 over 模糊词汇
关注状态 over 遵循过程
实战效果 over 方法导向
挑战自我 over 执行要求
最后。对于我们这些诞生在传统研发过程中的人来说，拥抱VUCA改变自己才是至关重要的，我非常相信未来的软件研发领域会需要大量的具备变革实战能力的技术专家，组织管理者，项目管理者。
最最重要的是永远不要生活在舒适圈。
p.s. 对于该次活动的体验我另外有一篇文章[12月2日深圳ACT课程体验report
]https://www.jianshu.com/p/c9b37fdb39c7
