BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

敏捷和瀑布的恩恩怨怨

| 作者 Christopher R. Goldsbury 关注 0 他的粉丝 ,译者 金毅 关注 0 他的粉丝 发布于 2011年10月26日. 估计阅读时间: 3 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

是采用瀑布模型还是敏捷方法?网站Scrumology的站长David J Blant认为答案应该取决于对所要解决的问题和方案的了解程度。

David在他的文章中提出了以下几个观点:

1. 当几乎完全了解所需解决的问题和方案的时候,用敏捷方法还是瀑布模型只是个人口味不同而已。

2. 当几乎完全了解所需解决的问题但对相应的方案知之甚少的时候,敏捷方法行得通,而瀑布模型则不适用。

3. 当对要解决的问题和方案都几乎知之甚少时,敏捷方法行得通,而瀑布模型则不适用。

在文章结尾处,David总结了他的观点:

敏捷方法与瀑布模型之间的争论旷日持久。短期内没有一方打算退出,但这争吵俨然成了白色噪声(white noise)。它让我们偏离了真正的问题,即我们是否都清楚要解决的问题或方案。

所以让我们停止把所有的灾难都归咎于瀑布模型,相反大家扪心自问,我们是不是为手头上的工作选择了正确的工具。

此文在LinkedIn的敏捷群组中备受关注。起初很多跟帖都赞成David的观点,但随着大家的进一步讨论,很多人逐渐清晰地认识到,在软件开发过程中,需要解决的问题和相应的方案都很清晰的情况已经几乎不存在了。比如来自Chris Shield的一条评论就谈到:

我认为在软件开发中永远不可能100%了解解决方案——永远不会。从第一天开始,就一直有变更,新的假设层出不穷,随后假设再被证明是不成立的,业务部门的新需求姗姗来迟,等等。

Greg Robinson认为:

软件开发本质上是一个探索和开发的过程,在此过程中,你历经无数潜在方案蜿蜒前行,最终得到一个合适的最佳选择。顺着这个思路,你可以考虑从制造业流程中引入更多实践,比如规划蓝图、与每个人达成共识,但第一次构建就正确无误地完成(OTOBOS)是最乐观的情况,也是所有瀑布模型的根本性缺陷。应该说,即使是为一个两周的sprint制订计划都很难,更何况是为项目做一年的详细计划了(你现在还打算不折不扣照着所谓的需求文档做一年的计划吗,即使当时它们是正确的?)

其他的评论则讨论了在软件开发过程之初就已经非常了解所要解决的问题和/或方案的可能性。然而,似乎能够一致确定的是,瀑布模型和敏捷方法在管理这类的项目时都能占有一席之地。

另外,我们也听到了网上一些不同的声音,包括Pawel Bradzinski撰写的博文。他的观点是:人,而不是流程或方法决定了软件开发过程的成功。

另外有些人针对影响软件开发的各种相关因素做了许多深入透彻的分析。Tom Peplow就在2008年给出过很棒的建议。

查看英文原文:Known vs Unknown

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

敏捷跟瀑布不是直接VS的 by 张 晓庆

迭代模型,而不是敏捷,是用来VS瀑布模型的
这样的争论没有太大的意义

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

深度内容

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT