为什么都敏捷开发了项目还会延期?!| 技术头条

Posted CSDN

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了为什么都敏捷开发了项目还会延期?!| 技术头条相关的知识,希望对你有一定的参考价值。

为什么都敏捷开发了项目还会延期?!| 技术头条

作者 | 王晔倞

责编 | 郭   芮

上个月,我曾写过一篇《》的文章,与大家探讨在传统企业里,如果搞互联网架构会遭遇哪些问题,并结合自己的经历聊一下心得体会。


说来也怪,在互联网盛行的这十几年里,我见过很多认真学习互联网思维的传统企业,虽然从技术架构、组织结构、到工作模式,都学得有模有样,绘声绘色,但基本都停留在 “四不像” 的阶段。


这种半吊子工程,不仅增加了内部矛盾,还降低了工作效率。


当然,导致这种现象的原因有很多,什么犹豫不决啊,什么错失时机啊,或者什么运营与营销手段过时等等。在外人看来,似乎都很有道理,但却没有命中核心。


在我看来,这和绝大多数的传统企业高管年龄偏大,且整体管理水平陈旧有关。


为什么都敏捷开发了项目还会延期?!| 技术头条


简单来说,很多传统企业老板平均年龄在40岁以上,高管起码在35岁以上,这些人在传统营销领域经验丰富,但随之而来的问题是对互联网不精通。他们大部分是业务好手,但整体现代化管理理念、管理技能与企业发展要求,还存在一定距离。


不仅如此,他们基本没有技术背景,对互联网架构的理解只局限于 “别出事”,对项目管理模式的理解只局限于 “快上线”。


记得在某次敏捷话题的分享中,在提问环节时,有位老板模样的大叔向我发问:“你们都鼓吹敏捷能提升研发效率,但为什么我们用了敏捷之后,项目周期该延误的还是照旧,成本也得不到有效的控制,真不明白为什么你们还整天瞎嚷嚷这个好,那个好,吹牛很好玩是吗?”


我脾气本来就爆,听完这番话的第一反应就想给他怼回去,或者干脆回他一句 “你不懂技术,没必要跟你解释。” 但我还是很礼貌的说了一番大道理,最终指着大屏幕违心地说了一句 “这是我的个人微信,今后可以多多交流。”


对方愣了几秒,面带微笑的点了点头,坐下了。但从他的表情上可以看出,对于这样的回答,他并不买账,估计心里早就用那三个字骂了千百遍了。


不过这也正常,在我的经验值里,如果自认为对研发与测试有着不少功底的话,那对项目管理模式就完全是门外汉了。有人说,门外汉还能站到台上去分享?这还多亏的这张伶俐嘴,和实践中积累了充分的案例,至少能在面对技术理科男的时候显得更加游刃有余,但在面对这种有备而来,并略带调侃的提问,的确显得有些措手不及。


为什么都敏捷开发了项目还会延期?!| 技术头条


进入现在的公司以来,我逐渐养成了 “遭遇挫折或不满事件,必复盘” 的习惯,通过翻阅大量资料及与其他公司的交流,对这个问题进行了梳理和规整。


如果再遇到类似提问,我想我会这样回答:


敏捷,解决的不是速度的问题,而是灵活性的问题。


就好比在短跑比赛中,速度最快的人种基本是黑种人,为什么呢?因为目标是明确的,拼的是身体素质,黑种人相比白种人、黄种人,天生就具有这方面的优势,当然也最有可能成为冠军。


短跑比赛,相当于一个需求明确且不会发生变更的业务项目,而黑种人,相当于某个采用瀑布式开发模式的技术团队,中途没有障碍,大家都把眼睛瞪大,撒开腿跑,一口气跑到终点,成本与效率一定是最低的。


当今的互联网业务,更像是一场羽毛球比赛。


就算面对同一个对手,每一场比赛的节奏,每一次出球的线路,都是完全不同的。在应对策略上,经验越丰富的球员越是能够增大预判的准确性,合理分配自己的体能和发力点,该快的时候快,该慢的时候慢,使自己的优势发挥至最大,最终赢得比赛。


很显然,敏捷模式不是万能的。


如果你的产品需求相对稳定,目标明确且很少走回头路,产品与技术的KPI各自为战,重视过程和强调文档,那就用瀑布式吧。


如果你的产品需求不明确,产品与技术的目标同为 “客户最终受益” 为宗旨,试探性需求偏多,接受不断尝试,不断试错的价值观,那就用敏捷式吧。


有人说,你这样讲还是太理论化,在现实的敏捷实施中,还是有人困扰于 “版本快结束的时候,需求要进行大范围调整” ,你质问他为什么?他会理直气壮地告诉你,“敏捷不就支持不确定性变更吗?”


对,敏捷的确支持,增加一个迭代周期来解决就行了,但时间与成本肯定会提升。


再说了,从敏捷的视角来看,目标变了等同于重新设定了新版本,重新再来自然需要更多时间。在这种场景下,非要给 “敏捷并未解决项目延误的问题” 的罪名,好像并不合适。


另外,虽然敏捷具有 “保持灵活性以便满足用户需求” 的功效,但用户往往对这种灵活性期望过高了,从而导致团队在持续交付价值的时候举步维艰。


在很长一个阶段里,我很反对敏捷,因为我觉得这为 “反复无常是正常的” 找到了一种借口。


你看,敏捷允许用户甚至能够在大型项目的后期调整优先级,但很多产品并不理解 “交付能力是有上限的” 这个道理。他们并不能真正理解速度和时间的度量标准,但却总是期望可以随时添加新的需求而且能及时得到交付。


我想,这也正是 “你们不是用敏捷了吗?那怎么项目还延期呢?” 这句话的由来吧。

声明:本文为作者投稿,版权归作者个人所有。



 热 文 推 荐 



☞ 

☞ 

☞ 

☞ 

print_r('点个好看吧!');
var_dump('点个好看吧!');
NSLog(@"点个好看吧!");
System.out.println("点个好看吧!");
console.log("点个好看吧!");
print("点个好看吧!");
printf("点个好看吧!\n");
cout << "点个好看吧!" << endl;
Console.WriteLine("点个好看吧!");
fmt.Println("点个好看吧!");
Response.Write("点个好看吧!");
alert("点个好看吧!")
echo "点个好看吧!"

点击阅读原文,输入关键词,即可搜索您想要的 CSDN 文章。

喜欢就点击“好看”吧!

以上是关于为什么都敏捷开发了项目还会延期?!| 技术头条的主要内容,如果未能解决你的问题,请参考以下文章

关于敏捷开发的一些想法

《​敏捷开发管理精髓》——谢明志老师敏捷/管理

敏捷开发的几个特点

小米 13 系列新品发布会将延期举行;马斯克:和苹果的误解得到了解决;IntelliJ IDEA 2022.3 发布|极客头条

敏捷开发很棒,但不是万能药

敏捷项目与任务看板