Ruby x Agile：从机器工作效率到人的工作效率的转变

作者 Sam Aaron 译者 仝键 发布于 2007年9月17日

领域

架构 & 设计,

过程 & 实践,

语言 & 开发

主题

Ruby ,

编程 ,

方法论 ,

敏捷

标签

投资回报率

这篇文章是介绍Ruby x Agile系列的第二篇，该系列文章记录了一套包含六个简短视频，视频探讨Ruby和敏捷方法论之间的关系。我们第一篇文章的内容是为什么Ruby和敏捷是一个好的组合。

这些视频的主要内容是Ruby的创始人松本行弘（Matsumoto, Yukihiro，昵称Matz，株式会社网络应用通信研究所[NaCl]的特别研究员）、自以为“敏捷煽动者（Agile agitator）”的平锅健儿（Hiranabe, Kenji，Change Vision公司的CEO）和Ruby的支持者角谷信太郎（Kakutani, Shintaroh，永和系统管理株式会社服务提供部的程序员[Service Providing Div. Programming, Eiwa System Management, Inc.]）之间的一场讨论。

该系列的这一部分以一场关于关注焦点从对CPU效率进行优化到对程序员效率进行优化转变的讨论开始。

“以前，CPU时间确实是宝贵的，但是现在人们的时间更宝贵，而且关注点已经转变到让人们从事的工作更加容易了。”

他们讨论了社会对IT依赖的增长和相关的程序开发成本之间的关系，并得出这样的结论：使用人力去节省CPU时间的观念将变得非常奢侈，而且解决方案并不是增加程序员数量，而是使用更好的工具和实践：

“如果我们转变关注点，并且在（计算的）和人相关的一面着手工作，将不需要这么多的程序员。我觉得，这个概念在诸如XP/敏捷或者Rails这样的运动中被体现了出来。”

“从机器效率向人的效率进行的转变已经产生。”

但是，Matz认为目前在CPU效率应被优先考虑的仅存领域就是超级计算（super-computing）。

视频最后以关于传统软件开发和敏捷软件开发所引入的过程之间区别的讨论收尾。三人介绍到，包含市场调研、下订单、交付和发布的传统工作流迭代（如第一图所示）需要花费一个季度到三年的时间才能完成。他们认为，如果将这些工作流单位的同步序列分解成更小的异步块的话（如第二图的内循环所示），那么可能能在一周到三个月内完成一次迭代。

“这么一个周期要花费一个季度到一年或者更多，也许甚至能达到三年之久。”

“当我们从这个模型（图一）转换到这个模型（图二），那这就是敏捷了。达到这一步的关键是语言的力量、业务和过程的同步或者匹配。”

当要求他解释“内循环（inner loop）”的含义时，平锅用下面的回答剖析到：

• （作为一个项目）敏捷是一个面向共有目标，在业务和IT方面协同工作的团队，即所谓的“内”。
• （作为一个过程）敏捷是一系列短期迭代，即所谓的“循环”。

您可以观看该系列相应的视频来了解更多的内容。这些视频的语言是日语，配有相应的英文字幕。

查看英文原文：Ruby x Agile: The shift from machine-performance to human-performance

---

译者简介：仝键，网名“咖啡屋的鼠标”，普通程序员。喜欢思考，沉默时沉闷至死，说起来却又无边无际。爱好广泛常恐有贪多不精之后遗症。从小接触电脑却白白荒废十余年光阴，直至大学之后才入编程之门。如今漂泊北京寻找着自己的一片天地。感兴趣的技术领域有Agile、Java、设计模式、Flex、Ruby和面向对象数据库等。个人技术博客为http://blog.csdn.net/tj19832/。参与InfoQ中文站内容建设，请邮件至china-editorial[at]infoq.com。

• 更早的 >