序
之前在 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代码示例的需求，所以开发起来可以进入心流之境。我们需要改进的就是细化需求的粒度，和阐述最小故事的描述方式。作为...我可以...以便于... (As I So) 这样的句式可以帮助实例化需求。
另外吴博提到需求会讨论的形式要做一些改变。恰巧，我们组在前一周就刚刚自发变革了需求讨论会的方式。开发可以主动分组参与讨论需求，而不是以往会议聆听者的形式，这样效率高，而且避免了需求理解的二一性。组里自发的变革和吴博倡导的方案不谋而合，这是一件很值得与组里同事分享的点，也激励和肯定我们小团队在研发中的思考和进步。
2.开发测试不分家，Mock、Fake保证最小验证
调整测试、开发分迭代的不同步现状，增加 Check Point 快速检视进度。Mock关联系统接口，Fake后台数据都是我们目前开发过程中没有做到的。预计三月底开始调整和组内推行。
3.功能、埋点监控、自测是开发任务的一部分
在开发过程中，开发主动做埋点监控的意识还比较薄弱，需要分享和落实。
4.学习灰度发布的实施方案
生产问题无法完全杜绝，而出生产问题其实并不可怕，只要问题解决修复的快，那影响是可以忽略不计的。灰度环境可以更快的验证生产，同时可以及时的切换、回滚。
分歧和反思
其实谈不上分歧，吴博只是基于目前我们的现状给了一个妥协的解决方案，而更偏理想主意的我才有了不一样的看法。
分歧一、自动化测试
实现自动化测试要求是很高的，需要开发人员具有测试的意识，测试人员具有开发的能力。实际实施起来很困难，但困难并不代表我们不去做。不做其实是降低标准，妥协的一个做法。我希望一个团队的成员每个都是强悍的，做开发做测试都是OK的。这里推荐一篇和我们团队分享过的文章程序员怎样鉴定强悍的小团队，别人一个小团队牛到没有专门的测试人员。所以，理想是美好的，而如何真正做好自动化测试才是问题解决之道。
分歧二、电子看板和实体看板
我认为电子看板好，我们组作为神兵的小白鼠客户，最早接入电子看板。对比以前的实体看板，电子看板方便很多，使用以后，至少我是不会再去花很多精力维护实体看板。但电子看板的问题在于，如何可视化体现项目的进展、阻碍、积压，这个我们还需要去摸索，也是我们的TO DO项，实现起来也并不难。
总结
非常感谢吴穹博士这2天培训分享的精华，我大大小小记了27个要点，主要的都列在上面了，还有一些需要做发散和延伸性阅读学习。也争取尽快在工作实践中灵活应用。
