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

22 评论 238314 浏览 19 收藏 7 分钟

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

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

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

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

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

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

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

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

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

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

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

wireframe-grid-rule-of-thirds

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

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

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

  1. 现有模式为何不能满足你的需求?
  2. 敏捷式开发为什么可以?

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

wireframe-kit-v22

现实的扭曲

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

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

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

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

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

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

回应变化:重于遵循计划

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

结论

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

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

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

敏捷式开发就是改来改去?

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

 

原文地址:blog.akanelee.me

作者:@Akane_Lee

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 确实没什么逻辑性

    回复
  2. 楼主说话像是西南地区人士

    来自广东 回复
  3. LZ讲的很不错,稍微偏激的描述还是刺激出了一些人的槽点

    来自四川 回复
  4. 我觉得敏捷还挺好用的啊 可能因为我们用鱼骨敏捷项目管理开发过程吧 一个标志的大看板 再加上需求 迭代 bug这几个模块的管理 就很简单了啊

    来自北京 回复
    1. 你是卖产品的,需求是什么,你怎么描述的。就是几行字吗。哈哈

      来自河北 回复
  5. 通过以上内容,鉴定书呆子一个。

    来自广东 回复
  6. 有点理解楼主的抱怨,不是说敏捷不好,而是说在很多现实情况下,采用敏捷并不能解决问题。对于敏捷方式的采用,需要考虑好需要解决哪些问题,而不是盲目的认为敏捷可以解决现实中出现的任何项目问题。敏捷宣言中的四条,在现实中有时确实很无力。个体和交互,现实中有很多的技术大牛、有能力有经验的人、有学习钻研精神的人,但是现在的很多软件开发人员,很多都是培训机构培训几个月就出来工作的,可想而知(当然不排除有优秀的人)。客户合作,很多客户都是想在最短时间,实现最多的功能,尤其对于不懂软件的人,频繁出现——这个功能应该很简单吧,明天可以给我吧,之类的。怎么样引导客户合作,确实是一个比较大的问题。响应变化,确实如楼主所说,有些变化真的是无理变化,或者说是举棋不定的结果,并不是所有的变化我们都需要及时响应的,同时也会导致很多浪费。而这种变化,可能在项目中却是多数。以上仅为个人工作中的经验,可能情况会有些极端吧。

    来自江苏 回复
  7. 个人感悟:敏捷首先从两个层次去理解,要做什么?为什么要这样做?然后就是3个“最”最短的时间,最有价值的事务和最小可用版本。在就是两个持续,持续进行迭代开发与运营,持续与用户沟通。我们都知道也常在嘴边念叨计划赶不上变化,敏捷的开发模式拥抱变化。

    来自广东 回复
    1. 一直不理解,什么是传统开发模式,为什么传统开发模式就是瀑布模式,瀑布模式就没有迭代了吗?瀑布模式也可以多次迭代啊,也能拥抱变化啊,为什么瀑布模式不能多次迭代?

      来自河北 回复
  8. LZ,说实话没看懂你到底想说什么,思路太不清楚了,表达的目的也没说清楚

    来自江苏 回复
    1. lz这篇文章的核心论点是:敏捷不是万灵丹,它是适合那些层次稍微高一点,知道大体框架要做什么的团队,敏捷的核心也是要在有足够强鲁棒性的框架下,再不断根据需求的变化而不断迭代优化,让这个大体框架逐渐明晰。这个和那些根本不知道自己的大体框架要干什么,上来就是东抓一把西抓一把,最后改成一锅粥的做法是有根本性区别的,首先鲁棒性上面都不够强!

      所以他强调,在用敏捷方法前,先弄明白自己团队的项目大体框架上面要做什么!

      来自广东 回复
  9. 敏捷对成员的要求确实高,但是也不全是这个样子的。

    来自江苏 回复
  10. 感觉作者不是特别理解敏捷开发,从外表看,敏捷开发和传统的瀑布开发差别很大,本质上敏捷也不是万能的,但是,之所以现在数以千计的项目转来做敏捷,尤其是大而复杂的项目,说明存在必有其道理。不可否认敏捷也有问题,但是相对于传统的那种要确定需求,设计,流程后才能开发产品的方法,敏捷能更大限度的减少损失(如果失败的话),我们都不喜欢改来改去,所以敏捷第一宣言就是,欢迎改变,究其原因是因为,事物是发展的,产品的环境是变化的,所以,我们一定要想那个小老鼠嗅嗅一样,保持敏感,从而达到敏捷。

    来自辽宁 回复
    1. 从你的回答来看,你只会照版的别人的东西。多实践一下再去做回答。为什么传统的开发模式就一定是瀑布开发模式,瀑布开发模式为什么就不能迭代了。传统的开发开发模式也可以拥抱变化,快速迭代。为什么没有这样做?请思考一下这个问题?

      来自河北 回复
    2. 从你的回答来看,你是来吵架的

      来自上海 回复
  11. 说的好,就是这样。

    来自上海 回复
  12. lz试试真正的瀑布流就能知道效率有多低了~ps:瀑布流意味着有严格的界限,而界限意味着有繁冗的流程,更坑的还意味着不可逆性。

    来自北京 回复
    1. 不是楼主需要知道什么,你经验太少,主要是人,瀑布流不一定效率低下,瀑布开发模式也可以多此迭代,主要是人。主要是即懂技术,有懂业务的大牛,有这样的人管理项目,不管瀑布和敏捷效率都会很高。没有这样的人,那个效率都很低。不要盲目的去下结论。

      来自河北 回复
    2. 如果需求明确,确实适合瀑布模型,如果需求不明确,使用瀑布模型确实很麻烦,逆向修改要改动的东西太多,从需求规格说明书,概要设计,详细设计都要修改,但是在实际的开发中没有人会使用严格的某一种模式,大多是混合模式

      来自上海 回复
    3. 瀑布模型效率是最高的,迅速就能做完整个项目,然后客户说我们的需求不是这样的,你理解错了,然后你就再次的从新设计整个项目

      来自上海 回复
  13. 没有哪个人一生来就是大神的,楼主这个吐槽明显看出是个幽怨的UI。。。被pm要求改过去改过来了吧。。。。

    来自广东 回复
    1. 来自上海 回复