敏捷开发思想自进入国内以来，火了一批产品经理，坑了一堆程序员。
敏捷开发好不好，仁者见仁，但是要说其对于传统开发来说具有绝对优势，是有待商榷的。从经验上说，当项目成员越多（成员数量的临界点不好说，还是要看具体项目）敏捷开发越难，原因就在于当连自己要做什么事，为什么这样做，这样做解决了什么问题都没有搞清楚的时候情况下，就奋不顾身的跳下去玩敏捷，妄想做第一批吃螃蟹的人，那结果可能比通灵更不靠谱，通灵起码还有个标的物在前面，而状况都搞不清的情况下，进入的只能是迷雾世界了。
实际上，长期以来对敏捷开发的误解一直都在，对这些误解做一下简单的梳理，可能有助于对这种现象有一个较好的理解。
误解一：敏捷对人的要求很高
要说敏捷对技术水平有一定的要求，那是毋庸置疑的，但是远远达不到天花板的程度。再者，撇开技术不说，有谁会觉的清楚找到项目开发流程、知道每位项目成员的工作内容、职责范围、产出，并清楚项目目标、需求、用户需要的开发人员（含设计师）很容易呢？
如果上述基础条件都无法达成，又怎么能确定运用敏捷开发方式后，所有项目成员方向都是正确的？就因为这种人太难找，所以会产生对人要求很高的印象。
而且在有企划书、规格书、用户研究报告的文件情况下都还不知道自己要干嘛、同事在干嘛，那敏捷就更没有意义了。
误解二：敏捷不需文档，也不做设计
文件撰写与否和敏捷开发可能一点关系也没有，敏捷开发强调“适应性而非预见性”，并没有任何强硬的规定。但是还有一句“可用的软件重于详尽的文件”，什么意思呢，就是告诉你文件不是不写，而是不需要累死在文件中。
应该先想想写文件是为了解决什么问题？如果不写文件会产生什么问题？
以 UI 设计师来讲，交出 UI Flow、Wireframe 这种文件是为了解决什么问题？要敏捷开发嘛就不用写了跳过，直接出 Mockup 吧。因为发现出包有漏改来改去改到死，和找到产品问题改良，根本就是两回事吧！
敏捷开发不是没文件没流程的包装纸。
误解三：敏捷好，其他方法不好
技术没有好坏，但是开发思想有高有低，只不过很多开发思想做着做着就变异了。很多人都以为敏捷开发就是一直小幅度改啊改啊改啊，可以增加工作效率，让大家工作更顺心，甚至就连瀑布流式的传统开发流程，设计师也是一直改啊改啊改啊，原因同样是有效率。
难道不是应该先承认有问题，再找出问题，之后找解决方法嘛？而不应该是先有方法，再想这个方法能解决什么问题。敏捷开发只是一种方法，方法论用在敏捷开发上，要回答两个问题：
现有模式为何不能满足你的需求？
敏捷式开发为什么可以？
敏捷开发不是万灵药，先找到问题点、知道为什么要采取敏捷，重点是卡在哪里需要敏捷方法来解决。设计师改来改去是为什么解决什么问题？敏捷开发的小幅度改来改去、和现况设计师的改来改去有什么不同？如果都一样为什么要采取敏捷呢？（有了RD设计师也不能忘啊）
项目开发的扭曲现实
个人与互动：重于流程与工具
开会是非常消耗时间成本的事情，钱也在不知不觉中溜走了，当项目成员很多，要用什么方式降低沟通落差、尽量让每个人理解到的都相同？怎么确保部门和部门间的信息交流顺畅？靠出张嘴沟通就能办到吗？
可用的软件：重于详尽的文件
有文件产生/解决什么问题？没有文件产生/解决什么问题？不写文件最爱用「我们是敏捷开发」当借口了，不会写就不会写、不知道文件写来干嘛就老实承认，拿这个当说辞，不是给敏捷开发抹黑嘛。
与客户合作：重于合约协商
如果客户没有在好的引导下一起合作，现实状况会变成“最后一次-确定最终版-说好不改了- ∞ ”。嗯？改来改去不就是敏捷开发吗？喂！！！
回应变化：重于遵循计划
这不是改来改去改到死的好理由！为什么要变化，变化是为了解决什么问题？没有问题改它干嘛？完全不代表可以没计划就上啊！
总结
敏捷开发宣言里各种许愿…拔掉敏捷二字不也是所有项目开发的理想？所以为了解决什么问题而采用敏捷式开发？为了改善工作流程抑或加快效率？
那设计师修改到死的工作情况在敏捷开发里要怎么被改善？
我觉得敏捷开发适用头脑清楚的人，只是这种人往往是大神级的了。和大神 PM、大神 Planner、大神 RD 合作，都清楚知道自己在干嘛、别人在干嘛，还能 Cover 一点别人的领域，知道解决这个问题可以往目标更进一步，这种合作模式才有办法做到敏捷，而不是因为抓漏抓重再修改。这也算朝目标迈进，但创新改 良产品和让产品看起来洞没那么大的改来改去本质上是两回事，敏捷开发只是个方法，而不是百病包治的灵丹妙药。
如果真的改来改去就算敏捷的话，那字大一点、Logo大一点、换一张照片、多出几版让我挑一挑，应该也算吧。
网友评论