BT

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

50位开发人员的答案:你最想让CIO了解敏捷的哪个方面?

| 作者 Mark Levison 关注 0 他的粉丝 ,译者 李剑 关注 1 他的粉丝 发布于 2008年2月20日. 估计阅读时间: 4 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

你是否正在尝试给CIO解释敏捷软件开发的好处?你的老板是否需要来自外界的确认?CIO杂志的Esther Schindler为你完成了这件艰难的工作。她向50多个开发人员和敏捷实践者问了一个同样的问题:“如果你想让老板理解和敏捷开发相关的一件事情,只能选一件,你会选择什么?理由呢?”。 他们的回答被分为7类:

1. 敏捷可以创建更好的软件

Sonic Innovations的技术领导人Kelly Anderson说过:“低劣的质量会浪费钱,很多钱。敏捷会提升质量,提升得很高,以致可以降低成本”。《软件测试:经验与教训》《计算机软件测试》的作者Cem Kaner也提到:“敏捷开发可以降低晚期变化所带来的开销,IT组织可以更容易响应相关干系人的需求变更” 。

2. 敏捷思想不仅仅是过程

敏捷是协同工作的一种方式,来自Wizewerx的Mike Sutton这样说:“它是对传统思维方式的一个挑战。这个过程是痛苦的,因为它迫使组织和个人正视其工作中的浪费、低效和缺点。”敏捷开发会影响整个组 织。对于一个组织而言,要想成功地实施敏捷开发,来自顶层的支持是至关重要的(译者注:InfoQ上曾有过相关方面的报道,请参见渐进式敏捷:由下而上的敏捷推行策略)。

3. 敏捷改变的不仅仅是开发流程

Esther指出,拥抱敏捷将会(并且应该)改变公司的文化与过程。伴随着更频繁的反馈和更多的协作,组织就会被迫去解决那些已然存在但是被忽略已久的问题。

另外,频繁反馈也意味着客户更快地看到价值,开发人员会得到有关前进方向的反馈。来自iDIA Computing的咨询师George Dinwiddie说:“反馈的延迟越短越好。减少作出决定与决定被实施之间的时间,就可以减少浪费。”

4. 敏捷并不是意味着“混沌为美”

Deltacom的QA经理Mike Emeigh指出,优秀的敏捷团队依然需要需求分析和设计:“他们只是不会浪费时间把它(译者注:指软件分析与设计,下文同)落到大堆大堆的纸上,[或 是]一群根本不可能理解所有[问题]的人在将它转化成可以工作的软件之前试着去学习理解它。”。

5. 敏捷的收获是值得我们为之等待的

按照TEKSystems的服务交付执行官James Kricfalusi的观点,收益并不是立等可取的。他建议说,人们不要期望看到立竿见影的成效,而应该以原来项目中所花的时限来判断过程的优劣。

6. 敏捷不是银弹

无论做什么事情,走向卓越都需要认真付出,关注细节。“……团队需要自律,严格的工作过程,管理层的支持和学习时间……在敏捷开发中,更多的收获来自于卓越,而非平庸。”身为独立咨询师和《敏捷开发艺术》作者的James Shore如是说。

7. 成功依赖于人

Colosseum Builders的所有者Miano说:“敏捷方式的开发对个人有很强的依赖性……在这种环境下工作的人需要有忽略他人怪癖的能力。”

Steve Reiser(一位资深软件工程师)说到,如果团队可以快速响应,常能获得阶段性成功,那么团队成员就会感到快乐,更好地发挥他们的主观能动性。

在Esther的文章Getting Clueful: 7 Things CIOs Should Know About Agile Development后面还有很多很多回复……

查看英文原文50 Developers Answer: What Do You Want Your CIO to Know About Agile?

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

8. 敏捷并不代表更快 by Jacky Li

在英文站上,有读者如是回复
我不知道为什么头头们会以为用了敏捷方法以后,项目的用时、所耗资源就会更少。我本以为这种事情只会发生在我的国家(阿根廷),但事实并非如此,这种想法处处可见。CIO们,如果你们真想理解敏捷含义的话,就请你们不要再把软件开发当作工厂了……软件开发是创造性的工作,工程师不是机器,我们是专业人士……

Re: 8. 敏捷并不代表更快 by hong yong

可是管理者都想让软件开发成为工厂,或者在某种意义上成为工厂。

“软件工厂”与“软件开发”矛盾吗? by Zhang Charlie

有读者说:

CIO 们,如果你们真想理解敏捷含义的话,就请你们不要再把软件开发当作工厂了……软件开发是创造性的工作,工程师不是机器,我们是专业人士……


汽车开发是创造性的工作,汽车研发工程师不是制造汽车的机器,他们是专业人士 ... 请问,汽车研发工程师与自动化的汽车工厂矛盾吗?

我发现,这些年来国内外不少人总是拿软件工程师与制造工厂的设备去比,这种比喻其实并不恰当,可以说是比错了阶段,比错了对象,真是误人子弟。

软件需要研发,汽车同样需要研发,制造行业的研发工作同样是非常富有创造性的。而软件工厂,作为一种异常成功的商业模式,其实早就存在很久了。

制造行业有敏捷制造,而软件行业可以有敏捷软件。软件研发是不是工厂,其实与敏捷不敏捷没什么关系。

敏捷教练 张恂
www.zhangxun.com

Re: 8. 敏捷并不代表更快 by Zhang Charlie

可是管理者都想让软件开发成为工厂,或者在某种意义上成为工厂。


现代化的自动化工厂有许多好处,其中显著的一点就包括:大批量、低成本的复制和制造。请问,刻一张光盘的成本是多少?有人说,软件(后期)制造的成本接近于 0。而借用电子的速度,构建软件自动化,恰恰是创造软件神奇的重要一个根源。

从这个角度看,微软恰恰是世界上最赚钱、最成功的“软件工厂”之一。卖拷贝、卖 license 的工厂,当然比单纯卖人力的工厂要好得多。请问,微软的毛利率是多少?

软件工厂模式当然是一个虚拟化的概念,它意味着我们可以从传统制造行业学习、借鉴很多成功经验,它的好处,其实还有很多 ...

敏捷不代表“更快”不如改叫“敏爽” by Zhang Charlie

如今任何一位非文盲,具有小学文化水平的人,恐怕都懂得“捷”的含义。如今有洋人(大洋彼岸之人)说了,“敏捷并不代表更快”,那么,咱还留着“捷”字干嘛?是不是我们译错了,Agile 不应该译成“敏捷”?究竟是谁第一个把 Agile 译作“敏捷”的,现在很难考证了。

如果 Agile 不应该叫做“敏捷”,那么叫做“敏秀”,“敏爽”,“敏杰”,怎么样?或者干脆用直译,叫尊贵的“啊极乐”方法,ok?

玩笑归玩笑,敏捷的“快”其实有多种含义。

首先,敏捷的“捷”是指反应快,应变快,措施快,能够快速地应对变化,响应变化,包括各种风险。这是 Agile 的本意,属于真理部分,应该不会错的。

至于项目能否更快地完成,这倒未必是一个重点。过去软件工程界有一个经验数值,超时 20% 通常是一个可以接受的范围。所以,认为敏捷就一定是要赶时间,提前完成项目,其实没有这个必要。

敏捷方法能够提高质量,这点应该也没有问题,属于 common sense,而且被过去多年来的实践已经证明了。而软件质量提高了,返工、废品、折腾自然就少了。因而从长远来说,敏捷可以缩短开发时间,提高开发效率,减少资源的耗费,也在情理之中。

世界上只有两种方法,一种是代表“旧势力”的传统方法,另一种是代表“进步势力”的敏捷方法。如果敏捷方法不能在项目的 time, cost, quality, risk 等等生产要素、衡量指标方面,处理、完成得比旧方法更好,请问,我们到底为什么要拥抱敏捷?难道仅仅是为了像消费时尚歌曲、电影、霓裳一样,作一个喜新厌旧的追星族?

敏捷教练 张恂
www.zhangxun.com

允许的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通知我

5 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT