1月2号，雾霾满天飞，但是今天是敏捷小圈2016的第一次聚会，敏娜、黄喆、范文斌、程鹏等敏捷大咖分享了众多精彩的内容，小弟我自愿当记录员，记下各位大咖的分享精华。
1、人群分析（黄喆、程鹏）
5%的前沿思考者
20%的积极分子
70%的稳健人员
5%的保守人员
在实际的改进转型中，挖掘20%的积极分子是非常重要的，通过20%的积极分子引导70%的稳健人员，可以让变革工作事半功倍。
如果leader不属于20%的范围，则推进难度很大（鼎桥案例）
可以考虑与leader一起参加一些前沿会议，触发leader进行思考。（黄喆建议）
2、spotify的案例分享（敏娜）
a、守、破、离（黄喆）
spotify的团队成员非常了解scrum，所以团队的运作重点是掌握核心思想，选择合适的实践方法执行
然而大部分情况下，团队对scrum只是部分了解，因此可以参考其他案例，从“守”做起，照搬成功的实践，一步一步尝试，发现团队中存在的问题，然后打“破”规则，设计合适自身团队的实践，不断学习演进走向卓越。
当团队熟练的掌握敏捷思想，则可以根据项目的情况，订制合身的实践。
b、自组织团队
愿景如何建立？
短期目标是如何与愿景link上？
这两个问题颇有点只能意会，不可言传的感觉。（我有点忘记是怎么讨论的了）
自组织团队的一个重要要求是领导和项目团队来电，然而在实践中，很容易出现团队自主性太强而忽视领导的要求，或者团队习惯于领导的管理而缺乏自主性（鼎桥案例）
交付如果让领导满意，则会获得更多自主的权利，因此建议先关注交付和愿景的一致性。（我个人的体会）
弱标准、强习惯，优秀的实践会自动被其他团队学习演进，形成公共的习惯。
c、接口编程
系统的设计是否对敏捷很关键？
d、工会形式的团队建设
交流形式，无压力的社区组织模式
3、沟通（范文斌）
不同于团队沟通，与领导的沟通，可能不会很直接。
a、领导的视角很广，与之沟通，尽量视角同步
b、领导真正的问题，未必会直接说出来，需要通过不断交流挖掘
说实话，我觉得要做到真的好难。
4、业务需求挖掘（黄喆）
a、建立需求优先级树，让优先级可视化，在开发过程中，优先级是可能会发生变化的，但是这种变化要反映在优先级树上，让项目知道他们聚焦在高优先级的工作上
b、建立业务原型，让需求可视化。（HTML建立网页版的业务原型）
c、严抓测试，交付以测试为主，避免“带病交付”
d、邀请真实的用户来验证产品，确认高价值的交付，如果存在问题，宁愿不做新需求，先把高价值的交付搞定。
5、DDD（敏娜）
a、通过业务模型中的名词建立设计模型中的对象，最好是一个模型就行~
b、模型使用统一的描述语言（例如有java、c、sql，但是在模型中，描述是业务和研发都能理解）
c、防腐层，通过对接口进行隔离，避免领域外的变化对自己产生影响。
最后来几张“大咖颠覆会谈”
