之前在 GitChat 上了解过吴博士的分享，也早就听说吴博是个喜欢在微信群里发红包的土豪。感谢部门给了这个机会，参加了吴博的培训，收货满满。写下这篇课后总结，是为给自己做个备忘，给朋友们做个分享。
>>金句分享
“以创业者的心态参与工作才能体现人生的价值。”
- 目前科技的转型更需要创业心态，快速试错。跟随业务的发展去学习。如果解决问题需要的技能点是100，那么就按照1000去努力。
“在XX环境下，很多新系统生出来就是一个老头儿”
- 想想挺可怕，但事实还没有那么糟糕。进公司做 DX 系统 3 年了，梳理的时候发现系统之间技术实现、业务模式基本没太大变化；而这 3 年，恰恰是互联网兴起变革大爆炸的 3 年。还有新业务线新系统在诞生......
>>关于心流 (flow) 和 稀缺
- 真正留心的事情才会产生心流，有同感。而《稀缺》因为改变吴博的人生观而被他极力推荐，我又做了一些延伸阅读。感觉道理和创客心态是互补的。稀缺并不可怕，可怕的是稀缺心态！过分极端可能会导致稀缺心态，需要把眼光放远一点，看看我们是如何越忙越没有时间，越穷越没有钱，越创新越跳不出牢笼的。
>>方法论
影响地图
精益数据分析
Quick Start
不确定性管思维处理方式
▲系统不确定性因素分析
把不确定性引向低成本，图中需求特性才是突破点，这和“会砍需求的PM才是好的PM”的道理是相通的。
Quick Start的启动方式确实是好用，有幸跟着亮哥和同事们做过一个快速启动，效率很高。
不确定的问题先给个可能是错误的解决方式，才能推动事情进行下去。这个技巧已经有了很好的日常应用和实践。比如推动系统功能细化时，就是采用先主动整理一份初稿再约大家讨论的方式，来应对连续几次讨论会大家无法都按时参加的窘境。
>>TO DO & TO SHARE
1. 颗粒化大需求，用作为...我可以...以便于...（As I So）定义用户故事。
细化需求这个我们组一直就在做，会有专人在分析评估需求时，重新拆分需求，形成为开发服务的在线wiki文档。我们组的开发是幸福的，他们看到的不是业务的一句话需求，而是细化后的有图文、甚至包含Gist代码示例的需求，所以开发起来可以进入心流之境。我们需要改进的就是细化需求的粒度，和阐述最小用户故事的描述方式。
另外吴博提到需求会讨论的形式要做一些改变。恰巧，我们组在前一周就刚刚自发变革了需求讨论会的方式。开发可以主动分组参与需求讨论，而不止是个聆听者。这样效率高，也避免了对需求理解的歧义。组里自发的变革和吴博倡导的方案不谋而合，这是一件很值得与组里同事分享的点，也激励和肯定了我们小团队在研发中的思考和进步。
2. 开发测试不分家，Mock、Fake保证最小验证
调整测试、开发分迭代的不同步现状，增加 Check Point 快速检视进度。Mock关联系统接口，Fake后台数据都是我们目前开发过程中没有做到的。预计三月底开始调整，并在组内推行。
3. 功能、埋点监控、自测是开发任务的一部分
在开发过程中，开发主动做埋点监控的意识还比较薄弱，需要分享和落实。
4. 学习灰度发布的实施方案
生产问题无法完全杜绝，而出现生产问题其实并不可怕，只要问题修复的快，影响是可以忽略不计的。灰度环境可以更快的验证生产，同时可以及时地切换、回滚。
>>分歧和反思
其实谈不上分歧，吴博只是基于目前我们的现状给了一个妥协的解决方案，而更偏理想主意的我才有了不一样的看法。
分歧一、自动化测试
实现自动化测试要求是很高的，需要开发人员具有测试的意识，测试人员具有开发的能力。虽然实施起来很困难，但有困难并不代表我们不去做。不做是降低标准、妥协的一种做法。我希望团队里的每个人都是强悍的，做开发做测试都是OK的。这里推荐一篇我在团队分享过的文章-《程序员怎样鉴定强悍的小团队》，别人一个小团队牛到没有专门的测试人员。所以，没有不可能，如何真正做好自动化测试才是问题解决之道。
分歧二、电子看板和物理看板
我认为电子看板好，我们组作为神兵（wizard）的小白鼠客户，最早接入电子看板。对比以前的物理看板，电子看板方便很多。使用以后，至少我是不会再去花很多精力维护物理看板。
▲我们看板定制的头像
>>总结
非常感谢吴穹博士这两天培训分享的精华，我大大小小记了27个要点，主要的都列在上面了，还有一些需要做发散和延伸性阅读学习。也争取尽快在工作实践中灵活应用。
