来自《互联网产品之美》。
4个核心思想
1、强调面对面的沟通，也就是说沟通很重要，任何人的相互交流胜于任何流程和工具；
2、要把精力集中在可执行的程序上，可以运行的产品胜于综合性文档，也就是强调了原型、模型、演示等的重要性；
3、团队合作和团队激励，合作胜于谈判，敏捷开发能将需求分析、开发、测试等全部团队成员融合成一个整体，大家都是“一条线上的蚂蚱”；
4、团队成员要有超强的适应能力，适应变化胜于按部就班，敏捷开发的特点就是快速，对于互联网行业来说，这点非常重要。
敏捷设计强调的是团队成员的高度参与，目的就是要让大家统一认识，把团队的目标变成每个人的工作目标，并得到每个团队成员的认同，
形成高度的凝聚力，以达到群策群力、高效协作的效果。
在敏捷设计过程中，由于没有高度细化的文档，成员之间交互信息的唯一渠道就是面对面沟通，良好的团队氛围和协作关系促进了这种沟通，
并使得消息有效传达。
上面几段话，总体比较靠谱，文档方面值得进一步探讨。
下面是自己的3点看法：
1、老外提出的很多概念、想法，可能是有一定的适用场景，也有可能是到了国内就“水土不服”，因为国内极度强调效率等特色化的东西。
懂得自然都懂。
我所经历学习到的：UML统一建模语言、敏捷开发、领域驱动设计、单元测试（国内普遍都是“伪”单元测试）。
概念都挺好，就是难以落地。
2、敏捷开发
国内存在非常推崇敏捷开发的人群，也有很多相关书籍和实际。
在xx厂xx团队期间，有幸参与了“敏捷开发”模式。
总的观点：“新瓶装旧酒，换汤不换药”。其实，很难见到全新的事物和方法论，通常只是名字不同，但内涵其实都差不太多。
比如，敏捷开发的特有实践：早会、晚会、看板、认领工作和工时、master角色。
存在不接地气或者无法“普试”的做法。
1）、快速开发、快速上线。
普遍存在一种现象，很多上游人群对“敏捷开发”的直观认识，就是：我提出一个需求，你们赶紧开发，赶紧上线。
单方面强调，加班加点干活。
“敏捷开发”成了让下游加班干活，快速出成果，廉价劳动力的借口和幌子。
2、早会和晚会
对于很多场景来说，会开多了，没啥意思，除了浪费时间。
1天大概就8小时，除去开会，进度不会那么明显。
频繁的开会，哪有这么快的进度更新。
如果跨部门、跨项目或者人员较多时，每个人的节奏根本就不同，比如上班下班时间点。
3）、看板
需求方或者大家之间，对别人的工作，根本没那么在乎。
如果是需求方和进度管理有需要，直接1个在线Excel表格或wiki页面即可。
纸质看板，写纸条、描述任务、贴纸条，已经过时啦。
通常来说，老板要的是：总的进度计划、里程碑节点、好的结果，提出需要协调解决的问题，任务细节没那个功夫关注。
结果优先。
4）、认领工作和工时
普遍存在一种情况：每个成员的定位角色，就决定了每个人该干嘛。
认领工作适用于自组织的情况？什么场景合适呢？
5）、master角色
一般不就是组长、项目经理、产品经理等人担任么？
做的事情有啥本质区别吗？
还是说只是形式不同，名称不同？
3、事物发展需要的条件和环境
橘生淮南则为橘，橘生淮北则为枳。
事物生长发展，需要相应的环境和土壤。
只吹好处，不讲环境，是无法落地的，最终只是形式而已。
中国的制度、人文环境、行业特点，都需要考虑，否则容易变了味，甚至成了相关人群的单方面道具。
文章出处登录后可见！
