在我看来，敏捷的目的：通过一切手段来激发成员的主动性（owner精神），以便快速迭代给用户带来价值。

激发主动性的手段有：

1. 每日站会。昨天干了什么，后续准备干什么（让成员做出承诺，有承诺，才有主动性），遇到什么阻碍？

2. 创造一个好的工作环境，自由的氛围，让大家自由发言，只要人人都发言，就会有参与感，就更主动。

3. 发自内心的去关注并引导团队成员成长。

4. 头衔不要太细。都叫工程师，如此开发和测试就能互相帮忙，而不是说开发就干开发。比如xx项目xx部门xx岗位。如果头衔太细，那么a项目不会帮b项目。a项目中的a部门不会去帮a项目中的b部门。

快速迭代的手段有：

1. 把需求切细。切成一个个能单独运行的小功能，功能越小，在开发人员还有耐心之前即可把功能开发完。早点上线，用户就能早点感受其价值并给出反馈，团队也能快速验证方向的正确性。

2. 面对3个月后才会做的大需求，先做一个风险评估，并把有风险的事先解决了，没必要提前去拆分需求，若现在花很多时间去拆分需求，等3个月后，大需求变了，是否白拆了？

3. 敏捷提倡当面沟通，当面沟通固然好，但当面沟通只适用于小团队，因此敏捷倡导一个团队3～9人。若不同成员在不同办公地点，是做不到当面沟通的。即使能当面沟通，真的适合每一个人吗？善于表达的人也善于带节奏，其的观点往往更被其他人接受，但后果有，a其观点即使逻辑洞察匮乏，也容易被其他人接受，b其会把那些不善于表达但富于洞察的言论给遮盖掉。因此“静默评审”基于文档的优势就体现出来了，基于文档沟通，大家都是对着一份文档进行文字输出观点。这样会相对客观。找到合适的沟通方式。

4. 专注。一个开发手上最好最多同时进行两个需求，即使两个需求卡住了，也不能去做新的需求，如果卡住就可以去想办法把这两个需求推下去或帮其他同事。同样对于产品经理来说，也是一样，产品经理的活一般是比较杂的，如果不专注的话，就会感觉一天啥事也没干就过去了。

5. 共用一套语言体系。比如写用户故事，作为XX人，我希望XX功能，以便实现XX愿望。目前还无法把这个用户故事进行落地。

6. 防止人员流失带来短暂瘫痪。老带新，3个人各一个人负责一个模块，和3个人，每人负责每个模块的3分之一，如此就不怕会有短暂的瘫痪。目前不知道实施是否困难？

带来价值的手段有：

1. 需求优先级。首先做风险评估，把风险提前处理掉。再看其他衡量维度：价值、新需求还是优化需求、必要功能还是惊喜需求（必要功能必须要做，惊喜需求，一次做一个即可），是否是被依赖的需求，被依赖的需求要先做。

2. 和用户一起，并不是用户说什么就满足什么，而是通过用户反馈的信息去洞察背后动机，但如果连做饭的米都没有，即使洞察力强也没用。用户信息是一个洞察的必要条件。

3. 可预测性，比如一个需求开发完，最短最长需要多长时间，如果跨度越小，那么说明可预测性越强，风险就越小。平均5～6天开发一个需求，和3～7天开发一个需求，业务会更喜欢前者。就像黄峥说的，确定性也是有价值的，工厂愿意为了确定性买单。这也是为什么有些工厂不去得罪大企业的客户，因为大企业的需求更可靠，确定性更高。

以上是我的分享，希望有用！