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、防腐层，通过对接口进行隔离，避免领域外的变化对自己产生影响。

最后来几张“大咖颠覆会谈”

敏捷小圈