为什么我不推荐敏捷开发?
当项目成员越多,我越不推荐敏捷开发,原因在于「当连自己要做什么事、为什么这样做、这样做为了解决什么问题」都搞不清楚前,就跳下去玩敏捷开发,那和比通灵还惨,通灵起码还有个目标物在前面,搞不清楚状况的人只能陪他跳世界迷雾开地图了 。
敏捷开发 – MBA智库百科 最下方有段「对敏捷开发的误解」。可顺便参考 敏捷软件开发 – 维基百科。
误解一:敏捷对人的要求很高
说高不高啦,撇开实作技术不谈,你觉得要找到清楚项目开发流程、知道每位项目成员的工作内容、职责范围、产出,并清楚项目目标、需求、用户需要的开发人员(含设计师)很容易吗?
如果上述条件无法达成,又怎么确定运用敏捷开发方式后,所有项目成员方向都是正确的?就因为这种人太难找,所以会产生「对人要求很高」印象。
连在有企划书、规格书、用户研究报告的文件情况下都还不知道自己要干嘛、同事在干嘛,能谈敏捷吗?
误解二:敏捷没有文档,也不做设计
文件撰写与否和敏捷开发一点关系也没有,敏捷开发强调「适应性而非预见性」,并没有强硬规定。虽然有一句「可用的软件:重于 详尽的文件」,但它没有叫你不要写文件。
先想看看写文件是为了解决什么问题?如果不写文件会产生什么问题?
以 UI 设计师来讲,交出 UI Flow、Wireframe 这种文件是为了解决什么问题?要敏捷开发嘛就不用写了跳过,直接出 Mockup 吧。因为发现出包有漏改来改去改到死,和找到产品问题改良,是两回事啊!
敏捷开发不是没文件没流程的包装纸。
误解三:敏捷好,其他方法不好
敏捷开发就是一直小幅度改啊改啊改啊,可以增加工作效率,让大家工作更顺利喔~~(就算是瀑布流式的传统开发流程,设计师也是一直改啊改啊改啊,效率了什么、顺利了什么啊!?)
先承认有问题,才能找出问题,之后找解决方法。而不是先有方法,再想这个方法能解决什么问题。敏捷开发只是一种「方法」,方法论用在敏捷开发上,要回答两个问题:
- 现有模式为何不能满足你的需求?
- 敏捷式开发为什么可以?
敏捷开发不是万灵丹,先找到问题点、知道为什么要采取敏捷,重点是卡在哪里需要敏捷这个「方法」来解决。设计师改来改去是为什么解决什么问题?敏捷 开发的小幅度改来改去、和现况设计师的改来改去有什么不同?如果都一样为什么要采取敏捷?(不要跟我说因为软件开发主力是 RD 所以忘记算上设计师。)
现实的扭曲
个人与互动:重于流程与工具
开会是非常烧钱的行为,如果项目成员一多,要用什么方式降低沟通落差、尽量让每个人理解到的都相同?怎么确保部门和部门间的信息交流顺畅?靠出张嘴沟通就能办到吗?
可用的软件:重于详尽的文件
有文件产生/解决什么问题?没有文件产生/解决什么问题?不写文件最爱用「我们是敏捷开发」当借口了,不会写就不会写、不知道文件写来干嘛就老实承认,少拿这个当说词。
与客户合作:重于合约协商
如果客户没有在好的引导下一起合作,现实状况会变成「最后一次-确定最终版-说好不改了-V21.psd」。嗯?改来改去不就是敏捷开发吗?(喂)
回应变化:重于遵循计划
这不是改来改去改到死的好理由!为什么要「变化」,变化是为了解决什么问题?没有问题改它干嘛?完全不代表可以没计划就上啊!
结论
敏捷开发宣言里各种许愿…拔掉敏捷二字不也是所有项目开发的理想?所以为了解决什么问题而采用敏捷式开发?为了改善工作流程加快效率?
那设计师修改到死的工作情况在敏捷开发里要怎么被改善?
我觉得敏捷开发适用「头脑清楚」的人,只是这种人往往是大神级的了。和大神 PM、大神 Planner、大神 RD 合作,都清楚知道自己在干嘛、别人在干嘛,还能 Cover 一点别人的领域,知道解决这个问题可以往目标更进一步,这种合作模式才有办法做到「敏捷」,而不是因为抓漏抓虫在修改。是啦这也算朝目标迈进,但「创新改 良产品」和「让产品看起来洞没那么大」的改来改去本质上是两回事啊!敏捷开发只是个方法,不是万灵丹。
敏捷式开发就是改来改去?
那「字大一点、Logo大一点、换一张照片、多出几版让我挑」也算啊~
原文地址:blog.akanelee.me
作者:@Akane_Lee
确实没什么逻辑性
楼主说话像是西南地区人士
LZ讲的很不错,稍微偏激的描述还是刺激出了一些人的槽点
我觉得敏捷还挺好用的啊 可能因为我们用鱼骨敏捷项目管理开发过程吧 一个标志的大看板 再加上需求 迭代 bug这几个模块的管理 就很简单了啊
你是卖产品的,需求是什么,你怎么描述的。就是几行字吗。哈哈
通过以上内容,鉴定书呆子一个。
有点理解楼主的抱怨,不是说敏捷不好,而是说在很多现实情况下,采用敏捷并不能解决问题。对于敏捷方式的采用,需要考虑好需要解决哪些问题,而不是盲目的认为敏捷可以解决现实中出现的任何项目问题。敏捷宣言中的四条,在现实中有时确实很无力。个体和交互,现实中有很多的技术大牛、有能力有经验的人、有学习钻研精神的人,但是现在的很多软件开发人员,很多都是培训机构培训几个月就出来工作的,可想而知(当然不排除有优秀的人)。客户合作,很多客户都是想在最短时间,实现最多的功能,尤其对于不懂软件的人,频繁出现——这个功能应该很简单吧,明天可以给我吧,之类的。怎么样引导客户合作,确实是一个比较大的问题。响应变化,确实如楼主所说,有些变化真的是无理变化,或者说是举棋不定的结果,并不是所有的变化我们都需要及时响应的,同时也会导致很多浪费。而这种变化,可能在项目中却是多数。以上仅为个人工作中的经验,可能情况会有些极端吧。
个人感悟:敏捷首先从两个层次去理解,要做什么?为什么要这样做?然后就是3个“最”最短的时间,最有价值的事务和最小可用版本。在就是两个持续,持续进行迭代开发与运营,持续与用户沟通。我们都知道也常在嘴边念叨计划赶不上变化,敏捷的开发模式拥抱变化。
一直不理解,什么是传统开发模式,为什么传统开发模式就是瀑布模式,瀑布模式就没有迭代了吗?瀑布模式也可以多次迭代啊,也能拥抱变化啊,为什么瀑布模式不能多次迭代?
LZ,说实话没看懂你到底想说什么,思路太不清楚了,表达的目的也没说清楚
lz这篇文章的核心论点是:敏捷不是万灵丹,它是适合那些层次稍微高一点,知道大体框架要做什么的团队,敏捷的核心也是要在有足够强鲁棒性的框架下,再不断根据需求的变化而不断迭代优化,让这个大体框架逐渐明晰。这个和那些根本不知道自己的大体框架要干什么,上来就是东抓一把西抓一把,最后改成一锅粥的做法是有根本性区别的,首先鲁棒性上面都不够强!
所以他强调,在用敏捷方法前,先弄明白自己团队的项目大体框架上面要做什么!
敏捷对成员的要求确实高,但是也不全是这个样子的。
感觉作者不是特别理解敏捷开发,从外表看,敏捷开发和传统的瀑布开发差别很大,本质上敏捷也不是万能的,但是,之所以现在数以千计的项目转来做敏捷,尤其是大而复杂的项目,说明存在必有其道理。不可否认敏捷也有问题,但是相对于传统的那种要确定需求,设计,流程后才能开发产品的方法,敏捷能更大限度的减少损失(如果失败的话),我们都不喜欢改来改去,所以敏捷第一宣言就是,欢迎改变,究其原因是因为,事物是发展的,产品的环境是变化的,所以,我们一定要想那个小老鼠嗅嗅一样,保持敏感,从而达到敏捷。
从你的回答来看,你只会照版的别人的东西。多实践一下再去做回答。为什么传统的开发模式就一定是瀑布开发模式,瀑布开发模式为什么就不能迭代了。传统的开发开发模式也可以拥抱变化,快速迭代。为什么没有这样做?请思考一下这个问题?
从你的回答来看,你是来吵架的
说的好,就是这样。
lz试试真正的瀑布流就能知道效率有多低了~ps:瀑布流意味着有严格的界限,而界限意味着有繁冗的流程,更坑的还意味着不可逆性。
不是楼主需要知道什么,你经验太少,主要是人,瀑布流不一定效率低下,瀑布开发模式也可以多此迭代,主要是人。主要是即懂技术,有懂业务的大牛,有这样的人管理项目,不管瀑布和敏捷效率都会很高。没有这样的人,那个效率都很低。不要盲目的去下结论。
如果需求明确,确实适合瀑布模型,如果需求不明确,使用瀑布模型确实很麻烦,逆向修改要改动的东西太多,从需求规格说明书,概要设计,详细设计都要修改,但是在实际的开发中没有人会使用严格的某一种模式,大多是混合模式
瀑布模型效率是最高的,迅速就能做完整个项目,然后客户说我们的需求不是这样的,你理解错了,然后你就再次的从新设计整个项目
没有哪个人一生来就是大神的,楼主这个吐槽明显看出是个幽怨的UI。。。被pm要求改过去改过来了吧。。。。
赞