敏捷的核心是相互信任与认可。这是我在公司成员面前分享经验的时候的心得。太多团队的失败正是来源于这一点，因为不信任队友，不愿意放手，导致整个团队分崩离析。
在海贼王中，路飞有一句话我记在心里：“我的确不会什么剑术，我不懂航海术，也不会做菜，也不会骗人，我相信没有别人的帮助我就活不下去！ ”
是的，在之前一家公司当中，在团队当中，我就是这样和团队一起活下来的。我并非一个全能型人才，在我的团队里配备了后端、前端、测试、UI、项目经理。我负责给出靠谱的产品方法、不断给产品拉资源、给团队打鸡血。
-----------------------------------
究竟什么样的团队才适合「敏捷开发」
1. 小团队
这点应该毋庸置疑。
从生活经验上来看，小动物一般用敏捷来形容，比如兔子、猫（当然，大动物也有，如：这头猪真胖，但它竟然还这么敏捷）。
小团队不会出现大团队那种尾大不掉的情况，「敏捷开发」进度可能每天都会变化，小团队有着更低的管理成本，产品经理可以很好的把控整个团队节奏。
当然，小团队也是要五脏俱全的。
2. 需求聚焦
如前文所说，大家采用「敏捷开发」肯定是有目的的。不管什么目的，肯定是为了快速响应、快速上线。这时，产品需求一定要聚焦、再聚焦。
有太多团队都是开发到后期突然要改一些不影响大局的东西，比如界面不好看、Icon不精致、交互不酷炫、需求Cover面窄。这些东西放在普通开发节奏的团队中是没有大问题的，但是在「敏捷开发」团队中，只会拖慢整个团队进度，本末倒置。
3. 工作内容无边界
及时补位的思想是要深入到每个团队成员心里的。
「敏捷开发」的团队或是初创团队一般都是一个人当好几个人用，每个人都是多面手（这也是好多朋友觉得小公司好的一点，即负责的内容多、成长快），原因就是他们的工作没有边界。
比如底层开发生病了，中间层大哥一定要顶上；比如QA人手不够了，产品经理写测试用例并参与测试也是常见的事。
4. 团队无明显短板
越小的团队越容易暴露问题，木桶理论在小团队中更容易体现。
「敏捷开发」过程很容易被团队中的短板所影响，这事虽然其他成员也有及时补位的精神，但每个人精力毕竟有限，我们还是希望能够每个人各尽其职。补的应该是未知的突发情况，而不是可预见的短板，这两个本身就不是一回事。
5. 互相信任
团队目标必须高度一致，并且相互信任，尽量少的辜负其他人。
产品绝对信任开发评估结果，开发绝对信任产品发起的需求等等。少质疑多沟通，才能快速实现目标。
好多大团队都会有各种需求评审、用例评审，每天文山会海，而「敏捷开发」会尽可能简化这个流程。但是我们要说的评审只是手段，目的还是要锤炼产品需求。因此纠结于是否该简化评审流程的朋友们，请尝试理解“不要把手段当目的”这句话。弱化评审的前提一定是产品经理自己已经将需求想明白，即满足团队预期、满足产品预期，再进行交付。
6.拥抱变化
之所以采用「敏捷开发」，真正的目的是快速响应、解决问题。当外界环境发生变化的时候，一定要及时接受并拥抱变化。
所谓的变化来自两方面。一方面是外部变化，比如产品方向和预期不符、市场反馈不好等；一方面是内部变化，比如效果图或者交互真的需要改动才能上线等。
面对这种未知的问题，团队里的相关人员需要及时调整心态，一起拥抱变化。
总结
「敏捷开发」需谨慎，一定要扪心自问团队是否满足上面说的几点。
「敏捷开发」不是万能的，解决问题才是王道，切勿盲目崇拜。
PS. 「敏捷开发」过后，产品经理一定要整理文档，否则快是快了，什么都没留住。切记，切记！！！
