敏捷是不是可以缩短项目周期,或者说“敏捷就是快”?
敏捷就是快吗?一旦有人觉得不快时,就会发出质疑:我们的敏捷做对了吗? 敏捷真正的含义到底是什么?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
敏捷就是快吗?一旦有人觉得不快时,就会发出质疑:我们的敏捷做对了吗? 敏捷真正的含义到底是什么?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(1)
在接触敏捷之前,大家对敏捷都是一知半解,更多的停留在字面意思的理解上:“敏捷就是快”。一旦有人觉得不快时,就会发出质疑:我们的敏捷做对了吗? 其实,敏捷并不意味着“快”,“敏捷”在百度字典中的解释是“反应迅速快捷”。在软件开发中,敏捷是使用各种管理的手段(例如,3个角色,5个事件)来确保软件开发人员能够对于外部或者内部的需求或者变化能够迅速的做出反应,保证软件系统的功能或者其他特性能够满足市场或者用户的要求。
敏捷模型和瀑布式开发模型是对立的,瀑布式开发模型主要是“按部就班”的进行需求调研、系统设计、详细设计、功能开发、测试、上线,以及运维等,我相信大家对于瀑布式开发模型非常熟悉,现在大部分的甲方IT部门或者乙方公司都采用这样的交付管理手段。同样,大家和我也有相同的感触,系统的需求可能不断地在变化,或者是调研不清楚,亦或设计不能够满足用户需求,没有别的选择,只能硬着头皮加班加点修改,呵呵,这也是程序员经常吐槽的地方…本质上,瀑布式的开发模型是“非常害怕变化的”,一旦有“任何的风吹草动”整个项目组都紧绷神经,进而通宵达旦;而敏捷模型则是“拥抱变化的”,敏捷拒绝“一成不变”,崇尚软件系统功能“持续增强”,它是把整个软件交付周期“拆”成一个一个小的瀑布模型,每个瀑布模型持续一周或者两周,我们把它称作“冲刺”,在每一个冲刺中都要进行需求的讨论和确认,都要对交付的成果进行评审,并且项目组还要进行自身的反思和回顾,这样即使变化来了,我们通过敏捷模型能够“轻松的应对”。
有一个例子,共享单车刚刚起步的时候,市场上共享单车的公司不多,共享单车的创新是通过互联网和手机支付的手段,帮助和方便用户完成 “最后一公里”的交通出行。起初共享单车业务逻辑是一辆自行车的成本大约200元人民币,设计寿命是3年,用户骑行一次大约需要支付1块钱,一辆自行车一年差不多可以收回200元的成本,第二年和第三年就可以实现盈利。但是,没有想到不到半年时间,其他的共享单车如雨后春笋般的出现,而且价格更低,并且有各种优惠活动。第一个吃螃蟹的共享单车企业原来的商业模式已经失效,但是他们发现他们有一个很大押金池子,如何有效的利用这笔资金成了他们“最后的救命蒿草”,他们的软件系统功能如何支撑“有效的利用这笔资金”成为了他们迫在眉睫要解决的问题。如果采用瀑布式的开发模型,按部就班,“3个月或者半年之后交付”,可能市场又不知道发生了什么变化。而敏捷的模型则可以在一定程度上很好的应对这样的突发情况。
总之,敏捷的核心是快速地应对变化,本质上,它并不能缩短软件交付的周期。有时候我们感觉“敏捷快”是因为它能够快速的响应市场或者用户的需求变化,而不是以前瀑布模型中,用户和项目组都为“这个功能是这个样子的,而不是现在开发成的这个样子”而相互的扯皮,推诿…
当然,我们在瀑布模型中也会主动或者被动地使用到“敏捷”,用户提出需求变更,今天晚上或者明天就可以看到结果。