当专案成员越多，我越不推荐敏捷开发，原因在于「当连自己要做什么事、为什么这样做、这样做为了解决什么问题」都搞不清楚前，跳下去玩敏捷开发，那和比通灵还惨，通灵起码还有个目标物在前面，搞不清楚状况的人只能陪他跳世界迷雾开地图了。
　　"敏捷开发 - MBA智库百科" 下方有段「对敏捷开发的误解」。可顺便参考" 敏捷软体开发 - 维基百科"。
　　误解一：敏捷对人的要求很高
　　说高不高啦，撇开实作技术不谈，你觉得要找到清楚专案开发流程、知道每位专案成员的工作内容、职责范围、产出，并清楚专案目标、需求、使用者需要的开发人员（含设计师）很容易吗？
　　如果上述条件无法达成，又怎么确定运用敏捷开发方式后，所有专案成员方向都是正确的？因为这种人太难找，所以会产生「对人要求很高」印象。
　　连在有企划书、规格书、使用者研究报告的文件情况下都还不知道自己要干嘛、同事在干嘛，能谈敏捷吗？
　　误解二：敏捷没有文档，也不做设计
　　文件撰写与否和敏捷开发一点关系也没有，敏捷开发强调「适应性而非预见性」，并没有强硬规定。虽然有一句「可用的软体：重于 详尽的文件」，但它没有叫你不要写文件。
　　先想看看写文件是为了解决什么问题？如果不写文件会产生什么问题？
　　以 UI 设计师来讲，交出 UI Flow、Wireframe 这种文件是为了解决什么问题？要敏捷开发嘛不用写了跳过，直接出 Mockup 吧。因为发现出包有漏改来改去改到死，和找到产品问题改良，是两回事啊！
　　敏捷开发不是没文件没流程的包装纸。
　　误解三：敏捷好，其他方法不好
　　敏捷开发是一直小幅度改啊改啊改啊，可以增加工作效率，让大家工作更顺利喔～～（算是瀑布流式的传统开发流程，设计师也是一直改啊改啊改啊，效率了什么、顺利了什么啊！？）
　　先承认有问题，才能找出问题，之后找解决方法。而不是先有方法，再想这个方法能解决什么问题。敏捷开发只是一种「方法」，方法论用在敏捷开发上，要回答两个问题：
　　1. 现有模式为何不能满足你的需求？
　　2. 敏捷式开发为什么可以？
　　敏捷开发不是万灵丹，先找到问题点、知道为什么要采取敏捷，重点是卡在哪里需要敏捷这个「方法」来解决。设计师改来改去是为什么解决什么问题？敏捷开发的小幅度改来改去、和现况设计师的改来改去有什么不同？如果都一样为什么要采取敏捷？（不要跟我说因为软体开发主力是 RD 所以忘记算上设计师。）
　　现实的扭曲
　　个人与互动：重于 流程与工具
　　开会是非常烧钱的行为，如果专案成员一多，要用什么方式降低沟通落差、尽量让每个人理解到的都相同？怎么确保部门和部门间的资讯交流顺畅？靠出张嘴沟通能办到吗？
　　可用的软体：重于 详尽的文件
　　有文件产生/解决什么问题？没有文件产生/解决什么问题？不写文件爱用「我们是敏捷开发」当藉口了，不会写不会写、不知道文件写来干嘛老实承认，少拿这个当说词。
　　与客户合作：重于?合约协商
　　如果客户没有在好的引导下一起合作，现实状况会变成「后一次-确定终版-说好不改了-V21.psd」。嗯？改来改去不是敏捷开发吗？（喂）
　　回应变化：重于?遵循计划
　　这不是改来改去改到死的好理由！为什么要「变化」，变化是为了解决什么问题？没有问题改它干嘛？完全不代表可以没计划上啊！
　　结论
　　敏捷开发宣言里各种许愿...拔掉敏捷二字不也是所有专案开发的理想？所以为了解决什么问题而采用敏捷式开发？为了改善工作流程加快效率？
　　那设计师修改到死的工作情况在敏捷开发里要怎么被改善？
　　我觉得敏捷开发适用「头脑清楚」的人，只是这种人往往是大神级的了。和大神 PM、大神 Planner、大神 RD 合作，都清楚知道自己在干嘛、别人在干嘛，还能 Cover 一点别人的领域，知道解决这个问题可以往目标更进一步，这种合作模式才有办法做到「敏捷」，而不是因为抓漏抓虫在修改。是啦这也算朝目标迈进，但「创新改良产品」和「让产品看起来洞没那么大」的改来改去本质上是两回事啊！敏捷开发只是个方法，不是万灵丹。
　　敏捷式开发是改来改去？
　　那「字大一点、Logo大一点、换一张照片、多出几版让我挑」也算啊～