快好知 kuaihz

为什么我不推荐敏捷开发?

当项目成员越多,我越不推荐敏捷开发,原因在于「当连自己要做什么事、为什么这样做、这样做为了解决什么问题」都搞不清楚前,就跳下去玩敏捷开发,那和比通灵还惨,通灵起码还有个目标物在前面,搞不清楚状况的人只能陪他跳世界迷雾开地图了 。

敏捷开发 – MBA智库百科 最下方有段「对敏捷开发的误解」。可顺便参考 敏捷软件开发 – 维基百科。

误解一:敏捷对人的要求很高

说高不高啦,撇开实作技术不谈,你觉得要找到清楚项目开发流程、知道每位项目成员的工作内容、职责范围、产出,并清楚项目目标、需求、用户需要的开发人员(含设计师)很容易吗?

如果上述条件无法达成,又怎么确定运用敏捷开发方式后,所有项目成员方向都是正确的?就因为这种人太难找,所以会产生「对人要求很高」印象。

连在有企划书、规格书、用户研究报告的文件情况下都还不知道自己要干嘛、同事在干嘛,能谈敏捷吗?

误解二:敏捷没有文档,也不做设计

文件撰写与否和敏捷开发一点关系也没有,敏捷开发强调「适应性而非预见性」,并没有强硬规定。虽然有一句「可用的软件:重于 详尽的文件」,但它没有叫你不要写文件。

先想看看写文件是为了解决什么问题?如果不写文件会产生什么问题?

以 UI 设计师来讲,交出 UI Flow、Wireframe 这种文件是为了解决什么问题?要敏捷开发嘛就不用写了跳过,直接出 Mockup 吧。因为发现出包有漏改来改去改到死,和找到产品问题改良,是两回事啊!

敏捷开发不是没文件没流程的包装纸。

误解三:敏捷好,其他方法不好

敏捷开发就是一直小幅度改啊改啊改啊,可以增加工作效率,让大家工作更顺利喔~~(就算是瀑布流式的传统开发流程,设计师也是一直改啊改啊改啊,效率了什么、顺利了什么啊!?)

先承认有问题,才能找出问题,之后找解决方法。而不是先有方法,再想这个方法能解决什么问题。敏捷开发只是一种「方法」,方法论用在敏捷开发上,要回答两个问题:

现有模式为何不能满足你的需求?

敏捷开发为什么可以?

敏捷开发不是万灵丹,先找到问题点、知道为什么要采取敏捷,重点是卡在哪里需要敏捷这个「方法」来解决。设计师改来改去是为什么解决什么问题?敏捷 开发的小幅度改来改去、和现况设计师的改来改去有什么不同?如果都一样为什么要采取敏捷?(不要跟我说因为软件开发主力是 RD 所以忘记算上设计师。)

现实的扭曲

个人与互动:重于流程与工具

开会是非常烧钱的行为,如果项目成员一多,要用什么方式降低沟通落差、尽量让每个人理解到的都相同?怎么确保部门和部门间的信息交流顺畅?靠出张嘴沟通就能办到吗?

可用的软件:重于详尽的文件

有文件产生/解决什么问题?没有文件产生/解决什么问题?不写文件最爱用「我们是敏捷开发」当借口了,不会写就不会写、不知道文件写来干嘛就老实承认,少拿这个当说词。

与客户合作:重于合约协商

如果客户没有在好的引导下一起合作,现实状况会变成「最后一次-确定最终版-说好不改了-V21.psd」。嗯?改来改去不就是敏捷开发吗?(喂)

回应变化:重于遵循计划

这不是改来改去改到死的好理由!为什么要「变化」,变化是为了解决什么问题?没有问题改它干嘛?完全不代表可以没计划就上啊!

结论

敏捷开发宣言里各种许愿…拔掉敏捷二字不也是所有项目开发的理想?所以为了解决什么问题而采用敏捷开发?为了改善工作流程加快效率?

那设计师修改到死的工作情况在敏捷开发里要怎么被改善?

我觉得敏捷开发适用「头脑清楚」的人,只是这种人往往是大神级的了。和大神 PM、大神 Planner、大神 RD 合作,都清楚知道自己在干嘛、别人在干嘛,还能 Cover 一点别人的领域,知道解决这个问题可以往目标更进一步,这种合作模式才有办法做到「敏捷」,而不是因为抓漏抓虫在修改。是啦这也算朝目标迈进,但「创新改 良产品」和「让产品看起来洞没那么大」的改来改去本质上是两回事啊!敏捷开发只是个方法,不是万灵丹。

敏捷开发就是改来改去?

那「字大一点、Logo大一点、换一张照片、多出几版让我挑」也算啊~

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:为什么我不推荐敏捷开发?  敏捷  敏捷词条  为什么  为什么词条  推荐  推荐词条  开发  开发词条  
攻略

 人到中年,越来越少发朋友圈

人到中年,身边的人也跟着到了中年,我仔细看了看微信朋友圈里的中年人,得出一个结论就是越成功的职场中年人就越少发朋友圈。但是他们平时的确使用微信,很多工作上的沟通...(展开)

攻略

 人际关系法宝:白领必须懂得的22...

第一条必须有一个圈子。无论如何做都是画地为牢;不加入一个圈子,就成为所有人的敌人;加入一个圈子,就成为另一个圈子的敌人;加入两个圈子,就等于没有加入圈子。只有独...(展开)