剖析短迭代
敏捷教练Dave Nicolette提出：我们应该如何设定迭代长度？是要根据发布周期的时间么？使用短迭代又有哪些好处？
新闻
50位开发人员的答案：你最想让CIO了解敏捷的哪个方面？
作者 Mark Levison译者 李剑 发布于 2008年2月19日 下午7时44分
你是否正在尝试给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后面还有很多很多回复……
8. 敏捷并不代表更快
发表人
凉粉 小刀
发表于
2008年2月19日 下午8时12分
Re: 8. 敏捷并不代表更快
发表人
yong hong
发表于
2008年2月19日 下午11时10分
Re: 8. 敏捷并不代表更快
发表人
Charlie Zhang（张恂）
发表于
2008年2月20日 上午12时42分
“软件工厂”与“软件开发”矛盾吗？
发表人
Charlie Zhang（张恂）
发表于
2008年2月20日 上午12时21分
敏捷不代表“更快”不如改叫“敏爽”
发表人
Charlie Zhang（张恂）
发表于
2008年2月20日 下午8时52分
-
在英文站上，有读者如是回复：
我不知道为什么头头们会以为用了敏捷方法以后，项目的用时、所耗资源就会更少。我本以为这种事情只会发生在我的国家（阿根廷），但事实并非如此，这种想法处处可见。CIO们，如果你们真想理解敏捷含义的话，就请你们不要再把软件开发当作工厂了……软件开发是创造性的工作，工程师不是机器，我们是专业人士……
-
可是管理者都想让软件开发成为工厂，或者在某种意义上成为工厂。
-
有读者说：
CIO 们，如果你们真想理解敏捷含义的话，就请你们不要再把软件开发当作工厂了……软件开发是创造性的工作，工程师不是机器，我们是专业人士……
汽车开发是创造性的工作，汽车研发工程师不是制造汽车的机器，他们是专业人士 ... 请问，汽车研发工程师与自动化的汽车工厂矛盾吗？
我发现，这些年来国内外不少人总是拿软件工程师与制造工厂的设备去比，这种比喻其实并不恰当，可以说是比错了阶段，比错了对象，真是误人子弟。
软件需要研发，汽车同样需要研发，制造行业的研发工作同样是非常富有创造性的。而软件工厂，作为一种异常成功的商业模式，其实早就存在很久了。
制造行业有敏捷制造，而软件行业可以有敏捷软件。软件研发是不是工厂，其实与敏捷不敏捷没什么关系。
敏捷教练 张恂
www.zhangxun.com -
可是管理者都想让软件开发成为工厂，或者在某种意义上成为工厂。
现代化的自动化工厂有许多好处，其中显著的一点就包括：大批量、低成本的复制和制造。请问，刻一张光盘的成本是多少？有人说，软件（后期）制造的成本接近于 0。而借用电子的速度，构建软件自动化，恰恰是创造软件神奇的重要一个根源。
从这个角度看，微软恰恰是世界上最赚钱、最成功的“软件工厂”之一。卖拷贝、卖 license 的工厂，当然比单纯卖人力的工厂要好得多。请问，微软的毛利率是多少？
软件工厂模式当然是一个虚拟化的概念，它意味着我们可以从传统制造行业学习、借鉴很多成功经验，它的好处，其实还有很多 ... -
如今任何一位非文盲，具有小学文化水平的人，恐怕都懂得“捷”的含义。如今有洋人（大洋彼岸之人）说了，“敏捷并不代表更快”，那么，咱还留着“捷”字干嘛？是不是我们译错了，Agile 不应该译成“敏捷”？究竟是谁第一个把 Agile 译作“敏捷”的，现在很难考证了。
如果 Agile 不应该叫做“敏捷”，那么叫做“敏秀”，“敏爽”，“敏杰”，怎么样？或者干脆用直译，叫尊贵的“啊极乐”方法，ok？
玩笑归玩笑，敏捷的“快”其实有多种含义。
首先，敏捷的“捷”是指反应快，应变快，措施快，能够快速地应对变化，响应变化，包括各种风险。这是 Agile 的本意，属于真理部分，应该不会错的。
至于项目能否更快地完成，这倒未必是一个重点。过去软件工程界有一个经验数值，超时 20% 通常是一个可以接受的范围。所以，认为敏捷就一定是要赶时间，提前完成项目，其实没有这个必要。
敏捷方法能够提高质量，这点应该也没有问题，属于 common sense，而且被过去多年来的实践已经证明了。而软件质量提高了，返工、废品、折腾自然就少了。因而从长远来说，敏捷可以缩短开发时间，提高开发效率，减少资源的耗费，也在情理之中。
世界上只有两种方法，一种是代表“旧势力”的传统方法，另一种是代表“进步势力”的敏捷方法。如果敏捷方法不能在项目的 time, cost, quality, risk 等等生产要素、衡量指标方面，处理、完成得比旧方法更好，请问，我们到底为什么要拥抱敏捷？难道仅仅是为了像消费时尚歌曲、电影、霓裳一样，作一个喜新厌旧的追星族？
敏捷教练 张恂
www.zhangxun.com
.gif)
5 条回复
回复